Hello again, everyone!
It has been really interesting to see how LLM toolchains have evolved from simple image creators to suites of agents swarming over a set of Markdown files that outline a goal. We have seen vibe coding, tokenmaxxing, open-claw, and MCP enter the lingua franca for systems integrators, builders, and customers. The amount of work that people can delegate to the machine layer is staggering, and if you told people in 2020 this would be possible, they would look at you as if you were some kind of insane crazy person.
Speaking of insane crazy people, there is also a lot of literature and science and common sense (are we calling it tradthink yet?) about how much you should be working and what people are experiencing.
“It is rotting your brain,” people say.
“You will never be able to write code again,” people say.
“The people at the frontier are burning themselves out,” people say.
I love coming online and examining each of these statements on their merits. I love to turn them over, this way and that, catching the odd glinting rays off of the sun and seeing their flaws and inconsistencies. I love to look up the speaker and understand the ulterior motive, because there almost always is one, for why they said what they said.
When I am finished enriching my understanding of their assembly of letters, numbers, and punctuation, I declare my own counter-edicts based on my own understanding, experience, and ulterior motives. We will fight fire with fire.
Let’s take LLM-supplemented software development. The average builder today using these tools is producing far more code than they did a year ago, but they are not doing it directly. They are directing tools to issue software, and they may be supplementing that with code reviews and the odd little piece of software here and there that is built by hand. This is the new normal.
If you were to compare that to a human role from 2020, the average software engineer is now doing essentially what their manager did just five short years ago. Understand the shape of the software, the rough high-level approach, and look for the intermittent “aha” that comes from years of experience scaling systems.
There is a subset of people who may have had this role before, or may be ready for this kind of responsibility and take it in stride. The average software developer who has gone through this transition in the past year or two is likely not ready for this kind of switch, and indeed, a good chunk of software developers are not even interested in it. This is one of the reasons why it is creating some burnout. Software developers as a career category have been upleveled wholesale to a software management job with LLM tools. It is a new skill set, and also being applied at an incredibly high rate across the whole software development ecosystem.
The expectation on converting to an LLM-supplemented engineer is that your output at least doubles, and in some cases goes up nearly an order of magnitude. That pressure also contributes to the burnout problem because people want to feel like they are being effective. This is where all of that “tokenmaxxing” nonsense comes in. You have to be driving these tools to do stuff around the clock, and while it is nice to believe these tools will work 24/7 without invoking some sort of union representative to require some level of breaks, they tend to mysteriously shut down or break at odd times. If this happens an hour after you went to scotch o’clock, you are in trouble. You have lost hours of potential work. This means you have some kind of obligation to check in after you have queued up some work to make sure it hasn’t gotten itself into a halt state.
There is one more piece of the puzzle to consider.
The cost of developing software with LLM tools has essentially gone to zero. Adding features can be nearly instantaneous and cost nearly zero dollars. This is a siren song because that means that people might just go and build software because it is cheap or free. That does not imply it is building essential features or valuable items to the platform. This is one of the most dangerous problems people have today. Back in the “old way” of software development, everyone had lots of time for ideas to sink in. They had plenty of days to sleep on feature requests and hold grooming sessions with the creators to make sure the value is captured in the tools and features being built.
In today’s world, it is far simpler to build everything. And that might include building stuff that has zero value, and perhaps items that have negative value. Very few people are strategically looking at the output and saying “we do not need this now” because it is cheap or free.
The problem is that they might make that statement at 11:15 AM. They will be adding features that have marginal value for the next five to nine hours afterwards. If you are as good at basic arithmetic as I am, you will note that this might put you in the twelve hours of work category.
In a world where people feel compelled to build around the clock, check in on late-night agent swarms, and are working at a higher career level than they did just months ago, often with zero new role calibration, is it any wonder that people are getting burned out?
So how can you fix this?
My own strategy is to book some thinking time every week. Make sure you are not prompting around the clock. When you have something that you need to build, think about it. Talk about it. Sing songs about it. Imagine what it looks like naked. Do anything but start building. Every moment you put into the thinking and imaging process, you are going to add value where it belongs, in the ideation layer.
If you feel like you are guilty about this, another thing to do is to do two concurrent projects at the same time that are reasonably distinct. I am always subconsciously grinding away on systems, user interfaces, and scaling problems for anything I am building. If I am building product A, and I also have plans for product B, I can think about product B while building product A or vice versa. Oddly, you might do similar amounts of work on just product A as you would with both product A and product B. You will feel less tired because it is not an overwhelming level of deep concentration on one thing, and you are bringing a fresh perspective to the table very often for each of the projects you are working on.
So if you are experiencing AI burnout, or have a friend who is experiencing AI burnout, this might help you find some balance or sanity in your life. Ensure you are not burning yourself out by going too deep into one thing and having time to think about the right thing to build. Make sure you are “zooming out” enough on the scope of your work, your career, and the habits you are practicing. Think about the gap between what your job used to be and what it is now, and spend time understanding that it is different.
Most importantly? Breathe. If you push too hard, you will get to diminishing returns. You should conduct your time like a symphony orchestra, and have time for the drums, the trumpets, the violins, as well as other instruments. By keeping up with a variety of different things, you will have fresh perspectives and have more time for “Aha” moments and bits of insight that will help spur innovation and new implementation ideas than if you just keep grinding away Sisyphus-style against your codebase.
Thank you for your time. If you wish to support my writing habit, and love to steal nickels from Jeff Bezos, consider supporting this habit with Amazon Affiliate Sponsored Links™! Today, John recommends you look at these two options for great wrist support over the course of your career. I use both a keyboard wrist wrest, as well as one for my mouse hand. I buy these 4-6 at a time because I have multiple computers and also have them handy for travel.
Talk to you all again soon!
