David Lapsley, Ph.D.

Founder & CEO (Stealth). Distributed systems, AI-accelerated SDLC, and infrastructure at scale.

7 minute read

In my year-end reflections, I mentioned that I’d be sharing more of my work through open source releases in the coming year. Today, I’m delivering on that promise.

I’m excited to announce the open source release of KodeOps, a CLI and TUI tool that automates the software development lifecycle from concept to structured backlog.

The backstory

Eighteen months ago, I left AWS to explore how AI was changing software development. I spent more than a year building software with AI every day, testing what it took to reach production-quality results, and learning where things worked and where they broke.

One of the clearest lessons: automating the SDLC is hard. Writing agents wasn’t the main constraint. The real bottlenecks were earlier in the process: planning, documentation, requirements gathering, and the organizational overhead that comes before anyone writes a line of code.

Teams were losing days or weeks in planning cycles. Requirements lived in scattered documents. The gap between an idea and an actionable backlog was surprisingly wide. I built KodeOps to close that gap.

The problem: 60% of development time isn’t spent coding

Here’s a reality most engineering teams face: the majority of development time isn’t spent writing code. It’s consumed by planning, documentation, and reporting. The journey from a rough idea to an actionable backlog item typically takes 3+ weeks, involving:

  • Writing PRFAQs and requirements documents
  • Creating and refining product specifications
  • Breaking work into epics, features, and tasks
  • Populating project management systems
  • Generating status reports for stakeholders

Meanwhile, AI coding assistants like GitHub Copilot and Cursor have revolutionized code generation, but they only address a fraction of the development lifecycle. Everything before and after the code editor remains manual, fragmented, and time-consuming.

KodeOps bridges this gap.

What is KodeOps?

KodeOps is an AI-powered SDLC automation platform built on three integrated pillars:

Pillar 1: Ideation to backlog

Transform natural language ideas into production-ready backlogs in minutes, not weeks:

> /sdlc/prfaq "Build a real-time collaboration feature for our docs editor"

KodeOps generates structured PRFAQs, Market Requirements Documents (MRDs), Product Requirements Documents (PRDs), and automatically populates your GitHub backlog with properly labeled, prioritized issues.

Pillar 2: Development workflow automation

Seamless GitHub operations, AI-assisted implementation, and automated code review:

> /dev/implement health-endpoints 1    # Implement task 1 from spec
> /workflow/pr                         # Create pull request with AI-generated description
> /dev/review                          # AI code review against architectural standards

Pillar 3: Business intelligence and reporting

Generate executive-ready reports automatically:

> /reports/wbr         # Weekly Business Review
> /reports/mbr         # Monthly Business Review
> /reports/qbr         # Quarterly Business Review

Spec-driven development

The core use case for KodeOps is the Spec-Driven LLM Development workflow I’ve written about extensively. KodeOps provides a structured path from requirements to verified implementation through slash commands in the OpenCode TUI.

Let’s walk through a concrete example: adding health check endpoints to a service.

Step 1: Generate the specification

In the OpenCode TUI, run:

> /dev/spec "Add health check endpoints to the control plane service.
  We need a liveness endpoint and a readiness endpoint that checks
  database and cache connectivity."

This generates a specs/health-endpoints/requirements.md file with testable acceptance criteria:

### Requirement 1: Liveness Endpoint

**User Story:** As a platform operator, I want a basic health check endpoint,
so that I can verify the service is running and responsive.

#### Acceptance Criteria

1. WHEN a client sends GET /health, THE System SHALL return HTTP 200 with JSON
2. WHEN the health endpoint responds, THE System SHALL include status field
   with value "healthy"
3. WHEN the health endpoint responds, THE System SHALL include timestamp field
   in RFC3339 format

Every requirement uses EARS notation: specific, testable, unambiguous.

Step 2: Generate the design

> /dev/design health-endpoints

This produces a specs/health-endpoints/design.md capturing architectural decisions:

### Architecture Decision: Dependency Injection

Health check functions accept dependencies as parameters rather than
accessing globals, enabling testability and flexibility.

### Interface Signatures

func CheckDatabaseHealth(db *gorm.DB) string
func CheckCacheHealth(cache *redis.Client) string
func RegisterHealthRoutes(router *gin.Engine, db *gorm.DB, cache *redis.Client)

### Property 4: Status Code Mapping

*For any* ready endpoint response, if all checks have value "ok" then
HTTP status should be 200, and if any check has value "error" then
HTTP status should be 503.

The LLM now knows exactly which patterns to follow. No guessing.

Step 3: Generate tasks

> /dev/task health-endpoints

This creates a specs/health-endpoints/tasks.md with implementation steps:

- [ ] 1. Create health check logic file
  - Create `internal/health/health.go` with package declaration
  - Implement `CheckDatabaseHealth(db *gorm.DB) string`
    - Handle nil database connection (return "error")
    - Execute ping with 500ms timeout
    - Return "ok" on success, "error" on failure
  - _Requirements: 2.1, 2.2, 2.3_

- [ ] 1.1 Write property test for database health check
  - **Property 5: Database Check Result Mapping**
  - _Validates: Requirements 2.2, 2.3_

- [ ] 2. Implement HTTP handlers and register routes
  - Create handler functions for /health and /ready
  - Wire up dependencies through RegisterHealthRoutes
  - _Requirements: 1.1, 1.2, 2.4, 2.5_

