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.

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

Make your strategy more robust to avoid common mistakes

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

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

How adoption will determine the lifecycle of the strategy

Yes, the physical notebook.

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

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