The silicon-saturated halls of major tech firms are currently witnessing a profound shift that goes beyond simple automation; it is a fundamental transformation of the software engineering identity. As the industry dives headfirst into a “tokenmaxxing” frenzy, where the volume of AI-generated output is prioritized over architectural integrity, a painful divide has emerged within engineering teams. On one side are those utilizing tools to generate massive amounts of code with minimal engagement, and on the other are the “craftsmen”—experienced developers who now shoulder the crushing burden of validating and fixing this machine-generated sprawl. Anand Naidu, a seasoned full-stack expert, joins us to discuss why this era of “botsitting” is leading to an identity crisis that some describe as bordering on clinical depression, as the traditional art of coding is replaced by a relentless cycle of review and maintenance.
Experienced developers often find themselves spending more time reviewing machine-generated code than writing their own. How does this shift from creator to validator change the day-to-day experience and mental load for a senior engineer?
The transition from being a creator to a mere validator is creating a phenomenon often called “botsitting,” and it is fundamentally exhausting for anyone who truly loves the architecture of software. In the past, the mental load was focused on solving complex problems and finding elegant ways to structure logic, but now, that energy is redirected toward catching the subtle, hallucinated errors of an AI. Instead of the sensory satisfaction of typing out a clean function, many of us spend our entire day buried under a mountain of pull requests, feeling the weight of a code review process that never seems to end. This shift turns the workday into a defensive struggle where the engineer acts as a human safety net, desperately trying to prevent bugs from slipping into production because the machine doesn’t understand the “why” behind the code. It is a tedious, high-stakes game of spot-the-difference that leaves even the most resilient craftsmen feeling drained by the end of a shift.
A significant divide seems to be forming between what are being called “lazy” engineers and the traditional “craftsmen” who fix the results. What are the long-term implications of this “tokenmaxxing” culture on team dynamics and code quality?
The rise of “tokenmaxxing”—the practice of maximizing AI-generated output just because it is easy—is creating a toxic imbalance that could permanently damage team morale. In this new environment, you have “lazy” workers who lean heavily on AI to answer questions and prepare updates without deeply engaging with the material, which creates an enormous amount of “AI sprawl.” This sprawl isn’t just extra code; it is a growing volume of work that requires constant supervision, and that entire burden of understanding falls squarely on the shoulders of the craftsmen. We are seeing a talent variance where those who generate the most output are often the ones contributing the least to the long-term stability of the product, leaving the veteran engineers tired, very tired, and increasingly resentful. If companies continue to reward sheer volume over the careful, manual validation of work, we risk a future where the actual knowledge of how a system works is lost entirely, buried under layers of machine-generated noise.
The idea of an “identity crisis bordering on depression” among software engineers is a stark observation. Why do you think the automation of coding feels so personally devastating to those who have spent years honing their skills?
For a professional who has spent a decade or more mastering the nuances of various languages, seeing their life’s skill suddenly framed as “no longer useful” is a traumatic experience. Coding was never just about getting a result; it was a craft involving logic, creativity, and a specific kind of digital craftsmanship that many of us took immense pride in. When that craft is declared “dead” by the industry, it triggers a deep sense of professional grief because our value is being redefined from innovators to mere supervisors of an unpredictable machine. There is a palpable sadness in realizing that the parts of the job you loved most are being phased out in favor of managing multiple AI tools and duplicating work in a frantic race for productivity. This crisis of identity occurs because when you remove the act of creation from the engineer, you take away the very thing that made them passionate about the field in the first place.
Large organizations that are 10 or more years old seem to struggle the most with this transition to AI-assisted development. What specific challenges do these established companies face when AI-generated output grows faster than their ability to evaluate it?
Older, more established companies face a unique set of hurdles because they often have a much higher variance in talent and a massive amount of legacy infrastructure that AI tools don’t fully comprehend. In these 10-plus-year-old organizations, the volume of AI-generated code is growing at a rate that far outpaces the team’s ability to actually evaluate and integrate it safely. This creates a bottleneck where the senior staff, who are already stretched thin, find themselves drowning in machine-generated pull requests that they simply don’t have the time to audit properly. Because these organizations have complex, interconnected systems, a single bug slipping into production through an unvetted AI update can cause a chain reaction of failures that are incredibly difficult to untangle. The result is a state of “AI sprawl” where the company feels like it is moving faster, but in reality, it is just generating more technical debt that will eventually have to be paid by the increasingly exhausted craftsmen.
What is your forecast for the future of the “craftsman” in an industry increasingly dominated by rapid, AI-driven code generation?
I believe we are heading toward a “Great Coding Reset” where the industry will eventually realize that the current obsession with speed and volume is unsustainable without a core group of people who truly understand the underlying mechanics of the software. My forecast is that while the “lazy” approach may thrive in the short term, the companies that survive the next decade will be those that find a way to protect and re-empower the craftsman, shifting their role from “botsitting” to high-level system orchestration. However, in the immediate future, we will likely see a continued period of friction and burnout as engineers struggle to find their place in a world where their traditional skills are undervalued. Ultimately, the craftsman will not disappear, but they will have to become the guardians of quality in an ocean of machine-generated mediocrity, ensuring that the human element of understanding remains the final authority in software development.
