You don't have to read every line

Source: Dev.to

Every day is your first day.

Allow me to use your mind for a second for a thought experiment.

If you’re starting a new job contributing to a codebase, would you read every line in existence before pushing a change? Or every line in the module you are changing? Or every line of the function that you’re supposed to alter?

The degree of precision required will vary depending on your task, of course, but most of us don’t have the luxury of reading every line that exists in the project before getting started on a change.

Now, what if I told you that the code was written by the best software engineer in existence? Would it ease your mind? What if it was all written by an intern—or generated by an AI?

Hopefully, by now you’re catching my drift… We’ve all seen horrible legacy codebases, intern code, and things we wish we could forget. But that’s not the end of the world, because…

Legacy Code Runs the World

Legacy code is a good problem to have. It means the company has survived long enough to accumulate code that has fallen apart over time, and if you’re tasked with migrating or altering it, there’s still value to be extracted.

We’ve all heard the tales of COBOL running on mainframes in many banks and Fortune 500 companies. While one could speculate about their eventual downfall, the size of their revenue is undeniable.

The Self‑Driving Car Problem

Imagine you’re given a fully autonomous car that you know is just as safe as your driving. Would you let it drive you around? What if it were ten times safer, or even a hundred times safer?

For contrast, suppose we replace all other cars on the road with self‑driving cars proven to be 25 % safer than the average driver. Would you accept to drive in such conditions?

Most people have a bias to overestimate how much control they have over risks they can affect through their behavior. Consequently, many would refuse to be driven by an autonomous vehicle, even if they were rationally convinced it would be as safe as—or safer than—their own driving.

So… the question is then, would you let an LLM code for you?

LLM Code Is Just Code You Didn’t Write

That brings us to the first real proposal. If you’re on the fence about LLMs, try it out yourself:

1. Give a state‑of‑the‑the‑art coding model a self‑contained task in your codebase.
2. Plan with it and clarify the requirements.
3. Once it produces a first version, explain your coding standards and test requirements, and ask it to review itself.
4. Let it open a pull request and see for yourself. Would you be mad if an intern, a junior engineer, or one of your peers wrote it?

It may feel mechanical—you have to converse about requirements and explain standards—but that can also be automated later.

I was skeptical about code generation until a tight deadline forced me to spin up Claude Sonnet 4.5 and work a few late nights. The backlog disappeared. Reviewing the output, I realized I wouldn’t be terribly disappointed if a junior or mid‑level engineer wrote a PR like Claude’s code did. It wasn’t a bad effort compared to what I could do at 9 pm, and the project got back on track. I became a convert.

The Real Questions

After that experiment you might wonder:

• Could the output be as good as yours or mine? Probably, given unlimited time to iterate and gather feedback.
• Can we go much faster with these new tools without losing much quality? I think so—it’s just that you don’t have to read every line.

You’ll have to ask yourself difficult questions. For example, when dealing with legacy code, would you always rewrite the entire solution for each migration? That would often be a waste of time. New tooling requires us to be more creative in how we validate the output.

Fundamentally, at some point it doesn’t matter who wrote the code; what matters is that it works. How do we know it works? That’s a topic for another post, where I’ll share more of my experience with legacy code.

What’s Coming

I hope this has been a pleasant introduction to the challenges of coding with LLMs. In the coming weeks you can expect:

• Spot problems before reading any code
• Read code faster and catch more issues
• Write tests that verify behavior
• Automate the feedback loop so the LLM reviews itself
• Remove yourself as the bottleneck

See you next week for more.

~ Ben