The gap is definitely real. But I think most of this thread is misdiagnosing why it exists. It's not that AI cannot produce production quality code, it's that the very mental model most people have of AI is leading them to use the wrong interaction model for closing that last 20% of complexity in production code bases.

The author accidentally proved it: the moment they stopped prompting and opened Figma to actually design what they wanted, Claude nailed the implementation. The bottleneck was NEVER the code generation, it was the thinking that had to happen BEFORE ever generating that code. It sounds like most of you offload the thinking to AFTER the complexity has arisen when the real pattern is frontloading the architectural thinking BEFORE a single line of code is generated.

Most of the 100-hour gap is architecture and design work that was always going to take time. AI is never going to eliminate that work if you want production grade software. But when harnessed correctly it can make you dramatically faster at the thinking itself, you just have to actually use it as a thinking partner and not just a code monkey.

▲

AstroBen 6 hours ago | parent | next [-]

I don't know how other people work, but writing the code for me has been essential in even understanding the problem space. The architecture and design work in a lot of cases is harder without going through that process.

▲

suzzer99 2 hours ago | parent | next [-]

I recently had to build a widget that lets the user pick from a list of canned reports and then preview them in an overlay before sending to the printer (or save to PDF). All I knew was that I wanted each individual report's logic and display to be in its own file, so if the system needed to grow to 100 reports, it wouldn't get any more complicated than with 6 reports.

The final solution ended up being something like: 1. Page includes new React report widget. 2. Widget imports generic overlay component and all canned reports, and lets user pick a report. 3. User picks report, widget sets that specific report component as a child of the overlay component, launches overlay. 4. Report component makes call to database with filters and business logic, passes generic set of inputs (report title, other specifics, report data) to a shared report display template.

My original plan was for the report display template to also be unique to each report file. But when the dust settled, they were so similar that it made sense to use a shared component. If a future report diverges significantly, we can just skip the shared component and create a one-off in the file.

I could have designed all this ahead of time, as I would need to do with an LLM. But it was 10x easier to just start coding it while keeping my ultimate scalability goals in mind.

▲

apitman 5 hours ago | parent | prev | next [-]

See "Programming as Theory Building": https://pages.cs.wisc.edu/~remzi/Naur.pdf

▲

phillipclapham 5 hours ago | parent | prev | next [-]

That's a good point and honestly I occasionally do the same thing. Sometimes you have to build something wrong to understand what right looks like. I think the distinction is between exploratory prototyping (building to learn/think) and expecting the prototype to BE the product. The first is thinking, the second is where the 100-hour gap bites you in the ass.

▲

seanmcdirmid 5 hours ago | parent | prev | next [-]

This. It’s also much easier to tell someone what you don’t like if what you don’t like is right in front of you than to tell them what you want without a point of reference.

▲

dijksterhuis 2 hours ago | parent | prev [-]

- version 1 -- we build what we think is needed

- version 2 -- we realise we're solving a completely different problem to what is needed

- version 3 -- we build what is actually needed

	▲	phillipclapham an hour ago \| parent [-]
		This is basically the entire argument for why the 100-hour gap exists and why that's fine. The gap isn't waste, it's the cost of understanding the problem space. AI can compress that cycle but it can't skip it. But you don't WANT to skip, it's the gate between quality and slop.

▲

Gud 4 hours ago | parent | prev | next [-]

Absolutely. You need to treat it like a real program from the very beginning.

▲

jopsen 6 hours ago | parent | prev | next [-]

Yeah, communicating what you want can be hard.

I'm doing a simple single line text editor, and designing some frame options. Which has a start end markers.

This was really hard to get the LLM to do right.. until just took a pen and paper, drew what I wanted, took a photo and gave it to the llm

▲

cyk21 2 hours ago | parent | prev | next [-]

This.

Additionally, the author seems to build an app just for the sake of building an app / learning, not to solve any real serious business problem. Another "big" claim on LLM capabilities based on a solo toy project.

	▲	phillipclapham an hour ago \| parent [-]
		I'm not making any claims about LLM capabilities. I'm making a claim about how most people USE them. The author's own experience proves the point. The moment they stopped prompting and started designing, the output quality jumped. That's not an LLM limitation, that's a workflow problem.

▲

tqwhite 5 hours ago | parent | prev [-]

YES YES YES!! I so wish that we could go back in time and never, ever have even suggested anything other that what you say here. AI doesn't do it for you. It does it with you.

You have to figure out what you want before the AI codes. The thinking BEFORE is the entire game.

Though I will also say that I use Claude for working out designs a lot. Literally hours sometimes with long periods of me thinking it through.

And I still get a ton more done and often use tech that I would never have approached before these glory days.

	▲	phillipclapham 5 hours ago \| parent [-]
		The hours of design thinking with Claude is exactly it. That's the part nobody talks about because it isn't 'sexy' and doesn't make for a good demo or tweet. But it's the secret sauce IMO.