“Coding” is an ambiguous term for many tasks and responsibilities. There is no agreed upon boundary at which point it will be “solved”. Consider these three cliches making the rounds now:
- Coding is largely solved? (ambiguous point of contention)
- Verification is not solved. (consensus)
- Maintainability is not solved. (consensus)
I have practical needs and I don’t see them getting met by arguing the semantics of point 1 while we’re suffering from 2 and 3. On a level playing field we might be able to negotiate “coding is solved” into a meaningful conversation, but the funding doesn’t want that, it wants a Superintelligence.
But it’s a little different. Rigorous thinking was required to produce anything at the previous layers. This one is different. One can now produce copious amounts of slop without thinking at all.
In that way, I’d argue, slop coding is solved.
It’s vaguely the same, though. We are abstracting technical language via natural language, but the details still have to be provided in some way. Leaving it to the AI to infer only works for very tiny things where ambiguity is low. For big things you have this ocean of slop because the AI still needs every detail specified else it will make shit decisions based on shit inferences.
I think a dev harness such as the one my company is trying to create is nothing more than trying to get the AI to make zero decisions and ask about even the slightest ambiguity — as it should.
So you wind up with an excruciatingly long detailed natural language spec that consumes boatloads of tokens and is impossible for a human to read through only to produce the exact same thing translated into code.
From that perspective, it’s just an abstraction layer. A very sloppy one.
I agree. I recently chatted with an ex-dev manager who tasked two of his devs with coding a new feature entirely through AI. They succeeded, but lamented that they had pages and pages of prompt to get it right. “You guys have rediscovered the concept of a ‘design doc’,” he told them.