Claudio Lassala's Blog

The Question That Started It

What happens to a software developer if the computer doesn’t have connectivity? Turn off the Wi-Fi. Turn off the Internet. Turn off the Intranet. The computer can only access its own resources. Can the developer still work? Does the application run?

I’ve been thinking about this question a lot lately, and it’s taken me on a journey through my own career — from a lesson learned twenty years ago to a present-day practice I’ve built into every project, and now to an uncertain future where AI is changing the equation.

Twenty Years Ago: When We Couldn’t Reproduce the System

A long time ago, I worked on a project where the client was in another country, very far from where I was. This was before we had the kind of internet speeds and availability we have today. We couldn’t just transfer big files over the network — it would take forever.

Their system was massive: large codebase, lots of data, deeply integrated with their infrastructure. It ran 24/7 operations. They couldn’t afford downtime, so they’d built a very stable platform on the backend.

Our job was to rewrite the front end. The system had good separation — the front end communicated with the backend using XML (this was before JSON). But here’s the problem: to run the front end, we needed the backend. And we couldn’t reproduce their backend in our development machines.

We tried. We failed.

After multiple attempts, we had to get creative. We built what I called a “fake backend” — essentially a simulator that would respond to the front end’s XML requests with canned responses. We recorded real interactions from their system and played them back during development.

It wasn’t perfect, but it worked. We could develop completely disconnected from their infrastructure. We could work on planes, at home without internet, anywhere. The fake backend ran locally, and we kept moving.

That experience taught me something I’ve carried forward ever since: dependency on external systems is a constraint I don’t want to live with during development.

Today: Building Independence Into Every Project

Fast forward to more recent projects. I’ve made it a practice to structure applications so I’m never stuck because dependencies are down or slow.

Take authentication, for example. On one project, we eventually integrated Azure B2C for production authentication. But I made sure not to be constrained by it during development. I didn’t want to be limited to only logging in through Azure B2C — it’s slower, it requires internet, and it adds friction to the development loop.

So we built a dual-mode system. During development, we use simple form authentication with a local user database seeded with well-known test users. Fast. No external calls. No waiting.

The same approach extended to authorization. We focused on permissions — protecting features, resources, and workflows — and stored those permissions in our own database. This meant we could test the entire authorization flow locally without ever touching Azure B2C.

For end-to-end tests, this was huge. We could write tests like: “Given I have permission to X, when I do Y, then I should observe Z.” We bypassed the login screen entirely and focused on the feature itself. Only a few tests actually exercised the authentication mechanism. Everything else assumed the user was already authenticated and authorized.

We did the same thing with Azure Service Bus. During development, we ran an in-memory message bus. Faster, no external dependencies. But we could flip a switch and use the real Azure Service Bus when we needed to verify that specific integration.

In production and QA environments, everything used the real services. But in development? Complete independence.

This approach has saved me more than once. During the freeze in Houston, I lost power for over a week. I kept working the entire time — running off my laptop battery, recharging with a gas generator when needed. When Azure went down due to a cybersecurity attack, I kept working. No internet? No problem.

Tomorrow: The AI Dependency

Now I’m thinking about the future, and it’s more complicated.

I use AI tools heavily in my development work. LLMs help me move faster, think through problems, generate code. But here’s the thing: I’m not running local models. I need internet connection for that speed.

If I’m in a situation where I don’t have internet — on a plane without Wi-Fi, in a place with spotty connectivity — I’m not going to be able to move as fast with certain kinds of work.

I could run a local LLM, but it would be quite a bit slower. And it would slow down my entire machine because of the resources it consumes. It’s like the difference between driving a car and walking. I can still get there by walking, but the level of effort is much greater and it’s definitely much slower.

Or I could go back to coding things by hand. Which, at this rate, feels like the difference between walking, riding a bicycle, driving a car, or flying.

The Bigger Question

This gets more interesting when I think about where we’re heading. Imagine AI agents that automatically identify issues in production systems, troubleshoot them, patch the fix, and deploy — all automated, all fast. That’s a huge reliance on connectivity.

If the servers are down, if the electricity is out, are we ready to go back to the basics? To the manual way of doing things?

