Hacker News Reader

Comment by salt-thrower | Hacker News Reader

At every company I’ve ever worked for, the bottleneck is not “how fast can we spit out more code?” It’s always: “how fast can the business actually decide what they want and create a good backlog?”

Maybe startup development will significantly accelerate with AI churning out all the boilerplate to get your app started.

But enterprise development, where the app is already there and you’re building new features on top of a labyrinthian foundation, is a different beast. The hard part is sitting through planning meetings or untangling weird system dependencies, not churning out net new code. My two cents anyway.

View on HN

As a PM I have never not had a backlog of little stuff we'd love to do but can't justify prioritizing. I've also almost always had developers who want to make improvements to the codebase that don't get prioritized because we need new features.

The upside is that both of these things are the kind of tasks that are probably good to give to AI. I've always got little UI bugs that bother me every time I use our application but don't actually break anything and thus won't impact revenue and never get done.

I had a frontend engineer, who, when I could just find a way to give him time to do whatever he wanted, would just constantly make little improvements that would incrementally speed up pageload.

Both of those cases feel like places where AI probably gets the job done.

> developers who want to make improvements to the codebase that don't get prioritized

So, to clarify – developers want to make improvements to the codebase, and you want to give that work to AI? Have you never been in the shoes of making an improvement or a suggestion for a project that you want to work on, seeing it given to somebody else, and then being assigned just more slog that you don't want to do?

I mean, I'm no PM, but that certainly seems like a way to kill team morale, if nothing else.

> I had a frontend engineer, who, when I could just find a way to give him time to do whatever he wanted, would just constantly make little improvements that would incrementally speed up pageload.

Blows my mind to think that those are the things you want to give to AI. I'd quit.

There are tons of small improvements I want to make to our codebase that would be great but take effort. Refactors are a great example. We hand those to Devin (or Cursor background agents, etc), review, and we're all happier for it. Our PM uses it fix those little UI annoyances all the time like "update the text on this button". It's been wonderful.

Really says something about the HN crowd that you're getting downvoted for this.

I completely agree. Those annoying UI bugs and the general need to refactor are often the same technical debt. If you want to make an already bad codebase even worse, giving those tasks to AI is probably the quickest and surest way.

The ability to untangle old bad code and make bigger broader plans for a codebase is precisely where you need human developers the most.

I'd give them to AI because they're generally just not getting done. I worked hard to get that frontend dev time to make those improvements, but there was no chance it was ever going to be enough. When you're talking about enterprise software, minor improvements to pageload speed do not move the needle on revenue. When you have a list of features that customers will actually pay for, those will get priority 100% of the time.

Everybody's job is to serve the company priorities. Engineers don't get to pick the tasks they want to do because they're getting paid to be there. I also have spent lots of time doing things I'd rather not do, because that's the nature of a job (plus a pile of stock options incentivizes me).

Better to have those tasks done by AI than not at all.

That sounds good, but if you have a PMO and an enterprise Change Control Board that controls your not-quite-CI/CD deployments, you may find yourself hamstrung. I've been in that position before, where there was simultaneously a bottleneck of clear requirements and also a bunch of stuff (tech debt, small features, bug fixes, UI tweaks) sitting and waiting on a branch ready to deploy when downtime was finally approved. Or, situations where enterprise policy requires human SQA signoff on everything going to prod. There are lots of places you can create inefficiencies in the system and lack of approved requirements is just one.

Thankfully my career has been at very early stage startups, so none of that applies!

I never worked at a place where not having a backlog was an issue. Quite the opposite in fact - there’s always infinite backlogs of stuff. Every single time I’ve seen organizations being slow to decide anything, it was due to the human tendency to stretch their tasks to occupy as much time as possible. Planning meetings are “the work” for a legion of people (even though they also know they’re mostly pointless). Untangling dependencies is harder when it involves approvals of other humans (particularly fun as multiple people are “the tech lead”, are all objectively wrong but unable to see how they’re simply getting in the way).

I don’t think LLMs are particularly smart, or capable of, or will definitely replace humans at anything, or if they’ll lead to better work. But I can already tell that their inherent lack of an ego DO accelerate things at enterprises, for the simple reason that the self-imposed roadblocks above stop happening

At my current workplace, we do have a roadmap for the business, but the actual backlog of tickets to implement work is all waiting on other siloed teams to make decisions that we are downstream of. This ranges from our infrastructure model to simple things like “which CSS components are we allowed to use.”

We are also explicitly NOT allowed to make any code changes that aren’t part of a story that our product owner has approved and prioritized.

The result is that we scrape together some stories to work on every sprint, but if we finish it early, we quickly run into red tape and circular conversations with other “decision makers” who need to tell us what we’re allowed to do before we actually do anything.

It’s fairly maddening. The whole org is hamstrung by a few workaholic individuals who control decision making for several teams and are chronically unavailable as a result.

I’ve seen this sort of thing happen at other big enterprises too but my current situation is perhaps an extreme example of dysfunction. Point being, when an org gets tangled up like this, LLMs aren’t gonna save it :)

The moment those people start being removed, and the little work they do automated, it’ll have a dramatic downstream effect.

I’ve already witnessed a certain big tech that started to move much faster by removing TPMs & EMs across the board, even without LLMs to “replace” them. With LLMs, you need even fewer layers. Then eventually fewer middle-of-business decision makers. In your example, it’s entirely possible that the function of making those components could be entirely subsumed by a single AI bot. That’s starting to happen a lot in the devops space already.

All that said, I doubt your business would benefit from moving faster anyway - most businesses don’t actually need to move faster. I highly recommend the “Bullshit Jobs” book, on this matter. Businesses will just need fewer and fewer people

All of those things will be easier with fewer people involved though?

Yup I agree. The fundamental limiter is humans deciding. But it will trivial to clone apps where things were already decided.

Though AI will probably just proactively add features and open PRs and people can choose

There was a submission a few months ago that boiled down to 'AI will force us to reevaluate our human in the loop decision points.'

Which I expect will be the gist of management consulting reports for the next decade.

If human decision-makers become the bottleneck... eventually that will be reengineered.

I'm fascinated to imagine what change control will need to look like in a majority-AI scenario. Expect there will be a lot more focus on TDD.

Eerily similar to the plot of terminator

Reply on news.ycombinator.com