Skip to main content

← All writing

The Doer Economy - we are killing the translator class

The Doer Economy - we are killing the translator class

If you look at how software was built over the last ten years, the most striking feature is the sheer number of people in the room who didn’t actually build the software.

We created a massive, highly paid layer of translators. We hired product managers to translate business requirements into Jira tickets. We hired marketers to translate product features into campaigns. We hired engineering managers to translate architecture into manageable two-week sprints.

We did this for a good reason. Systems were incredibly brittle, the tooling was heavy, and the cost of making a mistake in production was high. The space between having an idea and shipping it required a crowded room of people to manage the complexity.

I’ve seen that room emptying out recently.

I predict that next year we are fully entering the “Doer Economy”. AI has fundamentally collapsed the distance between a vision and its execution. When the cost of writing code, drafting copy, and generating boilerplate drops to near zero, the value of pure execution drops right alongside it.

If your primary professional skill is completing a highly specific task that someone else defined for you, you are now competing with a machine that does it instantly.

The people who win this next era will be the ones who can hold a vision in their head and execute it themselves.

We are already seeing this shift at the top. CEOs and founders are moving much closer to the product. Previously, a founder would eventually have to step away from the code to manage the people managing the people writing the code. They needed a deep hierarchy to test a single hypothesis. Today, a founder with technical context can sketch the architecture, have an AI generate the scaffold, and validate the idea directly in an afternoon. The companies that survive the next few years will have fewer people doing significantly more work, simply because the organizational drag of coordination has vanished.

This shift completely changes the software we buy, too.

SaaS companies are realizing that their core value is no longer a massive, complicated dashboard that requires a certification to use. Smart SaaS providers are shifting their focus away from the UI and toward developer primitives. They are shipping robust SDKs, incredibly clean APIs, and documentation specifically written to be digested by language models.

When you are building in the Doer Economy, you do not want to spend three weeks configuring a backend. You want to point your local AI agent at a service like Vercel, Supabase, or Contentstack, have it read the API documentation, generate the boilerplate, and hand you a fully connected system before your coffee gets cold.

The SaaS platform handles the plumbing. The AI handles the syntax. You focus entirely on the business logic and the user experience. You get to build the actual product.

This is a brutal paradigm shift for anyone entering the industry right now, and the standard advice they receive is terribly outdated.

For years, the playbook was to learn a narrow technical skill, keep your head down, and slot yourself into a large corporate machine. You learned how to take a ticket, write a React component, and pass it to QA.

That machine is shrinking. The new baseline expectation is shipping. You need to learn how to do more with vision, rather than executing isolated tasks without questioning the whole product. The code itself is no longer the hard part. Figuring out what the user actually wants, how the system holds together, and why the product matters, that is where the value lives now.

If you are starting out, stop waiting for a perfect roadmap. Stop waiting for a Jira ticket to give you permission to build. Start shipping what is in your head, throw it away when it breaks, and build it again until you hit something useful for someone else.

The future belongs to the people who can build it. The people who only know how to manage the builders are going to struggle.

Sep 4, 20267 min read

Building MCP Profile Hub part 2, one MCP server is the wrong abstraction

This article argues that a single, monolithic MCP server per platform is the wrong abstraction, especially for complex systems like Contentstack. Instead, it introduces managed profiles as the right unit of configuration, aligned to jobs, teams, or access boundaries rather than product catalogs. Each managed profile bundles a curated set of tools, Automations, and agents, enriched with account context, while still respecting individual user identities and permissions. Profiles can only narrow what a user can do, never expand their underlying platform permissions. This makes configurations easier to reason about, review, audit, and replicate across environments, and offers a scalable pattern for enterprise platforms with many roles and capabilities.

  • Composable architecture
  • AI engineering
  • API design
Aug 31, 20269 min read

Building MCP Profile Hub, part 1: Stop making the agent ask

Introducing MCP Profile Hub. I explain why enriching tool definitions with tenant-specific context dramatically improves agent performance. Instead of exposing generic CMS tools that force models to discover content types, environments, locales, and branches through multiple lookup calls, Profile Hub injects real account data directly into JSON Schemas as enums, defaults, and descriptions. This reduces tool calls, latency, and reasoning tokens while avoiding misleading examples and invalid defaults. The piece also covers the production engineering behind enrichment, how Automations and Agent OS agents are exposed as high-level deterministic tools, and why reusable HTTP-based tool definitions let teams run their own MCP runtimes. The core takeaway is that fewer, richer, context-aware tools beat large generic catalogs for real-world agent workflows.

  • Composable architecture
  • AI engineering
  • API design