I've felt like a broken record the past few weeks, but this.

Authoring has never been the bottle neck, the same way my typing speed has never been the bottle neck.

The bottle neck has been, and continues to be, code review. It was in our pitch deck 4 years ago; it's still there.

For most companies, by default, it's a process that's synchronously blocked on another human. We need to either make it async (stacking) or automate it (better, more intelligent CI), or--ideally---both.

The tools we have are outdated, and if you're a team with more than 50 eng you've already spun up a sub team (devx, dev velocity, or dev productivity) whose job is to address this. Despite that, industry wide, we've still done very little because it's a philosophically poorly understood part of the process (why do we do code review? Like seriously, in three bullet points what's the purpose - most developers realize they haven't thought that deeply here).

https://graphite.dev

My last job had a team with about 50% temp and contract. When the LLMs got popular, I could tell right away. When I reviewed their code, it was completely different than their actual style. The seniors pushed back because it was costing us more time to review and we knew it was generated. Also, they couldn't talk about about what they did in meetings. They didn't know what it was really doing. Eventually the department manager got tired of our complaining and said "it's all inevitable." Then those mercenaries started to just rubber stamp each other's PRs. The led to some colossal fuckups in production. Some of them were fired quietly, and the new people promptly started doing the same thing. Why should they care, it's just a short term contract on the way to the big payday, right?

I've always enjoyed software design, for me the coding was the bottleneck and it was frustrating as I had to roll through different approaches when I so clearly knew the outcome that I wanted.

Using Claude Code to first write specs, then break it down into cards, build glossaries, design blueprints, and finally write code, is just a perfect fit for someone like me.

I know the fundamentals of programming, but since 1978 I've written in so many languages that the syntax now gets in the way, I just want to write code that does what I want, and LLM's are beyond amazing at that.

I'm building API's and implementing things I'd never dreamed of spending time on learning, and I can focus on what I really want, design, optimisation, simplification, and outcomes.

LLM's are amazing for me.

Nobody mentioned Joel Spolsky's October 2nd, 2000 article, so I'll start: https://www.joelonsoftware.com/2000/10/02/painless-functiona...

Code is not a bottleneck. Specs are. How the software is supposed to work, down to minuscule detail. Not code, not unit tests, not integration tests. Just plain English, diagrams, user stories.

Bottleneck is designing those specs and then iterating them with end users, listening to feedback, then going back and figuring out if spec could be improved (or even should). Implementing actual improvements isn't hard once you have specs.

If specs are really good -- then any sufficiently good LLM/agent should be able to one-shot the solution, all the unit tests, and all the integration tests. If it's too large to one-shot -- product specs should never be a single markdown file. Think of it more like a wiki -- with links and references. And all you have to do is implement it feature by feature.

my LLM win this year was to give the corporate AI my last year's worth of notes, emails and documents and ask it to write my self review. it did a great job. i'm never writing another one of those stupid bits of psychological torture again

otherwise i'm writing embedded systems. fine, LLM, you hold the scope probe and figure out why that PWM is glitching

> Now, with LLMs making it easy to generate working code faster than ever, a new narrative has emerged: that writing code was the bottleneck, and we’ve finally cracked it.

This narrative is not new. Many times I've seen decisions were made on the basis "does it require writing any code or not". But I agree with the sentiment, the problem is not the code itself but the cost of ownership of this code: how it is tested, where it is deployed, how it is monitored, by whom it's maintained etc.

Writing code was never the only bottleneck, and I'm sure there is personal variation, but for me personally it has always been the dominant bottleneck.

My backspace and delete keys loom larger than the rest of my keyboard combined. Plodding through with meager fingers, I could always find fault faster than I could produce functionality. It was a constant, ego-depleting struggle to set aside encountered misgivings for the sake of maintaining forward progress on some feature or ticket.

Now, given defined goals and architectural vision, which I've never been short of, the activation energy for producing large chunks of 'good enough' code to move projects forward is almost zero. Even my own oversized backspace is no match for the torrent.

Again - personal variation - but I expect that I am easily 10x in both in ambition and in execution compared to a year ago.

I dont think the authors comments are without merit. My experience has shown me issues are usually more upfront and after the fact.

Either the bottleneck between product organizations and engineering on getting decent requirements to know what to build and engineering teams being unwilling to start until they have every I dotted and T crossed.

The backend of the problem is that already most of the code e see written is poorly documented across the spectrum. How many commit messages have we seen of "wip" for instance? Or you go to a repository and the Readme is empty?

So the real danger is the stack overflow effect on steroids. It's not just a block of code that was put in that wasn't understood, its now entire projects, and there's little to no documentation to explain what was done or why decisions were made.

Lots of devs complaining about code quality and understandability here.

I'm going to skip the obvious answer about how LLMs can actually improve code quality and reviewability and focus on a different argument: why engineers even care about code quality.

Most code is not written as a work of art but as an important functional piece to achieve return on capital. Programmers get paid by companies to produce code. The payment ultimately is driven by expectation of a return on investment of the code. Ultimately business owners and owners do not really care about code quality as long as it can deliver on return on capital. There are plenty of profitable businesses run on spaghetti code and old technology. However, engineers realized that bad code resulted in costly downstream consequences including consequences that affected ROI. Tech debt had to be paid not just in developer hours but also dollars and cents. Thus this obsession with code quality, code reviews, and this current debate.

Many including Andrew Ng at YC startup school recently are realizing that writing bad code is now a two way door instead of the one way door that it used to be. With LLMs you can deploy some bad code, realize it's bad, and rewrite that entire codebase tomorrow with near negligible cost. The fact that LLM can write some very very bad code is less important than the return on invested capital of that code especially when taking into account the speed at which that code can be fixed / completely re-written in the future, and especially when that in that future, LLMs will be even more capable than it is now.

Here's my advice: give in the shitty code and merge it. Claude 6 will refactor all of it to your liking very soon.

> The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. All of this wrapped inside the labyrinth of tickets, planning meetings, and agile rituals.

Most of these only exist because one person cannot code fast enough to produce all the code. If one programmer was fast enough, you would not need a team and then you wouldn't have coordination and communication overhead and so on.