With the speed that everything is moving, it seems like we need to make sure we don’t lose track of the fundamentals. We need to be prepared to handle these dependencies. We need to ask: if these dependencies aren’t there, can we still do it? And if we can, can we still do it in a timely manner?

What I’m Noticing

I understand that most software these days includes features integrated with other systems. Networking capability is necessary. But is that true for every single feature? I don’t think so.

To me, it’s important to be able to do some work while completely disconnected. It’s a design choice. It’s about resilience. It’s about not being blocked when the world around you goes down.

I’ve built this into my practice over the years, and it’s served me well. But as we move into a future where AI is increasingly part of the development workflow, I’m watching to see how this principle holds up.

It will be interesting to see how that’s going to go.

We’re all nudged – no, we’re all pushed -, into doing everything faster. We need to be more efficient. All the time. Go, go, go. More, more, more.

But sometimes we need to slow down to go fast.

Going fast, but out of control, can turn into a crash. Recovering from that crash often means delaying the achievement of a goal.

Slowing down to either establish or regain control often enables us to set a consistently fast pace and achieve a goal faster.

“What the heck are you talking about?”

I’m likely mixing metaphors based on experiences that resonate with me.

Riding

Riding a motorcycle fast is a thrill. But what’s the goal?

If I’m riding curvy roads, such as those in the Italian Alps, my goal is to enjoy the scenery on a motorcycle. Paraphrasing a passage of [[Zen and the Art of Motorcycle Maintenance]], “driving a car, we’re watching the scenery, while riding a motorcycle we’re a part of the scenery”.

If I’m going so fast that 100% of my focus is on staying on the road and not falling off a cliff or running into incoming traffic, then I’m disallowing myself from witnessing the amazing views around me.

When my goal is to get the thrill from riding a motorcycle as fast as I’m able to, I go to a race track.

But getting on the track and twisting the right wrist only makes me go as fast as I’m going. To learn to go as fast as I can possibly go, I need to slow down first. I need to know where the track goes. I need to know its camber, bumps, cracks, runoff areas, and references.

So first I’ll go on a track walk. That’s right, walk the track. See it up close.

Then get on a bike and go on a sighting lap. Then speed up just a little.

Stop and internalize what I’ve seen and how I’ve felt. Go out again, with the intention of working on specific aspects of my riding. Speed will come.

When winter comes, and the temperatures drop, it’s impossible to go as fast. Do I stop riding? No. Go out and ride my best, given what I have. As I do so, any sloppiness becomes immediately known: jerky body movements and sloppy throttle/brake control come to the surface. The braking approach into corners doesn’t work and requires adjusting. The mandatory slower pace brings extra awareness to things I was overlooking when I could just go fast.

Reading

Should I fast read or slow read?

What’s my goal?

Why have I picked up this book?

Say the goal is to learn as much as possible about the subject within a given timeframe. I’ll probably fast-read it. Flipping through the pages quickly, noticing the main sections, sub-sections, and images. Then go back to page one, and go through all the pages, slower this time, but still at a fast pace.

When my brain detects through my eyes something it deems important (I told my brain why I picked the book and what my goal is), it tells me to slow down. So I do. I highlight the passage. I write notes. I ponder. Then I speed up again.

Now I pick up another book. This is a work of fiction by an author whose writing I appreciate. I read the words at a much slower pace; I crawl through the words, savoring them, marveling at the craft.

Coding

I can write code pretty fast. I can use code snippets to speed up the process. I can use code generators. Or I can simply type fast. And lately, AI tools do that much, much faster.

But what’s the point of coding fast?

Typing as fast as I think doesn’t help if my thoughts are racing.

I’ve learned I should slow down when I’m not even sure what it is that I’m trying to accomplish. Slow down my racing thoughts. Once the goal and the best next steps are clear, then I use all the tricks I can to speed up coding.

I’ve also learned to deliberately slow things down, even when I know there’s a faster way to do it. For example, I may choose to use the mouse instead of a keyboard shortcut. Or type a long command on the terminal instead of any other faster way.

Food

