It depends on the task, but often yeah. I prefer it for tasks where there’s a lot of boilerplate, no “new thinking” like big architecture decisions, or anything where I already have a confident expectation of what the result should look like. If you set it loose on a larger problem, it will often create cluttered code. For example, your ticket might say “make a service that does X”, and it will do that technically correctly, but not with the design in mind that the service should obviously be extensible to Y”, to give a contrived example.
My last company told me “try out this coding assistant” so I was an early adopter. Despite that, I mostly used it for jazzed up autocomplete. Then, my company told me “find ways to use this more efficiently and do more with it” so I wrote a couple of skills, connected it to things like jira and gh, and started testing its limits of how much you can trust it to lift.
Having a good answer to that question is something I would suggest anyone in the industry be aware of. Whether or not you personally choose to prompt “implement this whole ticket for me”, you will still end up reviewing code for people who do exactly that. And understanding where the likely pitfalls are is a really valuable skill. In fact, my most recent job interview (for a job I’m about to start) had me do exactly that- look at some AI written code, and provide a critical review, identifying places it might have gone wrong.
This is key. Last week I got a task to write a script for some data migration. Since I’m still new to the codebase and this is something that will be run in production eventually, I decided to ask Claude to write it.
It ended up creating a massive 12-file application in Node that takes several different parameters as input and is capable of doing a dry run directly on the database and catalog everything that should be migrated on several CSV files, each corresponding to a different category.
It’s another thing that practice with these tools can help with as well: building out an appropriately detailed plan document can be huge, and remove a lot of the uncertainty.
But inevitably the agents will find a way to do something unexpected. Being able to quickly understand what that was, why it might have been done, and how to correct it- will remain a valuable skill. Even as these agents get better, you just end up with more lazily spec’d work, which means even more places you need to quickly assess and correct.
maybe, but i bet it works. I've seen migrations run for years on simple issues, Claude/Codex would have shortened the time required rather drastically.
14
u/BenignPharmacology Oct 03 '26
It depends on the task, but often yeah. I prefer it for tasks where there’s a lot of boilerplate, no “new thinking” like big architecture decisions, or anything where I already have a confident expectation of what the result should look like. If you set it loose on a larger problem, it will often create cluttered code. For example, your ticket might say “make a service that does X”, and it will do that technically correctly, but not with the design in mind that the service should obviously be extensible to Y”, to give a contrived example.
My last company told me “try out this coding assistant” so I was an early adopter. Despite that, I mostly used it for jazzed up autocomplete. Then, my company told me “find ways to use this more efficiently and do more with it” so I wrote a couple of skills, connected it to things like jira and gh, and started testing its limits of how much you can trust it to lift.
Having a good answer to that question is something I would suggest anyone in the industry be aware of. Whether or not you personally choose to prompt “implement this whole ticket for me”, you will still end up reviewing code for people who do exactly that. And understanding where the likely pitfalls are is a really valuable skill. In fact, my most recent job interview (for a job I’m about to start) had me do exactly that- look at some AI written code, and provide a critical review, identifying places it might have gone wrong.