DEV Community: Benjamin Savoy

#2 - Going to second base: know your boundaries

Benjamin Savoy — Tue, 10 Feb 2026 17:38:38 +0000

... or you'll end up with a monkey patching your code.

So, we've got to get intimate...

For today's cautionary tale, let me draw a parallel. You've gone on a few dates, all is going well, but you're not sure if you should go home with your date. After all, you hardly know them. How do you navigate that?

Over the last couple of articles, we've gotten acquainted with the code that the LLM wrote, but we haven't read a single line yet. If there were huge red flags, maybe we've spotted some already, but could there be something more sinister hiding in plain sight? Is it time to open up the files and look at actual code?

Well, hopefully you've sorted out the structural issues with your project, so let's go and ask a few probing questions...

What was your name again?

Ouch. If I had a dollar for every time I forgot the name of someone that I should know... But naming things turns out to be quite important for us too. Let's grab a poorly written Python method signature as an example:

def process_order(order_data)

What was his name again... Jim, Jeff, Geoff, Jean? Well... you get what I mean, hopefully, and I wouldn't fault you for not knowing what this method does, either.

@dataclass
class Order:
    customer: Customer
    items: list[OrderItem]
    discount_code: DiscountCode | None = None

@dataclass 
class ProcessedOrder:
    order: Order
    total: Decimal
    shipping: Decimal
    processed_at: datetime
    discount_applied: DiscountCode | None
    inventory_reserved: bool

class OrderProcessor:
    def __init__(
        self,
        discount_rules: DiscountRules,
        shipping_policy: ShippingPolicy,
        inventory: InventoryService,
    ):
        ...

    def process(self, order: Order) -> ProcessedOrder:
        ...

Without even writing any of the implementation, I've already given you enough data to have a plausible opinion about what it should do. You could then likely test it without really looking at what's inside, and that's what matters. If you know the business logic, and have detailed signatures like we have above, then you're ready to move on to the next step!

Size matters

Well, we've got a process method with some boundaries now, but we're still not looking at instructions. Let's assume process is a large method. Inevitably... it might well be if it's trying to do too much at the same time.

So we've got to put some limits too, and maybe we don't want the process method to worry about too many things at once. Maybe just calling different methods that worry about individual elements like discounts, shipping, and so on.


    def _calculate_total(self, items: list[OrderItem]) -> Decimal:
        ...

    def _apply_discount(self, total: Decimal, code: DiscountCode) -> Decimal:
        ...

    def _determine_shipping(self, total: Decimal) -> Decimal:
        ...

    def _reserve_inventory(self, items: list[OrderItem]) -> bool:
        ...

Phew. Now everything's settled. That's a much better structure to see in your generated code. If it feels like a method is a bit long, or doing more than one clear thing, it probably needs looking at. Even without reading any of the code, I can tell you that I'd expect something looking roughly like the above for such an order processing class.

It pays to have taste

Also, did I mention how nested loops and continue / break keywords are a pet peeve of mine? Yeah, that's a red flag too. You don't want to be nesting too many things at once. In code, or dating. Believe me.

I did mention above that I'd expect a few methods to be present to break the flow, but in the end it's experience talking. You have to read and write code a fair bit to get there, but that's part of the beauty of this job. However, when you do refactor or write code, there's a few constraints you can put on yourself, which may be helpful in getting to a better state and therefore learn as you do.

def get_eligible_totals(self, orders: list[Order]) -> list[Decimal]:
    totals = []
    for order in orders:
        if order.discount_code is None:
            continue
        if not self._discount_rules.is_valid(order.discount_code):
            continue
        total = Decimal("0")
        for item in order.items:
            if item.qty <= 0:
                continue
            if item.price <= 0:
                break
            total += item.price * item.qty
        if total > 0:
            totals.append(total)
    return totals

What's going on there? Well, you tell me. But if that hurts your brain, don't spend too much time on the above and read what follows:

def get_eligible_totals(self, orders: list[Order]) -> list[Decimal]:
    eligible = [o for o in orders if self._has_valid_discount(o)]
    totals = [self._calculate_total(o.items) for o in eligible]
    return [t for t in totals if t > 0]

