The quality of an LLM outputs is greatly dependent on how many guard rails you have setup to keep it on track and heuristics to point it on right direction (type checking + running tests after every change for example).

What is health of your enterprise code base? If it’s anything like ones I’ve experienced it’s a legacy mess then it’s absolutely understandable that an LLMs output is subpar when taking on larger tasks.

Also depends on the models and plan you’re on. There is a significant increase in quality when comparing Cursors default model on a free plan vs Opus 4.5 on a maximum Claude plan.

I think a good exercise is to prohibit yourself from writing any code manually and force yourself to do LLM only, might sound silly but it will develop that skill-set.

Try Claude code in thinking mode with the some super powers - https://github.com/obra/superpowers

I routinely make an implementation plan with Claude and then step away for 15 mins while it spins - the results aren’t perfect but fixing that remaining 10% is better than writing 100% of it myself.

Rule #1 I don’t do agentic coding. I keep my hands on the steering wheel and have it build everything up step by step, validate the code, commit. Repeat.

With agentic coding people underestimate the agent and over estimate the models value. So it’s important to be specific. What agent are you using? You will see radical performance differences between Claude code and codex compare to copilot for instance. You will also see pretty big differences if you have well groomed, agent specific agents files. Especially if the code base is very large, the agents files need to be able to guide the agent to make connections in the code.

But other than that what I’ve found to be the most important is static tooling. Do you have rules that require tests to be run, do you have linters and code formatters that enforce your standards? Are you using well known tools (build tools, dependency management tools etc) or is that bespoke.

But the less sexy answer is that no, you can’t drop an agent cold into a big codebase and expect it to perform miracles. You need to build out agentic flows as a process that you iterate and improve on. If you prompt an agent and it gets it wrong, evaluate why and build out the tools so next time it won’t get it wrong. You slowly level up the capabilities of the tool by improving it over time.

I can’t emphasize enough the difference in agents though. I’ve been doing a lot of ab tests with copilot against other agents and it’s wild how bad it is, even backed with the same models.

The problem is you still think that the perfect prompt or AGENTS.md or whatever is going to get you a one-shotted (or close) feature in return. There isn't (yet) a model or orchestration framework that is going to take a large feature from start to finish for you.

The reality is that LLMs/agents are just a new way to write code. You still need to understand, more-or-less, how this feature is going to actually work, and how it needs to be implemented, from start to finish.

The difference is that you don't write the code, you tell the LLM to write the code. Once you've figured out the right "chunk size" an LLM can handle it's faster than doing it yourself.

I've found it's actually a little _harder_ in green field projects because the LLM doesn't have guard rails and examples and existing patterns to follow.

Yes, but only when the LLM is treated as an implementation detail, not the feature itself.

In enterprise systems, “full features” built directly on model output tend to fail at the edges: permissions, retries, validation, and auditability. The teams that succeed put a deterministic layer around the model — schemas, tool boundaries, and explicit failure handling.

Once you do that, the LLM stops being the risky part. The architecture is.