A developer with 20 years on the job told me something last week.
His old burnout used to make sense. Eight hours of code. Brain fried. Go home. Sleep. Repeat. Predictable.
His new burnout is harder to describe.
He asks AI to do something. He reads what it produced. Something looks off. He asks again. He notices a regression in a file he never opened. He redirects. The AI confidently takes a wrong turn. He pulls it back. He ships less code than he used to, and feels more drained doing it.
It sounds easier than writing the code yourself.
It is not.
The 200 hour robot run is the perfect metaphor
Last week Figure AI livestreamed a humanoid robot sorting packages for 200 hours straight. The unit was called F.03, nicknamed Rose. Zero hardware failures. 249,560 packages processed. Self-charging fleet rotation. Onboard inference via their Helix-02 model. No human teleoperation, no remote control, no reset. By any objective measure, a triumph for the autonomy stack.
Watchers were spotting things. One yellow package gave the robot trouble for a long stretch. People noted the robot seemed less aware of its environment than a human would be. Subtle drift. Small failure modes. Things a casual observer would miss but a careful one could not stop noticing.
That is the job now.
Watching the autonomous system run, and noticing the parts that do not quite work. Not building. Not sleeping either.
Why supervision drains differently than building
Writing code is one kind of cognitive load. You hold the problem in your head, you decide, you produce output. There is a beginning, a middle, and an end. You finish a function. You breathe. You start the next one.
Supervising an autonomous system is a different load.
There is no rhythm. The AI does not pause when it is done. It produces, and you check, and it produces, and you check. Your attention can never relax because the model that confidently solved the last six things might confidently break the seventh.
The mental shape is closer to managing a junior than to writing code.
A junior who never gets tired. Never asks for clarification. Never sleeps. Never learns from yesterday’s mistake. Produces three times faster than the senior reviewing them.
That last part is the trap.
Because they produce faster than you can review, your queue grows. The work compounds in the wrong direction. You finish the day having reviewed twelve PRs and shipped two. You feel behind. You are behind. The metric you used to measure yourself by, “lines of code I wrote today”, does not apply anymore. The metric that should replace it, “judgment calls I made well today”, does not show up in any dashboard.
So you feel less productive, even when the org is shipping more.
The Figure AI livestream is what our work feels like now
A team of engineers built a system that runs autonomously. They went home. They came back. The system was still running. Champagne came out at hour 200.
But the actual watching of the run? That was a livestream. Thousands of people sat there for nine days noticing things. The package that got stuck. The motion that looked off. The failure modes nobody had documented yet.
That is our job now.
We are not only the engineers who build the system anymore. We are the engineers who watch it. And nobody talks about how tiring that is, because the building part used to be the only thing we measured.
What actually helps
Batch the AI work.
Do not oscillate between writing prose and reviewing AI output every six minutes. The context switch is what kills you. Set aside two hours for AI-assisted work, then turn it off. Write something yourself with no autocomplete. The brain needs a break from supervision.
For anything close to the core of the product, write it yourself.
The overhead of getting AI to write code you trust often costs more than just writing it. The simple version of this rule: if you would lose sleep over a bug in this file, do not outsource it to a system that does not lose sleep.
Treat AI output like junior PRs.
Review them with the same care you would a junior submission. Push back. Ask why. Do not merge because the code compiles. Compilation is the lowest bar a piece of code can clear.
Build in deliberate offline blocks.
Not vacation. Just hours where the tool is off. The autonomy of the system means you have to manufacture your own breaks. They do not happen by themselves anymore.
The thesis in fewer words
The tools are not the problem. The rhythm is.
Eight hours of building used to drain you in a predictable way. Eight hours of watching an autonomous system drains you in a way nobody named yet. It feels lighter in the moment. It is heavier at the end of the day.
The Figure AI team got champagne after 200 hours.
We get the next ticket.
Final Words
I would love to hear if this matches what you are feeling, or if your experience is the opposite of mine. The post is half-finished without the responses.
You can find me on LinkedIn (linkedin.com/in/ivanturkovic), X (x.com/ithora), and Threads (threads.com/@ithora).
If you want to reach me directly, the contact page is at ivanturkovic.com/contact.
For hiring or fractional CTO inquiries, you can book a 30-minute call at cal.eu/ivan-turkovic/30min.
So tell me: are you shipping more or less code than you were a year ago, and does it feel like you are doing more or less engineering?
If this post made you think, you'll probably like the next one. I write about what's actually changing in software engineering, not what LinkedIn wants you to believe. No spam, unsubscribe anytime.