One of the unintended consequences of writing is that articles occasionally leave you thinking about something you never meant to write about. That’s what happened after I finished the piece on AI-first engineering roles. I started that article with what I thought was a fairly narrow observation: the more of those job descriptions I read, the less they sounded like programming jobs. They certainly mentioned models, prompts and tooling, but underneath that they were asking for decomposition, judgment, ownership and coordination, the kinds of things I’d normally associate with architecture or technical leadership. I thought the interesting part was AI. The article said what I wanted it to say, I published it, and then it refused to leave my head.
That doesn’t happen very often. Usually, once something is published I’m already thinking about the next idea. This time I kept replaying parts of the article without really knowing why. I’d remember one of those job descriptions, and for reasons I couldn’t explain my mind would jump somewhere completely different, first to frameworks, then to cloud, and later to microservices. It didn’t make much sense. Those technologies solved different problems, belonged to different eras and were adopted for completely different reasons. Trying to connect them felt like the sort of pattern-seeking engineers are famous for. We build abstractions for a living, so we’re probably more willing than most people to believe that half a dozen unrelated things are secretly telling the same story. I spent a while assuming that was exactly what I was doing, but every time I convinced myself to let it go, another memory pulled me back.
Frameworks are probably the clearest example because I lived through that transition. What stayed with me wasn’t architecture, lifecycle management or dependency injection. Those came later. What I remember is the excitement of suddenly not having to solve the same problems over and over again. Boilerplate that everyone had quietly accepted as part of building software simply disappeared into the framework. Entire categories of work stopped being application concerns. It genuinely felt as though software had become easier to write because, in a very real sense, it had.
If you’d asked me back then what we’d all be discussing five years later, I don’t think architecture would have even crossed my mind. We certainly weren’t sitting around debating state management or arguing about where dependencies belonged. We were enjoying the fact that we could build more ambitious applications with less effort than before. That’s what everyone noticed.
The conversation changed so gradually that I don’t remember noticing it happen. One day the interesting discussions were about writing less code; a few years later they had shifted toward organizing increasingly capable applications, which meant talking about lifecycle, state, architecture, and the patterns that might hold all of it together. Looking back, it’s hard to imagine it unfolding any other way. At the time, though, it just felt like the conversation had gradually drifted somewhere else.
Cloud left me with almost exactly the same feeling, although it took me years to recognize it. I still remember how much of the conversation revolved around removing friction: provision infrastructure in minutes instead of weeks, stop waiting for hardware, stop filing tickets, just build something and keep moving. That wasn’t marketing hype; it actually happened. It’s difficult to explain to someone who didn’t live through it just how significant that shift felt.
What’s interesting isn’t that cloud eventually brought networking, identity, permissions, observability and operational ownership to the foreground. Those concerns had always existed somewhere. What interests me is how naturally our attention migrated there once provisioning infrastructure stopped being the thing slowing us down. Nobody collectively decided that observability was suddenly fascinating. We just found ourselves spending more and more time thinking about it because the previous bottleneck had quietly disappeared.
That memory was what made microservices harder to dismiss as another unrelated example. Independence was not an accidental side effect; it was the point. Teams were supposed to stop waiting on one another, own smaller pieces of the system, and release them on their own schedules. To a large extent, that worked. Giant coordinated deployments became less common, changes were easier to isolate, and a team could evolve its service without asking half the company for permission. For a while, it looked as though coordination had been reduced by designing much of it out of the release process.
What followed complicated that story. Once services could move separately, contracts and backward compatibility carried more weight. Ownership extended beyond writing and deploying code into operating it, observing it, and understanding how failure in one place affected everything around it. Platform teams emerged because every product team independently solving the same operational problems was not much of a victory. The original idea had worked; the difficult part had moved from coordinating releases to keeping separately evolving systems compatible.
That was where my explanation about scale stopped feeling sufficient. Larger systems undoubtedly create more complexity, but size alone did not explain why each improvement changed the kind of work demanding attention. The recurring thread was not simply that we kept building bigger things. Each breakthrough allowed more work to proceed without waiting for the rest of the system.
With frameworks, engineers could build larger portions of an application without recreating the same foundation each time. Cloud removed another dependency by letting teams acquire infrastructure without waiting on a separate provisioning process, and microservices carried that independence inside the system by allowing services, and the teams behind them, to evolve on different schedules. More recently, agents have made it possible for several lines of investigation or implementation to move at once, often with very little effort required to start any of them.
That independence is useful enough that nobody seriously wants to give it back. It also changes where attention has to go. Separately moving parts do not automatically share the same assumptions, and they do not remain aligned simply because they started from the same goal. Over time, they develop their own tribal logic, respond to the information available to them, and drift unless the surrounding system gives them a reason not to.
I had already seen that with teams and services, but working with multiple agents made it unusually visible. Generating work was rarely the difficult part. More than once I read an agent’s result, thought it was good, and only later realized it no longer fit the work developing around it. The problem was not that an agent had obviously failed. Its interpretation was reasonable, its assumptions made sense in isolation, and the result often looked finished. The trouble appeared when several of those individually convincing results had to coexist.
That was the connection I had been circling since the previous article. These technologies had little in common at the implementation level, but each made independent movement easier. I had been looking for a technical consequence they shared, which was probably why the connection took so long to see. There wasn’t one. Application architecture, cloud operations, service contracts and agent orchestration are different kinds of work. What repeated was the change in relationship between the parts: more of them could move without waiting, and shared assumptions became easier to lose.
I’m not convinced coordination is quite the right word for everything that followed, at least not in the way the word is usually used. Coordination sounds like meetings, planning and people waiting for other people. Much of this work is encoded into the system instead. A contract can preserve an assumption between services that release separately; observability can reveal behavior no team controls from one place. Even platform engineering and architecture began to look less like added process than attempts to decide where independent work could diverge and where it still had to meet.
The labels changed, but the concern underneath them felt increasingly similar. Once work could proceed independently, the results still needed enough shared context to remain compatible. That context might live in technical contracts, team ownership, or some awkward combination of the two, which may be why the work was so easy to mistake for overhead. It appeared after the breakthrough, when everyone expected the difficult part to have been removed.
That was the part I had missed while thinking about each technology on its own. I had treated what followed as a separate complication, almost as though engineering had failed to cash in on the productivity gain. But the gain was still there. We were building more, deploying more often, and allowing teams or systems to move with far less waiting than before. Maybe what I had been calling a complication was simply what it felt like to keep using that independence without losing track of where all of it was supposed to be going.
It also explains why software rarely feels permanently easier after a major breakthrough. The old friction disappears so completely that we stop counting it, while the work exposed by its absence becomes the new definition of difficulty. Nobody spends much time celebrating that servers no longer take weeks to provision or that every application no longer rebuilds the same foundation from scratch. Those victories became infrastructure. Our attention moved on.
The AI article left me thinking I had discovered something specific about agents and engineering leadership. I still think those roles are revealing something about where engineering work is going, but the emphasis on judgment, ownership and coordination no longer looks like a reaction to immature tools. It may be what becomes visible when the tools work well enough that producing another piece of software is no longer the hardest part.
I’m less interested now in whether the next breakthrough will make us more productive; it probably will. What I find myself wondering is what will become difficult once the thing currently slowing us down no longer does.