Jamie Hurst's Blog - Is this sustainable?

Is this sustainable?

Posted on Sunday May 24, 2026

A lot of what's been written on this topic falls into one of two camps: the "AI made me 30% more productive" piece, usually written by someone six months into using the tools and often by a consultant who doesn't have a job to actually do, and the architectural piece about how AI changes the SDLC, which tends to be written from a vendor perspective and skips over the human reality. I'm interested in something else: what it's actually like to be a senior engineer in an org that's gone deep on this, three years in, and whether the shape of the role still makes sense.

We build before we think

The biggest change in how I work is the collapse of the gap between idea and demoable thing. Three years ago, if I had a meaningful proposal, the process was familiar: write a proposal, get feedback, iterate, build a small PoC to demonstrate value, get a team assigned to take it to MVP, ship something fully featured and integrated with the rest of the platform six to twelve months later. I ran an initiative like this in 2023 to bootstrap a new style of service creation across our developer platform. It took about a year from first conversation to MVP, with maybe three months of that on the proposal and alignment work before any engineering started.

Now I work very differently. A recent example: there's a bottleneck emerging in our SDLC around merge request review, and a few teams have built homegrown bots to address it, none of which solve the actual problem at scale. I wrote a thin proposal and a working PoC together, demoed both within a couple of weeks, and used the demo to drive the conversation about what the solution should look like. We're now consolidating the existing efforts into something cohesive, far quicker than the old process would have allowed.

Most of this is good. The slide deck has largely disappeared from my workflow and I don't miss it. Slide decks were often a forcing function for clarity, but they were also a place where we buried detail to make things digestible, and the PoC-as-proposal model exposes more of the thinking earlier. Stakeholders increasingly want to see how something works in a concrete context rather than read a theoretical case for it, and that's a healthier place to have the conversation.

But the trade is real, and I don't think the industry is being honest about it. The cost of building has collapsed, but the cost of aligning organisationally has not. If anything, it's gone up. When three different teams can each produce a working solution to the same problem in the time it used to take to write a proposal, the bottleneck moves from engineering to coordination. The MR review situation is a good example: it's now easier to build a new bot than to adopt someone else's, which means cohesion gets harder to achieve, not easier. We're solving more problems, faster, and the org-level alignment work is paying the price.

There's a related point worth making, which is that this shift advantages people who can build fast with AI tools and disadvantages people who can't. The bias to action is genuine, but it isn't neutral. The engineers who've adopted these tools effectively get heard more often, get their proposals taken seriously more often, and shape direction more than those who haven't. That's a skills redistribution happening inside every AI-forward org right now, and most of us aren't talking about it openly.

The senior role got more powerful and less sustainable

The counterintuitive thing I'd report from three years in is that AI landed on senior roles earlier than it landed on junior ones. The standard narrative is that AI threatens entry-level engineers and elevates senior ones into pure strategy. My experience is closer to the opposite, and I think it's because senior engineers are the people positioned to recognise where AI can apply across the SDLC, write the proposals, navigate the org, and now also build the thing themselves. The work that used to need a team now sometimes needs one person with the right tools, and that person tends to be senior because seniority is where the system-level understanding lives.

The result, in my case, is that I code more than I have in years. Three years ago I coded maybe once a fortnight, mostly throwaway PoCs to demonstrate concepts. Now I code most days of the week, in between other work. The kind of code is different too. It used to be isolated demos. Now it's PoCs that I'm genuinely comfortable throwing away once they've answered the question, and some integration work at the platform level that previously would have required a dedicated chunk of time I couldn't carve out. The disposability matters. When PoCs are cheap, you can investigate three approaches in the time it used to take to investigate one, and that changes how you understand problems.

At the same time, the writing load went up. Not tactical writing, that's mostly...