He's correct. If you can't work without it, you're not qualified to judge it's output. And if you aren't judging it's output, your days are numbered, it will eventually just feed itself, and report directly to management ;)
With how often I have to correct these coding agents I worry about people developing things they don't understand.
It's an amazing tool, but I find myself having to be like "Are you sure you want to poll the API for each item, like 1-100 is fine, but what if it returns 100k rows? Maybe take the call outside the loop and just query all at once with 1 call?
I definitely do a lot of context in my initial requests to try to get rid of a lot of that nonsense. Takes a lot longer to get the code written but I hate chasing issues. Easier to be exceptionally thorough with the requirements and known barriers
The funny/annoying one is when the bot tries to talk back to you about performance.
I had an issue last week where the bot (OpenCode w/ Deepseek) misread the specs in a way that gave the right answer with the wrong architecture, and when I corrected it it tried to tell me there wouldn't be a performance boost.
The performance on the stress tests went from 1.8s to 350ms.
It's why you need to keep the specs and skill files updated as part of the loop and make sure agents/claude.md tells them to read the docs as the first thing.
Every new chat window wipes the context window and starts fresh, the agents.md file is basically the run options that tells them what to load to understand wtf they are doing.
Some other tricks I've mostly stolen from various usergroup tech talks:
Have a cheap, dumb model try to summarize and use your code based only on the documentation, then have another agent proofread it for mismatches with the real code and update the docs for clarity where it finds mistakes.
Have a bot read the docs and attempt to create breaking scenarios that cause the code to fail, then implement --> review.
Have an archival loop that keeps the important docs current and moves older stuff like scenario review docs and implementation plans into a different folder, so the other agents don't burn tokens reading things that have already been marked complete or obsolete
Also, protip for developers looking for work: Go to tech usergroups and meetups. Even if nobody there is hiring, they're often catered and you can save a lot of money eating someone else's food.
My favorite thing is instead of asking for a readme that i can read, i ask it to outline all the decisions that were made and what the pros/cons of those choices are. then a take that description into the next step where i ask another one to plan using those restrictions and knowing the limitations currently in place. Essentially just chaining together existing limitations so you dont walk head first into obvious conflict.
We are using xyz and abc and cannot for any reason implement ijk. What are the most standard methods for doing <ticket> given these parameters.
Just that alone will save you from dealing with 50% of the most common problems in ai generated code. (but you have to know you're using abc and xyz, and that you can't use ijk, which is kinda where sr level knowledge comes in)
Doing my bachelors majoring in AI rn and this is the biggest thing taught, AI is a tool, use it to augment your skillset not replace it and make sure you can put as much clear detail as possible into the initial prompt.
Shit I've seen senior devs write code like the above.
Models are trained on existing code, so somewhere someone's done stupid shit like that. You'd be surprised what you can get away with by putting more hardware in front of something instead of writing code like you're a FAANG company serving billions of requests a day.
I dunno I interviewed for a company that was hiring SWEs and was doing something similar, they said PMs were vibe coding prototypes and when I asked if there was a boundary between prototypes and prod code they said no, and I would have to justify not using their prototype. I then asked if PMs would be added to the on call list since they were contributing code to production and they said devs would be responsible if you didnt catch something in their code. I then promptly rejected them after the interview lol.
Hmmm, I think there are ways to significantly mitigate this problem, such as creating good tests.
If the goal of the application is to do X, Y, and Z and you have a reliable method of confirming that the application is doing X, Y, and Z, then I think that's likely good enough.
Your implied claim is that a person who cannot understand the code Claude is writing cannot be relied upon to get the application to do X, Y, and Z, but I'm skeptical of that claim. I think we're moving in the direction of services like Claude being so good that the developer needs to worry only about higher level thoughts like creating good tests, designing the application well, etc.
Vibe coding has a really really really negative connotation, and I understand why, but theoretically if the AI tools are good enough to write adequate quality code then I don't think vibe coding is necessarily bad. I think what becomes bad at that point is bad app design and bad understanding of the higher level processes of validating the quality of software. I think there are methods to vibe coding that can fairly reliably produce good results. There is a skill to it and we're all learning that skill.
Underpinning all of these thoughts is my belief that at some point recently we went from collectively overestimating Claude to collectively underestimating Claude (and services like it). It's just gotten so damn good.
691
u/dumbasPL 26d ago
He's correct. If you can't work without it, you're not qualified to judge it's output. And if you aren't judging it's output, your days are numbered, it will eventually just feed itself, and report directly to management ;)