What I believe and where we're headed

The short version

I think we're on an exponential, and we're starting to reach the part where AI helps build AI. Models now write high-quality code, the gap in taste and judgment with strong engineers is closing quickly, and they are getting better at pursuing higher-level goals on their own. Code is becoming cheap. 

Ode's job is to build the team and the playbook that our clients can't build themselves, keep them at the frontier of what AI can do inside real enterprises, and apply them to the biggest outcomes we can find. As the frontier moves, our pods should get smaller, drive bigger outcomes and take less time, and the talent profile of those pods may change. I think we're at a step change in that right now. Today it points toward holistic transformations: clients rethinking large parts of their business, which will eventually take many agents.

How much AI takes over depends on how far you zoom out. Zoomed in on one agent with a clear task and evals, such as turning a patient chart into medical codes, I expect AI to do most of the building soon: writing the agent, improving it against the evals, and building the integrations and supporting software around it. Zoomed out to the whole program, the work is deciding what a client needs, which agents to build and how they fit together, earning the client's trust, and reviewing outputs and correcting them. That end needs much more human involvement and will take AI much longer to absorb. This is also where our edge as a services business is.

What I believe

1. We are on an exponential, and AI is starting to build AI

Capability gains appear to be speeding up, partly because models now help with the work of making better models and better software. Exponentials are hard to reason about: people expect next year to look like this year plus a little, and on an exponential it looks very different. I think the evidence supports this, but it isn't certain. We shouldn't bet the company on it, but we should be ready for it to be true.

2. AI is getting very good at writing high-quality code, quickly

We went from Copilot autocomplete to shipping large amounts of code through Claude Code in less than two years. Today that still needs engineers with taste and judgment steering it, but that need is shrinking dramatically. In limited cases it's already close: engineers report Claude doing some work better than they do, it reliably one-shots many tasks, and some companies have stopped needing code review for many kinds of changes. It's too early to take our hands fully off the wheel, but it's starting to happen. Someone recently used Opus 5.5 to build native Rust replacements for Adobe apps like Photoshop and Premiere (Reddit post). It likely took a person with taste and a lot of back-and-forth. It's possible today, and it will get easier.

3. The further you zoom out, the longer people stay central

AI is getting better at pursuing higher-level goals. Yesterday, a medical coding agent meant a large hand-tuned prompt full of rules. Tomorrow, AI helps design that system and improves it on its own toward the most reliable way to do the coding. For a task like that, I expect our role to shift from tuning the agent toward defining the goal correctly and completely, and giving the AI the context and knowledge it needs. Pretty soon I expect it to hit a well-defined goal reliably on its own.

Zoomed out, a company transformation needs many agents. Someone has to decide which tasks matter, how the agents fit together, and how to get a real organization with real politics to change. AI will get better at those decisions too, but the larger the scope, the more taste, judgment, trust and comfort with ambiguity it takes. It's a spectrum, and I expect talented people will be needed to lead the zoomed-out end for a long time.

4. Client demand is moving toward transformations

Over our history, the frontier in the enterprise has moved from small AI features, to large AI systems in production, to autonomous agents. What's emerging now is less "build me an agent" and more "I need to rethink large parts of my business," which will eventually take many agents. Not every client looks like this. I see two reasons it's happening now: where companies are on the adoption curve, and models becoming good enough to support many agents inside one company.

5. As code gets cheap, access and knowledge become the constraint

Agents are only as good as the context they can reach. As building gets faster, more of the constraint moves to client systems and knowledge: access, credentials, security reviews, and knowledge that only lives in people's heads. These get easier too. Agents can draft access requests, and voice agents or quickly built tools can capture what subject matter experts know. But they depend on people's time and on how much a company trusts agents with its systems, and those change more slowly than code does.

6. As code becomes disposable, "platform" stops meaning code

I think our reusable platform will look less like a repository of code and more like a repository of specifications: how to build agents, factories and the primitives under them. If I can prompt Claude Code and get working code, saving the prompt is more useful than saving the code, because I can adjust the prompt for the next situation. The version I expect: a generic code factory described in detail in spec files. For each new client, we learn what makes them unique, edit the specs, and build a version specific to them in their environment. As we get closer to "push a button, get Photoshop," it's worth rethinking what platform and product mean.

7. Small teams of elite, trustworthy people

My hypothesis is that our most reliable people will produce much larger outcomes with few or no people under them. The line between PM and engineer is blurring. What I expect to stay scarce is judgment and taste at the program level, client trust, and the ability to find out what a client needs. I still expect hiring to be what limits our growth. We'll be bottlenecked on elite, trustworthy people, but what they need to be elite at will change. The current team is a great foundation, but we all need to push ourselves to ride up the exponential. And we need to evolve our hiring criteria to keep up: a year ago, writing code well mattered a lot; a year from now it won't matter much. 

8. Teach today's work well without locking it in

We need to keep teaching people today's work and doing it well: standardizing, and getting new people up to speed quickly. The best way to teach the work is immersion, with new people doing real work next to experienced people. Classroom teaching helps a little, mostly with knowledge that's easy to write down. The risk is that this effort locks in today's motion, or keeps us from noticing when the frontier shifts and the work needs to change. At 10 people, we changed what we did whenever the technology changed. At our current size, the company is harder to steer, and it isn't always clear whose job it is to notice.