Brazilian statehouses, such as Fogo de Chao, are an all-you-can-eat meat extravaganza. They have a little card or similar token on the table for each patron; one side is green, which means “Bring me meat”, and the other is red, which means “Stop bringing it”.

It’s common for the novice to sit at the table, turn the card green, get busy eating every cut the waiters bring, and then feel stuffed and done within 15 minutes.

Not me.

I keep flipping that card, green-red-green-red, controlling the pace, appreciating each cut. Figuring out which ones taste the best that day. After doing that for a while, someone always comes to the table and asks, “Sir, are you waiting on any cut in specific?” I tell them what I want, and take a few rounds of that. I get my money’s worth, enjoy a great meal, and head out very content.

Pace Yourself

• Do I need one fast lap?
• Or do I need as many consistent laps as possible?
• Do I need to slow down to smooth things out? To rebalance? To regain control?

In 2019, I made a change that seemed small at the time, but it’s profoundly impacted my productivity: I turned on Do Not Disturb on my phone—and never turned it off.

That’s not an exaggeration. Ever since, my phone has been on Do Not Disturb 24/7. Only a few people can punch through that firewall. Everyone else? I’ll check missed messages and phone calls and reach out later if necessary.

This isn’t about being unreachable. It’s about being intentional. The practice was suggested as part of a leadership training at Improving.

Intentional Tech: Tools That Serve You

We often think of productivity as doing more in less time. But I’ve found it’s far more powerful to reframe the question: What are we optimizing for?

For me, productivity is about protecting my focus so I can solve meaningful problems and do deep thinking. That means stripping distractions down to the bare minimum.

Take my phone, for example. When I unlock it, I don’t see a wall of apps or unread notifications. I see a phone—because that’s what it is—a tool for making calls (well, I know, I’m old…). The apps I do need, like the one I use to track my daily walk or reading habit, are right there. Everything else—email, chat, etc—is pushed to the far end of the phone, buried where I have to make a conscious decision to go looking.

Organize With Purpose

Not everything belongs in one place. I keep practical information—like records of my cars and motorcycles—in simple digital folders. But for deeper thinking and learning, I rely on Obsidian (or whichever tool may serve me in that moment).

When I read, I don’t just capture quotes. I create connections. And I’m deliberate about it. I don’t want AI to auto-generate those links for me. I want my mind doing the work—making sense of what I’m learning, drawing connections between books, ideas, and experiences. Because the value isn’t just in the notes. It’s in the relationships between them.

And those relationships evolve. When I revisit a book a year later, I might see new connections I couldn’t have imagined. That’s not machine learning. That’s human learning.

Productivity Isn’t a Feature—It’s a Practice

I’ve been talking more with teams about designing workflows and setups that support deep work. For developers, this might mean refactoring their code or embracing test-driven development. For consultants, it might be about writing better user stories or aligning more closely with stakeholder goals.

And sometimes, it’s as simple as rethinking your desk setup. I work with multiple monitors, but I’ve learned that more screens don’t always mean more productivity. It depends on how you use them. (I wrote more about that in my post “Multiple Screens May Not Make You Productive”, if you’re curious.)

The key takeaway is this: tools don’t make you productive. How you use them (and what you use them for) does, if they support a good why.

A Gentle Nudge

If there’s one thing I hope readers take away from this, it’s that productivity isn’t something that happens automatically. It’s something we have to design for. On purpose. Every day.

So the next time you pick up your phone, open your laptop, or sit down to read—pause and ask: What am I optimizing for right now?

The answer might just change the way you work.

I’m preparing a one-hour presentation for my colleagues at Improving about travel—specifically, about what travel teaches us about ourselves. The title that emerged from the process is “Learning Who You Are by Leaving Where You Were.” But this post isn’t about the talk itself. It’s about how I’m using AI as a thinking partner in ways that feel genuinely useful.

Starting with Voice

A couple months ago, when I signed up to give this talk, I spent 15 minutes voice journaling while driving. Just stories I normally tell people about my travels—moments that stuck with me, patterns I’ve noticed. I didn’t organize them. I just let them flow.

