DEV Community

Patrick Deloulay
Patrick Deloulay

Posted on

Introducing Disko - Made with AWS Kiro

#kiro #ai #hackathon

I built Disko in 4 days with spec‑driven development using AWS Kiro. Signed-up for the Kiro Hackathon on DEVPOST https://kiro.devpost.com/ - in the Productivity & Workflow Tools category

Disko

Solopreneurs need a lightweight way to show progress to customers. Disko is a transparent public board: ideas flow from Parking → Now → Next → Later → Release. Your audience can see momentum; you focus on shipping.

Why Kiro?

Kiro calls this spec-driven development—moving from “vibe coding” to viable code by structuring intent up-front. See the product page for how specs, agent hooks, and task automation fit together: kiro.dev.

  • Learn
    • Writing specs forces clear product vision, acceptance criteria, and definition of done. You learn by articulating the system before building it.
  • Leverage
    • Use Kiro’s spec → design → tasks flow and agent hooks to automate changelogs, docs, and repeatable chores so you stay in flow.
  • Deliver fast
    • With scope locked in the spec, you avoid re‑prompt loops and drift. Small, time‑boxed sprints (48–96 hours) translate to shipped features.

The spec-to-build loop (with Kiro)

Kiro helped me turn a single prompt into living specs. Writing the spec forced a crisp product vision and a concrete definition of done—if a feature wasn’t in the spec, it didn’t ship. I kept three artifacts in the repo:

  • Requirements: roles, acceptance criteria, UI expectations (.kiro/specs/disko-board/requirements.md).
  • Design: architecture, models, endpoints, and components (.kiro/specs/disko-board/design.md).
  • Tasks: sequenced plan mapped to requirements (.kiro/specs/disko-board/tasks.md).

Kiro’s approach—“turn your prompt into clear requirements, system design, and discrete tasks”—is exactly what made four days feasible. It’s the structure that prevents thrash and scope drift. Reference: Kiro – The AI IDE for prototype to production.

What shipped in 4 days

  • Board management: create/list/delete, toggle public; auto public links.
  • Idea management: CRUD, RICE (Reach, Impact, Confidence, Effort), status changes.
  • Drag-and-drop board: Parking, Now, Next, Later, Release, Won’t Do.
  • Public boards: read-only via secure link; admin-only fields hidden.
  • Release table: sort and filter shipped items.
  • Feedback: thumbs up + emoji (rate-limited), realtime updates.
  • Email invites: one-click sharing of public boards.
  • Realtime: WebSockets for idea and feedback updates.

Screenshot below:

The 4‑day journey

  • Day 1 — Foundation
    • Project skeleton in Go with Gin, MongoDB v2 driver wiring, Clerk auth middleware, templating, and clean folders.
    • Wrote requirements and design with acceptance criteria; locked scope from the start.
  • Day 2 — Boards and ideas
    • Boards API (create/list/update/delete + public links) and Ideas API (CRUD + RICE validation).
    • Private board and dashboard templates; baseline JS modules.
  • Day 3 — Flow and public view
    • Drag‑and‑drop board interactions and status transitions into Release.
    • Public board view with safe field visibility and Release table with sorting/filtering.
  • Day 4 — Realtime, feedback, and polish
    • WebSockets for idea/feedback updates, feedback widget with rate limiting, email invites.
    • Changelog, visible version, docs alignment, and UI simplifications.

How Kiro accelerated delivery

  • Acceptance criteria → code: Each feature tied to a WHEN/THEN in the requirements.
  • Design anchors: Single source of truth for endpoints and models avoided drift.
  • Tasks with traceability: Fast progress checks and easy scope cuts under time pressure.
  • Agent-friendly flow: Where helpful, background tasks (docs/version notes) can be automated with agent hooks (see kiro.dev on “Automate tasks with agent hooks”).

Kiro’s principle of “more context, less repetition” and spec steering meant I could focus on decisions, not re-explaining intent.

Speed, concretely: where Kiro saved time

  • Spec-first clarity
    • Writing the spec once avoided dozens of back-and-forths during implementation.
    • Decisions like “server-rendered templates vs SPA” were captured early and held.
  • Design reuse
    • Endpoints/models defined in the design flowed directly into handlers and templates.
  • Task execution
    • The task list served as an execution queue; easy to parallelize UI + API work safely.
  • Automation hooks
    • Docs and changelog updates are repeatable chores—ideal for agent hooks as suggested on kiro.dev.

Kiro vs vibe coding: benefits

  • Vision to velocity
    • Specs force product vision and a concrete definition of done; vibe coding drifts with each prompt.
  • Traceability
    • Every change ties back to requirements and tasks; vibe coding lacks a durable audit of intent → code.
  • Convergence, not oscillation
    • Spec steering reduces re-prompts and rework; vibe sessions often loop on wording, not outcomes.
  • Safer autonomy
    • Agent hooks run scoped, automatable chores (docs, tests, versioning) under rules; vibe coding mixes intent and execution ad hoc.
  • Team onboarding
    • Requirements/design/tasks are living docs; vibe coding transcripts don’t scale as shared context.
  • Predictable scope cuts
    • Clear acceptance criteria make it easy to trim without breaking the product story; vibe coding hides scope in chat.
  • Operational hygiene
    • Changelogs, version bumps, and logs are part of the flow; vibe coding forgets these unless you remember to ask.
  • Simpler architectures win
    • Kiro’s spec discipline pairs well with KISS/DNR; vibe coding tends to accumulate accidental complexity.

Value for developers (solo and teams)

  • Solo builders
    • Reduce decision fatigue: specs fix the target, agents handle the grunt work.
    • Faster throughput: clear tasks → fewer detours → more shipped features.
    • Built-in hygiene: changelogs, version bumps, and logs stay consistent.
    • Focus on product: spend time on RICE, UX, and feedback loops, not boilerplate.
  • Teams
    • Shared context: requirements/design/tasks act as a single source of truth.
    • Onboarding: new teammates ramp with specs instead of scrolling chat history.
    • Consistency: agent hooks enforce docs/tests/versioning policies automatically.
    • Alignment: acceptance criteria prevent scope creep and reduce rework.
    • Auditability: intent → design → code trace makes reviews and retros easier.

Lessons learned

  • Specs multiply speed: They compress decisions and eliminate ambiguity mid-build.
  • Specifications force product vision and a finished end product; scope stays honest.
  • KISS + DNR scales: Clear packages, small functions, and direct DB access are fast.
  • Logs matter: Purposeful logs across init/auth/network paths speed up diagnosis.
  • Version what users see: A visible version reduces release confusion.
  • Defaults reduce friction: RICE defaults make idea creation fast.

Conclusion and next steps

  • Start with a one‑page spec.
    • Write roles, acceptance criteria, and a definition of done. Keep scope tiny (one board, one flow).
  • Generate design and tasks in Kiro.
    • Use the spec to create a system design and a task list. Treat tasks as the execution queue.
  • Keep it simple.
    • Prefer KISS/DNR: Go + Gin, MongoDB v2 driver, Go templates, and small JS modules.
  • Add guardrails early.
    • Configure agent hooks to automate changelogs, version bumps, and docs. Add lint/tests where it’s easy.
  • Ship in days, not weeks.
  • For teams
    • Do lightweight spec reviews. Make acceptance criteria the source of truth. Use hooks to codify hygiene (docs/tests/versioning). Track intent → design → code for auditability.

If spec-driven development resonates, explore Kiro’s docs, especially on specs and agent hooks: kiro.dev.

kiro

Top comments (0)