This is Part 2 of a 4-part exploration of how coding philosophies, specs, and tools are evolving in the age of AI. If you're new to using AI for software development, you can read about the stack driving this change, here.
Let's start by briefly discussing Vibe Coding and comparing it to other philosophies such as AI-Assisted Engineering and Agentic Development. I feel it is important to understand the differences before we discuss how-to include them in your current workflow.
Vibe Coding vs. AI-Assisted Engineering
The term “Vibe Coding” was coined by Andrej Karpathy. He defined it as,
Where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
While, it might be easy to “forget that the code even exists” for MVPs or greenfield projects, this doesn’t scale very well when implemented on existing production-grade software. When you start vibe coding on an existing project, you'll see that the LLM would start making it's own creative decisions which might differ from your own, resulting in duplicate code, conflicting approaches and accumulation of technical debt. You basically skip the engineering part in software engineering and go with the flow.

AI-Assisted Engineering, on the other end of the spectrum, augments engineering practices instead of bypassing them. The term has been used since at least 2020, describing it as:
Data-driven process automation across the engineering lifecycle.
In software, it means using AI as an accelerator for established development practices: generating code, suggesting fixes, or automating documentation and tests.
Unlike vibe coding, AI-Assisted Engineering is grounded in process. It relies on clear specs, human review, and iterative feedback loops. Developers still own design and architecture decisions but delegate lower-level or repetitive tasks to AI. This structured collaboration between humans and AI is what paves the way for Agentic Development. This shows a shift from creativity without guardrails to collaboration built on process. Yet even AI-Assisted Engineering has limits: it depends on human initiation and oversight for every task.
Agentic Development
The next step, Agentic Development, extends that foundation by giving AI systems the ability to act on defined intent. Instead of waiting for instructions, agents can plan, execute, and coordinate work within defined boundaries, moving from just assistance to autonomy.
It builds on the concepts of AI-Assisted Engineering but the added autonomy makes AI feel less like a tool and more like a colleague helping you with repetitive tasks so that you can focus on creative ones.
Structure for Autonomy
As agents gain autonomy, structure becomes essential. Without it, you risk recreating the same unpredictability that made vibe coding unreliable in larger systems. Agentic Development works best when intent, behavior, and quality expectations are defined up front. Two techniques that help provide this structure are Spec-Driven Development (SDD) and Breakthrough Method for Agile AI-Driven Development (BMAD).
Spec-Driven Development (SDD)
Spec-Driven Development or SDD is a modern take on older software design methodologies. It starts with writing a spec document — describing the purpose, requirements and scenarios for a change — in a format that both humans, as well as AI agents can understand. Once a spec has been defined, tasks are created from this spec and finally an AI agent can work on the implementation.
By grounding AI collaboration in specs, we can reduce ambiguity and prevent model drift. Agents can reason, act, and self-correct within a clearly defined frame. This allows developers to better trust AI agents and sets foundation for multi-agent workflows. For example, with a common spec, writing tests and feature implementation can be delegated as two separate tasks to two separate agents enabling them to work in parallel. I do agree that this might be easier said than done at this stage but having the foundation that enables this possibility in the future is quite mind-boggling itself.
But writing spec documents seems like too much effort, right? This part too would be done in collaboration with AI agents. We already have multiple frameworks out there — Spec-Kit and OpenSpec to name my favorite two — that enable you to write and manage specs with the help of LLMs. We'll discuss them in Part 3 of this series where I'll show you how-to practice SDD in your daily workflow.
Breakthrough Method for Agile AI-Driven Development (BMAD)
BMAD is a meta-framework that brings Agile to agentic systems. It was designed to solve the lack of process structure and reproducibility when multiple agents work in parallel, in early AI-assisted workflows.
It follows a four-step iterative cycle — Analysis, Planning, Implementation, and Validation — executed by specialized agents (Analyst, Scrum Master, Developer, QA, and others). Each step produces structured artifacts and hand-offs, allowing other agents to continue the workflow autonomously.
At its core, BMAD emphasizes:
Clear separation of roles – 19+ specialized agents, each with defined tools, scope, and success criteria.
Continuous iteration – every workflow is designed to be testable, traceable, and repeatable.
Multi-agent collaboration – autonomous agents coordinate through shared artifacts, checklists, and validation gates.
SDD or BMAD?
Now the question remains, SDD or BMAD? BMAD, is a comprehensive meta-framework, which would work better for greenfield projects. It's structure enables you to scale but requires buy-in and organizational change. SDD on the other hand is lightweight and adaptable. It can work for both greenfield and brownfield projects. But where it shines is that it can be adopted by a single developer without having to change existing workflows. This enables you to start small and automate your workflows, one at a time.
In the end, both share the same goal: turning AI agents from a coding assistant into a reliable engineering partner, just at different levels of ambition. I'd recommend SDD as the starting point for almost any team because of it's lightweight nature and very shallow learning curve.
The philosophy of Agentic Development isn’t just conceptual, it’s meant to be applied. In the next part of this series, we’ll move from ideas to execution: how to integrate SDD into real development workflows, what tools make this possible, and how to introduce agentic practices augmenting your existing development experience.

