My most recent example of this is mentoring young, ambitious, but inexperienced interns.

Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before:

- During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "good catch, I'll fix that" (also reminiscent of an LLM).

- The time spent on trivial issues went down a lot, almost zero, the remaining issues were much more subtle and time-consuming to find and describe.

- Many bugs were of a new kind (to me), the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be. This breakdown of pattern-matching compared to "organic" code made the overhead much higher. Spending decades reviewing code and answering Stack Overflow questions often makes it possible to pinpoint not just a bug but how the author got there in the first place and how to help them avoid similar things in the future.

- A simple, but bad (inefficient, wrong, illegal, ugly, ...) solution is a nice thing to discuss, but the LLM-assisted junior dev often cooks up something much more complex, which can be bad in many ways at once. The culture of slowly growing a PR from a little bit broken, thinking about design and other considerations, until its high quality and ready for a final review doesn't work the same way.

- Instead of fixing the things in the original PR, I'd often get a completely different approach as the response to my first review. Again, often broken in new and subtle ways.

This lead to a kind of effort inversion, where senior devs spent much more time on these PRs than the junior authors themselves. The junior dev would feel (I assume) much more productive and competent, but the response to their work would eventually lack most of the usual enthusiasm or encouragement from senior devs.

How do people work with these issues? One thing that worked well for me initially was to always require a lot of (passing) tests but eventually these tests would suffer from many of the same problems

Even without LLMs, we were approaching a point of saturation where software development was bottlenecked by market demand and funding, not by a shortage of code. Our tooling has become so powerful that the pure act of programming is secondary.

It's a world away from when the industry began. There's a great story from Bill Gates about a time when his ability to simply write code was an incredibly scarce resource. A company was so desperate for programmers that they hired him and Paul Allen as teenagers:

  "So, they were paying penalties... they said, 'We don’t care [that they are kids].' You know, so I go down there. You know, I’m like 16, but I look about 13. They hire us. They pay us. It’s a really amazing project... they got a kick out of how quickly I could write code."

Source: https://youtu.be/H1PgccykclM?si=YuIFsUcWc6sHRkAg

Wow a lot of the stories people are writing here are super depressing. If a junior developer is delivering you a pile of code that doesn’t work, hasn’t been manually tested and verified by them, hasn’t been carefully pared down to its essential parts, and doesn’t communicate anything about itself either through code style, comments or docs … then you are already working with an LLM ; it just so happens to be hosted in - or parsed thru - a wetware interface. Critical thinking and taking responsibility for the outcome is the real job and always has been.

And, cynically, I bet a software LLM will be more responsive to your feedback than the over-educated and overpaid junior “engineer” will be. Actually I take it back, I don’t think this take is cynical at all.

In a professional setting, I agree 100%, no notes. Where LLMs have helped me the most are actually side projects. There, writing the code is absolutely the bottleneck - I literally can't (or perhaps won't is more truthful) allocate enough time to write code for the little apps I've thought of to solve some small problem.

That is true in some cases. However, there are many cases where writing the code IS the bottleneck. Experiments, trying different approaches, well defined code.

Examples:

This morning Claude Code built a browser-based app that visualizes 3.8M lines of JSON dumps of AWS infrastructure. Attention required by me: 15 minutes. Results: Reasonable for a 1-shot.

A few weeks ago I had it build me a client/server app in multiple flavors from a well defined spec: async, threaded, and select, to see which one was the most clear and easy to maintain.

A few days ago I gave it a 2K line python CLI tool and said "Build me a web interface to this CLI program". It nearly one-shotted it (probably would have if I had the playwright MCP configured).

These are all things I never would have been able to pursue without the LLM tooling in the past because I just don't have time to write the code.

There are definitely cases where the code is not the bottleneck, but those aren't the only cases.

I used to think authoring code was the bottleneck. It took a solid decade to learn that alignment of the technology to the business is the actual hard part. Even in the extreme case like a B2B/SaaS product wherein every customer has a big custom code pile. If you have the technology well aligned with the business needs, things can go very well.

We have the technology to make the technology not suck. The real challenge is putting that developer ego into a box and digging into what drives the product's value from the customer's perspective. Yes - we know you can make the fancy javascript interaction work. But, does the customer give a single shit? Will they pay more money for this? Do we even need a web interface? Allowing developers to create cat toys to entertain themselves with is one realistic way to approach the daily cloud spend figures of Figma.

