Hacker News Reader

Comment by idopmstuff | Hacker News Reader

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.

View on HN

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!

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

Reply on news.ycombinator.com