The AI Development Loop: How We Ship AI Features in Days and WHY we Love Kiro
People keep asking how a small team delivers production AI tools this fast. The answer isn't "we vibe code". It's a closed-loop system where AI participates in every stage, but humans steer every decision.
Building the future of professional networking with AI | AWS & Data Architect | CTO @ JuntoAI
"How are you shipping this fast?" I get this question a lot.
We launched JuntoAI Kinetic, a real-time AI voice interview system, and we keep pushing major features every week. A user portal with six sections. A CV readiness evaluator. A LinkedIn evaluator. Conversion analytics. Email tracking. LinkedIn data integration. Second interview sessions. Each one production-ready, tested, deployed. And JuntoAI Echo, your AI-human enabled copywriter, is already on the way.
People assume it's because we're "vibe coding". Just prompting an AI and shipping whatever comes out. It's not! What we've built is something more deliberate: a closed-loop development system where AI participates in every stage of the product lifecycle, but humans make every strategic decision.
Here's how it actually works.
The Loop
Human interviews users
↓
AI analyzes discovery data
↓
AI generates structured user stories
↓
AI implements the code
↓
Pre-built CI/CD pipelines test and deploy
↓
Users interact with the new version
↓
Users provide feedback via forms
↓
AI analyzes feedback → new user stories
↓
(repeat)Every step in this loop is real. Every step is happening in production right now. Let me walk through each one.
Step 1: Humans Do the Discovery
This is the part that can't be automated and shouldn't be. A human sits down with users, real professionals, real career frustrations, real workflow problems, and listens. Not a survey. Not a chatbot. A conversation.
The insight that Kinetic needed a "Pushback Loop", where the AI challenges vague answers like "I improved sales" with "Give me the percentage and the timeframe", came from asking users and seeing the output quality suffer. No AI would have identified that pattern from analytics alone. It took a human noticing that the interesting stuff only came out when someone pushed back.
Discovery is human work. It always will be.
Step 2: AI Analyzes and Structures the Findings
Here's where AI enters the loop. After discovery sessions, we feed the raw notes, transcripts, and observations into our development environment. The AI structures it, which is more than a summary.
In our workflow, this produces formal requirements documents. Here's a real example from our codebase: Spec 330, CV Evaluator Conversion Analytics:
### User Story 1: View All-Time Conversion Rates
**As a** CareerGraph admin
**I want to** see all-time conversion rates for the CV evaluator funnel
**So that** I can understand overall funnel performance since launch
**Acceptance Criteria**:
1. The admin CV-Evaluator tab SHALL display a "Conversion Metrics" section
2. The section SHALL show three all-time conversion rates:
- CV Evaluation Start → Email Captured
- CV Evaluation Start → Kinetic Interview Started
- CV Evaluation Start → Kinetic Profile Registered
3. Each metric SHALL display as a percentage with one decimal place
4. Each metric SHALL include the absolute countsIt's a structured requirement with acceptance criteria, data model definitions, API contracts, caching strategy proposals, and security considerations. The AI generated all of it, but from human-provided discovery insights.
Step 3: AI Designs and Implements
Each feature follows a three-document structure:
-
requirements.md— What we're building and why (from discovery)
-
design.md— How we're building it (architecture, data flow, API contracts)
-
tasks.md— Step-by-step implementation plan with requirement traceability
The tasks document is where it gets interesting. Here's a snippet from our Kinetic Portal V1 spec: a full user dashboard with six sections, backend API extensions, and responsive design:
- [ ] 3.6 Create `DashboardSection.jsx` page component
- Fetch portal data via `portalApi.getPortalData()` on mount
- Render session list using `SessionCard`, ordered newest first
- Display "Start New Interview" button linking to `/interview`
- Show empty state when zero sessions
- Render Resume Quality Score and LinkedIn Match Score using `ScoreRing`
- Handle loading and error states per Requirement 14
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 4.1, 4.2, 4.3, 5.1, 5.2, 5.3..._Every task traces back to specific requirements. Every requirement traces back to user discovery. The AI implements each task, and the implementation is grounded in the full context of the project: the architecture, the data model, the API contracts, the testing standards, and the brand guidelines.
This is possible because of how Kiro handles context. We have 15 steering files that give the AI persistent knowledge about our project:
.kiro/steering/
├── careergraph-structure.md # Service architecture, key files, data model
├── careergraph-product.md # Product vision, personas, business model
├── careergraph-nova-integration.md # Nova Sonic/Lite integration patterns
├── tech.md # Full technology stack, conventions
├── testing.md # Test framework, coverage targets, CI/CD
├── styling.md # Design system, Tailwind config, CSS architecture
├── deployment.md # Infrastructure, Terragrunt, pipeline rules
├── llm-usage.md # AI model selection, cost optimization
└── ...When the AI implements a feature, it knows that CareerGraph uses ESM imports (not CommonJS), that DynamoDB tables are named
juntoai-careergraph-data-{env} , that the frontend uses Tailwind with specific brand colors (#007BFF primary, #00E676 for AI indicators), and that tests must hit 70% coverage. It doesn't guess. It knows.Step 4: Pipelines Test and Deploy Automatically
This is the part most people skip when they talk about AI coding. Implementation is maybe 40% of shipping. The other 60% is making sure it actually works in production.
We have pre-built CI/CD pipelines that catch problems before users ever see them:
- Kiro hooks that automatically run tests when code changes:
{
"name": "Push Vitest Check",
"when": { "type": "shellCommand", "command": "git push" },
"then": {
"type": "askAgent",
"prompt": "Run the vitest test suite to verify all tests pass before the code is pushed."
}
}- GitHub Actions workflows with path-based triggers: CareerGraph tests only run when CareerGraph code changes
- AWS CodePipeline for automated Docker builds, ECR pushes, and blue-green ECS deployments
- Vitest for unit tests (70% coverage enforced), Playwright for E2E
The AI writes the code. The pipelines verify it. If tests fail, the AI sees the failures and fixes them and all still within the same development loop. No human has to manually run tests, check coverage, or deploy.
We shipped 30+ work packages across three release versions (v0.1, v0.2, v0.3) using this pattern. Features like the Bedrock Sonic integration, session state management, the interrogator persona, the pushback loop, CV parsing, hard close logic, structured logging, CloudWatch alerting, admin dashboards, the CV readiness evaluator, and the user portal. All went through the same loop.
Step 5: Users Provide Feedback, AI Closes the Loop
Once a feature is live, users interact with it and provide feedback through forms. This feedback flows back into the system:
- AI analyzes the feedback: patterns, pain points, feature requests
- AI generates new user stories from the analysis
- Those stories enter the spec workflow
- The loop continues
This is the part that makes the whole system compound. Each iteration isn't starting from scratch. The AI has the full context of what was built, why it was built, how it was built, and what users said about it. The next feature builds on that foundation.
Why This Isn't Vibe Coding
Vibe coding is: "Build me a landing page with a hero section and a signup form". And you get one. It works. It's fast. For that use case, it's great.
What we're doing is different in three fundamental ways:
1. The AI operates within engineering constraints, not in a vacuum.
Our steering files encode real engineering decisions: use ESM in CareerGraph but CommonJS in the main backend. Use
process.env.ENVIRONMENT for env-specific logic, not NODE_ENV . Store large objects in S3, not DynamoDB. Use Pino for structured logging with session correlation. These are constraints that prevent the AI from making architecturally wrong decisions.2. Every feature traces back to human discovery.
The AI never decides what to build. It structures, designs, and implements what humans discovered users need. The pushback loop, the three-pillar interview structure, the strategic archetype classification: these came from watching real users struggle with real problems. AI accelerates the path from insight to production. It doesn't replace the insight.
3. The infrastructure is pre-built and battle-tested.
When the AI implements a new feature, it deploys into an existing infrastructure: ECS Fargate clusters with auto-scaling, DynamoDB tables with proper GSIs, S3 buckets with lifecycle policies, CloudFront distributions, CodePipelines with blue-green deployments. The AI doesn't set up infrastructure. It ships into infrastructure that engineers built to be reliable.
The Role of the Engineer Has Changed & Not Disappeared
The engineers on this project aren't writing every line of code by hand anymore. But they're doing something harder:
- Designing the architecture that makes AI-generated code reliable
- Building the infrastructure that makes deployment automatic
- Creating the steering files that keep AI implementations consistent
- Running the discovery sessions that identify what to build
- Reviewing the AI's output for architectural correctness
- Debugging production issues at the protocol level (try debugging a bidirectional audio stream with 16kHz input and 24kHz output over WebSocket when the Bedrock connection times out at minute 7:59)
The job title might still say "software engineer." But the job is increasingly: design the system, steer the AI, verify the output, and own the production reliability.
The Stack That Makes It Possible
A few things make this loop work at the speed it does:
- Kiro as the development environment: specs, steering files, hooks, and agent-driven implementation in one place
- AWS infrastructure: ECS Fargate, DynamoDB, S3, CodePipeline, CloudWatch and all pre-built and managed via Terraform/Terragrunt
- Amazon Nova Sonic for the core product: real-time speech-to-speech that would be impossible to build with a text-to-speech pipeline
- Vitest + GitHub Actions for automated quality gates: 70% coverage enforced, zero-flake policy
- Structured specs that give AI the full context it needs to implement correctly
None of these tools alone is the answer. The answer is the loop:
human discovery → AI structuring → AI implementation → → automated testing → automated deployment → user feedback → → repeatThe Takeaway
You can build a lot of things with vibe coding. You can't build everything.
For products that require real-time streaming, production infrastructure, cost optimization, and engineering discipline (the kind of products that actually push AI forward) you need a system. A loop where AI amplifies human judgment at every stage, but never replaces it.
That's how a small team ships fast. Not by removing engineers from the process, but by giving them leverage at every step.
JuntoAI Kinetic is live at kinetic.juntoai.org . Built with Kiro, deployed on AWS, and powered by a development loop where AI and humans each do what they're best at.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article