Developers either over-rely on AI (abdication) or refuse to use it at all (avoidance). Both hurt the work. The middle path (assistive AI) uses these tools to handle mechanical tasks while humans keep ownership of decisions that require judgment.
We've built this approach into how we work, and we teach other teams to do the same. If your team is struggling to find the right balance, or you're not sure how to evaluate partners who claim AI makes them faster, we can help.
Book a call and let's figure out what makes sense for your situation.
As business leaders are trying to figure out how AI should factor into software projects, they find the noise makes it nearly impossible to think clearly. Talk to tech folks about AI and odds are you'll get one of two reactions: breathless enthusiasm (AI will write all our code, 10x productivity is just a prompt away) or principled rejection (AI produces garbage, real developers don't need it, the whole thing is a hype bubble).
Both reactions are understandable, but both miss the mark.
We get it.
After spending the past year integrating AI tools into our development workflows and teaching our clients how to do the same, we've identified two failure modes we see most often. Understanding them is the first step toward something more productive.
Failure Mode 1:Abdication
The hype around AI makes it scarily easy to abdicate responsibility by prioritizing speed over understanding.
Abdication looks like this: you generate prodigious amounts of code, code that technically works for the happy path, call it "productivity", and move on. You feel great and ship features faster than ever before. You let the AI make architectural decisions because it's fast and an "expert".
You might not even be intentionally making those choices, but then the other shoe drops when reality takes your system down “non-happy” paths.
The truth is that you've likely created a codebase nobody understands, carrying technical debt that compounds invisibly, with edge cases that explode in production because nobody thought them through. Not the AI. Not the developer.
Luckily, we haven't inherited one of these codebases yet, but we're bracing for it. The signs are already visible in code samples and open source projects. Signs such as patterns varying file to file because each was generated in isolation. Or the error handling covers just the obvious cases while it's missing the subtle ones. The code feels assembled rather than designed.
That's not to say the developer using these tools is necessarily lazy or careless. More often, they're responding to pressure. Pressure to ship faster! Do more with less! Keep up with competitors (who claim AI has made them 10x more productive)!
That shortcut becomes a trap. The code ships, but it doesn't last. Shortcuts have a cost. Eventually, someone has to untangle it, usually at much greater expense than if it had been built thoughtfully.
Abdication is corrosive to the craft. It produces software that functions, but doesn't serve the humans who depend on it.
Failure Mode 2: Avoidance
The opposite mistake is just as limiting.
Avoidance looks like this: refusing to engage with AI tools on principle. Those who find the hype is so off-putting, and the examples of AI generated garbage so abundant, that they dismiss the whole toolset. They lean on close-minded, old aphorisms: "Real developers don't need these crutches." "The craft matters." "We'll do it the way we've always done it."
Honestly, we get this view, too. The instinct is understandable. The hype really is overblown. Charlatans are everywhere. And the craft really does matter. But avoidance means missing genuine amplification that a well crafted tool can provide a skilled practitioner.
It isn't the fictional 10x productivity that marketing departments promise. It is, however, a real reduction of mechanical friction. Used well, and harnessed, these tools free developers to focus on work that actually requires human judgment.
Every developer has tasks that are necessary but not particularly interesting. Looking up syntax for the third time today. Transcribing a well understood solution into code. Updating documentation that's clear in your head but tedious to write down. That work comes with the territory, but it isn't where the real value is created. Offloading the mundane should be something we all aspire to do, letting us use our skills to add value instead of executing rote tasks.
Architecture matters. Problem solving matters. Deciding what to build and why is where experience earns its keep.
When developers avoid AI tools entirely, they still spend that energy. They aren't worse developers for it, but they are forgoing leverage that could free attention for more meaningful work.
Leveraging Assistive AI
Between abdication and avoidance is an approach we've come to call assistive AI.
Assistive AI uses tools to remove mechanical friction while keeping judgment firmly in human hands. Developers still do the thinking and make the decisions while the tools handle transcription, coordination, and routine synthesis.
Here's what that has looked like in practice for us.
When one of our developers needs to keep project documentation synchronized with code changes, they don't spend hours crawling through git logs trying to remember what changed. They use a specialized Claude Code sub agent we built called Diderot, named after the philosopher who edited the original Encyclopédie. Diderot analyzes what's changed and updates the documentation to match. With this assist from AI, what used to take two to three hours of archaeology now takes about fifteen minutes of review.
Diderot doesn't decide what's worth documenting or how information should be structured for users. Those are human calls that require experience and taste. He handles synchronization, so developers can focus on decisions that actually benefit from their expertise.
We use a similar approach for design systems. Another sub agent, Ray, named after designer Ray Eames, helps organize scattered CSS into systematic design tokens. Ray doesn't create brand identities or make strategic design decisions. Instead, she turns chaos into order so that when a designer joins the project, they're working with a clear system rather than hundreds of magic numbers.
Across these examples, the division of labor stays consistent. The AI handles the mechanical work. Humans retain ownership of decisions that require judgment. We produce better results working together.
A Suggestion on What to Look For
When you're evaluating development partners or trying to understand how AI should factor into your software investments, here's what we suggest.
Be cautious with teams that promise AI driven speed without explaining what remains a human responsibility. If the pitch is "we use AI to build faster," ask which decisions are automated and which aren't. Ask how quality is ensured when code is generated rather than written. Ask what happens when something breaks.
Be equally cautious with teams that dismiss AI entirely. The tools have real value when used thoughtfully. A team that refuses to engage with them may be working harder than necessary for the same outcomes, and you may be paying for that extra effort.
Look for teams that can clearly articulate how they think about AI. Where does it fit? What stays human, and why? How do they ensure that any amplification benefits the client rather than just accelerating delivery?
Finding the Middle Path
At Infinity Interactive, we've spent more than 25 years building software for clients who need technical problems solved without managing technical details themselves. AI tools haven't changed that mission. They've made us more effective at it by freeing us to apply judgment where it matters most.
We've also learned that this approach is teachable. Developers who've drifted into abdication can learn discipline. Those who've been repelled by the hype can learn to see past it. Both benefit from working alongside people who've already navigated the middle path and built practices that work.
The tools can help us move faster. They can't replace judgment. Judgment is still what our clients are paying for, and we still take responsibility for what we ship.
Want to talk through how AI assisted development could work for your team? Whether you're looking for a development partner or want to help your existing team find that middle path, we're happy to share what we've learned. Let's talk →