--- type: "article" title: "Agentic Development and Engineering Strategy" summary: "It’s hard nowadays to not link AI and Strategy, but calling it AI Strategy in your company can signal a lack of situational awareness. The same happened in the past with Cloud Strategy, DevOps Strategy, Mobile Strategy, you name it.\nThose terms are loaded in meaning and at the same time can mean nothing.\n\n\nThanks for reading Engineering Strategy! Subscribe for free to receive new posts and support my work.\n\n\n\n\n\nThat’s what I call Strategy Theater\n\nStrategy Theater is when we use buzzwords and apparently esoteric concepts to create the illusion of high-level thinking. Richard Rumelt calls this Fluff.\nTruth is, LLMs and Agents build on top of it and have had the most orthogonal adoption within companies that I have ever seen, in areas like, but not limited to:\n\nHow do we build products with Agentic Development. 👈 This post.\n\nAnd how this affects the buy vs. build decision-making, for example.\n\n\nHow products behave with new agentic/AI capabilities, AI Products.\n\nHow do we support our clients, from manual processes to AI workflows.\n\nEach of those areas requires its own understanding of the investment in how AI impacts it, plus how to measure it. And a company might invest all of them or none.\nToday, I focus on the first point. Please let me know in the comments if you would like me to explore the other two.\nLeave a comment\n\nEngineering Strategy is how we address the\nhigh-stake business challenge from a technical point of view.\n\nThe high-stake business challenge is the key factor here. Do we know which it is? Or are we blindly copying the market trends?\nI guess nobody would be fired (yet) to buy from Anthopic. 🤷\nEach of those points requires a dedicated post; for now, I wanted to share a draft list of ideas for each section that I’m exploring plus some personal/biased opinions.\nAgentic Development\nNew practices\nLLMs and Agents do have impacted our ways of working. The impact of being for good or for bad doesn’t matter. Because we are still learning the new ways of working.\nIt will take time until they become stable.\nFor now, the commoditization of LLMs is producing new high-order systems, and the methodologies are co-evolving with them.\nAgentic Development changed the whole Software-Development Life Cycle (SDLC). If the time to add code cost drops significantly, the bottleneck moves somewhere else. The obvious is PR review time; the next are product definition, measuring impact, and, in some cases, QAing.\n\nThe bottleneck has always been decision-making, though. Now it’s more obvious. Code being the bottleneck… we can argue that it never was.\n\nBuy vs. Build has become more challenging\nIf the cost of building drops, buying looks expensive. Buying has implications:\n\nContract negociation,\n\nIntegration,\n\nExposed to the vendor update lifecycle,\n\nNot fully doing that little thing that the business considers critical for the user (spoiler: it unusually is…).\n\nYet, there’s a new cost. The maintenance/running it. Building is fun, maintaining… not that much.\n\nWe are creating legacy beyond our possibilities.\nA legacy we need to maintain now.\n\nFor companies that don’t have a DevOps culture, this has bigger implications. Because whoever builds it isn’t responsible for running it. We are moving a lot of work to our SRE teams. Sending hugs for you all, SREs. 🫂\nSo, building with AI without a DevOps culture has this broken feedback loop of the cost of maintaining.\nMy suggestion here is to check with SRE teams how they are dealing with the increased throughput that AI enables. Have an honest conversation with them, and understand their pains and complaints. This will help you understand the sociotechnical system dynamics.\nCore vs. Supportive Subdomains\nAI has this tendency to work on what’s known, because that’s what it is trained on. Not being aware of this can lead us to create fast, existing products/solutions. Those that you cannot sell because everyone else has it too.\nUsing Domain-Driven Design terms, we can see it as:\n\nSupportive Subdomains: Desirable to use AI because we want to go fast on something that is expected but not unique. With AI, we can have the baseline faster than before.\n\nCore Subdomain: This is your product differentiator. Where you aim to be unique. The usage of AI can bring us to the wrong solution, an existing one over an innovative one.\n\nI explore this topic in more detail here.\n\nHow to measure impact?\nThere is a lot of work to understand impact, from DORA metrics to new metrics, systems to identify bottlenecks, and new ways to (try to) measure ROI.\nToday, I’m not sure how to really measure impact. Definitely we’re seeing:\n\nIncrement of PRs.\n\nIncrement of time spent on PR review.\n\nIncrement of unstable systems. Systems need to absorb a huge change rate increase.\n\nDeterioration of understanding systems.\n\nEach new improvement moves the bottleneck to a new place, which creates opportunities for improvement and new products to sell.\nRegardless of that, it’s still challenging to link the increment of output with outcome. I’m seeing some improvements, but we shouldn’t underestimate:\n\nEffort to measure impact,\n\nMore change rate doesn’t mean money. Users take time to adopt new products/features. The adoption isn’t linear.\n\nProbably the people from DX are the ones investing the most in a scientific approach to understanding productivity. I would check them out for how to measure impact for sure.\nhttps://docs.getdx.com/dx-ai/\nAdoption\nAdoption Rate is always different between people and departments. There’s no best approach to help people adopt new tools and ways of working.\nI’m seeing that the best is to change approaches depending on the moment the company is in:\n\nEveryone learns the same thing in different ways: You aim for fast experimentation and learning, even though people learn the same thing and might be duplicating effort.\n\nCentralized policy/recommendation: After learning, you want to help people to leverage the good practices that suit your company context.\n\nSingle Vendor vs. Multiple Vendors\nI wouldn’t bet today on only trying one vendor, like only buying from Anthropic. Each company is designing a set of products based on their own incentives. Locking into a single vendor might simplify things but also exposes you to being limited to one company approach.\nThe good thing about adopting a single vendor, is that you optimize your company for the set of products they will offer. Reducing the need to relearn or adapt to your company. You adapt to them instead of the other way around.\nThat, IMHO, works well if you aim to gain as much velocity as the vendor can provide. The counterpart of that is that all your competitors would be in the same situation. Meaning that AI won’t be a competitive advantage.\nI believe adapting the tools to your specific context would outperform defaulting to the vendor’s tooling only.\nYet, this second approach requires discipline, situational awareness, and more investment in the ecosystem understanding. If those aren’t part of your strategy, then defaulting to vendors could be a better approach.,/\nWatercolor drawing\nMy weekly drawing that helps me stay in touch with the craft 😄\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThanks for reading Engineering Strategy! Subscribe for free to receive new posts and support my work." newsletter: "Engineering Strategy" newsletter_handle: "engineeringstrategy" newsletter_url: "https://usecommune.com/n/engineeringstrategy" author: "Aleix Morgadas (@aleixmorgadas)" published: "2026-10-10T14:52:45.000Z" canonical_url: "https://usecommune.com/n/engineeringstrategy/a/agentic-development-and-engineering-strategy" markdown_url: "https://usecommune.com/n/engineeringstrategy/a/agentic-development-and-engineering-strategy.md" chat_url: "https://usecommune.com/n/engineeringstrategy/a/agentic-development-and-engineering-strategy/chat" source_url: "https://learnings.aleixmorgadas.dev/p/agentic-development-and-engineering" body_source: "imported" likes: 0 replies: 0 body_words: 1221 --- # Agentic Development and Engineering Strategy It’s hard nowadays to not link AI and Strategy, but calling it AI Strategy in your company can signal a lack of situational awareness. The same happened in the past with Cloud Strategy, DevOps Strategy, Mobile Strategy, you name it. Those terms are loaded in meaning and at the same time can mean nothing. Thanks for reading Engineering Strategy! Subscribe for free to receive new posts and support my work. That’s what I call Strategy Theater Strategy Theater is when we use buzzwords and apparently esoteric concepts to create the illusion of high-level thinking. Richard Rumelt calls this *Fluff.* Truth is, LLMs and Agents build on top of it and have had the most orthogonal adoption within companies that I have ever seen, in areas like, but not limited to: - How do we build products with Agentic Development. 👈 **This post**. - And how this affects the buy vs. build decision-making, for example. - How products behave with new agentic/AI capabilities, AI Products. - How do we support our clients, from manual processes to AI workflows. Each of those areas requires its own understanding of the investment in how AI impacts it, plus how to measure it. And a company might invest all of them or none. Today, I focus on the first point. Please let me know in the comments if you would like me to explore the other two. [Leave a comment](https://learnings.aleixmorgadas.dev/p/agentic-development-and-engineering/comments) Engineering Strategy is how we address the **high-stake business challenge** from a technical point of view. The high-stake business challenge is the key factor here. **Do we know which it is? Or are we blindly copying the market trends?** I guess nobody would be fired (yet) to buy from Anthopic. 🤷 Each of those points requires a dedicated post; for now, I wanted to share a draft list of ideas for each section that I’m exploring plus some personal/biased opinions. # Agentic Development ### New practices LLMs and Agents do have impacted our ways of working. The impact of being for good or for bad doesn’t matter. Because we are still learning the new ways of working. It will take time until they become stable. For now, the commoditization of LLMs is producing new high-order systems, and the methodologies are co-evolving with them. Agentic Development changed the whole Software-Development Life Cycle (SDLC). If the time to add code cost drops significantly, the bottleneck moves somewhere else. The obvious is PR review time; the next are product definition, measuring impact, and, in some cases, QAing. > *The bottleneck has always been decision-making, though. Now it’s more obvious. Code being the bottleneck… we can argue that it never was.* ### Buy vs. Build has become more challenging If the cost of building drops, buying looks expensive. Buying has implications: - Contract negociation, - Integration, - Exposed to the vendor update lifecycle, - Not fully doing that little thing that the business considers critical for the user (spoiler: it unusually is…). Yet, there’s a new cost. The maintenance/running it. Building is fun, maintaining… not that much. We are creating legacy beyond our possibilities. A legacy we need to maintain now. For companies that don’t have a DevOps culture, this has bigger implications. Because whoever builds it isn’t responsible for running it. We are moving a lot of work to our SRE teams. Sending hugs for you all, SREs. 🫂 So, building with AI without a DevOps culture has this broken feedback loop of the cost of maintaining. My suggestion here is to check with SRE teams how they are dealing with the increased throughput that AI enables. Have an honest conversation with them, and understand their pains and complaints. This will help you understand the sociotechnical system dynamics. ### Core vs. Supportive Subdomains AI has this tendency to work on what’s known, because that’s what it is trained on. Not being aware of this can lead us to create fast, existing products/solutions. Those that you cannot sell because everyone else has it too. Using Domain-Driven Design terms, we can see it as: - **Supportive Subdomains**: Desirable to use AI because we want to go fast on something that is expected but not unique. With AI, we can have the *baseline* faster than before. - **Core Subdomain**: This is your product differentiator. Where you aim to be unique. The usage of AI can bring us to the wrong solution, an existing one over an innovative one. I explore this topic in more detail here. ### How to measure impact? There is a lot of work to understand impact, from DORA metrics to new metrics, systems to identify bottlenecks, and new ways to (try to) measure ROI. Today, I’m not sure how to really measure impact. Definitely we’re seeing: - Increment of PRs. - Increment of time spent on PR review. - Increment of unstable systems. Systems need to absorb a huge change rate increase. - Deterioration of understanding systems. Each new improvement moves the bottleneck to a new place, which creates opportunities for improvement and new products to sell. Regardless of that, it’s still challenging to link the increment of output with outcome. I’m seeing some improvements, but we shouldn’t underestimate: - Effort to measure impact, - More change rate doesn’t mean money. Users take time to adopt new products/features. The adoption isn’t linear. Probably the people from DX are the ones investing the most in a scientific approach to understanding productivity. I would check them out for how to measure impact for sure. [https://docs.getdx.com/dx-ai/](https://docs.getdx.com/dx-ai/) ### Adoption Adoption Rate is always different between people and departments. There’s no best approach to help people adopt new tools and ways of working. I’m seeing that the best is to change approaches depending on the moment the company is in: - Everyone learns the same thing in different ways: You aim for fast experimentation and learning, even though people learn the same thing and might be duplicating effort. - Centralized policy/recommendation: After learning, you want to help people to leverage the good practices that suit your company context. ### Single Vendor vs. Multiple Vendors I wouldn’t bet today on only trying one vendor, like only buying from Anthropic. Each company is designing a set of products based on their own incentives. Locking into a single vendor might simplify things but also exposes you to being limited to one company approach. The good thing about adopting a single vendor, is that you optimize your company for the set of products they will offer. Reducing the need to relearn or adapt to your company. You adapt to them instead of the other way around. That, IMHO, works well if you aim to gain as much velocity as the vendor can provide. The counterpart of that is that all your competitors would be in the same situation. Meaning that AI won’t be a competitive advantage. I believe adapting the tools to your specific context would outperform defaulting to the vendor’s tooling only. Yet, this second approach requires discipline, situational awareness, and more investment in the ecosystem understanding. If those aren’t part of your strategy, then defaulting to vendors could be a better approach.,/ # Watercolor drawing My weekly drawing that helps me stay in touch with the craft 😄 [![](https://substackcdn.com/image/fetch/$s_!ZYII!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F964214e7-ebe2-4a9a-8f90-51d37347356d_1280x854.png)](https://substackcdn.com/image/fetch/$s_!ZYII!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F964214e7-ebe2-4a9a-8f90-51d37347356d_1280x854.png) Thanks for reading Engineering Strategy! Subscribe for free to receive new posts and support my work. *** ## Discussion No replies yet.