Claudio Lassala's Blog

I’ve been thinking about a question I’m hearing more often lately—sometimes out loud, sometimes between the lines.

If AI can write software, and the software “works”… does it really matter how the code reads?

It’s tempting to say no.

Because if the problem is solved, the value is delivered, and the user is happy… what’s left to worry about?

But I keep coming back to the same answer I’ve used for most of my career:

It depends what kind of problem we think we’re solving.

The “one-off” exception

There are absolutely situations where code quality matters less.

• A one-time data fix
• A temporary script
• An emergency workaround to keep the business moving
• A spike or proof-of-concept that we already expect to throw away

If we’re truly going to throw it away, then sure—optimize for speed and learning.

In those moments, the bar is: Did we solve the immediate need safely enough to move on?

But here’s the catch.

Most software doesn’t stay a one-off.

The thing we “just needed for now” becomes:

• a reusable utility
• a core workflow
• a dependency
• a pattern we copy into other parts of the system

And once it sticks around, code quality becomes a must-have.

It becomes the cost of doing business.

“But humans won’t read it—AI will”

This is where the conversation gets interesting.

A newer version of the argument goes like this:

If AI is going to work with the code anyway… maybe humans won’t need to read it.

I get the impulse.

But in practice, I’m seeing the opposite:

Good code helps AI do better work.

Not because AI needs “pretty” code.

Because AI—like humans—works from the signals we give it.

And code is full of signals.

Tests and naming are signals

When a system has:

• clear tests that describe behavior
• method and variable names that reflect intent
• domain language that matches the business

…an LLM has a much easier time building an accurate mental model of the system.

That’s the same reason humans do better work in well-written codebases.

When I walk into a messy system, I spend time translating.

• What does this variable really represent?
• Why does this method exist?
• Which edge cases matter?
• What’s the business rule hiding inside this loop?

An AI agent has to do that translation, too.

If the only thing it can see is “computer language,” it will describe the system at the computer level.

But if the code and tests are written closer to natural language—closer to business intent—then the system can reason at that level instead.

The difference between describing the “how” and the “why”

Here’s a simple example of what I mean.

If the code is messy, the best summary you’ll get from an LLM is something like:

• “This function iterates through an array of integers and filters values…”

That might be technically correct.

But it’s also useless for a non-technical stakeholder.

If the code is written with intent, the summary can shift to something like:

• “This logic scans a customer’s open invoices and selects the ones eligible for payment…”

That’s the same algorithm.

But now it lives in the world the business actually cares about.

And that’s the world where good decisions get made.

Comments aren’t the fix—names are

One of the easiest traps (especially with AI-generated code) is:

• write procedural code
• then paste a few comments on top

Comments help.

But comments don’t create structure.

The habit I trust more is the one we’ve been practicing for decades:

• turn comments into names

If you feel the urge to write a comment like:

• “// Validate the customer’s eligibility”

That’s a hint.

Make it a method.

ValidateCustomerEligibility()

Give it a name that expresses intent.

And now both humans and AI have something sturdy to hold onto.

Guardrails for AI-written code

So when I think about “AI writing software,” I don’t think the answer is:

• Let it generate code, and we’ll just ship whatever works.

I think the answer is:

• Let it generate code inside the same guardrails we expect from humans.

Guardrails like:

• Use domain language (DDD’s ubiquitous language)
• Write tests that describe behavior and edge cases
• Prefer intention-revealing names
• Keep functions small enough to hold in your head
• Optimize for the next change, not just the current one

And this last part is where I’ve seen the most significant payoff:

When user stories are written for humans, and code is written to match those stories, AI agents can do better pull request reviews.

Not “code coverage” reviews.

But feature coverage reviews.

Value coverage.

They can spot:

• what wasn’t implemented
• what scenarios are missing
• what tests don’t reflect the story
• what assumptions aren’t written down anywhere

That’s a higher level of assistance than “fix my syntax.”

And it’s only possible when we give the AI clean signals to work with.

The real question

So maybe the question isn’t:

• Does code quality matter when AI writes software?

Maybe the better question is:

• What kind of future do we want this code to have?

If it’s disposable, fine.

But if it’s going to live—if it’s going to evolve—then quality is still the thing that makes change affordable.

---

Takeaway I’m sitting with: Code quality isn’t just for humans. It’s the set of signals that helps both humans and AI understand what a system is really trying to do—and that understanding is what makes the next change safer, faster, and more aligned with the value we meant to deliver.