Andrew Filev's numbers landed in my feed last week and I haven't been able to shake them. His engineering team went from 36 people to 30. Throughput didn't drop — it nearly doubled. That's roughly 170% output on 80% headcount, backed by JIRA ticket data across six months of real work.

Filev isn't some breathless startup founder demoing a prototype. He built Wrike, grew it to over a thousand employees, and sold it for $2.25 billion. Now he's running Zencoder, an AI coding agent company, and he turned his own engineering org into the test case. The VentureBeat piece where he laid all this out is the first detailed, data-backed account I've seen of a full AI-first engineering transformation with before-and-after metrics. Not projections. Actuals.

And the structural shifts he describes match everything I've been watching unfold.

The cost of experimentation collapsed

Before AI, testing a product idea was expensive. You'd spend weeks perfecting user flows, writing specs, aligning stakeholders, all before a single line of code. Agile helped, but even agile couldn't make rapid experimentation cheap enough to do routinely.

Filev's team broke through that wall. An idea now goes from whiteboard to working prototype in a day: AI-generated PRD, AI-generated tech spec, AI-assisted implementation. Their creative director, who isn't an engineer, is shipping production code on the company website. Hundreds of custom components, designed, built, and maintained directly in code by someone whose title has nothing to do with software development.

The Zencoder data is hard evidence of something I keep seeing: the floor of individual capability has risen so fast the org chart can't keep up. His UX designers and project managers are submitting production-ready pull requests. When a release crunch hit, they jumped in and fixed dozens of interface details overnight. Not mockups. Working code.

This is what happens when the cost of trying things drops close to zero. You stop validating with slides and start validating with software. And teams that can't do this yet are competing against teams that already can.

The leverage point moved

The shift I didn't expect was this: when AI handles most of the implementation, the valuable skill isn't writing code any more. It's defining what "good" looks like.

His QA engineers evolved into something closer to system architects. Instead of writing test cases after the fact and filing bugs, they're defining correctness in machine-readable form. They build AI agents that generate acceptance tests directly from requirements, then weave those agents into the production pipeline so validation runs before code ships, not after. The agent writes the code, but it also proves the code works against criteria a human defined upfront.

This is what "shift left" was always supposed to mean, and it took AI to make it real. If the agent can't validate its own work, it can't be trusted to generate production code. So the people who define correctness have become the critical path. Product managers, tech leads, QA engineers. The ones setting the standard, not the ones writing the code.

The team supports 70-plus programming languages and countless integrations. Their coverage improved, bugs dropped, and users became fans — not because better programmers wrote it, but because validation was baked into the workflow from the start.

The diamond flipped

For decades, software development followed a diamond shape. A small product team defined what to build, handed it to a large engineering team to implement, then narrowed again through QA. The big middle was where the headcount sat.

Filev describes that geometry inverting. Humans engage deeply at the beginning (defining intent, exploring options, setting constraints) and again at the end, validating outcomes. The middle, where AI executes, is faster and narrower.

He calls it a "double funnel" and I think the framing is right. It's less assembly line, more control tower. Humans set direction, AI handles execution at speed, humans step back in to check the results before anything reaches production.

The implications for team structure are significant. You don't need 36 engineers when 30 can produce 170% of the output — and the research suggests those smaller AI-augmented teams produce better work, not just more of it. But the 30 who remain aren't doing the same work the 36 were doing. They're orchestrating AI workflows, tuning agent instructions, defining guardrails. This is what I called the compiler moment — the shift from writing code to directing agents. Filev's data is what that moment looks like when it hits a real team, across real time.

The question nobody answered

Filev frames this as "engineering at a higher level of abstraction" and draws the historical parallel: punch cards to high-level languages, hardware to cloud, and now code to AI orchestration. Each transition raised the ceiling. Each made the previous way of working look quaint within a few years.

And he's right. But he also glossed over something that matters.

Six people aren't there any more. His team went from 36 to 30. The throughput numbers are impressive. The quality improvements are real. But somewhere in that story are six people who used to have engineering jobs and now don't. Filev doesn't say whether they left voluntarily, were made redundant, or simply weren't replaced when they moved on. The piece doesn't ask the question.

I don't raise this to undermine his results. They're genuine and important. But the narrative that AI lets engineers "work at a higher level of abstraction" needs to be honest about what it means for the engineers who can't make that leap. Not everyone transitions smoothly from writing code to orchestrating agents. The skills are related but they're not the same. Some of the best implementers I've known were brilliant at translating requirements into clean, working software but had little interest in the architectural thinking that AI-first workflows demand.

I've written before about the reskilling myth — the gap between "retrain into the new roles" and what actually happens when you try. The evidence from six decades of federal retraining programmes says most people can't make wholesale career pivots at the scale and speed this transition demands.

What this actually means

The pattern here matches every conversation I'm having about AI-first development. Smaller teams, higher output, a fundamental redefinition of what engineers actually do. And this is one company's data from six months — not a McKinsey forecast or a vendor demo.

The maths is brutal. If a team of 30 can produce 170% of what 36 used to deliver, the competitive pressure on teams still operating the old way is immense. Not in theory. In the JIRA data. It's the same pattern Block demonstrated when it halved headcount while posting record profit.

Filev's engineers now routinely decide when AI output is safe to merge without review, how tightly to constrain agent autonomy in production systems, and what signals actually indicate correctness at scale. These are decisions that didn't exist eighteen months ago. They're the job now.

If your engineering team is still debating whether to adopt AI tools, someone else's team of 30 is already shipping what used to require 36. And they're not going back.