AI coding agents are getting better at writing code. But after testing several of them on real projects, I've learned that choosing the right tool is only part of the problem.
The more important question is: Can the agent actually help you ship working software?
As an independent developer, I care less about impressive demonstrations and more about what happens when an AI agent has to work with an existing codebase, understand a project's requirements, fix bugs, or implement a feature without breaking something else.
Here's what my experience has taught me so far.
1. The best AI isn't necessarily the best coding agent
It's tempting to evaluate AI tools by how well they answer questions or generate code snippets. But working on an actual application introduces a different set of challenges.
A coding agent might generate a beautiful component but misunderstand how it fits into the existing application. It might implement a feature that looks correct but fails when connected to a backend. It might even introduce new bugs while attempting to fix old ones.
I've experimented with several tools, including ChatGPT, Claude, DeepSeek, Kimi, Grok, and Codex.
My results varied depending on the task.
Some tools performed better at frontend work, while others were more effective at backend implementation and debugging. The tool that impressed me in one area wasn't necessarily the one I'd choose for another.
The lesson? Evaluate AI tools on the work you actually need them to do, not just on their demos.
2. Context matters more than I initially expected
A coding task rarely exists in isolation.
When working on an existing application, an agent needs to understand more than the immediate instruction. It needs to account for the project's architecture, existing conventions, dependencies, data structures, and intended user experience.
Consider a seemingly simple request: add a new feature to a productivity application.
The implementation might involve:
- Updating the interface.
- Connecting the feature to existing application state.
- Persisting data correctly.
- Handling errors and edge cases.
- Making sure existing features continue to work.
An agent that only understands the visible interface may produce something convincing without delivering a complete implementation.
I've found it useful to be explicit about requirements, constraints, and expected behavior rather than relying on a vague description of the desired result.
The more consequential the change, the more important it becomes to understand the surrounding code.
3. Different tools deserve different jobs
One of my most useful observations has been that I don't need to choose a single AI tool for everything.
I can use one tool to explore an architectural decision, another to help implement a feature, and another to investigate a stubborn bug.
For example, when developing an application, my workflow might involve:
- Planning: Define the expected behavior, constraints, and acceptance criteria.
- Implementation: Use an appropriate coding agent to make a focused change.
- Review: Inspect the generated code and check whether it follows the project's architecture.
- Testing: Run the application, exercise the feature, and check for regressions.
- Refinement: Address any problems before moving on.
This approach is more deliberate than handing an agent a broad instruction and assuming the job is finished when it returns code.
It also makes failures easier to diagnose. If something goes wrong, I can investigate a specific change rather than untangling a large collection of unrelated modifications.
4. AI-generated code still needs an engineer behind it
AI can accelerate implementation, but generating code and delivering reliable software are not the same thing.
A feature can compile and still behave incorrectly. A database operation can work in a basic demonstration but fail under unexpected conditions. An interface can look polished while being confusing to use.
That's why I believe developers should understand the code they're shipping, even when an AI agent wrote much of it.
I want to be able to explain why a solution works, identify its limitations, and modify it when requirements change.
This doesn't mean manually writing every line. It means retaining enough understanding and control to take responsibility for the final result.
AI should increase a developer's capabilities, not eliminate the need for engineering judgment.
5. The biggest productivity trap is accepting code too quickly
It's easy to confuse the amount of code generated with the amount of progress made.
An agent might produce hundreds of lines in seconds. But if the implementation is incorrect, those lines become additional work to understand, debug, and replace.
I've learned to value focused changes over unnecessarily large implementations.
A practical approach is to break substantial tasks into smaller steps, define what success looks like, and verify each important change before building on top of it.
For a frontend feature, that might mean checking the component's behavior and integration. For a backend feature, it might mean verifying data validation, error handling, and persistence.
The appropriate checks depend on the application, but the principle remains the same: generated code is a proposed solution, not proof that the task is complete.
6. My approach going forward
I'm continuing to experiment with AI-assisted development as I build and improve my own software products.
Rather than chasing every new tool, I want to develop a workflow that combines the strengths of AI with the parts of engineering that still require careful reasoning, testing, and product judgment.
My current priorities are straightforward:
- Choose tools based on demonstrated performance on relevant tasks.
- Give agents clear requirements and enough project context.
- Keep changes focused and reviewable.
- Test actual behavior instead of trusting a successful code-generation response.
- Treat failures as useful feedback about both the tool and my workflow.
I don't think there's one universally best coding agent. The best choice depends on the project, the task, the available context, and how effectively the developer can evaluate the result.
And as these tools continue to evolve, I expect that conclusion to evolve with them.
Final thoughts
AI coding agents have changed how I approach software development. They can help me explore ideas, accelerate implementation, and solve problems that would otherwise take longer.
But the goal isn't to generate the most code in the least amount of time.
The goal is to build better software.
I'm interested in learning how other developers are approaching this shift, especially those working on real applications rather than isolated coding exercises.
What's your experience with AI coding agents?
Have you found a tool that consistently performs well for your particular workflow, or have you also discovered that different tools excel at different tasks?
I'd be interested to hear what has worked for you, what hasn't, and how you verify that AI-generated code is actually ready to ship.
Top comments (4)
Really good point about generated code not necessarily meaning the task is complete. I've noticed that the real challenge isn't always getting AI to write code, but making sure the result actually works as intended. How do you decide when to trust an AI-generated implementation and when to rewrite it yourself?
Personally, I prefer asking the agent to make only the minimum changes needed instead of rewriting half the project for one feature, I review every change it makes and fix things myself if something's wrong. And if it completely messes things up, I just delete its changes, rethink my prompt, and try again. Saves me from spending more time debugging the AI than actually building the product lol.
The hidden price in agentic coding is the verification surface. Generating two hundred lines of plausible code costs a fraction of a cent, but auditing whether an agent quietly mutated state or touched an adjacent file costs twenty minutes of human attention. When generation cost drops to zero, an agent that touches five unrequested files creates negative value on the review step. The tools that actually save budget are the ones that keep their blast radius narrow enough that verification stays cheaper than typing.
Mostly by not taking "done" at face value. In a model-labelled sample of 800 of my own follow-up prompts to coding agents, about 1 in 6 existed because the agent fell short, and 37% of those were verification gaps. My global instructions ask the agent to end with what it ran and what that showed, and to write "not verified" plus the reason for anything it couldn't check. That tells me what to run myself. I haven't measured whether it cuts the misses.