def _has_valid_discount(self, order: Order) -> bool:
    ...

def _calculate_total(self, items: list[OrderItem]) -> Decimal:
    ...

Did you notice the bug in the first method, too? In the original, break exits the inner item loop entirely. So if the third item has a negative price, items four, five, and six never get counted. Knowing what your language allows (in this case list comprehensions) and avoiding smelly keywords (global, break, continue, etc...) will get you there, at least some of the way.

`datetime.now()`, I hardly knew thee

So now that we've got a feel for structure and taste, let's talk about the things hiding deeper. The places where your code reaches out and touches the real world.

Time is the classic offender. A datetime.now() buried three layers deep means your code behaves differently every time you run it. Randomness is the same problem wearing a different hat. Configuration is a bit more predictable but can still sneak up on you. Then your tests start to break because it's January and someone decided to compare the months in a date object. I wish I was making this up.

IO, filesystem, network calls, external services, mutable state, user input, build environment... they're all boundaries too. Some obvious, some less so. But they all reduce to one question: can I control this from a test? If you can't swap it out, it's not a boundary, it's a leak. And would you trust a monkey with a wrench to fix it? Well, I wouldn't, and I wouldn't monkey patch it either.

Oh, and keep your eyes open for those red flags: nested loops, giant methods, untyped data, hardcoded values, hidden dependencies. They're the crumbs which feed the little bugs...

Robots have no taste... or if they did they'd be brutalists.

Someone else did it wrong at least once in the training data, and therefore, you must now suffer the consequences.

And hey, if you can explain those key common problems to your LLM and configure a competent software engineer AI agent as a result, you'll probably save yourself some time. But agents are a topic in and of their own which is better addressed in its own post.

Oh, did you notice how I didn't address the missing Clock in the OrderProcessor class? Well, that's something you'd want to inject in C# or other languages, but sometimes, no matter how much you think a particular Dutch person is wrong, there's no need to get angry and the best course of action is just let them drive slowly on the motorway. They're on holidays, and you can't worry about every time someone else is wrong.

Same goes for (some) Python conventions. So relax, chill out, and go along with freezegun.

Until next time...

~ Ben

#1 - Spot problems before reading any code

Benjamin Savoy — Wed, 21 Jan 2026 20:06:21 +0000

Last week we started with a strong claim: You don't need to read every line. But now we've got to substantiate it. So, today, I'll show you a few ways to spot issues without even looking at the code. That's particularly interesting with LLMs as you might want to try coding in a language that you don't even know yet. I do believe that it's entirely possible, as long as you have an adequate amount of software engineering experience. I have myself experimented with game development in Rust (assisted by Claude), but more on that later with a practical example...

Structure is documentation

You've probably already heard of MVC (model, view, controller) which is a popular way to organise web applications. It does separate the concerns in three distinct buckets. There are of course many more approaches, all with different advantages for different kinds of software. The goal here isn't for me to preach what the best approach is, but that whatever approach is used should be obvious from looking at the file tree.

For example, let's take a basic MVC webapp filetree:

MyApp/
├── src/
│   └── MyApp.Web/
│       ├── Controllers/
│       │   ├── HomeController.cs
│       │   ├── OrdersController.cs
│       │   └── UsersController.cs
│       ├── Models/
│       │   ├── Order.cs
│       │   ├── User.cs
│       │   └── ViewModels/
│       │       ├── OrderSummaryViewModel.cs
│       │       └── UserProfileViewModel.cs
│       ├── Views/
│       │   ├── Home/
│       │   │   └── Index.cshtml
│       │   ├── Orders/
│       │   │   ├── Index.cshtml
│       │   │   └── Details.cshtml
│       │   ├── Users/
│       │   │   └── Profile.cshtml
│       │   └── Shared/
│       │       ├── _Layout.cshtml
│       │       └── _ValidationScripts.cshtml
│       ├── Services/
│       │   ├── IOrderService.cs
│       │   ├── OrderService.cs
│       │   ├── IUserService.cs
│       │   └── UserService.cs
│       ├── Data/
│       │   ├── AppDbContext.cs
│       │   └── Repositories/
│       │       ├── IOrderRepository.cs
│       │       └── OrderRepository.cs
│       ├── wwwroot/
│       │   ├── css/
│       │   ├── js/
│       │   └── images/
│       ├── Program.cs
│       ├── appsettings.json
│       └── MyApp.Web.csproj
├── tests/
│   └── MyApp.Tests/
│       ├── Controllers/
│       ├── Services/
│       └── MyApp.Tests.csproj
├── README.md
├── Makefile
├── docker-compose.yml
└── MyApp.sln

