A few years ago, if someone had asked me who I was building software for, my answer would have been straightforward. I build software for users. If the product exposed an API or SDK, then I also built it for developers. That was the relationship we had with software for decades. Users interacted with interfaces, developers integrated systems, and engineering teams focused on making both experiences as seamless as possible.
Today, I don't think that answer is complete anymore.
Over the past year, I've noticed something quietly changing across the software industry. More and more products are no longer being used exclusively by people. Increasingly, they're being consumed by AI. Sometimes it's an AI coding assistant reading your documentation before another engineer opens it. Sometimes it's an autonomous workflow deciding whether your API is reliable enough to integrate. Other times it's a browser agent navigating your application to complete repetitive business tasks without anyone clicking through the interface manually.
It's an interesting shift because it introduces a new audience that most of us never consciously designed for. We spent years refining User Experience (UX) to help people accomplish tasks more easily, and we invested heavily in Developer Experience (DX) so engineers could build integrations with minimal friction. Now there is a third audience entering the conversation, and unlike the other two, it doesn't care how beautiful your interface looks or how polished your landing page feels. It only cares whether your software is understandable, predictable, and trustworthy.
That's why I believe we'll hear a lot more about Agent Experience (AX) over the next few years.
Software Has Quietly Gained a New User
When we talk about AI, most discussions revolve around models becoming larger, smarter, or faster. We compare benchmark scores, reasoning capabilities, context windows, and coding performance. Those conversations are important, but they often overlook something happening underneath.
AI is gradually becoming another consumer of software.
Think about how many development workflows already involve AI today. GitHub Copilot suggests implementations by reading the surrounding codebase. Claude Code explores repositories to understand project architecture before making changes. Cursor indexes documentation and source code so it can answer implementation questions. Autonomous agents built with frameworks like LangGraph or Model Context Protocol (MCP) inspect APIs, execute tools, and make decisions without direct human involvement.
In each of those situations, your software is no longer communicating only with people.
It's communicating with another piece of software that happens to reason using language.
That changes the way we should think about designing modern systems.
AI Doesn't Experience Software the Way Humans Do
One of the easiest mistakes to make is assuming AI evaluates software the same way people do.
Humans naturally appreciate thoughtful interfaces. We notice typography, spacing, animations, colors, branding, and visual consistency. Developers tend to evaluate products differently. They look for good documentation, clear authentication flows, helpful SDKs, and examples that make integration straightforward.
AI evaluates software through an entirely different lens.
It doesn't care whether your homepage has impressive animations. It doesn't care whether your buttons follow the latest design trends. It isn't impressed by gradients or polished illustrations.
Instead, it asks questions that sound much more like this:
- Can I discover every available endpoint?
- Are response objects consistent?
- Is authentication clearly documented?
- Can I understand this error automatically?
- Is this operation deterministic?
- Can I safely retry this request?
Those questions aren't about aesthetics.
They're about certainty.
The easier your software is to understand programmatically, the more valuable it becomes to AI systems that need to reason about it.
Predictability Is Becoming More Valuable Than Cleverness
Over the years I've reviewed many APIs that technically worked but felt unnecessarily difficult to understand. Often the problem wasn't performance or functionality. It was inconsistency.
Consider two different approaches.
The first API might expose endpoints like:
/getUser/allUsers/createUser/deleteUser
Nothing is fundamentally broken.
Now compare that with an API following predictable REST conventions:
GET /usersGET /users/{id}POST /usersPUT /users/{id}DELETE /users/{id}
Both APIs solve the same problem.
The difference is that the second communicates intent much more clearly.
Humans appreciate consistency because it reduces cognitive load. AI depends on consistency because patterns are how it generalizes behavior. Once an agent understands one endpoint, it can often infer how the rest of the API behaves without additional explanation.
Predictability becomes a feature in its own right.
Documentation Is No Longer Just for Humans
Documentation has traditionally been something teams finished after shipping the product. Sometimes it was treated almost like a formality.
I don't think that's true anymore.
Documentation is increasingly becoming part of the interface itself.
When an AI assistant generates integration code, it doesn't magically know how your platform works. It reads your documentation, examines schemas, studies examples, and builds an internal understanding of your system before writing a single line of code.
Every missing example creates uncertainty.
Every undocumented endpoint increases ambiguity.
Every inconsistent explanation makes automated reasoning more difficult.
That's one reason standards like OpenAPI, JSON Schema, AsyncAPI, and MCP are becoming increasingly important. They don't simply document software for people. They describe software in a structured way that machines can understand as well.
The better those descriptions become, the less time both developers and AI spend making assumptions.
Error Messages Are Becoming Part of the Conversation
One area I think many teams still underestimate is error handling.
For humans, an error message is often just feedback explaining what went wrong.
For AI, an error message is an opportunity to recover automatically.
There's a significant difference between returning:
"Invalid request."
and returning structured information explaining which field failed, why it failed, and what correction should be made.
That additional context transforms an error from a dead end into another decision point.
Instead of giving up, an AI agent can retry with corrected input, ask for clarification, or choose a different execution path entirely.
Good error messages no longer improve only the developer experience.
They improve the agent experience too.
Building Software That Machines Can Trust
The more I think about Agent Experience, the more I realize it isn't introducing completely new engineering principles.
Instead, it's reinforcing principles we've known for years.
Predictable APIs.
Consistent naming conventions.
Clear authentication.
Stable versioning.
Structured documentation.
Meaningful error responses.
Deterministic behavior.
Explicit business rules.
These practices have always resulted in better software.
The difference now is that AI exposes weaknesses much faster than people do. Humans often work around inconsistencies through intuition or experience. Machines can't. They rely on clear contracts, structured information, and repeatable behavior.
Ironically, designing software that AI understands often results in software that humans appreciate even more.
Why I Think This Matters More Than the Next AI Model
Many organizations are currently focused on choosing the best AI model.
Should they use GPT?
Claude?
Gemini?
Open-source alternatives?
Those decisions certainly matter.
But I suspect they'll become less important over time.
The larger competitive advantage won't come from having access to a particular model.
It will come from how well your engineering organization teaches that model to understand your systems.
Companies with predictable architectures, excellent documentation, structured APIs, and well-defined engineering standards will allow AI to become productive almost immediately.
Companies with fragmented documentation, inconsistent conventions, and undocumented business logic will continue forcing every AI assistant to rediscover the same information over and over again.
Eventually the model won't be the bottleneck.
The quality of the software ecosystem surrounding it will.
Final Thoughts
For decades, software engineering has focused on building products that people enjoy using and developers enjoy building on.
That foundation isn't changing.
What is changing is the audience.
Software increasingly communicates with other software that can reason, plan, automate, and make decisions on behalf of people. As that trend continues, products won't simply compete based on features or interface design. They'll also compete on how easily intelligent systems can understand, trust, and integrate them into larger workflows.
Perhaps that's the most interesting part of this shift.
Agent Experience isn't replacing User Experience or Developer Experience.
It's becoming the bridge between them.
The companies that recognize this early won't just build products that people love using.
They'll build products that AI understands naturally, integrates confidently, and chooses automatically.
I have a feeling that will become one of the defining characteristics of great software over the next decade.
Thanks for Reading
If you enjoy reading about software engineering, system architecture, AI engineering, backend development, cloud computing, and building scalable digital products, you're in the right place. I regularly share practical lessons, engineering insights, and reflections from projects I've worked on, along with ideas that I believe will shape the future of modern software development.
Beyond writing, I work with founders, startups, businesses, researchers, and organizations to design and build scalable software solutions. Whether it's developing AI-powered applications, architecting cloud infrastructure, modernizing legacy platforms, building custom business systems, or turning a product idea into production-ready software, I genuinely enjoy solving complex engineering problems.
I'm also happy to support educational initiatives, open-source communities, research collaborations, and non-profit projects whenever I can. If you're building something meaningful and think I can help, feel free to reach out. I'd always enjoy connecting with people who are passionate about building technology that creates real impact.
Top comments (0)