9. Small teams with large impact should be paid for impact

If four people can change a company's economics, pricing close to time-and-materials penalizes the efficiency we're building. There may be a short window where we can do this before others can, and we should try to be paid accordingly: outcome-based fees, or equity in the companies we transform.

10. Being a services business is an advantage in this moment

Product companies standardize and services firms customize, and each approach has a downside. Custom work is slow and expensive, which has limited the problems it makes sense for. Cheap code makes custom work much cheaper. Product companies accept standardization because one expensive codebase can serve many customers. When code is cheap, that codebase is easier to copy and less valuable to own. Both changes favor us. We can keep our know-how in specs, tailor them to each client at the start of an engagement, and build what fits that client in their environment, at much lower cost than custom work used to take.

What we're doing about it

Building an agent factory factory

We're starting a dedicated team to build an agent factory factory. It's the largest investment in core IP we've ever attempted. The team’s job is to build reusable machinery that generates an agent factory for each client and leans on agents to do as much of the building as possible.

The short-term goal is to get our delivery teams leverage quickly on real clients. Can a team of three engineers that today tunes one agent work on fifteen by the end of Q4? Can the same team take on a much larger share of the client’s transformation at once?

The medium-term goal is to move our time away from building individual agents and toward building systems that build agents, often a large number of them. We'll get there incrementally, each piece building on the last, and the exact roadmap isn't settled yet.

Much of the work will look like writing detailed specs that describe generic versions of a few components: a code factory, an agent factory built on top of it, and a knowledge-capture component. Others may follow, such as components for data engineering or ongoing monitoring/security.

Once those exist, we expect an engagement to work like this:

1. Get as much access to and information about the client's organization as possible, possibly using some of these components to help.
2. Customize the specs to the client's situation, needs and systems.
3. Use Claude to generate that client's agent factory from the customized specs, in the client's environment.

We'll use each piece on client work as soon as it helps, rather than waiting for the full stack.

Enhanced playbook for getting clients ready

Our old list of asks for clients (software tools, Mac laptops, access to certain systems, data policies) came partly from what we needed to build the right thing, like access to the right data. It also came partly from wanting to move fast and work in a way that felt natural to us. Because many of the asks rested on a loose sense of speed or comfort, we had no clear principle for which ones mattered, and we often negotiated them away or accepted pushback.

The agent factory changes what we need. If a client wants 400 agents in six months, we have to build with the factory. That requires a specific stack, policies that allow the models we use, access to the client's systems, and openness to new ways of working. We're rebuilding the playbook around those requirements: what we ask for, how we explain why, and which asks we hold firm on.

Some of the readiness work can be automated. With the right access, AI can map a client's systems, processes and domain. As with the rest of delivery, we want people's time going to the parts of readiness that need them.

Data engineering work

Data engineering comes up in a lot of our engagements today: ETL pipelines, data warehouses, ontologies, governance. For large projects, clients sometimes work with other partners on this category of work. For smaller ones, we've sometimes done the work ourselves.

This topic is likely to grow in importance. When many agents at a company consume its data, it's more worth asking what data they need, how they should access it, and what primitives would make the right things available to them in the best way. We will increasingly need to support our clients on this work as it becomes a blocker to them transitioning into a highly agentic future.

I expect best practices for data engineering work to change quickly as we ride up the exponential. As code becomes cheap, so does building ETL pipelines, data integrations, and purpose-built datastores. In a year it's feasible that agents handle much of this work themselves and the data layer becomes more self-organizing.

Evolving our hiring strategy

What makes someone successful at Ode will keep changing as the frontier moves, and our hiring has to keep up. That means the attributes we look for, the interviews that test for them, the recruiting that finds those people, and how we define roles as PM and engineer start to converge. We're treating this as an ongoing process that should keep evolving rather than settle into a new fixed version.

Writing code matters less every quarter, with reading code not far behind, and we should stop testing for it in interviews over time. What we'll look for instead is the ability to selectively review outputs and make major design decisions, systems thinking (both designing a large system and knowing the common components and how they fail), high agency, and the ability to hold the business problem and the technical solution in one head.

Experimenting with pricing

If we can produce larger outcomes with smaller pods, we need to price our services in a way that rewards us for that efficiency. We've never been a time-and-materials business, but now is the time to be more deliberate about evolving our pricing model. That includes explorations into milestone- and outcome-based pricing, and models that let us take equity stakes in our biggest transformations.

Getting everyone more AI-pilled

The whole company needs reminding, over and over, that it's everyone's job to keep us on the frontier. The frontier moves insanely quickly. The technology is evolving on an exponential, and it's hard for the human brain to reason about that and easy to become complacent. Often it won't be management but the people on the front lines of deployment who are best equipped to see when we're doing something outdated or when something new is possible. Our clients come to us because we're better than they are at staying on the bleeding edge, but no one is immune to drifting off it, even us. Everyone needs constant reminders of this, and it needs to be deeply instilled in the culture, especially now that we're getting large enough that change is getting harder.

‍