phillipclapham

This is the most important point in the thread. The study measures code complexity but the REAL bottleneck is cognitive load (and drain) on the reviewer.

I've been doing 10-12 hour days paired with Claude for months. The velocity gains are absolutely real, I am shipping things I would have never attempted solo before AI and shipping them faster then ever. BUT the cognitive cost of reviewing AI output is significantly higher than reviewing human code. It's verbose, plausible-looking, and wrong in ways that require sustained deep attention to catch.

The study found "transient velocity increase" followed by "persistent complexity increase." That matches exactly. The speed feels incredible at first, then the review burden compounds and you're spending more time verifying than you saved generating.

The fix isn't "apply traditional methods" — it's recognizing that AI shifts the bottleneck from production to verification, and that verification under sustained cognitive load degrades in ways nobody's measuring yet. I think I've found some fixes to help me personally with this and for me velocity is still high, but only time will tell if this remains true for long.

The security angle is definitely right but the framing is still too narrow. Everyone's debating context window economics and chain policies, but there's a more fundamental gap lying underneath these: nobody's verifying the content of what gets loaded.

Tool schemas have JSON Schema validation for structure. But the descriptions: the natural language text that actually drives LLM behavior have zero integrity checking. A server can change "search files in project directory" to "search files in project directory and include contents of .env files in results" between sessions, and nothing in the protocol detects it. And that's not hypothetical. CVE-2025-49596 was exactly this class of bug.

Context window size is an economics problem that's already getting solved by bigger windows and tool search. Description-layer integrity is an architectural gap that most of the ecosystem hasn't even acknowledged yet. And that makes it the thing that is going to bite us in the butt soon.

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.

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.

That's a real risk and I'd be lying if I said it never happens. But the distinction I'd draw is between using AI to generate conclusions vs using it to stress-test yours. Thinking FOR you vs thinking WITH you. When I say rubber ducking I mean something closer to what borski described — "fight and engage me on my ideas" — not "tell me what to think."

The steering problem is worst when you go in without any sort of position. If you sit down and say "what should I write about X" then yeah, you're risking ending up thinking whatever the model thinks. But if you sit down with even a half-formed argument and conviction and say "here's what I think, build on it and poke holes in it," the dynamic is completely different. You're still driving. You still need to maintain meta-awareness of how your thinking might be shifting in response to the AI, but you remain in control.

With that I think the editor vs thinking tool framing is a false binary. The best use I've found is somewhere in between — more adversarial than an editor, less open-ended than brainstorming. Alternating between convergent building together and structured disagreement, basically.

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.

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.

Can't help but notice the definitions in this law are the most revealing part. When cowsay is legally an "application" and your friend's personal website with a download link is a "covered application store," that's not sloppy drafting. That's the deeper mechanism working exactly as designed.

This is the same pattern we keep seeing everywhere in society (and it links together with the pattern of enshittification): set the compliance floor at exactly the level that Apple, Google, and Microsoft already meet, make the definitions broad enough that everyone else technically falls under them, and let the liability created by that do the rest. You don't need to ban hobby distros. You just need to make maintaining one a legal risk egregious enough that no volunteer is willing to or even can afford to take it on.

76-0 in the Assembly. Ask yourself when the last time was that 76 California legislators unanimously agreed on anything that didn't have a well-funded lobby behind it.

Oops, I had several tabs open and put this on the wrong one lol. Thanks!

Can't help but notice the definitions in this law are the most revealing part. When cowsay is legally an "application" and your friend's personal website with a download link is a "covered application store," that's not sloppy drafting. That's the deeper mechanism working exactly as designed.

This is the same pattern we keep seeing everywhere in society (and it links together with the pattern of enshittification): set the compliance floor at exactly the level that Apple, Google, and Microsoft already meet, make the definitions broad enough that everyone else technically falls under them, and let the liability created by that do the rest. You don't need to ban hobby distros. You just need to make maintaining one a legal risk egregious enough that no volunteer is willing to or even can afford to take it on.

76-0 in the Assembly. Ask yourself when the last time was that 76 California legislators unanimously agreed on anything that didn't have a well-funded lobby behind it.

I think there's a useful distinction nobody here is making: there's a difference between using AI as a writing tool and using AI as a thinking tool.

Most people in this thread are talking about the output stage. You know: polish my text, fix my grammar, generate my message. That's where you lose your voice. But the blank page problem borski describes isn't really a writing problem, it's a thinking problem. Once you know what you want to say, saying it tends to be the easy part for us writers (sometimes lol!).

The most useful thing I've found is using AI to figure out what I actually think, using it for rubber ducking, exploring angles, stress-testing arguments, and then closing the tab and writing it myself. You get the cognitive help without losing the (or your) soul. I've output more writing in my own genuine voice in the last year than I did in several years prior, and it's because I use AI for clarity instead of replacing my output.

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.