# How AI Is Rebuilding Software Engineering - Part 1: What’s Actually Changing > Source: > Published: 2026-07-29 14:01:54+00:00 We are living through one of the most challenging moments the software industry has faced. AI’s disruption made us rethink almost everything: how we build software, the roles we know, how we measure performance, and the processes and practices themselves. Even software service models are shifting. I say “almost” on purpose: the fundamentals, at least for now, still hold. Meanwhile, you might be feeling overwhelmed by the flood of AI content across social media. I feel that way too, and it’s exactly what pushed me to write this. This isn’t another piece about which trendy tool to adopt or what skill to learn to “stay ahead”. It’s what I’ve seen from the inside, across real projects, over the past few months — the parts of this shift that don’t get as much airtime as the usual AI headlines. This is the first of two pieces. Here, I’ll cover what’s changing at the structural level: roles, service models, and how we work together as teams. Then, I’ll get into what’s happening inside teams day to day — the bottlenecks, the friction, and why measuring any of it is harder than it looks. You’ve probably heard about [FDE](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers?utm_source=substack&utm_medium=email****), AI Engineer, Agentic Engineer, and other new “hottest” profiles companies are looking for right now. At the same time, you’ve probably also heard about existing developers being replaced. While it’s fair to say AI is introducing new roles, the good news is that developers aren’t going to disappear, as some are trying to claim. What’s more likely is that fewer developers will be needed to write code itself — though even that isn’t a given: the long-term cost and accessibility of AI tooling is still an open question, and the current pricing model is unlikely to stay as it is (that alone might deserve its own article). For those worried about it, it’s worth mentioning that — aside from the AI-specific skills — many of the abilities listed in these “new role” job descriptions are already part of the current developer skill set. Fundamental programming and architecture concepts still matter just as much. Is there really a difference between learning a new tech stack that popped up and learning about agents, MCPs, prompts, or token consumption? After all, this is something developers have always done as part of their careers. So it’s not far-fetched to assume a shift or re-categorization is entirely possible for current developers, after some re-skilling. In some cases, these new roles might even help split and scope responsibilities that used to be crammed into a single role wearing several hats at once. Which brings us to a broader conclusion: existing roles will likely change from what we know today. AI deepened something that had already been happening in recent years — **the profiles that stand out aren’t just tech experts**. Companies are looking for people who thrive in ambiguity, take ownership, solve problems, and want direct impact on the product and the company itself. And those are not skills AI gives you. Over the last several years, software services were mostly sold under three models: fixed price, time & materials, and staff augmentation. Whichever was chosen, at some point it all came down to selling people’s hours. AI changed that game. Companies started reviewing their software costs. At first, they asked themselves whether they even needed a software partner, given that building software might be easier than ever. They also questioned the value of paying for enterprise software licenses if they could now build their own custom software instead. Now that they’ve learned they may still need a software partner — especially if building a tech team isn’t their core business — and that building custom software, even with AI, can still be expensive, they’ve started asking for the same quality, in less time, at a lower price, leaning on the idea that AI tools should make that possible and that they shouldn’t need big teams to ship the same amount of features. This caused selling hours to become less profitable than before, so service models started shifting to new shapes that are still being defined. In that context, what’s clear is that **the main asset now is the value proposition over the hours needed**, and that teams will include people and AI agents. What’s not clear yet is how to measure, charge, and eventually standardize the value a software partner delivers, since “value” means something different for every company and business. Another open question is the pricing model for AI tooling itself, which isn’t sustainable as it stands today and keeps changing. Does this mean staff augmentation is over? No, at least not yet. Companies will still need tech experts. On top of that, transitioning existing partner relationships to new models won’t be easy for either side. New projects will likely be where the new models get tested first. Even before AI showed up, I’d already noticed it was getting harder to strictly follow some “agile” principles as project context became more dynamic. The fixed structure of sprints and the nature of some ceremonies started to clash with what actually happened day to day. Once AI entered the picture, we had to start re-thinking what the new agile looks like. Along the way, some of the questions we started asking were: how do we measure complexity now that we have this “AI superpower”? Does it still make sense to write user stories, or should we solve an entire PRD in one shot? Do we keep daily meetings, or shift to more collaboration sessions instead? What’s our new team capacity? The answer I keep coming back to is that: there’s no single solution, it depends on the scenario. Even two teams in the same organization might work with different strategies. What I’ve learned is that the right strategy, methodology, and process depend largely on the AI adoption level of the entire organization, not just a single team. I’ll come back to the measurement question later — it turns out it’s bigger than story points. None of these three shifts — roles, service models, agile — come with a playbook. We’re figuring out the rules as we go, and that’s exactly why this moment feels harder than previous ones: there’s no established “right answer” to copy from. That’s the structural layer of what AI is reshaping. There’s a second layer, just as real: what actually happens inside teams once all of this hits daily work — the bottlenecks, the friction, the burnout, and why measuring any of it is harder than it looks. That’s what the next piece is about.