Work as I knew it changed completely for me this year. All those frameworks, languages and libraries I've learned and used over the past years combined are not even close to the scale of change in how I work as a software developer.
I always worked within small teams, which meant being very practical, writing lot of code. And I loved it. I enjoyed rearranging the characters, making the code more coherent, more readable, more usable. I enjoyed the struggle, the occasional frustration of not being able to resolve something in an hour and having to Google for an answer, reading up some documentation once more to find out something that I'm missing.
And when it finally clicked, the satisfaction followed. This was a lot of fun, and I enjoyed every single bit of it. Nowadays though, it's not part of my job anymore.
How the job looks like
I don't recall a single day this year in my day to day job that I manually wrote any code whatsoever. It's more about creating specs, and then test scenarios, setting up the data for them. I define these test scenarios in natural language, and then I just make sure they are generated as I intend.
What follows is relatively straightforward. Just let the AI agent run to implement the code that handles those cases, and that's it as far as the implementation goes. The implementation which took majority of the sprint now shrinks to minimum.
Solo projects vs. team work in an actual dev job
It was also this year that I was, for the first time in many years, able to pick any project outside my work and just finish it in like one or two weeks. And that was just a few hours each evening. Some of these projects could take weeks of free time without AI. Seeing these results is really amazing.
It's obviously different than working in a team and working with much bigger project, much bigger code base to which many people could contribute. The code and actual building got so cheap that anyone can push hundreds of lines of changes every single day. If you multiply it by the size of the team, you could easily see that there is not enough brain capacity for people to go through that amount of change, or even hold it in their heads.
Back to square one?
Part of the frustration is to keep up with the scale of change and the actual pace of these changes. If the FE hype cycles were crazy enough, the AI hype cycles and all the tooling, plugins, skills, and whatever else comes with, are on another level.
But I think more than that, which was always part of the job in some way or another, the struggle to keep up is partly caused by non-existent playbook within the dev teams. The bottleneck completely shifted. Yes, all those nice frameworks how to work within teams are still there, they simply didn't have a chance to evolve and adapt to a different reality.
There is no playbook, no method backed by relevant data, that would recommend optimal way to integrate AI into the workflow without producing huge bottlenecks and potentially burning people out. And no, adding more devs to this doesn't really help. All you end up with is adding more devs producing stuff at much faster pace with unresolved bottleneck.
It's simply changing, not a tragedy
We can either stay still, or adapt and try to figure something out. This is what we have always been doing. We found out different solutions.
Yes, the scale of change is immense. Yes, the job is not the same as it was before and that fun part for many devs is gone. So what are we gonna do about that?
If you found something in your work that feels like coding used to, tell me in the comments.
For a full version: https://youtu.be/yDYDoh1sWgo
Top comments (1)
The fatigue you are describing comes from an economic inversion. When the marginal cost of generating syntax falls toward zero, the entire bottleneck shifts to verification and liability.
On a traditional team, code review was bounded by the speed of human typing and thinking. With agents generating diffs, every developer effectively manages a small fleet of junior contributors pushing plausible pull requests. Reviewing plausible code is cognitively more taxing than writing it from scratch because you absorb all the downside risk of silent regressions with none of the creative satisfaction of building the abstraction. Adding more engineers just accelerates the volume of unverified diffs queueing at the review boundary.
Where I see teams regain control and satisfaction is shifting craftsmanship entirely into boundary invariants. Instead of skimming hundreds of generated lines to guess whether an edge case breaks, the work becomes designing property-based tests, strict schema contracts, and deterministic runtime assertions. If an invariant suite can reject invalid states automatically, you stop acting as a human linter and get back the agency of defining the system's actual rules.