Your team installed Copilot or Cursor. Output went up. But so did the time spent in code review, fixing subtle bugs the AI introduced, and arguing about whether the generated code follows your patterns. Net productivity gain? Hard to say.
The problem isn't the AI tool. It's using it without structure. A spec with clear acceptance criteria produces better output than "make a login page." Steering files that encode your error handling and API conventions eliminate rework. The teams I've seen get real gains from AI coding tools have invested in the process around them, not just the license.
AI without structure
- β Generated code that "works" but ignores your patterns
- β Security logic written by autocomplete
- β PRs that take longer to review than to write by hand
- β Every developer getting different output for the same kind of task
AI with spec-driven workflows
- β Output that matches your codebase on first generation
- β Clear boundaries on what AI touches and what it doesn't
- β Reviews focused on design, not style nitpicks
- β Consistent patterns regardless of who prompted
- β Audit trail from requirement to implementation
What I help teams build
Steering files that actually work
Not a 50-page style guide the AI ignores. Short, pattern-specific documents that get included when relevant: "when editing a Lambda handler, here's how we do error handling, logging, and response formatting." Concise enough to fit in context, specific enough to produce good output.
Spec templates your team will actually use
Lightweight structures for breaking features into requirements, design decisions, and tasks. Not waterfall. More like "enough structure that the AI gets it right on the first try instead of the third."
Policies that enable instead of restrict
Where does AI shine? CRUD operations, tests, boilerplate. Where do humans stay in the loop? Auth logic, compliance code, data migrations. Written for developers, not legal.
Hooks and checks that catch problems early
Pre-commit validation, automated reviews, guardrails that flag when the AI is going off-pattern. Cheaper to catch it here than in a production incident.
Why I have opinions about this
I've been building with Amazon Kiro since early access. Not writing thought pieces about it β actually shipping features with spec-driven workflows, daily, for real applications. My open source libraries are built this way. My consulting projects are built this way.
I also know it's not magic. Spec-driven development requires more design thinking upfront, not less. The teams that get value from it are the ones whose senior engineers shift time from typing code to writing specs. That's a change in how people work, and it doesn't happen by installing a tool.
Two ways I can help
π οΈ
Set up your AI workflow
I'll audit your current development process, build steering files for your codebase, create spec templates, define policies, and train your team. You're self-sufficient when I'm done.
Typically 2-4 weeks
β‘
Build features with AI
I'll spec and build features for your application using AI-assisted workflows. You get production-ready code, full documentation, and a working example of how spec-driven development looks in practice.
Project-based pricing
Frequently Asked Questions
What is spec-driven development?
Spec-driven development is a workflow where engineers define requirements and design decisions upfront, then let AI handle the implementation. Tools like Amazon Kiro formalize this into structured specs with requirements, design documents, and task lists that the AI executes against. The engineer focuses on what to build and why; the AI focuses on how.
How do steering files improve AI code generation?
Steering files are markdown documents that provide persistent context to AI coding tools. They encode your team's standards, architectural patterns, naming conventions, and project-specific knowledge so the AI generates code that matches your codebase from the start, rather than producing generic output that needs heavy revision.
Is AI-assisted development just for greenfield projects?
No. AI-assisted development is often more valuable in existing codebases where there are established patterns to follow. Steering files can encode those patterns, and spec-driven workflows help break down changes into safe, reviewable increments. The key is teaching the AI your codebase's conventions rather than letting it invent its own.
What policies should teams have around AI coding tools?
Teams need clear guidelines on: what code AI can generate vs what needs human authorship (security-critical paths, compliance logic), how AI-generated code should be reviewed, what data can be shared with AI tools, and how to handle attribution and licensing. The goal is enabling productivity while maintaining accountability and security.