Always reminds me of this meme.

Some day we won't even need coders any more. We'll be able to just write the specification and the program will write itself.

Oh wow, you're right! We'll be able to write a comprehensive and precise spec and bam, we won't need programmers any more!

Exactly!

And do you know the industry term for a project specification that is comprehensive and precise enough to generate a program?

Code It's called code.

▲

_davidwarner a day ago | parent | next [-]

I think both can be true: as coding languages go from lower to higher level, they go from being more implementation-like (e.g. assembly, C) to being more spec-like (e.g. Rust, Haskell). It then follows that writing a good spec could be considered coding if your compiler (or agent) can reliably turn that spec into your desired output.

So the main challenge I see with this approach is getting the spec right. Too little detail and the output is uncontrolled, too much detail and you're adding too many constraints (and you may be better off just writing code). From my experience, agents haven't been the best at writing good specs. But maybe this project can help with that?

	▲	memjay 39 minutes ago \| parent [-]
		Yes. That’s the problem I noticed with specs too. Agents aren’t really good at finding the right abstraction layer. They tend to write way too detailed specs (e.g. naming variables in specs) and when controlling for less details the output degrades. But I worry the most about who will be able to define all of those specs (with all of their necessary detail and edge cases etc.) without understanding the systems that live below the specs. Maybe that won’t be a problem anymore if agents will be able to 100% accurately translate specs into code. But for now I imagine this to be really difficult.

▲

hleichsenring a day ago | parent | prev | next [-]

Two things about that. On the one hand, I couldn't believe coding would be replaced when I started Agent Smith in January 2026. On the other hand, I wanted proof.

After 500k lines of code in Agent Smith, none of which I wrote by hand, I have to admit it: coding is more or less solved. That doesn't mean architects, developers, DevOps people and everyone else aren't needed anymore. I think they're needed more than ever.

Just implementing something isn't good enough. The spec has to point to sensible approaches and procedures, and the code has to be well structured (in my view, at least). Then the specs can simply run in parallel all night.

So my actual work on Agent Smith isn't coding at all. It's deciding what the right thing to build is, and how, in terms of design and architecture. I don't even review the code. But I do test it: 10k tests, a harness, a commit hook that blocks a spec while the suite is red, the whole story.

And unfortunately, that works pretty well. I also think last year's programming was more romantic :-D

	▲	memjay 31 minutes ago \| parent \| next [-]
		I agree that “coding” in the sense of hand-writing code is solved. But code was made to create architecture, to design systems and also to make actual code (machine code) readable for humans. In my experience with spec-driven development, the lossy layer of specs on top of code is not the right way to drive development of systems and architecture. The English language is not precise enough to describe those systems. Of course you can use specs or just prompts to drive the creation of code (I do that for 99% of my code) but the “truth” is still the actual code and not the prompts/specs. Maybe that’s also just a difference between people (like visual learners vs non-visual etc.) and some have an easier time to grasp every detail of the systems they are working on through code and some through descriptions. Guess it also depends on the complexity of the software you are developing. For private projects I had more success with spec-driven while at work it would be a terrible choice.
	▲	geraneum a day ago \| parent \| prev [-]
		> And unfortunately, that works pretty well. Why unfortunately?

▲

Paracompact a day ago | parent | prev | next [-]

Very confidently wrong.

Do you know why it's easier to specify theorems than it is their proofs? Or why ACSL != C?

You can go ahead and make a more specific argument, e.g. that mainstream UX-centric software development may not be amenable to current paradigms of formal verification, but to insinuate that a complete spec reduces to source code itself is naive.

EDIT: Possibly I have responded too acutely to the points you care less about. I agree that "in the future we won't need programmers" is questionable since good spec-writing and spec-vetting requires at least as much expertise, if not more, than ordinary coding work, and that is fair to call comprehensive spec work "code" in that it is technical and formal. But it is decisively not source code.

▲

avlman a day ago | parent | prev [-]

A couple of decades ago coding was "solved" by just writing UML diagrams. The nonsense never ends.

	▲	hleichsenring a day ago \| parent [-]
		That's a different thing. UML described structure: classes, relations, maybe some state machines. The generators turned that into skeletons, and people still wrote the actual logic by hand. Here the agent writes the logic too, and 10k tests plus a commit gate check whether it works. In my case that's about 500k lines nobody typed. You can doubt that the approach generalizes, but it's not the same promise as UML.