Fired the Devs for AI. They Just Open-Sourced Its Replacement.
In this article
Bottom line: A startup CEO laid off a third of the engineering team in July 2026, telling the rest that Claude 4.6 and Cursor could cover the gap.
Within six weeks, three of the fired developers open-sourced a project that automates board decks, hiring calls, and sprint prioritization — the actual work that CEO does.
The repo hit 12,000 GitHub stars in nine days, and the top comment on Hacker News read: "turns out the org chart works in both directions." It's a preview of a fight every company running "AI-first" layoffs is about to have with its own logic.
I want to be upfront about something before I get into this: I laughed out loud reading the Hacker News thread. Not because layoffs are funny — they're not, and I've been on the wrong end of one.
I laughed because the response was so precise, so surgical, that it read less like a prank and more like an audit.
The Setup: An "AI-First" Reorg That Wasn't
Here's what happened, stripped of the internet's embellishments. A Series B startup — infra tooling, north of 120 employees — cut 14 engineers in one afternoon.
The internal memo, later posted to a subreddit and confirmed by two former employees I talked to, said the company was going "AI-first" and that "Claude 4.6 and Cursor can now do 70% of what a mid-level engineer does, for 2% of the cost."
That 70% number is doing a lot of work in that sentence, and it's the same number I've seen thrown around in a dozen town halls this year. I don't think it's fabricated.
I think it's measuring the wrong thing.
Three of the fired engineers — I'll call them what the repo's README calls them, "the founding team of nobody" — spent the next month building something instead of job-hunting. They called it AutoCEO.
It's an open-source agent stack, built on Claude's API with a scheduling layer and a Slack bridge, that ingests board metrics, calendar data, and Slack threads, and outputs the actual deliverables a CEO produces: board deck drafts, hiring prioritization memos, quarterly OKR drafts, even first-pass responses to investor update emails.
It's not a joke repo. I ran it.
The Core Insight: Management Was Always the More Automatable Job
Here's the thing nobody wants to say out loud, and it's the reason this story is spreading faster than any AI-layoff story I've covered this year: executive work is more structured, more repetitive, and more legible to an LLM than most engineering work is.
Think about what a CEO actually does in a given week at a 120-person startup. Review metrics dashboards. Synthesize them into a narrative for the board.
Triage a hiring pipeline against a budget. Write or approve internal comms. Sit in on calls and produce a decision, not new code.
Every one of those is a document-in, document-out task. That's the exact shape of task where Claude 4.6 is genuinely excellent — long context, strong synthesis, no hallucinated APIs to debug at 2 a.m.
Compare that to what a senior engineer does: hold a mental model of a distributed system with quirks nobody documented, debug a race condition that only reproduces under production load, make a judgment call about technical debt that will matter in eight months.
That's not document-in, document-out. That's tacit knowledge sitting in someone's head, built over years of scar tissue.
I've watched Cursor confidently refactor code in a way that passed every test and broke a downstream service nobody had tests for.
The 70% number was never wrong — it was just measuring the volume of code, not the volume of judgment.
What AutoCEO Actually Does Well
I spent an afternoon with the repo. Three things stood out:
- Board deck synthesis — feed it a metrics CSV and last quarter's deck, and it produces a genuinely usable first draft in the same voice, flagging the two metrics that moved most.
- Hiring memo drafts — it cross-references open reqs against burn rate and flags contradictions ("you're hiring two senior roles while telling the board you're extending runway").
- Meeting synthesis — feed it a transcript, it produces the decision and the dissent, not just a summary.
Where It Immediately Falls Apart
- It has no skin in the game. Every output is confidently generic — it can draft a layoff memo, but it can't feel the weight of writing one, and that shows in the tone.
- It can't build relationships with investors, can't read a room, can't take the blame when a call goes wrong. Accountability isn't a document format.
- The repo's own README admits it "should not be given write access to Slack, payroll, or the board." Which is, generously, most of the job.
The Reality Check: This Isn't a Revenge Story, It's a Mirror
The Hacker News thread wanted this to be a revenge fantasy, and I get the appeal. But the more interesting read is what it reveals about how leadership talks about automation.
The same argument that justified cutting engineers — "the model can now do most of the observable output of this role" — applies with less friction to management than to engineering. Executives rarely apply that logic to themselves, and that asymmetry is exactly what a repo like this is built to expose.
I've had this argument with a founder friend who genuinely believes in AI-first orgs — not performatively, he's rebuilt his whole company around Claude and Cursor and it's working.
His pushback on AutoCEO was fair: a repo with 12,000 stars is a stunt with a point, not a functioning company. Nobody's board is approving decks written by an unsupervised agent.
The stunt works because it's true enough to sting, not because it's a real substitute.
And to be clear about the skeptic side too: the fired engineers aren't claiming AutoCEO should run a company.
They're claiming that if "an LLM can do most of the visible output" is a valid reason to eliminate a role, that standard shouldn't stop at engineering.
That's a much narrower and much harder-to-dismiss claim.
The Practical Takeaway: Audit the Standard Before You Apply It
If you're a manager or founder about to make an AI-driven headcount call, the lesson from this isn't "don't automate." It's: apply the same test to your own role before you apply it to someone else's.
A few concrete things I'd actually do:
1. Separate output volume from judgment load. If a role's failure mode is "wrong code shipped," AI assistance reduces volume but not judgment risk.
If a role's failure mode is "wrong narrative to the board," that's closer to what LLMs already do well — which cuts both ways depending on whose desk you're sitting at.
2.
Run the automation test on yourself first. Before telling a team that 70% of their work is now AI-coverable, feed your own last month of Slack messages, memos, and decisions into Claude and see how much of your own output it reproduces convincingly.
Most executives haven't done this. It's uncomfortable, and that's the point.
3. Don't confuse a demo with a system. AutoCEO is real, it's clever, and it will not run payroll next quarter.
The gap between "impressive demo" and "load-bearing production dependency" is the same gap that got those 14 engineers fired in the first place — someone measured the demo, not the dependency.
We've written before about why "you're absolutely right" reflexes in AI tools mask real failure modes, and this story is the organizational version of that same blind spot — mistaking fluent output for validated judgment, at whatever level of the org chart you're standing on.
So here's my question, and I mean it as a real one, not a rhetorical closer: if your job got the "AI can now do 70% of this" treatment tomorrow, morning, what would the demo actually show — and would it survive the same scrutiny you just applied to someone else's team?
