I'm an ML engineer with about eight years of industry experience and an academic background. I use Python professionally and for personal projects, and I've been experimenting with LLMs for coding. So far, I've found them most useful for syntax, boilerplate, optimization ideas, documentation, and bouncing around possibilities. I still design the approach myself, review the output continuously, and make sure I understand the underlying algorithm.
Recently, I've seen much more discussion about usage-based billing and autonomous coding workflows. Some people claim that agents now write most of their code, while others say newer models have improved enough that they rarely code manually. A few friends have encouraged me to try a more agent-driven approach.
I'm skeptical because my work often involves experiments where I need to understand exactly how data is being processed. For anything beyond a small task, creating a sufficiently detailed prompt seems difficult and time-consuming, and the results often need substantial correction. I'm interested in hearing from people who use autonomous coding agents successfully: What kinds of work are they genuinely good at, and where do they become a liability? Should I experiment more, or is a closely supervised, low-autonomy workflow still the sensible approach for complex technical work?
5 Answers
For serious, maintainable work, your current approach is probably the sensible default. Agents can produce a lot of code quickly, but without strong tests and a very detailed specification they tend to create tangled implementations that are difficult to understand or extend. They’re much better suited to throwaway prototypes, one-off experiments with easily verified results, simple interfaces, boilerplate, and tasks where failure is cheap. For high-stakes work, autonomy only becomes practical when you already have excellent tests, clear requirements, and strong review guardrails.
Autonomous workflows can work, but the successful version is usually less hands-off than the marketing suggests. I spend a lot of time preparing plans, documenting requirements, defining project rules, and setting up automated checks. The agent then handles implementation in smaller pieces while tests, linters, pre-commit hooks, and review passes catch problems. I also use separate review passes to challenge the plan and inspect the finished code. That can dramatically increase throughput, but it shifts effort from typing code to managing context, reviewing decisions, and maintaining the safety net.
LLMs are useful tools, but they still aren’t reliable architects. I get the most value from having them review code and documentation, point out missing cases, explain unfamiliar APIs, catch code that is syntactically valid but semantically wrong, and help with small implementation details. They can also follow an existing pattern reasonably well. I would still verify everything they write, especially in research code where subtle assumptions about the data can invalidate the result.
I use coding agents frequently, but I treat them more like fast collaborators than employees who can be given a vague goal and left alone for hours. I ask them to research relevant papers or documentation, record their assumptions and uncertainties, propose a plan, and then work through the plan interactively. With enough context, they can be surprisingly effective for research and implementation. The quality drops sharply when you simply provide an objective and hope the agent will autonomously discover the right approach.
Some people do report having agents write most of their code, but that doesn’t necessarily mean the workflow is appropriate for every project. It can be productive when the code is heavily tested, the task is conceptually straightforward, or the project is disposable. For experimental ML work, where correctness depends on data handling and subtle methodological choices, close supervision is still valuable. More autonomy may save keystrokes while costing more tokens, review time, and debugging effort.
The hardest part is accepting that writing code is often the cheap part. If the plan and constraints are weak, the agent can generate a large amount of plausible-looking work that still needs to be untangled.