
We are an AI-run software agency. We use AI in our own engineering every day, we build AI into products, and we run our own AI agents to operate the company. So when we talk about AI for software development, we have skin in the game, and you should read this with that in mind.
Here is the honest version anyway, because the honest version is more useful than the hype or the doom.
AI has genuinely changed how we build software. Not in the "it does everything now" way the headlines suggest, and not in the "it is all a bubble" way the skeptics claim. The truth is more specific and more useful: AI is excellent at some parts of software development and quietly terrible at others, and knowing the difference is the whole game.
The short version: AI makes good engineers dramatically faster on the well-understood parts of the work, which is why a build that used to take us about four months now takes about one. It does not do the parts that decide whether software actually survives real users: architecture, the last stretch to production, security, and knowing what not to build. Those still need people.
What AI Is Genuinely Good At
Used by someone who knows what good looks like, AI is a real force multiplier. Where it earns its keep for us:
- First drafts, fast. Give it a clear, well-scoped task and it produces a working first version in minutes instead of hours. You still review and shape it, but you start from something instead of a blank file.
- The boring, necessary stuff. Boilerplate, wiring, config, repetitive refactors across a codebase. The work that is not hard, just slow. AI eats it.
- Tests. It is genuinely good at drafting tests, which is the exact thing tired engineers skip. More tests, written faster, is a real quality win.
- Understanding unfamiliar code. Point it at a codebase nobody remembers writing and it explains what is going on. That alone saves hours when you inherit or rescue a project.
- Research and options. "What are three ways to do X and the trade-offs" is something it does well as a starting point for a real decision.
Add these up and you get the four-months-to-one-month effect. That is not marketing. It is what happens when experienced engineers stop typing the easy 70% by hand and spend their time on the hard 30% instead.
Where AI Breaks
This is the part the demos never show, and it is the part that actually matters.
- Architecture and system design. AI writes the feature in front of it, not the system around it. It does not hold your whole product in its head, so left alone it produces code that works today and becomes a tangle you cannot build on in six months.
- The last 20% to production. Getting something to demo is easy now. Getting it to stay up under real traffic, handle the failure cases, and not fall over when a hundred people use it at once is exactly as hard as it always was. AI is weakest right where it counts most.
- Security. AI happily ships code with real, exploitable gaps, most often missing access controls that leave data exposed. It looks fine. It is not fine. You find out the expensive way if nobody who knows security reviewed it.
- Knowing what not to build. AI will enthusiastically build whatever you ask for, including the wrong thing. It has no opinion about whether a feature is worth building. That judgment is still entirely on you (or the team you hire).
- Confident wrongness. The failure mode that catches people out: AI is often wrong in the exact same confident tone it uses when it is right. If you cannot tell the difference, you cannot safely use it for anything that matters.
The pattern across all of these is the same. AI is brilliant at the parts of software development that are well understood and bounded, and unreliable at the parts that need judgment, context, and responsibility.
So What Does This Actually Mean?
Two things, and they point in the same direction.
AI amplifies good engineers. It does not replace them. A strong engineer with AI is dramatically faster than they were a year ago. A non-engineer with AI can get surprisingly far, then hits a wall exactly where the judgment starts to matter. The value is not in the tool. It is in the person driving it who knows when the tool is wrong.
The advantage goes to whoever can do both. The people winning right now are the ones who know how to code and know how to drive AI. They get the speed of AI without inheriting the mess it leaves when nobody is checking. That combination is the actual skill of this era, and it is what you are really buying when you hire a team that has genuinely adopted AI rather than just talked about it.
How We Use AI (the Proof)
We do not just use AI on client work. We run our own company on it, which is the only reason we can speak to any of this honestly.
We build AI into our own SaaS, Formester: an AI form builder, agentic workflows that take real actions after a submission, and a retrieval system grounded in real data. We run our own internal agents, including a finance agent that creates invoices and runs the numbers, a bug-fixing agent, and a code-review agent. And we deliver AI for clients, not just for ourselves.
That day-to-day, in-production experience is what taught us where the line is between what AI can do and what it cannot. We learned it by shipping, not by reading about it.
The Honest Takeaway
AI for software development is neither magic nor a threat. It is a genuinely powerful tool that made building faster and left the hard parts exactly as hard. If you use it to skip the judgment, it will hurt you. If you use it to move faster on the work that does not need judgment, it is transformative.
If you want AI built into your product properly, or you want a team that uses AI the way we do (for speed, with the judgment to catch it when it is wrong), that is what our AI development work is. And if you are still deciding whether to build it yourself with AI or bring in help, we wrote an honest guide to exactly that: build it yourself with AI, or hire a developer.
Frequently Asked Questions
Will AI replace software developers?
Not for real production work. AI replaces a lot of the typing and the first-draft grunt work, which makes good engineers much faster. It does not replace the judgment that decides what to build, how to structure it so it lasts, and how to keep it secure and running. AI amplifies a strong engineer; it does not stand in for one.
What is AI actually good at in software development?
Speed on the well-understood parts: boilerplate, first drafts of a feature, writing tests, routine refactors, explaining unfamiliar code, and research. Used well by someone who knows what good looks like, it compresses work that used to take months into weeks. We have taken builds from roughly four months to about one this way.
Where does AI fail in software development?
The parts that decide whether software survives real users: system architecture, the last 20% to production, security, and knowing what not to build. AI writes the feature in front of it, not the system around it, and it is confidently wrong often enough that unchecked AI code breaks in ways you find out about from your users.
Should I use AI to build my software myself, or hire a team?
If you are still testing an idea or building something small, use AI yourself. If real users and money depend on it, you need people who can code and drive AI. We wrote a full honest guide to that decision: build it yourself with AI, or hire a developer.
Related reading: AI Development Services, Where AI-Built Apps Actually Break, and Build It Yourself With AI or Hire a Developer?.
Get practical engineering insights
Real lessons from building products - ours and our clients'. No spam. Monthly.
Have a project in mind?
We'd love to hear what you're building. Let's talk about how we can help.
Let's Talk
