# AI Copilots for Tech Architecture: The Highest-ROI Use Case You're Not Building Boris Bogatin & Tufik Pubz, Catio | AI Engineer CODE 2025 | 27:29 Source: https://www.youtube.com/watch?v=QRWdapxMdSY Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/ai-copilots-for-tech-architecture-the-highest-roi-use-case-youre-not-building Published: 2025-11-24 Tags: agents, context-engineering, copilots, enterprise, multi-agent ## TL;DR - Architecture decisions determine whether coding productivity produces useful software or more rework and technical debt. - A useful architecture copilot needs a live model of the technology estate, recommendations tied to business outcomes, and guidance embedded in developer workflows. - Leaders should start with one portfolio area, prove business impact, and expand only after teams have evidence that the approach works. ## Summary Boris Bogatin and Tufik Pubz argue that coding copilots have received most of the attention, while architecture decisions remain managed through spreadsheets, tribal knowledge, and instinct. They identify three problems: leaders lack a current view of services, dependencies, and drift; they struggle to rank architecture work by business impact; and developers need guidance that scales without turning architecture teams into bottlenecks. Their proposed architecture copilot begins with messy system data and turns it into a live digital twin. It then combines that model with company goals, standards, and constraints to produce explainable, ROI-ranked recommendations. A conversational agent can carry those standards into feature design and everyday developer work. The speakers describe multi-agent systems as a way to reason across interconnected architecture problems, while acknowledging that large architectural models and environment simulation are still future ideas. They recommend starting with one portfolio area and one team, then scaling after proving the value. ## Key ideas ### Architecture choices determine whether coding output creates value [01:13](https://www.youtube.com/watch?v=QRWdapxMdSY&t=73s) Coding copilots now support much of the software life cycle, from project management through execution and operations. Boris Bogatin asks what is still missing. His answer is architecture guidance. If a team produces more code while moving in the wrong architectural direction, the result can be poor software, rework, and technical debt. Architecture decisions also shape very large technology spending and determine whether technology supports business objectives or slows them down. The argument is practical: productivity gains from coding matter more when teams have already chosen a sound direction. Coding faster does not fix a bad architectural decision. ### Architecture leaders lack a live view of what they own [03:04](https://www.youtube.com/watch?v=QRWdapxMdSY&t=184s) Tufik Pubz describes visibility as the first major problem. As a technology estate grows, leaders can no longer reliably understand its services, dependencies, and changes over time. Without a dependable, current map, decisions become slow and defensive. Teams may carry redundant spending, fail to manage risks, or make multi-million-dollar bets without knowing what they already have. The speakers compare the needed system to a living architecture map that updates as the estate evolves. It should capture messy systems, implicit knowledge, and shifting dependencies rather than relying on a wiki that describes what the organization thinks it has. ### Recommendations need a visible connection to business impact [06:34](https://www.youtube.com/watch?v=QRWdapxMdSY&t=394s) The second challenge is deciding what to do next when resources are scarce and every project claims importance. Tufik says leaders need expert-ranked actions tied to business impact. The relevant factors can include cost, performance, risk, and time to value, alongside existing investments and strategic goals. Recommendations should be explainable and traceable: teams need to know why an action is valid, where it came from, what impact it is expected to have, and how outcomes will be measured. The proposed result is a roadmap in which each initiative has a score, a justified return, and explicit links to business objectives and architecture practices. ### Developer autonomy needs architecture guidance inside the workflow [09:04](https://www.youtube.com/watch?v=QRWdapxMdSY&t=544s) The third challenge follows the shift-left model, where developers make more architectural decisions as they build and ship features. Architecture teams and review groups cannot examine every decision effectively, but leaving developers without guidance creates misalignment. The speakers propose conversational agents that give tailor-fit designs, answers, and advice within developer workflows. These agents would carry organizational policies, standards, and strategic guidance into feature design. The goal is to avoid both extremes described in the talk: autonomy without alignment creates chaos, while approval gates without autonomy slow productivity. Architecture review could move from checking standards after the fact to having standards built into designs by default. ### A true architecture copilot starts with a digital twin [11:39](https://www.youtube.com/watch?v=QRWdapxMdSY&t=699s) The first of the speakers' three pillars is a live visibility layer called Stacks. It would ingest information from clouds, Kubernetes services, logging platforms, and other sources. The system would model dependencies, drift, and change over time, then assemble the information into a digital twin of the deployment and architecture. This model should reflect the system's current reality rather than the contents of documentation. The digital twin gives the rest of the copilot something concrete to inspect and reason about. Without that foundation, recommendations would be based on incomplete or stale information. ### AI needs company context before it can recommend architecture [12:36](https://www.youtube.com/watch?v=QRWdapxMdSY&t=756s) A system model alone does not explain what the company is trying to achieve. The second pillar is to combine the live architecture model with business objectives, requirements, standards, strategy, and team context. A company in hypergrowth may make different choices from a company optimizing an established estate. The copilot should use that context to produce recommendations fitted to the objectives of a business, workspace, or team. Tufik describes the desired output as data-backed, best-practice, and ROI-based recommendations. These recommendations should make trade-offs visible across cost, performance, risk, and other measures that matter to the organization. ### Multi-agent systems fit architecture's interconnected problems [13:33](https://www.youtube.com/watch?v=QRWdapxMdSY&t=813s) The speakers describe architecture reasoning as more complex than a one-shot coding task because its parts are interconnected. A recommendation may require breaking down dependencies, examining separate areas, and combining the results into a global view. They suggest multi-agent systems as one way to distribute this work across agents focused on different parts of the problem. The agents can collaborate toward a recommendation and extend the design-review processes that human teams already use. Tufik also describes a possible longer-term progression from language models to large architectural models and eventually simulations that test system behavior before a decision is made. He is clear that this future does not exist yet. ### Conversational guidance is the third pillar [17:35](https://www.youtube.com/watch?v=QRWdapxMdSY&t=1055s) The third pillar is a conversational architectural agent embedded in the way developers and architects work. It should answer questions about the current architecture, advise on optimization and refactoring, and generate designs from feature requirements such as a product requirements document. Organizational governance and controls would be part of the agent's context, so the resulting designs follow the guidance set by architecture leaders. This connects strategic direction with the choices developers make each day. The speakers say this could let architecture teams scale through the guidance they provide to the AI, while spending less time on repetitive reviews and more time on difficult technical and strategic work. ### The proposed workflow moves from system understanding to measured outcomes [21:15](https://www.youtube.com/watch?v=QRWdapxMdSY&t=1275s) The end-to-end process has four steps. First, ingest data from messy systems and normalize it into a live digital twin. Second, align the model with company goals, requirements, and context, then generate ranked recommendations with projected effects on cost, performance, return, or another selected measure. Third, put governance into generated designs, answer what-if questions in real time, and enforce standards inside the existing workflow. Fourth, track decisions, verify outcomes, and improve the system over time. The speakers connect this process to coding copilots: an architecture copilot can help teams aim before coding agents fire, with the possibility that architecture agents and coding agents will exchange direction directly. ## Notable quotes - "If you're going into the wrong direction with a lot of coding output, are you not going to get to poor code, poor results, and a lot of redo and tech debt versus moving truly into the right architectural direction?" (01:32) - "You have to have a system of recommendations. The reason these recommendations really to fulfill what you're talking about must be explainable and traceable." (07:55) - "Autonomy without alignment creates chaos and gates without autonomy kills productivity." (10:50) - "You can't manage what you don't measure." (22:30) - "Start small and scale up to it." (26:27) ## Tools & references mentioned - Catio - Splunk - Datadog - Kubernetes - GP2 - GP3 - LLMs ## Who should watch - You lead architecture or technology planning but still depend on spreadsheets, static documentation, or informal knowledge to understand your estate. - Your organization has shifted architectural decisions toward developers and you need standards to reach them without adding more review gates. - You are evaluating an architecture copilot and want a small pilot tied to measurable business outcomes rather than a company-wide rollout. ## Related talks - [Copilots Everywhere](https://aietalks.com/talks/copilots-everywhere) (Thomas Dohmke, GitHub & Eugene Yan, 18:22) - [Grounded Reasoning Systems for Cloud Architecture](https://aietalks.com/talks/grounded-reasoning-systems-for-cloud-architecture) (Iman Makaremi, Cat.io, 26:06) - [From Copilot to Colleague: Trustworthy Agents for High-Stakes](https://aietalks.com/talks/from-copilot-to-colleague-trustworthy-agents-for-high-stakes) (Joel Hron, Thomson Reuters, 19:45) - [Prototyping as Leadership: How a CTO Ships with AI Agents](https://aietalks.com/talks/prototyping-as-leadership-how-a-cto-ships-with-ai-agents) (Hursh Agrawal, The Browser Company, 18:18) - [Building AI Agents with Real ROI in the Enterprise SDLC](https://aietalks.com/talks/building-ai-agents-with-real-roi-in-the-enterprise-sdlc) (Bruno Passos, Booking.com & Beyang Liu, Sourcegraph, 20:56)