At the start of 2026, my working day looked roughly as it had done for the past couple of decades. I would open my IDE in the morning, and close it in the evening, and in between I would write code by typing it into a window designed for that purpose. Carefully and diligently, always trying to envisage myself as a journeyman stonecutter whose work would ultimately be part of some great cathedral of code.
My days don’t look so much like that anymore. I am spending less and less time in the IDE. My work now generally takes place in a terminal window, or rather in half a dozen terminal windows at once, tessellated across my Studio Display like the control room of a faintly ridiculous spacecraft. There is still code being written, and quite a lot of it, but my own fingers are producing very little of it directly these days. I find myself doing something else. I’m thinking. Reviewing. Directing. Steering and correcting.
This is a larger shift than it first appeared to be, and I have spent recent weeks trying to figure out what exactly has changed. Not in the tooling, which is well-documented elsewhere, but in the shape of the work. This post is my attempt at that reckoning, as it appears to me in the middle of April 2026. Some of what has changed is straightforwardly good. Some of it is more complicated. And there are inevitable implications for the profession that aren’t being talked about clearly enough.
Breaking Out of the IDE
The first and most obvious change is geographic. I’ve moved house.
For most of my career, the IDE was the natural centre of gravity for development work. Visual Studio, NetBeans, IntelliJ, and so on. It was where you read, wrote, and debugged code, navigated between files, ran tests, and probably where you interacted with version control, and perhaps a database. The terminal was a secondary surface, something you dropped into for the occasional shell command or to run a build that the IDE couldn’t quite handle gracefully. The browser was for Stack Overflow and testing deployed applications. But the IDE was home.
Agentic coding inverts that relationship. Now the terminal becomes the primary surface, because that’s where the composition happens — where you can pipe one tool into another, run things in parallel, orchestrate work across multiple repositories and contexts without the IDE’s assumption that you’re generally focused on a small number of files at a time. The IDE is now mostly somewhere I go to look at something an agent has produced for me, not somewhere that I originate the work. It’s a read-only view onto the results of work that happens elsewhere. I find myself eyeing my upcoming JetBrains renewal with something close to suspicion.
The consequence is a shift in what I spend my time thinking about. For years my typing speed was a limiter on my output. A piece of work was as large as I could hold in my head while my hands worked through it. Refactors were as ambitious as I was prepared to execute keystroke by keystroke, accelerated somewhat by tooling like Resharper. Until very recently, I cheerily advocated pair-programming or mobbing — one person thinking ahead while another drove.
That limiter has gone now, and the thing I’ve discovered in its absence is that I spend considerably more time thinking about the shape of what I’m building. What are the right abstractions? What’s the cleanest seam between these two services? Is this really the problem we should be solving, or is there a better solution sitting just a little further along, or to the side of it? Where are we really trying to get to? These were always questions I cared about, but they competed with the unromantic business of getting the code actually typed. Now they don’t have to compete anymore. The writing takes care of itself, more or less, and the thinking expands to fill the space.
The Constraints That Quietly Dissolved
The second thing that’s changed has happened by subtraction. Some of the constraints that I had taken as being permanent features of my working life have simply stopped being constraints.
Firstly, the invisible fence between backend and frontend. I’ve always described myself as a backend developer, and been a bit sceptical of the term “full-stack developer”, muttering darkly about jacks of all trades. I shied away from frontend work, not because I was incapable, but because the activation energy for picking up another modern frontend framework well enough to be as productive as I wanted had always felt prohibitive. There was always TypeScript’s evolution to keep current with, and whichever of React, Vue, Angular or Knockout was fashionable this year (or happened to be chosen by my current client). CSS evolved past what I’d learned, and the surrounding galaxy of build tools and popular NPM packages turned over every few months. Easier, I figured, to stay on my side of the fence, where the problems were familiar and the paradigms stable. In a large enough enterprise there would always be some smart young things only too happy to put a shiny front on my well-architected, scalable and performant distributed backend.
But now that fence has gone. Not because I’ve suddenly learned the syntax of all these frontend frameworks, but because the cost of working in an unfamiliar area has collapsed to something like the cost of working in a familiar one. I describe what I want, I review what’s produced, I ask questions when something looks wrong. It’s no different to the Tech Lead or Tech Architect roles that I have held, reviewing and coordinating a team of workers who output deliverables in languages where I am not a syntax expert. The asymmetry between “the stack I know well” and “the stack I don’t” has narrowed to the point where the label “backend developer” feels like a ridiculous distinction, like a pianist who still insists on only playing the white keys.
The same thing has happened with unfamiliar codebases. There used to be a period of getting up to speed with a new system — days or weeks of reading, talking to colleagues, running up a local environment and seeing what broke, before you’d built enough of a mental model to be able to contribute usefully. That hasn’t quite gone to zero, but it’s collapsed considerably. You can have a conversation with an unfamiliar codebase now, in a way that simply wasn’t possible this time a year ago, and that conversation gets you to productivity faster than reading someone else’s opinion of what you might want to know ever did.
But the constraint whose dissolution has surprised me the most is that of the tradeoff between competing kinds of work. In most projects I’ve worked on there’s a near-permanent tension between shipping new features, fixing bugs, and paying down technical debt. You can do some of each, but the delivery pressure inevitably pulls relentlessly towards the features, and the bugs and the debt get whatever attention you can smuggle past the roadmap. Each increment becomes a small negotiation about what you’re not going to do, because there’s never enough capacity to do it all.
I think this tradeoff has partially dissolved. Not entirely — the economics of teams still matter, and not every kind of work parallelises cleanly. But it’s no longer the zero-sum game it used to be. A small team (or, in my current case, one guy and a handful of concurrent agent sessions) can genuinely work on multiple threads at once. The Monday-morning question of “what’s the single most important thing to work on today?” has been replaced by something more like “what feature should I ship next, while other agents simultaneously run to fix bugs / add tests / eradicate tech debt?” It’s a different kind of decision, and it’s changing the character of my week.
Of course, orchestrating three things poorly is worse than doing one thing well. But when an agent can be left alone to crack on with a long-running improvement, it removes that sense that every choice is an either/or — that time spent reducing tech debt is time stolen from features. I find myself orchestrating improvements to codebases that I simply could not justify if it were necessary for a human developer to painstakingly make the changes keystroke by keystroke.
The Virtuous Documentation Circle
Another pleasing and slightly unexpected side effect to all of this agentic development is that the artefacts of my work - the commit messages, the PR descriptions, the README.md files, the Swagger docs, the GitHub issues - have become much richer and more useful than they used to be.
This is not because I’ve suddenly become a more diligent person. I’m every bit as lazy as I was at the start of the year. It’s because the cost of producing decent documentation has collapsed. Writing a proper PR description used to take some effort - five or ten minutes at the end of a tiring piece of work, when all you really wanted to do was hit the merge button, toss it over the wall to QA and move on. Now it costs nothing, because it can be produced as naturally as the code itself, to a consistent standard.
But the really interesting thing is what this does over time. Those artefacts aren’t just output for consumption by your fellow human team-mates; they’re a rich source of input context for future agentic sessions. A well-written README becomes context for the next piece of work on that codebase. A detailed GitHub issue becomes the starting point for an implementation session that might not happen until weeks later. A thorough commit history makes it easier for an agent to understand why a particular decision was made. Every bit of documentation produced today makes tomorrow’s work easier, which in turn produces better documentation, which makes the day after easier still.
This is a virtuous circle - a self-reinforcing loop that improves the system over time. I’m seeing the codebases that I work on become progressively easier to work with because the ambient quality of the documentation has been steadily rising. That’s a form of technical debt repayment that’s essentially free, and it compounds marvellously. The failure mode, which I’m watching for, is documentation that looks thorough but isn’t — agent-generated context feeding into the next agent’s context, with nobody in the loop checking whether any of it is still true. So far the discipline of actually reading the PR descriptions before merging has been enough. Ask me again in six months.
A Redistribution, Not a Levelling
So far I’ve been describing what has changed for me, the changing nature of my day-to-day work in my current role. I feel unshackled. Some of the key constraints that have limited my productivity for much of my career have melted away. But considering the impact on the whole industry, I think there’s something large going on. Much of the conversation about agentic coding still tends toward one of two unhelpful poles. On one hand we have the evangelists for whom this is a democratisation, a great levelling, the end to the priesthood of software development. Now anyone can ship software! On the other hand, we have the sceptics, for whom this is a threat to the profession, a commoditisation of the craft, the thin end of a wedge that ends in mass displacement.
Neither description quite matches what I’m seeing. What’s actually happening, I think, is a redistribution rather than a levelling. The profession is being reshaped by three things at once, and they don’t all move in the same direction.
Basic technical capability has become broadly accessible. Many tasks which previously required esoteric and arcane knowledge are now within reach of anyone prepared to think clearly about what they want. The intermediate plateau of competence - the dev who knows their primary stack well but has been intimidated by the adjacent ones - has effectively disappeared. People can now produce working software across a much broader range of technologies than they could before. That’s real democratisation, real mobility, and it’s a good thing.
At the same time, the skills that resist commoditisation - knowing what to build, knowing what good architecture looks like, recognising when some plausible-looking output is in fact wrong, decomposing big problems so that agents can execute on them effectively, constructing the guardrails that let you trust the output - those skills have become more valuable, not less. The force multiplier on them has grown. A senior developer or solution architect with good judgement now multiplies that judgement across a volume of output that would have been unthinkable this time last year. The gap between someone who knows what they’re doing and someone who merely appears to hasn’t narrowed; it’s widened.
Which leaves the broad category of competent professionals — the mid-level developers who have been the backbone of most teams I’ve worked in — in what looks to me like the least defensible position of the three. The things that used to distinguish a mid-level dev from a junior (broad familiarity, willingness to dive into unfamiliar code, the ability to produce reasonable boilerplate output following a pre-existing pattern without fuss) are precisely the skills that are being commoditised the fastest. Not obsoleted, necessarily, but no longer the differentiator they once were. I don’t say this with any relish. I’ve worked with a lot of excellent mid-level developers, and the honest answer is that I’m not sure what the path forward looks like for someone two or three years into the trade right now.
Agentic coding gives a great deal — fearlessness across unfamiliar territory, the collapse of old tradeoffs, the virtuous loops of documentation and tooling. But it demands something in return, and what it demands is taste. Judgement. The willingness to take responsibility for what the agents produce, to know when they’ve wandered off the path, to hold opinions about how the software should be structured that aren’t just rubber-stamps of whatever the model suggests. Fearlessness without judgement isn’t courage; it’s recklessness. The developers who thrive in the coming years will, I suspect, be the ones who’ve understood that their professional identity now rests on the judgement, not on the stack knowledge.
This is good news for developers who’ve been in the trade a while. Taste and judgement are acquired slowly, mostly through years of getting things wrong, and they don’t have a shortcut. They’re the things the industry has historically struggled to reward, because they’re hard to measure and harder still to interview for. They’re going to matter more now, because they’re increasingly what we’re actually being paid for. I’m aware this is a conveniently flattering conclusion for someone at my stage of career, and I hold it with appropriate wariness. It’s possible the models get good enough at architectural judgement fast enough that this moat narrows too. But that’s not the bet I’m making.
Choreographing the Dance
Years ago, on an old episode of .NET Rocks that I remember more clearly than I probably should, Bob Martin described a programmer as becoming a “choreographer of a dance of code as it’s flinging around the system, becoming better organised and better structured”. In 2008 this metaphor felt aspirational rather than descriptive. Most of us were very much performing the dance. But in recent months, Martin’s metaphor has become quite literal. I spend my days now arranging the movements of a cast of agents: setting up the stage, giving the instructions, reviewing the performance, making corrections. The code still gets written, but not by me. I am entirely responsible for it, but no longer its immediate author. I have become the choreographer.
Whether this is a good or a bad thing depends, I suspect, on how much you enjoyed the typing. The slow chipping away at blocks of stone that might one day fit together to form a mighty gothic cathedral. I think I did enjoy it, mostly, and I don’t want to dismiss that craftsmanship out of hand. But I enjoy the thinking more. And the thinking is what’s left, now that the typing has gone.
That’s what agentic coding gives me. What it demands in return is that I be worth the leverage that it provides.
A companion post will follow in a few days, turning from the reflection above to the practical side of agentic development — the workflows, the tooling, the concrete habits that have made this way of working actually work for me. If you’ve read this far and found yourself wanting the mechanics rather than the philosophy, that’s where they’ll be.