Is this sustainable?

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 disappeared, but strategy and vision work. I'm shaping direction across multiple workstreams simultaneously, in a way I couldn't have three years ago, and AI tools make that possible because I can context-switch between drafts more fluidly. I can work on a few problems at once and produce coherent thinking on each, which used to require sequencing.

So the role expanded in two directions at the same time. More hands-on engineering and more strategic writing, alongside more meetings as I get pulled into conversations as the SME on GenAI in developer experience and tooling across the org. Logically this shouldn't be possible. The week is the same length it was three years ago.

What gave way is the human-focused work. Mentoring is the clearest example. I have less time for 1-2-1s than I did three years ago, and that isn't an accident, it's a choice I've made under pressure. The 1-2-1 work doesn't benefit from AI tooling. You can't backload it. It requires dedicated time and attention, and when the other parts of the role are expanding to consume the available hours, the mentoring is the first thing to go. I'm not relieved about this and I think it's a real problem, both for me and for the engineers I should be developing. The pattern is the same shape as the alignment problem in the previous section: AI made the technical work cheaper, and the human work, the mentoring, the alignment, the problem definition, became disproportionately expensive relative to everything else, and therefore got squeezed.

The other thing that gave way was thinking time. There's very little of it in my working day now. The productivity gains from AI got captured by output volume rather than output quality. The org's expectations rose to absorb the speed-up, and the slack that used to exist between tasks, the unstructured time where strategic thinking actually happens, got eaten first because it's invisible on a dashboard. I'm at a point in my career where thinking is supposed to be most of the job, and most of it now happens on holiday because the working week doesn't accommodate it.

The honest version of where I've landed is that the role isn't sustainable at this pace. The motivation right now is real, I'm learning constantly and the work has genuine impact, but the volume of what I'm being asked to deliver is rising faster than AI is making me capable of delivering it. The productivity story says we ship more because we're more productive. The lived version is that we ship more because expectations expanded by more than the productivity gain, and the gap is being made up in hours, attention, and the parts of the role that weren't supposed to be optional.

The depth I bet on

When I returned from five months of paternity leave in early 2024, the org needed someone at my level to lead GenAI work in developer experience and I was the available person. It wasn't a bet so much as an opportunity I recognised when it showed up. I took enough time to satisfy myself that this wave was different from previous hype cycles before I committed, but once I did, I had to drop most of the rest of my work on developer experience to make space for it. For a while I was the only engineer at any seniority dedicated to this, and the depth I built up happened by necessity as much as by design.

The upside has been real. I have a position in the industry that didn't exist three years ago and is currently scarce, and I get to partly shape how this technology lands at a 4,000-engineer organisation. The day-to-day work makes it harder to capitalise on that externally than I'd like, but the underlying career position is one I'm fortunate to be in, and I'm aware of that.

The downside is that I traded a lot of generalist depth to get here. Three years ago I had opinions across developer experience and infrastructure, with reasonable depth in languages and frameworks, including a decent grasp of Java Spring specifics I genuinely couldn't recall now. Does that matter? I'm not sure yet. Probably less than I'd have predicted, because the specifics are increasingly something I can recover from tools when I need them. But the breadth itself, the ability to hold strong opinions across multiple domains, has narrowed, and that has consequences I won't fully understand for a few more years.

The other downside is that the depth I've built is partly perishable. A lot of what I know about how to apply GenAI in an SDLC context will be obsolete within eighteen months because the tools and patterns are still moving fast. The generalist platform knowledge I used to have was more durable than what's replaced it. I'm betting that the organisational change experience, knowing how a large engineering org actually adopts new technology, who needs to be convinced, what the governance constraints mean in practice, will compound and stay valuable even when the specific tools and patterns age out. That's a defensible bet but it isn't a certain one.

And then there's the labelling problem. I'm now identified with one thing in a way I wasn't before. That's good for visibility and current career mobility, but labels become liabilities when the landscape shifts. The platform principals who got known as "the Docker person" or "the Kubernetes person" five years ago are now either grandfathered into their roles or carefully repositioning. I'm at the asset stage of that arc, but the liability stage exists too, and the work of managing the transition is something I'll have to think about deliberately rather than letting happen to me.

Scope expanded because the discipline expanded

The headline change in my role is scope, and it's the easiest one to misread. Three years ago, the initiatives I owned tended to be narrower and more contained. They might have been used across the organisation, but they were focused on one part of the SDLC and typically served tens of engineers a month. Now everything I work on is org-wide, used by all engineers, often every day. The scope is bigger by orders of magnitude.

The temptation is to attribute this to career progression, but that isn't really what happened. The scope expanded because developer experience as a discipline expanded underneath me. For years, DX was the worthy-but-overlooked function. The problems were real but absorbable, and we struggled to get the funding and time to fix them properly because the cost of leaving them broken was distributed and hard to measure. DORA and adoption metrics told us we were heading in the right direction, but they didn't make the case sharp enough to compete for serious investment against more obviously revenue-adjacent work.

AI changed the economics of that conversation. The same operational issues that were tolerable when humans were the only consumers of the platform stopped being tolerable when AI started magnifying them. A weak local development setup is annoying when an engineer hits it. The same weakness becomes a serious bottleneck when an agent is trying to operate on the codebase. The term "agent experience" is starting to emerge in the industry to describe this, and it's the right framing. The fixes we put in place for developers also serve agents, and agents scale in ways developers never could. A piece of internal platform that previously served 4,000 humans now potentially serves 4,000 humans plus an unbounded number of agent instances those humans deploy. The investment economics flip when you frame it that way, and the conversation moves from team-level prioritisation to board-level prioritisation almost overnight.

The uncomfortable bit is that this didn't happen because DX got better at making the case for itself. It happened because AI exposed how much the platform was already holding back. The discipline got its moment through external forcing, not through advocacy. That's humbling if you've spent years arguing for the work, and worth being honest about because it's what every DX organisation is now experiencing.

With the scope expansion comes the harder problem of justifying it. The org is asking me to demonstrate impact at board level, and the measurement apparatus to do that doesn't exist yet. DORA was built for a previous era. Adoption metrics tell you what people use, not whether the organisation is better off. We're inventing the measurement framework while running the programme, which is uncomfortable but unavoidable given how new the discipline is in its current form.

The downside of broader scope is the one I find sharpest, which is that the work becomes inherently credit-share. Narrow initiatives have clear ownership and visible wins. Org-wide programmes are political by nature, involve many stakeholders, and attribute success across multiple contributors. The trade-off is real: you exchange clear attribution for actual leverage on outcomes. I think it's worth it, but I won't pretend it's costless, and the senior engineers I see most frustrated right now are usually the ones who haven't fully made peace with this part of the deal.

What I think this means

I've been writing about my own role, but I don't think the pattern is unique to me. I'm at the sharpest end of it because GenAI is my specialism and the org has routed everything related to it through me, but the dynamics I'm describing generalise. Senior engineers in AI-forward orgs are doing more leveraged, more hands-on, more meeting-heavy work simultaneously, with the human-focused parts of the role paying for it. The build cost collapsed, the alignment cost rose, the thinking time disappeared, and the productivity gains got captured by output volume rather than output quality. I think what's hit senior roles first will land elsewhere as productivity expectations propagate through the rest of the org, and the version of this story that mid-level engineers will be writing in two years probably rhymes with mine.

We don't yet know what this means for engineering as a discipline, or for the people doing it. The honest version of what it feels like, from inside it, is paddling harder to stay ahead of an ever-increasing current. It works for now. It won't last forever.