How a YADRO Developer Configures Claude Code with Spec-Driven Development

YADRO programmer and architect Daniil Podolskiy has been working with Spec-Driven Development methodology for nine months and manages AI agents that write code in his place. He calls himself not a vibe coder, but an engineer — and explains why. This is the first article in his series on organizing the workspace of an SDD developer: an examination of basic Claude Code setup for quick model switching without reloading.

SDD vs. Vibe Coding

Vibe coding is when a developer describes a task to AI, looks at what happened, and iterates "by feel". The approach is popular precisely because it works fast and requires no upfront preparation. Spec-Driven Development is fundamentally different.

First, a full specification is created: requirements, architecture, system behavior, edge cases. Only then does the AI agent begin working from the document as a technical specification. The developer shapes the structure and makes architectural decisions, while AI implements the details and fills in the code.

Podolskiy insists that his approach is "more comprehensive than simply talking to AI". SDD restores engineering discipline to an area where it began to disappear due to the speed of AI tools — requirements, design, implementation, verification. The executor changed, but the process itself remains engineering.

This is what distinguishes SDD from vibe coding: not the tool, but the methodology.

Configuring Claude Code for Multiple Projects

The central task of the article is how to switch models in Claude Code without reloading, individually for each project. At first glance a detail, in practice — a serious bottleneck for those managing multiple repositories simultaneously. The standard global model configuration is not suitable in such a situation. Different projects impose different requirements: a production service needs Opus with deep reasoning and strict instruction adherence, a prototype or routine task works fine with Sonnet or Haiku. If each transition between projects requires manual reconfiguration and agent restart, the developer begins to avoid changing models — and takes a "universal" one instead of the optimal choice.

Key configuration principles:

• `CLAUDE.md` at the project root — model and context are fully isolated at the repository level
• The `/model` command switches models on the fly without restarting the current session
• Project-level `settings.json` stores agent profiles, permissions, and tool sets
• Local override files distinguish dev and prod configurations
• Environment variables allow model control through CI/CD without editing config files

Why Switching Speed Changes Quality

With Spec-Driven Development, a single project sequentially uses several models at different stages. Creating a specification requires a powerful model with strong reasoning and detailed responses. Implementing from a ready specification needs a fast and predictable model — less chance of deviation from the task. For final review, another profile is needed again. If switching takes thirty seconds and requires manual manipulation, the developer gradually begins avoiding model changes. This worsens both speed and quality — especially at the specification writing stage, where reasoning is critical.

"My approach to work is more comprehensive than simply talking to AI," —

Daniil Podolskiy, YADRO.

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

What This Means

Spec-Driven Development is gradually becoming a separate engineering discipline. While most developers are learning vibe coding, some are transitioning to rigorous methodologies: documentation, specification, agent, verification. An analysis of Claude Code setup from an architect at YADRO is one of the first systematic Russian-language materials on this topic. The series is worth following for those who still work with AI tools intuitively.