From Vibe Coding to Engineering: A Practical Kiro Workflow for Coding Agents

The shift: from asking for code to engineering the loop

The most useful change in how I think about coding agents is that the prompt is not the product. The product is the loop around the model: what context it receives, what objective it is pursuing, which tools it can use, how success is checked, what evidence survives the session, and when a human should intervene.

Andrew Ng’s 2026 writing makes this broader than prompt technique. His AI Engineering Skills Map separates building and deploying AI applications, software-engineering fundamentals, using coding agents, and shaping the build; his loop-engineering essays emphasize an agentic coding loop inside slower developer and external-feedback loops. The implication for me is that faster code generation increases the value of architecture, specification, verification and product judgment rather than replacing them.

Ng has also described agentic loop coding as letting an agent continue until it satisfies a condition such as a product specification. That framing moves attention from producing one impressive answer to defining a measurable stopping condition. A capable model can iterate, but iteration without an acceptance test is only repeated guessing.

1. Start with a specification, not a giant prompt

DeepLearning.AI's Spec-Driven Development with Coding Agents course, taught by Paul Everitt in partnership with JetBrains, formalizes a useful hierarchy: a project constitution establishes mission, technical boundaries and roadmap; each feature gets requirements and validation criteria; implementation follows the specification rather than reconstructing intent from chat history.

In Kiro, I can apply this directly with Specs. For a meaningful engineering application I want requirements to state the system boundary, inputs, outputs, assumptions, failure behavior and acceptance tests. For analytics, I also want expected grain, units, source provenance and known exclusions. The agent can help draft these artifacts, but the specification is valuable precisely because I can inspect and correct it before code amplifies a misunderstanding.

2. Treat context as an architecture

Always-loaded context should be small. Kiro steering is appropriate for durable project conventions and boundaries; file-matched or automatically included guidance is better for specialized domains; Skills are better for reusable procedures that should load only when needed. This is progressive disclosure applied to agent context.

My attached Kiro notes reinforce a practical rule: link to detailed material rather than stuffing it into every session. A short project contract can point to deployment guidance, SQL rules, analytical definitions or a query catalog. This reduces context noise while preserving discoverability. The same principle applies to AGENTS.md and repository documentation: make the entrance concise, then let the agent retrieve depth deliberately.

3. Use deterministic checks for deterministic truths

A model should not be asked to 'remember' facts that software can validate. Formatting, schemas, duplicate keys, SQL grain, required columns, test results and forbidden paths are better enforced by code. Kiro hooks can run shell commands or agent prompts on defined events, and some pre-action hooks can block when deterministic checks fail.

The distinction is important: steering is guidance; a test is evidence; a blocking validation command is enforcement. If a generated query must preserve one row per task, write a fixture that fails when a one-to-many join inflates the result. If a schedule must respect capacity, verify overlaps programmatically. Prompts can explain the rule, but checks should prove the property.

4. Add agents only when responsibilities actually separate

It is tempting to turn every workflow into planner, coder, reviewer, tester and critic agents. Anthropic's guidance on effective agents argues for starting with the simplest composable pattern that works and adding complexity only when the benefit justifies latency and cost. My graph-workflow notes reach the same conclusion from a Kiro perspective.

Delegation is useful when workers can have genuinely different context, tools or output contracts—for example, an implementation worker and an independent validator. A workflow graph is useful when dependencies, retries, approvals or recovery are real requirements. If one Kiro session plus a test command solves the task reliably, an elaborate orchestration graph is architecture theater.

5. Think in graphs when the work really is a graph

Some engineering tasks do have explicit dependency structure. A SQL change can depend on schema inspection; validation depends on the candidate revision; a deployment should depend on tests; a review may invalidate downstream work. Modeling those dependencies makes selective retry possible: rerun the failed node and its descendants rather than restarting everything.

The attached graph-workflow prompt adds two disciplines I find especially useful: bound correction loops so repeated failure becomes a report rather than infinite churn, and compare the graph against a simple baseline. A workflow should earn its complexity by improving reliability, recovery or reviewability.

6. Separate delivery from learning

A particularly useful idea from Lamis Mukta's AI Native DevCon talk is to separate the live task loop from a later learning loop. During delivery, the agent implements, checks and repairs. Later, a separate process can review evidence across completed sessions, identify recurring gaps and propose changes to reusable project memory or procedures.

That separation prevents one bad session from silently rewriting the rules for every future session. Proposed lessons should carry evidence, scope, confidence, version information and a validation method. Promotion should be reviewable and reversible. This is closer to configuration management than to a magical self-improving model: the model weights are not changing; the future context is.

7. Build an analytical truth layer for data-heavy work

Coding agents become much more useful for engineering analytics when they can retrieve authoritative definitions instead of inferring business meaning from old SQL. My Analytics Truth Registry concept treats grain, joins, temporal semantics, metric definitions, basis-of-estimate rules and provenance as versioned contracts.

This creates a strong division of labor. Retrieval can tell the agent what a metric means and which join keys are required. Deterministic validation can return PASS, FAIL or REVIEW_REQUIRED. The model can explain the finding and propose a correction, but it should not promote an observed legacy query into authoritative truth merely because it appears frequently.

8. MCP is a tool boundary, not agent intelligence

Kiro's MCP support is useful when an agent needs approved access to documentation, databases, deployment status or other services. But connecting an MCP server does not make a workflow reliable by itself. Tool descriptions, permissions, input validation and the trust boundary still matter.

For enterprise work I prefer narrow, read-oriented tools first: retrieve schema metadata, search approved documentation, run a parameterized query, or inspect deployment state. Credentials stay outside prompts and repositories. A model-facing tool should expose the smallest useful operation rather than a generic execute-anything surface.

9. A practical Kiro pattern I can actually use

For a new feature: first ask Kiro to inspect the repository and write or refine the feature spec. Second, confirm assumptions and acceptance criteria. Third, implement in bounded increments. Fourth, run deterministic tests and browser checks. Fifth, have a review pass inspect the diff against the spec rather than against vague intent. Sixth, record unresolved issues and useful evidence.

For recurring work, move stable project conventions into steering, reusable procedures into Skills, cheap deterministic automation into Hooks, and external capabilities behind approved MCP tools. If repeated sessions expose the same failure, propose a memory or procedure change and evaluate it separately. The result is not autonomous software development; it is a progressively better engineered collaboration between a human, an agent harness and deterministic tooling.

What I would avoid

I would avoid one enormous always-loaded instruction file, agents that exist only to role-play job titles, hooks that trigger expensive loops after every edit, memory that promotes every failure into permanent policy, and claims that a workflow is reliable because the model said its own output looked correct.

The most important novice lesson is that Kiro's features are not interchangeable. Specs define what should be built. Steering supplies durable context. Skills package procedures. Hooks react to events. Custom agents constrain a specialized working context. Subagents delegate bounded work. MCP connects tools and data. Tests and validators establish evidence. Used together selectively, these pieces create a development system rather than a larger prompt.