AI-assisted engineers are burning out, is this fine? | Hacker News Reader

AI-assisted engineers are burning out, is this fine?

evilmartians.com

42 pointsvinnyglennon26 comments

My only thought is take your time to actually review what the LLM/Agent generates... ensure that you understand and can follow it. Give feedback and iterate as necessary. I've used this analogy a lot, but it's really a lot like managing remote development teams in a lot of ways... and even though you can also use agents for planning, it becomes a critical step as part of the communication loop when you aren't sharing a physical space.

I emphatically do not use multiple agents at a time... I monitor what the agent I'm working with is doing, stop it if it's going down the wrong path and give feedback along the way... don't be afraid to git reset a set of changes, then tell the agent you did so and why. Spend more time on structure and design up front, it will save you a lot of headaches later.

Beyond this, I've found the "5 hour window" that anthropic gives to be pretty helpful... when I've expended my allotment for the window, odds are, I've done enough for the day even. Read, work on something else, etc... know when it's a good time to stop for a day... it's easy to over-work yourself... it takes discipline to actually break for lunch, or the day. For that matter, step away from your desk for lunch and plan to take at least an hour if you can.

You can still deliver a crap ton of value beyond what you individually could do with an agent... but there needs to be a human in the loop for anything that people depend on for their money or livelihood.

Charming praise for Anthropic’s low rate limits. It’s a selling point over codex I hadn’t thought of.

Honestly, I've only ever actually hit the 5 hour limit a handful of times and it's been around 30m or less from the next window... I've either stopped for the day or took a break and continued in the next window.

I'm not running a bunch of agents in parallel as I actually review/track most of what is getting done while it's happening.. sometimes I'll stop/rollback and rerun with updated instructions. I can't imagine anyone actually doing meaningful reviews of code generated by a half dozen agents running in parallel for example/contrast.

That said, I mostly stand by my statement... at least in how I've been using AI lately.

Writing code was slow but you understood what you built. Reviewing AI code is fast but you're accumulating blind spots. Both the human cost (this article) and the codebase cost are growing together.

"Writing code was slow but you understood what you built. "

Yes. Definitely. I never did try and error with code snippets from the internet until something sort of worked.

I never hacked things together like this till the sun rose and had no idea 2 weeks later who wrote that hacky mess and why like this. Or well, years later.

And as the code piled up and side problems took over, I certainly did not reimplemented the same functions again and again, because I forgot I did the same already 3 years ago. And that module (and that part and this), that works great as long as you don't touch anything? Yeah, I certainly know how that works in detail. All in control. Gotta fight to keep AI away from my code to stay in control!

You do realise this is your experience, and just outs you as a mediocre engineer and doesn't prove that slow and steady doesn't win the race, right?

Or did you write your comment with an intentional self-demeaning note, and not a sarcastic tone?

Let me put it like this, I believe there are holy sacred programmers out there, who always are in total control of their code, I just have not met them yet.

And no, not all my code is written at 5 am when I am close of passing out. But I say those who never experienced that flow to also do hacky things to get something done and if it takes till the morning, maybe did not capture the full spirit of a hacker site?

"holy sacred programmers" and writing "the same functions again and again" are two extremes. There's a point in the middle where you implement the same function twice perhaps and then on the third time feel like such a thing should already be there and so go look or maybe perhaps add some documentation or centralize functionality to a utilities library etc.

I believe the point being discussed is the scale of "badness" that vibe-coding introduces.

"There's a point in the middle where you implement the same function twice perhaps and then on the third time feel like such a thing should already be there and so go look or maybe perhaps add some documentation or centralize functionality to a utilities library etc."

