[jaggederest]

Basically IDE free since May 2025. I actually reinstalled vscode when setting up a new machine and I think I've launched it twice?

cc -> local automated testing -> github -> PR -> heavy integration tests -> review (github ui, +/-) -> manual test locally -> merge -> deploy -> manual test remotely -> synthetic user testing -> repeat

[noisy_boy]

But what about navigating the code by the call stack? I didn't know that GitHub has a way to do that. Or maybe I'm probably coming across as being dumb enough to be talking about still trying to have a mental model of what calls what.

[r3trohack3r]

Personally, I use a debug agent for that.

I've never used breakpoint debugging, was always a printf debugger. And now an agent can do that loop for me.

Prompt is usually something along the lines of:

>I would expect the behavior of this to be [X] - instead I'm observing [Y]

And the agent will form hypothesis, place printf statements, compile, and scrape logs on loop - each loop ruling out hypothesis or narrowing down what portion of the code is responsible for the unexpected behavior.

It has been able to pin-point the exact line(s) of code responsible every time I've reached for it so far.

[jaggederest]

For what it's worth, generally speaking I read all of the code and keep it in my brain - I have some uncommon assets in that regard like a high reading speed and great memory. `git grep` is the other tool I use often.

I rarely find that the call stack is the limiting factor, to me, and I suppose I do something similar to what you're talking about but just in my head - I know where a file is referenced via imports, what a function does, and what the flow of control is like.

[fruit2020]

Do you not need to use the debugger sometimes? Or can cc debug by itself

[locknitpicker]

> Do you not need to use the debugger sometimes? Or can cc debug by itself

A key feature of AI coding assistants and coding agents is troubleshooting. It turns out that LLMs excel at pattern matching, specially when coupled with feedback signals. It turns out that troubleshooting represents just that. A few years ago people searched the likes of stack overflow to fix problems, and it turns out LLMs can do the equivalent of that much faster.

[simonw]

Coding agents can use debuggers if they need to.

From what I've seen they're more likely to run a python -c "import your_code; your_code.do_stuff()" experiment to figure out what's going on though.

[jaggederest]

I have not used a debugger in anger in perhaps a decade. I write tests, and if that's not enough, I write more tests.

Tests stick around and prevent future problems, whereas the debugger only shows me something once.

[addaon]

But tests show you if a bug is happening, they don’t help you understand the underlying cause of the bug. In a decade, you haven’t hit a compiler codegen issue, a silicon erratum, a race condition, or anything that required actually spending effort understanding the causal path?

[jaggederest]

I don't know what to tell you besides that I've found more, better bugs using comprehensive testing than I ever found with a debugger.

The sole exception to that is that, back in the very early days, troubleshooting IE6 really required a debugger. But everything else, from memory leaks to thread hang issues to deadlocks, testing is better.