At Every, No One Writes Code, but People Are the Bread of the Sandwich

Summary

• Agents took over the code and the chores, and people took the planning, the review, and the polish.
• Headcount did not shrink after automation. Work moved to review and to recording lessons.
• The more output piles up, the more you need a mechanical filter before expert review.

What a small team said to move like a company ten times its size really looks like

On April 13, 2020, a small subscription product that bundled two paid newsletters came out. It was a modest bundle that let readers subscribe to Dan Shipper’s Superorganizers and Nathan Baschez’s Divinations at once. The company’s explanation at the time was simple: “Before, you had to subscribe to each newsletter separately.”

A few years later, Every began describing itself on its careers page as “a media company, a software company, and a consulting company.” It publishes a daily AI newsletter with more than 130,000 subscribers, advises companies on adopting AI, and builds and runs software products in-house. Apps such as the email assistant Cora, the writing tool Spiral, the dictation app Monologue, and the file organizer Sparkle came out of that. The careers page describes the organization as a team that “ships like a company ten times its size.”

They draw attention not simply because they produce a lot. It is because the way they build software is completely different from a traditional development organization. In a piece written together by CEO and co-founder Dan Shipper and Kieran Klaassen, the general manager of Cora, published on December 11, 2025, this declaration appears: “Nobody is writing code manually.”

The record of this case comes mostly from articles written by Every’s own people and from a podcast transcript, and customer stories published by the collaboration tool Notion and the cloud platform Render add concrete detail. Every is also a company that releases the tools it made along the way and sells AI agents, subscriptions, and consulting.

It was not a tech company built around agents from the start. It is closer to a field report of a small team that started as an ordinary newsletter publisher, widened into software and consulting, and then rebuilt software development, writing, and day-to-day operations around agents.

Products multiplied, and the traditional way of developing hit its limit

As of December 2025, Every ran five software products in-house and was preparing a few more. Each product was used by thousands of people every day for important work, but the structure was that each was “primarily built and run by a single person.” A small organization simply did not have the physical resources to carry several products at once.

Dan Shipper and Kieran Klaassen pointed to a structural contradiction in traditional engineering. In traditional development, every feature you add makes the next feature harder to build. As code grows, unexpected edge cases multiply, the dependencies between pieces of code get tangled, and errors that are hard to predict keep piling up. The authors saw that software engineering until now had been built on the premise that “coding is hard and engineers are scarce.” The moment agents could write code, that old premise began to shake.

There was a bottleneck in the editing process of writing and polishing, too. The main job of editor-in-chief Kate Lee is the “top edit,” the last review before publication. But the editor-in-chief, who should be fixing a piece’s structure and direction, often read a piece for the first time only at the last stage. Because she often read the piece for the first time at this stage, her judgment came in only at the very end.

Operations were also tangled. Before Notion came into full use, marketing materials were mostly scattered across Google Drive, and important context was often buried and lost in Slack conversations. Information that people found hard to find was also hard for agents to reach and use.

But by around May 2026, the bottleneck had moved somewhere else. On a podcast, Dan Shipper described the landscape after automation like this: “the automation produces a glut of work that’s all okay, all reasonably good,” and “So you flood the zone with tons of stuff that’s close but not quite right.”

COO Brandon Gell handed over a pull request (PR) with the joking words “I literally have no idea if this works, but here you go,” and Dan Shipper recalled that the reviewer who received it “completely redid” the code. Making code and stamping out text had become very easy, but the review work of pinpointing whether it is truly right had become the organization’s most precious bottleneck.

Compound engineering: 80% goes to planning and review

To solve this problem, Every built a method it calls “compound engineering.” It is a way of stacking up what you learn bit by bit so that each feature you build makes the next one easier. The authors said the effort splits roughly 80% into planning and review and 20% into the actual work and compounding. Instead of time spent typing code, most of the work became time spent refining the plan handed to the agent and picking apart the results.

The early compound engineering loop ran in four stages.

The first is the planning stage. The agent researches widely: the existing codebase, past commit history, and best practices on the internet. Then it writes a plan document, as a file or a GitHub issue, that holds the goal, the architecture, the code approach, the sources it consulted, and the success criteria. It is not that people let go and hand everything over. The developer reviews what the agent researched and corrects the direction. The authors stress that “Good planning is not pure delegation.” In a setting where agents write all the code, most of a developer’s time goes into this planning stage.

The second is the work stage. The agent makes a step-by-step to-do list from the approved plan document and writes the actual code. Here the agent does not stop at typing code. It uses Playwright, a web browser automation tool, or XcodeBuildMCP, which controls a mobile environment, to use the web app itself or imitate a phone screen and catch errors on its own.

