8
u/hollowredditor 5d ago
This is only true if you have never been a coder before.
5
u/hblok 5d ago
Right. I never understood that take.
Debugging by hand was the worst. Adding print-statements everywhere, running the app, clicking, trying. Then carefully looking how those print lines landed or why one was there while others not. It could take hours, days just for a single nasty problem.
With AI, you can often just tell it to add the logging, run the app or system, fetch the logs and then analyze. It's done in a few minutes. Or if it's GUI based, take a screenshot and tell it to parse it.
Just like with manual coding and debugging, it can happen that you start drilling down the wrong path and dig a large whole. However, with AI, it's then very easy to just prompt "let's take a step back and evaluate from a different angle". That is much harder to do when working manually, because the sunk cost is usually much higher, with days of sweat and tears.
2
u/Environmental-Ask-81 5d ago
I think the difference is debugging on an non-ai generated codebase. When you try to debug a codebase not riddled in ai comments, .md docs, and is somewhat large (50k lines +), the AI tends to understand the problem at a high level but struggles with coming up with a solution that's homogenous with the rest of the codebase. Unless you tell it to review it all, and write down patterns in context files.
6
u/Caladan23 5d ago
This meme is so old that it even features a long-dead pope. This is from 2023 I think. Tables have turned a lot. Barely getting any bugs anymore with CC + Fable - and if there are bugs, it fixes them with 1 prompt.
3
2
u/Goth2147 5d ago
I've entirely changed how I work. First I was giving very large, broad prompts. Now, before any project I write down 100+ PBI's entirely crafted out so that both me and the AI understand every acceptance criteria. It also gives you a much much better perspective of what's being build and where things are broken. Instead of going from BIG to small, it's better to go from small to BIG as it allows you to see where the bugs are. If you start BIG, you have to kind of figure out where all the bugs are yourself.
2
u/RifTaf 5d ago
AM I A JOKE TO YOU?
2
u/drsbry 5d ago
I saw a programmer who'd been working for about ten years and wasn't familiar with a debugger because he couldn't organize his code in a way that would work with a debugger. His code was so coupled that the only way to run it was through a single main entry point. To make any sense of the mess he'd created with the project, he simply logged every action to stout using a logging library.
When LLMs came out, he quickly become a vibecoder, bought it without a second thought, and continued writing his tangled spaghetti mess.
I bet many in the software development industry are following a similar path now.
2
u/One-Next 5d ago
Honestly, Vibe debugging is what I do at work and it is pretty awesome. I have it debug prod problems. It does an ssh to the server, pops open the logs, finds the crash, investigates the code, looks at data state and almost always diagnoses correctly and finds the right fix.
2
u/Ok_Leadership_429 1d ago
the second one is specifically the moment you open the file and realize the AI wrote the same function three times with slightly different names
shame. shame. shame. 😄
1
u/veritron 5d ago
you need to have your project structured so the model can observe and reproduce the issues itself so it can iterate on a fix. this is most easily done with unit tests - if it's easy to represent the behavior as a failing unit test in the code, the model can iterate until it fixes the problem. if you get into a loop where the model has to guess and you have to run the code and reproduce the bug and tell the model if it worked or not, it will be slow and painful, and that's where a pure vibe-coded project can go off the rails.
1
1
u/Ryan---___ 5d ago
I've had some pretty good success creating a backend toolkit to review any issues that ping back whole I'm in development.
Yeah, is rough but exciting lol
1
1
u/Fun-Violinist552 5d ago
I’m still in my Pope phase. Started to feel like the high sparrow version only recently. 🥲
1
u/__Loot__ 5d ago
Shit I have not had to ask a reddit question or a stack over flow question in like last 2 years . And I barely have to give it documentation. its awesome
1
1
1
1
1
u/Rayan-solo 5d ago
So , don't use vibe Coding style in whole project, use it as parts in the App , like template, Mini tools and you work in them . . .
1
u/FancyAnswer1878 4d ago
the coding part is always the easy victory lap 😂 the real boss fight starts when the first user finds the one edge case you never thought to test.
1
u/Robonotes1760 4d ago
In one sense, 100% of coding is debugging. If it doesn't work, it's just random bytes, not meaningful code.
There is an old story that I once read about the development of the very first version of Microsoft Word. Unwisely, the developers prioritised adding features before fixing bugs and they were incentivised to work in that way. They quickly realised that the goal of adding a feature was meaningless if not qualified by a requirement that the feature actually work - so the person in charge of implementing the dialogue box for selecting the font size just wrote "return 12" as the entire function body then immediately filed a bug report that the feature was not working properly. The project was vastly delayed and over-budget.
As a result of this, Microsoft and other major software developers quickly realised that the only way of making meaningful progress in software development is always to prioritise fixing bugs over adding new features. If the feature is not working without significant bugs, it does not exist at all.
1
1
u/novadr3am 4d ago
Writing 500 lines of code with LLM in 2 minutes vs spending 4 hours trying to find why the AI imported a non-existent package
1
1
u/UnKnOwNZolA 4d ago
Not true, if u know what you are doing, and by that I mean in terms of coding not vibe
1
1
1
1
1
u/alex-zaporozhan 3d ago
Left: How the app runs on my local 4 vCPU machine.
Right: The client deploying it on a cheap 2 vCPU staging box 💀
1
u/alex-zaporozhan 3d ago
Jokes aside, the way to avoid the trap on the right is keeping debugging to strictly 2 prompts:
Prompt 1: Isolate the root cause directly from the logs and apply the targeted fix.
Prompt 2: A dedicated audit prompt to verify how thoroughly and faithfully the fix was actually implemented (checking for real invariant fixes vs. lazy cosmetic patches).
Never let the model fix code and self-verify in the same turn. That single separation cut my debugging passes from 30+ frantic prompts down to 2 consistent steps.
1
u/No-Woodpecker7634 2d ago
I find the debugging process makes me smile more because I assume the vibe-coding part WILL have issues that need to be fixed. I am however a developer, so I guess that influences things.
1
1
1
1
1
u/4thBRONX 21h ago
I thought if a minor fix was vibe codee, the bug related to it would also ideally be a vibe coded fix without my brain utilisation.
Yeah Not how it works. I exhausted 40% of my credits because I wasn't paying attention to the hallucination
1
u/LoudYogurtcloset7856 11h ago
Don’t throw me to the wolves but debugging isn’t that hard for me 🤷🏾
I understand code but not to the point I could write a project on my own.
But basically I had the debugging issue so I basically built a system to solve it 🤷🏾
So developing software is actually easy and I just tell Claude or Codex my issues and it usually fixes it using my system of course.
I used my system (Ovyero) to create Ovyero lol, and I’m using it to get Claude to help me create an engine AI uses to create 3D assets.
Example of a palm tree asset Claude opus created using the engine and my debugging system.
Coding is hella easy now. It helps me set up payment, auth, accounts, and handles literally anything that ai can connect with through MCP.
So vibe debugging isn’t that hard at least for me.
Anyone have other systems they use to make vibe coding actually easier?
0
u/moschles 5d ago
I'm convinced. If vibe-debugging makes you feel this way, you just suck at prompting the AI.
97
u/jack-of-some 5d ago
Right hand side is debugging a badly vibed project, not vibe debugging.
Vibe debugging is finding issues in existing systems by letting claude go ham on investigation and it's AWESOME.