Introduction
This project starts from something very simple: a Google Form that collects sprint check‑ins and feedback, all ending up in a single spreadsheet.
Inside that sheet is a mix of important signals – who has finished their work, how confident people feel, and where someone might be struggling – but in its current form it’s hard to act on quickly. The aim of this series is to turn that spreadsheet into a small, reliable backend that makes those signals easier to see and work with.
I also want to use this project as a chance to experiment with spec‑driven development and with Kiro – an AI‑assisted IDE that helps me write requirements, designs, and tasks before I touch the actual implementation.
Step 1 – Starting from a spec (with Kiro)
Before writing any code, I asked Kiro to help me describe the system I wish existed. Instead of jumping straight into implementation, I worked through a spec‑driven flow: capturing requirements, shaping a design, and breaking things down into tasks I can actually build.
Kiro sits inside my editor and acts like a structured copilot: I can say “I have this form and I want to turn it into a marking/feedback tool” and it helps me turn that into a requirements document, a design with clear components, and a set of concrete tasks I can pick up one by one. It feels less like “write some code with AI” and more like “design the system together first, then implement”.
For this project, that ended up as three files:
-
requirements.md– what the tool should do, who uses it, and the acceptance criteria. -
design.md– how the system is put together: main components, data model, and the AWS pieces it will use. -
tasks.md– a checklist of implementation steps, each tied back to one or more requirements.
At this point I have a requirements file, a design document, and a generated task list – but still no running code. In the next part of this series, I’ll start turning that written design into a concrete architecture and the first implementation steps.
Top comments (0)