How Kiro Changed the Way I Build (for real)

Koyelia Ghosh Roy — Mon, 15 Sep 2025 16:25:28 +0000

Building ProcureSense with KIRO: the moment hooks + specs changed everything

I used to start projects the way a lot of us do: open an editor, try a prompt, nudge things until they kind-of work. With KIRO, I stopped “winging it” and started building on rails.
The rails were two things: agent hooks and spec-to-code. Together, they let me vibe-code from scratch without creating future pain.

When hooks clicked:
In ProcureSense (a multi-agent procurement PoC running Llama 3.1 8B via Ollama, locally), every flow now wraps an agent with two tiny but powerful steps:
-Pre-hook: assemble context before generation—policy, domain strategy, task/session state, and any live tool data.
-Post-hook: send the draft through a policy critic that fixes risky clauses or misaligned terms.

Practically, it means I don’t “remember to add the safety bits” each time. The hooks are declarative files (.kiro/hooks/...), so they’re always on.
When I save a contract, the contract-analysis hook runs.
When a forecast updates, the budget variance hook runs.
No heroics, just predictable behavior.

Specs → code (and fewer regrets)

The other shift: I stopped free-handing endpoints.
I write a short spec in plain language—route,request/response, constraints, “done” looks like X—and KIRO turns it into a FastAPI scaffold with Pydantic models and examples.
That little ritual flips my mindset from “let’s try something” to engineering by contract. Specs live under .kiro/specs/... (requirements, design, tasks) and become living tests I can hit immediately.

Vibe coding, but with guardrails
Hooks + specs gave me the confidence to move quickly. To keep outputs enterprise-aligned (not just locally optimal), I enhanced the rails with Advanced Context Engineering:
-A Global Policy Context is pinned (never pruned).
-Deterministic budgets across DSC (Domain Strategy), TSC (Task/Session), and ETC (Ephemeral Tool) with pruning order ETC → TSC → DSC → GPC (never).
-Every draft is gated through the policy critic post-hook.

It feels lightweight in practice: I experiment freely, while the rails keep agents honest.

Hybrid deployment that fits real life
-FastAPI gives me production-grade REST, async performance, and type-safe contracts—easy to integrate when this grows up.
-ngrok gives me an instant HTTPS URL to the same local API—no cloud setup, no cost—so stakeholders can click and see the real thing.
The best part: it’s a hybrid path. I develop on-prem/CPU today; later I can swap ngrok for VPC/Kubernetes with no code changes.

What actually changed for me
-I ship faster because specs remove ambiguity.
-I break less because hooks make good behavior default.
-I sleep better because context budgets and a policy critic keep outputs aligned to enterprise rules by construction.

If you’re curious, start with :
-one page: the routes you need, the data you accept/return, and the guardrails that can’t be skipped.
-Add two hooks (pre/post), keep context budgets explicit, and you’ll feel the same shift I did—from coaxing a prompt to designing a system.

Repo: https://github.com/koyeliaghosh/ProcureSense-Kiro
Project page: https://koyeliaghosh.github.io/ProcureSense-Kiro/

How Kiro Changed the Way I Build (for real)

Koyelia Ghosh Roy — Mon, 15 Sep 2025 11:52:01 +0000

I used to “open editor → improvise.” Kiro flipped that.

I now start with a one-page blueprint and Advanced Context Engineering (ACE): pin a Global Policy Context (GPC) that can’t be pruned, budget the rest (DSC/TSC/ETC) deterministically, and gate every draft through a Global Policy Critic. From there, I go spec-to-code: tiny work orders (route, schema, constraints, “done” checks). Kiro turns that into a clean FastAPI backbone where every agent runs on the same rails—pre-hook context assembly, post-hook policy review—so no agent “optimizes locally” and drifts from enterprise goals.

Why hybrid architecture approach (FastAPI + ngrok)?
FastAPI (production backend)
Enterprise-grade REST + OpenAPI docs

Async performance for concurrent agents

Pydantic type-safety & contract enforcement

Scales for high-volume procurement flows

Easy enterprise integrations

ngrok (global access)
Instant public URL to local server (no cloud bill)

HTTPS by default

Stakeholders can see the real system, live

Strategy (multi-tier)

🏢 FastAPI: complex multi-agent workflows + full LLM processing

🌐 ngrok: tunnel for real-time judge access

🚀 Pure-Python demo: zero deps, runs anywhere

Where ACE lives in the code

Hierarchical budgets — src/context/budget_config.py

@dataclass
class ContextBudgetConfig:
gpc_percentage=0.25; dsc_percentage=0.25
tsc_percentage=0.40; etc_percentage=0.10

Dynamic pruning — src/context/context_manager.py

ETC → TSC → DSC → GPC (GPC is pinned)

def prune_context(...): ...
def build_context(agent_type, request): ...

TSC uses rolling summaries; DSC preserves key strategy.

Token accounting — src/context/token_counter.py
Budget checks before/after pruning; every layer tracks usage.

GPC protection — src/context/gpc_manager.py

def is_gpc_pinned(): return True

Even under extreme pressure, GPC survives.

In practice:

Negotiation: GPC blocks prohibited terms; DSC adds category strategy; TSC recalls prior rounds; ETC injects current quotes.

Compliance: GPC enforces legal rules; the critic auto-repairs risky clauses.

Forecast: GPC budget thresholds override optimistic local forecasts.

**Net effect: **Kiro moved me from “prompt until it works” to engineering by contract—small specs, reusable hooks, measurable alignment—delivered via FastAPI + ngrok and grounded by ACE so the system is enterprise-first by construction.

DEV Community: Koyelia Ghosh Roy

How Kiro Changed the Way I Build (for real)

How Kiro Changed the Way I Build (for real)

ETC → TSC → DSC → GPC (GPC is pinned)