> If they mean turning a well-specified problem into runnable code, they’re increasingly right.
Has coding ever meant anything else? This is just semantics, but I don't think a product person talking to customers to find out what they need has ever considered their work to be coding, even if the fruits of their discovery eventually ends up as code.
> Code was always the medium
Exactly. If you discovered that what the customer really needed was a wooden cabinet you'd build that instead. You wouldn't give them code and expect it to hold their belongings. Code has never entered the picture until you have something that is well-specified.
What LLMs and coding agents do is drastically increase the opportunity cost of writing code by hand. But there are downsides to this. The value in a mature codebase is not number of lines of code. If you've worked with one, you know that lots of code can often be more of a liability than an asset. Lots of code increases the maintenance burden, it increases the complexity burden, it makes hunting down bugs harder. Lots of code signals not just complexity but poorly managed complexity. So really, in most codebases the opportunity cost of writing code was already incredibly high.
The other downside is that programming, especially in a high level language (i.e. not assembly), is not usually this discrete process of ideate -> plan -> write -> test -> review or whatever. Programming is a continuous interaction in which the computer is providing feedback in real time. This is why reducing build time is so powerful because it lets you get feedback faster. This is why IDEs are a good idea because it lets you get feedback faster. Certainly there are people and disciplines where you write out a detailed specification and implement it. But I think most programming is more fluid where as you write you then see where the inefficiencies and clunkiness is and you can adjust in real time. It becomes obvious if your design was bad or based on inappropriate assumptions because when you go to implement it you will feel the wrongness of it. And using agents robs you of this process.
Think of the difference between using an agent and writing code by hand like the difference between recording a live guitar or programming a track with MIDI. You can perfectly make a MIDI track that sounds just like a live guitar, you can program micro-timing adjustments, bends, and expressions. Or you can actually play a guitar. This requires building from a big vat of experience that not everyone has. But you get to feel the guitar vibrate in your hand and become part of this tight feedback loop of you and the instrument. I'm not saying one is better than the other. I'm just saying they produce different kinds of music even though they could in theory produce the same music.
The counterargument is now the AI agent is doing this process. Agents have an internal monologue where they write, test, update, test, etc. They also make difficult search or refactor jobs easier. But AI agents can't viscerally feel something is wrong or inappropriate because they can't have the lived experience of maintaining code. They can't feel the cost of having to add functionality into something that was designed and implemented poorly so it takes forever. What they can do is copy really well. And maybe they are so good at copying they will copy all the right patterns.
But in the meantime, because these tools cannot microadjust and become part of a very tight feedback loop right now it poses a problem. These tools push the evaluation of code further down in time where the cost is greater. To reiterate, the maintenance and refactoring of code was already what a lot of us are spending a lot of our time on in the first place. And pushing that work down the line makes the most expensive part of software engineering even more expensive.
This article misses the point. It assumes that the way business is currently done will be the way business is always done, but the LLM revolution aims to replace businesses that have these types of constraints sure initially it will work with them, but soon enough scrappy codebases will come out that hold their own and stand the test of time with LLMs at the helm
Even "add a button" should be questioned. See the XY problem.
> If they mean turning a well-specified problem into runnable code, they’re increasingly right.
Has coding ever meant anything else? This is just semantics, but I don't think a product person talking to customers to find out what they need has ever considered their work to be coding, even if the fruits of their discovery eventually ends up as code.
> Code was always the medium
Exactly. If you discovered that what the customer really needed was a wooden cabinet you'd build that instead. You wouldn't give them code and expect it to hold their belongings. Code has never entered the picture until you have something that is well-specified.
I think it's easier to explain the anomalous "chess is solved".
What LLMs and coding agents do is drastically increase the opportunity cost of writing code by hand. But there are downsides to this. The value in a mature codebase is not number of lines of code. If you've worked with one, you know that lots of code can often be more of a liability than an asset. Lots of code increases the maintenance burden, it increases the complexity burden, it makes hunting down bugs harder. Lots of code signals not just complexity but poorly managed complexity. So really, in most codebases the opportunity cost of writing code was already incredibly high.
The other downside is that programming, especially in a high level language (i.e. not assembly), is not usually this discrete process of ideate -> plan -> write -> test -> review or whatever. Programming is a continuous interaction in which the computer is providing feedback in real time. This is why reducing build time is so powerful because it lets you get feedback faster. This is why IDEs are a good idea because it lets you get feedback faster. Certainly there are people and disciplines where you write out a detailed specification and implement it. But I think most programming is more fluid where as you write you then see where the inefficiencies and clunkiness is and you can adjust in real time. It becomes obvious if your design was bad or based on inappropriate assumptions because when you go to implement it you will feel the wrongness of it. And using agents robs you of this process.
Think of the difference between using an agent and writing code by hand like the difference between recording a live guitar or programming a track with MIDI. You can perfectly make a MIDI track that sounds just like a live guitar, you can program micro-timing adjustments, bends, and expressions. Or you can actually play a guitar. This requires building from a big vat of experience that not everyone has. But you get to feel the guitar vibrate in your hand and become part of this tight feedback loop of you and the instrument. I'm not saying one is better than the other. I'm just saying they produce different kinds of music even though they could in theory produce the same music.
The counterargument is now the AI agent is doing this process. Agents have an internal monologue where they write, test, update, test, etc. They also make difficult search or refactor jobs easier. But AI agents can't viscerally feel something is wrong or inappropriate because they can't have the lived experience of maintaining code. They can't feel the cost of having to add functionality into something that was designed and implemented poorly so it takes forever. What they can do is copy really well. And maybe they are so good at copying they will copy all the right patterns.
But in the meantime, because these tools cannot microadjust and become part of a very tight feedback loop right now it poses a problem. These tools push the evaluation of code further down in time where the cost is greater. To reiterate, the maintenance and refactoring of code was already what a lot of us are spending a lot of our time on in the first place. And pushing that work down the line makes the most expensive part of software engineering even more expensive.
This article misses the point. It assumes that the way business is currently done will be the way business is always done, but the LLM revolution aims to replace businesses that have these types of constraints sure initially it will work with them, but soon enough scrappy codebases will come out that hold their own and stand the test of time with LLMs at the helm
Scrappy codebases is a very kind way to put it.