AI Made Every Engineer Faster. It Didn’t Make Your Team Better.
Today we’re releasing Port33’s AgentOS as open source: a coordination layer for engineering teams where humans and AI agents both do real work. Here’s the problem it solves, and where to get it.
By Afsheen Afshar - Founder & Managing Partner, Pilot Wave Holdings. First Chief AI Officer in private equity history at Cerberus · first Chief Data Science Officer in Wall Street history at JPMorgan · former Managing Director at Goldman Sachs · MD/PhD, Stanford.
AgentOS GitHub: https://github.com/Pilot-Wave-Technology/AgentOS
Spotify’s co-CEO says his best engineers haven’t written a line of code since December. Google says AI now writes more than a quarter of its new code. Shopify tells its people to prove an AI can’t do a job before they’re allowed to hire a human to do it.
If you write code for a living, or run a team that does, you’ve heard some version of this everywhere for the past year: AI is making our developers dramatically more productive. And if you’re the one watching the inference bills climb, you’ve probably started asking the quieter question underneath the claim: whether all that spend is actually turning into impact.
Often it’s not. More code doesn’t mean more productive.
Now the data is in.
In a randomized controlled trial, experienced open-source developers were given AI coding tools to use on real issues in codebases they knew well. Before they started, they expected AI to make them about 20% faster. After they finished, they still believed it had. The measured result was the opposite: they were 19% slower. And they never noticed.
I don’t cite that study to argue AI doesn’t work. It does; we use it everywhere. I cite it because it exposes the thing almost no one is managing: the speed you feel and the progress you make are no longer the same number. And once that’s true, running an engineering team the way we used to stops working.
We built Port33’s AgentOS because we ran straight into that problem inside our own firm, led by Harsh Agarwal, a Senior Partner at Pilot Wave who leads our technology effort, and his team. Harsh has been clear on this from the engineering side: open source is the right place to pressure-test the system. Developers will tell us fast where it’s useful, where it’s too heavy, where it needs deeper integrations, and where agents need more context. That’s exactly what we want.
Pilot Wave puts AI into real operating businesses: retail, industrial, and critical-infrastructure companies where the work either shows up in the P&L or it doesn’t. We are not evaluating AI from the outside. We are living in the place where the acceleration is real and the coordination is what breaks. AgentOS is what we built to hold it together, and as of today it’s open source and free to use. You can get it on GitHub right now: try it, break it, contribute, open an issue, tell us where it’s wrong. We’d love to hear from you. Here’s what it does, and why we built it.
What AgentOS does
• Goal-oriented orchestration: breaks a goal into workstreams and assigns work across humans and agents while tracking dependencies in real time, so the team stays aligned to the outcome instead of drifting into disconnected tasks.
• Agents that manage the work, not just do it: flags misalignment, surfaces blocked dependencies, and catches drift before it costs the team a day. Coordination scales with output instead of breaking under it.
• Self-improving platform: watches the AI landscape across models, MCP servers, frameworks and tools, and pull relevant improvements back in, so the platform keeps improving without a standing research project.
• Contribution ledger: records who did what, which decision was made, what output was created, and how it moved the goal: a clearer basis for compensation, performance and capital allocation than task counts.
Why we built this
When AI coding tools got good inside our own work, the first result was obvious: every engineer could do far more, far faster. The problem showed up immediately after. Once everyone on a team has that kind of acceleration, keeping the team pointed at the same goal becomes the hard part.
Most AI development tools are still built around tasks. Give a model a prompt, hand an agent a job, get an output back. That was fine when AI was helping at the margins. It breaks the moment AI is doing a meaningful share of the work and humans and agents are all moving in parallel.
At that speed, a team can drift in a single day. One engineer refactors a service. Another builds against the assumption that service just invalidated. An agent generates tests for a path the team is about to abandon. Someone updates documentation for a feature that’s already changing underneath them. Everyone is producing. Nothing is converging.
Microsoft’s own data makes the trap visible. In its early-2026 rollout of Claude Code and GitHub Copilot CLI, teams merged roughly 24% more pull requests than they otherwise would have. Microsoft was careful to note that a merged pull request is a proxy for output, not a measure of value. Put that next to the slowdown study and you have the whole problem in two numbers: more work moving through the system, no guarantee the system is getting anywhere.
Even the researchers who pushed back on the slowdown finding end up here. Faros AI, studying more than 10,000 developers, argued the effect is real but that the cause is structural. AI unlocked velocity, and existing workflows for review, testing, deployment and cross-team coordination can’t keep up with it. Developers don’t work in isolation. They work inside a system. The system is what’s failing.
From task-based AI to goal-oriented engineering
Engineering teams don’t exist to complete tasks. They exist to reach goals.
AgentOS starts from the goal and works backward. It breaks the goal into workstreams, assigns work across humans and agents, tracks dependencies, and keeps asking the one question the task-based tools never ask: is the team still moving toward the outcome? More code, more tests, more pull requests is not the point. Whether all of it is adding up is the point.
Agents should help manage the work, not just do it
Agents shouldn’t only wait to be managed by humans. They should help manage the work happening around them.
If two engineers are building in directions that no longer fit, the system should say so. If a dependency is blocked, it should surface it. If work is drifting from the goal, it should flag that before the team loses a day to a wrong assumption. There are dozens of tools that help an individual engineer produce more. There are almost none built to keep the team coherent once everyone is producing more. That gap is what AgentOS is for.
The market moves too fast to track by hand
Keeping up with AI is now more than a full-time job. New models. New MCP servers. New agent frameworks. New tooling. Some of it won’t matter in a month; some of it will be foundational. Expecting a founder, CTO, or engineering lead to sort that out manually, while also running the business, isn’t realistic.
AgentOS runs agents that monitor the landscape and pull relevant improvements back into the system. The goal isn’t for every team to read every launch thread and hand-wire every update. It’s for the system to keep getting better as the field does, without turning your engineering org into a full-time research department.
Attribution is now a business problem
Every AI-assisted team is going to hit the same question, and it’s not a technical one. When everyone is using AI to write code, who actually created value? Not who typed the prompt, merged the branch, or shipped the most visible output. Who moved the team closer to the goal? That answer drives compensation, performance, team design and where you put capital. The old signals were already rough. AI makes them worse.
The people who built the field’s measurement frameworks are saying this out loud. Nicole Forsgren, who created the DORA and SPACE frameworks most engineering orgs measure themselves against, has spent the last year arguing that activity-based metrics fall apart once AI is writing a meaningful share of the code. When commits and pull requests can be generated on demand, counting them tells you how busy the system is, not how much it accomplished. The consensus forming in 2026 is that measurement itself has to change: that volume has to give way to contribution, and that AI’s role in the work has to be made legible instead of blurred into a headcount number.
AgentOS includes a contribution ledger that records who did what, what decision was made, what output resulted, and how it moved the goal. Because the whole system is goal-oriented, contribution connects to progress instead of collapsing into a task count. It is, in effect, the attribution layer the measurement frameworks are now saying they need.
Neurometric is a leader in the tokenminning movement: it builds and hosts task-specific SLMs that hit frontier-beating accuracy at a fraction of the cost of general-purpose models. Calvin Cooper, a Director at our firm, co-founded Neurometric and serves as its COO, and he has seen firsthand that AI implementation is now a top priority inside enterprises. What has changed is the emphasis. The first wave was tokenmaxxing: more tokens, more model, more spend thrown at every problem. The shift now underway is toward AI efficiency, making sure the money already going into AI actually produces value. AgentOS is our team’s version of that discipline pointed at engineering. It exists to make sure the speed and the spend are turning into impact, not just activity.
Why open source
We’re open-sourcing AgentOS because the problem is bigger than us. Every serious engineering team using AI will hit some version of it, and the more capable the tools get, the more urgent the coordination problem becomes. This isn’t something one team should solve in a closed room while pretending it has all the answers.
AgentOS is available now at https://github.com/Pilot-Wave-Technology/AgentOS. Try it, contribute, or send us feedback at info@pilotwaveholdings.com. This is version one, and we expect it to change quickly.
AI already settled the question of how fast an engineer can move. The open question, the one that will separate the teams that compound from the teams that just look busy, is whether they can keep that speed pointed at something that matters.