Faros AI tracked more than 10,000 developers across 1,255 teams and found that heavy artificial intelligence (AI) users merged 98% more pull requests, while review time on those pull requests climbed 91% and company-level delivery showed no measurable improvement. For a product-led growth (PLG) team, that pattern explains why the backlog clears and the experiments still crawl. I think most PLG leaders are buying AI coding tools to fix a bottleneck that lives somewhere else in their loop.
PLG engineering velocity is the speed at which a product-led growth team turns a user signal into a shipped, measured experiment. AI coding agents shrink one stage of that loop, the build. Review, release, and experiment readout set the pace for everything else. The PLG teams pulling ahead in 2026 redesign the whole loop around agents and judge themselves by experiments completed per quarter.
How does AI for product-led growth change shipping speed?
A PLG product grows by learning, and it learns one experiment at a time. A user signal becomes a hypothesis. The hypothesis becomes a spec, then code, then a flagged release, then a readout. Each completed lap teaches the team something real about activation, conversion, or expansion.
Most of those laps fail, which is exactly why their count matters. Ronny Kohavi, who ran experimentation at Microsoft, reported that about one-third of tested ideas improved the metric they targeted, one-third did nothing, and one-third made it worse. The stakes per win are also small. Kyle Poyar’s survey of more than 1,000 products and ChartMogul’s 2026 conversion report both put a good freemium free-to-paid conversion rate at 3% to 5%. They place a great rate somewhere between 6% and 12%. Nobody jumps from good to great on a single test.
So the math of PLG works a lot like compound interest. The win rate times the average lift is your interest rate. The number of experiments you finish each year is the number of compounding periods. First, count the laps:
Here N is experiments completed per year and Tloop is the average days from signal to readout. Then compound them:
G is the cumulative lift on your target metric, w is the share of experiments that win, and g is the average relative lift of a winning test. Plug in Kohavi's one-in-three win rate and a modest 2% lift per winner. A team on a 30-day loop finishes about 12 experiments a year and compounds to roughly 8% total lift. A team on a 10.5-day loop finishes about 35 and compounds to roughly 26%. The model is simplified, since real wins overlap and decay, but the direction holds: a shorter loop beats a smarter roadmap.
Where does the PLG loop actually lose time?
Every PLG experiment passes through the same six stages, and the loop takes as long as all six combined:
Think of a restaurant kitchen during a dinner rush. A faster grill helps, but tickets still pile up if plates wait at the pass for the head chef to inspect them. AI coding agents are the faster grill. The table below breaks a typical 30-day loop into stages and shows what happens under two scenarios. The numbers are hypothetical, and the direction of the review column comes from the research in the next section.
The AI-only team cut its build time by more than three-quarters and gained two experiments a year. The redesigned team gained twenty-three. Both teams bought the same coding agent.
Why doesn't AI coding alone speed up the PLG loop?
AI coding alone barely moves the PLG loop, because building takes up a minority of total loop time. A computer architect named Gene Amdahl explained this ceiling in 1967. Amdahl's law says the speedup from improving one part of a process is capped by how much of the total time that part takes:
S is the overall loop speedup, p is the share of loop time spent building, and s is how many times faster the agent builds. In the baseline above, building takes 9 of 30 days, so p is 0.3. An agent that turns nine days of building into two gives s of 4.5:
Even an infinitely fast agent caps out at 1 ÷ 0.7, or about 1.43 times faster. And that ceiling assumes the other stages stay put. The research says they don't.
The table below pulls together telemetry and controlled studies from Faros AI, METR (Model Evaluation and Threat Research), DORA (DevOps Research and Assessment), and Jellyfish.
Read together, the studies agree on one thing. AI raises code output, and the extra output lands on reviewers, testers, and on-call engineers who didn't get any faster. The 2025 DORA report calls AI an amplifier: it magnifies whatever engineering discipline a team already has. For a PLG team, that means agents speed up the experiments of teams with tight loops and pile up unread pull requests for everyone else.
How do agentic coding tools like Google Antigravity change the PLG loop?
Agentic tools matter for PLG because they reach past the build stage. Google Antigravity, which Google announced on November 18, 2025 alongside Gemini 3, gives agents the editor, the terminal, and a browser. Its agents produce artifacts as they work, including task lists, implementation plans, screenshots, and browser recordings. Those artifacts let a reviewer approve a plan and check the evidence, which attacks the review stage directly. Antigravity 2.0, announced at Google I/O on May 19, 2026, added scheduled tasks, so an agent can run on a timer without a human kicking it off.
The best PLG example I've seen targets the cleanup that follows every experiment. Every A/B test leaves a feature flag behind, and stale flags pile up as code debt that slows the next release. Duolingo built an agent that finds old feature flags and opens the removal pull requests itself, and it went from prototype to production in about a week on OpenAI's Codex CLI (command-line interface). That agent shortens the release stage for every future experiment. I walked through how Antigravity orchestrates agents like this in my breakdown of advanced agentic coding.
What does a whole-loop PLG redesign look like?
A whole-loop redesign gives every stage an owner, a target, and an agent where one helps. Here is how I'd approach each stage.
Signal: route funnel drops automatically. A workflow tool like n8n can watch your activation funnel and post a drop at onboarding step three to the team channel with the affected cohort attached. The signal stage shrinks from days to minutes. I compared where workflow engines and coding agents each belong in Google Antigravity vs. n8n.
Spec: write one paragraph an agent can act on. Name the metric, the hypothesis, the guardrail metric, and the success threshold. A spec that precise works as both a prompt for the coding agent and a contract for the readout.
Build: ship every change behind a flag. The agent builds, tests, and wraps the change in a feature flag by default, so release becomes a toggle.
Review: shrink the batch. DORA's research has long favored small batches, and they matter more when agents write the code. Let an AI reviewer catch style and obvious bugs first, and save human attention for the experiment design and risky surfaces like billing and permissions.
Release: clean up behind yourself. Schedule an agent to remove flags from finished experiments, the way Duolingo did.
Readout: decide the answer before the build. Pre-register the success metric and sample size in the spec. When the data arrives, the readout becomes a lookup, and nobody spends a week debating what the chart means.
The redesign also changes what leadership watches. Most dashboards track activity at the build stage. A PLG team needs loop metrics.
None of this works if the team won't change how it operates, which makes it a leadership problem first. I wrote about that gap in why teams still aren’t using AI.
What does this mean for solo founders and small PLG teams?
Solo founders get the cleanest version of the redesign, because one person owns every stage and handoffs cost almost nothing. Their new bottleneck is the readout. An agent can ship ten experiments in a week, but a product with modest traffic can't measure ten experiments in a week. A common rule of thumb for the users needed in each variant is:
n is users per variant, p is your baseline conversion rate, and δ is the absolute change you want to detect. Say your free-to-paid rate is 4%, and you want to detect a 10% relative lift, or 0.4 percentage points:
That's 38,400 users per variant for one clean answer. A small product will wait weeks for that traffic no matter how fast its agent codes. My advice for small teams is to test bigger swings. Detecting a 30% relative lift needs about one-ninth the sample, so a bold onboarding rewrite reads out far faster than a button-color tweak. Here is a lean stack for a team of one, organized by loop stage:
Will autonomous coding give PLG teams a lasting edge?
Code is getting cheap for everyone at the same time, so cheap code alone won't separate anyone for long. The lasting edge belongs to teams that treat the PLG loop as the product their engineering org builds. Those teams will learn three times as often as their competitors from the same tools, and in a market where most experiments fail, learning rate decides who finds the next activation win first.
If this connects to something you're trying to solve, book a complimentary consulting session. No pitch, just perspective.
Frequently asked questions
What is PLG engineering velocity?
PLG engineering velocity is the speed at which a product-led growth team turns a user signal into a shipped, measured experiment. The most useful way to track it is median days from signal to experiment readout, along with experiments completed per quarter. Lines of code and pull requests merged measure only one stage of that loop.
Do AI coding agents speed up product-led growth?
AI coding agents speed up the build stage, and the build stage is usually a minority of a PLG experiment's total cycle time. Faros AI found heavy AI adopters merged 98% more pull requests while review time rose 91%, with no measurable improvement in company-level delivery. PLG teams see real gains only when they also shorten review, release, and readout.
Why does AI coding increase code review time?
AI agents produce more and larger pull requests than human developers, and the number of senior reviewers stays the same. Faros AI's 2026 report on 22,000 developers found median review time up 441.5% and pull requests merged with no review up 31.3% under high AI adoption. Smaller batches, AI pre-review, and agent artifacts such as plans and screenshots help reviewers keep pace.
What is Amdahl's law, and how does it apply to PLG teams?
Amdahl's law says the overall speedup from improving one part of a process is capped by the share of time that part takes. If building is 30% of a PLG experiment's cycle time, an infinitely fast coding agent can speed up the whole loop by at most about 1.43 times. The remaining 70% of the loop sets the ceiling.
What is Google Antigravity?
Google Antigravity is an agent-first development platform Google announced on November 18, 2025, alongside Gemini 3. Its agents plan, write, test, and verify code across the editor, terminal, and browser, and produce artifacts like task lists and screenshots for human review. Antigravity 2.0, announced at Google I/O on May 19, 2026, added a desktop app, a command-line interface (CLI), a software development kit (SDK), subagents, and scheduled tasks.
What is a good free-to-paid conversion rate for a PLG product?
Kyle Poyar's survey of more than 1,000 products, published in Lenny's Newsletter, and ChartMogul's 2026 conversion report both put a good free-to-paid conversion rate for a self-serve freemium product at 3% to 5%. Poyar places a great rate at 6% to 8%, and ChartMogul places it at 8% to 12%. Free-trial products tend to convert higher because they attract fewer, more motivated signups.
How many experiments should a PLG team run?
A PLG team should run as many well-designed experiments as its traffic can read out with statistical confidence. Ronny Kohavi's data from Microsoft found only about one-third of tested ideas improved their target metric, so volume matters. A common rule of thumb for sample size per variant is 16 times the metric's variance divided by the square of the effect you want to detect.
How should PLG teams measure the impact of AI on engineering?
Measure loop metrics: median days from user signal to experiment readout, experiments read out per quarter, the share of experiments with a pre-registered success metric, and the count of stale feature flags. Pull requests merged and the percentage of AI-written code describe activity at one stage and can rise while the learning rate stays flat.