The biggest tragedy to me was learning that even an aggressive incentive model does not solve this problem. Throwing equity and gigantic salaries into the mix only seems to further complicate things. Doing software well requires at least one person who just wants to do it right regardless of specific compensation. Someone who is willing to be on all of the sales & support calls and otherwise make themselves a servant to the customer base.

This reminds me of the quote by Robert C. Martin[1]: "the ratio of time spent reading [code] versus writing is well over 10 to 1".

If programmers spend 90%+ of their time reading code rather than writing it, then LLM-generated code is optimizing only a small amount of the total work of programming. That seems to be similar to the point this blog is making.

[1] https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...

Right, we all know this. LLMs write a lot of bad code that cannot be realistically reviewed.

I've even had code submitted to me by juniors which didn't make any sense. When I ask them why they did that, they say they don't know, the LLM did it.

What this new trend is doing is generating a lot of noise and overhead on maintenance. The only way forward, if embracing LLMs, is to use LLMs also for the reviewing and maintenance, which obviously will lead to messy spaghetti, but you now have the tools to manage that.

But the important realization is that for most businesses, quality doesn't really matter. Throwaway LLM code is good enough, and when it isn't you can just add more LLM on top until it does what you think you need.

I used to think I needed to type faster.

As I get older I spend more of my coding time on walks, at the whiteboard, reading research, and running experiments

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

I will disagree with the author.

If you look from the lenses of BigTech and corporations, yes code was not a bottleneck.

But, if you look from the perspective of startups, rigorous planning was because resources to produce features were limited, which means producing a working code was a bottleneck, because in small teams you don't have coordination overhead, idea and vision is clear for them -> to produce something they have discussed and agreed on already.

My takeaway is, when discussing broad topics like usefulness of AI/LLM, don't generalize your assumptions. Code was bottleneck for some, not for others

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.

> 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.

In addition to the poor code we spend time on, we get to lose even more time endlessly talking about it and working on ways around the issues. I swear I have spent as much time tinkering with these models and the tooling as it took for me to bring my first skills up to a level to get hired. For people who are asking me if "ChatGPT can build a web app," they're really asking if they can build this thing without learning anything. I have bad news for them...

> The marginal cost of adding new software is approaching zero, especially with LLMs. But what is the price of understanding, testing, and trusting that code? Higher than ever.

I’m not sure about that: the code LLMs generate isn’t categorically worse than that written by people who no longer work here and that I can’t ask anything to either. It’s also not much better or worse than what you’d find online but has a more broad reach than my Google-fu, alongside some hallucinations. At the same time, AI doesn’t hate writing tests because it doesn’t get a choice. It doesn’t get breaks and doesn’t half ass things any more or less depending on how close to 5 PM it is.

Maybe my starting point is viewing all code as a liability and not trusting anything anyone (myself included) has written all that much, so the point doesn’t resonate with me that much. That said I have used AI to push out codebases that work, albeit that did take a testable domain and a lot of iteration.

It produces results but also rots my brain somewhat because the actual part of writing code becomes less of a mentally stimulating activity compared to requirements engineering.

_about 2 years back. I pushed back hard with a similar argument but I have since come around._

I think the premise is true that writing code was never the "main" bottleneck but like any power tool, when wielded by the right person, it can blow past bottlenecks.

many of these arguments,only assume the case of an inexperienced engineer blindly pumping out and merging code. I concede the problems in this case.

