Skip to main content

← All writing

Intuition and the real cost of research

Intuition and the real cost of research

For most of my career, moving fast was a liability.

In many of the rooms I was in, the expectation was that you researched before you built. A colleague might spend three weeks studying a feature: stakeholder interviews, competitor analysis, a long document.

I would usually have already built something.

By the time the research finished, we often ended up in the same place anyway. The difference was that I had skipped the process everyone else considered necessary.

Over time I learned to adapt. Slow down publicly. Produce the artifacts. Earn alignment before moving.

Only now, many years into my career, does that instinct feel like an advantage rather than something I have to manage. I suspect AI is part of the reason.

What research is actually doing

Research isn’t the problem. It exists for a reason.

If you’ve never shipped something before, studying how others solved it helps. You’re building the mental model your intuition doesn’t yet have.

For a long time I underestimated this. I assumed people doing weeks of research were just being slow. Some were, but many were doing exactly what they needed to do: constructing the experience I already had from building similar things many times before.

The difference wasn’t diligence. It was starting point.

What AI changes is the cost of acting on that intuition.

When building something took weeks, making the wrong decision carried real consequences. Spending more time researching before committing made sense.

But if implementation is cheap, the balance shifts. The penalty for trying the wrong approach becomes much smaller, while the cost of analysis stays the same.

Intuition as compressed experience

People sometimes frame intuition as the lazy option. Skip the process, trust your gut.

To me intuition isn’t guesswork but accumulated experience: grit.

Over time, patterns repeat. Certain interface choices fail in predictable ways. Certain tradeoffs surface again and again. Eventually your brain learns to recognize them quickly.

When you see a problem and immediately sense the direction it should go, you’re not skipping thinking. You’re retrieving a decision from a long history of similar problems.

For most of my career, this wasn’t always easy to rely on socially. Moving too quickly could read as dismissing the process others needed to feel confident in the decision.

The trust problem

There is also a more practical issue.

Intuition is personal context compressed into a decision. The problem is that nobody else has that context.

The person who spent weeks researching can explain their reasoning in detail. They have documentation. They can walk a client through every step that led to the conclusion.

If your answer is simply “I’ve built enough of these to know,” that rarely satisfies a room that needs to justify the decision. Research, in those cases, is creating trust.

One thing that helps bridge this gap is building early. A working prototype gives people something concrete to react to. The conversation shifts from trusting a claim to examining something real.

But it doesn’t eliminate the need to explain the thinking behind it.

Conclusion

Research-heavy processes have always been a reasonable hedge against inexperience. For people still building their internal models, they serve an important purpose.

The difficulty is when the same approach becomes the default for everyone, regardless of experience or how quickly things can now be built.

For years I had to adapt my instincts to processes that weren’t designed for them.

Now those instincts feel like they finally exist in an environment where they make sense.

Intuition built through experience isn’t the opposite of process.

For the right person working on the right problem, it may have always been the process

On this page
Jul 24, 20268 min read

The biggest risk to AI is the enterprise org chart

This article argues that the real risk of corporate AI is not rogue superintelligence but how large organizations deploy it, usually in service of cost-cutting rather than creating new value. Big enterprises buy AI like office furniture, wrapped in committees, procurement, and risk matrices, so it ends up optimizing ticket deflection and headcount instead of enabling innovation. The real bottleneck is bureaucracy, not intelligence. In contrast, a roughly 500-person company has enough depth to build serious systems but short enough communication paths that the person with the problem can help build the solution. AI lets domain experts prototype directly, shortening the loop between friction and fix. The key is governance that enables safe experimentation instead of vetoing it, using AI to expand reach rather than just reduce costs.

  • 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