That transcript became the seed. I dropped it into NotebookLM and asked it to suggest titles and abstracts. The title it helped me land on—“Learning Who You Are by Leaving Where You Were”—immediately resonated. It captured something I’d been circling around but hadn’t quite articulated.

Using Every Feature to Think

When it came time to actually prepare the content, I used pretty much every feature NotebookLM offers. Not because I wanted to try all the tools, but because each one helped me think differently about the material:

• Infographics to see what themes emerged from my initial thoughts
• Audio overviews (the brief “elevator pitch” version, the deep dive, the longer form) to hear my own ideas reflected back in different ways
• Slides to identify what might be unclear or need more development

I’d listen to an audio overview while driving and take voice notes for new thoughts that came up. Then I’d feed those back in and generate new overviews. Back and forth like that.

The Dry Run

Eventually, I did a full dry run—just me in my car, imagining someone sitting next to me, walking through the entire presentation out loud. No slides, no notes. Just talking.

This was valuable in ways I didn’t expect. I could feel when I was rambling, when I was using too many words to make a simple point. I kept an eye on the time and realized I was only halfway through my stories but already 40 minutes in. Saying it out loud made the timing problems obvious in a way that outlining never does.

The whole thing took about 70 minutes. I knew I’d skipped stories I wanted to include, but I also knew where I was losing the thread.

What Comes Next

Now I’m going to take that recording, transcribe it, and feed it back into NotebookLM. But this time, I’m going to be much more specific with my prompts:

• For the brief overview: Help me tighten the core message
• For the deep dive: Expand on the stories that landed well
• For the debate: What hard questions might people ask about the points I’m making?
• For the critique: Focus on timing, pacing, and structure—how should I open, develop, and close?

I’ll also ask it to generate slide decks. I’ve done this before and been impressed—when I mentioned the Munich town hall and standing there alone on a rainy day, it created a photorealistic image that captured the mood.

These aren’t my personal photos, but they might work as placeholders while I tell the story—like a biopic where actors portray real people, then you see the actual photos during the credits. I might try that approach.

The Real Work

After I generate all these materials, I’ll export the slide deck and apply Improving’s branded templates. This will be good practice for streamlining content creation for future talks—figuring out how to move quickly from AI-generated drafts to polished, on-brand presentations.

But here’s what I keep noticing: the AI isn’t doing the work for me. It’s helping me think. Each audio overview surfaces something I hadn’t quite seen. Each infographic shows me where my ideas cluster. Each generated slide deck reveals which moments have visual weight.

The voice journaling, the dry run, the back-and-forth with the tool—it’s all just different ways of thinking out loud. The AI is a mirror that reflects my thoughts back in forms I can examine from new angles.

Why This Matters

I’ve been doing this kind of preparation for years, but usually it’s all in my head until I sit down to write slides. By that point, I’ve already committed to a structure that might not work.

This approach—voice journaling, feeding transcripts into AI tools, generating different views of the same material, doing dry runs, refining—lets me explore the shape of the talk before I lock anything in. It’s messier, but it’s also more honest. I’m not pretending I know exactly what I want to say before I’ve said it.

The AI amplifies my ability to think by giving me more ways to encounter my own ideas. That’s what makes it useful.

I’ll probably write another post after I give the talk—about how the preparation translated to the actual delivery, what worked, what didn’t. And maybe a separate post about the travel content itself. We’ll see.

I remember when we used to only have programmers and system analysts. That’s how it was when I started in the mid-90s, getting into IT and computers.

The main IT guy at the office was both a programmer and an analyst — a system analyst. The analyst would talk to the stakeholders, the business people, to understand the problem that needed to be solved. Then they’d come up with the design for the solution, the different pieces that needed to be built, even the database design. And then, the programmers would write the code to implement it.

At the places where I worked, it was always the same person doing both lines of work: analyzing the system and writing the code.

The Evolution of Titles

A few years later — I don’t remember exactly when — we started talking about developers. Instead of calling people programmers, we called them developers because they were doing both: system analysis and programming.

Then came the front-end and back-end developers. Which was odd to me because, for the longest time, it was just developers, without a real distinction. You had developers who knew how to do both.

