18 years building developer tools taught me this: AI is forcing us to rethink everything about when and what to build.
Teams see a workflow problem and immediately think: “Let’s build a tool.” That instinct is costing you months of engineering time.
The Hidden Cost of Tool-First Thinking
Picture this: Your team just spent 3 months building a custom deployment dashboard. Meanwhile, your competitors wrote deployment context in markdown and let agents handle the analysis.
Guess who ships faster now?
The problem isn’t that tools are bad—it’s that we default to building them when a simpler solution would work better in an AI-first world.
What Winning Teams Do Differently
I’ve been building agent infrastructure at enterprise scale, and the shift I’m seeing is profound. Engineers stuck in “tool mode” are getting lapped by engineers in “context mode.”
Here’s what the transition looks like:
Instead of building log parsers → Create rich log schemas that agents can query dynamically
Instead of API connectors → Document APIs with failure modes (MCP is becoming the de-facto standard here)
Instead of custom dashboards → Structure data that agents can visualize on-demand
The Best “Tool” I Built This Year
Plot twist: It was a README file.
No UI. No deployment pipeline. No maintenance burden. Just well-structured context that agents can consume and act on.
The Uncomfortable Truth
Building tools feels productive. Writing documentation feels like busywork. But agents don’t need your UI—they need your context.
This creates a psychological challenge. Every developer instinct we’ve built over the past two decades says “build a tool.” Fighting that instinct goes against muscle memory.
The Real Shift
This isn’t theoretical. It’s happening right now:
- Teams that embrace context-first thinking are shipping faster
- Engineers who understand agent capabilities are making better architecture decisions
- Organizations that invest in structured data over custom UIs are seeing better ROI
The engineers that figure this out first are already pulling ahead.
Important Caveats
This doesn’t mean “never build tools.” Complex interactive workflows still need custom solutions. Real-time collaboration still needs dedicated interfaces. Security-critical operations still need purpose-built tooling.
But most teams are building tools by default, not by necessity.
A Framework for Deciding
Before you start building, ask:
- Can an agent consume the underlying data directly? If yes, you might not need the tool.
- Is this truly interactive, or could it be query-driven? Agents excel at query-driven workflows.
- What’s the maintenance burden vs. the value? Tools accumulate technical debt; good documentation doesn’t.
- Are we building this because we need it, or because we always have? Question your defaults.
The Challenge
What’s the last tool you built that could have been a really good markdown file instead?
Most engineers won’t naturally make this shift because it contradicts everything we’ve learned. The teams that do will have a measurable advantage.
The question isn’t whether this shift will happen—it’s whether you’ll be ahead of it or behind it.
This post expands on a LinkedIn article that resonated with thousands of engineers. The patterns I’m describing are real and happening at scale—but they require a fundamental rethinking of how we approach software development.