AI brain fry
Hear ye, hear ye! At last, there’s a word for what everyone has been vaguely feeling for months, to varying degrees: AI brain fry.
Even though you’re supposed to be juggling 5 refactorings and 5 features at the same time, you end up half-heartedly pushing one forward and getting stuck on Instagram while waiting for the LLM to hand things back to you. A slight feeling of disgust at the end of the day.
Does this sound familiar? Rest assured, you’re human, and you’re tired.
As we come to grips with the possibilities offered by LLMs, the very nature of a developer’s work is changing—something I touched on in a recent article titled “You’re a Manager Now, Whether You Like It or Not.” Some predict that software development will soon consist of running 10 agents in parallel on different topics, then validating the results with a single glance. In reality, we’re not there yet, because humans remain the limiting factor.
Reviewing that much code is exhausting, because each time you have to immerse yourself in a logic that isn’t your own. Some might say it’s easier to react (criticize code) than to act (write code), yet I’ve noticed that few people are eager to review 20 pull requests a day.
And then there’s context switching. Everyone knows how difficult it is to carve out blocks of deep work time, especially when you’re in a role that falls somewhere between individual contribution and team management (e.g., Lead Developer). Context switching when you’re juggling 10 projects at once is simply not possible.
Next, we need to address the myth of productivity. We all know from experience that rest is essential to creativity, and neuroscience confirms this. It’s often when your gaze wanders into the distance without actively thinking about the subject that the best ideas spring to mind. And when, occasionally, a window of intense creativity opens up for you for three or four days, it’s not uncommon to feel the aftereffects in the days that follow. Such productivity can therefore only be fleeting; our brains need rest.
But, more fundamentally, it’s the very nature of the work that’s at stake. The value of an experienced developer lies in their ability to switch between the microscopic (the line of code) and the macroscopic (the architecture—at the codebase level, but also the organization). In one sense, this is the ability to translate a simple idea into functional software; in another, it is the realization that a single detail can change everything—or even compromise everything. This knowledge is acquired through experience. That is why certain high-stakes decisions should only be made by those who are actively involved in development—what Vincent Lextrait calls “mentofacturing.”
This intertwining of the macroscopic and the microscopic represents, in my view, a significant limitation of LLM-assisted development. If you care about quality, you must stay engaged with the code and likely write certain very specific parts yourself (because they’re critical or to serve as examples for the LLM). A recent example: an algorithm for executing buy/sell orders in the markets.
As for me, I don’t know how to do that on 10 topics at the same time.