but put this to test with more experienced engineers. how has/does it change their workflows? the results (I've personally observed) are exponentially different.

---

> LLMs reduce the time it takes to produce code, but they haven’t changed the amount of effort required to reason about behavior, identify subtle bugs, or ensure long-term maintainability.

I have to strongly disagree here. this argument doesn't apply universally. I've actually found LLMs to make it easier to understand large swaths of code, faster. especially in larger codebases that have legacy code that no one has worked on or dared to touch. LLMs bring an element of fearlessness, which makes it easier to effect change.

Whether or not there was a claim that code _was_ the bottleneck, this raises some points that I've been talking over with people for a while now.

Introducing a lever to suddenly produce more code faster creates an imbalance in the SDLC. If our review process was already a bottleneck, now that problem is even worse! If the review bottleneck was something we could tolerate/ignore before, that's no longer the case, we need to solve for it. No, that doesn't mean let some LLM review the code and ship it. CI/CD needs to get better and smarter. As a reviewer, I don't want to be on the lookout for obscure edge cases. I want to make sure my peer solved the problem in a way that makes sense for our team. CI/CD should take care of making sure the code style aligns with our policies, that new/updated tests provide enough coverage for the new/changed functionality, and that the feature actually works.

The code expertise / shared context is another tough problem that needs solving, only highlighted by introducing a random graph of numbers generating the code. Leaning on that one engineer who has been on the team for 30 years and knows where all the deep dark secrets are was not a sustainable path even before coding agents. Having a markdown file that just says "component foo is under /foo. Run make foo to test it" was not documentation. The imbalance in the SDLC will light the fire under our collective asses to provide proper developer documentation and tooling for our codebases. I don't know what that looks like yet. Some teams are trying to have *good* markdown files that actually document where all the deep dark secrets are. These are doubly beneficial because coding agents can use those as well as your humans. But better markdown is probably a small step towards the real fix which we wont be able to live without in the near future.

Anyway, great points brought up in the article. Coding agents aren't going away, so we need to solve this imbalance in the SDLC. Fight fire with fire!

Writing software is like a combination of writing a short story, cleaning your room, and planning a vacation. The bottleneck is always low confidence, much like work anywhere else.

I have watched for almost 20 years employers try to solve and cheat their way around this low confidence. The result is always the same: some shitty form of pattern copy/paste, missing originality, and delivery timelines for really basic features. The reasons for this is that nobody wants to invest in training/baselines and great fear that if they do have something perceived as talent that its irreplaceable and can leave.

My current job in enterprise API management is the first time where the bottleneck is different. Clearly the bottleneck is the customer’s low confidence, as opposed to the developers, and manifests as a very slow requirements gathering process.

Yes but no.

It’s decisions.

Ninety five percent is all the decisions made from every person involved.

The fastest delivery I ever encountered were situations where the stakeholders were intimately familiar with the problem and made quick decisions. Only then did speed of coding affect delivery.

In large organizations, PMs are rarely POs. Every decision needs to be run up the flagpole and through committee with CYAs and delays at every step.

Decision makers are outsourcing this to LLMs now which is scary as they are supposed to be the SME.

It’s the same old same old where the generals make decisions but the sergeants (NCOs) really run the army. That’s where I feel leads/principles/staff really make out break the product. They are the fulcrum dealing with LLM from above and below.

For me, writing CSS and coming up with professional looking designs were huge bottlenecks. Now I delegate those tasks to LLMs.

I recently started working on a client's project where we were planning on hiring a designer to build the front-end UI. Turns out, Gemini can generate really good UIs. Now we're saving a lot of time because I don't have to wait on the designer to provide designs before I can start building. The cost savings are most welcome as well.

Coding is definitely a bottleneck because my client still needs my help to write code. In the future, non-programmers should be able to build products on their own.

> 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.

I can relate :-)

Our team maintains a configuration management database for a company that has grown mostly organically from 3 to 500+ employees in ~30 years.

We don't have documented processes that would account for most of the write operations, so if we have a question, we cannot just talk to the process owner.

The next option would be to talk to the data owner, but for many of our entities, we don't have a data owner. So we look into the audit logs to see which teams often touch the data, and then we do a meeting with some senior folks from each of these teams to discuss things.

But of course, finding common meeting time slots with several senior people from several teams isn't easy, they're all busy. So that alone might delay something by a few weeks to months.

For low-stakes decisions, we often try to not go through this effort, but instead do things that are easy to roll back if they go wrong.

Once we have identified the stakeholders, have a common understanding among them, and a rough consensus on how to proceed, the actual code changes are often relatively simple in comparison.

So, I guess this falls under "overhead of coordination and communication".

It's always nice to look at history to parallels to modern conversations, and I think it's instructive to look back at the era when software jobs were getting outsourced to overseas. Even though the cost of generating code was cheaper, and the people on the other end can participate in meetings and all that, software is still primarily done in person. Even today, several years after the pandemic and the height of remote work, many tech companies are mandating in-office policies even for software workers.

The point is that there's a human element to code that we can't even capture when working remotely with intelligent humans. LLMs will always be like a remote worker.

