All articles

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 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/ 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 😄 Thanks for reading Engineering Strategy! Subscribe for free to receive new posts and support my work.

Oct 10, 2026

Software Architecture is highly contextual. That kind of context that doesn’t reside only on written documents nor glamorous diagrams. The one that you build overtime as you understand more the business, the user, and the software at hand. Thanks for reading Engineering Strategy! Subscribe for free to receive new posts and support my work. It’s the accumulated set of decisions that drove you where you are, enables certain futures, and locks you down from others. The software is the result of all those decisions, some intentional while others accidental, those that survived the real world stress and chaos, and they incomplete representation of what happened that drove it where it’s today. I’m sure you had to work with legacy systems, and understanding the full picture by only looking at the code was impossible (and drove to the wrong conclusions). You also had to speak to people to understand the whole. Because code lacks context. It only tells you a part of the story. And all of a sudden, we got AI. Here is my experience so far combining architecture and AI. Lack of architecture, AI doing more of the same We all had that feature that our architecture doesn’t support yet; like geoqueries, time series graphs, you name it. Sometimes it’s obvious, other’s not that much. The team gets that kind of feature to develop. AI makes a first SQL query with some JOINTS, adds an index, and the feature works in local and staging. You test it, and all good to go. And then production kicks us hard. You open the monitoring system, and you realize that that query won’t perform for several reasons. You’re stressing the database a lot, affecting other queries as well. Running that query against the main DB was the wrong decision, yet, it can be unnoticed if that wasn’t caught up early on the SDLC. This example can be detected during the PR review, but think of more subtle changes that can be overseen. In order to make that performant, we would need to either materialize the views, or move the structure to dedicated DB that supports that kind of high performing aggregation for example. Learning: Adding features on top of existing capabilities works ✅ Adding features that require extending the system capabilities could be undetected by the AI. The main missing context could be: Production system demands like traffic/load/etc, Current system limitations like not supporting geo-queries, Available solutions/vendors that might require budget approval. The common AI approach in this case is to keep with existing capabilities over extending them. More of the same. This pattern locks you to the existing architecture, because it will rely on existing as much as possible. Good if the existing architecture is good enough, Bad if you aim to move away from it. A person with enough backend and database experience, would have picked this issue either on design time, or PR review time. Indeed, this is usually what happens when the surface of the change is obvious enough. But the thing here is that before, we would have paired or debated around the solution as a team. Now, we are moving away from those collaborative spaces to be more impactful, or focused on delivery. So, the amount of small nuances like the one I shared starts to happen more often. For most cases, those bad decisions that impact production are noticeable enough to be addressed. The problem is those that do not make enough noise and accumulate over time. Providing Context and Asking for Solutions to the AI, and the solutions not being context specific enough to apply. Recently, we had to architect the capability of real-time communication, a chat. If you ask everyone about how to implement that, you will receive something in the lines of: Let’s implement a Pub/Sub with a Redis Cluster and WebSockets. Let’s aim to use a OSS implementation that handles the retires, and other infrastructure stuff for us. We keep our stateless application to handle the different messages, and business logic. And to be fair, that’s a good solution for most cases. AI replied the same. So, we should be able to move forward with it, shouldn’t we? Well. No. Those solutions have implications. Not because it’s common and accepted, it should apply to us. Maintaining a Redis Cluster, and thousands of WebSockets connections can easily become a nightmare to handle. But this cost isn’t obvious for the team developing the feature, because that’s handled by the infrastructure team. That decision has implications on the other team. Now, they have to keep those things up. Plus, adding real-time adds more stress to the existing application and database. Our traffic is modest. So our solution should be. We should aim for something that we shouldn’t manage, and perform good enough for the current traffic and expect to perform well up to a x10 - x20 in traffic increase. So, we continued to explore more approaches. And we found that a serverless stateful application based on the Actor Model to be suitable for our use case. Avoiding all the infrastructure complexity, and focus on the pure business logic. This solution based on our traffic is peanuts 🥜. We moved from an accepted solution by the big tech, which has organizational consequences to maintain that solution up, to a context specific one. That one created way more debate than the accepted one. The good kind of debate. Which I enjoyed a lot by the way. Learnings AI provides common industry approaches to problems, but they are generic solutions. Those approaches are usually shared by big tech, a very different context compared to us. It also defaults to our current capabilities, and it’s hard to explore alternatives. AI doesn’t know how to navigate organization complexities, like: How to propose to rely on into a new vendor, or, How to propose a separate service on a monolithic application structure. AI went well to PoC different approaches guided by humans, you stress your architecture to see how much can it support, in terms of performance/concurrency, as well as new product needs, and/or use cases. AI knows that’s now, but not what’s next We are delivering this feature, but our product lead is already thinking way ahead of this. Are we moving into that direction? Is our current solution making that harder or easier to reach? I have been lucky enough to work with brilliant business and product people. And one single thing that I know after working with them is that there is no way to do a braindump of what they have in mind. Adding that to the AI context, as a markdown maybe? No way it happens (yet?). You learn about their vision though conversations, debates, and endless discussions on how they see the reality, how they are modelling it in their heads. And then my work is to: Create shared Models between the team members to understand what’s being considered; Event Storming is still one of the best tools I found for this. Understand first where we are, so we can understand how far we are from there, and which steps have to be done to be closer to that. Drive a way to model that domain in code, as well as improving the architecture to support that domain model, and the different stress that it will suffer after serving our user needs. I find it hard to encode that as context for the AI agents. Because: It consumes a lot of context, and it provides the wrong guidance to the agents. Should I work on this feature or the next feature? That criteria is hard to delegate, because it also adds the dimension of certainty. Should we address that now or later? The product vision, and the domain model at hand is something you iterate on. The more you learn, the better you get at it. Aim to delegate that, and you lose that skill of closing the present and the future. The domain model needs to be shared between people, otherwise each person implements their own understanding of the problem. AI makes that gap between people understanding worse. Which has two main outcomes that I can think of: You rely on AI suggestions for the implementation; Making the solution not a business differentiator. Remember that AI is trained on existing solutions, you should create new ones, otherwise why using yours and not the existing? You receive the feedback very late on the SDLC, usually not on the PRs, but either in the demos with the product people, or worse, in production based on customers feedback. Other areas I’m exploring How the org chart is supporting the changes based on how AI can drive cross-team changes, and how that affects the Conway’s Law. DevOps culture impact. If creating is cheap, but maintaining isn’t, how that dynamic is affected. Please, we are all learning together. Leave a comment with your learnings so far. 🙌 Leave a comment A drawing I made I’m learning about watercolor, and I wanted to introduce it as part of my newsletter. I hope you like it 😄 Thanks for reading Engineering Strategy! Subscribe for free to receive new posts and support my work.

