upvote
> Code was very rarely the bottleneck in the first place.

I disagree. Kinda

What AI has made much simpler is that you don't have to waste time checking docs and have the best autocomplete system by a long shot - this was a bottleneck unless you were doing Java or some other language with "perfect" AC

What AI made "kinda easier": solving for usual problems. The stuff you would search Stack Overflow, or think a couple of minutes for an optimized solution - not a bottleneck but not 100% smooth neither

You still have to test and validate your code. AI made this easier-ish but this is still where I see manual work being needed (even if you are automating tests - you still have to think on what you want the code to do)

reply
But searching on google or SO wasn’t the bottleneck either. It was searching on your own codebase (and dependant ones) for the exact place (a class, a file, a function) where to put/delete/update business logic without breaking production.

LLMs help, but they haven’t been trained on our own repos. I don’t need the LLM to help me with algos that are available online… I need them to help me with custom business logic

reply
I disagree. Coordinating 100 folks to align on a problems statement with "agile" and sprints was always the biggest bottleneck. Difference in opinion, internal politics is always a bottleneck.

I think now, code is the bottleneck. Just because you can generate million lines of code, people with different skill level think they are accomplishing the task, testing, merge conflicts, trust has become the bottleneck.

reply
A pattern I have seen:

The “old way” would be lots of debate (both bike shedding and useful) among engineers during design phase, and then you’d implement.

Now it’s shifted so there are no design docs and there is only the generated prototype. People trying to do their design review while there’s already a functional-ish prototype and it goes nowhere. There’s an anchoring effect in place because the first thing already exists and management says “this seems to work, just use it and move on”. The result is that useful debates about substantive issues don’t happen and bikeshedding is all way get to do

reply
This is so accurate. I am a fairly senior individual contributor and its been more than a year since I saw a good design doc or quality design discussion. Before you can even question the design, someone has generated a 50k line prototype and already made up their mind because of all the “you’re absolutely right..” and “X is exactly what you need..” from AI.
reply
This very much. First thing built is what get approved. Even if it will generate 10x the workload down the line, because today's quality bar is very much demo level.

And then you get paged at 2am because prod is down and the support channel is more active than the team's one.

reply
The distance between substantive issues vs bikeshed sized issues is non-linear and ill-defined. Sometimes: yeah, we're just bikeshedding. Other times, it's important to suss out unshared implied context that doesn't match between various stakeholders and will have outsized ramifications later. What's new is the speed of executing changes. If there was no substantive debate about what programming language to even use so everyone is equally happy (read: sad), so what? Have the LLM rewrite the entire project in another language over the span of a couple of days after that discussion is had because the language used has specific shortcomings that have been unmined.
reply
This just says that we can output code faster. I'm saying that the rate at which we output code wasn't the thing that was slowing down development. We've always been able to increase that even without AI by adjusting the working environment and removing obstacles to programming.

In larger organizations, quite often it's the business that is holding back development. They can only handle so much change and speed needs direction to be velocity. Drafting requirements is generally much slower than implementing them.

Like the number one complaint from programmers has been that they don't get to do programming. They want to write code, not update jiras or spend hours in meetings.

reply