[gste]

I think this is outdated. If you follow spec-driven development, get the model to do all the planning work upfront, review and iterate the plan, write clear markdown file documentation on the abstractions and patterns you want to follow, then you have every opportunity to tell the model how you want it to write the code. If you use Opus or Fable 5 it will then write the code better and faster than you will.

[tripleee]

you're a lot more skilled than I am if you're able to know the abstractions and patterns you want while only have a weak grasp on the actual code. For me the abstractions emerge as I understand what I'm actually working with

[therealpygon]

> while only have a weak grasp on the actual code.

How much of a grasp does one need on the UEFI code operating their computer? The drivers that operate a hard drive? The communication protocols for their monitor?

This seems to me to be the fallacy — that all code must always be understood to operate properly or to be useful. If the AI is sufficiently intelligent enough to understand the code, at some point (most) people won’t need to. Not saying that’s now, but that is likely to be where things are headed in the long horizon. That said, I don’t have a crystal ball, nor do the people claiming that won’t be the outcome, so right now it seems more like people arguing about which forks should be used while the cake is still in the oven.

[dalemhurley]

I think you can have some system design in mind upfront, but agree the bulk emerges as you code. Clean Code practices worked exactly this way in which you write and then rewrite the clean code.

[preg_match]

I agree, but this works too because AI makes prototyping more rapid. It's common to be stuck with suboptimal solutions because of time constraints. Maybe the feature isn't really what the customer wants, or maybe the code isn't actually very good. But it reaches prod anyway.

But, with AI, the cost of code has gone down more than it already has. Well, cheap things are easy to throw away. So you prototype, prototype, prototype, and close the loop as much as possible with the customer. True agile development, not big A Agile.

The problem is this requires alignment from management, and we're just not seeing it at many company. They can't grasp that things have changed, and that throwing away code is free. They don't trust engineers to close that gap, so customers and stakeholders are still waaaaaay over there and we're delivering features they don't want.

[eikenberry]

IMO "get the model to do all the planning work upfront, review and iterate the plan" is backwards. It works better if you do an initial plan yourself and then have the AI review it (and iterate as necessary). Makes you think about the design for a bit so you can have a semblance of a mental model.

[prymitive]

I have never seen a plan written by LLM that wasn’t vague and light on details, every time I need to ask for more details and every time I ask to implement it trips over some dead end in the plan, discards the plan and continues as if there was no plan to begin with. Planning feels often just narrating the request and a wish list then what a human would do - methodically build enough understanding so that you’re confident of the direction you choose. LLM plans are overhyped and overrated.

[addaon]

This just doesn't match my experience writing idiomatic C code for embedded real-time systems with ChatGPT-5.5 and -5.6. Are Opus and Fable really that different? I general I find that a fully correct implementation for some function may take an hour and be nearly one-shot, but going from there to code I'd be willing to actually commit is at least 4x the time commitment with regular back-and-forth -- so four hours of deep engagement for every one hour of one-shot. ChatGPT-5.6 Sol seems to be better that -5.5 at the one hour do-it portion, but worse at the four hour do-it-well portion.

[bluefirebrand]

I haven't done "spec driven development" in my entire career, 15+ years

Until managers give up on Agile, we'll never get time to actually write specs

[whatevaa]

Sure. But try it on a project on non-trivial size and then tell us the cost of it. LLMS are billed per token.

[written-beyond]

Depends on how long that planning/review cycle takes.

[gste]

True, but I think people are also missing the trick behind markdowns that reference each other and are used for context window management. They go in your source control, they are reusable, extendable, and composable in the same way code is. So planning is not a one-off effort. It compounds over time. If you're doing it right your plan is referencing automation techniques - testing, CI/CD, etc. This further compounds so that the agents verify their own work against the standards that you set.

To be honest, the models are getting so good that they do most of this unprompted now.

[theptip]

Agreed, all of the staff/principal engineers I work with are ~99%+ AI generated code, and increasing business value delivered as a result. This is on planet scale infra not CRUD apps. (And yes, you do need to carefully review the output and give steers/corrections. It’s still faster.)

At this point if you can’t get the agent to write good code then either I) you are in a very specific niche (like Karpathy trying to write NanoGPT) that is extremely out-of-distribution, or II) skill issue, you need to learn how to prompt better.

It’s fine to have a skill gap! Just don’t delude yourself that the tools are bad and everyone claiming they are good is wrong.

[dbingham]

> Agreed, all of the staff/principal engineers I work with are ~99%+ AI generated code, and increasing business value delivered as a result. This is on planet scale infra not CRUD apps.

This has been the pro-"write with LLMs" argument the whole time. "If you're not getting good results, you're not prompting well. FAANG are doing x% of their development with AI."

Yet all of the companies that I can think of that build on planet scale infra and have gone all in on LLM development have seen a marked drop in quality and stability since adopting LLM driven development.

So yeah, I don't buy it. When I hear that engineers are writing their with LLMs and I see quality improve or stabilize, then maybe I will start to question whether its a prompting issue.

[piker]

How is a GPT implementation “extremely out of distribution” but “planet scale infra” isn’t? That’s got me totally confused about your point that I was taking seriously.

[theptip]

Go read Karpathy on this, his telling will be more nuanced than mine for the specific example. But the whole point of NanoGPT is that it’s distilling all of his wisdom and taste into a very dense and maximally educational version that fits on a single screen. It’s simply not something that has been done before in the corpus.

Planet scale infra often requires some novel ideas at the architectural layer (the engineers can input those) and then it’s mostly in-distribution C++ / Rust / Go; most of the hyperscalers open-source their stacks, for one. But for two, a ring buffer, look-aside cache, deterministic hash, b-tree, lsm-tree, etc. are all well-known patterns.

Hyperscaling is also often a very clear objective function; i need this code path to run in this many microseconds/nanoseconds, so i can hit the scale numbers I need. Claude/Sol can extract prod logs and build a representative micro-benchmark, and then hill-climb on it autonomously. Thats straight up the fairway for the training set, even if it often has a high bar for finishing and requires sophisticated Workflows or lots of tokens to explore the search space.

E2A: sorry sorry, typo, I meant microGPT. I can see why this would be confusing.

https://karpathy.github.io/2026/02/12/microgpt/

[potatolicious]

A lot of stuff that underpins planet-scale infra is open source and has been for a long time. The general approaches and architectures for it have also been widely discussed and litigated in the commons so it's not just the code - the specific why is also very well documented.

So despite its importance much of it is actually pretty in-distribution.

[piker]

Okay, but then that does not square with calling a GPT implementation out-of-distribution, let alone "extremely" so.

[tripleee]

it's really cool how in the past measuring developer productivity was incredibly difficult, but now its become easy if someone's making a point about LLMs

[bigstrat2003]

No, the tools really are bad, and everyone claiming they are good really is wrong. Or deliberately lying.

[gamblor956]

They're both wrong and deliberately lying.

[disgruntledphd2]

LLm generation of code is an absurdly high dimensional process, and incredibly sensitive to the starting conditions and any other interactions so in some sense it's expected that there will be wildly different outcomes.

Personally, I'm more on the LLM code is pretty bad from a design point of view, particularly when much of the code is already LLM generated.

[oasisaimlessly]

btw, your last paragraph makes you sound like an ass.