Yes, my point was exactly about the middle ground. (And the double implemented functions were of a rather small kind, where rewriting them was faster than looking for the old ones. And it was hyperbole of course, I don't routinely do the same again and again for no reason. I remember maybe 2 or 3 instances of that happening)

I wrote bad code and good code in my life, depending on the project and depending on myself.

And where I wrote bad code in the past, AI is actually great with helping that. Finding duplicates, documentation out of order, etc.

"I believe the point being discussed is the scale of "badness" that vibe-coding introduces."

The point I was discussing is that code is not automatically understood, or good, just because a human wrote it.

So all in all, sure, Vibe coding enables a new universe of bad code (that pretends to look good). But if done right, it can also raise the bar. It is a powerful tool and up to us on how we use it.

Since we out here doing ad hominems: if you don't think the code you wrote a few months ago is shit, you're already cooked, and judging by that comment, I'm betting you're crispy.

Even the best code I've ever written rots, not because it changes but because I get better. Now... I know thinking out of the box is hard... but one can get better a lot of different ways, and call me an optimist, but I'm betting folks can get better at producing tool-assisted code, too. Assuming how we do it now is how it will be forever is silly.

We're in the middle of figuring out the next level of mediated engineering. You-know-what or get off the pot, but stop pretending being a dinosaur is still in vogue. It's gauche, and trust me, we've seen it all before...

... back in my day we didn't have that fancy IDE autocomplete; we memorized every function in a library. IDEs?! ... Back in my day we didn't even have debuggers; we just knew how the code worked. Pish posh, back in my day the compiler didn't even produce error messages that made sense. Compilers? The faux luxury of it all! Back in my day, if you actually cared about your code, you wrote the assembly by hand.

The code I write is pretty good, and it stays good throughout the years because it was already good. If you're frequently finding month old code to be shit, your code is just shit to begin with.

Or .. you are working in an unstable environment. If the system you take as a base changes frequently(like the web), your code becomes bad, outdated code, no matter how shiny it was before. But if it was good, migration and maintaining it is easier.

React is 13 years old

So?

Are you implying I should have switched to react 13 years ago, when it was just another framework who come and go?

And then my experience would have been stable?

(I kind of doubt it, when my unstable web experience was caused by changes into how canvas works, webrtc, indexeddb, webgl, webgpu. I don't make simple UI's)

Or well, just that "let" was introduced makes all my beautiful old code with only "var" bad code by modern standards.

"let" is 11 years old.

My point is that the web is not really an unstable platform anymore, it's just something people say that used to be true. Also using var and other superceded constructions doesn't make the code bad; that's not what bad code is. I think you know this.

I think I know that different people have different metrics what bad code is.

My main metric is, if it is readable. So yes, I also don't consider my old code with var bad. But other people do.

If you haven't had this experience, I would rather think yóu are junior

Yes. Definitely.

I didn't necessarily know everything about my code at all times before.

And that justifies my gleeful embrace of not knowing anything about my code now.

Working on some experimental coding it reminded me how coding in little steps then testing, documenting and coding some more is basic to making development work. Now LLMs encourage big chunks of development all at once. The interfaces, back end, tests, configuration all appear at once, fully formed. Coming to terms with the code still requires taking in minutia, but keeping up with LLMs ends up exhausting this capacity. The new method is fully the opposite of what has been known to work.

You can certainly work on small chunks with an LLM agent. I’ve gotten the best results with 1. Small chunk with tests 2. Refactor/simplify 3. Next small chunk. - I do work on backend and front end at the same time usually but I’ll do a backend pass, then when I need a dopamine hit to keep me focused I’ll get some front end done. So it’s backend steps 1 and 2 repeated until I feel flat, front end steps 1 and 2 until I’m Neuro chemically satisfied then back to backend. YMMV

Exchange / "chat" requests like with a human contractor feels like the optimal bandwidth. Imagine having a report whose work nobody in the org understands or owns? Can't scale into maintenance or support mode.

I might be open to some agent-like behavior, access to a git repo and ticket system. Probably not my whole OS, any more than I'd give to a drunk schitzo I met on the Internet.

I see the appeal to what people have going on. But I've been using LLMs for going on a year, I was slow to adopt and wait-and-see because I didn't need it at the time (deep dive, learning python Ecosystem). I'm glad I stayed the course. I can get great results prompting these things and edit the results with care.

No more burnout than a subordinate working for hire in this mode. Things remain manageable, and I can do all the higher level Dev/Eng/Product work that drives the Coding. Which is a good new challenge to me, never got to go so high up the food chain with so much focus.

This was bound to happen. Probably won't get better, but will mean we will need more emphasis on mental health.

"the part of the profession that attracted them in the first place is being removed or fundamentally altered"

Personally, I experienced something different. Before AI, it was the managers who gradually took away the joy and tried to fundamentally alter the profession... AI brought much of the joy back. Until some upstream roles discovered AI and used it as leverage to send larger volumes of bullshit downstream. I got away, sadly some people could not.

But AI has actually enabled me to work through by backlog much faster, which decreases my chance on burnout.

And I still enjoy the process actually. It's a different process indeed. But times change, and you can't always do the same thing forever.

This asynchronous engineering progress has allowed me to do more householding in between. It maybe sounds crazy, but I feel it helps me organise my life better. For me it won't cause any burnout anyway.

Shared this one with my team; this has been an ongoing discussion for the last few months because its affecting most of us at varying levels.

And this doesn't cover the scenario of code reviews. If, in the example, Ben and Alice are reviewing each other's code - Ben now has twice as much code to review as Alice does, so her AI usage also affects him negatively.

I’ve felt burnt out- it’s pretty exhausting reviewing and testing code all day

Reply on news.ycombinator.com