If I read “load-bearing” or “blast radius” one more time…
Don’t forget about the “smoking gun”
The bottleneck was never the code
311–320 of 446 posts
Re: The bottleneck was never the code
#312Earlier quoted context omitted.
> 2. It's annoying and disruptive to be interrupted when doing work that requires deep focus. Steering a LLM also requires deep focus. Unless you want to end up on accidentally quadratic or have a CVE named after your project.
How can it? You prompt it, then wait minutes+ for it to come back. It's the opposite of flow state.
What I do is, I'm always responding to output N while the AI is working on prompt N+1. So we are both always responding to each other's question/answer before last.
Re: The bottleneck was never the code
#313It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…
I don’t think that’s the issue. The problem is that with software you don’t know what a user might like until something is in production.
This is probably true of other fields too. But rolling back changes there is expensive (example construction).
But with software you can get to put things out and iterate. This is not to say identifying what’s needed isn’t important but you had roles where the product owner is getting feedback for the previous iteration while the devs are working on the current one.
With code assistants this loop collapses a LOT. Suddenly it can be a lot easier to define better what you need and in near real time also gauge how it would operate.
Both are true “leave me alone” and “you don’t know what to build”. Because the people identifying what to build aren’t the people doing the building.
Re: The bottleneck was never the code
#314Earlier quoted context omitted.
No. It's not more AI. The solution is designing and sticking to development process that is more resilient to errors than the one that's currently happening. This isn't a novel idea. Code reviews weren't always part of the process, neither was VCS, nor bug tracker etc. The way AI is set up today, it's trying to replicate the (hopefully) good existing practices. Possibly faster. The real change comes from inventing be…
What better practices do you mean? Are you saying we just need different more agentic-friendly practices that ensure scaled reliability beyond what we can manually check? If so I totally agree. AI is 100% capable fundamentally of making new processes. Look I mean it’s not like I think opus 4.7 is all you need, but how can you argue with the fact that adoption since 4.5 has been an inflection point? That’s kind of pro…
> What better practices do you mean?
I literally listed examples above... Code reviews weren't the norm until some time around 2010-ish. Then programmers realized that reviews help improve the code quality, and, eventually, this became so popular that today virtually everyone does it.
Anyways, I'll give an example from something that I've personally experienced / contributed to, which isn't as massive of a thing as code reviews, but is in the same general category.
Long ago, Git didn't have --force-with-lease option. Few people used `git rebase` command because of that (the only way this would work is if using it later with --force, which could destroy someone else's work). In the company I worked at the time, we extended Git to have what was later implemented as --force-with-lease. Our motivation was the need for linear history and some other stricter requirements on the repository history (s.a. every commit must compile, retroactive modifications in response to tests added later etc.)
This is an example of how a process, that until then was either prone to accidental loss of programmer's work or would result in poorly organized history was improved by inventing a new ability. This is also an example of something AI doesn't do, because, at its core, it's a program that tries to replicate the best existing tools and practices. It won't imagine a new Git feature because it has no idea what it could possibly be because its authors don't know that either.
> opus 4.7 is all you need, but how can you argue with the fact that adoption since 4.5 has been an inflection point?
What did it invent?
Re: The bottleneck was never the code
#315Earlier quoted context omitted.
> A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload. The problem rather is: often good programmers have quite good ideas how these problems could be solved, but for "organizational politics" reasons they are not allowed to apply these solutions. Thus: Concerning (B): Because they are not allowed to apply their improvement ideas, they are the bottlen…
Additionally on A: the people who will be stuck maintaining this contribution for years and years have a different view of the pain. Pushing a 90% solution through is a ‘win’ for the coder who is leaving, and hurts everyone on a continuing basis. It’s bad accounting, and lets the consultant look good for making the team perform worse (and look bad later). And, IME, if that 90% solution needs a 100% rewrite after 40-8…
No matter what you do, entrenched engineers will make SURE they will be the only ones maintaining everything until their retirement, because they will make life impossible for everybody else until they leave.
Entrenched engineers don’t want to you to alleviate or god forbid share the pain. Pain is good for employment security. And if the ship goes down, they’ll make sure they’re the last one to get fired, because there’s nothing the entrenched engineer fears more than having to job hunt.
Re: The bottleneck was never the code
#316Earlier quoted context omitted.
> systemic tech debt is now addressable at scale with LLMs. Is there any reason to believe this? I've only seen the evidence of the contrary so far. My experience with AI coding aides is that they, generally: 1. Don't have an opinion. 2. Are trained on code written using practices that increase technical debt. 3. Lack in the greater perspective department, more focused on concrete, superficial and immediate. I think,…
You are not wrong about anything you’re saying but like I said this misses the forest for the trees. I’m talking about like the next ~2 years. There is a common idea that we don’t understand this technology or what will happen performance wise. We know a lot more about what’s going to happen than people think. It’s because none of this is new. We’ve known about neural nets since the 40s, we know how RL works on a fun…
> look at say Claude sonnet 3.x. It’s an entire world away in like a year
In the area I work I find them to be of very little value both then and now... I see no real difference. They help in marginal tasks. Eg. they catch typos, or they help new programmers to faster explore the existing codebase.
So far, I haven't used a single line of code generated by AI, even though I've seen thousands. Some of them worked to draw attention to a problem, but none solved it successfully. It was all pretty lame.
I see no reason to believe it's going to get better. Waving hands more forcefully isn't helping, there's no argument behind the promise of "it will get better". No reason to believe it will...
But, more importantly, the AI is applied on a level where really important things don't happen. It's automating boilerplate work. It doesn't make decisions about the important parts. Like, in the example above, the AI is not capable of choosing a better strategy: use pyproject.toml or write code to build Python packages? It's not the kind of decision it's called to make and nobody sensible would trust it to make such a decision because there isn't a clear right or wrong answer, only the future will prove one or the other to be the right call.
Re: The bottleneck was never the code
#317Earlier quoted context omitted.
It’s part of the problem but AI also can crush this on pure lines of code and functionality alone. It can put out 100,000 lines of somewhat decent code in a day. That usually takes months or years of manual coding for a team.
More lines of code doesn’t help adding more constraints to a system without violating the existing ones. In fact, it makes it harder.
It’s not just verbose code. I’m talking about 100,000 lines of relatively decent feature code that isn’t bloated.
Re: The bottleneck was never the code
#318I think veteran engineers have always known that the real problems with velocity have always been more organizational than technical. The inability for the business to define a focused, productive roadmap has always been the problem in software engineering. Constantly jumping to the next shiny thing that yields almost no ROI but never allowing systemic tech debt to be addressed has crippled many company's I have work…
- systemic tech debt is now addressable at scale with LLMs. Future models will be good enough to sustain this, if people don’t believe this I would challenge them to explain why. First consider if you understand what scaling laws are like chinchilla and how RL with verification works fundamentally - I completely agree with you about fundamentally the limitation being the business able to coherently articulate itself…
The problem with tech debt is not that it is some poorly designed code in a few repositories that can just be changed. True tech debt is the kind that requires significant architectural changes across many systems and is almost always coupled with major data migrations. You need the rest of the business to agree that you want to invest all that time and energy to fix a problem someone else created 10 years ago. You likely will also need other teams to set aside time on their own road map to address it. You also might need customers to change what they are doing because if software lets you do something, you can guarantee that someone has learned to do it - even if that 'something' was actually a bug.
LLMs don't solve any of those problems by itself.
Re: The bottleneck was never the code
#319>The goal was to test our structured-generation algorithms and their open-source counterparts, replacing the naive “does it accept this string?” with something closer to the real problem: “does it produce the right token distribution?” The experiment kept coming up in conversation, then returning to the roadmap. Last month, I spent half an hour explaining the method to Codex. A few hours later, it had produced a working first version. That’s all it took.
Proving that the bottleneck, was, in fact, the code. It's just that the AI wrote it now.
The person who thought "the bottleneck wasn't the code" already had the goal discussed and coherent in their mind.
Code as bottleneck doesn't have to mean "I wanted this feature but it took me many months to finally code it". It is also "I wanted this feature for 2 years, but the friction in sitting down to put it in code and spending 5-10 days on it, etc, put me off".
If the code wasn't the bottleneck, they could just sit and write it themlseves. But, they didn't want to go through the effort and time spent of coding it themselves, as they knew it wouldn't take as little as with the LLM.
(And even when you don't have a clear final spec in mind, the exploratory code+check+discard+retry-new-design, is also faster with an LLM, precisely because the "code" part is).
In other words, the code was the bottleneck.
The post appears AI-generated itself, just with instructions to avoid obvious constructions, which still makes for tedious reading.
Re: The bottleneck was never the code
#320It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…
Are you referring to the author specifically? Or a specific hypocritical person you know? If you're making a general statement about groups of online people you might be falling for the group attribution error[1], where the characteristics of an individual are assumed to be reflective of the whole group. In any case, two things can be simultaneously true: 1. Writing code is not the bottleneck, as in we can develop fe…
>Writing code is not the bottleneck, as in we can develop features faster than they can be deployed.
That's an organizational issue due to over-regulation, bureucracy, too many stakeholders each with their own irrelevant opinion, etc.
Startups or FOSS projects without the above absolutely can't "develop features faster than they can be deployed", and usually have a huge backlog of bugs and features they'd like to have, but never got around to.