Every implementation task has corresponding test tasks. Nothing ships without verification.

Step 4: Implement

> /dev/implement-all health-endpoints

OpenCode executes each task using AI-assisted code generation, following the spec as a contract. The implementation is guided by explicit requirements, not vague prompts that lead to AI drift.

Step 5: Review

> /dev/review health-endpoints

This verifies the implementation matches the specification, running tests and checking that all acceptance criteria are satisfied. Drift is caught before it reaches production.

This is the closed loop: specs become the source of truth, implementations are verified against them, and the entire process is automated. No more “vibe coding” with impromptu prompts.

Key features

200+ AI Models via OpenRouter A single API key provides access to Claude, GPT-4, Gemini, Llama, Mistral, and more. Choose the right model for each task, or let KodeOps decide.

Zero-Dependency Deployment Everything runs in a self-contained Docker container. Prerequisites: Docker and bash. That’s it.

Persistent Conversational Memory Thread-based sessions maintain context across restarts. Your AI assistant remembers previous conversations, project decisions, and team preferences.

Terminal-First Interface Both interactive TUI mode and scriptable CLI mode. Works with any editor, integrates into any workflow, runs in any CI/CD pipeline.

Fully Extensible Custom agents, commands, skills, and plugins can be added without modifying core code. Three-layer configuration (container -> user -> project) enables organization-wide standards with per-project overrides.

The numbers

Metric Before KodeOps With KodeOps
Idea to Backlog 3+ weeks 30 minutes
Requirements Documents Hours of writing Minutes of review
Status Reports Manual compilation Automated generation
Context Switching Constant Minimized

Why I’m open sourcing this

The ideas behind KodeOps aren’t proprietary. They’re the natural evolution of spec-driven development applied to the full SDLC. I’ve written extensively about Spec-Driven LLM Development and the philosophy behind it. KodeOps is the tooling that makes those ideas practical at scale.

By releasing this under the Apache Software License v2, I’m hoping to:

  1. Give back to the community that has taught me so much over the past 18 months
  2. Accelerate adoption of structured, spec-driven approaches to AI-assisted development
  3. Build in public and learn from how others use and extend these ideas

The tool is free forever and community-driven.

Getting started

Installation

# macOS (Homebrew)
brew tap actualyze-ai/tap
brew install kdo
kdo install

# Or download directly
# macOS (Apple Silicon)
curl -L https://github.com/actualyzeai/kdo/releases/latest/download/kdo-darwin-arm64 -o kdo

# macOS (Intel)
curl -L https://github.com/actualyzeai/kdo/releases/latest/download/kdo-darwin-amd64 -o kdo

# Linux (x86_64)
curl -L https://github.com/actualyzeai/kdo/releases/latest/download/kdo-linux-amd64 -o kdo

chmod +x kdo
sudo mv kdo /usr/local/bin/

Install containers

Once the binary is installed, run the install command to download the required containers:

kdo install

This pulls the container images needed for the SDLC automation and spec-driven development workflows.

Configuration

# Required: OpenRouter API key (get one at openrouter.ai/keys)
export OPENROUTER_API_KEY="sk-or-v1-xxxxx"

# Optional: GitHub integration
export GITHUB_TOKEN="ghp_xxxxx"

# Optional: Web search capabilities
export TAVILY_API_KEY="tvly-xxxxx"

Quick start

# Launch interactive TUI mode
kdo

Once in the TUI, run commands directly:

> /sdlc/prfaq "Your product idea here"

This launches the OpenCode TUI where you can immediately start using the /dev/spec, /dev/design, /dev/task, /dev/implement-all, and /dev/review commands.

Build from source

If you prefer to build from source:

git clone https://github.com/actualyzeai/kdo.git
cd kdo
go mod download
go build -o kdo ./cmd/kdo

See the CONTRIBUTING.md file for detailed development setup instructions.

Who is KodeOps for?

  • Engineering teams (10-50 developers) at growth-stage companies looking to accelerate delivery
  • Open source maintainers managing high-volume contributions and community engagement
  • Developer-entrepreneurs building products solo who need to move fast
  • DevOps engineers who prefer CLI-native tools that integrate into existing workflows

What’s next

This release is just the beginning. I’ll be publishing tutorials, walkthroughs, and educational content here and on YouTube to help teams adopt these practices. I’m also continuing to develop KodeOps with new features based on community feedback.

Our roadmap includes:

  • Enhanced development workflow automation: Deeper GitHub integration, automated testing orchestration, deployment pipelines
  • Advanced business intelligence: Custom KPI tracking, velocity analytics, predictive insights
  • Ecosystem expansion: Additional MCP server integrations, plugin marketplace, enterprise features

If you’ve been following my writing on spec-driven development, this is the tool that ties it all together. If you’re new here, KodeOps is a practical starting point for bringing structure and automation to your development workflow.

Join the community

We’re building KodeOps in the open and welcome contributions, feedback, and feature requests:

Check it out at actualyze.dev, and let me know what you build with it.

You May Also Enjoy

The Missing Half of AI-Assisted Development

12 minute read

There’s a growing conversation in the industry about building a “Cursor for product management,” an AI-native system focused on helping teams figure out what...