The difference between AI as autocomplete and vibe coding couldn't be bigger. It's like the difference between having your phone with you on a trip somewhere to take pictures with, and just watching a video of the place on your phone at home.

Autocomplete speeds up code generation by an order of magnitude, easily, with no real downside when used by experienced devs. Vibe coding on the other hand completely replaces the programmer and causes lots of new issues.

> LLMs reduce the time it takes to produce code, but they haven’t changed the amount of effort required to reason about behavior, identify subtle bugs, or ensure long-term maintainability.

I'd argue that they're slowly changing that as well -- you can ask an LLM to "read" code, summarize / review / criticize it. At the least, it can help accelerate onboarding onto new / unfamiliar codebases.

I agree with most of this. Writing code is one of the easy bits of Software Development. Writing the specifications about what to write is hard.

Once you can specify what to create, and do it well, then actually creating it is quite cheap.

However, as a software developer that often feel I'm pulled into 10 hours of meetings to argue the benefits of one 2-hour thing over the other 2-hour thing, my view is often "Lets do both and see which one comes out best". The view of less technical participants in meetings is always that development is expensive, so we must at all cost avoid developing the wrong thing.

AI can really take hat equation to the extreme. You can make ten different crappy and non-working proof-of-concept things very cheaply. Then throw them out and manually write (or adapt) the final solution just like you always did. But the hard part wasn't writing the code, it was that meeting where it was decided how it should work. But just like discussing a visual design is helped by having sketches, I think "more code" isn't necessarily bad. AI's produce sub par code very quickly. And there are good uses for that: it's a sketch tool for code.

I used Sonnet4 to write my last frontend task, fully, with minimal input. It is so much better than ChatGPT it's unbelievable, but while a 6hour coding task was transformed into a 30 minutes supervision task that generated good, but also correct code, I was a bit afraid for new engineers coming into an old project.

How are you supposed to understand code if you don't at least read it and fail a bit?

I'll continue using Sonnet4 for frontend personally, it always had been a pain point in the team and I ended up being the most knowledgeable on it. Unless it's a new code architecture, I will understand what was changed and why, so I have confidence I can handle rapid iteration of code on it, but my coworkers who already struggled with our design will probably have even more struggles.

Sadly I think in the end our code will be worse, but we are a team of 5 doing the work of a team of 8, so any help is welcome (we used to do the work of 15 but our 10x developper sadly (for us) got caught being his excellent self by the CTO and now handle a new project. Hopefully with executive-level pay)

I work on business software.

I think one very important aspect is requirements collection and definition. This includes communicating with the business users, trying to understand their issues and needs that the software is supposed to address. And validating if the actual software is actually solving it or not (sufficiently).

All of this requires human domain knowledge, communication and coordination skills.

I predict that using LLMs is going to be a firing offense.

There will be a 100 justifications for and against it, but in the end you are going to need junior devs.

If said junior dev has not done the work, and an LLM has helped them, you are going to lose your hair walking through the code - every single time.

So you will choose between doing the work yourself, hiring new devs, or making the environment you do your work in become predictable.

We can argue that LLMs are massive piracy monstrosities, with huge amounts of public code in them, or that they are interfering with the ability of people to learn the culture of the company. The argument doesn't matter, because the reasoning being done here is motivated reasoning.

You will not care how LLMs are kept out of the playing pen, you just care that they are out.

So incentives will be structured to ensure that is the case.

What will really be game set and match, will be when some massive disaster strikes because of bad code, and it can either directly or tangentially be linked to LLMs.

I have not found LLMs to be most beneficial in straight writing code especially in complex large scale systems. However, I have found them extremely useful at the aspects the author claims they make more difficult: understanding, testing, and trusting that code.

An LLM is an extremely useful search engine. Given access to plenty of CLI tools asking it questions about an unfamiliar code base is extremely helpful. It can read and summarize much faster than I can. I don't trust its exact understanding but I do trust it to give me a high level understanding of an architecture, call out dependencies, summarize APIs, and give me an idea of what parts of the code base are new/old etc.

Additionally, having LLMs write tests after setting up the rough testing structure and giving it a few examples massively decreases the amount of time it takes to prove my understanding of the code through the tests thereby increasing my confidence/trust in it.

This shouldn't be surprising to anyone in software development. Regardless of how essential your software is, you can just shit out any stupid-ass thing that vaguely works and you've finished your ticket.