Oct 2, 2026

Guest post by Colette Molteni. Founder and author of Empathy Elevated, a Substack publication on emotional intelligence, Stoicism, and AI-human partnership for technical professionals Aleix made a point in his early April post, Rethinking Pair Programming in the Age of AI, that there is no such thing as “pairing with AI”. No, in fact, the pairing is grounded as a human act. When it’s a person and an agent, that is agentic development. It’s a different practice with a different set of rules. Once you accept this distinction, an uncomfortable realization surfaces. Seniors are not always paired with AI. But are they still pairing with juniors now that agents are in the room? Walk into most engineering teams right now, whether it is agentic, software, or backend, and you will see two things happening in parallel. Seniors are getting faster with agents. Juniors are getting quieter. The two patterns are not unrelated; they are from the same dynamic but on different ends of the long table. The most common AI-era pairing failure is not technical. It’s when seniors stop scheduling pairing sessions because the agent is perceived to be faster. Juniors stop asking them for the sessions because they do not want to appear as a bottleneck. Nobody decides this intentionally. It just happens.​ What Seniors Stopped Transferring When Agents Showed Up A pairing’s real product was never about the code only. It was about judgment formation. That is something an agent cannot transfer to a junior. It is innately human work. The underrated function of a pairing session was making the seniors’ reasoning observable. A junior could witness the wrong turn, the half-formed hypothesis, and the moment the senior could explain, “Actually, here’s why we do not want to do it that way. Let’s try this instead…” Agentic development collapses the visible reasoning. The output can be read but not iterated on, as you would with a human colleague over Zoom or in person. The final output appears, but the path to get there happens in milliseconds, without the reasoning absorbed. The deliberation disappears like a flame extinguished. The juniors see the answer, and not the thinking. Juniors do not just need the correct code or way forward to troubleshoot. They need to watch how a senior decides between several plausible approaches. That’s what builds an engineer’s judgment. That’s exactly what solely agentic workflows skip by default. Aleix named it in his piece that seniors discover agent productivity, but then the pairing calendar quietly empties. Nobody directly announces it. The slot just drops. The cost builds up over time. A junior never watches a senior reason out loud. They miss more than just that weekly session at 10am on Tuesday. They miss the pattern of how seniors later change their minds. That is a pattern to be observed and make them senior one day. Noticing what your team is absorbing from your behavior, not just from your output, is a quiet power. Seniors set the implicit curriculum whether they intend to or not. Three Prompt Patterns That Build Judgment Instead of Bypassing It The three prompt patterns can be used to move from simple diagnosis to practice in collaboration, iteration, and applying judgment. Pairing is a human exercise. The agent is a tool. Like any tool, what matters is what the human decided to build before they picked it up. The agent is a contributor to the session, not a substitute for a pairing session itself. These are patterns you can leverage as a senior with your junior in your next pairing session. Treat the output of these patterns as a third party: to be challenged, edited, or even discarded. Pattern One: Articulate the problem before opening the agent The junior writes three things before any prompt is typed. The problem statement The constraints At least one hypothesis about the approach Make this non-negotiable: written out, every time. Learning loss occurs in the seconds between knowing there is a task and assuming it is always a prompt. The thinking that should belong to the engineer gets handed to the agent before the engineer ever did it themselves. This exercise is short, with just three to five minutes to do before writing out the prompt. But in those few minutes, the junior becomes the author of their work rather than the editor of the agent’s work. Skip this step, and the remaining session is a cleanup, rather than a collaboration. Pattern Two: Pair upon the prompt itself, not just the output Review the prompt together before the junior runs it. Where is it unclear? What context is missing? What assumption is buried in the phrasing? Reframe what code review is becoming. The artifact worth reviewing has shifted upstream, from the diff to the prompt. Pattern Three: Require a counter-position After the agent outputs, the junior has to articulate one reason they would push back on it. Do this before accepting it. This trains the muscle of disagreeing with a confident-sounding source. That muscle is the actual deliverable. This pattern is the one juniors will resist the most. Pushing back on an output that sounds confident can feel presumptuous. The agent is great at sounding authoritative. But that’s exactly why it has to be practiced during a pairing. As a senior, you are there to validate the disagreement and challenge the agent. Building confidence in dissent is a skill. The Review Question That Tells You Whether the Junior Actually Learned A standard pull request review was built for a different world. You would comment on the differences, request changes, and approve. The workflow assumed the author wrote the code. The difference is that the thinking is different now. The artifact is not necessarily someone else’s thinking. The mentorship has to move upstream of the diff. Ask the junior to walk you through why the agent’s approach is correct. Do not accept that it just is. If the junior cannot articulate this, the pull request is not ready, regardless of the test results. This is not about gatekeeping. This is about mentorship with the new interface of working in tandem with agents. Ask in your next pull request review, “What did you consider and reject?” If the answer is “nothing, the agent gave me this”, that’s the signal, not a fail. It’s a teaching moment. Over time, the answers to this question will become ingrained knowledge within the team. The paths that are rejected weigh just as much as the accepted ones, as these are lessons that carry through. A senior who gathers these answers and reviews them can spot which agent failure modes the team is already recognizing, and where the teaching moments still are. How often does the junior push back on the agent’s output during a review? An increasing frequency over time is an indicator of forming a judgment. A frequency of zero indicates dependency. How seniors deliver this review matters as much as what we review. The goal isn’t to make juniors defensive about agent use. The goal is to make the team’s reasoning visible currency. Pairing Is Still Human. The Stakes Just Got Higher Pairing is still human, but the stakes aren’t only about throughput and sprint velocity. It is about the team’s long-arc capability and the judgment that ships next quarter and the quarter after that. Agents quietly changed something about leadership. The fastest path to short-term output now bypasses the slowest path to long-term capability. Every senior is now choosing between these two paths, each day. Most are not even aware of this choice. The fastest path to short-term output now bypasses the slowest path to long-term capability. Every senior is now choosing between these two paths, each day. Most are not even aware of this choice. This choice plays out one calendar invite at a time. The senior who skips a pairing session because the agent is faster has not necessarily done anything wrong on that day. The output shipped. The sprint moved. But compounded over time and repeated, it produces a team of engineers who can prompt but not think. The damage seeps in, like a tap slowly overflowing a sink. Pairing is not just knowledge transfer. It is an investment in someone else’s reasoning, becoming independent of yours. Agents can make that investment easier to skip, but they do not make it less necessary. You are paid to build a team, not just to ship a sprint. About Colette Empathy Elevated Human skills for high-intellect professionals navigating work in the age of AI. Free weekly. Paid Deeper. By Colette Molteni Founder and author of Empathy Elevated, a Substack publication on emotional intelligence, Stoicism, and AI-human partnership for technical professionals Creator of The PACE System™ (Pause, Ask, Consider, Empathize), a framework for navigating high-stakes interpersonal moments in technical environments. Data and Process Excellence Manager at ResMed, a global medical technology company Has mentored junior employees through AI-assisted technical work Lean Six Sigma Black Belt

