Do you know about chair pants? Making their appearance in an episode of 2023 TV series Jury Duty, Todd, cast as a socially awkward inventor, shows up to the courtroom wearing crutches that swing out from his waist and allow him to sit wherever he pleases. When wearing his chair pants, Todd goes about his day and never worries about chairs again!

I have found myself thinking about Todd and his chair pants when I hear people talking about how AI will revolutionize software engineering. One of the more extreme predictions is that AI models will soon replace the work of software engineers entirely! With recent advances in AI, companies will soon be able to go about their day and never have to worry about writing code again.

In my experience, many of these promises sound a lot like Todd’s chair pants: Sure, they allow you to “not think about chairs” as you move about your day. (Think of all the money the world could save on chairs!)

But they also make it impossible to sit anywhere else. Watching Todd attempt to board a bus or get in the jurors’ box while wearing his chair pants is as funny to me as watching Devin, the so-called first AI software engineer, struggle to perform basic software engineering tasks.

3 Reasons Why AI-assisted Coding Isn’t Replacing Software Engineers

There are three reasons why I think we are still in the “chair pants era” of AI-assisted coding.

1. LLMs that write code do not solve software problems more generally.

Todd’s chair pants do not solve sitting in general; they solve sitting specifically in the case where you are standing on firm ground with no other obstacles.

Similarly, LLMs, like any software development tool, can be helpful at solving certain kinds of problems, like greenfield coding.

In my experience, software engineers don’t spend most of their time writing greenfield code. It’s spent figuring out where to put the few new lines of code actually needed, and debating how much refactoring is needed to get there.

Another sign that LLMs do not solve software problems in general is that they tend to take a brute force approach to problem solving, and can struggle to use common abstractions like recursion.

2. Badly generated code may be worse than no generated code at all.

When Todd is not using his chair pants, they get in his way and make it harder to go about his day. Anyone who has lost a day (or a month!) diagnosing an issue with a codegen tool knows that using generated code in production requires a high level of trust in the tool.

In the case of LLMs, even if the bad code can be dismissed, it can still break developers out of flow or worse, lead them down a dead end path, resulting in an overall decrease in productivity.

3. LLMs might give the right solution to the wrong problem.

What outcome was Todd after with his invention? If he wanted to be able to rest his back or legs, I’m not sure if lugging around a pair of heavy crutches attached to his waist actually helped him.

For teams considering adopting LLMs into their development workflows, it is important to focus on the intended impact of these tools. Are these tools leading to faster development cycles, less time waiting for manual code reviews, and fewer bugs in production?

In my experience, the quality of these models is often measured by the number of recommendations generated by the model that were accepted by the developer. Although this is a good proxy for model accuracy, what if the developer accepts the recommendation only to replace it later, or what if a recommendation was accepted that ended up raising an issue during code review, only to delay the deployment of the code into production. More holistic measures are needed to understand how LLMs impact development teams.

How to Avoid Building the Wrong Solution

At 8th Light, we help our clients avoid building “chair pants” solutions to problems leveraging a variety of software approaches, including AI software solutions. For example, one client wanted a document AI solution that never extracted text from document scans. My team designed and delivered a human-in-the-loop solution that enabled a few human raters to perform text extraction exceptionally well. As the model improved in performance, the human raters had less and less to do, until eventually enough trust in the model was gained to enable fully automated extractions.

I encourage you to take a similar approach to AI-assisted coding. Don’t believe products that promise you will never have to worry about code again. They are only disguising the real task that these models are trained to do, which is to generate code, not to solve problems.

Instead, approach this emergent technology as you would any other tool — one with the potential to accelerate software delivery in your teams. Keep in mind that the value of an invention is not in its novelty but in its utility.

As software professionals, we should not just assume that AI-assisted coding will help our teams! If we don’t try to quantify the outcome of AI-assisted coding tools, we run the risk of paying the price for a tool that just gets in the way of developers. No offense to Todd, but no one wants his chair pants.

For more on 8th Light’s approach to AI-assisted coding, see our pulse report on AI-assisted Coding: Benefits and Considerations.