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.

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.

Nowadays, everyone is creating AI Assistants to help us in our day-to-day activities and "vibe coding" nice and shiny demo apps. However, when you try to bring AI Assistants to life in production—especially to be used by the citizens of a Gov Portal—you realize that creating the AI Agent itself is only 10% of the effort required. The other 90% is spent on satisfying cross-cutting concerns and different stakeholder concerns. This talk will be based on my own experience of putting citizen AI Assistants for a Gov Portal (built on top of an AI Agentic Platform) into production. I'll talk about the challenges we faced, concerns we received from different groups of stakeholders, important NFRs and quality attributes of the solution, and possible solutions for these challenges. This talk will give useful tips, provide a wider view on real-world challenges, and improve critical thinking. This talk will be interesting for diff Roles to get a wider view on real world challenges and to improve critical thinking. Amongst other topics I want to talk about (not in order for now): - Naive implementation of Chatbot -vs- scalable and mature implementation - Benefits and drawbacks of using AI Agentic Platform -vs- custom implementation - Choice of Public LLM vs Private LLM - Performance and quality challenges - Infrastructure - Costs - Error handling - UI/UX - Guardrails and protection against misuse and DDOS attacks - Observability - Multilingual support - Testing and evaluation framework - PII data handling - and more...

Today, AI can answer questions, search for information, and complete tasks. But how do you turn it from just another chatbot into a true extension of a brand? Using Mushroom Hennadiiovych, Silpo’s AI assistant, as a case study, I’ll share how we built a product that brings together modern LLMs, product thinking, and a distinctive brand personality. We’ll explore the journey from idea to launch, the solution architecture, the trade-offs, the mistakes we made, and the lessons that can help anyone building AI products.

Implementing AI into a government service with 23+ million users is a journey of continuous product discoveries and challenges. In this talk, I will share the real-world experience of how the "Diia" ecosystem is transitioning from a classic Digital State (where users search for the required services themselves) to an Agentic State (where AI proactively fulfills the user's intent). What we will cover: - Product Discovery and Paradigm Shift: The transition from Digital State to Agentic State. Why traditional interfaces have reached their limits and how we validated the need for proactive AI solutions. - AI in Support as the First Big Step: How we automated 90% of requests without a drop in quality (CSAT). Soft AI UX: why people struggle with prompting and how we guide them using hybrid interfaces. - The Upskill Case and Team Transformation: We didn't fire a single operator. How we built internal AI tools for the team, turning yesterday's support agents into AI trainers. - Deep Dive into Diia.AI on the Portal: The launch of the world's first agentic service at the government level. How our RAG architecture works, how we architecturally protect personal data (PII) from entering the LLM, and how we repel jailbreak attempts.

What happens when a large language model becomes the entry point to government services that operate under real-world load and in the context of an information war? In such an architecture, any request may be not only incorrect but also intentionally manipulative — and standard AI safety solutions prove far less reliable than they appear in laboratory benchmarks. In this talk, I will share how we built a custom guardrail module for Diia.AI after encountering the limitations of off-the-shelf filters and the high cost of the LLM-as-a-Judge approach. Instead of validating every request with a large model, we designed a cascade security architecture: fast ML classifiers filter out most of the traffic, while the LLM is invoked only where deeper contextual analysis is truly required. This talk is not about perfect models, but about trade-offs, constraints, and practical decisions that must be made when an AI system operates not on a laptop, but within a national-scale service.

This presentation is designed for engineers, architects, and technical leaders who want not only to use large language models, but also to understand how they work, how to interact with them through APIs, what challenges arise when building RAG systems, and how to solve them.

AI development hits everyone, so hit us. Everybody wants AI agents to replace regular UIs. In this talk, I will describe the evolution of our multitool AI agent, built with Node.js on top of Google Vertex AI. I’ll dive into our journey of choosing the right models and scaling development through CI/CD, TDD, and performance monitoring. Is it even possible to achieve stable results for AI projects that can hallucinate and return various responses? Interestingly, we eventually decided to remove MCP servers and Zod schema validation—technologies often considered the "standard" for these tasks. Want to know why we moved away from them? Join my session to get these insights and ask your questions live!