Dispatch from the Future: building an AI-native Company – Dan Shipper, Every, AI & I

How do you build an AI-native company when the playbook is still being invented? Dan Shipper starts with that problem, rather than a finished organizational framework. At Every, his team is experimenting with what happens when agents become the normal way engineers build software. Those experiences are useful as working practices that others can examine and extend, not as a claim to have settled how every company should operate.

Shipper describes a “10X difference” between organizations where 90% and 100% of engineers use AI. He gives no measured outcome for that comparison; the mechanism he identifies is organizational. If a remaining group works through traditional, editor-centered methods, the company still has to accommodate those methods. When everybody delegates implementation, the team can organize work around that shared assumption. Full adoption changes which workflows the organization can use, not just how quickly an individual writes code.

Every is his concrete case. Shipper reports the following operating figures at the time of the talk:

The code percentage comes without a stated counting method. His accompanying description is that handwriting code is no longer the team's normal practice: implementation goes through Claude Code, Codex, Droid, or another coding agent.

Each app has a single principal developer. That staffing claim matters because the products are not presented as disposable prototypes: they are applications the company builds and operates for users.

Cora, Every's email assistant, makes the claim tangible. In the interface Shipper shows, incoming-email summaries appear on the left. On the right, an assistant answers questions about the contents of his inbox. He asks when his AI Engineer talk is scheduled and gets an answer directly, rather than having to locate the relevant message himself. Shipper says one engineer built almost all of Cora, with one or two contractors helping in particular areas.

Next comes Monologue, a speech-to-text app he compares with superwhisper and Wispr Flow. Shipper reports that Monologue has one developer and thousands of users. He emphasizes the complexity behind its polished interface. He then shows Spiral as another substantial application with one engineer, without explaining its functionality in this part of the talk. The examples establish the scope of ownership: a developer is responsible for a real product, not merely generating an initial version.

Shipper locates the practical shift in Claude Code's terminal interface: it moves the engineer away from continuously editing code and toward delegating tasks. That makes it possible to work on several features or bugs concurrently. Four open agent panes can be performative, he acknowledges, but Shipper reports that Every engineers productively use four agent panes at once. The useful distinction is whether those agents are advancing separate pieces of work that one developer can direct and assess.

Lower implementation cost also changes which ideas get attempted. A risky prototype becomes easier to start when the first action is to delegate an investigation rather than reserve a large block of engineering time. His example is a possible major refactor: ask an agent to research it, then do something else while that work proceeds. The immediate return is more opportunities to learn whether an idea is worth pursuing.

That changes internal persuasion, too. Instead of writing a memo, preparing a deck, or first convincing colleagues to allocate time, a developer can build a demo that makes the idea concrete. Shipper describes prototypes made in a couple of hours. A demo lets colleagues experience an interaction that may be difficult to justify in words. This is especially valuable for unusual ideas whose appeal only becomes clear when someone can try them.

Once implementation is delegated, engineering needs processes for working at that level. Shipper describes the move as programming upward from Python and JavaScript into English, while recognizing that the resulting practices echo earlier engineering methods. Every calls its approach compounding engineering. Where accumulating features can make subsequent changes harder, its explicit goal is to make each feature leave the next one easier to build.

The loop has four steps:

1. Plan. Describe the work in enough detail for an agent to carry it out.
2. Delegate. Give the implementation task to the agent.
3. Assess. Determine whether the result is good through tests, trying it, further agent investigation, human code review, or agent code review.
4. Codify. Preserve what the preceding steps taught you so it can influence future work.

The fourth step is where an individual task becomes an investment in the team's future capability. Lessons from planning, delegation, and assessment go into CLAUDE.md, sub-agents, or slash commands.

For example, a reusable instruction for the codification step can be written in the same language used to direct the work:

After assessing a change:

- Identify any bug discovered, plan corrected, or delegation problem encountered.
- Extract the lesson that would help with a similar future task.
- Propose a concise update to CLAUDE.md, a sub-agent, or a slash command.
- Explain when the new instruction should apply.

This turns an engineer's private experience into proposed shared instructions. The essential operation is to make tacit knowledge explicit: what went wrong, what corrected it, and what a future agent should know. A prompt library can then distribute those lessons throughout the organization.

The organizational effects start with reuse. Different Every products often need similar capabilities, such as a Teams feature or a particular OAuth implementation, even when they use different technologies. Traditionally, reuse might require extracting a shared library or asking its author to explain the work. With an agent, the receiving developer can point Claude Code at a colleague's repository, have it study the implementation, and recreate the capability in the destination stack and framework.

The third route does not depend on both products adopting the same package. Shipper describes it as sharing without extra cost: more developers create more implementations that agents can inspect. The concrete saving is the reduced need to package or manually explain every useful piece of work.

The next beneficiary is a new hire. Shipper reports that new hires are productive on their first day. Environment setup, expectations for a good commit, and pull-request conventions are already recorded in CLAUDE.md, Cursor files, or Codex files, so the agent has context for setting up the local environment and preparing work in the team's style. As the current Claude Code memory documentation makes explicit, these instructions supply context rather than enforced configuration; assessment still matters.

Lower startup cost also makes short specialist engagements more practical. An expert freelancer can contribute a focused piece of work during a brief visit instead of spending most of the engagement learning how to get started. Shipper compares it to a DJ dropping into a few bars of a song: the surrounding structure is already there, allowing the specialist to add the part they know particularly well.

Every's developers also use the company's other products. When they encounter a bug, a paper cut, or a small quality-of-life improvement, they can download that product's repository, have an agent investigate a fix, and submit a pull request to the app's general manager. The contribution arrives as proposed code that the product owner can review, rather than only as a request that the owner must investigate and implement. Shipper describes this cross-product contribution pattern as already common inside Every.

He then extends the idea to customers: perhaps a customer's agent could investigate a bug and submit a pull request. That is a speculative possibility in the talk, distinct from the internal collaboration already happening. It resembles an unusual form of open-source contribution, with an agent helping a user cross the distance between noticing a problem and proposing a change.

The same ability to enter unfamiliar repositories has let Every defer standardizing on one language or stack. Product builders choose the technologies they prefer, while AI helps translate between languages, frameworks, and environments. Shipper leaves open whether this will remain workable as the company grows. At its reported scale, the reduced cost of working across stacks gives the team more freedom to choose them independently.

The last boundary to move is between managing a product and contributing to its implementation. Technical managers can commit code, including the CEO. Shipper says he had committed production code during the preceding couple of months, despite the other demands of running Every. Technical competence remains part of the claim; the change is that contribution becomes possible on an interrupted schedule.

His example begins between meetings. Ask Claude Code to investigate a bug, leave it working while attending to another responsibility, then return to inspect a plan or a root-cause fix and prepare a pull request. The agent carries the investigation forward while the manager's attention is elsewhere. This reduces dependence on the long, uninterrupted focus block Shipper associates with doing the entire task manually. It is not easy or magical, he stresses, but it is possible.

That brings the adoption argument back to product ownership. Based on Every's experience, Shipper argues that a single engineer should be able to build and maintain a complex production product. Codified learning makes subsequent feature work easier, while agents make it easier for colleagues to contribute across product boundaries. The combination allows concentrated ownership without making every product an isolated engineering effort. He closes that argument with a callback to the opening New York–San Francisco rivalry: perhaps the people in this room are seeing something their West Coast peers have not yet noticed.

Every's business brings those activities together as ideas, apps, and training. The closing offering includes a daily AI newsletter, reviews of new models and products, the application bundle, and training and consulting for large companies, presented as one subscription at one price. The company publishing these experiences is also using them to build the products and teach the practices it sells.