Every day there’s a new framework, a new agent architecture, a new paradigm, or a new post announcing that everything just changed. I read them too. But the more time I spend actually building with AI across different industries, the more I find myself caring less about what’s new and more about what actually works.
Some of the biggest lessons have been surprisingly simple. The best AI systems are often the least complicated. Not every problem needs AI. Coding agents are changing the economics of software development much faster than I expected. And getting people to actually use these tools can sometimes be harder than building them.
These aren’t predictions about where AI will be five years from now. They’re just a few things I’m learning from actually building with it.
Less is more
There is a lot of pressure right now to solve everything with AI. A process is slow, so let’s build an agent. A report is difficult to find, so let’s add a chatbot. Someone discovers a new agent framework, and suddenly we’re redesigning an architecture around it. The conversation starts with the technology instead of the problem.
I think that’s where a lot of the ROI from AI disappears. Not because AI doesn’t work, but because we’re building systems that are more complicated than the business problem requires. You can build an incredibly sophisticated AI system to automate something that takes an employee two hours per month. Technically impressive, but economically pointless. Every additional layer is also something you have to build, test, maintain, monitor, and pay for.
Sometimes the best solution isn’t AI at all. It might be a scheduled job, a better report, a cleaner data pipeline, or a traditional piece of software. The more projects I work on, the more I think good AI engineering is partially about knowing when not to use AI.
The starting point should still be the same one we used before AI: What is the business problem? What is solving it worth? What is the simplest technology that can solve it reliably? The business case should decide the architecture, not the other way around.
Where the leverage is very real
On the other hand, there are areas where the productivity gains are difficult to ignore, and software development is probably the biggest one I’ve experienced personally.
I’ve recently worked on two completely different client projects where we built new platforms essentially from scratch while heavily using coding agents throughout development. One team primarily used Claude Code and the other primarily used Cursor. These weren’t demos or weekend prototypes. They became real systems used in production.
A few years ago, before coding agents became part of the development process, projects of similar scope could easily have taken a year or more to build. These were being used in production in roughly a quarter of that time. That still blows my mind a little bit, and I think we’re only starting to understand what that does to the economics of building software.
But there is an important distinction. The speed didn’t come from giving an agent a prompt and letting it run wild. There were still experienced engineers making architecture decisions, understanding the business requirements, reviewing the output, debugging problems, and deciding what should actually get shipped. The coding agent multiplies judgment. It doesn’t replace it.
That distinction becomes increasingly important as these tools get better. The barrier to producing code is collapsing, but producing code was never the entire job. Knowing what should be built, how the pieces should fit together, and whether what was produced is actually good still matters.
Infrastructure is changing too
The same shift is happening with infrastructure. Writing application code faster is great, but if every application creates its own infrastructure patterns, security decisions, naming conventions, and deployment processes, eventually you have a different problem: you built faster, but you also created chaos faster.
I’ve been using Infracodebase, which was built by some of my former colleagues, and what I value most is that it keeps everything in order. We already know AI can generate infrastructure code. What made the difference for me is that the infrastructure comes out consistent with the standards we care about, and the output gets checked before anything reaches production.
That last part matters more than it sounds. When humans and agents are producing more of the work, the question stops being how fast you can generate code and becomes whether you can trust what was generated. After eight years in banking, I know how much that question matters in a regulated environment. Speed matters, but keeping everything under control while moving at that speed might matter even more.
Just because you can build your own software doesn’t mean you should
This is another lesson I think a lot of businesses are going to learn over the next few years. Building your own CRM, SaaS platform, internal application, or workflow tool has become dramatically easier. I’ve done it for my own business, I’ve done it for clients, and there are situations where it makes complete sense.
But there’s an important caveat, especially for small businesses: if you or someone on your team isn’t technical, keep paying your subscription.
Building version one is becoming the easy part. Owning software is different. Someone still has to understand the architecture, fix bugs, maintain integrations when APIs change, manage deployments, think about security and data, and build the feature somebody is inevitably going to ask for six months from now.
If nobody inside the business can do those things, eventually you’re going to hire someone like me to maintain the software you built because you didn’t want to pay for the software you were already using. And you may end up spending considerably more.
AI has dramatically lowered the cost of building software. It hasn’t eliminated the cost of owning software. Sometimes that $100-a-month SaaS subscription is an incredible deal.
Adoption might be more important than the technology
One of the more humbling lessons for me came from building an AI system that worked pretty well. The problem was that pretty well wasn’t good enough.
The system would occasionally give users the wrong answer. Not constantly, but enough. Eventually people stopped trusting it and went back to the way they had been doing the work before. It was a good reminder that the technical definition of a successful system and the user’s definition can be very different.
At first, it’s easy to look at something like that purely as a technology problem. Make the model better. Improve the prompts. Add better retrieval. Improve the evaluation. Obviously all of those things matter, but there was another problem: the users expected the system to behave like traditional software.
Traditional software has trained us to expect deterministic behavior. You click the button and the same thing happens every time. AI systems don’t always work that way. They can be incredibly useful and still occasionally be wrong. If people don’t understand that distinction, a few bad experiences can destroy trust in an otherwise useful system.
That experience changed the way I think about AI adoption. You can build a great system and still fail if you don’t teach people how to use it, what to expect from it, and where they should still apply their own judgment.
That’s why I’m increasingly interested in enablement
Over the last year I’ve started doing more AI workshops with executives, business owners, and small teams. Some of the sessions start very simply: What is an LLM? What is actually happening when you send a prompt? What are these systems good at? Where do they fail? What information should you give them, and what information probably shouldn’t you give them?
Then we get hands-on, and that’s usually when things click. There is a big difference between showing an executive an AI demo and having them sit down and use the technology against a problem they actually deal with every week. You can almost see the questions change. They stop asking, “What can AI do?” and start asking, “Could I use this for this process?”
That’s a much more interesting conversation. It’s also why I think enablement is one of the biggest opportunities in the industry right now. There is still an enormous gap between the people living inside the AI bubble and everyone else, including people running very successful businesses. Giving them another AI product isn’t necessarily what closes that gap. Sometimes it’s simply helping them understand the tools they already have.
AI titles are probably overrated
We’re also seeing AI Product Managers, AI Software Engineers, AI Architects, AI this, AI that. I’m increasingly skeptical that most of those distinctions will matter long term.
There are obviously specialized roles where they do. An applied AI engineer actually building and shipping AI systems requires a particular set of skills. But for most technology roles, I think AI simply becomes part of the job. A software engineer should know how to use AI. A data engineer should know how to use AI. A product manager should know how to use AI. A designer should know how to use AI.
We all have different strengths and specialties, but increasingly the expectation should be that you know how to use the tools available to solve the problem in front of you. Eventually, I think we’ll stop feeling the need to put “AI” in front of everything.
AI eventually becomes electricity
I keep coming back to the electricity analogy. Most of us use electricity hundreds of times every day, yet most of us couldn’t explain in much detail what is happening inside the electrical grid when we turn on the lights in our house. And we don’t need to. It works.
We don’t describe companies as “electricity-enabled businesses,” and we don’t put “electricity-powered” in our job titles. Electricity became infrastructure. I think something similar eventually happens with AI.
It gets embedded into our development environments, CRMs, spreadsheets, infrastructure, customer service platforms, operating systems, and everything else we use to run businesses. Most people won’t need to understand transformers, inference, embeddings, context windows, or whatever architecture comes next. They’ll just use it.
Although personally, understanding how these systems work has made me a little more paranoid about them too. I’ve been experimenting with personal AI assistants like Instinct and Muse, and I think the category is awesome. The idea of having an assistant that understands your information, schedule, work, and preferences starts getting surprisingly close to the personal assistant we’ve imagined for years.
But mine gets read access. Access to my money? Absolutely not. Maybe being this embedded in the technology means I know too much.
The fun part
For all the noise around AI, this has been an incredibly fun time to be building technology. I get to work with different businesses, in different industries, with completely different problems, while the tools available to solve those problems seem to change every few months.
Some things that felt expensive or impractical two years ago are suddenly possible. Some things that sound incredibly impressive today are completely unnecessary. And some of the biggest opportunities have nothing to do with building another AI agent. They come from helping people understand the technology they already have access to.
The more time I spend actually building with AI, the less interested I am in using AI everywhere. I’m much more interested in using it where it creates real leverage.
Sometimes that means building an agent. Sometimes it means using a coding agent to build a platform four times faster. Sometimes it means teaching a team how to use Claude.
That might be the biggest lesson I’ve learned so far. The technology is incredibly powerful, but the real skill is knowing how much of it you actually need.