A few days ago, Maggie Appleton from GitHub Next gave a talk titled "One developer, two dozen agents, zero alignment."[^1] If you haven't watched it, you should. It's sixteen minutes that reframe the entire conversation about AI productivity.
Her thesis: we've been building AI tools that make individuals faster. But "believing individual productivity leads to great software is nine-women-make-a-baby logic." More individual output doesn't solve problems that require communication and coordination. It makes them worse.
She's right. And I've been watching the chip-design version of this problem play out for twenty years.
(If you're new to this series: Part 1 explored the tension between precision and judgment in engineering teams. Part 2 examined why single-player AI accelerates the wrong thing. This piece is about what changed — and what comes next.)
---
What GitHub Got Right
Maggie names something the industry has been dancing around: "Implementation is rapidly becoming a solved problem. Agreeing on what to build is the new bottleneck."
That sentence could have been written about chip design in 2006. Or 1996. The difference is that AI has accelerated the implementation side so dramatically that the alignment bottleneck is now impossible to ignore — even in software, where the cost of getting it wrong is a sprint, not a $50 million respin.
She goes further: "Most of the context you need for alignment is not in the codebase. It's in people's heads." We've been calling this tribal knowledge. It's the methodology a senior engineer carries, the constraints discovered three projects ago, the rationale behind a tradeoff that nobody wrote down because there was never time.
And she says something I think is genuinely brave for someone at GitHub: "Coordination tools are still from another era... designed for an outdated way of building software." GitHub is publicly admitting that pull requests and issues — their core product — aren't built for a world where twenty agents are making changes simultaneously.
I respect that. It takes intellectual honesty to look at the tools you've built and say they're not enough for what's coming.
---
Where Chip Design Has Been Living This
Here's what's different about our world.
In software, when alignment breaks, you ship a bug. You patch it. You deploy a fix over the weekend. The cost of misalignment is a sprint.
In chip design, when alignment breaks, you get a respin. The mask set alone costs millions. The schedule slips six months. The market window closes. Careers get derailed. Only 14% of chips succeed on first silicon, and roughly 70% of those failures trace back not to physics, not to engineering errors, but to misalignment between teams. Spec drift. Assumptions that diverged silently. Verification running against constraints that changed three months ago.
We've been paying the alignment tax for decades. We just never had a name for it.
And the AI paradox Maggie describes — individual speed up, system-level chaos — is already measurable. In software, where the data is more abundant, a peer-reviewed trial by METR[^2] found that experienced developers using AI tools actually took 19% longer to complete tasks, despite believing they were 20% faster. A separate analysis of 10,000+ developers by Faros AI[^3] showed 98% more pull requests merged, but review times up 91% and zero improvement in organizational delivery velocity.
If you think about it, this is exactly what happens when you accelerate every individual without connecting the system between them. The output inflates. The alignment and coordination cost absorbs the gains. The team doesn't actually move faster.
We've been watching this in chip design for twenty years. Now software is discovering it too.
---
Three Areas of Work — Only One Has Infrastructure
Whether you're building software or silicon, engineering work falls into three areas:
Intent — developing and communicating what we're building and why. What are the constraints? What changed? Who needs to know?
Knowledge — making sure everyone follows the right methodology, the right best practices, learning from previous mistakes and previous designs.
Execution — running the simulations, writing the code, doing the layout, verifying, iterating until it's right.
Today, execution has intelligent infrastructure. That's what EDA tools are. That's what IDEs and CI/CD pipelines are. Decades of investment, billions of dollars, genuinely good tools.
Intent and knowledge? We're on our own.
To align around intent, we write specs in Word or Excel. We hold meetings to review results and keep everyone in sync. We go through iterations that take days or weeks — just to make sure three disciplines share the same understanding. And the spec is maybe 10% of intent. The other 90% — every decision, constraint, rationale, and tradeoff — lives in meetings, email threads, and people's heads.
To align around knowledge, we create scattered documentation. Checklists in someone's folder. Best practices that propagate top-down in meetings half the team misses. Lessons learned that get captured once and never found again.
Even with all of that effort, people within the same team still miss things. Specs drift. Knowledge disappears when someone leaves. The 20th project starts from scratch even though 90% of the methodology is reusable.
Maggie's GitHub talk names this for software. We've been living it in chip design at 100x the stakes.
---
What Would It Take to Actually Solve This?
In the first two articles of this series, I described the tension between precision and judgment in engineering teams, and why single-player AI accelerates the wrong thing. Now I want to think about what a real solution would require.
If you accept that engineering work has three areas — intent, knowledge, and execution — and that only execution has intelligent infrastructure today, then the question becomes: what does intelligent infrastructure for intent and knowledge actually look like?
Intent needs more than a better document. The spec is maybe 10% of design intent. The other 90% is every decision, constraint, rationale, and tradeoff that shapes what the team is building — and it lives in meetings, email threads, hallway conversations, and people's heads. What intent needs is a system that keeps all of it connected and current as the design evolves. Not a repository that stores what someone wrote down last quarter. A living system where changes propagate to whoever depends on them, and where what's being built can be continuously checked against what was intended.
Knowledge needs to compound, not disappear. The fact that a senior engineer's methodology is 90% reusable across projects — but gets rebuilt from scratch every time — tells you the problem isn't that knowledge doesn't exist. It's that there's no infrastructure to capture it from the work itself. Not from documentation that nobody has time to write. From the decisions engineers make every day. If knowledge compounded the way code does through version control, your 20th project would start where your 19th left off. New engineers would ramp in weeks, not months. And when someone leaves, the knowledge wouldn't leave with them.
Execution needs intelligence around the tools, not just faster tools. EDA tools are powerful. But the intelligence around them — what to run, when, how to interpret the results in context, how to chain steps together — is still manual. Engineers write scripts, parse log files, re-run the same testbenches. What execution needs is AI that understands the design context, wraps around the existing tools, and handles the mechanical work so engineers focus on judgment.
Three areas. Three infrastructure gaps. That's what we're working on at AIDAChip — and I think anyone building multiplayer AI for any engineering domain is going to run into the same three.
---
Why a General-Purpose Tool Can't Solve This
GitHub ACE is a thoughtful step toward multiplayer AI for software. But chip design isn't software with higher stakes. It's a fundamentally different domain:
The specs aren't code. Chip specifications are multi-level, multi-discipline documents where a single parameter change cascades across analog, digital, verification, layout, and signoff. A markdown plan doc can't represent that structure.
The tools aren't interchangeable. Chip design uses vendor-specific EDA tools — Cadence, Synopsys, Siemens — with proprietary formats, PDK dependencies, and regulatory requirements. The execution engine has to understand each tool chain.
The stakes per cycle are different. A software sprint gone wrong costs a week. A tape-out gone wrong costs $10-50 million and six months of schedule. That economic pressure demands a different level of rigor in how intent propagates and conformance is verified.
The regulatory environment is different. Export controls, on-premise deployment requirements, customer-owned data, zero telemetry. A cloud-only microVM architecture doesn't work for semiconductor.
The knowledge is different. AMS methodology, corner-case awareness, design patterns for PLLs and SerDes and data converters — this is domain-specific expertise that a general-purpose system will never have.
The thesis is the same: alignment is the bottleneck, and multiplayer AI is the architecture to solve it. The implementation has to be domain-native.
---
The Category Is Now Real
Maggie's talk does something important for everyone working on this problem: it moves the conversation from "is alignment a real issue?" to "how do we solve it?"
A year ago, when we started talking about multiplayer AI and the coordination tax, we spent most of our conversations educating people on why the problem exists. Now GitHub is saying it publicly. The category is real. The question is who builds the domain-specific versions.
For chip design, where the alignment tax has been the invisible bottleneck for decades and the cost of getting it wrong is measured in millions, that's the question we've been building toward answering.
---
If you've followed this series from the beginning — from the two operating systems of engineering teams, through the single-player AI paradox, to this — thank you. Future articles will go deeper into what the three engines look like in practice, with real scenarios from the 18+ engineering teams we've been learning from.
Engineering, Aligned.
---
[^1]: Maggie Appleton, GitHub Next: "One developer, two dozen agents, zero alignment — the case for collaborative AI engineering." April 2026. https://www.youtube.com/watch?v=ClWD8OEYgp8
[^2]: METR (Model Evaluation & Threat Research), "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." July 2025. RCT, N=16, 246 tasks. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[^3]: Faros AI, "The AI Productivity Paradox Research Report." 2025. Analysis of 1,255 teams, 10,000+ developers. https://www.faros.ai/blog/ai-software-engineering
[^4]: Siemens EDA and Wilson Research Group, "2024 IC/ASIC Functional Verification Trend Report." First-silicon success at 14%. https://resources.sw.siemens.com/en-US/white-paper-2024-wilson-research-group-ic-asic-functional-verification-trend-report/
---
Follow AIDAChip
- LinkedIn - Website
---
About the Author
Khaled Alashmouny is the Founder of AIDAChip. With 20+ years in semiconductors — including 13 years leading analog/mixed-signal design teams at Apple — he has 9 IEEE publications and 7 patents. His work focuses on building intelligent infrastructure for engineering alignment: keeping intent, knowledge, and execution connected across teams so engineers innovate instead of coordinate.
About AIDAChip
Engineering, Aligned. AIDAChip is three intelligent AI-driven engines on one platform — spanning intent, knowledge, and execution across all vendors and teams. The Intent Engine captures and propagates design intent. The Knowledge Engine compounds tribal knowledge. The Execution Engine wraps your EDA tools with AI teammates. Together, they run and align the system so engineers innovate instead of coordinate.