I came into work this week feeling foggy.
Not sick. Not unhappy. Not even unmotivated, exactly. Just mentally dull in a way I could not immediately name. The kind of tired where the tabs are open, the coffee is there, the work matters, and some part of the mind that usually reaches for the problem simply does not reach.
That was the strange part. Most weeks, I come in with energy. There is usually something I want to show somebody, something I tried over the weekend, something a model did that surprised me, something I want to pull apart and understand. That feeling has become one of the defining textures of engineering right now. The industry feels awake. Every week, some new capability shows up and quietly moves the line between impossible and obvious.
This time, I sat down and felt none of that first. I felt fog. Then I recognized the shape of it.
It felt like burnout.
That word can sound too heavy for a Monday morning, especially when the cause is not despair. The confusing thing about this version is that it comes from excitement. I am not tired because the work feels dead. I am tired because the work feels alive in too many places at once.
AI has made software feel playful again. It has brought out the inner kid in a lot of engineers. People are building side projects because they can finally make the thing in their head without spending three weekends just getting the scaffolding right. They are automating small annoyances in their lives. They are prototyping games, tools, agents, workflows, dashboards, weird little experiments that would have been too expensive to justify a year ago. The gap between idea and artifact has collapsed, and that collapse is intoxicating.
I think that is mostly wonderful.
There is a specific kind of joy in realizing that your imagination has more surface area now. A thing you used to file away as "maybe someday" can be real by dinner. A weekend thought can become a working prototype. A conversation can become a branch. The craft has not disappeared. If anything, the craft has moved upstream into taste, judgment, sequencing, and the ability to see what is worth making. But the loop is faster, and faster loops create more sparks.
The problem is that engineers are using the same muscles for all of it.
And maybe the muscle itself has changed. A lot of the work AI accelerates is the work that used to give the day some rhythm: writing the first pass, chasing the obvious bug, tidying the module, moving through a problem with your hands. That work was still work, but it often lived in a more mechanical register. It gave the mind somewhere to go after the harder parts: understanding the user, framing the opportunity, deciding what matters, holding the business case and the human need in the same picture.
Those are not lighter activities than coding. They are heavier. Taste, judgment, empathy, sequencing, and decision-making are some of the most cognitively expensive things an engineer does. AI has made them more central, which is good. It has also concentrated more of the day around them, which means the work can feel more alive and more draining at the same time.
The muscle that designs a production system is not exactly the same as the one that makes a toy app on a Saturday night, but it is close enough. The same attention, the same abstraction, the same pattern matching, the same debugging instinct, the same little background process that keeps asking, "what if I tried it this way?" For a long time, many engineers used that muscle for something like eight hours a day, five days a week. That was already a lot.
Now the day can look different. Eight hours at work. Then a side project because the new tool is too interesting not to try. Then a late-night rabbit hole because somebody posted a demo that changes how you think about agents. Then a weekend experiment because the idea has been sitting in your head and now it finally feels reachable.
Nothing in that list is obviously bad. That is what makes it hard to notice. It does not feel like overwork while it is happening. It feels like curiosity. It feels like momentum. It feels like being part of the future while it is still being assembled.
There is also a quiet pressure underneath it now. The field is moving fast enough that stepping away can feel expensive. A week of rest can feel like a week of tools you did not try, patterns you did not absorb, and people shipping things you now have to catch up to. Even when the body is away from the keyboard, some background process can keep running, measuring what might be slipping past.
But a muscle does not care whether you are lifting for work or for fun. Use it hard enough, often enough, without recovery, and it starts to fatigue.
For me, that fatigue did not show up as a dramatic collapse. It showed up as fog. It showed up as the absence of the normal spark. It showed up as rereading the same thing more times than I should have needed to. It showed up as a small resistance to starting, even on work I cared about. It showed up as the unsettling feeling that the thing that usually gives me energy was asking for energy I did not have.
I do not want to overstate that into a diagnosis. I am not a clinician, and a blog post should not pretend to be one. But I do think engineers need a better vocabulary for the early signs. Burnout is not always a person dramatically quitting or declaring that they hate the job. Sometimes it is quieter. Fog. Irritability. Shallow attention. A lower tolerance for ambiguity. Trouble starting. A strange flatness around technology that would normally make you curious. Losing the joy before you lose the ability.
That last one feels important. In this moment, curiosity is one of the most valuable things an engineer has. Not because every new tool deserves attention, but because the field is changing quickly enough that the people who stay curious will see leverage before the people who are only compliant. If we burn out that curiosity, we are not just hurting individual engineers. We are damaging the very thing that makes this era productive.
So the question is not how to make engineers less excited. I do not want that. I do not want a culture where the correct response to a new capability is professional distance. Some of the best work comes from people getting obsessed for a minute. Some of the most useful ideas enter through side projects and experiments that did not ask permission first.
The question is how to protect the excitement from becoming extraction.
I do not think there is one neat answer. I am suspicious of any burnout essay that ends with a tidy checklist, because the real problem is usually cultural, personal, and structural at the same time. But I do think there are patterns worth talking about.
Rest has to be treated as part of the creative loop, not time away from it. The mind that makes good software is still a body. It needs boring recovery. Walks, sleep, meals without a screen, time where nothing is being optimized. That can sound embarrassingly basic until you notice how many smart people behave as if their brain is exempt from physiology. In this moment, rest is not the opposite of ambition. It may be the only counterweight strong enough to protect the judgment, curiosity, and taste that make ambition useful.
Play also needs to stay play. A side project can be energizing because nobody is waiting on it, nobody is scoring it, and it does not need to become a product. The moment every experiment becomes potential output, curiosity starts wearing a uniform. One of the healthiest things an engineer can do right now might be to build something deliberately unshippable. No roadmap. No users. No announcement. Just a little private proof that the imagination still belongs to you.
Teams need language for load before the load turns into failure. "I am cooked" should be useful signal, not weakness. If an engineer says they are foggy, flat, or out of spark, the answer cannot always be another planning meeting about how to push through. Sometimes the right response is to move the shape of the work: more writing, less implementation; more review, less invention; more product thinking, less debugging; a real day away from the machine.
And maybe most importantly, we need to separate pace from aliveness. A fast team is not necessarily an alive team. A team can ship constantly and still be draining itself. The better measure is whether people still have access to judgment, taste, humor, and curiosity after the sprint is over. If the answer is no, the velocity is borrowing from somewhere.
Engineering is feeling this first because AI landed here first. But I doubt it stays here. The same pattern is coming for other trades and industries as these tools get better: more leverage, more creative surface area, more people realizing they can make things that used to require whole teams. That will be exciting. It will also ask more of the same human systems that already get tired.
I still think this is an extraordinary time to build. I still want the demos, the side projects, the strange weekend experiments, the feeling that the edge of the field is close enough to touch. I just think we have to learn how to hold that wonder without letting it consume the people who feel it most.
That is the conversation I want more engineers, managers, founders, and teams to have now, while the energy is still high. Not because the moment is bad. Because it is good enough to be worth protecting.
