Transcription
Let's today understand the situation familiar, I think, to every developer. We have a task, we have a powerful language model, well, like GPT4, and we start what was very aptly called vibe coding in our materials, that is, development by intuition. >> Uh-huh. We go through prompts, persuade the model, sometimes argue with it, and in the end, after several hours, we get something that seems to work. But this vibe, it's a dangerous thing >> very. >> The result cannot be reproduced later, it's impossible to test it normally, and it, of course, leaves behind a trail of technical debt. >> Exactly. And today, we will, in essence, conduct such an investigation. We have a crime scene. This very unstable vibe coding. >> And there is the main suspect, the methodology Spec Driven Development, or SDD. It was presented by Elharis from Amazon. And it promises to bring order, to turn this chaotic chat with AI into a strict engineering discipline. So, and our task is to examine the evidence from this presentation and understand, is this really a revolution in development or, well, just another hype in a beautiful wrapper. Okay, let's get to the first piece of evidence. The problem of vibe coding. The authors call it a crisis. Well, crisis is, um, certainly a strong word, >> maybe. After all, many breakthrough projects were born precisely in such a chaotic search, on pure intuition, on experiments. Aren't we risking killing all creativity, all this research spirit with this total structuring, in pursuit of, well, sterile predictability? >> Listen, excellent question. It, in essence, sets the tone for our entire discussion. The authors don't dispute the value of experiments. The problem is different. >> What is it? When a prototype needs to be turned into a product, vibe becomes the enemy. But imagine, in a month you need to fix a bug in the code that was generated based on a dozen or so vague prompts. >> That's a nightmare. >> How to reproduce it? How to guarantee that the fix won't break something else? The presentation, in fact, contrasts this chaotic chat with a structured process. And the solution they offer is the Kira tool. And they position it not as a chatbot, but as an agentic IDE. Agentic integrated development environment. It sounds impressive, of course, but how does it differ in practice from, say, Copilot, which is built into my IDE? Is it just autocompletion on steroids or what? >> Not at all. Agentic is the key word here. Look. Copilot is an assistant. It suggests the next step, like a navigator. >> Uh-huh. An agentic IDE is, in essence, a full-fledged junior developer who sits next to you. You don't ask it: "Complete this line." >> And what do I tell it? >> You give it a task: "Listen, implement the feature from ticket number 123." And it goes to your Jira or Asana itself, reads the ticket, analyzes the requirements, >> itself >> itself finds the necessary files in the project, writes the code, tests for it, and brings you a ready pull request for review. That's what an agentic environment is. It takes on the entire software development lifecycle, the very SDLC, not just helps write code. >> Okay, sounds ambitious. The slides say that the architecture of this SDD process stands on three classic pillars: requirements, design, and implementation. >> Yes, >> so far, everything is like in a textbook. Where does the magic begin? What distinguishes it from simply writing a technical specification and, well, feeding it? >> And >> the magic is precisely in the formalization of each of these stages. Let's start with requirements. Instead of writing them in free prose, which can be interpreted in any way, >> yes >> a special EARS syntax is used. Easy approach to requirement syntax. It's a structured, but still natural language. >> And how does it look? The template is very simple. When a certain condition occurs, the system must perform a certain action. That's all. Hmm, no "it would be nice if" or "the system should be fast." Here's an example from the presentation. When a user requests a joke, the system must check the history to avoid repetitions. Clear, unambiguous, verifiable. >> Wait, but this syntax, it sounds incredibly rigid and limited. Real system requirements are often much more complex. They are full of nuances, some implicit conditions. Aren't we artificially simplifying the task, losing important details, just to please the machine? >> That's a fair concern. But the goal of EARS is not to describe all the company's business processes in one sentence. The goal is to force the developer to decompose a complex, vague task into a series of atomic, unambiguous, and verifiable requirements. >> Understood? That is, in essence, it forces us to do what good engineers already do. Exactly, to combat ambiguity. After all, it is the root of bug rage. Even when people write code, we are just eliminating the need for AI to think something for us. >> Okay, let's assume we've written a perfect, unambiguous specification in EARS. That's half the job, but I can write a perfect instruction, and the LLM will still generate code with bugs that, well, formally follows it. How to build trust? How can we be sure that the generated code is actually correct? >> And here we move on to the second, and perhaps the most important, technical element from the presentation: Property-based Testing, or PBT. >> Property-based testing, >> yes, and this is a fundamental shift in the approach to testing. Instead of writing tests for specific scenarios, we describe the properties, or invariants, of the system, fundamental rules that must always be observed. Sounds abstract. Can you give an example? >> Of course. Imagine you are testing a shopping cart in an online store. A regular test is a scenario. If I add item A for 100 rubles and item B for 50, the total amount should be 150. Classic. But what if you add an item with a zero price or a negative one? Or remove an item? Properties are formulated differently. The total price of the cart must always be equal to the sum of the prices of all items in it. And here's the most important part. Regardless of what these items are, how many there are, and in what order they were added or removed. >> Understood. And the PBT system, it turns out. >> And the PBT system, having received this property, turns into a very malicious and creative tester. It starts generating hundreds, thousands of unexpected scenarios itself to break this property. >> Uh-huh. It will provide empty strings, huge numbers, special characters, rare combinations of actions, anything that can find a loophole in your logic. And requirements in EARS format translate perfectly into such properties. This allows proving the correctness of the code at a much deeper level. >> So we are literally moving from the model "I hope you understood me" to the model "I can mathematically prove that you understood me." Exactly, this is a colossal shift from faith to verification. But so far, all this looks like working in a vacuum. Real development needs external context. Access to API documentation, to tasks in the backlog, to internet search. How does the system solve this problem without overloading the model's context window, which, as we know, is not infinite? For this, the authors developed the MCP Model Context Protocol. This is, in essence, an API for an AI agent that allows it to interact with external services on demand. >> Ah, so it requests information itself, right? The presentation mentions integration with AWS documentation, Asana tasks, and the Braй search engine. Instead of stuffing 500 pages of documentation into the prompt, the agent gets the ability to ask: "Um, find me information about limits for S3 in the AWS documentation." And gets a precise answer: hmm. >> It's like giving an engineer access to the internet and the project knowledge base, instead of forcing them to remember everything by heart? >> So the process can be customized. What level of control do I, as a developer, have over the artifacts generated by the agent, for example, over the design document? Can I somehow influence its detail or even the architectural decisions it proposes? >> Yes, and for this, an interesting concept of "grid" is introduced. It can be translated as granularity or level of detail. This is, in essence, a regulator of the agent's autonomy and depth of work. So, Low Grid is a basic setting. For example, you can ask the agent: "Include diagrams, interface mockups in the design document," and it will do it. High Grid is already a full-fledged sparring partner mode. At this level, the agent can challenge your architectural decision. For example, you propose to use S3 for storing user sessions, >> and it >> and the agent, having analyzed the task, can respond: for this purpose, according to AWS best practices, a more idiomatic and performant solution would be DynamoDB. Here's a comparison of the advantages and disadvantages of both approaches. >> Uh-huh. So, grid is, in essence, a regulator of the agent's self-confidence and autonomy. At the low level, it's just an obedient executor, and at the high level, it's a full-fledged opponent in an architectural dispute. This is a completely different level of interaction. >> Absolutely. >> But what about the rules adopted in a specific project? Code style, commit format, prohibition of using certain libraries. Do you have to specify this in the prompt every time? That's tedious, isn't it? >> No, for this, so-called steering files are used. For example, instructions.md. Directly in the project repository. >> Uh-huh. The team defines all their internal rules there once. We use such and such linters, we format commits according to such and such a template. We never use library X. For the agent, this becomes a constant guide to action, like an internal regulation for a new employee. And how does this work with large, existing projects? Any LLM will simply drown if you try to load the entire repository of a million lines of code into it. >> The materials address this point. Kyro doesn't load the entire project at once. Instead, semantic code indexing is used. >> So, >> when the agent receives a task, it doesn't read everything, but performs a semantic search to determine which specific files and modules are relevant for completing this particular task. It's like an experienced developer who intuitively knows where to look for the right controller or service in the codebase, rather than reading all the code from cover to cover. >> And it's effective. >> The authors claim that the efficiency of prompt caching with this approach reaches 95%, which makes interaction fast and economical. >> Let's move on to a practical example to make all this more tangible. The presentation includes the Grams project. Grandpa's Joke Generator. >> Yes, >> it's understandable why it needed memory. A classic grandpa also repeats the same three jokes in a loop. Exactly. And as the speaker notes, it was a very expensive generator, since it worked on LLM, but was almost useless due to constant repetitions. The task was simple: add memory to it. And how did they solve it? Precisely according to the SDD methodology. First, the developer applied EARS. The requirement was: when the system generates a joke, it must ensure that this joke has not appeared in the last twenty responses. This is already a specific, verifiable specification. And what did the agent do? Having received this requirement, the agent responded: "Understood, for this we will need persistent state storage. I propose to use AWS S3 bucket for this." Here is the design document describing how this will work. >> So, >> what's even more important? At the next stage, it didn't just generate Python code that works with S3, it generated AWS CDK code. That's Infrastructure as Code. >> Exactly, it's a framework for describing cloud infrastructure as code. That is, the agent itself wrote and tested scripts that create and configure this S3 bucket when deploying the application. So it's responsible not only for the application code but also for the infrastructure on which this code will run. That's a serious claim. >> Very. >> And in the transcript of the speech, there was a telling moment when the developer doubted the agent's solution. Yes, this is precisely a demonstration of high grid in action. The developer looked at the proposal to use S3 and asked: "Wait, S3 for storing the history of the last twenty jokes feels a bit, well, excessive?" Uh-huh. And he says: "Agent, please explore alternative, more idiomatic solutions within the AWS ecosystem for such a task." And what did the agent do? >> The agent took a pause, conducted research through MCP, and returned with a new proposal. It recommended a more suitable service, for example, DynamoDB, and explained why it's better in terms of latency and cost. >> So it acted not just as an executor, >> but as a full-fledged technical consultant. >> So, let's summarize. We've analyzed a methodology that tries to introduce real engineering discipline into the chaos of development with the help of AI. This is a clear departure from development by intuition. >> Definitely. Key elements are formalized requirements through EARS syntax, provable correctness through property-based testing, and controlled access to external context through the MCP protocol. It seems the main idea is that in the era of generative AI, the most valuable artifact is no longer the code itself. >> Absolutely, the most valuable artifact becomes its specification. >> Uh-huh. The specification turns into a living, executable, verifiable document that guides the work of artificial intelligence. And the code itself in Python, Java, or any other language becomes just a derivative, a byproduct, almost like machine code that results after compiling C++. >> So the source of truth becomes the specification. >> Exactly. And in conclusion, one thought for reflection. These presented materials describe a very structured, top-down, almost waterfall process: requirements, design, implementation. But we know that many great innovations in software development are born from unstructured experiments, from rapid prototyping, from that very creative chaos. >> And this is the main question that remains open. Does such a system, focused on predictability and verification, leave room for accidental discoveries, for those happy accidents that have always driven our industry forward? Or is the era of heroic vibe coding and creative chaos in code truly coming to an end, giving way to the cold engineering discipline of machines. M.