But the split made sense for practical reasons. Depending on the team and the project, some developers would focus mostly on the back end, while others would focus mostly on the front end, so that work could be done asynchronously or in parallel. Two people could work on the same feature or user story at the same time, as long as they collaborated and created a contract for how the front end and the back end would communicate. Then they could go off and work in parallel, integrating their pieces later.

What I’ve Noticed About Front-End vs. Back-End

After many years of doing this, I’ve come to a realization: the back end will always outlive the front end.

A well-built, well-designed, well-architected back end will always outlive the front end because the front end is more volatile. And there are good reasons for this.

For one, the front end is the part of the system users are more likely to interact with. It’s where people interface with the system. And as these people understand the system better, as they get more comfortable using it, as they get over the initial challenge of learning where everything is and what the system can do, then they start asking for enhancements or changes.

Depending on what they ask, it may very well be only a change to the front end, not to the back end. That is, if both were created with an architecture that allows for that.

Another consideration: the devices where front ends run change more rapidly than back-end technology. Computers get better processors, more multithreading capability, and multicore. There are things on the client side. Monitors get bigger, and the resolution gets better.

But also, there’s the situation where the screens get smaller — smartphones and tablets. Those also need front ends, but they’re a different kind of interface from those on a regular computer. We’re not using a mouse or an external keyboard. We’re tapping on a screen. We’re using touch.

With all these front-end changes — due to devices, computers, and screens — the back end may not have to change at all. Or when it does, if well-structured and architected, it can be changed with minimal changes. In some cases, it may be an addition. Maybe it’s creating a new view model to map data from the database into what the new UI for the new device requires. It could be a database view or a read model in an event-sourced system. Those are additive, which are usually easier than changing existing code.

The Limitation of Specialization

I’ve been thinking that some developers focus solely on front-end development, and others solely on back-end development, which can be somewhat limiting.

Both of them should really focus on neither. Yes, they may have preferences or be better skilled at one or another, but at the end of the day, those are just pieces of technology.

In both cases, they should learn to work with people, to work with businesses, and to come up with the best solutions.

For those on the front-end side of things, they should get very much in touch with user experience design, empathy, and all of these techniques and approaches to understand the problem being solved and then come up with better experiences for it. And then from there, get to the UI design.

For the person who is mostly on the back end, that could mean understanding the problems you’re trying to solve, the events—the business events that happened, and the domain events—and designing it to capture users’ intent, people’s intent, and business intent. Design around that first, before thinking about persistence concerns, data replication, and those things.

And for that, getting to learn domain-driven design, more specifically the strategic patterns, learning about context mapping, and the relationship between the different types of domains, ubiquitous language. That is very important.

For both front-end and back-end developers, I believe that if they view behavior-driven development from the standpoint of people’s behavior, rather than system behavior, that would be best. Because now they focus on the people and the problems that need solving, they put their heads together to come up with the best solution.

What This Means in the Age of AI

Now, in the age of AI, a person who can do that — who can have the empathy, develop the empathy, articulate thoughts, and facilitate conversations with people to then come up with the designs for the behavior and the experience, to a point where they can describe it — can then collaborate with AI to refine that understanding.

And last but not least, work with AI for AI to do the actual work of proposing mockups, wireframes, and high-definition prototypes. And from there, creating the actual implementation on the front end, on the back end, creating what is technically necessary to pull it off.

No longer would front-end developers spend a lot of time figuring out CSS, styles, and misalignment in the design. Let AI figure that out. Do that kind of work.

Same thing on the back end, trying to address some complicated business logic. Let AI write that logic. As the human in the loop, make sure that the acceptance criteria are well-defined, the user stories are well-defined, and the examples are well-defined. Have documented ways to write good specs for the automated tests, and let AI implement the solution.

The Real Skill

The labels — programmer, analyst, developer, front-end, back-end, full-stack — they’ve all been useful at different times. But they’re just labels for pieces of technology.

What I’m noticing is that the real skill, the one that matters more now than ever, is the ability to understand people and problems. To design with empathy and intent. To articulate what needs to happen before worrying about how it happens.

The technology will change. The devices will change. The tools will change. AI will handle more of the implementation details.

But understanding what to build, and why, and for whom — that’s still on us.