Who thought lazy devs were the bottleneck? The industry needs 8x as much regulation as it has now; they can do whatever they want at the moment lol.

I completely agree with the author. I am only really more productive with LLM's when I have to use an API or tool I am not familiar with. Jasper Reports being the latest example. When it comes to what I do most, LLM's doesn't help much.

I think most of the supposed bottlenecks are mostly a consequence of attempting to increase development speed by throwing additional developers at the problem. They're trivially problems that don't exist for a solo dev, and there's a strong argument that a small team won't suffer much from them either.

If you can use tools to increase individual developer productivity (let's say all else being equal, code outputs 2x as fast) in a way where you can cut the team size in half, you'll likely a significant productivity benefit since your communication overhead has gone down in the process.

This is of course assuming a frictionless ideal gas at STP where the tool you're looking at is a straight force multiplier.

A bit more interesting is slightly inverse to this. What will win in the next 10 years?

IMO expectations are now so high from users that you need to create websites, apps, auth, payment integration, customer supoort forums and chats. And this is to break the ice and have a good footing for the business to move forward. You could see how this is a problem for a non technical person. Nobody will hire someone to do all that as it will be prohibitively expensive. AI is not for the engineers, it is a “good enough” for folks that do not understand the code.

A lot depends on where the money will be invested, and what will consumers like as well. I bet the current wave of ai coding will morph into other spheres to try and improve efficiency.

When I learned coding it took a lot of effort just to get something to work at all, it took many years until I could take an idea and write code that works right away after the spelling errors have been fixed. Now I have colleges that have no idea what they're doing but AI gives them code that works... Meanwhile the coding standards, languages and frameworks changes faster then I have time to keep up. I always liked code that was simple, easy to understand, and easy to change, remove and rewrite. Writing and working with such code is very satisfying. But noone cares about code anyway. It's more of an brutalist abstract artform that very few people appreciate.

1. Define the problem you are trying to solve.

2. Propose a solution to the problem and get feedback.

3. Design the data model(s) and get feedback.

4. Design the system architecture and get feedback.

5. Design the software architecture and get feedback.

6. Write some code and get feedback.

7. Test the code.

8. Let people use the code.

Writing the code is only one step.

In all honesty, I expect over time intelligent agents will be used for the other steps.

But the code is based on the proposed solution, which is based on the problem statement/requirements. The usefulness of the code will only be as good as the solution, which will only be as good as the problem statement/requirements.

I saw one tech company say they’re going to measure the impact of AI tools by counting merged pull requests per engineer. Seems like I great recipe for AI bullshit churn counting as positive impact.

Was anyone claiming it is the bottleneck? Seems like a straw man.

All of these are the exact reasons I don't go overboard with a custom Vim or Helix setup with all sorts of bells and whistles, and just use stock Sublime. The real problem is never the speed at which I can write code. I need to model a complex problem domain. My choice of language and tools virtually eliminate all boilerplate and focus the effort on those modeling and software design problems. I've tried LLMs multiple times, and each time they've proven they cannot help me.

I think that the writer has it completely wrong. A lot of the "overhead" they describe came about precisely because software development was so precious and expensive. That will change now and LLMs can speed up the validation.

Finally LLMs makes code reading and understanding much easier and faster which is the exact opposite of what the writer claims.

It isn't going to be a work free utopia, but the write has the wrong framing of the situation.

Code is always the bottleneck because people aren’t always thoughtful about how they design it.

Coordination, communication, etc… honestly not that big of a deal if you have the right people. If you are working with the wrong people coordination and communication will never be great no matter what “coordination tools you bring in”. If you have a good team, we can be sending messenger pigeons for all o care and things will still work out.

Just my opinions.

I think the bottleneck can be summarized as verification and understanding. While that was the bottleneck before as well now it makes even more sense to find comprehensive ways to work with that. If you can quickly verify that the code is doing the right thing and that it is understandable, then you might achieve productivity increase.

And there's no good reason why LLM's can't at least partially help with that.

I woke up saying “no” into my pillow over and over again this morning about this problem.

There are two ways forward:

- Those of us that have been vibing revert to having LLMs generate code in small bits that our brains are fast enough to analyze and process, but LLMs are increasingly optimized to create code that is better and better, making it seem like this is a poor use of time, since “LLMs will just rewrite it in a few months.”

- We just have a hell of a time, in a bad way, some of us losing our jobs, because the code looks well-thought out but wasn’t, at ever increasing scale.

I have wavered over the past months in my attitude after having used it to much success in some cases and having gotten in over my head in beautiful crap in the more important ones.

I have (too) many years of experience, and have existed on a combination of good enough, clear enough code with consideration for the future along with a decent level of understanding, trust in people, and distrust in scenarios.

But this situation is flogging what remains of me. Developers are being mentored by something that cannot mentor and yet it does, and there is no need for me, not in a way that matters to them.

I believe that I’ll be fired, and when I am, I may take one or both of two roads:

1. I’ll continue to use LLMs on my own hoping that something will be created that feeds my family and pays the bills, eventually taking another job where I get fired again, because my mind isn’t what it was.

2. I do one of the few manual labor jobs that require no reasoning and are accepting of a slow and unreliable neurodivergent, if there are any; I don’t think there truly are.

I’ve been close to #2 before. I learned that almost everything that is dear to you relies on your functioning a certain way. I believe that I can depend on God to be there for me, but beyond that, I know that it’s on me. I’m responsible for what I can do.

LLMs and those AIs that come after them to do the same- they can’t fill the hole in others’ lives the way that you can, even if you’re a piece of shit like I am.

So, maybe LLMs write puzzling code as they puzzle out our inane desires and needs. Maybe we lose our jobs. Maybe we hobble along slowly creating decent code. It doesn’t matter. What matters is that you be you and be your best, and support others.

I disagree. Writing code was a bottle neck in software engineering. Code review is for code that doesnt hold the standards. Debuging is for code not written well. Integration is needed when you dont take to acoount the properties of the different parts

Specifications are the only missing part. And that is done through the question to the llm.

The problem is managing complexity.

That's the only simplification that makes sense and accounts for the different phenomena we see (solo developers doing amazing things exist, teams doing amazing things exist, amazing teachers exist, etc).

There are many ways of doing it. If you understand the problem, and see a big ball of unecessary complexity rising, you get upset.

This resonates a little, it's problems that you need to consider... When I quit smoking I noticed my code quality dropped. It wasn't because I missed the cigarettes, it was the mental break with a solid social excuse I was missing. I started taking smoke breaks, without the smoke and things returned to normal.

The difference between a hobbyist who codes and a professional is all of the things listed in this article.

As someone who shamefully falls more in the hobbyist camp, even when they code in the workplace, and has always wanted to cross what I perceived as a chasm, I’m curious, where did most people who code for a living learn these skills?

Has anybody previously had Gantt chart paths "non-code-1 -> code-1 -> non-code-2 =-> code-2" and transformed them into coding tasks, and taking advantage of the newfound coding speed? What did you do? I would need buy-in from people.

TBH, I feel like the biggest help Cursor gives me is with understanding large-ish legacy codebases. It's an excellent (& active) "rubber duck". So I'm not sure the argument holds - LLMs don't just write code.

Agreed. Tribal knowledge and communication is the biggest bottleneck. As soon as your team starts growing, you spend most of your time in communication and not writing code.

This is what I’m working on fixing at wispbit.com

LLMs are surprisingly good at writing test cases—something many developers either skip or struggle with. If you structure your workflow around TDD (Test-Driven Development), the LLM can generate and continuously rerun those tests as it iterates on the code. This creates a powerful closed-loop system where the spec (your unit tests) and the implementation evolve together.

Multimodal LLMs take it even further. I've given Claude 4 a screenshot and simply said, “There’s too much white space.” It correctly identified the issue and generated CSS fixes. That kind of feedback loop could easily become a regression test for visual/UI consistency.

This isn’t just about automating code generation—it’s about augmenting the entire development cycle, from specs to testing to visual QA.

Maybe it was never the bottleneck for paid software engineering at incorporated entities but it was definitely, 100%, the bottleneck for most human people.

And now instead of having to get the help or code from an actual programmer, as a non-programmer but technical person, I can generate or alter any small trivial applications I want. I'm not going to be writing an OS or doing "engineering" but if I want to write a GUI widget to display my PCs temps/etc, or alter a massive complex C++ program to have some feature I want (like adding checkpointing to llama.cpp's fine-tune training), suddenly it's trivial and takes 15 minutes. Before it'd take days if it were feasible without help at all.

