Naplen

An AI software factory that plans, builds and reviews in your repositories

Coding assistants write more code and leave your reviewers to check all of it. I build a factory around your codebase and rules that plans each change, builds it, reviews it and validates it against your CI, so your reviewers see work that has already passed all of that.

Flow of the factory: plan, implement, multi-model review, adjudicate, validate, approval, with fixes returning from adjudication to implementation.
Work moves from plan to approval; confirmed review findings return to implementation.

Small slices with their own checks keep a change honest

Every task starts from your code, your conventions, your CI configuration and the history around the change. A planning step breaks it into small slices, and each slice names the files it may touch, the checks that prove it done and the point where it stops and reports. The example at the end of this page shows one.

Implementation and testing run slice by slice in a sandbox, with permissions bounded to the task. A rule such as "no existing test is skipped or weakened" closes the easy route to a green build.

Independent models and an adjudicator resolve disagreements against the code

More than one model reviews each change, and an adjudication step checks every finding against the diff, so a dispute gets resolved instead of averaged. Confirmed findings go back to implementation as fixes.

In my factory's review ledgers, that has confirmed 1,812 findings, 674 of them blocking, at an average of 1.47 review rounds per ticket. Those are confirmed findings, not a defect rate, and the factory also develops itself.

Review caught a plan that covered only part of its own goal

In one recorded incident, a plan for a taxonomy migration covered 9 of 69 tickets its own goal named, and a review round caught it. The lesson is now a written rule the factory works under.

Custom agent skills carry your standards the same way, so the pipeline checks your review rules and architectural constraints instead of your reviewers having to remember them.

It rebuilt the site you are reading

My software factory rebuilt this website: 50 pull requests and 378 files changed, about 36 hours from the first run to the last merge. That is a single snapshot and not a rate, and the elapsed time includes waiting for host capacity.

You start with a workflow review, and the factory runs in your repositories

A workflow review comes first: I look at how a change moves through your team and what the factory can take on. You leave with a plan either way.

If you go ahead, the factory connects to GitHub or GitLab and works through your CI/CD, and usage reporting shows what ran, what it cost and what it changed. It does the volume, I review what it produces, your approval workflows set what needs sign-off, and you get no constant meetings.

Start with a workflow review of your own repositories.

Example: one slice of a plan
slice: 2
goal: add rate limiting to the public API
files:
  - internal/api/ratelimit.go
  - internal/api/ratelimit_test.go
criteria:
  - go test ./internal/api/... passes
  - a request over the limit returns 429
invariants:
  - no existing test is skipped or weakened
bound: stop and report after 15 turns or 40 minutes

Capabilities

Pipeline

  • Planning and decomposition
  • Multi-model review with adjudication
  • Validation against your CI

Controls

  • Sandboxed execution
  • Permission boundaries and approvals
  • Usage reporting

Stack

  • Go
  • Python
  • Kubernetes
  • Terraform
  • AI agents and orchestration
  • MCP

Related services

[email protected]