I Built a Conversational Todo Manager with Codev!

[waleedkadous]

I Built a Conversational Todo Manager with SPIDER and TICK Protocols

I just finished building a conversational todo manager using the SPIDER and TICK protocols, and I wanted to share the journey with the community!

🚀 Live Demo: https://codev-demo.up.railway.app/
👉 Repository: https://github.com/ansari-project/codev-demo
📖 Full Tour: https://github.com/ansari-project/codev-demo/blob/main/codev-tour.md

See It In Action

The app in action: managing todos through both the GUI and conversational AI interface. Here, the AI is adding relevant emojis to all todos based on a natural language request.

What I Built

A Next.js 15 todo application with a twist—it has dual interfaces:

1. Traditional GUI: Standard todo list with inline editing, status management, and due dates
2. Conversational AI: Chat with Google Gemini to manage your todos using natural language

The interesting part? Both interfaces work with the same local data, stored entirely in your browser using IndexedDB. No backend database needed.

The Interesting Technical Bits

This project has some fun architectural complexity that made it a great demonstration of Codev:

🗄️ Local Browser Storage

All todos are stored in IndexedDB (browser's local storage), so your data never leaves your machine. This meant designing proper storage abstractions, handling asynchronous operations, and ensuring data consistency between the two interfaces.

🤖 MCP Interface Pattern

The conversational interface uses the Model Context Protocol (MCP) to communicate with Google Gemini. Here's where it gets interesting: instead of exposing your API key to the client, I implemented a server-side MCP endpoint that acts as a secure proxy.

🔀 Fancy Local Redirection

The MCP server runs as a local service on your machine. The app does some clever redirection to route requests through this local MCP server, keeping your API keys safe while maintaining the simplicity of client-side storage. This pattern lets you run AI-powered apps entirely locally without exposing credentials.

The Development Process

I followed the SPIDER protocol (Specify → Plan → Implement-Defend-Evaluate → Review) for the main feature across 14 git branches, then used the TICK protocol (fast autonomous implementation) for smaller additions like Railway deployment and bug fixes.

The Numbers

• ~2,500 lines of production code
• ~2,000 lines of specs, plans, and reviews
• 75 automated tests defending the implementation
• 2 complete development cycles (SPIDER + TICK)

The Tour

I created a detailed walkthrough at codev-tour.md that shows:

• How the specification captured requirements
• How planning broke work into 7 phases
• The Implement-Defend-Evaluate loop in action
• Multi-agent consultation with GPT-5 and Gemini Pro
• How TICK protocol handled quick iterations
• All the lessons learned along the way

The tour is basically a "behind-the-scenes" look at context-driven development. You can see every spec, plan, and review that went into building it.

Key Takeaways

1. Architecture emerged from specs: The MCP pattern and local storage strategy came from thinking through security and simplicity requirements in the specification phase, not from coding first.

2. Multi-agent consultation saved time: Having GPT-5 and Gemini Pro review the plan caught issues before implementation, reducing rework.

3. Tests as defense: The "Defend" phase forced me to think about edge cases and failure modes, resulting in more robust code.

4. Context drives code: Having clear specs meant the implementation was straightforward—I knew exactly what to build and why.

Try It Out!

The repo has full instructions for running it locally. I'd love to hear feedback or see what others build with Codev!

Questions? Happy to discuss any part of the architecture or development process.

---

Built using Codev - where context drives code