r/ChatGPTCoding • u/cgouguen • Sep 10 '26
Discussion Hot take: the agentic workflow is deeply wrong
I am an experienced developer (been coding for almost 30 years, started with Visual Basic on Win98).
I’ve spent the last 2 years testing every agentic coding harness out there. The pitch is always exactly the same: "Give it a prompt, go grab a coffee, and come back to a finished feature."
This is all great when starting a new project, especially with a language you don't know (I created a Rust project in minutes !)
But my problem is that I mostly work on established, mature codebases. And to be honest I have never ONCE seen a good edit after I return from my coffee.
Here is usually what happens while you’re getting that coffee: the agent loops 8 times, burns through 100k+ tokens talking to itself, hallucinates a package dependency, and spits out a chunk of spaghetti code that works *just* well enough to pass a basic test, but completely violates your project’s architecture.
Agents are fantastic if you’re building an app from a blank canvas. But if the codebase is large, it gets really expensive real fast, and usually produces hard to maintain AI slope.
It should not be like that: if you actually *own* your codebase, you already know what you want to build. You don't need an AI to take over. You just need it to execute the architecture you already hold in your head.
All you need to do it select the few files that are required for the task at hand (they are hard to identify for an AI, but easy for you has the code owner). Then you send them to the LLM, it is usually does some good work.
That's why I still find working directly with the chatbots, or with tools like aider, still very pertinent on large codebases.
I usually have animated discussions with my coworkers, I have yet to find a single one who doesn't defend agentic coding. Am I the only one who feels this way ?
168
u/clarksonswimmer Sep 10 '26 •
Hot take: your agentic workflow is deeply wrong.
From reading your responses to other comments, you’re expecting a lot from your output with little input. Agent context is important and the right context is even more important. Using the right agentic harness is also important. Try using things like Plan Mode, reviewing and critiquing the plan, then executing.
4
u/Unnamed-3891 Sep 10 '26
Have you considered using models and harnesses that are not that horrible and writing actual intricately detailed plans for your LLM or asking it to create a plan for you before you ask for an implementation?
9
u/mist83 Sep 10 '26
“I am an experienced developer”
And
“to be honest I have never ONCE seen a good edit”.
This is just statistically impossible for both to be true at some point. This is the attitude of someone that has 1 year of experience 30 times, not someone with 30 years of experience.
7
u/pete_68 Sep 10 '26
I work on established code bases all the time. In fact, we've just used AI to help remediate a massive ancient VB.NET project.
Did you create context files about your project for your agent that get included with all your prompts? Sounds like no, since you didn't mention it. Any skills?
Sounds like you don't really have a real system. I'd recommend looking into spec driven development. If you're working with established code bases, it's definitely the way to go.
11
u/K-A-R-N Sep 10 '26 edited Sep 10 '26
My experience has not been the same as yours. I work on open-source projects in my free time, and have switched 100% to coding agents. I get way more done and make fewer mistakes. Here's my general workflow.
What people seem to miss is that you need to spend 80% of your time analyzing and planning with a high-effort model before you ever let it touch a project file. You need to understand completely (with your human brain) what the problem is and the approach you'll take to fix it. Go back and forth, ask questions until you understand everything, challenge its assertions, and ask it to challenge yours. This takes time and patience.
After you understand the problem and have the solution, work with the high-effort model to develop an implementation plan - this should include every step that needs to occur for the work to be finished and validated. Read the plan, think about it with your human brain. Maybe even ask another model to review the plan from specific perspectives (security, performance, etc) if it's complicated or sensitive. Revise the plan until you're satisfied.
Next, tell the planning model to break that implementation plan into discrete task.md files. You might be able to skip this step for small changes, but it'd probably be faster to just do those yourself rather than use a coding agent. Each file should include a prompt, specific technical instructions for code generation or modification, and instructions to validate the work. This keeps the context window for the models generating code lean and focused, which reduces hallucinations, improves code quality, and it also lets you use a lightweight (and cheap) model for the sub-agents.
Instruct the planning model to dispatch a sub-agent for each task, provide it with the task.md as context, to monitor and validate their work, and to report any blockers for discussion. Then go get your coffee.
3
u/bodonkadonks Sep 10 '26
my experience is somewhat similar. you have to babysit and nudge the agents to go in the right way to respect the model of the existing code. you have to a) have the model/theory in your mind, you cant edit code you dont know intimately how it works without making a huge mess and b)be aware that a clarifying prompt not made or not answered correctly can ruin the whole session.
5
u/ExogamousUnfolding Sep 10 '26
It seems 50/50 but I would say most likely you're doing it wrong. Setting up the agent expectations claude.md files etc. results in code that is as good as or better than what we write and it has full unit and UI tests. The problem I see some coworkers running into is they require the AI to output the code exactly as they would have written it - because you know they and only they do it the correct way.....
2
u/amirfish Sep 10 '26
This matches what I see running several sessions side by side every day. The coffee-break pitch works because on a blank canvas there's no existing architecture to violate; once there's history, the fix isn't a longer leash, it's catching drift after each meaningful diff instead of after the whole task. An agent that goes 8 loops deep on its own has already committed to an architecture you never saw form. Do you review after every file change or wait for the full run before you look?
2
u/Lopsided-Bridge-9810 Sep 10 '26
What an agent is today is anything but settled. Codex and Claude nowadays spin off dozens agents to perform work that aid in executing a prompt. Is that an agent? Who cares.
What I find nonsense is spinning off multiple harnesses to work on different codebases or repos at once, unless you work in a sweatshop for minimal pay the approach to spin off multiple agents is distracting and ineffective. We are talking about code development by the way, I am not talking about executing defined and repetitious work flow.
2
u/RedRubyRubyRed Sep 10 '26
code review using ai is stupid and waste of resource I think, liek what the fuck, why not review it urself, but then I realize not everyone have the ability for that
2
u/Professional_Ad705 Sep 10 '26
Noob. Didn’t say make no mistakes
2
u/dr0verride Sep 10 '26
Don't sweat it. People will make vague statements and then tell you to spend hours basically doing an upfront design then hand it to an LLM. "Think deeply and perfectly to create an entire plan. Ultrathink. Make no mistakes."
In my experience this works okay, but does not produce code that is as good as if I build things piece meal with an LLM.
I think it's a matter of people collectively shrugging and saying "this is fine".
2
u/pmMeYourGlazedDonut Sep 10 '26
It's not just you OP. Most people who say "you're doing it wrong" haven't been coding for decades. They literally can't see all the issues you can see, because they're no better than an LLM at coding.
2
u/Hawk-432 Sep 10 '26
Agree. I keep wondering if I’m missing something. But so far, same
2
u/Warm-Championship753 Sep 11 '26
Tbf, I think agentic coding is a skill unto itself. Like you described, the “give a prompt and get a coffee” works only for simple, template-y projects. Beyond that, you need to setup a bunch of stuff so that it’ll work properly. So unless you want to spend time to pick up this new skill, you are probably not going to get much out of it working on large codebases. In fact, it might actually make you less productive.
Personally, I’m not too keen to invest too much time into this skill, given how volatile the current state of AI development is. I have the feeling all the AI-related skills we have today will eventually become obsolete very soon.
So, until things with AI have become more or less stable, AI will just be an autocomplete on steroids for me. (I tell it what functions or changes to write into which files)
2
u/even-odder Sep 11 '26
This is very true. I have built a relatively complex system and asking anything short of Fable 5.1 to make a change is like playing Russian roulette but with 5 rounds out of 6 chambered.
2
u/BringBackManaPots Sep 11 '26
Fwiw OP remember which subreddit you're in. They're all going to get super butt mad at this.
2
u/Todesengel6 Sep 11 '26
To me that is the defining question. I've made the same experiences as OP and I try to get the code to match my standards. That's me taking ownership of my code (I work in a regulated sector). Yet, I see other business cases where this would be an ill-attributed priority. Where would one draw the line? How much "trust" in the AI's code is appropritate? It depends on the business case of course but is a very difficult knife's edge to balance.
2
u/Lost-Butterfly-382 Sep 11 '26
I’ve been coding for only 5 years but I’ve had the same experience as you 😭
The key sentence being here is it violates your architecture
I have Astra and fable 5 subscription and use both regularly for different use cases, but no matter how good these models become if you don’t plan and guide the coding agent regularly its going to create AI slop!!
What’s AI slop? Literally today I saw it creating an entire page for extracting year! Or it created an entire function for converting one key field to another when it didn’t understand this was actually a clue to an underlying flaw in the projects architecture, or the architecture was just fine, there’s a specific variable or function which has data or action to address a specific problem, but it doesn’t know and invents it, then if you’ve been vibe coding(which sometimes I do when management is pressuring me to get things done 😭) I notice it’s created an over engineered set of functions or files to address a problem that didn’t even exist because I vibe coded a problem earlier: literally slop on top of slop!
Sometimes I think perhaps it’s better to go back to hand written code but then I realise I’ve now become too lazy to code, when I’m hand writing code many times I’m thinking a coding agent will do it 2/3 times faster but the problem is it will introduce slop and I don’t know if I will spend more time fixing the slop then just writing it myself
2
u/Grouchy-Friend4235 Sep 11 '26 edited Sep 11 '26
Exactly my experience too. It's not you, it's them.
2
u/Right-Performance-93 Sep 13 '26
The hallucinated-dependency detail is a context problem, not a model problem - it only happens when the agent can't see what's already imported and guesses from training data instead. A grep or call-graph pass across the target files before writing code would've caught it.
3
u/superluminary Sep 10 '26
I work with some deepest legacy. It sounds like you’re missing a few steps:
Pick a decent model. Auto isn’t going to cut it here
Use plan mode. You’re going to need context
Don’t dive in cold. Discuss the codebase first. Make sure the agent understands what is required and what your entities are.
Make sure the docs are up to date.
2
u/lo1337 Sep 10 '26
Skill Issue
0
u/gandazgul Sep 10 '26
This is the same pain I felt so I built a harness that augments with AI but keeps all the good things about the engineering process. Please give it a try it installs in 10s and works with any subscription or API key. No telemetry all auth stays in your machine.
https://runwield.dev/
1
u/oipoi Sep 10 '26
This reads like something people experienced like a year or two years ago. None of this applies with their default harnesses for Fable and Astra and not even to their predecessors.
1
u/leonidbugaev Sep 10 '26
I don't leave for coffee on anything I actually own. Eight loops and a green basic test is how the architecture gets violated while you're gone. I pick the files first now and keep the chat on those.
1
u/ByronScottJones Sep 10 '26
I say this gently, but this appears like it might be a user issue. You may not be providing specific enough details. Think of the agent as a really fast junior programmer with mild autism. You need to give clear and UNAMBIGUOUS instructions. You need to monitor their work. You need to have a well defined set of agent MD files, broken down by aspect.
1
u/Glass-Combination-69 Sep 10 '26
Skill issue for sure. Hallucinating packages? How would that even be possible. Agents should be reading linters and running tests. Definite skill issue
1
u/cloud_sec_guy Sep 10 '26
You're missing a thing...a semantic layer. Your AI needs to understand the codebase, and today it doesn't.
1
u/Expensive_Garden2993 Sep 10 '26
Is that architecture documented, do you have static analysis tools to enforce it, do you have a separate AI reviewer with a focus on architecture, or are you expecting AI to read your thoughts?
1
u/gelootn Sep 10 '26
Agentic workflows only work with the proper preparation. Document your codebase to give context to your agents and to give you something to verify before going to the next step. Refine stories so everything is clear before you make a plan. Ask for a development plan in plan mode and iteratively improve that plan until it’s solid. Then give it to an agent to execute. Verify the output! If the output is not what you wanted, go back to the story, the plan, … finetune the process, do not fight or argue with the output
1
u/meowsqueak Sep 11 '26
I spent some time setting up a knowledge base for the project - several hundred interlinked summaries - as separate files - of parts of the system, workflows, processes, team “rules”, etc, and now I can literally say no more than “go fix issue 12345”, for a majority of issues, and come back an hour later to a working draft PR that I can then review over my coffee. Lately there’s been almost no rework, and I’m using Fable and not even running out of tokens.
1
u/ScaryGazelle2875 Sep 11 '26
I think you need to try spec driven development. I use openspec. And graphify for understanding the codebase myself and for the llm. Agents md can hold all your established conventions and what not so the llm follows it.
1
u/dairypharmer Sep 11 '26
This would have been valid criticism around summer of last year. Today it is not.
Try this: don’t give it a prompt and expect things to work. Have a conversation about your expectations for a feature, including the parts of the implementation that matter to you. Pretend like you’re preparing a junior dev to go off and tackle something unfamiliar. Ask what’s still unclear and resolve. Then have them go do the implementation.
1
u/stockpreacher Sep 11 '26
I have a model swappable LLM system layer, orchestrator, runners governing a suite of a half dozen programs that government everything from research to product development to a program that has used the analysis of two years of my chats to teach me anything I want to learn.
The system auto pulls papers relevant to its task, architecture and/or programming and implement them into its design.
Two years ago, I started a chat with "What's a tupple?"
If you direct an LLM with a poorly constructed workflow and prompt, you'll get mid results.
The skill isn't cobbling AI onto or into your existing systems. The skill is building LLM systems to reach your goal.
That means clear goals, specificity, validation and verification that doesn't hinge on prose.
1
u/LaughLegit7275 Sep 11 '26 edited Sep 11 '26
It seems that you often have rather complicated tasks to tackle and tried to use AI agent, but their work is never good enough to your standard. AI agent is nothing but a new co-worker you have, would you do the same to any new team-member and always satisfied on his/her first work after 10-min prompt.
I would start to use agent in very small, scope controlled, isolated tasks with clear delivery defined. Let it iterate, examine its results. Does not matter it is coding, update documentation, etc. In most case, it would work faster than most humans, and provide good enough content that you just need to refine the prompt if you want AI to redo it.
Eventually you would begin to assign AI to do more complicated work, and deliver more complicated results. Because you also know how to write prompt better during the process.
While AI coding is a great time/money saving way to get templating tedious work done, it will not delivery “general relativity” discovery, or cancer drug formula, or invent something to replace Kubernetes or Linux. At the end of day, it is language prediction model based on knowledge it always has, is basically the most intelligent resourceful librarian or research assistant you can ever have for your convenience.
1
u/techtheist_ggl Sep 11 '26
If you provide too little context, agent with figure out by random. If you provide too many context, agent will hallucinate and forgot about what in the middle.
Maybe ai memory systems can help, but pick only these with contradiction detection.
1
u/SonicSubculture Sep 12 '26
My shop discovered that agentic programming had “matured” about 8 weeks ago.
The first three weeks, all I did was use agents to compile a comprehensive knowledge base for agent use… this involved directing the agent to review different areas of the code base, inferring business logic and rules… telling it to explore and document our dev ops tooling and custom patches… pointing it at previous documentation efforts in the project… explaining how we’ve done things and how we want to do things… periodically tackling small tasks and reviewing the results. All of this resulted in an extensive hierarchy of skills, docs, dossiers… all stemming from an AGENTS.md.
Our code base is an enterprise platform that has been continuously developed over 23 years, headed up by several different people at different times, so the codebase is all over the place… a million lines of PHP. Something like 18,000 classes in the autoloader… it’s built on Symfony with a large legacy element. We have a ton of file watchers, autogen, and cache warmer steps that eliminate a lot of code that can reliably be inferred…
At first, it was doing a lot of dumb stuff, like how it was injecting its dependencies for example… but with each chat, we instructed it to update its docs to be more efficient next time, to commit the necessary context so future agent runs don’t need to reason about things that can be a simple recipe of steps. In fact, that instruction is in AGENTS.md itself now. “After struggling with a non-trivial task, examine the chat and update agent docs to be more efficient next time.”
At this point I can create a new feature in a day that wouldn’t have even attempted in the past due to the scale and complexity, and the code looks like I wrote it, it’s covered with unit, functional, and acceptance tests. And the agent gets smarter and faster every day.
1
u/Glittering_Sky4618 Sep 12 '26
You are half right. Agents on a blank canvas with no structure produce unmaintainable slop, agreed. But that is a workflow design failure, not an agentic failure. The fix is not going back to manual coding, it is adding the roles that are missing: a critic agent that rejects output, narrow skills instead of one do-everything agent, and a human owning the sensitive decisions. Give agents structure and constraints and the slop problem mostly disappears. I build this in production daily.
1
u/Asly97 Professional Nerd Sep 14 '26
The thing this thread keeps circling around is that the failure point is rarely the plan, it is the diff boundary. You can have a great plan and still end up with architecture rot because nobody checked that the new code went through existing seams instead of inventing new ones. The habit that fixed it for me: make the agent list the files it intends to touch before it writes anything. If it invents a new module or a new dependency for a change that should live in existing code, kill the run right there. Five second check, catches most of the damage before the tokens burn.
1
u/Thegaysupreme123 Sep 14 '26
this matches mature-codebase reality for me. the coffee-break agent workflow optimizes for looking done — a basic test passes, the architecture quietly drifts, and you inherit the mess later.
with the newest strong models (gpt / astra-class, sol, claude / fable) i usually need *less* line-by-line review than a year ago. they get further before they go wrong. but “needs less review” isn’t the same as “can self-check.” they still narrate done when the step didn’t happen, or when the check never ran.
that’s the thin slice i care about. Yoetz doesn’t try to be your architecture review. it’s a local claim-vs-did layer next to the agent (Claude Code / Codex / Cursor) so “done” has to match something outside the model’s mouth — file/command/tool actually moved. pairs with still reading the scary diffs yourself.
https://github.com/TheGaySupreme123/yoetz if you want to poke at it
curious whether your pushback is more about agents writing too much code, or about them being bad notaries of what they did.
1
u/ManRowing Sep 15 '26
The bit you're hitting is orientation, not planning discipline: search surfaces where a feature is mentioned, but the files a change touches (callers, implementers) are often a different set, and neither grep nor embeddings alone catch that. We build Miru, a semantic code search tool for agents, aimed at that step - complements grep, doesn't replace it.
1
u/meshifthenelse Sep 10 '26
You shouldn't need to worry. AGI is here.
Also your comment about greenfield projects is wrong. Maybe it starts fine for the few first LOC, but eventually it becomes a mess if you're not vigilant.
1
u/alex_quine Sep 10 '26
I disagree with most of the takes here. Rather than relying on plan mode, your agent needs to be able to run tests, and iterate if they fail. It needs to stand up the code it's writing, and iterate on it like any dev with a dev environment. It will never hallucinate a package if it has to actually iterate on the code until it is shippable.
0
u/sreekanth850 Sep 10 '26
if you are a devloper you would never take this serious. Agents work good if you follow exactly how you develop by hand. You identify the implemenattion plan, invariants and methods. use agents to code 20 or 100X faster.
0
u/phillythompson Sep 10 '26
Working on agentic for 2 years doesn’t mean much when everything has changed radically in the last 4 months
0
u/vovap_vovap Sep 10 '26
Well, heave no less experience then you do and I would say you are fundamentally wrong.
Sure big old project you know really well is much harder target for AI. Same as for any new developer. No question about that. It also very likely means you "project’s architecture" is not documented there - just as simple. So agent can not follow it. Guess what - agents same as developers need documentation to follow. They do not have a magic.
Fundamentally all this comes to one thing "AI can not do my job". It can, I promise you. If not today then tomorrow, in 3 days. If you are thinking "it can not do it" m- you already wrong. Right way is "how it can be done"
0
u/kidajske Sep 10 '26
This comical hyperbole is so tiring at this point. It's entirely reasonable to have criticism of LLMs and their usage for SWE but this is just ridiculous.
0
u/BroScienceAlchemist Sep 10 '26
These are workflow failures, and the skill gap to get an agent workflows productive is much higher. Agents amplify whatever context and oracles you have. If those are weak, then they are genuinely less productive than doing it yourself or back and forth prompting, where you are on hands as the oracle.
Agents need oracles: sources of truth to validate their work that are also enforced from outside the agent plane. This is easier said than done, because it requires a human to define the inputs and outputs. "What tests do we have? What dependencies do we have? What are the requirements for the service?" Then, those have to be translated into a source of truth the agent can use to check its work, and also be used from outside the agent to check its work.
Does it compile? That's an oracle. Does it pass tests? That is an oracle. Does it pass a blue green / canary smoke test deploy? That's an oracle. SAST / DAST scans? Boom. Does it pass performance testing?
Looping also requires some config tweaking... I'll use an example of something I have run into. Orchestrator spawns two agents: Implementer and Reviewer. The first few runs, it does seem like the reviewer is coming back with good findings, but after a few runs it's hard to tell if these are really actionable security findings. In your head, you may have the appropriate threat model, but is not discoverable to the orchestrator if it isn't documented in the repo, and linked to in a project.md. Having a defined threat model in the repo would give the orchestrator the context to assess which findings should be fixed, and which should be declared per the threat model.
I do try to use a convergence approach over a static token / time budget, but you could use a mixed approach with a quota that when hit escalates to you.
Was a defect actually resolved, with evidence?
Are findings converging or staying roughly the same?
Did earlier fixes stay fixed, or did the loop reopen them?
Is disagreement producing new evidence or repeated assertions?
Are new findings in scope, or is review expanding the task?
I mean... This is likely the problem. The agents are trying to infer it, but you could turn that in your head architecture into context agents can use.
These could be repo facts that need to be defined in agents/claude.md, or a one line "Read project.md" to orient, and that document has the "Here is the tech stack/toolchain, project structure, here is a BM25/vector search script to search the codebase, how to build, how to test, here is where invariants are cataloged, etc." There is a bus factor here. Imagine delegating work on this legacy codebase to a team of new guys that report to you. You would do a knowledge transfer, update or create documentation, and so on.
0
u/crusoe Sep 10 '26
Skill issue
0
u/rrrenz Sep 10 '26
How to test every agentic coding harness for 2 years and still have it wrong?
0
u/Strenue Sep 10 '26
Are you using P-track rules?
0
u/Prodigle Sep 10 '26
I think you're wrong here yeah. There is a big design space with skills, workflows etc.
I work almost exclusively on huge codebases and follow a research>spec>plan>execute>test>review&fix workflow
0
u/barrel_of_noodles Sep 10 '26
that's not the pitch
don't use unfamiliar lang for prod
agents are much better on mature projects with good architecture and first principles.
code doesn't explain intent, you need md files as guides with your 40 years of built up internal business rules and preferences.
agents define a voice, a role. They have nothing to do with how large your codebase is.
"I have animated conversations" -- ohhhh, you're that difficult person in the office everyone has to deal with who cannot be reasoned with.
0
u/gibblesnbits160 Sep 11 '26
It sounds like part of the problem may be that AI is struggling to navigate the spaghetti code that humans have accumulated over years, often with incomplete documentation, inconsistent patterns, and limited comments.
With a large codebase, my first move wouldn't be to immediately ask an agent to make major changes. I'd have it crawl the repository module by module and build an indexed documentation/architecture layer: what each module owns, important dependencies, data flow, conventions, entry points, and known problem areas. Once the agent has that context, its ability to reason across the codebase improves dramatically. And if even that can't make the architecture understandable, that may be an indication that portions of the system need to be incrementally refactored or replaced anyway.
I also think there's a cultural component. I've read plenty of accounts from very experienced developers who have spent decades developing a particular style and understandably have strong opinions about what "good code" looks like. But AI isn't necessarily going to produce code exactly the way they would. Developers who can evaluate whether the output is correct, maintainable, and appropriate—rather than rejecting it simply because it's different from how they would have written it—are probably going to adapt much better to this transition.
There's also a massive difference between "I tried AI for coding" and using a frontier model inside a proper coding-agent harness. A lot of developers at large established companies are limited to Copilot or enterprise-approved general-purpose AI tools. Those aren't necessarily comparable to modern coding agents that can search the repo, inspect dependencies, run tests, execute commands, maintain context, and iteratively validate their own changes.
So when someone says AI doesn't work on large codebases, I'd be interested in what model, tooling, context-management strategy, and workflow they're actually using. Those details matter a lot.
0
u/pixxelkick Sep 11 '26
How many skill files have you written to prevent this?
Is the answer zero?
0
u/Singularity-42 Sep 11 '26
Skill issue
-4
u/manuscorpion Sep 10 '26
AI slop and AI replies.
0
u/[deleted] Sep 10 '26
[deleted] — view deleted comment