Your Team Uses AI. Why Aren't You 10x Faster?

A 10x engineer does not yield a 10x organization.

I’ve been a Director of Engineering at Salesforce, Lyft, and Twitter. These are among the world’s most well-known tech companies. Yet at Logic, the six-person startup I co-founded, we ship faster than much larger teams at those companies would ever be able to.

Every month we ship hundreds of features¹. Over 95% of the code we check in is written by AI.

If you are a CTO or VP of Engineering, you might be looking at these numbers with skepticism. You’ve likely given your teams Cursor, Claude Code, or similar tools, but you haven’t seen a 10x speedup. You might see a 10% or 20% bump, but nothing transformative.

One of the key reasons for this gap is likely a principle from 1967.

Amdahl’s Law

Gene Amdahl was a computer architect who observed something that seems obvious in retrospect: when you speed up part of a system, the overall improvement is limited by how much time that part actually took.

If writing code represents 20% of your total development time, and you make it 10x faster, you don’t get a 10x overall speedup. You get 1.22x. That 20% shrinks to 2%, but the other 80% remains untouched.

The formula is:

\(Speedup = \frac{1}{(1 - P) + \frac{P}{S}}\)

Where P is the proportion of time spent on the task you’re improving, and S is the speedup factor for that task.

In our example:

\(\begin{aligned} P &= 0.2 \\ S &= 10 \\ \frac{1}{0.8 + 0.02} &= 1.22\times \end{aligned}\)

This formula is why AI disproportionately benefits smaller teams.

Where the Time Actually Goes

Developers at large companies spend surprisingly little time writing code. AWS reported engineers spend only one hour per day coding.

The rest of the time (1 - P) is consumed by:

• Planning and Design: Gathering requirements, designing features, and debating the architecture of a system.

• Code Reviews: The back-and-forth loops ensuring that new code is consistent and correct.

• Testing: Writing and running manual and automated tests.

• Debugging: Reproducing and fixing bugs in complex distributed systems.

• Documentation: Writing design docs, updating tickets, and creating guides for users.

And the big one.

• Communication and Coordination: Attending stand-ups, all-hands, planning meetings, performance reviews, and managing other stakeholders.

In this environment, P (the time spent coding) is low — perhaps 20%. Even if AI makes coding instant (S = ∞), the maximum theoretical speedup for that organization is 1.25x.

The S’s & P’s at Logic

At Logic, we don’t just use AI to write code. We use it to attack those other non-coding tasks that slow everyone else down.

Because we’re small, and because we integrate AI into the process, our P is much higher. Here is how we compress those traditional bottlenecks:

1. Planning and Design
Instead of weeks of requirements gathering, we use agentic tools to iteratively write PRDs with us. We treat it as an interactive interview process, and have the agent research our codebase and the web in real-time before asking each question, making each additional question well-informed and intentional.

Here’s our ~/.claude/commands/prd.md for that.

2. Code Reviews
One of our founding engineers, Mark Golazeski, wrote about the many things we do to automate code review at Logic. When you have a six-person team needing to perform 200+ reviews every month, you can’t afford not to automate as many aspects of it as possible.

In large orgs, code review often holds up changes for days. By contrast, we often get reviews done in minutes.

3. Testing and Debugging
Writing comprehensive test suites is tedious, so humans often skip it. However, tests are an amplifier in an AI-first world. We believe this so firmly that we don’t allow AI to commit any code that isn’t 100% covered.

This forces the AI to do some level of validation on every line it writes. It also acts as a debugging harness. We’ve optimized our test runner to run thousands of tests quickly in parallel, allowing the AI to run test suites over and over again while debugging things.

And when we run into a new issue, we give the AI the inputs, outputs, and symptoms and set it loose to create regression tests and figure out the root cause.

4. Documentation & Communication
In the same post, Mark describes some of the automation we’ve done around summarizing PRs and generating diagrams for documenting and communicating changes.

No Overhead

We’re too small for most of the traditional organizational overhead that slows down larger companies.

We sit within earshot of one another. We eat lunch together. We have one short recurring meeting, once a month. The sheer weight of coordination overhead, the force that crushes velocity in large organizations, simply doesn’t exist for us. We operate with high autonomy.

The old trade-off here used to be that smaller, more nimble, teams simply can’t ship as much code, but AI has helped level that playing field for us.

Takeaway

If your AI-augmented team isn’t shipping dramatically faster, one of your contributing factors is likely Amdahl’s Law.

The solution isn’t to try to get the AI to just generate more code. A faster engine won't help a car stuck in traffic.

Identify where time actually goes, figure out which of those activities can be improved, and systematically attack the bottlenecks that still exist even if coding has become lightning-fast.

Speed up code review. Invest in clearer specs. Improve your CI/CD pipeline. Most importantly, reduce organizational overhead.

And keep watching for your next bottleneck to emerge, because as soon as you fix one, Amdahl’s Law will point you to the next.

1. Not just fixing typos or sending out simple one-liners, but real features and improvements. Averaging 370 lines changed per pull-request, including tests.