Ambition for 2026 was to boost team's performance by 15-20%... we made 30-50%. AI-assisted SDLC has been converted into AI-based SDLC where people work together with agents with clear responsibility separation: humans - for sense and control, agents - for routine. We use "human-in-the-loop" approach and experiment with agent loops. Can we treat that as an "AI software factory"? Let's think about together... I will show how we work based on one of our biggest solution consisting of 152 projects with 2.5 mln lines of source code and 18.7 mln of tokens to describe shared context. How do we support it? How do we overcome context window size limits? See you on the meeting!

In the agentic-first era, we’ll bring all your project data together in one place and give agents access to it. We’ll discuss the problems this would solve, how to collect and validate the data, and how to keep it up to date. And also you will see how this approach will change the way your team works.

Why do some teams speed up with the same AI tools while others drown in slop? We'll go through common anti-patterns of working with AI agents in development, from "generate everything at once" to blind trust in the output, what they lead to in practice, and what to do instead.

Every new cloud provider a company adopts usually means another set of Terraform configurations, another deployment guide, and yet another way of doing things. Costs start growing faster than the number of providers. Platform engineering helps break this dependency: the golden path becomes the interface, while the specific cloud becomes just an implementation detail. A developer describes what they need — a service and a production database — and the platform decides how that should be provisioned in a hyperscaler versus a local cloud provider. In the live demo, a developer creates a new service through a self-service portal. One template, one Kubernetes manifest — and the application is deployed to two clouds at the same time. The same PostgreSQL request becomes a managed database service in one cloud and an operator-managed database running in Kubernetes in another. We’ll also look at the limits of this approach. IAM, storage, and backups are not completely hidden by the abstraction layer — and I’ll explain why that is actually a good thing. After the talk, you’ll understand how the “request → composition” pattern works for databases across different clouds, how to start building your first golden path without creating your own PaaS, and which differences between cloud providers should remain visible to developers.

Deploying and Optimizing LLM Inference in Production on GPUs Ranging from L4 to 4xH200: Choosing Inference Engines and Configurations, Balancing Throughput, Latency, and Cost, and How to “Squeeze” the Most Out of Your Hardware and Avoid Common Tuning Mistakes

Imagine two mission-critical systems exchanging sensitive data, when either system, or the network between them, could be compromised. We’ll build the integration architecture step by step, introducing trust boundaries, identities, access control, data minimisation, encryption, and other security controls that limit blast radius. We’ll show how layered architectural decisions can keep systems secure and resilient even when individual controls fail.

As the classic once said, “life should be interesting.” Especially in interesting times. And especially when AI barges into our cozy little bubble uninvited and starts threatening to take our jobs. But if you can’t beat them, lead them. So I decided to be the first to voluntarily give AI some of my work. Well, not exactly give it away — more like pass on the honorable title of React monkey. Somewhere along the way, though, I got carried away and ended up building an entire troop of AIpes, each with (almost) clearly defined roles, (almost) well-defined responsibilities and constraints, and the ability to handle my tasks with (almost) a single command. That’s what I want to talk about: how a simple idea of making an LLM write routine code turned into a whole team of specialized agents; how I built my own agent harness in Claude Code; what worked, what broke, and what workarounds I had to invent along the way. And finally, what training my AIpes taught me about models, prompts, and why adding “pwetty pwease” to your prompt still won’t make a rule actually bind.

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.