Claudio Lassala's Blog

Last week, I gave an Improving Talk about something that’s been on my mind for a while now: the real bottleneck in software development isn’t typing speed. It’s everything around the code.

You can watch the full recording here…

The Overwhelm Is Real

I started the talk by acknowledging something we’re all feeling. Two years ago, we were drowning in new JavaScript frameworks. Now? It’s AI tools. Every day, there’s a new tool claiming to be “the actual way” to do something—as if adding the word “actually” makes it more legitimate.

But here’s what I’ve learned: nobody has this figured out. Not me, not the people shouting on social media, not anyone. It’s moving too fast.

So what do we do? We take a step back. We stop polishing the Ferrari in the garage and actually take it for a drive. We pick one tool, one aspect of that tool, and we use it to solve a real problem. Then we rinse and repeat.

The Real Bottleneck

The talk centered on a problem I’ve seen for decades: we show up at Sprint Review with something we built, and the stakeholders say, “That’s not what we need. Start over.”

It’s not that we’re typing too slowly. It’s that we’re building the wrong thing.

The friction is in the communication layer—the miscommunication layer. We hear one thing, design something else, spend weeks implementing it, and then discover we were solving the wrong problem. Now with AI, we can go in the wrong direction faster, which just means we get more lost.

From Fuzzy to Focused

I walked through my approach: record every conversation with stakeholders. Say things out loud. Let AI help parse, synthesize, and connect the dots.

In the demo, I showed how I take a simple recorded description—like wanting to build a prototype of a Brazilian card game called Truco—and turn it into:

• Well-structured user stories with acceptance criteria and scenarios
• Two working prototypes (one in React, one with Portuguese localization) in under a minute
• A foundation for conversation, not a final product

The point isn’t “look how fast AI can code.” The point is: now we can validate ideas before we commit to building the wrong thing.

The 30-Second Wow

You present something to stakeholders, and within 30 seconds, they either say:

• “Wow, that’s close to what we need”
• “Now that I see it, I realize I didn’t explain it well”
• “That’s great—and it gave me more ideas”

Words are abstract. I say “order,” you think “purchase order,” someone else thinks “sales order,” another person thinks “sequential order.” We need to get to shared understanding fast.

Prototypes do that. And now, AI can help us create them in minutes instead of days.

Living Documentation

I also talked about something that’s been a passion of mine for years: tests as living documentation.

If our tests are supposed to document our system, why do we write them in a way that’s hard to read? Why do we fill them with //Arrange, //Act, //Assert comments and duplicate the implementation logic in the test?

Instead, I showed how I use AI to generate tests that follow the Given-When-Then format—regardless of whether it’s a unit test, an API test, or an end-to-end test. Everything reads like English, grounded in the user stories we already created.

Then I can prompt AI to analyze those tests and create an executive summary for financial stakeholders. Full circle: from conversation to code to documentation that helps both technical and non-technical audiences.

Pull Request Reviews That Matter

I also shared my approach to PR reviews. I don’t start with the code. I start with:

1. What need are we fulfilling?
2. Does the user story convey that?
3. Do the tests cover the scenarios?
4. Then I look at the implementation

I’ve codified this process into a workflow that AI runs for me. It pre-scans everything and tells me what to pay attention to—not tabs vs. spaces, but potential performance issues, missing edge cases, and whether the implementation aligns with our architectural patterns.

A few sprints ago, it caught a query performance issue, suggested two solutions, asked if I wanted to address it now or later, and then implemented the fix when I said “go ahead.”

The Long Game

Near the end, I touched on something people don’t talk about enough: technical debt from outdated dependencies.

A few months ago, I had to update dozens of NuGet packages. Tedious work. So I told AI: “Update each package one at a time, run the tests after each update, fix anything that breaks, and move to the next one.”

It did. While I worked on other things.

This isn’t the future. This is how I’m working right now.

Why I’m Sharing This

If you’ve ever felt like good ideas lose momentum somewhere between discussion and deployment, this talk is for you.

I’m not saying I have it all figured out. I’m saying I’ve found a way to reduce friction across the entire development lifecycle—from clarifying needs to prototyping quickly to maintaining code quality over time.

The tools are capable. We’re just not always using them where they shine.

Watch the full talk if you want to see the demos, the workflows, and the specific prompts I use. And if something resonates, let me know. I’m always learning out loud.

Make sure to check out the upcoming Improving Talks webinars we have in February.