The third is the review stage. A linter, which is a code syntax checker, unit tests, and manual tests that a person tries by hand run together. Inside the company, they use code review agents such as Claude, Codex, Friday, and Charlie. In particular, the plugin that Every developed for Claude Code and published under the EveryInc account on GitHub runs 12 review sub-agents at the same time, in parallel. The sub-agent perspectives that the original text names are three: common security problems, common performance problems, and code that is over-engineered, made more complex than it needs to be. After the 12 agents each sweep through the code with their own eyes and the results are merged into one, the developer looks at that summary and makes the final decision on what to fix.

Review sub-agents checking in parallel

The fourth is the compound stage. Every lesson learned while building the feature, whether a bug it ran into, a performance problem, or what it learned in solving them, is recorded inside the codebase or the plugin in the form of prompts and rules. The comments exchanged in code review are also summarized and stored. These lessons are kept together with the codebase, so even someone who joins today and has never seen the code can, through the agent, avoid common mistakes in advance as well as a colleague who has worked there a long time.

Every engineers mainly use Anthropic’s Claude Code, and some use Factory’s Droid or OpenAI’s Codex CLI. The authors wrote, “Manually writing tests or writing human-readable code with lots of documentation is now unnecessary.”

The polish stage where people return: a loop widened to eight stages

On May 29, 2026, Kieran Klaassen published a loop that widens the old four stages to eight. The flow starts with ideate, then goes through brainstorm, plan, work, and review, and continues to polish, compound, and repeat.

The key to this expansion is the newly added “polish” stage after review. Even if the agent has written all the code and it has passed tests and review without a problem, this is the process in which a person looks at the screen, checks the design and the wording, and sees how it actually feels. Kieran Klaassen gave this reason for adding the stage: “Sometimes everything technically works, but the product is still not good.” His explanation is that the work stage, where agents catch mechanical errors, “has become boring—in the best way.”

Every's compound engineering loop, expanded

Trevin Chow, whose title on the team page is Compound Engineering maintainer, explained this collaboration structure with a sandwich. “AI is the stuff in the middle. Humans are the bread on either end, holding it together.” He means that planning what to build at the start, and shaping the taste and texture of the product at the end, belongs entirely to people.

The Render customer story shows how Kieran Klaassen actually runs Cora. He uses a long run command he calls “lfg.” With this one command, the middle of the loop, from making the plan through implementing the code, testing, and creating the PR, runs mostly without a person. Depending on the size of the task, one run takes anywhere from about an hour to as long as sixteen hours.

He keeps the running app open next to the agent’s session and reviews by watching the screen himself. His iron rule is to spend half the time on a feature building the product and the other half recording what the work taught him. He also runs a separate audit command that periodically re-checks the whole set of lessons built up so far, to confirm that each rule still fits the current codebase.

According to the Render piece, Kieran Klaassen did not write a single line of code himself that year and did not even look at the code. He oversees the whole of Cora’s product planning and engineering, while design, marketing, and customer support are each handled by dedicated colleagues. On the podcast, Dan Shipper said that Kieran Klaassen built Cora’s whole inbox, from start to finish, “in about a month or two.”

In the real work, this compounding of lessons was likely run in a semi-automated way, not as a hand-kept record. When a feature was done, a script was probably run to gather the code changes, the comments left by the 12 sub-agents, and the record of fixed errors, and to tidy them automatically into a rules file for the agent to read on the next task. And when rules grew so many that they conflicted or pointed to old code, the agent probably picked out unneeded rules through the separate audit command and suggested deleting them, and people approved this.

Agent collaboration that spread to the editorial room and Slack

The approach of putting agents at the center of the work spread in the same way outside the development team.

The work of Every’s editorial room splits into three stages: the “developmental edit,” which sets a piece’s central thesis and structure, the “line edit,” which polishes the sentences, and the “top edit,” the final check by editor-in-chief Kate Lee. Agents step in at every stage.

Staff writer Katie Parrott opens a Claude project before writing a first draft and has the agent interview her, asking one question at a time. Only after working out her thoughts in words and firming up the logic does she start writing. Every first draft must pass the company’s standards, which ask whether it is truthful, useful, and has its own voice. Questions such as “Does this writing articulate something true?” are the standard.

Eleanor Warnock, who was managing editor as of February 2026, used AI for a first judgment on pitches and first drafts, for unpacking complex technical paragraphs so they are easy to understand, and for a final sentence check against the company style guide. When deciding on subtle, subjective wording, editor-in-chief Kate Lee opens the Spiral app and gets suggestions for different ways to rewrite. Anthony Scarpulla, who handles social media posts, gets “building blocks, not finished posts” from Claude, and then a person carefully reads every post and gives the final approval.