Yep, code won't matter in the future. Code isn't the bottleneck anymore and it's a good liberation for us professional developers. Now we can move on.

That is why there is a being difference between being a sofware engineer, or software developer roles, and a plain coder, and titles carry more than words.

There has long been ways to reduce writing boilerplate code with IDEs. AI code generation is just another tool and it will help enable competent people.

>> LLMs are powerful — but they don’t fix the fundamentals

Sounds like we're (once again) rediscovering "No Silver Bullet".

We're approaching a future where creativity will be the bottleneck, everything else is going to be abstracted away.

Thank you; this is exactly what was bothering me. This is my opinion as well you just found the words I could not find!

True. Therefore I'm eagerly awaiting an artificially intelligent product manager.

Or I might build that myself.

There are times when writing the code is a bottleneck. It's not everyday code. You don't quite know how to write the code. Whatever you try breaks somehow, and you don't readily understand how, even though it is deterministic and you have a 100% repro test case.

An example of this is making changes to a self-hosting compiler. Due to something you don't understand, something is mistranslated. That mistranslation is silent though. It causes the compiler to mistranslate itself. That mistranslated compiler mistranslates something else in a different way, unrelated to the initial mistranslation. Not just any something else is mistranslated, but some rarely occurring something else. Your change is almost right: it does the right thing with numerous examples, some of them complicated. Making your change in the 100% correct way which doesn't cause this problem is like a puzzle to work out.

