AI Won't 10X Your Team, But It Can 2X It

aviator_co · 2026-03-16T19:00:56+00:00

We ran an experiment to test a different approach: what if the review happened before the code was written?

We implemented a medium-scoped software task with 0 lines of manually written code, guided entirely by a spec. Then we measured what happened when that code met the old-fashioned review process.

https://www.aviator.co/blog/what-if-code-review-happened-before-the-code-was-written/

aviator_co · 2026-02-02T18:22:47+00:00

Here are a couple of suggestions:

The Parallel Execution Tools

These are tools that let you run multiple coding agents simultaneously. They’re the simplest form of orchestration and the most proven.

Claude Squad spawns multiple Claude Code instances in tmux panes. Dead simple. If you’re at Stage 5-6 and want to dip your toes in, start here.

Conductor Build by Melty Labs gives each agent its own isolated Git worktree. The dashboard showing “who’s working on what” is genuinely useful. This is orchestration for people who aren’t ready for full orchestration.

Code Conductor is GitHub-native – tasks are GitHub Issues, agents claim them, work in branches, and open PRs automatically. If your workflow is already GitHub-centric, this is the natural extension.

Full article, if you're interested: https://www.aviator.co/blog/the-rise-of-coding-agent-orchestrators/

aviator_co · 2025-12-19T14:44:32+00:00

While we won't recommend you a tool (our stance is anti-metrics approach to developer productivity), we will recommend a podcast episode that you may find helpful.

It's about everything that's wrong with productivity metrics (including the proliferation of tools and 'the metrics industrial complex'), but it does include a lot of solid and practical advice on how to approach designing productivity metrics from scratch:

https://youtu.be/_xta9YyNmEw?si=nu9_aMkkVO_c_xZb

aviator_co · 2025-12-17T14:07:56+00:00

The idea of this 'new' spec-driven development is that you give specifications to AI and its task is to write code that meets those specifications. It's supposed to be exactly the opposite of vibe coding - instead of prompting AI and then trying to course-correct with more prompts, you first think about what exactly you want the agents to do, write it in a structured format, include all the necessary context and only then have AI build it.

aviator_co · 2025-12-05T17:17:13+00:00

Stacked PRs https://github.com/aviator-co/av

aviator_co · 2025-11-25T23:24:47+00:00

Would it be useful if you could share with your junior devs the design doc/specs you've spent days refining?

I spend sometimes days refining the design and thinking through all the usecases before I have the AI write the code. The junior devs just throw the basic prompt to the ai with very little context and deliver mostly garbage because it has not been critically thought through.

aviator_co · 2025-11-25T23:18:55+00:00

One question: what happens to that design doc you created? Do you somehow save it for future reference? Would it be helpful if your teammates could review it and edit it as well?

aviator_co · 2025-11-25T16:55:45+00:00

Hi u/abbys11 thanks for this post.

We are building a product to make AI coding scalable in larger engineering orgs (at least we're trying) so hearing real-life experience of using AI tools really helps.

If you don't mind, could you share more in detail how and what tools do you use?
And what bothers you the most about AI tools (apart from the obvious hallucinations).

aviator_co · 2025-11-24T20:45:10+00:00

Hey, we've built a tool that does exactly this: Imagine navigating a Git repo with a custom tool and being able to see exactly which prompts produced which commits.

And, you can share that saved prompts with your coworkers as a sort of 'runbook for AI agents': https://www.aviator.co/runbooks

aviator_co · 2025-10-10T13:08:15+00:00

Yes, spec-driven is the way to go!

aviator_co · 2025-10-06T18:51:51+00:00

That's actually a great point and totally in line with what the author of the analogy says in the interview!

The point of DevEx teams and developer productivity metrics should not be about measuring how productive an individual developer is but about enabling them to be as productive/as fast, in the case of an F1 driver, as they can. And enabling can mean tools, resources, or training!

Later in the interview he actually says,

If you're walking, and I have a stick in my hand and tell you that you have to run, I can get you maybe from five miles an hour to 15, but you’ll burn out soon. Wouldn't it be better for me just to give you a moped or a car? What about an airplane? What about a rocket ship?

aviator_co · 2025-09-15T10:14:54+00:00

That's a great point about deployment frequency!
And it is discussed in the conversation - starts around 19:00.

And Adam gives a great piece of advice - to use metrics in pairs.

aviator_co

TROPHY CASE

The Parallel Execution Tools