AI Dev Podcast #2: Architecture in the AI Era

Sergey sets the frame: change driven by AI looks much like the arrival of microservices alongside DevOps — some approach it rationally, others ride the hype, and as an industry, he says, we lag precisely on the engineering side. His proposal: step back, look at the systems and processes we actually work in, adopt changes step by step, assess results and share what worked widely — otherwise there is no telling apart what is merely sold from what works. Alexander picks it up: AI was once again treated as a silver bullet, with a fear of being left behind on top. Yet years of adoption have shown that the winners are not those who spread it fastest across every process, but those who already had foundations. Research, he says, shows AI amplifies what an organisation already has: strong engineering and a platform make work faster still, while chaotic processes simply gain entropy — things happen quicker with no systemic effect.

Andrey pushes back: there is Lovable, and anyone with even shaky command of any language puts together a prototype in minutes, whereas before he paid for a specification, hunted for contractors by reference and dragged it towards a prototype for months. None of it needs engineering culture or a platform: development has been democratised and costs little. Alexander accepts it: inside T-Bank he is responsible for their own equivalent of the platform, and Lovable really does yield not just a prototype but a working product with Stripe or Shopify integrations, authentication and a database. Except that at some point you stop adding features and start bug-fixing: mend one part and another falls apart. He linked the product to a GitHub repository, downloaded the code and found no file of rules for agents, no skills, no guardrails, no test harness inside. A sandcastle: without an engineer to add a brace and shore up the foundation it will not rise above a metre.

Sergey separates two orthogonal processes: creating something new and evolving what exists. A prototype lives on its own and bothers nobody, and many teams now replace external SaaS with their own: a CRM or a planner takes about a week of prompting — not sellable, but it covers your needs. Difficulty starts with product-grade solutions, where economics comes first of all. Deploy in three places and in one the margin is 10-20%, while in another, because of traffic profile and memory use, it is already negative — and telling a model to spend less of your money is hard. Hence his point about juniors: a model knows a priori what a person learns over five years at university and ten to twenty at work, but you must speak to it in the language of the domain. Ask it to design a marketplace architecture and you get one thing; phrase the same task in the terms of an architecture practice book and the answer is narrower, more formal, with fewer hallucinations, and the model reasons in architectural tactics you then land on your context.

Alexander turns to the architect's role. The canonical enterprise hierarchy — corporate architects, solution architects, software architects and engineers at the bottom of the food chain — is not to his taste; at T-Bank architecture was a role performed by high-grade engineers — less talking, more doing — while the corporate layer landed with technical directors by domain. Top-down, language models act as assistants: gathering the landscape, generating documentation. But plan mode in assistants like Claude Code or Codex is effectively an architect at feature level inside a repository: it explores the code and asks what matters to you. Alexander designed multi-tenancy with such an assistant: the document used to take a day to write, a week to sell and a month of waiting, whereas on a greenfield system it fits into a day of interactive co-design. He wants to extend that by pulling in context at four levels: company rules, the domain, the repository and the specific task. Sergey tempers it: what you build in a day does not live in a vacuum, and the constraint is no longer coding speed but delivery and infrastructure.

Another barrier, in Sergey's view, is data. A knowledge base convenient for humans must also match an ontology and carry no duplicates for a model, or corporate rules from today and from years past will set it arguing with itself; part of the context — preferences, the political reasons behind decisions — is not encoded at all and always lags reality. Alexander describes the move from Software Engineering 1.0, with its handoffs between analyst, developer, tester and support, to a 2.0 where people and agents work in one system. Delegating responsibility to agents works only with a clear intent, recorded constraints, automated code review and evaluations in place, and only a human who holds the domain context can assemble that. Sergey backs it with the swings of market mood: last year companies reported laying off 10% of staff and tens of thousands of people, while this year a quarterly Gartner report records hiring again — working with agents suddenly needs strong specialists.

Sergey explains why the fundamentals hold: architectural tactics live at a meta level above the code, and neither tables nor schemas carry metadata about modularity, so agents miss it. His example: two services under one business invariant — you cannot withdraw more than ten thousand if a condition in the neighbouring service applies. Two teams will negotiate; agents need supra-system context. A model can also reach a valid answer through invalid reasoning: it may drift into how houses and cities are built, producing a correct-looking but unworkable solution. Economics shifts too: a reusable component always cost more and paid off if two to five systems picked it up; now it costs the tokens spent on it. Alexander moves value from implementation to contracts and rules, and years-old tech debt can go to Claude Code, Codex or Cursor. The shared risk is vendor lock-in on a model that subsidises tokens today and raises the price tomorrow; the answer is a layer with quotas and a canonical API plus an internal model to switch to. Closing, Andrey names context the main differentiator, Alexander notes that by the third year people ask for a financial effect, and Sergey advises running a local model at home.