How a YADRO Developer Sets Up Claude Code for Spec-Driven Development

Daniil Podolsky, a programmer and architect at YADRO, has worked with the Spec-Driven Development methodology for nine months, directing AI agents that write code in his place. He does not call himself a vibe coder but an engineer, and he explains why. This is the first article in his series on organizing the workspace of an SDD developer: a walkthrough of a basic Claude Code setup for switching models quickly without a restart.

SDD vs. vibe coding

Vibe coding means the developer describes a task to the AI, looks at the result and iterates by feel. The approach is popular precisely because it is fast and needs no advance preparation.

Spec-Driven Development works on a fundamentally different principle. First you create a full specification: requirements, architecture, system behavior, edge cases. Only then does the AI agent start working from the document as if from a technical brief. The developer defines the structure and makes the architectural decisions; the AI implements the details and fills in the code.

Podolsky insists his approach is "more comprehensive than just chatting with an AI." SDD brings engineering discipline back to a place where it had begun to disappear because of the speed of AI tools: requirements, design, implementation, verification. The executor has changed, but the process remains an engineering one. That is what separates SDD from vibe coding: it is a methodology, not a tool.

Configuring Claude Code for multiple projects

The article's central task is how to switch models in Claude Code without a restart, individually for each project. It looks like a minor detail, but in practice it is a serious drag for anyone working on several repositories at once.

A standard global model setting does not work well here. Different projects have different requirements: a production service needs Opus with deep reasoning and strict instruction-following, while a prototype or routine task is fine with Sonnet or Haiku. If every move between projects requires manual reconfiguration and an agent restart, the developer starts avoiding model changes and picks a "universal" model instead of the optimal one.

Key configuration principles:

• `CLAUDE.md` in the project root: model and context are fully isolated at the repository level
• The `/model` command switches the model on the fly without restarting the current session
• Project-level `settings.json` stores agent profiles, permissions and the toolset
• Local override files separate dev and prod configurations
• Environment variables let you control the model through CI/CD without editing configuration files

Why switching speed changes quality

In Spec-Driven Development, a single project uses several models in sequence at different stages. Writing the specification calls for a powerful model with strong reasoning and detailed answers. Implementing against a finished spec only needs a fast, predictable one, which lowers the chance of deviating from the brief. The final review calls for yet another profile.

If switching takes half a minute and involves manual steps, the developer gradually starts avoiding model changes. That hurts both speed and quality, especially at the specification stage, where reasoning is critical.

"My approach to work is more comprehensive than just chatting with an AI," —

Daniil Podolsky, YADRO.

The series will continue. Upcoming articles will cover orchestrating several agents in parallel, context management and the structure of the specifications themselves.

What this means

Spec-Driven Development is gradually taking shape as a distinct engineering discipline. While most developers are learning vibe coding, some are moving to strict methodologies: documentation, specification, agent, verification. This breakdown of a Claude Code setup by a YADRO architect is one of the first systematic Russian-language pieces on the topic. It is also worth following for those who still work with AI tools intuitively.