Vibe Coding a Todo App

We’ve been using Copilot for code completions since early this year. It’s useful, a typing accelerator. But the AI space has been moving fast, and I wanted to test something more ambitious: what happens if you let an AI agent write an entire application?

Not a toy snippet. A real program with a TUI, persistence, keyboard navigation, scheduling, notifications. Something you’d actually use.

Tuido

The idea was simple: a terminal-based todo app for quick “remember to do this” tracking during the work day. The kind of tool that should live in a terminal window, be keyboard-driven, and stay out of your way. We used OpenAI’s latest model through an agentic coding setup: describe what you want, let the agent write the code, iterate on the result.

Rust was a deliberate choice. If the AI can produce working Rust, with its borrow checker, lifetime system, and strict type safety, that tells you something about the capability level. Rust doesn’t let you be sloppy.

The result: Tuido. A TUI todo app with task creation, editing, completion, scheduling with natural language dates (“tomorrow at 9pm”), desktop notifications for overdue tasks, persistent storage to ~/.config/tuido/todos.json, and a help menu. All keyboard-driven.

What worked

The agent handled the structural code well. Setting up the TUI framework (ratatui), the event loop, keyboard input handling, rendering text with colors and styles. It wrote this correctly and mostly idiomatically. The Rust compiler caught the few mistakes, and the agent could usually fix them when shown the error.

JSON persistence was trivial for it. Serde serialization, file I/O, creating the config directory if it doesn’t exist. This is the kind of boilerplate that AI handles perfectly: well-established patterns with clear conventions.

The natural language date parsing worked on the first try. It picked a crate (chrono), wrote the parsing logic, handled timezone conversion. Not perfect, and we had to fix some UTC issues, but the skeleton was right.

What didn’t work

Taste. The initial UI was functional but ugly. Wrong colors, inconsistent spacing, information density too high. The agent had no opinion about what looks good in a terminal. We spent time massaging the rendering: subdued colors for completed items, no icons on completed todos (visual noise), overdue items highlighted but not screaming. These are judgment calls that the agent couldn’t make.

Edge cases in interaction design. Moving the cursor during add/edit mode. What happens when you try to edit a completed item. How the help menu should overlay the main view without destroying it. Each of these required a specific decision about UX, and the agent either didn’t think of them or made the wrong call.

The code was also… fine. Not bad, not great. It compiled, it worked, but it wasn’t the code I would have written. Variable names that were slightly off. Functions that were slightly too long. Patterns that were slightly non-idiomatic. Each individually acceptable, but together they added up to a codebase that felt generated rather than crafted.

The realization

Tuido is a useful app. I use it daily. But building it taught me something about where AI-assisted development is and isn’t ready.

For a small, well-scoped application with established patterns, like a todo app, a CLI tool, or a simple web service, vibe coding works. Describe what you want, let the agent build it, polish the result. The AI handles the mechanical parts. You handle the taste.

For anything with real architectural complexity, like our design system, our artifact registry, or our git platform, vibe coding would fall apart. These systems have deep design decisions that compound over time. The choice to use content-addressable blobs in Flux. The YAML-driven RBAC hierarchy in Codex. The three-layer semantic token architecture in Sirius2. An AI agent wouldn’t make these decisions. It would make a decision, and it might be reasonable, but it wouldn’t be the right decision for our specific context.

AI is getting better fast. Faster than I expected. But the gap between “can write a todo app” and “can architect a design system” is not a gap that’s closing linearly. The hard parts of software engineering, the architecture, design, trade-off analysis, and system thinking, are still ours.

For now, anyway. I’m watching this space closely.