LLM AI is absolutely worthless in this type of situation because it's not something you can wing from the training data. It's not a verbal problem of token manipulation. Sure, if you already know how to code this correctly, then you can talk the LLM through it, but it could well be less effort just to do the typing.

However, writing everyday, straightforward code is in fact the bottleneck for every single one of the LLM cheerleaders you encounter on social networks.

X isn't the bottleneck. Y isn't the bottleneck. Z isn't the bottleneck. T ...

Guess what X + Y + Z + T ... in aggregate are the bottleneck, and LLMs pretty much speed up the whole operation :)

So pretty pointless and click-baity article & title, if you ask me.

One thing I despise about LLMs is transferring the cognitive load to a machine. It’s just another form of tech debt. And you have repay it pretty fast as the project grows.

The most outspoken person against LLMs on my team would bring this up a lot. Though the biggest bottleneck he identified was the politics and actually coming to agreements on spec of what to write. Even with perfect AI software engineers, this is still the issue, as someone still needs to tell the AI what to do. If no one is willing to do that, what’s the point of any of this?

I think a lot of teams will wrestle with the existing code review process being abused for quite a while. A lot of people are lazy or get into tech because it’s easy money. The combination of LLMs and a solid code review process means you can submit slop and not even be blamed for the results easier than ever.

This is a strawman isn't it? I haven't read one post or comment saying that writing code is "the bottleneck".

It's something that takes time. That time is now greatly reduced. So you can try more ideas and explore problems by trying solutions quickly instead of just talking about them.

Let's also not ignore the other side of this. The need for shared understanding, knowledge transfer etc is close to zero if your team is agents and your code is the input context (where the actual code is now at the level that machine code is now: very rarely if ever looked at). That's kinda where we're heading. Software is about to get much grander, and your team is individuals working on loosely connected parts of the product. Potentially hundreds of them.

My philosophy is dirt simple:

I am the pointy end of the spear.

I'm less concerned with professionals using LLMs to code and more excited by the idea of regular people using LLMs to create programs that solve their problems.

Wish the blog had an RSS feed

Maybe true, but not true enough.

The title says it all

bottom line is only thing that matters in the end

The author doesn't give any arguments to support his claim.

Nan, it depends on quality of data you trained the bot.

The author puts the BLUF: "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."

They're not wrong, but they're missing the point. These bottlenecks can be reduced when there are fewer humans involved.

Somewhat cynically:

code reviews: now sometimes there's just one person involved (reviewing LLM code) instead of two (code author + reviewer)

knowledge transfer: fewer people involved means this is less of an overhead

debugging: no change, yet

coordination and communication: fewer people means less overhead

LLMs shift the workload — they don’t remove it: sure, but shifting workload onto automation reduces the people involved

Understanding code is still the hard part: not much change, yet

Teams still rely on trust and shared context: much easier when there are fewer people involved

