Forem: Erik Israni

Why the Best Open Source Teams Treat Writing, Testing, and Reviewing as Three Separate Jobs

Erik Israni — Thu, 05 Mar 2026 15:18:44 +0000

You adopted AI to move faster, and it worked. Output went up. Features that used to take days landed in hours. Contributors shipped more. And then something broke: AI accelerated the part of development that creates work for reviewers, but didn't do anything about review itself.

The result is what I call the AI Throughput Gap.

Traditional workflow:
Write -----> Test -----> Review

AI-assisted workflow:
AI Writes Faster ---> PR Volume Explodes ---> Review Becomes the Bottleneck

PRs pile up faster than any one person can clear them
Edge cases slip through because reviewers are moving too fast
Contributors wait days for feedback and go quiet
You merge something that looked fine and spend the next week fielding issues

This isn't a productivity problem. It's a tooling problem. Somewhere along the way, the idea took hold that if AI can help you write the code, it can handle the rest too. Review included.

It can't. Not the same way. Understanding why is the difference between shipping confidently and shipping slop.

What "Agentic" AI Is Actually Optimized For

When you're building something, describing a feature, watching an AI scaffold a component, iterating on logic, the model is operating in creation mode. Its job is to generate, move forward, and produce the next thing based on what you want.

That's powerful. But it's directional. The model is optimized for momentum.

Reviewing code is the opposite. Instead of moving forward, you're scanning laterally across an entire change, looking for:

What's missing
What's fragile
What works in isolation but breaks under load
What conflicts with something three files away

The questions are fundamentally different:

Creation mode asks: Does this do what it's supposed to do?

Review mode asks: What does this do that we didn't intend? What did we forget? What's going to bite us six months from now?

These are different cognitive jobs. And that difference is exactly why context matters so much, which is what makes collapsing them into one tool so costly.

The Hidden Cost of One-Session Review

When an AI helps you write a feature, it absorbs your intent. It knows:

What you were trying to build
The decisions you made along the way
The tradeoffs you rationalized in real time

That context is valuable while building. It becomes a liability when reviewing.

A good code reviewer doesn't know what you meant to do. They only see what you actually did. The distance between intent and implementation is exactly where bugs live, where security gaps hide, where forgotten edge cases sit quietly waiting.

Using the same AI session that wrote your code to review it is like proofreading your own writing immediately after finishing it. Your brain fills in what should be there. You miss what isn't.

Human engineering teams figured this out long ago. That's why code review exists as a discipline separate from implementation. AI teams are relearning the same lesson. And the solution is the same: separate the jobs.

The Three Jobs Framework

Your development workflow is three genuinely distinct jobs, each with its own goal and failure mode.

Writing

Goal: Produce working code that implements intent
Failure mode: Building the wrong thing, or in a way that's hard to maintain

Testing

Goal: Confirm the code does what it claims
Failure mode: False confidence from tests that pass but miss the cases that matter

Reviewing

Goal: Find what writing and testing missed
Failure mode: A clean merge on code that causes problems nobody saw coming

What only review catches:

Security vulnerabilities
Performance edge cases
Style inconsistencies that become technical debt
Architectural drift that compounds over time

Collapsing these into one tool or one session doesn't make the workflow efficient. It makes each job worse. The teams shipping reliably with AI aren't using it to do everything at once. They're using it to do each job better, separately.

AI doesn't replace good process. It amplifies it when you separate the jobs.

Why This Matters More in Open Source

For a closed product, a bad merge is a bad day. You fix it, ship a patch, move on.

In open source, the blast radius is everyone who depends on you.

OSS maintainers are already stretched thin:

Often one or two people managing contributions from dozens
Reviewing PRs from contributors you've never met
Holding context across a codebase that keeps growing
Every merge carries downstream consequences for users who built on your project

A security vulnerability in a popular library doesn't just affect your users. It affects their users. A performance regression in a widely-adopted package ripples outward in ways that are hard to track and harder to undo.

And yet OSS maintainers are typically the least resourced to handle this well. No dedicated QA. No security review team. Just you, your contributors, and whatever time you can carve out.

AI increased code throughput for everyone. Maintainers still have the same number of hours. That gap has to close somewhere, and right now it's closing on your review queue.

What Purpose-Built AI Review Actually Looks Like

A coding assistant and a code reviewer are doing completely different jobs. Kilo's Code Reviewer doesn't pick up where your last prompt left off. It reads a completed change fresh, the way a senior engineer would.

Here's what that looks like in practice:

Reads diffs, not prompt history. It sees only what changed, with no prior context about what you intended.
Compares against codebase patterns. It flags when a change drifts from established patterns in the rest of the project.
Runs security checks automatically. Each PR gets checked for common vulnerabilities before it touches your main branch.
Runs on every PR, automatically. External contributor submissions get a thorough first pass before you ever have to look at them.

For maintainers, that translates to:

Issues caught before merge, not after
Contributors getting faster, more substantive feedback, which keeps them engaged
Consistent review quality even when you're offline or heads-down on something else
A review queue that doesn't require you to be everywhere at once

The Right Tool for Each Job

The goal isn't more AI in your workflow for its own sake. It's the right tool for each job, applied where it actually helps.

You've already seen what's possible when a tool is matched to the task. Review is just the next job in line, and it deserves the same intentionality.

