Skip to main content

← All writing

The biggest risk to AI is the enterprise org chart

The biggest risk to AI is the enterprise org chart

I speak to folks in big companies quite a lot, friends, ex-colleagues, community members, etc. This made me aware that the biggest risk surrounding AI might actually come from the companies deploying it. At some point, the enormous bill for models, data centers, consultants, and whatever an “AI transformation office” does all day will arrive. Someone will have to justify the spend, and the easiest story to tell is cost reduction.

You can put headcount savings in a spreadsheet, show the board that a process now needs six people instead of nine, and draw a downward line labeled efficiency. Building new products is hard. Exploring new markets is awkward. An opportunity nobody has seen before tends to perform badly in a quarterly forecast. So, cost reduction it is.

This is why employees resisting corporate AI programs are not irrational. They have worked inside the system long enough to know what “transformation” usually means. The company talks about augmentation for six months, and then finance discovers subtraction: people get laid-off.

Large companies buy AI like office furniture

A massive company rarely starts with the problem; it starts with the program.

There is an AI strategy, a steering committee, an approved vendor list, a risk matrix, and a slide explaining which model employees are allowed to use for lunch recommendations. Procurement negotiates a giant contract, security disables half the useful features, and legal writes a policy nobody understands. By the time everyone is comfortable, the selected model has been replaced six times.

This is not because the people involved are stupid. Most of them are behaving rationally inside their given incentives. Security is punished for leaks. Legal is punished for liabilities. Procurement is praised for discounts. Nobody gets fired because the company failed to invent a product they didn’t know was possible, that missed opportunity never appears on an incident report.

Consequently, large organizations drag AI toward the things they already know how to measure: ticket deflection, reduced handling time, and more output from the same budget. Automating tedious work is highly useful, but the problem starts when cost reduction becomes the absolute limit of the company’s imagination.

AI cannot outrun bureaucracy

People talk about AI as if intelligence is the bottleneck inside large companies. I think it rarely is.

The enterprise already has smart people who know the customers, the broken processes, and the weird internal exception from 2017 that means the obvious solution will set something on fire. The actual bottleneck is getting anything across the organization. A useful idea moves from the person who understands the problem, to a manager, into a planning document, through a prioritization meeting, and finally into a department whose roadmap was locked last quarter. Every handoff strips away context until the team building the solution knows the least about why it was needed.

AI can make each individual step faster, but it cannot fix a system where the steps should never have existed. Give a coding agent to an engineer waiting three weeks for architecture approval to deploy on a modern stack, and they simply become extremely productive at waiting.

Five hundred people is an AI advantage

This is why smaller companies get a wildly disproportionate benefit from AI. The models and licenses cost the same, but the difference is how quickly an idea can collide with reality.

I think ~500 people might be the perfect size for this exact moment.

Five hundred people feels like a massive enterprise when you are trying to track down the owner of a random internal system, yet it feels tiny compared to the organizations I tend to sell to at work. 500 people companies have proper engineering teams, product managers, designers, support, security, legal, and specialists who understand remarkably narrow parts of the business. They have the depth to build serious things.

But they remain small enough that the person experiencing a problem can usually find the person capable of fixing it. That matters more than access to the newest model.

Back in the day, when I was building the (at the time) largest Sitecore + Vue implementation in the world for L’Oréal, the distance between understanding a problem and shipping the solution required multiple entire teams and a brutal development cycle. Today, the most useful thing AI changes is that distance. A person who knows where the friction lives can now build a prototype, automate part of the workflow, or create a tool without waiting for a six-month planning cycle.

The first version might be wrong. Good. Someone can use it, complain about it, and make it less wrong. That tight loop is where the acceleration happens, and at 500 people, the loop is still short.

The person with the problem can now build

For most of software history, knowing what needed to exist and being able to create it were separate jobs. A support engineer might understand exactly why customers get stuck, but they needed engineering capacity to test a fix.

AI is blurring that line. The person closest to the work can produce more of the solution themselves. They can create the first interface, query the data, or build enough of the automation to make the conversation concrete. This does not make every employee a senior software architect, but it does stop every idea from entering the company through a Jira ticket.

At the 500 size, this is an enormous advantage. A developer can understand more of the product surface, and a product manager can test an interaction instead of describing it in fifty acceptance criteria. The company moves faster because fewer thoughts die while waiting to become somebody else’s priority.

The middle-sized company advantage

The AI discussion keeps drifting toward model quality and compute budgets. Those matter, but most companies are applying models, not training them. For them, organizational shape matters more than model choice.

A 500-person company has the surface area to find thousands of valuable use cases and the technical skill to build real systems around them, without requiring an expedition team to move information across the business. That window will not stay open forever. As companies grow, they add process because process solves problems. Eventually, changing the process requires a process.

We should treat the 500 employee size as a weapon. AI gives these companies the leverage to build products, internal systems, and entirely new categories of work that previously required massive teams. Using that leverage solely to reduce costs would be an astonishing waste.

The real win is operating a 500-person company with the reach of a much larger one, minus all the meeting invites.

Can you guest how many people work at Contentstack?

On this page
Mar 10, 20266 min read

Intuition and the real cost of research

This article explores how AI changes the balance between research-heavy processes and intuition-driven building, especially in product and technical work. The author reflects on a career of moving faster than surrounding teams, where strong intuition (really compressed experience from shipping many similar things) often clashed with expectations for lengthy research and documentation. As AI makes implementation and iteration dramatically cheaper and faster, the true bottleneck shifts from building to deciding what is worth building. Research still matters for those without established mental models, and for environments where stakeholders need evidence and paper trails. But when iteration costs hours instead of weeks, over-indexing on analysis can become the real drag. The piece argues that, in an AI-enabled world, experienced intuition is not anti-process; for the right people and problems, it is the process.

  • Composable architecture
  • AI engineering
  • Frontend
Feb 11, 20267 min read

TDD finally makes sense

AI coding tools have removed the old excuse that test driven development is too slow or too costly. When AI can generate both implementation and test scaffolding in minutes, the time cost of writing tests first collapses, turning TDD into an obvious quality and productivity win. The real risk now is vibe coding, where developers ship AI generated code that looks fine but crumbles under real edge cases. By using AI for planning, then encoding that thinking as tests and letting the AI implement against them, teams get faster feedback, more reliable code, and fewer hotfixes. In an AI assisted world, the competitive advantage shifts to defining behavior and edge cases up front, and TDD becomes the discipline that makes that thinking explicit.

  • Composable architecture
  • AI engineering
  • Frontend
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