Blog
3 min read

Adopting the 'Vertical Slice' Philosophy for Spec-Driven Development

Attempt at building and maintaining understanding in the era of vibe-coding.

Advait LonkarAdvait Lonkar@advait_l

Setting up a project in today's day and age, with AI coding agents improving at a break-neck speed is a whole new game altogether. For my algorithmic trading project, that I have decided to pursue, I am going to try my hand at spec-driven development. I have seen a few mature enterprise codebases in my years of experience, and though they were mostly developed pre-AI and who knows how they are going to look in the future, there was certainly a lot to learn from them.

They more often than not featured a matured documentation strategy - with Solution Architecture Document (SADs), Product Requirement Document (PRDs), Architecture Decision Records (ADRs) and many other guides, references, runbooks, How-Tos and more. The true value of these wasn't really the content in them, but the process they enabled in having a feature or a PoC be built, validated against options, and then approved for actual production-grade development.

So for my algo-trading project, I have decided to adopt one such system, with many ADRs outlining the different standards in the codebase for different aspects of the codebase - branching strategy, unit-testing, build-tooling, project-structure, semantic-constraints, data-contracts and many more. The SAD, PRD and ADRs are all evolvable documents, and alongside the code version history, these documents provide a great snapshot into the current state of the codebase & the architecture and how we arrived here. And with coding agents and the AGENTS.md file, it is quite easy to steer the coding agents to generate, modify and follow the conventions laid out in these documents, and proceed with implementation.

One major thing that I have adopted in this 'vertical slice' approach. So in addition to all the types of documents mentioned above, I am also maintaining a roadmap and a changelog, and at each iteration, there is a checklist which the codebase has to clear, otherwise the next iteration in the roadmap is not up for implementation. And that checklist ensures, that at every iteration the code runs end-to-end through the logical scaffolding of a algo-trading system, with toy fixtures to simulate everything. This way, I can always get an understanding of what is happening in my codebase all the time at a much deeper level that - dare I say - a vibecoder.

Of course I don't know how productive this is, or if there is any advantage in doing it this way or the thousand other ways to work with coding agents. But this is not about being at the top of productivity charts, this is about being proactive with coding agents, while simultaneously maintaining a serious understanding of my own project - which by its nature I would hope to put some money into, in the future.

Back to the blog