Where AI Helps Developers and Where It Goes Wrong

Introduction

AI has made me faster on real projects, especially when I already understand the system, the workflow, and the business context I am changing.

The biggest gains usually come from the boring but time-consuming parts: boilerplate, repeated patterns, documentation, first-draft tests, and getting from an idea to something workable faster. But faster output is not the same as better output. AI can accelerate useful delivery, but it can also accelerate bad architecture, weak product decisions, and expensive implementation choices if no one is guiding the work.

AI Is Good at Producing Code Quickly

My experience with AI-assisted development has been strongest when the problem is clear, the surrounding system already has patterns to follow, and someone experienced is actively reviewing the output. In those situations, AI can significantly reduce the time spent on repetitive implementation work. It does not remove the need for technical judgment, but it can move a project from blank-page effort to reviewable work much faster.

• Generating boilerplate code: AI is useful for creating repetitive scaffolding such as routes, handlers, forms, API payloads, validation logic, and component structures. The work still needs review, but AI can remove a large amount of tedious setup.
• Refactoring repeated patterns: I have used AI to identify places where repeated markup or logic could be simplified into an array, a reusable function, or a shared component, especially useful when a codebase has grown quickly and the same pattern has been copied several times with small variations.
• Converting between frameworks: In one project, I used AI to help convert a React Bootstrap application to a modern component library. The team's original estimate was around six months, based on the scope of the work before anyone had adopted tools like Claude or Codex. With AI-assisted development, it was completed in about six weeks.
• Writing tests that would otherwise be skipped: Developers often know tests are important, but under delivery pressure, unit and feature tests are easy to defer. AI can create a first draft of tests for existing logic, giving developers something to review, improve, and expand rather than starting from nothing.
• Explaining inherited code: AI can help explain what unfamiliar code is doing, especially when the original developer is no longer available. This is useful not only for developers, but also for product managers, stakeholders, or technical leads who need to understand the intent and risk of a change.

These examples are why I see AI as an accelerator rather than a replacement. It can produce code and options quickly, but the value comes from having someone experienced enough to know what to accept, what to reject, what to simplify, and how the output fits into the broader product or delivery goal.

Speed Is Not the Same as Quality

AI can produce code quickly, but fast output is not the same as good engineering. Some of the most frustrating AI-generated solutions in my own work were technically functional but difficult to maintain, usually because of unnecessary abstraction: wrappers around wrappers, helper functions around helper functions, and compatibility layers that made the code more complicated. This usually happened when AI tried to make one existing pattern work with another instead of stepping back and asking whether both patterns should be redesigned.

A useful analogy is a book written in English that needs to be read by a French speaker. The best solution is to translate the book into French. AI, however, may notice that another chapter on the shelf is written in German and decide to create a process that translates the English book into German first, then into French. The result may technically work, but it introduces unnecessary complexity, more failure points, and a harder system to maintain.

There is a human version of this same problem. Once people get comfortable with AI output, they often stop challenging it. The first answer looks reasonable, it is confidently worded, and it is faster than pushing back and asking for something better. Over time, that habit matters more than any single mistake. The people who get the most out of AI are usually the ones who keep questioning the output, even after months of using it well, not the ones who eventually just accept whatever comes back first.

I've had to challenge AI responses regularly, since they missed context, made an incorrect assumption, or just made things up.

This is why experienced technical people remain essential. AI can generate options quickly, but someone still needs to evaluate architecture, remove unnecessary complexity, enforce standards, and decide whether the proposed solution is actually right for the system and the business problem. The same pattern applies to product and solutions work: AI can summarize feedback, generate feature ideas, draft requirements, and compare options, but it cannot fully own prioritization, stakeholder alignment, business context, or accountability.

How to Use AI Well

Using AI well is not just about picking the most powerful model. In practice, the best results come from matching the model to the task, giving it clear constraints, and reviewing the output with experienced judgment.

Different models have different strengths. In my own work, stronger reasoning models were more useful for backend logic, SQL, debugging, and architecture decisions. Smaller or cheaper models were often good enough for repetitive refactoring, simple tests, classification, summarization, and structured extraction. Some models performed better for frontend layout and visual component work, while others were better suited for backend implementation. Model choice is both a technical and product decision: a high-end model may be worth the cost for complex reasoning or high-risk work, but wasteful for simple classification or boilerplate generation.

After using several AI models across coding, document analysis, image scoring, feedback classification, and general delivery workflows, my conclusion is that there is no single best model for every task. The right choice depends on the type of work, the required quality level, latency, cost, integration complexity, and how much human review will be involved. These notes reflect my experience with the models available at the time of writing. Since model quality and pricing change quickly, the broader lesson matters more than any specific ranking.

Conclusion

Model selection is a product and architecture decision, not just a technical preference. For high-value reasoning tasks, a more capable model may be worth the cost. For repetitive classification, summarization, or structured extraction, a cheaper model may deliver enough quality at a much better operating cost. The best implementation is often not one model everywhere, but a routing strategy that matches the model to the job.

AI will reduce the value of some repetitive tasks, but it increases the value of people who can define the right problem, guide the tools, evaluate the output, and integrate the result into real systems and real workflows.