Jul 2, 2026

Make your strategy more robust to avoid common mistakes

May 2, 2026

Missed communication, lack of sociotechnical system understanding, and more.

Apr 25, 20261 likes

Why "pairing with AI" is harmful to your team and what to do instead

Apr 6, 20261 likes

How adoption will determine the lifecycle of the strategy

Mar 10, 20262 likes

Yes, the physical notebook.

Mar 3, 20262 likes

How coherent actions and ad hoc teams help you on the execution of the strategy

Feb 19, 2026

How coherent actions and ad hoc teams help you on the execution of the strategy

Feb 19, 2026

I heard this sentence multiple times during my career, and sometimes said by myself.

Jan 18, 2026

I heard this sentence multiple times during my career, and sometimes said by myself.

Jan 18, 2026

Identifying what's necessary to overcome the high stakes challenge

Dec 21, 2025

Identifying what's necessary to overcome the high stakes challenge

Dec 21, 2025

The ultimate stakeholder

Nov 7, 2025

The ultimate stakeholder

Nov 7, 2025

An example of a chat in a two-sided marketplace product

Aug 18, 2025

An example of a chat in a two-sided marketplace product

Aug 18, 2025

Measures against losing knowledge due to AI

Aug 9, 2025

I’m sure you are familiar with commit messages that look like:

Aug 9, 2025