How much can you infer from just the file tree? Hopefully a fair bit already. Requests likely come from Controllers. The state should hopefully be self-contained in Data. Services handle the business logic - hopefully in a stateless manner since we have a separate Data directory. Views are the glue between the Controllers and the rest, indeed they map 1:1 so it's easy to track what goes where.

Now you could decide that things that map 1:1 with each other should be in the same folder, and you wouldn't be wrong. The main point here is that structure should make it obvious where to look at the very least.

So, it runs on your machine, but what about mine?

You may have noticed a few more things at the root of this folder, which are quite helpful here.

Seeing a Makefile makes me hope that I might find a way to build, test, and deploy this application. And hopefully the README.md file would provide the rest of the context needed for those tasks. It gives me hope that this repository might be self-contained and have all the instructions that I need to run it. However, remove the Makefile, and it's starting to look dicey. At best it seems like I'd have to read the whole README and copy paste commands from there. It does seem like a bit of a hassle.

Structure is documentation, but what about documentation?

Okay - I have a chip on my shoulder here. I hate to repeat myself. However, some people (including most LLMs) love to write a lot of documentation, and there might even be some people who enjoy reading it! Reality is, though, that if your file tree doesn't make sense, and then you have to look at documentation, you've already lost a fair chunk of time figuring how things are supposed to work. You're losing a lot of clarity about where you should store new code. And that does compound quite quickly, every new hire, every time you forget about an old legacy repository, the process repeats itself.

Moving and restructuring files around is usually the first step I take when faced with a complex legacy codebase, because it lets me tackle self-contained problems one by one. You're then no longer dealing with spaghetti, but small self-contained problems. And if you're not, the (hopefully) few files that really don't fit might well be the main problem you've got to tackle... leaving the rest mostly as-is.

Debugging without reading, really?

I've tried some game development in Rust, without knowing anything about the language. Claude Code did most of the work and as I troubleshoot things, I kept noticing that my previous engineering experience was applicable even if I didn't read any code. I was merely looking at the file tree, Claude Code, and launching the game every now and then.

But what I found out is that most bugs that arose as the game became a bit more complex were simply due to a lack of separation of concerns.

Every iteration, I'm adding a new UI element, a new kind of object in the game, a new mechanic, but it seems that LLMs are not that great at designing things iteratively like that with an eye for the future. And then, boom, I could click on things in game but the map would jitter all around the place, pop ups wouldn't be displayed, and some buttons I just implemented were not working anymore. It was a nightmare, but then I looked at the file structure.

Odd, I have a new file for the game settings panel I just added. I have a file for the map generation... but it's all in the same folder and there's no UI module. Let alone multiple UI modules. Every file was trying to define a bit of the UI and ultimately ended up being inconsistent.

A simple prompt to modularise the game, including a UI module with several files each dealing with a separate part of the UI and a reminder to check for inconsistencies quickly dealt with the buggy UI and Claude went on implementing many more features with way fewer bugs from that point on.

Structure is your map (and a few red flags)

Before I leave you for today, let me give you a few red flags that you can quickly check and apply to your output, and see if it helps you iterate faster with LLMs! Here's what could be a sign for concern:

No clear separation of concerns
Inconsistent names
Large files (500+ lines)
Missing/mismatched directories (for tests and others)
Lack of build/run automation and instructions
No clear entry points (APIs, CLI, DBs)

If you can't see the architecture from the file tree, something's wrong! Until next week...

~ Ben

#0 - You don't have to read every line

Benjamin Savoy — Tue, 13 Jan 2026 18:03:03 +0000

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 I don't think many of us 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 what if it was all AI-generated?

Hopefully, by now, you're starting to catch my drift... We've all seen horrible legacy codebases, intern code, and things that we wish we'd be able to forget. But that's not the end of the world, because...

