Vibecoding
Build for the vibe, debug later
Start new thread

Do you actually read the code your AI agent writes, or just skim the diff and move on?

by•

honest self-assessment time. when an agent finishes a task and shows you a diff, what actually happens?

for me it depends entirely on the size. under ~30 lines I read every line. past that I mostly skim for anything that touches auth, payments, or migrations and trust the rest if tests pass. I know that's not a great policy, it's just the realistic one given how much code moves through these sessions in a day.

curious where everyone else draws the line. is there a file size or file type where you always stop and read carefully no matter how rushed you are? and has skipping the read ever actually bitten you, or has it been fine so far?

55 views

Add a comment

Replies

Best

I do not know how to code properly, and first I wanted to write code for my plugin, but even after multiple attempts across several days, it didn't work properly (I think that I clearly described the features I wanted).

Since I didn't know which part to fix, I decided to use AI to teach me the code so I can overview what I am doing and understand it.

But if I were an experienced programmer, I would just ask AI where the particular parts in the code are responsible for the feature, and I could change them later. Once the man has the knowledge, everything is easier :)

I think it depends more on the task being done.

For example, if it's UI work, I just test if it does the job and if it's fast. If it doesn't work or isn't fast, it obviously means either the code should be reviewed or the foundations aren't good. If it passes all my manual tests, I don't care about its structure. Code and structure are commodities right now and can be refactored as many times as we want without much human time.

The exception to this rule is backend work. There are security concerns, the risk of losing data, and a lot of other concerns that make me move slower when doing it. But we also have distinct backend environments and proper software engineering tasks to help us avoid missing something there.

I was a strict defender of code quality before LLMs and had the opinion that the quality of the product was directly related to minimal and proper abstractions in code. But I think we're now in the “industrial revolution era,” and the goal here is to make products abundant by using as many machines as needed, along with newly invented QA processes.

Products made by hand by a master of the craft will probably be of higher quality, but they will become expensive and part of a niche.

the one that's bitten me is migrations, but not in the way you'd expect - it wasn't a bad migration, it was a fine migration that silently dropped a default value on a column nobody flagged because the diff was 200 lines of "routine" schema changes and I skimmed past it. now my rule is less about line count and more about blast radius: anything that touches a schema or a payment path gets read regardless of size, even if it's one line. everything else I trust tests for. the uncomfortable truth is size is a bad proxy for risk, a one-line change to a migration is scarier than a 300-line new UI component.

I've been programming about 10 years now, so I just have a habit of wanting to know what the LLM has produced.

I at least skim the code unless it's something trivial.

And for larger pieces of code I ask the LLM to audit and review it and I analyse the review output.

It's definitely easy to get comfortable especially as these models get better and better but knowing how to code is a valuable skill to have.

@galdayan blast radius over line count is a better rule honestly, I'm stealing that framing. the "fine migration that silently dropped a default" example is the scary part though - that's not even an agent mistake in the traditional sense, it's a correct-looking change with an invisible side effect that only shows up later as a data problem, not a code review problem. makes me think the real fix isn't reading harder, it's forcing schema changes into their own isolated diff that can't hide inside a bigger routine-looking commit

 yeah exactly, and I'd go further - once it's forced into its own diff, you can actually write a dumb checklist for it ("does this change any column default, nullability, or type") instead of relying on a human to notice something buried in 200 lines. the isolation is what makes the review mechanical instead of hoping someone's attention doesn't wander on line 140.

@Samuel that "ask the LLM to audit its own output" step is underrated - I do the same for anything over maybe 50 lines. Curious though, do you ever catch it agreeing with itself too easily on the review pass? Like the audit is written by the same model that wrote the code, so it sometimes just confirms its own assumptions instead of actually challenging them.

@tgloureiro the "commodities right now, refactor later" take on UI code makes sense to me for throwaway stuff, but doesn't it get expensive the moment that UI code needs to survive a redesign? refactoring is cheap when you're touching one component, less cheap when three other screens quietly depend on the exact shape of the thing you're changing. curious if you draw a line between "disposable prototype UI" and "UI that's actually load-bearing for the product," or if it's the same low-scrutiny treatment either way