Panel discussion “AI yesterday, today, tomorrow” with AI Dev Conf (Category AI4SDLC)
Appeared. panelI have been working on AI Dev Conf. The composition of the participants was representative: Alexey Totmakov from VK Tech, Rafael Tonakanyan from Sber, Andrei Kuleshov from Yandex SourceCraft and me in the role of moderator. I think it was a good conversation about the fact that AI in development has already become basic hygiene: models help write code, tests, documentation, disassemble legacy, review and move faster on routine tasks. But the big question now is whether we can safely embed AI into an engineering system so that it produces a measurable output, rather than simply increasing the amount of code generated. We touched on many topics, but the main ones are noted below.
1The first big topic is context. A model without context is like a very confident junior developer who doesn’t know your system. It can quickly come up with a solution, but it doesn't understand why it's weird workaround, what SLAs the service has, what dependencies you can't touch, what data you can't send out, and what tests are really important. So “giving models access to code” is not a strategy. Normal engineering formulation is needed: purpose, constraints, context, acceptance criteria, change boundaries, tests and a way to verify the result. It’s about the same chain I’ve talked about a lot: intent -> context -> plan -> tasks -> implementation -> verification.
2The second topic is the transition from assistants to agents. The assistant helps the person, but the person holds the goal, plan and responsibility. The agent can already decompose the task, call tools, change the code, run tests, read the error and try again. It sounds beautiful, but in a big company it immediately raises uncomfortable questions. What repositories does the agent have access to? Can he read the logs? Can it change the configuration? Who is responsible for security regression? What's logging? Where do you need approval? How do you roll back? Agentic coding is not just a smarter model. This is the new architecture of the development process.
3The third topic is metrics. It is very easy to count the wrong things: the licenses purchased, the number of requests to the model, the number of lines of code generated. All of this can be a useful adoption signal, but it doesn't show whether the engineering system has gotten better. You need to look at the chain as a whole: cycle time, time-to-PR, time-to-merge, review quality, defects, security risk, the burden on senior engineers, the cost of tokens and the share of the result that actually reaches production.
4The fourth topic is politics. If AI can access code, tasks, logs, documentation, and internal data, the rules can no longer be kept in the mind of the architect. You need machine-testable policies: what data can be given to models, what models are allowed for what tasks, where the agent has access, what changes require manual confirmation, what needs to be logged and what actions are always prohibited.
5️ Another important point is that strategy cannot be built around one model. Models will change faster than processes. Therefore, more sustainable elements are needed: gateway, routing between models, evals, logging, cost limits, quality comparison and the ability to replace the provider without rewriting the entire process.
For developers, the conclusion is this: it is important to be able to design a verifiable work for the person and the agent: set a task, give context, limit the solution, read diff critically and build a verification outline.
For techlids, EMs, and CTOs, the conclusion is tougher: AI adoption is not about purchasing licenses. This is a change in the operating model of development. You have to think about context, politics, tools, sandboxes, evals, observability, metrics, economics, and responsibility.
So the big question right now is, can your organization safely, measurably, and regularly turn AI acceleration into production output?
#AI #AI4SDLC #Engineering #Management #Architecture #Agents #DevTools