Legacy Code Runs the World

Legacy code is a good problem to have. That may not resonate with many of you, but having legacy code means that the company has survived long enough to deal with code that has fallen apart over time. And if you're tasked with migrating it or altering it, it probably means that there's still value to be extracted.

We've all heard the tales of COBOL running on a mainframe to this day in many banks and Fortune 500 companies... and while one could speculate about their eventual downfall, the size of their revenue is undeniable.

The Self-Driving Car Problem

Let's hop into another parallel for a second to illustrate a perception problem we might face. If you were given a fully autonomous car that you knew was just as safe as your driving, would you let it drive you around? What if it was ten times safer, or even a hundred times?

For contrast, what if I proposed to replace all other cars on the road, with self-driving cars that are proven to be 25% safer than the average driver. Would you accept to drive in such conditions?

I don't know what your answers are, and they might be very rational... but we have a human bias to overestimate how much control we have on the risks that we can affect through our behaviour. Therefore, it's quite possible that most people would refuse to be driven by an autonomous vehicle, even if they were rationally convinced that it would drive as safely as they personally would.

So... the question is then, would you let a LLM code for you?

LLM Code Is Just Code You Didn't Write

That brings us to my first real proposal. And if you're on the fence about LLMs, maybe you'll just have to try it out for yourself. Give one of the best and latest coding models a self-contained task in your codebase. Plan with it, and work with it to clarify the requirements. Then, once it produced a first version of the code, explain your coding standards and test requirements, and ask it to review itself. And finally, let it open a pull request, and see for yourself. Would you be mad if an intern wrote this? A junior engineer? One of your peers?

You'd be right if you felt that this was a bit mechanical, after all you had to have a conversation about requirements, and also needed to explain coding and test standards. But don't worry, that can also be automated later on, and I'll explain how in later articles.

So far we've just covered common thought experiments about legacy code and AI... but if you're having trouble letting go of controlling every line of code you're writing, you're not alone. I refused to use code generation much, until a very tight deadline came across my desk, and in a last ditch effort, I spun up Claude Sonnet 4.5 and worked a few late nights... and the backlog disappeared.

Reviewing it, I realised I wouldn't be terribly disappointed if a junior or mid-level engineer wrote a PR like Claude Code did. Realistically, it was not too bad of an effort compared to what I could do at 9pm. And thus, the project was back on track, and I was a convert.

The Real Questions

After this experiment, hopefully you'll have seen some passable code being generated, like I did, and you're wondering what's next. After all, this might have just been an easy task, and the code is not as good as what you'd have written anyway.

Then we have to ask, could the output be as good as yours or mine? Well, probably, given an unlimited amount of time iterating over the code and gathering feedback.

But then, can we go much faster with those 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 some difficult questions. For example, if you're dealing with legacy code, would you always rewrite the entirety of the solution for each migration? That would often be a waste of time. Therefore, that new tooling requires us to be a bit more creative in the way we validate the output.

Fundamentally, at some point, it doesn't matter who wrote it. It matters that it works. But how do we know that it works? Well, that's where I will share with you some of my experience dealing with legacy code... but that will be for another post.

What's coming

I hope that this has been a pleasant introduction to the challenges that one might face when coding with LLMs. It may be a bit basic for some, and I'm sure you've thought some of those things, but now that we're all on the same page, here are a few things you can expect to see in the next few weeks:

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

See you next week for more.

~ Ben

DEV Community: Benjamin Savoy

#2 - Going to second base: know your boundaries

So, we've got to get intimate...

What was your name again?

Size matters

It pays to have taste

datetime.now(), I hardly knew thee

Robots have no taste... or if they did they'd be brutalists.

#1 - Spot problems before reading any code

Structure is documentation

So, it runs on your machine, but what about mine?

Structure is documentation, but what about documentation?

Debugging without reading, really?

Structure is your map (and a few red flags)

#0 - You don't have to read every line

Every day is your first day

Legacy Code Runs the World

The Self-Driving Car Problem

LLM Code Is Just Code You Didn't Write

The Real Questions

What's coming

`datetime.now()`, I hardly knew thee