AI Coding Agents: You have to watch them carefully
I must admit: I was quite the skeptic when AI coding agents made their way to the fore. In my defense, early versions were -- at best -- clumsy and not too helpful.
Time went by, and trying the tools again, I found them much improved, in fact remarkably so. I had to admit I could now see how very useful these tools can be to a seasoned engineer.
Why Coding assistants are an old engineer's best friend
I'm sure junior and intermediate engineers have their own tales of how these tools are saving them heaps of time, how they are way more productive, etc. I'll let them tell their own tales.
For an engineer / architect with decades of engineering experience, I can tell you that coding agents are incredibly powerful for taking an idea and a design and turning this into a reality. Going from 4 - 6+ months to build out a rules engine to doing so in a couple days is hard to argue with: from ideation to implementation in so short of time means you can really drive change in your organisation.
What I've said could be true of engineers newer to the game (and likely is true), but the great power of being more experienced / knowledgeable in software design and implementation is that as a seasoned engineer, you know the pitfalls and pratfalls that software projects often encounter if certain things aren't done properly. If you aren't in the know, things like exception handling, proper authentication, performant code, adhering to industry standards and so on can end up being lost when using an AI coding agent.
Why? Because if you don't know to implement these things, then likely neither will your coding agent.
It's all in the context
As I mentioned in a previous post, when it comes to coding agents, providing context is critical to success.
The agent isn't a genie granting wishes. If you tell it "Write me a react app which lets people track their pets' diet goals", it will do its darnedest to do just that. But without context, it will likely do a pretty crummy job.
Context can be provided in the form of instruction files (copilot, cursor, windsurf and many other support this paradigm), in the form of task-oriented prompt files, but most important of all, from the prompt conversation you're holding with the agent.
When developing our pet diet app, we want to build up the agent's understanding of not only what our application does, but what are our coding best practises, the correct tools / libraries to use to implement our system, how best to secure the system, instrumentation and logging, and so forth.
The agent might accidentally land on this kind of best practise stuff, but that's not been my experience. Agents will do what you tell them, but without the context of expertise, they will brute force a solution for you which is -- in many cases -- sub optimal and which is missing those critical infrastructure and scaffolding code units one expects from a production-quality system.
Agents gone wild: Why you have to keep an eye on the little devils
Ask any engineer you know using these tools, and you'll hear hysterical tales of coding agents gone on what appears to be a psychedelic walkabout, doing things that are clearly not a good idea.
Agents can go off down a crazy road trying to solve some issue in the code it's developing, editing file after file but with no fix in sight. You step in, take a look, and realise it was just missing a reference to another file.
The "Eureka Doom Spiral" This is where the agent, trying to work out why its code is failing will fall into an endless cycle of code scanning and repeatedly calling out "Eureka! I found the problem", or "Here's the smoking gun!" but never landing even close to the actual problem. I once let an agent keep going until it worked out it was NOT close to the problem, but after a while it stopped being funny and started feeling awkward. I just fixed the bug myself.
Too little or too much Agents can take shortcuts where you don't want them, but in other cases implement a mad amount of custom code when a single nuget / npm / py package would have sufficed.
AI Chatty Cathy Agents can be verbose to the point of being blabbermouths. Getting all that dope documentation out of your agent can be a double-edged sword when you find your repo's README.md is as long as War and Peace.
These are just some examples of why you need to apply your expertise and discernment to what these tools are producing. They need you to make best practise decisions, both in how you prompt them as well as in knowing what to keep and what to ditch, when to interrupt our eager agent when it's gone off the rails, and what of its output is useful or actually what we want.
Wrap Up
While it's super exciting to be part of a generation of engineers to see the advent of these kinds of tools, it's also important to remember that a fancy new jigsaw is only as good as the craftsman who's applying it.
As an engineer, these tools are there to assist you, not to do your job for you. You still have to apply best practises, provide guidance, discern useful code from cruft. If you want to understand where your value lies as an engineer in the age of coding agents, it's just this. You are the expert in what needs to go into your solution to make it the best it can be.
The agent is just taking a crazy amount of dictation and input from you to make your high-quality system a reality.
source: https://www.linkedin.com/pulse/ai-coding-agents-you-have-watch-them-carefully-chris-smith-mtzsc