The teams that look back on this period and feel good about how they built won't be the ones who used AI the most. They'll be the ones who used it most clearly.

Free Tooling for Open Source Maintainers

The most critical software in the ecosystem shouldn't lose to commercial projects because it can't afford the tooling. That's why we built the Kilo OSS Sponsorship Program.

We're already supporting over 280 open source projects with access to Kilo's full platform, including credits for the Code Reviewer.

Three sponsorship tiers based on project size and maturity:

Tier	Value	Who It's For
Seed	$9K/year	Early-stage or smaller OSS projects
Growth	$24K/year	Established projects with active contributors
Premier	$48K/year	High-impact projects with broad adoption

No strings attached. Takes about 2 minutes to apply.

Apply for the Kilo OSS Sponsorship Program →

If you're maintaining something people depend on, this is for you.

We're Sponsoring Open Source Projects with Free AI Code Reviews (and Up to $200/mo in Credits)

Erik Israni — Wed, 25 Feb 2026 16:41:01 +0000

What We Built and Why

Kilo is an open-source agentic coding platform. That means IDE extensions for VS Code and JetBrains, a CLI, cloud agents, the works. We process a lot of code. And one of the things we built that we're most proud of is our Code Review feature: automated, intelligent reviews that run on your pull requests and flag issues across performance, security, style, and test coverage.

We use it ourselves. Our contributors use it. And we kept thinking: the projects that would benefit most from this are the ones with the least resources to pay for it.

So we built a sponsorship program. 280 Participants and counting!

How It Works

The Kilo Open Source Sponsorship Program provides qualifying open-source projects with free access to Kilo's tooling , starting with Code Reviews, and scaling up based on your project's size and activity.

There are three tiers:

Seed — For smaller and early-stage projects. 5 Enterprise seats + automated Code Reviews on your public PRs. Worth about $9,000/year.

Growth — For large, active projects with regular contributors. 15 Enterprise seats + $20–100/month in Kilo Credits + Code Reviews. Worth about $27,000/year.

Premier — For high-visibility projects with significant communities. 25 Enterprise seats + $200/month in Kilo Credits + Code Reviews. Worth about $48,000/year.

Tier placement is made on a rolling basis, once we review your application and place you based on repository activity, community size, and project visibility.

What You Actually Get

Automated Code Reviews on your public PRs. Kilo shows up in your pull request review flow and reviews for performance, security, style, and test coverage. It's not a static code analysis tool. It reads the code, understands the context, and gives you the kind of feedback you'd expect from a senior engineer on your team, one that has access to endless coffee, never gets tired, and never misses a PR.

Enterprise access. All accepted projects get full Enterprise seats. That means advanced team features, usage analytics, and priority support for everyone working on your project.

Kilo Credits (Growth and Premier tiers). Credits you can use across any of Kilo's tools, including IDE extension, CLI, cloud agents, app builder. You pay-per-token at provider cost, no markup.

Access to free models. All tiers include access to free models at no cost.. Currently Grok Code Fast 1, Mistral Devstral 2, and KAT-Coder-Pro V1.

Visibility. We'll feature your project on our website and potentially in marketing materials. If you want your project to get in front of Kilo's 1M+ users, this is one way to do that.

A direct support channel. Selected projects get a dedicated channel to talk to Kilo team members directly. Not a ticket queue.

What We Ask In Return

Three things:

Your project must be open source with a public repository and a valid OSS license (MIT or equivalent).
You enable Code Reviews on your public PRs, Kilo will appear in your review flow.
You consent to being featured in Kilo's OSS showcase: website features, marketing materials, links to public PRs using Code Reviews.

That's it. No vendor lock-in, no exclusivity requirement, no "you must tweet about us" clause.

Why We're Doing This

Honestly? A few reasons.

Open source is infrastructure. A lot of the code that runs the internet is maintained by people working nights and weekends with no budget for tooling. That's always felt like an oversight in how the tech industry thinks about sustainability.

We also think AI-powered code review is genuinely better when it runs on real, diverse, production open source code. Your contributors write differently than our internal team does. Your PR patterns are different. Your codebases have different histories and constraints. Every project that runs Kilo Code Reviews helps make the tool sharper for the whole community.

And yes, we want more developers to know Kilo exists. We think the best way to do that is to be useful first.

Who Should Apply

If your project checks these boxes, you're a good candidate:

Public repository with an active OSS license
Regular PRs being opened (doesn't have to be high-volume, just active)
Maintainers who would actually use the tooling

We're reviewing applications on a rolling basis. Applying doesn't guarantee acceptance, we'll reach out directly to projects we accept.

Apply

👉 kilo.ai/oss

Questions? Drop into our Discord or email hi@kilocode.ai.

And if you're an OSS maintainer who's skeptical of sponsored programs in general: fair. We'd rather you check out the code (github.com/Kilo-Org/kilocode) and make your own judgment than take our word for it.

I'm Erik, one of Kilo's community managers. I spend most of my time in our Discord working with developers who are building with AI and supporting the open source projects that power the ecosystem. If you're maintaining an OSS project or just want to talk shop, come find me.

Kilo is the open-source agentic coding platform , IDE extensions for VS Code and JetBrains, CLI, cloud agents, and more. 1M users, 21T+ tokens processed, #1 app on OpenRouter. kilo.ai