The editorial team made three core prompt skills, a top edit skill, a skill that filters out the cliched phrases that give away AI writing, and a style guide checker, and stores them in the company’s GitHub and updates them together. Dan Shipper gathered 30,000 of editor-in-chief Kate Lee’s historical copyedits and built a new skill called “Kate Pass,” which he described in an October 2026 post. When a team member asks the agent to review a draft, the agent leaves its edits as suggestions directly on the Google Doc.

In practice, all this large body of editing data probably did not fit into a single prompt either. The team likely used agents to sort the 30,000 edits into typical correction patterns, such as trimming filler phrases and tightening openings, and turned them into a book of best practices. Then it likely built the agent to connect to the document tool and leave comments in suggestion mode, without damaging the original.

In day-to-day operations too, adopting agents evolved step by step. In March 2026, Every released “Plus One,” a personal assistant it had been using internally. It was a personalized agent based on OpenClaw that runs inside Slack. Members used it to triage bugs, draft marketing copy, and run growth experiments. COO Brandon Gell set up his own Plus One in 45 minutes and had it organize bug reports into Notion and summarize his calendar for a daily morning briefing. Austin Tedesco, the head of growth, built and uses an agent himself with Claude Code, but admitted he still spends a fair amount of time tinkering with the system. Trust built slowly. They started by handing over very small jobs and widened the agent’s range of responsibility a little at a time.

On October 6, 2026, Every announced the “Every Agent,” a single agent that the whole company shares, merging the personal assistants everyone had been using separately. It was built on Claude Managed Agents and had been used inside the company for about six months before launch.

The key to this change was “collaboration in the open.” If you call @Every in any Slack channel and write down a task, the agent handles the work right there in the thread. The feedback that people give as corrections in the thread is stored as is and carried into the next job. Dan Shipper explained, “Prompting in public works because most AI use is invisible.” It lets colleagues learn from each other by watching how they assign work to the agent and correct it.

Actual use did not depend on job type. Brandon Gell had the agent create a speaker contract with Documenso and draft a cover email to send with it. Douglas Brundage, the head of marketing, had the agent create a PR that adds two speakers’ profiles to the Thesis conference website, and an engineer reviewed it and merged it into the code. Arielle Shipper, the head of operations, makes a weekly leadership report that combines service performance, website visitors, and email statistics and points out where the numbers do not match. Mike Taylor, the head of evals, made and uses a personal skill that, every Monday, checks the things left unfinished and resets the week’s priorities.

Every now sells the same agent to other companies’ Slack workspaces.

In the Notion customer story, quarterly planning was also handled by an agent. The OKR interview agent that Brandon Gell built interviewed every employee one on one, based on leadership’s priorities, and then wrote a standardized plan. The interviews were “basically done in a day,” and managers only had to review and approve the finished plans. Austin Tedesco spent only about 20 minutes setting up the next quarter’s plan.

Management of growth metrics was also automated. Notion Workers query four data sources (the internal admin tool, Kit, Stripe, and PostHog) every six hours and organize the results, and then an agent posts a growth scorecard to Slack at 7 a.m. every day. Austin Tedesco only checks by eye that the numbers look right and moves on. He had Codex or Claude Code build the agent, the workers, and the databases by describing the structure he needed in words, and said he has never once read the Worker code that actually runs. Brandon Gell summed up the organization’s operating principle in one sentence: “No one at this company should do computer errands.”

The more you automate, the more precious experts become

The role of people inside the organization changed completely. On the podcast, describing the mood in the company’s Slack, Dan Shipper said “you’re as likely to hit a human as you are an agent.” Not only developers but every member uses Claude Code and Codex in daily work, everyone makes PRs, and, in reverse, engineers write essays.

Tight gates were put in place so that PRs from non-developers do not break the system. Dan Shipper explained, “we have repo rules and review guidelines so that before Willy sees a PR, it’s gone through a bunch of processes.” It is the same structure as the editorial room, where a piece goes through several verification skills before it reaches the final desk.

In practice, when a non-developer opens a PR, the integration build system probably runs the linter and automatic tests first, and the 12 review sub-agents in the plugin likely leave review comments on whether it meets the security and performance rules. Only after the agent fixes the flagged problems on its own does a notification go to a reviewer like Willy, and the authority for final approval and merging the code probably stayed with the engineers to the end.

What work do people do in such an environment? Brandon Gell stressed, “Experts are more important than ever because they lay the groundwork for an agent to do amazing work.” This is because the sense that sets the standard for what is good code and what is a good piece of writing, and the eye that spots the flaws in what agents pour out at a glance, are exactly the areas that cannot be automated.

On the team page, the structure of the organization has changed accordingly. Unfamiliar titles appear: head of evals, head of AI education, head of enterprise AI adoption, applied AI engineer, head of platform, and Compound Engineering maintainer. On the other hand, there is only one person dedicated to customer support.

