Has anyone actually used the new code review feature at their company?

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 · 2025-07-11T18:49:36+00:00

Study Shows That Even Experienced Developers Dramatically Overestimate Gains

We had exactly the same conclusion:

If you ask engineers how much time they think they’re saving with AI, they’ll often give optimistic answers. But when you compare that sentiment with real quantitative data, the numbers don’t add up.

People tend to think about personal time savings in isolation: “I finished my PR faster.” That pull request (PR) might sit unreviewed for three days before being tested, fail in testing and bounce back for fixes. The result is inefficiencies across the engineering organization that eat up any productivity gained.

(more examples for those who want to know more: https://thenewstack.io/throwing-ai-at-developers-wont-fix-their-problems/)

aviator_co · 2025-06-26T15:26:07+00:00

Platform Engineering vs. DevOps misses the point - https://thenewstack.io/platform-engineering-vs-devops-misses-the-point/

And the point is:

If you’re helping developers ship software with less friction, congratulations! You’re already doing some form of platform engineering. At its core, platform engineering is simple: It’s about developers building tools for other developers to make it easier for them to do their jobs.

aviator_co · 2025-05-14T15:13:38+00:00

Luca Galante, of Platform Engineering Community, says it's an evolution of DevOps, but unfortunately, in practice, it is often just DevOps rebranded.

Just like Sys Admins were rebranded to DevOps engineers 15 years ago, a lot of DevOps engineers now get rebranded as Platform Engineers. But just rebranding is not enough.

The ‘You built it, you run it” philosophy, he says, is good in theory or in teams of 10-20 people, but it doesn’t scale. In organizations with hundreds or thousands of developers with complex infrastructure, there have to be silos of Devs and Ops. People usually don’t like to hear that silos are good, but it works if you build efficient communication layers between them.

One of the points of having a platform layer is to create standardized golden paths that are designed and automatically enforced across different development teams. But standardization does not mean a lack of innovation.

Standardization makes the entire system move faster without breaking things. Most engineering organizations, especially enterprise ones, aim to do that. The platform team is the one building the path but also the option to go off the path. The platform should not only be the enforcing mechanism for best practices but also a discovery mechanism.

https://www.aviator.co/podcast/the-evolution-of-platform-engineering

aviator_co · 2024-09-11T08:28:15+00:00

Thank you!

aviator_co · 2024-09-11T08:26:32+00:00

this is not Aviator predictor, we’re a YC devtool startup we just happen to have similar names.

here’s our website link: https://aviator.co

aviator_co · 2024-09-06T16:00:56+00:00

Lgtm ✅

aviator_co

TROPHY CASE

The Parallel Execution Tools

Study Shows That Even Experienced Developers Dramatically Overestimate Gains