
Maintaining Excellence as a Software Engineer
As a person who works in software engineering, I feel well-placed to say that AI, and specifically, LLM-driven coding agents, have made for a wild past few years. The amount and pace of technological change have been unlike anything I've ever experienced in my career. I'm not even sure "career" is the appropriate time horizon– maybe "life". The only thing that even gets close to being in the family photo is home internet, but the rate of progress there compared to LLMs was straight-up, glacial. All that to say, in engineering, everything seems to have changed and we aren't going back. Nor do I think we should. But in the midst of all the change, and all the speed and all the hype, something quite important has changed and if engineers aren't careful, we might just find ourselves sacrificing our future careers (and minds) to go faster today
Being good matters
When AI coding really got big, there was a narrative that the playing field had been leveled. That is, being an expert engineer didn't matter anymore and coding had been "solved". The opposite ended up being true. The field has tilted even more toward senior engineers. Instead of the gap between novices and experts closing, it's widening. Managing coding agents well, in service of producing quality software, takes expertise and judgement, both of which derive from skill and experience.
How engineers got good
Before LLMs came along (remember what that was like!?!), getting better at engineering largely looked like this:
- Encounter a difficult challenge that is beyond current skill level
- Feel confused for a non-trivial amount of time while thinking about the problem
- Explore the problem and really work to understand it. Research concepts. Try solutions. Fail a lot. Go to sleep thinking about the problem. Wake up thinking about the problem. Lose sleep thinking about the problem
- Finally, arrive at a solution The problem gets solved and the engineer has gained skill and experience. You showed up to work and you got better. The formula of growth hidden in that process is:
Time spent, proximity to the problem being solved and cognitive strain determine growth
LLMs changed the inputs to the equation
Agentic coding changes the math. We spend far less time on individual problems. This is one of the biggest selling points made about AI engineering: get things done a lot faster. LLMs have also moved us farther away from the problem we're working on. Our team now has an agent that plans and writes much of our code. Alerts in Slack about an issue on the backend? Claude will research and propose a root cause (and maybe write the code to fix it). The problems have been abstracted away. We simply observe and manage the agents and systems that are close to the problems. Finally, we don't need to stretch as far mentally to find solutions to the hard problems. We just have to make sure the model has access to the right context and is "listening" to the right triggers. We aren't going as deep as we used to. Instead we go wide.
The bottom line is, we don't get better simply by showing up to work anymore.
The manager's paradox
This is certainly not a new problem. In software engineering, and almost all knowledge work, we've seen this type of problem before with managers. Here's how "the manager's paradox" goes: someone is good at their job, so we make them a manager. They end up being a good manager, in no small part because of their skill and judgement in the domain they are now managing. But, they're no longer growing that skill, so over time it erodes and they become a worse manager. This feels like an especially relevant example, given that it seems like most engineers are being promoted to "agent managers".
Skill growth requires intention
So, we now find ourselves in the middle of the agent paradox. The skills that make people good at managing agents and producing good work efficiently are the very skills that atrophy when we do it. It's no longer enough to show up as a software engineer and assume you'll simply get better. Growth requires intention and discipline. Maintaining expertise and judgement is critical to the future careers of software engineers–and more importantly, growth and cognitive fitness are required for human thriving and well-being.
An unclear future
One thing that is clear to me: it's incredibly unclear where this is all headed. If you had told me two years ago, that my entire org would be managing multiple agents writing our code, I would've slow-blinked you back into whatever crazy time-traveling machine you came from. Yet, that's becoming the norm. As I write this, Fable is finishing up a migration we've long struggled with. Things seem to be moving quickly and in directions that are hard to plan for. However, investing in judgement and expertise is a strong hedge, wherever we end up as engineers. I'll share a bit more about how my team and I do that in an upcoming post.
Maintaining expertise and judgement is critical to the future careers of software engineers–and more importantly, growth and cognitive fitness are required for human thriving and well-being.
Related Posts
My AI Toolkit (Dec 2025)
The AI tools I’m using in my day-to-day as of December 2025. It’s been a wild year in terms of available tools and their levels of efficacy and sophistication. Now seems like a good time to reflect on my current usage.
Balancing Thinking with Agentic Coding
One of the most exciting things about agentic coding is the ability to move quickly. One of the biggest dangers of agentic coding is the ability to move quickly. One of the most important problems to solve right now is finding the balance between speed and learning.
How I'm Coding These Days
The coding scene changed a lot in 2025. As the year comes towards its conclusion, I have thoughts and reflections on my journey as a software engineer and how I'm currently leveraging AI in my day-to-day