It’s shades of gray honestly. Sometimes they are very good (especially if you need some small tool that scratches a particular itch or want something that is 50% there right now), other times they’re extremely dumb and write horrible code. Especially of you want them to use some modern feature of your language that they don’t know anything about, or when the language in question isn’t very popular, or when the library you are using at the same time isn’t very popular, changed a lot recently and is big. They can go in circles for hours with 'wait actually …, actually …, but wait …, but actually …, ad nauseam. But when you limit them in scope, give realistic goals and constraints they more often than not work good.
My similar experience. Plan it out with clear goals and explicit behavioral tests in Gherkin. Review first.
Often I would have thought of three of those scenarios but it gave me an additional four with edge cases and full negative scenarios. I can choose which to keep or ditch.
Invest planning in architecture and enlist virtual or human review as appropriate.
Ask questions like “how well does this scale?”. “Are we painting ourself in a corner?” “What if …”
Have coding policies. Write unit tests first, make them pass and then refactor.
Enlist another agent - even from a different vendor to code review.
Create a pipeline that enlists tools that you trust to catch any nonsense. That pipeline can even include invoking another agent RAGged out to be hyper focused on quality.
Human verify commits and PRs.
At the end of the day, if you could have blasted out the same behavior with better quality then congratulations.
If you were able to create new behaviors in .1x the time with agentic assistance and awesome quality that catches the attention of stakeholders, you might start standing out as the person getting shit done.
It’s shades of gray honestly. Sometimes they are very good (especially if you need some small tool that scratches a particular itch or want something that is 50% there right now), other times they’re extremely dumb and write horrible code. Especially of you want them to use some modern feature of your language that they don’t know anything about, or when the language in question isn’t very popular, or when the library you are using at the same time isn’t very popular, changed a lot recently and is big. They can go in circles for hours with 'wait actually …, actually …, but wait …, but actually …, ad nauseam. But when you limit them in scope, give realistic goals and constraints they more often than not work good.
My similar experience. Plan it out with clear goals and explicit behavioral tests in Gherkin. Review first.
Often I would have thought of three of those scenarios but it gave me an additional four with edge cases and full negative scenarios. I can choose which to keep or ditch.
Invest planning in architecture and enlist virtual or human review as appropriate.
Ask questions like “how well does this scale?”. “Are we painting ourself in a corner?” “What if …”
Have coding policies. Write unit tests first, make them pass and then refactor.
Enlist another agent - even from a different vendor to code review.
Create a pipeline that enlists tools that you trust to catch any nonsense. That pipeline can even include invoking another agent RAGged out to be hyper focused on quality.
Human verify commits and PRs.
At the end of the day, if you could have blasted out the same behavior with better quality then congratulations.
If you were able to create new behaviors in .1x the time with agentic assistance and awesome quality that catches the attention of stakeholders, you might start standing out as the person getting shit done.
Either way, your expertise is valuable.