I've been away from the corporate software world for a while and can't really justify an expensive AI subscription. I've experimented with AGY CLI and Codex: AGY handles basic frontend work fairly well, but building a Flutter app required quite a bit of guidance. Codex has also been frustratingly slow and frequently reports that my monthly quota has expired before doing much useful work.
I keep seeing two very different opinions. Some developers say tools such as Claude Code are so capable that they barely write code anymore, while others say AI still hallucinates, needs constant supervision, and produces code that requires substantial cleanup. What is the realistic picture? Where are these tools genuinely useful, and how much software engineering skill and review do they still require?
6 Answers
A productive workflow is to use a stronger model for planning and clarification, then let a coding model implement a detailed, reviewed plan. Keep the requirements and architecture explicit instead of asking for an entire product from a vague prompt. Automated guardrails are also essential: unit, integration, and end-to-end tests, linting, security checks, and architecture checks should run before changes are accepted. With good tests and small, well-defined tasks, AI can significantly increase throughput. Without them, it can quickly fill a project with plausible-looking code that nobody fully understands.
The quality depends heavily on the task and the codebase. AI is quite good at familiar, well-specified work, repetitive transformations, scaffolding, and disposable scripts. It is much less reliable with implicit requirements, unusual architecture, deep debugging, and decisions that require understanding years of context. The output often resembles work from a junior developer: frequently useful, but rough and prone to odd design choices. Experienced developers get more value because they can provide detailed requirements and recognize problems quickly.
The practical answer is to try a modest plan or a local/free option on a real but low-risk project and measure the result yourself. Subscription limits and model speed vary, but the important question is how much time the tool saves after review and correction. Don’t judge it only by how impressive the first generated code looks. Track the time spent specifying the task, fixing mistakes, writing tests, and maintaining the result. AI is powerful and useful, but it is not a substitute for understanding the code you ship.
AI is also useful as an advanced autocomplete or refactoring assistant. For example, it can update a calling convention across many packages or generate a one-off script that would otherwise take an hour to write. I prefer asking it to create a reusable script rather than performing a large manual change through repeated prompts. However, it tends to overproduce code, reimplement things that should be reused, and choose unnecessarily complicated solutions. Tests and static tooling help, but they don’t replace reading the code.
That distinction between reusable scripts, routine transformations, and core product code is helpful. The risk seems much lower when the tool is producing a throwaway utility than when it is shaping a long-lived system.
Those views aren’t really contradictory. AI can handle a large amount of implementation work while still producing hallucinations, weak abstractions, and subtle bugs. The more responsibility you give it, the more important it becomes that someone understands the system well enough to define the direction, review the result, and catch failures. It’s a bit like autopilot: it reduces routine effort, but you still need a qualified pilot who knows where to go and what to do when things go wrong.
Your results will depend on both your experience and your workflow. Senior developers often get better output because they can write precise prompts, break down a feature, and evaluate architectural tradeoffs. Less experienced developers may get working code without realizing that it is insecure, inefficient, or difficult to maintain. AI can help people learn, but it doesn’t automatically develop the judgment needed to verify its work. In practice, many developers are not idle; they are spending less time typing and more time planning, reviewing, testing, debugging, and making product decisions.
That matches what I’ve been seeing. It can produce something that looks complete very quickly, but reviewing whether it is actually maintainable or correct still takes real engineering judgment.