In high-load systems, infrastructure costs often grow not because of the load itself, but because of inefficient architectural decisions: overprovisioning, excessive use of managed services, unnecessary data movement, incorrect SLA decisions, and the lack of a transparent cost model. At the conference, we will discuss how to approach cost optimization as a full-fledged architectural practice, rather than a one-time resource reduction exercise. We will also cover workload profile analysis, identifying real bottlenecks, building unit economics for infrastructure, traffic optimization, caching, CDN, observability, and controlled service degradation. Separately, we will look at the trade-off between performance, reliability, and cost: where maximum fault tolerance is truly required, where an eventually consistent approach is sufficient, and where managed solutions should be replaced with a simpler self-hosted architecture.

This talk is about taming AI: the journey from a simple Plan Mode in Cursor/Claude to structured specification systems. We'll break down why GitHub Spec Kit turned out to be too heavyweight, how ADR (Architecture Decision Records) helps agents retain context across sessions, and why OpenSpec by Y Combinator (Fission-AI, W26) became sweet spot. The central thesis: code quality on output equals specification quality on input. Together we'll reflect on the transformation of the developer's role — from "coder" to "spec architect."

What if an engineer receives not a task, but a ready PR with context and a proposed solution? At Wix, we’re building remote agents — autonomous agents triggered by external events (Jira, Slack) that execute tasks in the background without human involvement and return results as context for developers. In this talk, I’ll cover: what remote agents are, how they’re architected, and how to integrate one into your own system. I’ll share real numbers — success and failure cases from our experience. Beyond that, the non-obvious parts: where agents break, why a spec-driven approach is critical for them to work, and what changes in team processes when part of the work is done by an agent. This talk is for those already working with AI tooling and thinking about the next step — from copilot to autonomy.

Ten years ago, we pulled libraries and frameworks into our projects not because we wanted to — but because we had to. It was the only way to survive the “browser wars” era and avoid drowning in spaghetti code. Frameworks became our спасіння, and we got used to them. Since then, the web has evolved — but our habits haven’t. HTML, CSS, and JavaScript have made huge leaps forward, yet we still automatically pull in megabytes of abstractions just to render a simple product list — and proudly call it a “modern stack.” It’s time to ask ourselves some uncomfortable questions: • What problems do frameworks actually solve today — beyond our fear of being left alone with plain JavaScript? • Where is the line where “developer comfort” turns into unnecessary weight for the product? • Have frameworks become just a convenient shield — hiding our reluctance to truly understand the platform? I’m not saying we should delete React tomorrow (although…). But I do want to explore this: do frameworks still solve real technical problems — or are we just building another “Hello World” in React because we’ve forgotten how to do it any other way?

Vibecoding is one of the most effective tools for a product manager today. It not only enables the use of ready-made services to speed up workflows, but also allows you to build custom tools tailored to specific tasks, taking into account the product context and processes. This reduces unnecessary actions and repetitive manual work. In large teams, it’s about personal efficiency and workflow automation. At the R&D stage, it’s about the ability to independently build an MVP, get initial user feedback, and only then hand the solution over to development. In the talk, Maksym will explain how he uses vibecoding in his work as a product manager — from MVP development to building custom tools.

In many systems, analytics are built directly into the backend: events, workers, and enrichment through dozens of database queries and calls to other services. In our case, a single analytics event generated up to 10 database queries, which, at a scale of millions of events, placed a significant load on production. In this talk, I’ll explain how we completely changed our approach: - we switched from application events to CDC via Debezium; - we started feeding changes from each table directly into the data pipeline; - we moved enrichment and aggregations to BigQuery; and we effectively removed the analytics load from backend services. As a result: - we eliminated millions of read queries to the production database; - reduced the complexity of the backend code; - separated OLTP from analytics; and made building analytics significantly faster. Let’s talk separately about a less obvious benefit: now, to build new analytical scenarios, all you need is one Data Engineer, an ERD diagram, and modern AI tools—without involving the backend team and without changes to the production code. We’ll also examine: - where CDC actually delivers value, and where it doesn’t; - what issues arise (lag, duplicates, schema changes); - how the system’s cost changes; and why “the same data” in the new architecture isn’t free.

<p></p>

Market expectations for developers are rising fast: today, clients expect not only basic prompt-writing skills but also hands-on experience with the Model Context Protocol (MCP). In this talk, we’ll show that MCP isn’t as complex as it seems. We’ll walk through the journey from a standard REST API to a fully functional MCP server. You’ll learn the key features of the protocol, the essential libraries, and the security considerations needed to enable AI to interact with your backend autonomously.

Oleksii Minakov and Vyacheslav Koldovskyy will face off in a spectacular battle, showcasing the most exciting and unexpected use cases of generative AI tools live on stage. Expect unconventional scenarios, creative experiments, and impressive real-world applications of AI that will engage both beginners and experienced professionals. The goal is not just to impress, but to expand your understanding of what modern artificial intelligence is truly capable of. Vyacheslav Koldovskyy: Agent Skills Superpowers Remember how Neo learned Kung Fu in The Matrix? The knowledge was simply uploaded into his mind. Unfortunately, that doesn’t work for humans yet — but it’s already possible for AI agents through Agent Skills. Agent Skills are essentially the equivalent of human skills — the ability to perform actions, achieve outcomes, or solve specific tasks. However, unlike humans, agents don’t need years of training. These skills can be created, combined, and reused almost instantly. In practice, Agent Skills are modular building blocks of behavior: individual functions, instructions, or scenarios that an agent can invoke when needed. They can range from simple actions (like processing text or retrieving information) to complex workflows (running analysis, interacting with APIs, or executing multi-step processes). The real “superpower” emerges when these skills work together. An agent can dynamically choose which skill to apply, chain them together, and adapt its behavior based on the context of the task. Moreover, if we define a sequence of actions not as deterministic code but as a set of agent skills, we effectively “program” the agent in a completely different paradigm — non-deterministic programming. Unlike traditional programs, this approach allows systems to adapt to context, make decisions under uncertainty, flexibly adjust behavior, and even improve over time. And that’s exactly why Agent Skills are the true superpower of AI agents — something we’ll explore together with Vyacheslav Koldovskyy.