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

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.

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.

With Agentic PDLC, the agents no longer just writes or reviews code — it forms hypotheses and tests them in production. How do you re-architect for autonomous agentic loops that run 24/7 on systems serving millions of users? Drawing on enterprise experience, we'll break down how to move from human control to event-driven governance and explicit guardrails for agents.

As the team grows, products multiply, and the engineering organization evolves - the CTO role often shifts from a technical leader to a manager staring at spreadsheets and dashboards. And that’s when it becomes truly challenging: to stay in the technical loop, remain close to the architecture and systems, and keep a real sense of what’s happening on the ground. In this talk, I’ll share my experience on how to stay a Hands-on CTO - maintaining deep technical understanding, influencing architecture, and scaling the company at the same time, without losing touch with the code and core systems. Key topics we’ll cover: - How the CTO role evolves as the company grows - from coder to system-level leader. - The most common traps: loss of architectural memory, disconnect between business and engineering, dependency on a few key people. - Healthy habits that help keep technical context: code reviews, architecture stand-ups, "walk the code" sessions, CTO R&D sprints. - Decision-making systems: how ADRs and RFCs help maintain clarity and traceability. - Communication with tech leads: building effective 1:1s, technical syncs, and knowledge-sharing loops. - Tools and platforms that preserve context - dashboards, monitoring systems, and architecture reviews.

A discussion with representatives of high-risk systems about why security architecture should be incorporated at the design and development stage, rather than added after release into production. We will talk about the risks of delayed implementation of controls, common security illusions, and practical approaches to integrating security practices into the work of product teams.

Have you ever wondered what’s really going on under the hood of distributed systems? Not those “sort of a cluster” setups with 3 nodes, I mean the real deal. The exabyte-scale beasts. In this talk, we’ll peek behind the curtains of modern infrastructure. How do systems that crunch mountains of data actually work? What patterns, principles, and engineering decisions are hiding behind truly scalable architectures? Here’s what we’ll dive into: - What the inner life of a distributed system really looks like - How a distributed app is different from a distributed system - How data storage patterns evolve into modern DBs, queues, and logs - Why “PostgreSQL in the cloud” isn’t really PostgreSQL anymore - Why Northguard might just outshine Kafka - And how new players like NewSQL are changing the game If you’re an architect, tech lead, developer or just curious about why infrastructure scales the way it does - come join! I’ll share insights you might use in your own projects (or at least see them from a new angle). P.S. Yep, there’ll be a bit of magic ✨ and a whole lot of hard truths about the distributed systems powering our world. ?

This presentation will focus on the maintainability quality attribute — how to keep business logic isolated, consolidated, encapsulated, and consistent, as well as how to integrate it with the infrastructure layer, including persistence, messaging etc. We will explore the practical application of the following approaches: - OOD / Rich Domain Model / DDD - Hexagonal layered architecture - CQRS / Persistence / ORM All these aspects will be illustrated through a real-world task example and its implementation approach (code examples will be in .NET).