Comment by locknitpicker | Hacker News Reader

Comment by locknitpicker | Hacker News Reader

Parent Full thread

> Bottleneck for what? More features?

Code changes. Not necessarily features, but also bug fixes, plain old maintenance, and even refactoring to improve testability.

With AI coding assistants, what in the past were considered junior dev tasks are now implemented with a quick prompt and an agent working in the background.

These junior dev tasks are now effortlessly delivered by coding assistants, with barely any human intervention. Backlogs are cleared faster than new items are added. And new items are added more and more because capacity to clear them is no longer an issue. The challenge is now keeping up with the volume of changes. I see this first-hand at my org.

> Those are pretty good bottlenecks for a company. I doubt an agent is fixing any of those. At least any time soon.

Just because you can think of other bottlenecks that doesn't mean that generating code was not a bottleneck, and is not the bottleneck today. The mere notion of a backlog demonstrates that it is a bottleneck.

I was not merely stating other bottlenecks. I'm saying they're more important bottlenecks.

They can't all be equally important bottlenecks; a bottleneck is by definition a singular component or sub-system most-limiting to the system's output.

What are we trying to output from our businesses? Code?

What is this magical context floating around every business that will unlock AI agents to produce ... what?

[Edit] I apologize for my tone. You're right, dealing with the speed of code generation is an unprecedented problem. I was making the argument that it's not the most important to the business and that rate of code change is very rarely the top concern. But that does not mean it's not the most important problem for someone. For the developers dealing with the system, it is.

> I was not merely stating other bottlenecks. I'm saying they're more important bottlenecks.

This is a pointless statement though. The fact that writing code is a bottleneck, and a critical one, doesn't mean it's the only thing standing between us and fixing/implementing something.

It's like downplaying the time taken by international flights, because people can spend time passing through security.

The truth of the matter is that all software development processes is built around how slow code is written. Now code is ceasing to become a bottleneck and the current software dev process starts to emerge as inadequate.

No, it is not pointless to say other things are more important. An order of importance is how you prioritize things.

You're asserting that it is critical. Why is code change speed critical?

What is your analogy getting it? It does not map to my argument evidently.

You're asserting it is slow code that has evolved our development process. Why? It used to be correctness and appropriateness. How is it suddenly speed?

Bottleneck for what?

> Now code is ceasing to become a bottleneck and the current software dev process starts to emerge as inadequate

If you say so. It's a honeymoon period for executives and a lot of them already got a lot of cold showers. It's just a very uncomfortable topic but it is already happening. Maybe not in your org but I am seeing it already.

I am not against the new reality even if it were to solidify (which it will not; productivity gains as sold are illusory and plateau VERY quickly; we're talking days -- and contrary to what many on HN believe, not all work is pitch decks and rapid prototypes).

I really like the acceleration and removal of dumb grunt work. I love it. But the current LLMs, even Codex and Opus, _are_ doing dumb stuff even on max effort still. People get hyped up and overshoot as they always do.

It must be said that I've used Opus for some pretty high-level and high-quality architectural work and it did very well -- but it took a lot of effort and steering, leaving me questioning whether I wouldn't have the done planning and scoping better and quicker.

Frontier LLMs do very well but people give them too much credit IMO.

> Backlogs are cleared faster than new items are added

Totally depends on what kind of product and codebase.

Last time I checked, the number of open issues in Claude Code repo has increased.

And I have seen tons of tickets that are open for years. Not because it's technically hard or anything. An intern can do that. Those tickets are not closed because nobody wants to deal with what comes after it.

> Last time I checked, the number of open issues in Claude Code repo has increased.

The Claude Code repo features bug reports that are a mishmash of complains about prompt output, backend responses, documentation updates, browser extensions, etc.

Still, during the last week the repository reports ~2k closed issues vs ~1.3k new issues.

https://github.com/anthropics/claude-code/pulse

Reply on news.ycombinator.com