... and so on.

"Fewer humans involved" remains a high priority goal for a lot of employers. You can never forget that.

Slowly it’s getting time to become a goose farmer. Enough of this AI shit.

The article misses the point that LLMs are not removing the bottleneck of writing code for people who know how to write code. It's removing this bottleneck for everyone else.

I've spent the last few weeks writing a non-trivial distributed system using Codex (OpenAI's agentic coding system). I started by writing a design brief, and iterated with o3 to refine it so it was more complete and less ambiguous. Then I asked it to write a spec of all the messages - didn't like its first attempt, but iterated on it til I did like it. Then got it to write a project plan, and iterated on that. Only then did I start on the code. The purpose of all this is to provide it some context.

It generated around 13K lines of Go for me in just over two weeks. I didn't previously speak Go, but its not hard to skimread to get the gist of its approach. I probably wrote about 100 lines, though I added and removed a lot of logging at various times to understand what was actually happening. I got it to write a lot of unit tests, so that coverage testing is very good. But I didn't actually pay a lot of attention to most of those tests on the first pass, because it generally got all the fine detail stuff exactly right on the first pass. So why all the tests? First, if something seems off, I have a place to start a deep dive. Second, it pins down the architecture so that functionality can't creep without me noticing that it is needing to change the unit tests.

Some observations.

- Coding this way is very effective - the new models almost never make fine detail mistakes. But I want to step it through chunks of new functionality at a size that I can at least skim and understand. So that 13K LoC is about 300 PRs. Otherwise I lose track of the big picture, and in this world, the big picture is my task.

- Normally the big design decisions are separated by days of fine detail coding. Using codex means I get to make all those decisions nearly back-to-back. This is both good and bad. The experience is quite intense - mostly I found the fine-detail coding to be "therapeutic", but I don't get that anymore. But not needing to pay attention to the fine detail (at least most of the time), means I think I have a better picture in my head of the overall code structure. We only have so much attention at any time, and if I don't have to hold the details, I can pay attention to the more important things.

- It's very good at writing integration tests quickly, so I write a lot more of them. These I do pay a lot of attention to. Its these tests that tell me if I got the design right, and if not, these are the place I start digging to understand what I need to change.

- Because it takes 10-30m to come back with a response, I try to keep it working on around three tasks at a time. That takes some effort, as it does require come context switching, and effort to give it tasks that won't result in large merge conflicts. If it was faster, I would not bother to set multiple tasks in parallel.

- Codex allows you to ask for multiple solutions. For simpler stuff, I've found asking for one is fine. For slightly more open questions, it's good to ask for multiple solutions, review them and decide which you prefer.

- Just prompting it with "find a bug and suggest a fix" every now and then often shows up real bugs. Mostly they tend to be some form if internal inconsistency, where I'd changed my mind about part of the code, and the something elsewhere needed to be changed to be consistent.

- I learned a lot about Go from it. If I'd been writing myself, my Go would have looked more like C++ which I'm very familiar with. But it wrote more idiomatic Go from the start, and I've learned along the way.

- Any stock algorithm stuff it will one-shot. "Load this set of network links, build a graph from them, run dijkstra over the graph from this node, and tell me the histogram of how many equal-cost shortest paths there are to every other node." That sort of stuff it will one-shot.

- It's much better than me about reasoning about concurrency. Though of course this is also one of Go's strengths.

Now I don't have any experience of how good it would be for maintaining a much larger codebase, but for this sort of scale of utility, I'm very impressed with how effective it has been.

Disclaimer: I work at OpenAI, but on networks, not AI.

Funny article, but it seems that the author did not get the "Definition of Done" memo.

While...

> Writing Code Was Never the Bottleneck

...it was also never the job that needed to get done. We wanted to put well working functionality in the hands of users, in an extendible way (so we could add more features later without too much hassle).

If lines of code were the metric of success (like "deal value" is for sales) we would incentivize developers for lines of code written.

[dead]

[dead]

Yet another article trying to take away from the impact of LLMs. This one is more subtle than most, but still the message is "this problem that was solved, was never actually the problem."

Except... writing code is often a bottleneck. Yeah, code reviews, understanding the domain, etc, is also a bottleneck. But Cursor lets me write apps and tools in 1/20th the time it would take me in an area where I am an expert. It very much has removed my biggest bottleneck.