Pedro Sousa
Português

Blog

Reflections on engineering, AI and product.

14 articles

Featured

How I work with AI: I don't ask for code, I configure the environment the AI works in

I believe the real gain with AI didn't come from better prompts, it came from changing the question. Instead of asking for code, I engineer the environment, the harness, where the agent works within my standards.

AIClaudeMobile DevelopmentiOSDeveloper ProductivitySoftware ArchitectureAI AgentsMCP
Jun 24, 2026
Read article ›

More articles

Aug 23, 2026

The agent didn't make a mistake. It answered exactly what you asked.

Most problems with AI agents in production aren't hallucination or model limitations. It's that the engineer doesn't realize they're asking the wrong question. The model delivers what it received. The problem happens before the call.

Read article ›
Aug 16, 2026

You didn't refactor the code. You just moved the problem somewhere else.

Refactoring is not reorganizing code. It's changing internal behavior without changing external behavior, and most refactors that happen in real projects don't do that. They just relocate where the problem lives.

Read article ›
Aug 09, 2026

The model didn't forget. You never explained it properly.

Most problems with LLMs in production aren't model failures. They're failures by whoever built the system around it. Context engineering isn't an optional step: it's the only part that actually matters.

Read article ›
Aug 02, 2026

What nobody tells you about working internationally: the problem isn't your English

Most Brazilian engineers who try to break into international careers get stuck in the wrong place. Language isn't the bottleneck. The way you communicate technical decisions is.

Read article ›
Jul 26, 2026

Kotlin Multiplatform is not Flutter. And that confusion is costing entire architectures.

Most teams adopt Kotlin Multiplatform with the same mindset they'd use for Flutter, and that's when things start to fall apart. Sharing logic across platforms is different from sharing a product. That distinction rarely shows up early enough.

Read article ›
Jul 19, 2026

RAG didn't fail because of search. It failed because of the context you didn't give the model.

Most RAG problems in production aren't about document retrieval. They're about poorly constructed context passed to the model. This article explains why the pipeline works in testing and breaks in the real world, and what I would change today.

Read article ›
Jul 12, 2026

Flutter solves the wrong problem when you already have a working Kotlin app

The decision to go cross-platform is almost always made before anyone understands what problem is actually being solved. I've worked on both sides of that decision, and the mistake I kept seeing wasn't technical. It was a misdiagnosis.

Read article ›
Jul 05, 2026

The abstraction you created to simplify things will be your next maintenance problem

Every abstraction is born from good intentions. The problem is that it ages without warning, and by the time you notice, it's already spread across ten places you no longer control. That's the cost nobody puts in the PR.

Read article ›
Jun 28, 2026

The agent that worked in testing and broke in production

Building an AI agent that works in a demo is straightforward. The problem shows up when real context arrives: noisy data, long sessions, ambiguous states. Most teams find that out after deploy.

Read article ›
Jun 21, 2026

Working abroad doesn't make you senior. Context does.

I went to work at a software factory in France thinking the geographical leap would change my technical trajectory. It did, but not in the way I expected. What actually happened was slower, more uncomfortable, and more useful than anything I could have planned for.

Read article ›
Jun 13, 2026

SwiftUI Preview as an Architecture Sensor

When a Preview starts demanding acrobatics just to work, the problem is rarely the Preview. The problem is the architecture. I learned that the hard way, trying to fix the symptom instead of the cause.

Read article ›
Jun 11, 2026

The pattern you won't refactor because it's working

Bad technical decisions rarely blow up. They just stay. This article is about the kind of code that survives not because it's good, but because it works just enough to never become a priority.

Read article ›
Jun 07, 2026

The module that knows too much is not a module. It's a monolith with extra files.

Modularizing a project without modularizing the thinking creates an illusion of isolation. The practical result is a monolith distributed across folders, with invisible coupling and increasingly slow builds.

Read article ›