Since trying to adopt LLM workflows since around 2023, LLM generated code has generally left me with a feeling of mild satisfaction at best. Sitting now in 2026, models have improved by leaps and bounds but LLM code still leaves me with that feeling. That’s not to say that LLMs haven’t encroached into more and more of my workflow over time, however the actual code output they generate has not left me more impressed over time. Some of the developers that I trust the most, those cracked staff devs who seem to know everything inside an out, seem to hold this opinion as well. It’s typically the junior and mid level devs that I’ve noticed lean on LLM tools the most. For a business trying to optimize for labour cost, the “mid” quality of AI code is fine enough, however the cult of AI driven agentic workflow development has started to turns it’s nose up when a developer does something “manually”.

“Agents are so good now! I’m sure if you asked model of the week to do that for you it would crush it!” – Everyone I talk to AI about

With how good models are now I have to agree, but it’s beyond a question of fidelity. I would believe that whatever new ultra coding model given the right context, tools, skill files, hooks, etc would 100% be able to execute on the tasks. The question for me becomes: if I already know what I want to do, what’s the tradeoff between just doing it and trying to explain to an agent how to do it?

Where I use LLMs

LLMs have found their ecological niche in my development environment as an effective “research assistant” that I can delegate factual research tasks to. With some of the available MCP connectors in most agent harnesses, it’s so easy to ensure that an agent has access to tools it needs to see monitoring data, database DDL, database data, code patterns, and even institutional knowledge. Those natural questions that come up when planning a feature such as “How much extra write traffic to this table will I introduce with this change” or “How many times does this job I’m adding a new query to run in a day” can be delegated to an agent on the spot leaving me to return to whatever train of thought I was already in.

As much as I really want to say that all LLM generated code is garbage slop code not worth any real developers time, that’s not an intellectually honest opinion either. The reality is LLMs and agent harnesses like Claude Code are now write decent code for the most part. Agents can still struggle to write concise code that’s informed by knowledge of a given business task, and the code LLMs generate does tend towards the over-engineered at times, but for most businesses that’s probably a fine tradeoff. Agents are especially effective with changes where the work of discussing what change needs to be made is more work than the change itself: copy changes, repeatable changes to several files, etc. If we are heading towards a world where those sorts of tasks can be executed by an agent being driven by a non developer, and reviewed by developer teams, that seems overall like a win to me.

The key factor that makes these tasks worth an agent doing for me is they, typically speaking, don’t take context on the codebase and the business away from me as a developer. Adding meta tags to a bunch of buttons, asking claude to rewrite an array map using a functional interface, or reviewing an AI written PR that adds a small conditional fixing some Sentry error that’s been kicking around aren’t going to reduce my ability to understand the system that a codebase is representing and the business need that it’s trying to solve.

Where LLMs fall flat for me

It’s only a given then that where I don’t like LLM and agent driven work is tasks that do require my own expertise of the codebase, software development practices, or my experience. Claude Code could, with some non zero amount of quality, create for me a large sized epic that adds functionality to the app. It then could, in theory, automatically execute on those pieces of work autonomously and in parallel. I could orchestrate 15 agents all working together, giving each other code reviews, with a designer agent and a supervising agent, to get the work done. I do 100% believe agents could do this and produce a reasonable product. In fact, I’ve contracted my services out on the side and basically done just that, and the product worked well enough to make the client happy.

Where LLMs fall flat for me is not fidelity. The tradeoff between developer context and LLM speedup just isn’t worth it, and that’s being generous and assuming that agentic workflows like what I describe above do actually speed up work (With the data that I have seen I’m not convinced the speed up is real but I would believe it can given the right org).

Good developers thrive on what LLMs take away

The best developers thrive on institutional knowledge. They know their code is legacy the moment it’s shipped to production. They know that the needs of the business are going to change in a few months. They’re ready for half of their project to get de-prioritized for a company wide priority project. They know how much over or under engineering they need to do for a project by reading the context of that project against the business. LLMs are just kind of bad at that stuff. LLMs don’t know that your PM has a tendancy to under-estimate the effort of projects, or that at a company all hands if you read between the lines you know that your team is going to have to do support work for another team for a quarter. Company and office politics, org structure, and the ego of people leading projects are important inputs that can have a real effect on the code you write. And the verbose and winding nature of LLM code doesn’t lend itself well to the fuzzy nature of how work really gets done in an software shop.

Claude Code-ers aren’t bad devs

All that being said, I don’t believe in the type of “developer powerscaling” that tends to happen in conversations like this. The Primeagean Pirate Software Yandere Dev Linus Torvalds Jonathan Blow epic pwn your code sucks cause you write javascript is a toxic part of the wider culture of software that I hope dies and never comes back. This is work for most people at the end of the day, and if the way you choose to get work done (or need to get work done if you work at a company like that) is to spin up 5 claude code agents and prompt…you gotta do what you gotta do. A non zero amount of my token usage at work is simply so that I can say I tried to do something with AI. I will say that I think going forward what’s going to separate mid level from senior developer is a desire to struggle through problems yourself and seek that deeper meaning, even if only to be able to better control agents that go off the rails.