The change is also clear in numbers. In the December 11, 2025 piece, the authors, drawing on Every’s experience, estimated that “a single developer can do the work of five developers a few years ago.” But this was not a means of cutting staff. On the podcast, Dan Shipper said the headcount had grown from four people in the early days of using GPT-3 to about 30. The Notion customer story says about 30 agents run on a team of 20, and the team page checked on October 22, 2026 showed 34 people in total, including contributing writers.

Dan Shipper confessed in a May 2026 essay: “We’ve automated everything we can here at Every.” “Yet there’s more human work to do than ever.” He also added on the podcast, “we’re hiring more now.” Automation did not shrink the company, and people’s time moved from writing code by hand to planning, review, polish, and recording lessons.

What other organizations should take from this case

When you look at Every’s experiment, you should keep a few limits in mind.

Every is, at its base, a small organization. It is a company that covers AI technology itself every day and writes about it, and its members’ understanding and interest are unusual, to the point of publishing a review on the day a new foundation model launches. Above all, the software products it runs are small, and each product is run by one person holding full authority. Whether this approach would work the same way in a large company that handles a huge legacy codebase tangled over decades by hundreds of engineers has not yet been proven. Also, since Every itself distributes related tools and provides consulting to companies, there may be a motive built in to present its own experience in a more attractive light.

Even so, the trial and error Every has gone through raises important questions for business leaders of any size and industry.

First, in the age of generation, review becomes the scarcest resource. Bring in agents and you produce code and drafts quickly and in large volume. But most of that output stays at the level of “close but not quite right.” If an expert then tries to check each piece with no safeguard, the whole organization is paralyzed by review fatigue. Like the 12 sub-agents or automated repo rules, a multi-stage filtering mechanism must come with it, one that filters out mechanical errors before the output reaches the expert’s eyes.

Second, what people produce must always be accumulated as rules for the next agent. That is why Kieran Klaassen spends half of his working time organizing what he learned, and why Dan Shipper turned Kate Lee’s 30,000 past edits into a skill. If you do not leave the cause and the fix of a solved problem in the form of a codebase or a prompt, the next agent that runs will repeat the same mistake endlessly. You need to set up rules so that work does not end as a one-off but remains as an asset for the next job.

Third, adopting AI must move out of a private back room into an open square. When everyone used a personal assistant alone, no one could tell who was getting what efficiency with which prompt, and some even lost time tinkering with their tools. But when people shared how they work by calling @Every in Slack’s shared channels, they could see and copy each other’s prompts in open channels, and the use of AI spread faster.

Typing code by hand and fixing sentences by hand are steadily disappearing. But the depth of planning that decides what to build, the sense for shaping a technically finished product to the user’s eye level, and the critical review that watches so the system does not stray down the wrong path remain areas for people alone. The more you hand work to machines, the more important the standards of the person who sees through the result become.

---

Sources

1. Every (Dan Shipper, Kieran Klaassen) — Compound Engineering: How Every Codes With Agents
   https://every.to/source-code/compound-engineering-how-every-codes-with-agents — 2025-12-11 (primary)
2. Every (Kieran Klaassen) — Compound Engineering Gets an Upgrade
   https://every.to/source-code/compound-engineering-gets-an-upgrade — 2026-05-29
3. Every (Dan Shipper) — After Automation (free excerpt read)
   https://every.to/p/after-automation — 2026-05-21
4. Every — Transcript: ‘We Automated Everything With AI and Tripled Our Headcount’ (AI & I podcast, Dan Shipper with Brandon Gell)
   https://every.to/podcast/transcript-we-automated-everything-with-ai-and-tripled-our-headcount — 2026-05-27 (page date; the transcript refers to the May 21 essay as “yesterday”)
5. Every (Every Staff) — Everyone Gets a Sidekick
   https://every.to/p/everyone-gets-a-sidekick — 2026-03-29
6. Every (Dan Shipper) — Introducing the Every Agent
   https://every.to/on-every/introducing-the-every-agent — 2026-10-06
7. Every (Kate Lee) — This Is How the Every Editorial Team Uses AI
   https://every.to/p/this-is-how-the-every-editorial-team-uses-ai — 2026-02-23
8. Every — Team page
   https://every.to/team — accessed 2026-10-22
9. Every — Careers page
   https://every.to/careers — accessed 2026-10-22
10. Every (Dan Shipper, Nathan Baschez) — Superorganizers and Divinations bundle announcement
    https://every.to/everything/introducing-the-superorganizers-divinations-372366 — 2020-04-13
11. Notion — Every customer story (vendor)
    https://www.notion.com/customers/every — undated; accessed 2026-10-22
12. Render (Hazal Mestci) — Half the feature is the lesson: how Kieran Klaassen runs Cora without touching the code (vendor)
    https://render.com/blog/half-the-feature-is-the-lesson-how-kieran-klaassen-runs-cora-without-touching-the-code — 2026-07-26