Over the past few months we have been building one of the subdomains of our lending project, with most of the code written by AI under architectural supervision: 100 stories in 26 days, 12 repositories, ≈218,500 lines of code, 44 ADRs, including PCI DSS and National Bank of Ukraine requirements, where the cost of an architectural mistake is quite high. This experience changes the way we look at the architect's work when planning project decisions. Although AI tools help automate and accelerate development, in fact it is the human who remains responsible for the result. By default, AI does not think strategically and often picks the simplest implementation path, which can lead to negative outcomes in the future unless a human explicitly describes the strategy when setting the task. So the more autonomy we want from AI, the higher the qualification required of the human beside it: there remain decisions that cannot be delegated, no matter how smart the next model gets. Modern methodologies (ADR, quality gates, ATAM, TOGAF) are transforming in the age of AI and make it possible to achieve a higher-quality result with higher autonomy. That is what we will talk about in my presentation. This talk is for architects, team leads, and senior engineers who have already tried AI and strive to increase the effectiveness and autonomy of their teams.

How would you call a tech lead who reads and checks every single line of code their team writes? For me it is not a rhetorical question: in my career I built the contribution process for one of the largest repositories at Grammarly, for a hundred contributors monthly. Today every one of us has become a tech lead of a team of AI agents, and we ask ourselves and each other the same question: how do you call a person who does not read the code their agents generate? Without going into the full controversy of that question, I believe the answer is fundamentally the same for a team of people and a team of agents. Properly built processes let the lead avoid micromanagement and reviewing every line in a pull request. In this talk I will show pragmatic recipes for building AI development that will bring you closer to trusting the code your AI agents write.

If your development process looks like “I write a prompt in Claude Code, and then we get the job done using my favorite set of skills”—then you’re a year and a half behind the times, which, in our AI reality, is an eternity. Nowadays, graphs and self-improving loops are all the rage—you define a task, and it’s broken down into 100,500 separate blocks, each of which is simple, produces a measurable result, and is therefore easy to manage and improve. Sounds perfect? Yes—until you get tired of a simple task taking an hour and a half, or until you start calculating how much it costs (in money or tokens—it doesn’t matter). Over the past six months, I’ve built six such factories as a consultant—all following the same blueprint—but now, with every new client, I start a long conversation explaining that you most likely either don’t need this approach, or you do—but in a different way. We’ll touch on three aspects—technological, economic, and cultural—to explain where the problems actually arise and why I no longer consider the “dark software factory” in its graph-and-block form to be a silver bullet for everyone.

A few years ago, we started building Architecture as Code with a fairly simple goal: make architectural knowledge accessible, up to date, and understandable for engineers. C4 diagrams, ADRs, OpenAPI specifications, ERDs, ownership, and other documentation gradually moved closer to the codebase, becoming version-controlled and machine-readable. We built it for humans. Then AI agents arrived. And unexpectedly, we discovered that one of the hardest parts of working with AI — transferring enough system context to an agent — had already been largely solved. In this talk, we’ll explore why repository access alone is not enough, how code context differs from system context, and how Architecture as Code naturally evolves into Context Engineering. Using practical examples, we’ll look at the context an AI agent needs to do more than just write code: understanding domains, architectural decisions, API contracts, ownership, and system constraints. We’ll also discuss the next challenge: ensuring that the context AI relies on actually reflects the real state of the system.

When you give an LLM satellite imagery, object detection can look impressive on high-quality images — and completely fall apart when you switch to freely available satellite data, where the entire object may be just 20 pixels across. I’ll share our journey of detecting illegal landfills in Sentinel-2 imagery and explain why the path to a working solution wasn’t simply “get more data and throw a bigger model at it.” We started by moving away from LLMs and toward specialized object detectors, and eventually ended up with an architecture where each individual feature of an object is detected by a separate agent, while the final probability is calculated using explicit mathematical rules.

This talk will explore what software engineering looks like when a product becomes part of a national digital infrastructure. Millions of citizens, government registries, critical infrastructure, personal data, dozens of integrations, and strict security requirements fundamentally change the rules of software development. Things that work well in the private sector may require a completely different approach in GovTech. We will follow the journey from idea to production, covering the principles behind building a SuperApp, product discovery, the specifics of the SDLC, on-premise and cloud infrastructure, cybersecurity, and information security. We will also take a closer look at AI in GovTech — from collecting and preparing data for proprietary models to developing AI components and integrating them into government digital products. The talk will show how to balance real-world constraints with modern engineering practices while maintaining the ability to build and continuously evolve digital services at national scale.

No product team can keep up with every need and use case of the Defense Forces. At the same time, military units are already adapting existing digital products on their own — building companion apps and custom tools to address specific needs across their end-to-end combat workflows and accelerate enemy destruction. How can we turn this demand into a full-fledged platform capability? How can we give users a safe, standardized way to adapt digital products to their own battlefield needs? In this talk, we’ll share our approach to this challenge, walk through real-world cases, and demonstrate the core capabilities that are already in use today. We’ll also explore where this approach can go next: from adapting user interfaces to working with backend logic, data, and AI/agent capabilities — ultimately enabling users to build their own end-to-end workflows on top of a shared platform.

What is really happening to outsourcing companies in the AI era? Clients have stopped asking, “How long will this take?” — they now come in with their own estimates. They have already reassessed what we should be capable of, without us making any promises or even agreeing with those expectations. Long-term planning has broken down, and with it, the financial model and the traditional role hierarchy. This talk is about how we are navigating that shift, through two specific cases. The first: a client asked for a 10× productivity increase starting with the very next sprint. We never promised that manual work would disappear — another vendor did. The client removed 6 out of 10 engineers from our team and replaced them with a “swarm of agents.” We’ll look at how that swarm was set up, why features still failed to make it to production, and why engineers are now being brought back. The second: we made the same bet ourselves — pushing AI adoption as far as possible in an internal experiment. The result: 2.5 months instead of one, one out of four features rewritten after release, and hundreds of bugs. But there were valuable lessons. We discovered that the real delivery bottleneck was pull requests, built a PR classifier around that insight, and defined an order of operations between Claude, the classifier, and developers — along with what we call the 80% rule. And finally, we’ll address the question every outsourcing company now has to face: the same feature takes fewer billable hours at roughly the same rate. The client pays less, while we have less room to be wrong.

Building an AI agent is only half the job. The real challenge is knowing whether it performs reliably and continues to meet expectations as models, prompts, tools, and data evolve. In this session, we’ll use a practical example to show how to build effective Evals for AI agents: creating representative test cases, defining meaningful quality criteria and metrics, combining automated checks with LLM-as-a-Judge and human evaluation, comparing different agent versions, and making Evals a core part of the development and testing lifecycle.

A story about the creation and development of the largest military app, the ins and outs of IT support, and a look at the pros, cons, and pitfalls of the process