This content originally appeared on DEV Community and was authored by Koyelia Ghosh Roy
I used to open an editor and “see what happens!” mode.
Kiro made me slow down—in a good way. I now start every project with a one-page blueprint: the goal (enterprise-aligned procurement copilot), the agents definition and scope (like Negotiation, Compliance, Forecast), and a set of Advanced Context Engineering rules. In plain English: pin a Global Policy Context that can’t be pruned, budget the rest of the context (DSC/TSC/ETC) so prompts don’t bloat, and run every draft through a Global Policy Critic before it leaves the house.
From there I went spec-to-code. Each feature became a short “work order” Kiro could act on: the route, request/response shape, constraints (local LLM via Ollama gpt-oss:20b, CPU-friendly token budget), and what “done” looks like. Kiro turned those specs into a clean FastAPI skeleton with the same rails for every agent: pre-hook context assembly, post-hook policy review. That consistency killed a ton of drift and “local optimizations.”
I also stopped blaming prompts for runtime problems. When 20B on CPU dragged, I asked Kiro to help with defensive engineering: longer HTTP timeouts, smaller token budgets, and a triple-fallback LLM client (OpenAI-compat → Ollama chat → Ollama generate). No more mysterious empties—either I got text or a clear error.
The best part? Iteration felt honest. My spec doubled as living tests. I could hit /agent/negotiation, /agent/compliance, /agent/forecast and immediately see the critic add warranties, strip risky clauses, or enforce budget variance. If policy changed, I tweaked the GPC or budgets—not a dozen prompts.
Kiro didn’t just speed me up; it shifted my mindset from “prompt until it works” to engineering by contract. Smaller specs, reusable hooks, measurable alignment. It feels calmer, more deliberate—and the result is enterprise-first by construction.
This content originally appeared on DEV Community and was authored by Koyelia Ghosh Roy