If you are a Software Engineer or Tech Lead and you are looking for a clear mental model to navigate the modern AI engineering stack, then this email is for you.

In today’s issue, I want to share the first part of a three-part series on the essential layers of AI engineering, based on the framework developed by author and researcher Chip Huyen. Today, we start at the very top.

Here is what else we are covering in this issue:

• The Read-Only Memory: The incredible trajectory of Chip Huyen, from a small farming village in Vietnam to teaching Machine Learning at Stanford.

• The Open Thread Club: Tackling presentation anxiety, and why imagining the audience naked completely fails in practice.

• The Rendezvous: Key upcoming software events in Las Vegas, Madrid, and Geneva.

Before you continue, if you enjoy my work and would like to support the newsletter, I’d really appreciate it if you shared it with a fellow engineer:

💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky

Or simply forward this email to someone who might find it useful.

The Read-Only Memory

Today you learn a bit more about Chip Huyen, the author of the AI Engineering book (which I recommend without getting paid).

After high school, her three-day trip to Brunei turned into a three-year journey across Asia, Africa, and South America. To fund her travels, she wrote about the people she met and eventually published four books of stories in Vietnamese. During that time, she worked as a Bollywood extra, a casino hostess, and a street performer. Years later, after initially being rejected by Stanford, she reapplied, was admitted, and went on to teach Machine Learning Systems there.

But there is one detail about Chip that I find even more interesting in the spirit of your list.

When she shared her story at Stanford, she explained that she came from a small farming village in Vietnam, didn’t have internet at home until she reached university, and wasn’t even accepted by Stanford at first. Once there, she admitted she was afraid of public speaking because she thought her accent would make it hard for others to understand her. A public speaking course at Stanford helped her gain confidence and change that perception.

And there is a second, particularly lovely layer to this: when she started teaching Machine Learning Systems, she published the course materials and publicly asked other professionals to review the notes and provide feedback. The course eventually became the foundation for *Designing Machine Learning Systems*.

In this section, we will focus on biographies of computer pioneers, forgotten historical whitepapers that remain entirely relevant, and independent blog posts that question the status quo of our industry.

Would you like to suggest some? I hear you! 👇🏻

📧 I have something for you!

The Open Thread Club

On this occasion, a reader asked this:

For performing talks and presentations, does imagining people naked actually work to temper my nerves?

— Nervous Anonymous Presenter

I will confess here and now that: yes, I’ve tried this.

Only once. Why? It did not work for me.

Two tricks that actually work for me:

• If I have a friend in the audience, I focus my talk on that person, and it really helps to temper.

• Focus your view “into the void”. What does this mean? Avoid eye contact with people in the audience and, instead, keep your eyes in the blank spaces between the public attending to your talk. Like that, the public has the feeling you are keeping eye contact (which could be good), but you are not affected by their reactions.

Do you have any tricks? Share it!

This person is starting with making talks and presentations and asked this in the context of reading this👇🏻

In this space, we will address real dilemmas about architecture, technical friction, or leadership situations you send anonymously.

Instead of giving theoretical or dogmatic answers, I will respond honestly, sharing my own past mistakes in similar situations and the lessons I learned while trying to solve them.

You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻

📧 I have a tale to share!

The Rendezvous

The events of this week.

• Are you going to re:Invent 2026 in Vegas (USA)? It will happen from November 30th to December 4th.

• In Madrid (Spain), the Dev Fest 2026 will be held on November 27th.

• In Geneva (Switzerland), from December 9th to 10th, the KCD Suisse Romande 2026 will run in English and French.

A radar of events about software engineering and technical leadership.

The priority here is not to be exclusively massive conferences, but to give visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know of an event worth sharing, the channel is open for you to send it to me and share it with the community.

Do you own an event or summit? Drop me an email! 👇🏻

📧 I know about an event!

The A-Side

Today, we’re looking at the Application Development Layer (Product-First).

This is the layer where most of the user experience is built. The idea is pretty simple:

Get as much value as possible from existing foundation models using traditional software engineering, without changing the model itself.

Chip Huyen highlights three main areas here:

👉🏼 Systematic & Rigorous Evaluation

Evaluating probabilistic models is one of the hardest parts of building AI systems. A simple “looks good to me” approach doesn’t scale very far.

The goal is to move from informal vibe checks to automated and reproducible evaluation pipelines. One approach is AI-as-a-judge, where a more capable LLM evaluates the output of another model against a defined set of criteria.

If you want, I can treat this AI-as-a-judge approach in future editions. Write me in the comments!

👉🏼 Prompt Engineering & Context Management

This is where techniques like RAG (Retrieval-Augmented Generation) become useful.

Instead of expecting the model to know everything, we provide it with the relevant business context at runtime. For example, company policies or product documentation can be retrieved from a vector database and included in the prompt.

The idea is to give the model the facts it needs, when it needs them, rather than relying entirely on what it learned during training.

👉🏼 AI Interfaces & Control Logic

This is about everything around the model: how users interact with it, how we orchestrate agents, and how we constrain what the system can actually do.

That might mean using patterns such as Plan-and-Act, enforcing structured outputs with JSON schemas, or adding guardrails to deal with things like prompt injection, unsafe content, or unexpected model behaviour.

🧐 A real-world example

Imagine you’re building an enterprise customer support assistant.

You probably don’t need to train your own LLM. You can provide company policies and product information through RAG, evaluate the responses using an AI-as-a-judge approach, and constrain the output to a well-defined JSON schema that your application can safely consume.

That’s a lot of product value without touching the model weights.

☝🏼 The key takeaway

A huge amount of the practical value businesses are getting from AI today is being created in this layer.

And that’s an important point: you can build surprisingly capable AI products without ever training or fine-tuning a model.

So, what does this layer Application Layer actually look like at a glance?

• Evaluation: Move beyond informal vibe checks towards automated, reproducible evaluation.

• Context: Use RAG and retrieval systems to give models access to the information they need at runtime.

• Control: Use guardrails, agent orchestration and structured outputs to make AI systems more predictable and useful.

But there’s a limit.

What happens when prompt engineering and RAG aren’t enough? What if you need the model to behave in a very specific way that simply doesn’t fit into the context you can provide?

That’s when we need to go one level deeper.

Next week, we’ll look at how we can adapt the “brains” of these models themselves.

As always, if you have thoughts, questions, or disagree with something I’ve written, drop me a reply or leave a comment. I read and reply to all of them.

Be safe,
Marcos

Looking forward to hearing from you about the new format of the newsletter. Tell me here! 👇🏻

Drive me in!

We love to believe that treating our startup like a family means they will protect our careers when they finally scale.

That is the biggest lie we swallow in this industry.

If you are a Software Engineer and you are looking to navigate corporate growing pains without sacrificing your own growth, then this email is for you.

I want to tackle the brutal reality of the startup honeymoon phase in The A-Side. We will break down what happens when your company scales beyond a thousand people and why your career suddenly stops being their priority.

To complement that reality check:

• The Read-Only Memory: Simon Sinek’s personal wake-up call about faking professional happiness.

• The Open Thread Club: Rethinking your baseline loyalty to the company when AI anxiety creeps in.

• The Rendezvous: Upcoming November engineering summits in Barcelona, Lisbon, and San Francisco.

Before you continue, if you enjoy my work and would like to support the newsletter, I’d really appreciate it if you shared it with a fellow engineer:

💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky

Or simply forward this email to someone who might find it useful.

The Read-Only Memory

Today, I bring you Simon Sinek. This person has a book I would like to recommend (I’m not getting paid for it)

Start with the Why

— Simon Sinek

The story that I bring you today is very related to the topic you will read in The A-Side (down in this email).

When his first company seemed to be doing reasonably well, a friend was the first person to notice that something didn’t add up. Sinek admits that he had been pretending for some time to be happier and more successful than he actually felt. It was that conversation, not professional success, that enabled him to start changing his life.

Did this happen to you?

In this section, we will focus on biographies of computer pioneers, forgotten historical whitepapers that remain entirely relevant, and independent blog posts that question the status quo of our industry.

Would you like to suggest some? I hear you! 👇🏻

📧 I have something for you!

The Open Thread Club

Following up on the main topic of The A-Side today (read down in the mail), I don’t bring you a question from readers. Not because I don’t have any about this topic, but quite the opposite, including concerns about “I’m worried about the AI taking my job”.

Today, I bring you something I wrote some time ago, so:

• Instead of worrying about “will the company fire me?”

• Just think, “What should be my position in regard to the company I’m working for”

Read the full email here 👇🏻

In this space, we will address real dilemmas about architecture, technical friction, or leadership situations sent anonymously by you.

Instead of giving theoretical or dogmatic answers, I will respond with honesty, sharing my own past mistakes in similar situations and the lessons I took away when trying to solve them.

You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻

📧 I have a tale to share!

The Rendezvous

From now on, you should start targeting summits and conferences happening in November, so I can bring you 3 during that month.

• The PyConES 2026 is happening in Barcelona (Spain) next November 6th to 8th.

• In Lisbon (Portugal), the Web Summit 2026 starts November 9th and ends on the 12th.

• If you are in the San Francisco area (USA), you will have the QCon San Francisco 2026 from November 16th to 20th.

If you attend some of those, tell me how it goes!

A radar of events about software engineering and technical leadership.

The priority here is not to be exclusively massive conferences, but to give visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know of an event worth sharing, the channel is open for you to send it to me and share it with the community.

Do you own an event or summit? Drop me an email! 👇🏻

📧 I know about an event!

The A-Side

Every developer starts in the honeymoon phase.

When a startup is small, say under 500 people, it’s easy to feel that your work really matters. You know the people around you, you can see the impact of what you’re building, and you’re close enough to the company’s mission to feel part of it.

Motivation is high. Sometimes very high.

You might even find yourself going the extra mile, working late or taking on more than you probably should, because you genuinely care about what you’re building.

Then the company grows. 800 people. 1,000. 2,000.

More layers of management appear. Teams get reorganised. Processes multiply. Decisions take longer. And at some point, you hear someone say:

This isn’t what it used to be.

— You team mates, in the coffe break

It’s tempting to blame the company. But most of the time, it’s not that simple.

As a company grows, the way it operates has to change. The focus shifts towards products, revenue, efficiency, organisational goals and, increasingly, doing more with less. AI is only adding more pressure to that equation.

And somewhere along the way, your individual career can stop being a priority for the people at the top.

That doesn’t necessarily mean your manager doesn’t care. They might care a lot. They may simply have 15 other things competing for their attention and very little room to protect your interests.

👉🏼 So be careful about where you put your extra effort.

There’s nothing wrong with caring about your company. But your career is ultimately yours.

Put some of that extra mile into your own skills, your own projects, your network and your growth.

Because when the company changes, restructures, or moves on to its next priority, those are the things that stay with you.

👉🏼 Invest in yourself first.

If you want more honest thoughts on navigating engineering careers, Tech Lead roles, and the path towards Staff Engineer:

Read the full list here → https://newsletter.optimistengineer.com/t/tech-lead

Be safe,
Marcos

Give them a two-line requirement, they say, and AI will take care of the rest: architecture, code, tests, the lot. But what happens when generating code becomes faster than understanding what that code is actually doing?

If you’re a software engineer trying to spend less time fighting AI hallucinations and more time building reliable, predictable workflows, this issue is for you.

Hey! As you know, I’m trying out a new format for the newsletter, and I’d love to hear what you think about it! Please take just 1 minute to complete this short survey.

Let's go to the survey!

In today’s issue, we dive into The A-Side and take a closer look at Structured Prompt-Driven Development (SPDD). We’ll walk through the workflow loop that helps keep your intent aligned with the code, and why doing the analysis first matters more than jumping straight into the canvas.

And there’s more:

• The Read-Only Memory: Donald E. Knuth once offered a $2.56 reward for finding errors in his books. A small detail that says a lot about his approach to technical work, and about being open about mistakes.

• The Open Thread Club: What happens when a C-Level demo goes well enough that, suddenly, your demo is expected to become a production application?

• The Rendezvous: A quick look at upcoming SRE, CloudNative, and Python events in Salt Lake City, London, and Rapperswil.

Before you continue, if you enjoy my work and would like to support the newsletter, I’d really appreciate it if you shared it with a fellow engineer:

💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky

Or simply forward this email to someone who might find it useful.

Thanks, as always, for reading.

The Read-Only Memory

Do you know who Donald E. Knuth is?

Donald Ervin Knuth is an American computer scientist and mathematician. He is a professor emeritus at Stanford University. He is the 1974 recipient of the ACM Turing Award, informally considered the Nobel Prize of computer science.[4] Knuth has been called the “father of the analysis of algorithms”.

But that’s not the main reason why I mention Donald today. Watch this out!I found on his Standfor’s web page that Knuth personally pays $2.56 to anyone who finds a genuine error in his books. It is not merely a symbolic reward; he has maintained the system for decades and publishes lists of errors so that readers can verify them. There is something highly unusual for an academic of his stature in publicly turning his own mistakes into an opportunity for others to contribute.

Who would you say NEVER would do that from the nowadays technology spectrum? Write it in a comment!

In this section, we will focus on biographies of computer pioneers, forgotten historical whitepapers that remain entirely relevant, and independent blog posts that question the status quo of our industry.

Would you like to suggest some? I hear you! 👇🏻

📧 I have something for you!

The Open Thread Club

Today’s topic on The Open Thread Club, I think, is happening in those companies where innovation is the goal of the company. Lately, I've read about many “AI Labs” created either as a whole company or as dedicated/supperpowered group/team.

How to build a quick prototype that everybody knows will be declared production-ready just after the demo?

— Anonymous streessed developer

That question summarizes the question that arrived in my mailbox a couple of months ago.

This developer told me, in detail:

• We have to develop an AI-based project and demo it to the C-Level board.

• We need several apps to make this happen.

• We have a very demanding timeline to deliver value.

• My concern is that if we build these apps without a minimum level of testing and CI/CD, and the project proves its value, we could end up in trouble when we need to iterate and make it production-ready because of the technical debt we’ve accumulated.

First, did you face the situation when a prototype becomes automagically into a production-ready product just because the C-Level member (you choose) says so? Because this is the case of this person.

Second, do not try to fight that situation: you will fail. Instead, you can do something else.

📖 My take: Do implement those minimal tests and the complete CI/CD, even if your requirements say “do not lose time on that”. You are a developer accountable for the work you do and, as such, you have to ensure you put in place the right quality to ensure the success of your apps.

Depending on the project, the right level of X is different. When you work on a project like the one described:

1. You will avoid too many tests and focus on the happy path to ensure that your next changes do not f*ck up the app.

2. You will implement the automatic CI/CD run. For me, the automation is included in the minimum. Why? You need speed to deliver new versions of your app fast, and the automation gives you precisely that.

Hope this helps!

In this space, we will address real dilemmas about architecture, technical friction, or leadership situations you send anonymously.

Instead of giving theoretical or dogmatic answers, I will respond with honesty, sharing my own past mistakes in similar situations and the lessons I took away when trying to solve them.

You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻

📧 I have a tale to share!

The Rendezvous

• KubeCon & CloudNativeCon North America 2026. KubeCon is one of my favourites, and it’s coming next November 9th to 12th in Salt Lake City, Utah.

• If you’re in an SRE role, this is for you. In London, the Observability and SRE Summit will happen on 21st and 22nd of October.

• For those Python lovers in Europe, the Swiss Python Summit will happen in Rapperswil on October 22nd and 23rd.

If you go to some of those, tell us how it goes!

A radar of events about software engineering and technical leadership.

The priority here is not to be exclusively massive conferences, but to give visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know of an event worth sharing, the channel is open for you to send it to me and share it with the community.

Do you own an event or summit? Drop me an email! 👇🏻

📧 I know about an event!

The A-Side

In the previous chapter, we introduced what SPDD is and the problem that it tries to solve.

The Optimist Engineer

[The A-Side] A Guide to SPDD: What is SPDD? Prompts as First-Class Artefacts (#166)

The industry is selling you a massive lie about AI coding assistants…

Read more

21 days ago · 4 likes · Marcos F. Lobo 🗻🧭

Now, we go a bit deeper.

🔍 Why Analysis Comes Before the Canvas

There is another important distinction in SPDD that is easy to miss.

The workflow does not necessarily go directly from requirements to the REASONS Canvas. There is an analysis step in between. Why?

☝🏼 Because before deciding how to change a system, we need to understand the system we already have.

The analysis step examines relevant parts of the codebase and domain, identifies concepts, dependencies, risks, and possible design directions, and uses that information to create the context for the structured prompt.

A useful way to think about the distinction is:

Analysis asks: “What do we know about the problem and the existing system?”

REASONS asks: “Given that understanding, what exactly are we going to build?”

This separation is important because otherwise it would be very easy to ask an LLM to design a solution without giving it enough knowledge about the system it is changing.

And that is exactly the type of situation where AI assistants can confidently produce technically valid but contextually wrong solutions.

🗝️ The SPDD Workflow

The exact commands depend on the tooling, but the OpenSPDD implementation provides a useful concrete representation of the SPDD workflow.

The core flow is roughly:

Business requirement
        ↓
     Analysis
        ↓
  REASONS Canvas
        ↓
 Code generation
        ↓
 Validation / tests
        ↓
 Human review
        ↓
     Sync
        ↺

OpenSPDD currently provides commands for the main steps:

/spdd-analysis

Analyzes the requirement and relevant parts of the existing codebase.

The goal is to understand domain concepts, current implementation, risks, and possible design directions.

/spdd-reasons-canvas

Turns that understanding into the structured REASONS Canvas.

This is where requirements, entities, approach, structure, operations, norms, and safeguards are made explicit.

/spdd-generate

Uses the Canvas to generate code task by task.

The idea is that the model is no longer improvising the whole solution from a short prompt. It is executing a more explicit implementation plan.

/spdd-prompt-update

Used when the requirement or intended behavior changes.

This is an important distinction.

If we discover that the business requirement was wrong or incomplete, the intent should change first.

That gives us:

Requirement change
        ↓
Prompt update
        ↓
Code update

/spdd-sync

Used when the implementation changes without changing the intended behavior, for example because of a refactoring or implementation-level correction.

That produces the reverse direction:

Code change
        ↓
Sync
        ↓
Prompt updated

OpenSPDD currently also provides optional commands such as /spdd-story, /spdd-api-test, /spdd-code-review, and /spdd-reverse, but they are not the core of the workflow.

The important part is therefore not memorizing the commands.

The important part is understanding the loop.

🔄 The Interesting Part: Prompt ↔ Code

For me, this is the part that makes SPDD more interesting than a sophisticated prompt template.

The relationship between intent and implementation works in both directions.

When behavior changes

Suppose the original requirement was:

Premium customers can exceed their monthly usage quota.

Later, the business changes its mind.

Now Premium customers must also respect a quota.

That is a behavior change.

The intent has changed, so we update the structured prompt first.

New requirement
      ↓
Update REASONS Canvas
      ↓
Generate / modify code
      ↓
Review and test

When implementation changes

Now suppose the behavior is still correct, but we refactor BillingService because we want to introduce a different internal abstraction.

☝🏼 That is an implementation change.

The intent has not changed.

We can therefore change the code first and synchronize the structured prompt afterwards.

Refactoring
      ↓
Code changes
      ↓
Sync Canvas

This distinction is one of the most useful ideas in SPDD.

• A behavior change means intent has changed.

• A refactoring means implementation has changed while intent remains the same.

If the code changes its behavior but the prompt does not reflect that change, the two artifacts are now telling different stories. That is effectively Prompt Debt.

And like technical debt, it may not hurt immediately. It tends to become expensive later, when someone uses the outdated artifact as the basis for the next change.

👩🏻‍💻 What Changes for Engineers?

This is where SPDD becomes more than an AI tooling discussion.

If AI becomes increasingly capable of writing implementation code, some engineering skills become even more important.

1. Abstraction First

Before asking AI to implement a feature, we need to understand the objects, boundaries, responsibilities, collaborations, and constraints involved.

The interesting engineering question becomes less:

“Can I write this class?”

and more:

“Should this responsibility exist here in the first place?”

That is not a new software engineering skill.

AI simply makes it more visible.

2. Alignment

Someone still needs to define what the system should do, what it should not do, and which constraints cannot be violated.

SPDD makes those decisions explicit in the structured prompt.

The goal is to resolve important disagreements before implementation rather than discovering them after hundreds of generated lines have already been produced.

3. Iterative Review

AI-generated code still needs human review.

In fact, the more code generation becomes automated, the more important it becomes to have a disciplined review loop.

That does not necessarily mean reading every generated line with equal attention.

It means reviewing the right things at the right level:

• Does the implementation match the requirement?

• Does the design fit the existing architecture?

• Are the domain concepts correct?

• Are the safeguards being respected?

• Are the generated tests actually validating the intended behavior?

SPDD tries to make that review easier by giving reviewers something to inspect before the implementation itself is generated.

⚖️ What SPDD Does, and What It Doesn’t

There is a temptation to interpret a framework like this as a way to make AI-generated code predictable.

That would be going too far.

SPDD does not eliminate LLM uncertainty, and it does not guarantee architectural correctness or software quality.

The authors explicitly describe the goal as keeping the model’s non-determinism within more controllable boundaries rather than eliminating it altogether.

That distinction matters.

SPDD can make intent more explicit.

It can make design decisions easier to review.

It can make successful prompts reusable.

It can provide a mechanism for keeping those artifacts aligned with the implementation.

But humans still have to decide whether the requirements are correct, whether the architecture makes sense, whether the trade-offs are acceptable, and whether the resulting software actually works.

That is probably the most useful way to think about the methodology.

Alright! Wrapping up for today.

✨ Takeaways

What interests me about SPDD is not the prompt template itself.

We’ve been writing structured requirements, architecture documents, coding standards, design documents, checklists, and implementation plans for years.

The more interesting idea is the lifecycle.

Instead of:

Requirement → Chat → Code → Done

SPDD proposes something closer to:

Requirement
    ↓
Understanding
    ↓
Analysis
    ↓
Structured design
    ↓
Implementation
    ↓
Validation
    ↓
Synchronization
    ↺

The prompt becomes part of the engineering system.

It captures not only what we want to build, but also the reasoning, structure, constraints, and implementation decisions that guide the AI.

And because the artifact is kept alongside the code, that knowledge has a chance to survive the individual chat session, the individual developer, and the individual change.

That is the part I want to experiment with.

Because perhaps the interesting shift in AI-assisted software development isn’t that machines are getting better at writing code.

Perhaps it is that engineers are going to spend more of their time deciding what the code should mean before asking a machine to write it.

And that brings us back to the original question:

What happens when generating code becomes faster than understanding it?

Frameworks like SPDD are an attempt to make sure our engineering process keeps up.

In the AI era, software development may become less of a contest of model IQ and more a question of how effectively engineers can use their cognitive bandwidth to define, review, and evolve the systems they are building.

Be safe,
Marcos.

They want you to believe that typing code faster automatically equals shipping products faster.

But local speed rarely translates to global throughput… unless you have a lot of money and the right framework.

Are you seeing your developers crank out code at record speeds while your actual release cycle remains stuck in the mud?

If you are a Tech Lead and you are looking to scale AI-generated code without sacrificing architectural integrity, then this email is for you.

We are stripping the magic away from these tools in The A-Side. I will show you how the SPDD framework turns disposable chats into first-class, version-controlled artifacts.

We need to stop treating prompts like used tissues.

And the rest of the stack is just as loaded:

• The Read-Only Memory: Tim Berners-Lee and the radical 1993 decision to release the World Wide Web entirely for free.

• The Open Thread Club: A reader desperately needs help taming an exploding AI token budget.

• The Rendezvous: Upcoming developer summits in Bengaluru, Amsterdam, and Barcelona.

Before continuing, if you like my work and you want to support it, I would appreciate it if you could share this newsletter with your peers via:

💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky

Or just forward this email. Thanks in advance!

The Read-Only Memory

Today I bring you Tim Berners-Lee and his momentum when the World Wide Web was in place, and so a question came:

how to spread this thing

When the Web began to demonstrate its potential, he and his collaborator Robert Cailliau seriously considered the possibility of starting a company and charging for its use.

They even discussed various business models, but faced a problem: the experience with Gopher had shown that charging royalties could hinder the adoption of a technology still trying to take off, and that turning the Web into a commercial product could lead to the emergence of incompatible, fragmented versions.

Ultimately, they reached a conclusion unusual for creators of something with such immense economic potential: they were more interested in building something useful than in getting rich.

CERN finally opted to release the technology royalty-free on April 30, 1993, allowing anyone to use and develop it. Refs [1], [2]

I want to reinforce this sentence:

[…] They were more interested in building something useful than in getting rich. […]

Can you imagine that nowadays? I read you in the comments or replying this email.

In this section, we will focus on biographies of computer pioneers, forgotten historical white papers that remain entirely relevant, and independent blog posts that question the status quo of our industry.

Would you like to suggest some? I hear you! 👇🏻

📧 I have something for you!

The Open Thread Club

The following topic arrived quite soon in my inbox (as expected):

My company wanted me and my team mates to waste money in AI as much as possible, so we did. Now, that the cost is higher than they expected, they want us to reduce the cost. I want to reduce the cost but not the usage

— Anonymous cost reducer

This is a hot topic in my opinion. Reading on Bluesky, I find many people struggling with this. Do you feel identified with this? I do. Would you have a take on this for our Anonymous cost reducer reader? Share it in the comments!.

📖 My take: The first thing I did was install rtk tool to save tokens. It actually works for me.

Second, I use Haiku by default (I’m using Claude Code), and I just switch to Sonnet when I want the plan and iterate over it. Opus is just for really complicated plans. Fable when I’m ending the month… and I still have budget :).

Just with that, I managed to keep my money burning under control.

Any other tip you may have? Share it by replying to this email!

In this space, we will address real dilemmas about architecture, technical friction, or leadership situations sent anonymously by you.

Instead of giving theoretical or dogmatic answers, I will respond with honesty, sharing my own past mistakes in similar situations and the lessons I took away when trying to solve them.

You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻

📧 I have a tale to share!

The Rendezvous

This week I bring you conferences in India, Europe, and the US.

• For you, reading from Bengaluru (India), Open Source India 2026, happening on October 7th and 8th.

• In Amsterdam (Netherlands), the World Summit AI 2026 is coming on October 9th and 10th.

• And for those RUST lovers, the EuroRust 2026 will happen in Barcelona (Spain) and online from October 14th to 17th,

A radar of events about software engineering and technical leadership.

The priority here is not to be exclusively massive conferences, but to give visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know of an event worth sharing, the channel is open for you to send it to me and share it with the community.

Do you own an event or summit? Drop me an email! 👇🏻

📧 I know about an event!

The A-Side

Are you seeing your developers crank out code at record speeds while your actual release cycle remains stuck in the mud?

Maybe that question is too drastic; I know. My point there is:

How can we make our work with prompts more effective?

PDD wants to ensure that as we scale AI-generated code, we don’t sacrifice quality or architectural integrity.

☝🏼 Disclaimer: I have not tried this methodology yet. This is a summary of the framework, so you can get up to speed on this trend and give it a try.

Let’s go.

🎯 The Problem

Individual coding speed is rarely the true bottleneck in the software delivery lifecycle. When teams adopt AI assistants without a framework, they often hit four friction points that kill throughput:

• Ambiguous Requirements: Misunderstandings are turned into code faster, scaling the impact of every error.

• Review Fatigue: Pull requests become massive and frequent, making architectural inconsistencies harder to spot. For me, today, this is a huge impact.

• Integration Issues: Generated code does not automatically mean aligned code, leading to frequent testing failures.

• Production Risk: Reasoning about the risk of a change becomes nearly impossible as the volume of unmapped code rises.

It’s like buying a Ferrari and driving it on muddy roads: the engine is powerful, but road conditions and traffic determine your arrival time.

Here is where this SPDD framework comes.

👩🏽‍💻 What is SPDD? Prompts as First-Class Artifacts

SPDD is an engineering method that treats prompts as version-controlled, reviewed, and reused assets.

Nice definition, right? Let’s dive in a bit

👉🏼 Instead of relying on disposable chats, teams use structured prompts to capture requirements, domain language, and design intent.

The backbone of this method is the REASONS Canvas, which guides the AI from high-level intent to concrete execution.

Abstract parts (intent & design)

• R — Requirements: What problem are we solving, and what is DoD?

• E — Entities: Domain entities and relationships.

• A — Approach: The strategy of how we’ll meet the requirements.

• S — Structure: Where the change fits in the system; components and dependencies.

Specific parts (execution)

• O — Operations: Break the abstract strategy into concrete, testable implementation steps.

Common standards parts (governance)

• N — Norms: Cross-cutting engineering norms (naming, observability, defensive coding, etc.).

• S — Safeguards: Non-negotiable boundaries (invariants, performance limits, security rules, etc.).

SPDD enforces a “closed-loop” rule: when reality diverges or requirements change, you must fix the prompt first. This ensures the prompt remains the source of truth for the system’s logic.

☝🏼 Warning: Prompts are not tissues; don’t toss them after one use.

This is it for today’s issue. Next week, you will receive in your inbox the second part that completes this series: The SPDD Workflow: From Story to Code.

Be safe,
Marcos.

Welcome to this very first issue of The Optimist Engineer with the new format.

How many times have you been fed the lie that growing in tech is just a matter of accumulating years of experience?

The truth is that waiting quietly in your chair for someone to notice your hard work is a one-way ticket to career stagnation.

If you are a software engineer and you are looking to take control of your career path and actually land that next promotion, then this email is for you.

For The A-Side today, I am sharing the core strategies that truly drive professional success in our industry. We will break down exactly how to act for the role before you get the title and how to make your real-world impact undeniable with hard numbers.

That is just the start. Also in this edition:

• The Read-Only Memory: Ada Lovelace’s forgotten attempt to design a steam-powered flying machine.

• The Open Thread Club: My take on surviving environments where management claims every task is a top priority.

• The Rendezvous: Upcoming tech events to put on your radar in Oslo, Bern, and Madrid.

👉🏼 I leave here a short survey to get your feedback about this new format.

📋 I'll answer the survey!

Before continuing, if you like my work and you want to support it, I would appreciate it if you could share this newsletter with your peers via:

💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky

Or just forward this email. Thanks in advance!

The Read-Only Memory

You are probably familiar with Ada Lovelace’s biography.

Augusta Ada King, Countess of Lovelace (10 December 1815 – 27 November 1852), also known as Ada Lovelace, was an English mathematician and writer chiefly known for work on Charles Babbage's proposed mechanical general-purpose computer, the analytical engine. She was the first to recognise the machine had applications beyond pure calculation. Lovelace is often considered the first computer programmer.

— Wikipedia

But you may not know that her first major technical project wasn’t a computer: she wanted to build a flying machine.

Around the age of 12 or 13, she became fascinated by the flight of birds.

She didn’t just say she wanted to fly. She studied bird anatomy, investigated how their wings worked, and even conceived of a steam-powered flying machine. She herself described the idea of ​​building something that would allow her to travel directly over mountains and valleys.

The Computer History Museum preserves this story and connects it to what Ada would later call “poetical science”: the combination of imagination and science.

In this section, we will focus on biographies of computer pioneers, forgotten historical whitepapers that remain entirely relevant, and independent blog posts that question the status quo of our industry.

Would you like to suggest some? I hear you! 👇🏻

📧 I have something for you!

The Open Thread Club

Folks, in this very first edition of The Open Thread Club, a reader shared this just past Tuesday:

I work in a job environment where priorities are piled up. I mean, it’s not like priorities change, but all priorities are top priority. Any advice for handling this situation? Thanks.

— Anonyous.

First, thanks to our Anonymous reader for sharing this. I could not imagine a better way to kickstart this section.

Second, do you feel identified with this? I do. Would you have a take on this for our Anonymous reader? Share it in the comments!

📖 My take: There is not such a thing as “everything is TOP priority”.

☝🏼 Keep this in mind: not even for the person who asked you that. The person who asked you to have 2 sprints with 3 different priorities at the same time is not really expecting it, even though she/he will never acknowledge it.

👉🏼 What you have to do: Figure out what the most important priority is, what is the most impactful one; the one that brings the most value over the rest. That’s the one that you will prioritize for real. The rest will go later. Actually, what I used to do is rank them so that when I finish the first one, I know what to do next.

Let me know how it goes.

In this space, we will address real dilemmas about architecture, technical friction, or leadership situations you send anonymously.

Instead of giving theoretical or dogmatic answers, I will respond with honesty, sharing my own past mistakes in similar situations and the lessons I took away when trying to solve them.

You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻

📧 I have a tale to share!

The Rendezvous

For this section, I received many emails since last Tuesday, when I announced the change in the format for the newsletter. Thank you all for the support!

• Never went to this, but looks interesting: The NDC Oslo 2026 is happening from 14-18 September 2026 in Oslo (Norway).

• Also on September 17th, the Swiss Cloud Native Day 2026 will happen in Bern (Switzerland). It’s always a good time to bring some great ideas (and chocolates) from Swiss people.

• The GDG Madrid comes back from summer vacations with a new event “Liderazgo, equipos y desarrollo con IA”. Not sure if it will be in English too. Coming next September 22nd in Madrid (Spain).

The priority here is not to be exclusively massive conferences, but to give visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know of an event worth sharing, the channel is open for you to send it to me and share it with the community.

Do you own an event or summit? Drop me an email! 👇🏻

📧 I know about an event!

The A-Side

How many times have you been told that growing in tech is just a matter of “accumulating years of experience”?

In The A-Side today, I want to share with you the core strategies that truly drive promotions and professional success in our industry, based on my own trajectory from junior to Tech Lead.

🚦 Let’s take a break here, so say something super important: If, after reading this article, you feel that you are not able to act like that, no worries, that’s ok. And I mean it. Take the reading as an informative article and DO NOT STRESS YOURSELF trying to become a person that you are not. There are other ways to achieve the same. Drop me a message if you want to discuss this.

Engage! 🖖🏼

🎯 Act Before You Get the Title

Here is a hard truth about scaling your career: nobody is going to come to your desk, tap your shoulder, and say:

Bob, it’s time to become a Senior.

If you want the next level, you have to start acting like you are already in that role.

Take ownership of technical decisions, help your teammates, and solve problems beyond your immediate tickets.

I know: it’s not an easy task, and maybe it’s not fair, but from my experience, I can tell you this is a must-have.

Now, acting like a Tech Lead sounds great on paper, but what makes someone actually stand out when they are starting?

👩🏽‍💻 Adaptability and Real-World Impact

When hiring or evaluating junior engineers, nobody is checking if you can memorize textbook algorithms. What senior leaders look for is openness to change.

If the company needs you to move from Java to Rust or adopt a new AI tool tomorrow, your answer should be:

I’m ready to learn.

I know (again): It can sound like it’s not fair… and it’s not, but that’s the spirit that the majority of startups look for in Junior profiles.

You have the right mindset and the technical drive. But there is a silent career killer that holds back even the most talented engineers.

🗝️ Make Your Work Visible (Numbers Matter)

In a growing tech company, your manager does not have time to track every single line of code you write.

If you don’t communicate your impact, it simply didn’t happen.

🧐 Bring data to your 1-on-1s:

• “I reduced infrastructure costs by 12% with this optimization”.

• “We reduced production bugs dramatically after implementing automated testing in our pipeline”.

Soft skills and clear communication will take you further than pure syntax.

You now have the exact mindset to take control of your career path. Let’s wrap up for today!

✨ Takeaways

• Don’t wait for permission: Act as the role you want before you receive the title.

• Be adaptable: Mindset and willingness to learn beat stack loyalty every single time.

• Own your visibility: Measure your impact with numbers and present it to your manager.

☝🏼 Remember: Software engineering is not just about writing code; it’s about solving real problems and driving value.

What is the biggest challenge holding you back from stepping into your next career level right now?

Drop a message in the comments or reply to this email; I read and reply to all!

Be safe,
Marcos.

As the saying goes:

Everything changes.

I think you will love this change.

For a long time, The Optimist Engineer has been a weekly conversation in the form of a single-topic essay. We have delved into design patterns, technical pragmatism, architecture debt, and the lights and shadows of leadership.

However, if building systems teaches us anything, it is that rigidity is the first symptom of obsolescence.

To provide more complete value and make this community more participatory, the newsletter is evolving into a renewed structure with four distinct blocks.

The Read-Only Memory (ROM)

We will leave the usual suspects aside to explore readings with a different perspective.

In this section, we will focus on biographies of computer pioneers, forgotten historical whitepapers that remain entirely relevant, and independent blog posts that question the status quo of our industry.

Would you like to suggest some? I hear you! 👇🏻

📧 I have something for you!

The Open Thread Club

Software development does not happen in a sterile environment, and team dynamics rarely follow an algorithm.

In this space, we will address real dilemmas about architecture, technical friction, or leadership situations sent anonymously by you.

Instead of giving theoretical or dogmatic answers, I will respond with honesty: sharing my own past mistakes in similar situations and the lessons I took away when trying to solve them.

You can start participating RIGHT NOW! Click the button below and tell me your story so I can answer in the next issue 👇🏻

📧 I have a tale to share!

The Rendezvous

A radar of events about software engineering and technical leadership.

The priority here will not be exclusively massive conferences, but giving visibility to smaller, local encounters or emerging initiatives. If you are organizing a conference or know an event worth sharing, the channel is open for you to send it to me and share it with the community.

Do you own an event or summit? Drop me an email! 👇🏻

📧 I know about an event!

The A-Side

The heart of the newsletter remains untouched.

It will continue to be the weekly thematic article where we keep diving into architecture, design principles, and technical culture with the usual analytical and pragmatic approach.

So, what’s next?

Next Thursday, Sep 10th, you will receive the first issue with this new format together with a poll, which I would love for you to take part in so I can understand your feedback on the new format.

This change does not seek to add noise, but to build a richer, more transparent, and useful space for everyone.

What do you think about this change? leave a comment or drop me an email!

Be safe,
Marcos.

As usual, I take the whole of August to rest and recharge my batteries.

This means that you should not expect new issues during this month.

On this ocassion, I will not write here the list of the TOP issues at this point. Why?

I really wish you could get some rest and disconnect for a while.

In recent years, I have seen more people getting into trouble with stress, cognitive load, and burnout.

I don’t want that for you. I want you to be as healthy as possible, so I want to make my contribution.

In exchange, I'll tell you my trick when I get 2 weeks of PTO:

1. Put the laptop in the backpack.

2. And put the backpack in the closet/wardrobe/locker.

Do it and thank me later 😉.

Enjoy.

Best,
Marcos.

The world, the place you live in, is the sick place. Seahaven is the way the world should be.

— Cristof, The Truman Show

A safe place is important in technology as well, and you cannot ask every single user to implement security on their own.

Previously on Building an Enterprise MCP Platform...

We’ve built the foundation. Before we tackle how to lock down and secure our platform today, let’s quickly review the core decisions we’ve made so far:

• Vol. I (Deployment) - The Where: We escaped the localhost trap by moving MCP servers to the cloud. We mapped out our compute options, choosing AWS Fargate for low-latency, persistent SSE connections, and AWS Lambda for sporadic, stateless utility tools.

• Vol. II (Delivery) - The How: We automated the journey. We chose Docker to guarantee execution consistency and used Crossplane (or CI/CD pipeline wrappers) to abstract away the cloud infrastructure, letting developers ship code through simple, reusable YAML interfaces.

In today’s email, you will get the answer to the ultimate production question: How do we control who is actually allowed to talk to them?

If you are a Software Engineer trying to understand the main challenges at the time of deploying MCP Servers in Production, this email is for you. Know someone who might be interested in this topic? Forward them the email 👇🏻

Share

Let’s continue with the last topic: Security

You have to implement a single point where all the requests are authenticated through your Identity Provider (a.k.a. IDP).

You should not put that responsibility on the developers of the MCP Servers.

• Developers should take care of their MCP Server.

• You take care of the platform where they deliver that value, including authentication.

Please note that I say Authentication and not Authorization. In my approach, I decided to tackle Authentication only, leaving the possibility to the developers of the MCP Server to implement Authorization, if they want. Why do I do that?

• Simplicity. I wanted to keep the platform simple.

• Ownership. Each developer/team could have different needs in terms of Authorization (they will get the JWT anyway).

This is a decision you can make; Remember: tradeoffs.

Following the same pattern as before, you will have to implement an AWS Lambda function to act as an MCP Authentication, implementing the OAuth 2.1 protocol.

Below, you can see the architecture diagram, using AWS pieces.

Even though I will not describe the OAuth 2.1 process, let me describe a bit the flow of that architecture diagram:

• The AI Client (Claude Code-alike) has an MCP Server configured, but not authenticated. So the authentication process needs to be executed and, for that, a concrete request.

• That goes to your AWS CloudFront and from there to the Application Load Balancer. By the way, I picked an ALB, but it could be an AWS API Gateway; there is a small difference for our use case. If you want details about this decision, drop me an email or reach out to me on Bluesky.

• The request arrives at the MCP Authenticator, and from there the IDP that your company uses (such as OKTA, Keycloak, etc) will provide the information required by the AI Client to be able to authenticate against the IDP itself.

• The AI Client authenticates against the IDP and then requests again to the MCP Authenticator, so this will provide, through the ID, a Token.

• Once the AI Client has the token, the following requests will arrive at the MCP Server, with an authentication check in the middle.

This way, you provide an authentication mechanism, transparent to the developers of the MCP Servers, so developers don’t need to implement by themself.

The last part of this architecture is to have a way by which the users, a.k.a. the developers of the MCP Servers, can make their software available under this Authentication wall. For this, remember that your solution must satisfy the following:

1. Make your developers autonomous. This means that the owners of the MCP Servers must be autonomous in making their software available in your infrastructure.

2. CI/CD. This means that the owners must work in CI/CD mode, so your solution should be designed for that from the heart. No dependencies with other repos or systems.

3. Technology already known; don’t reinvent the wheel. This means that your solution should use a technology that is already familiar to your users, so they don’t have to make an extra effort to learn something else.

If you want to know the 2 options I implemented for this, drop me an email by clicking here 👇🏻 and you will get it for free.

📧 I want to know more!

Alright! Let’s close for today and the current series.

✨ Takeaways

Before you go, here is a quick summary of the core principles to keep in mind when securing your enterprise MCP platform:

• Security belongs to the platform, not individual developers: Do not put the burden of authentication on MCP Server developers. Centralize it at the platform level to free up dev teams and ensure consistent security standards across the organization.

• Authentication != Authorization: Decoupling authentication from authorization keeps the platform architecture simple. Handle authentication centrally via OAuth 2.1 and your Identity Provider (Okta, Keycloak, etc.), while leaving token-based authorization to individual server owners based on their specific business logic.

• Decoupled Architecture Pattern: Intercept and validate requests before they hit your MCP Servers by routing traffic through AWS CloudFront and ALB (or API Gateway) to a dedicated AWS Lambda function acting as your MCP Authenticator.

• Enable developer autonomy: Your platform solution must empower server owners to make their tools available through self-service CI/CD pipelines, relying on familiar tools and patterns so they don’t have to learn a new stack.

This is it; the end of this 3-issue series dedicated to explaining how to enable MCP Servers in the real world. Hope you like it. If yoy have any questions, feedback, or comments, you can reply to this email, drop a comment in Substack, or reach me in Bluesky.

Best,
Marcos.

We happy?… Vincent!… We happy?

We’re happy.

— Jules and Vincent, Pulp Fiction

Your users don’t need to know how their MCP Server reaches Production, but they need to know that there is a way that satisfies their needs.

In the first issue of this series, dedicated to enabling MCP Servers in the real world, you learnt how to choose the right way to deploy MCP Servers.

Before we dive into today’s pipeline automation, let’s ground ourselves with the core lessons from Vol. I: Keep Deployment Simple:

1. Centralize to maintain: Cloud deployment is the only way to guarantee instant security patches and seamless updates for non-technical users.

2. Choose compute wisely: We mapped out the decision tree, using Fargate for stateful, low-latency LLM interactions, and Lambda for sporadic, stateless utility tools.

3. Avoid over-engineering: We prioritized starting simple based on current sporadic usage rather than future hypothetical scale.

In today’s email, we transition from where the infrastructure sits to how we build a zero-friction path from a developer's repository to that infrastructure.

If you are a Software Engineer trying to understand the main challenges at the time of deploying MCP Servers in Production, this email is for you. Know someone who might be interested in this topic? Forward them the email 👇🏻

Share

Let’s continue with the next topic: Delivery

You need to define the workflow for developers to deploy their MCP servers from code to production.

If you read this newsletter for a while, you know that I’m a big fan of Kubernetes (when it makes sense), and the solution I give you to achieve a Cloud Native delivery of MCP Servers leverages Crossplane. If you want to know more about Crossplane, here I give an explanation about what Crossplane is and its main use cases.

Fundamentally, you have to build a pipeline to tackle Continuous Integration and Continuous Delivery (as usual).

1. CI - From code to Docker image

Yes, Docker is the magic here.

👉🏼 You have to implement a CI pipeline to be used by the developers (a.k.a. the owners of the MCP Servers to be deployed).

This pipeline will build the code and create and push a Docker image for that build.

The outcome of the CI stage is the Docker image uploaded into a Docker Image Registry, like AWS ECR.

📖 Why a Docker image?

Consistency. It offers consistency of the execution environment. This is, in my opinion, the number one advantage.

With a ZIP file, you’re completely dependent on the runtime provided by AWS (or any other cloud provider).

With a Docker image: the operating system, system libraries OpenSSL, glibc, native binaries, Python/Java/Node versions, installed tools, travel with your application.

2. CD - Deliver via Crossplane

You have to implement a CD pipeline to be used by the developers to deliver their stuff; in this case, their MCP Servers, packaged as Docker images, into AWS Lambdas.

In this pipeline, developers will be able to ship a Crossplane Composition to deploy their MCP Servers to the cloud, in our case, via an AWS Lambda. The Composition must represent their use case (deploy an MCP Server encapsulated into a Docker image) and just that. Let me clarify what I mean by just that.

The developers must have nothing to do with IAM roles, authentication, Lambdas, or any other platform business. The Crossplane Composition will deploy all the corresponding pieces that the Platform Team, Security Team, and others agreed (on behalf of developers) to deploy MCP Servers in the cloud.

📖 Why Crossplane?

Abstraction. It abstracts away the underlying complexity, allowing developers to focus on delivering software through a simple interface (even if it is YAML) that is centered on use cases, without having to bear the cognitive load of deploying to the cloud.

⚠️ Important note: If you are not in Kubernetes, just discard Crossplane (not worth having Kubernetes just for Crossplane) and implement the same abstraction using another abstraction layer, such as GitHub Workflows, Terraform, CDK Framework, or something homemade by your organization.

Let’s close for today with some takeaways.

✨ Takeaways

That’s it; does it look simple? Of course, it is not; You and I know that the heavy lifting comes in:

1. The implementation of the CI pipeline should be generic enough to support different languages and frameworks, but not so generic that it becomes difficult to use. If you want to dig more into this, I wrote about how the MAKEFILE approach can help you strike this balance.

2. The implementation of the Crossplane Composition should focus on the use case and expose an interface (YAML properties) that addresses it. Reaching agreement among developers on that interface will be a challenge, I can tell you that upfront.

At the end of the day, you have to keep in mind the following:

1. Create reusable pipelines for developers.

2. Abstract the complexity of the platform, so developers can focus on their business and deliver, and you have the flexibility to change the platform transparently in case it is needed (today Lambdas, maybe tomorrow Fargate).

Coming up in the next issue...

Now that we have covered where our servers live (Deployment) and how to get them there automatically (Delivery), we are ready to face the final boss of production readiness: Security. In our next and final edition, we will tackle how authentication, authorization, and secure governance work for your internal AI protocol servers.

Best,
Marcos.

Welcome, to the real world.

— Morpheus, Matrix

All the tutorials on YouTube tell you how to deploy an MCP server locally and, sometimes, even in the Cloud.

All of them have the same problem: They don’t solve a real-world problem. That’s what I bring you.

This is the first of three newsletter issues dedicated to how to enable MCP Servers in the real world.

In today's email, I'll walk you through the main problems to solve and a practical approach to tackling them when you have to deploy MCP Servers in Production at scale.

If you are a Software Engineer trying to understand the main challenges at the time of deploying MCP Servers in Production, this email is for you. Know someone who might be interested in this topic? Forward them the email 👇🏻

Share

You most likely have the following use cases knocking on your door:

1. Development teams need to deploy MCP Servers so their users can use them across the organization through Claude Code, Cursor, etc, but they don’t know how to make it happen.

2. Product organization and other teams create quick-and-vibe proof of concepts they need to validate, but they have the same issue than develoepers, or even worse, because they are not even technical enough to understand how to do it.

With those use cases in mind, your challenges are the following:

• Deployment. Where will the MCP Servers be running so the users can use them through their AI clients?

• Delivery. Alright, you know where the MCP Servers will live now; how do you make them arrive there?

• Security. How will authentication and authorization work for the MCPs?

You need a platform that helps the teams to achieve their goals quickly.

Let’s start with the first topic: Deployment.

👉🏼 Taking into account the use cases described at the beginning, you need to deploy to some kind of cloud instance. Why?

• You can't expect MCP server owners to be responsible for distributing their software to users for local execution.

• What about updates? You may want to distribute your MCP server through an AI Marketplace, but ensuring that updates are applied depends on the AI client's configuration.

• At least some of your users aren't technical enough to deal with Claude Code or Cursor commands for installing and configuring MCP servers. In fact, they probably don't even know, or care, what an MCP server is.

Those three reasons can be summarized as follows: You cannot expect MCP server users to deal with the technical details of managing the setup.

👉🏼 The MCP Server should be available wherever it must be, so no technical users could tell Claude Code:

Hey, I want to use the application available in http://my.company.com/mcp/my-company-custom-designer

Another important point is maintainability, which becomes much simpler when you deploy in the cloud, at the time of:

• Security patches released by the owners of the MCP Servers will arrive all at once to their users.

• New features and maintainability will follow the same path, straight to the users.

The last part is how to deploy the MCP Servers into the cloud. If we focus on a cloud provider like AWS, we can find multiple options, such as:

• Lambda Functions.

• Fargate.

• S3 bucket.

• …

👉🏼 My recommendation: based on your current use cases, perform an analysis and pick up the fewest options as possible, so your platform becomes simpler.

📖 In my experience, a container technology like AWS Lambda or Fargate works pretty well for the use cases described above. But how can you decide?

Choose AWS Fargate if:

• Your MCP server is frequently used or in production: It needs minimal and consistent latency so that the LLM’s interaction with the tools doesn’t feel slow.

• You use HTTP transport with SSE: The standard for remote servers requires persistent connections, which Fargate handles natively and efficiently.

• Your agent maintains a long workflow: Complex data analysis or coding tasks that take more than 15 minutes or that benefit from keeping variables and state in memory.

• Cold start is a performance problem: Even though AWS Lambdas have improved a lot on this, maybe your case cannot afford the cold start of an AWS Lambda.

Choose AWS Lambda only if:

• Usage is extremely sporadic: An MCP server that is only called a couple of times a day, where maintaining an active container on Fargate (even a small one) doesn’t justify the minimum monthly cost.

• You expose simple event-based tools: Tools that perform a quick “fire and forget” action (e.g., “send an alert to Slack”, “check the weather on an external API”) where cold-start latency is not critical and uses a different transport mechanism or an intermediate API Gateway that translates REST calls to Lambda calls.

☝🏼 There is no “the best choice for deploying MCP Servers”, just different options based on the nature of the MCP Server.

📖 What did I do? I’ve started deploying MCP Servers via AWS Lambdas because the current usage of the MCP Servers is still sporadic.

A lot of things to process. Let’s wrap up for today.

✨ Takeaways

To make sure you don’t get lost in the infrastructure weeds, let’s look at the three or four key ideas that will shift your deployment approach from day one:

• The Deployment Decision (Local vs. Cloud): Stop trying to distribute MCP servers locally. If your users are non-technical or you need instant security patching and feature delivery, your viable choice is the Cloud. Treat MCP servers as centralized web services, not local binaries.

• The Compute Decision (Fargate vs. Lambda): When deploying on AWS, do not guess. Choose your compute model based on these strict technical boundaries:

  • Choose AWS Fargate if: You are running production-grade servers requiring consistent, low-latency; you rely on standard HTTP transport with Server-Sent Events (SSE), which requires persistent connections; or your agents run long, stateful workflows that exceed Lambda’s 15-minute execution limit.

  • Choose AWS Lambda only if: Your MCP usage is extremely sporadic (to avoid the idle costs of a persistent container) and your tools perform quick, stateless, “fire-and-forget” actions (like sending a Slack alert) where cold-start latency is acceptable.

• The “Pragmatic First” Rule: Don’t build for hypothetical future scale. Start with the simplest, most cost-effective option that matches your current sporadic usage (even if it’s Lambda as a starting point) and evolve as usage data demands.

Coming up in the next issue...

Now that you have a clear grasp of the where (Deployment), the next edition will dive straight into the how: the challenge of Delivery. We will explore how to seamlessly automate the delivery from the developer’s repository right into the cloud without friction.

Best,
Marcos.

Because releasing software should not feel like a coin toss, especially not on a Friday at 6 p.m., when everybody is already mentally halfway into the weekend, and the margin for dealing with surprises is much smaller than we would like to admit.

If every release feels risky, the problem is usually not the release itself. The problem is the system behind it.

In today’s email, you will learn the pillars that help you build software in a way that makes shipping safer, calmer, and more predictable.

And I do not mean only coding practices. I mean everything that shapes the Software Development Lifecycle, or SDLC.

At a high level, three things matter:

• Housekeeping principles

• A system that speaks

• Observability that helps you anticipate and react

A good approach is not to attack them one by one from top to bottom. It is better to work across them gradually, improving a bit of each and iterating over time, because that is usually how real systems improve in the real world.

This is where release confidence starts.

Housekeeping principles

Before your system can help others, it has to be able to help itself.

If your systems are not stable, understandable, and maintainable, you will not create real value for your customers, because even if the product looks good from the outside, the internal machinery will keep creating friction, uncertainty, and avoidable risk.

This is where the basics matter more than people like to admit.

1. Make roles clear

If people do not understand their role, ownership disappears.

That is how you end up with a red monitor in production and nobody acting, not because people do not care, but because nobody feels clearly responsible enough to move first.

A team with unclear roles hesitates. It avoids decisions instead of solving problems, and that hesitation becomes part of the system as much as any technical debt.

2. Use a common programming language

If only one person understands a service, you do not have a system you can trust. You have a bottleneck.

Ownership drops, debugging slows down, and the whole service becomes riskier than it needs to be, because every meaningful change or incident ends up depending on the same small number of people.

Software is not only technical. It is social too, and the social side matters more than many teams realize until production starts asking uncomfortable questions.

3. Decouple your applications

The more isolated your system is, the safer it becomes to change, because failures are less likely to spread in unexpected ways, the responsibilities of each module stay clearer, and the whole system can tolerate change without collapsing under its own coupling.

That is why decoupling matters so much.

Inside the application, it means keeping modules properly separated and making sure a failure in one place does not cascade uncontrollably into others. Outside the application, it means avoiding hidden coupling through infrastructure, configuration, or assumptions that nobody wrote down but everybody has been quietly relying on.

A system that speaks

If your system cannot explain what is happening, you are blind in production.

Do you remember the sentence from the Clean Architecture book, “The architecture that speaks“? This is the same idea.

Your logs should make it clear whether a failure comes from

• Infrastructure.

• External dependency.

• Your own service.

If you cannot tell where the problem started, you will waste time blaming the wrong layer, and in production, that kind of confusion is not a minor inconvenience; it is time your users feel directly.

A good system answers questions quickly, and it does so in a way that helps you move, not just stare at the screen:

• What failed?

• Where did it fail?

• Is it internal or external?

• Is it isolated or systemic?

If your logs cannot answer that, they are noise.

Anticipate and react with observability

The best moment to detect a problem is before your users do.

Observability is not about having dashboards for the sake of it. It is about designing signals that help you act while there is still room to do something useful.

Early warning signals

These alerts tell you something is drifting before it becomes visible to the customer:

• Latency increasing.

• Error rates are growing.

• Queues are building up.

• Resources saturating.

Their value is not panic, but time. They give you time to investigate, time to understand what is changing, and time to act before a small deviation turns into a production incident.

Failure signals

When something is already broken, you need clarity more than anything else.

At that point, the alert should make it obvious what is failing, how bad it is, and what to do next.

This is where runbooks matter, because a good alert without a clear action is incomplete, and a paged engineer without a clear first step is often forced to improvise under pressure, which is exactly what good observability is supposed to reduce.

A runbook should answer:

• What does this alert mean?

• What likely caused it?

• What to check first?

• What to do next?

Short. Concrete. Actionable.

In a future issue, I will go deep into something important: How to make releases actually safe.

So far, let’s wrap up for today.

✨ Takeaways

Shipping software at 6 p.m. on a Friday shouldn’t feel like an extreme sport. If you want to move from anxiety to total peace of mind every time you push to production, keep these three golden rules in mind:

• Isolate the impact (Decoupling): Design your application so a failure in one module doesn’t bring down the entire system. When you contain errors locally, changing code becomes infinitely safer.

• Make your system speak (Clear logs): You are flying blind in production if your logs can’t answer three questions in seconds: what failed, where it failed, and whether the issue is yours or from an external API. Less noise, more context.

• Never improvise under pressure (Runbooks): An alert without a clear action plan is useless. Every critical page must include a short, direct document mapping out the first three steps to fix the issue. You defeat panic with clear instructions.

From here, I would like to hear from you about your tales deploying in Production and what you do in order to get confident for each release.

Best,
Marcos.

Of course, we talked about work. I am not saying it is a good idea to talk about work during a dinner with friends; I am just saying it is today’s reality, and that carries a lot of meaning, such as:

• What everyone is up to.

• How we use AI in our jobs.

• Uncertainty about where our profession is heading.

Clearly, the uncertainty point took up quite a bit of time.

Throughout the conversation, one of my friends asked:

Guys, with all this AI stuff, how do you interview people applying for a Software Engineer position?

In today’s email, I will tell you what my current approach is for interviewing candidates in the early AI Native era. Specifically:

• Live coding test: yes or no?

• Using AI for the technical test.

• What gives me the most value in identifying a good candidate in the era of AI.

If you are a Software Engineer or Tech Lead involved in designing and running job interviews to hire Software Engineers, this email is for you.

Know someone who might be interested in this topic? Forward them the email 👇🏻

Share

Now, let’s get down to business.

Live coding test: yes or no?

This was the first thing that came up in the conversation, and I personally have a strong opinion on it.

In my opinion, live coding tests are dead. In fact, they were already dead before the arrival of AI, at least for senior profiles.

Why?

Nowadays, coding tests do not bring enough value to invest the time of two Software Engineers during a live interview with another person, since we have machines (Claude Code, Cursor) to generate code.

👉🏼 In 2027, code is going to be much less important than it is today. Things like design patterns, software architecture (MVC, hexagonal, etc.) will take a back seat, overtaken by other aspects such as:

• Code efficiency. AI code works, but is it optimal in terms of performance?

• AI-optimized code. A lot of code means a lot of tokens and a lot of money spent; this is something you know perfectly well today. Therefore, the code generated by AI in 2027 must be optimal from the start, so that the cost of creating it is optimal and its subsequent modification by the AI is cost-optimal as well.

For junior profiles, I still see some value in it, but not so much to know if they understand the language syntax, but rather to understand how their mind works when programming, whether they use patterns, and what tradeoffs they evaluate.

At this point, you might be wondering:

So, do I ask the candidates to use AI live?

Using AI for the technical test

There could be an alternative to the live coding session, but one that is more AI Native: live code creation but using AI.

☝🏼 However, this variant has certain challenges that I consider a blocker today:

• To program with AI, you need a paid account. Obviously, a company cannot expect candidates to pay out of pocket to spend tokens programming with AI for a live interview. In that case, how is AI usage managed?

• Waiting times for the machine to do its job. From the moment the developer asks the AI for something until the result appears, time passes; dead time that can lead to awkward silences and, worse, a waste of time for both interviewers and the interviewee.

As I said at the beginning, I think these are barriers that can make an interview even more difficult.

👉🏼 Instead, I think you can ask the interviewee about how they use AI today, and their opinion on using AI for code generation.

Why?

Because it will give you clues as to:

• Do they have the experience your company needs regarding AI usage?

• Do they fit your company’s stance on those aspects?

So, what can give me value in a face-to-face interview?

What gives me the most value to identify a good candidate in the era of AI

Two key aspects.

1. Cultural fit

You need to make sure the candidate is a cultural fit for your company. If the person is not aligned on:

• Values

• Goals

• Growth expectations

• ...

You are going to waste your time, you will fail at your goals, and the company’s reputation will suffer.

I won’t expand much more on this topic, as you can find interesting articles about it in this same newsletter.

• Ensuring to hire the right person

• The dilemma of the person with willingness but lack of experience

2. System design

☝🏼 This seems key to me today.

More than ever, you need candidates to have the ability to think about:

• The system.

• Dependencies.

• Global architecture.

• Making decisions based on trade-offs.

• The product to be built.

The largest part of your interview should revolve around system design.

If you are interested in learning System Design, I don’t have much about it in my newsletter, but I can recommend:

✨ Takeaways

So, what to keep in mind:

• Live coding is obsolete for seniors: Spending the engineering hours of two interviewers to watch a candidate write lines of code is a poor use of resources. In the era of Claude Code and Cursor, standard code generation is a solved problem (kind of).

• The problem with live AI testing: Running live coding sessions with AI introduces friction, such as managing paid tool licenses for candidates and dealing with awkward, time-wasting lag while waiting for AI outputs.

• The interview sweet spot (System Design & Culture): The true signal of a great candidate in an AI-native world lies in their architectural thinking and cultural alignment. Shift your interview focus toward global architecture, dependency management, making trade-offs, and ensuring core values match your team’s vision.

Now it’s my favourite part. What are you doing in terms of hiring? What are your approaches in this early AI Native era? Looking forward to your comments!

And then fail because they didn’t understand the business they were building.

In today’s issue, I want to share why understanding the domain is one of the most important skills in software architecture, especially when building distributed systems, and even in the era of AI code generation.

Most architectural problems don’t start with technology but with a misunderstanding of the business.

Have you ever felt like everyone on your team speaks a different language when designing a system?

In today’s issue, I want to share a small conceptual correction that will save us major headaches when designing distributed systems, because we often mix apples and oranges when talking about architecture.

What a Domain is NOT

When a team starts building software, it’s common to find purely technical divisions like a user service, a database service, or an email service.

But the domain has nothing to do with Java, Python, PostgreSQL, or Kafka. All of those are simply technological decisions.

☝🏼 The domain exists even if there is no software; if we turned off all of an airline’s servers tomorrow, the concepts of ‘Booking’, ‘Flight’, and ‘Overbooking’ would still exist in their business.

So, What Exactly Is a Domain?

According to Eric Evans in Domain-Driven Design (DDD)

The domain is the sphere of knowledge or activity—specifically, the problem area that the user is trying to solve with the program.

👉🏼 The domain is the problem we are trying to model, not the technical solution or the database.

A large domain (like E-commerce) is divided into specialized areas with their own rules, which DDD calls Subdomains:

• Catalog and Inventory

• Ordering and Billing

• Logistics and Customer Service

Bounded Context: The Boundary of Your Model

If you ask around your company what a “Customer” is, for billing, it will be a legal entity that pays, and for support, it will be a user opening tickets. Both are right.

That’s why we need a Bounded Context, which is the explicit boundary within which a business model has a precise and consistent meaning.

Mixing these boundaries without clear borders is the reason why software in large systems becomes fragile, error-prone, and extremely difficult to understand.

At this point, you may ask:

Why this matters in Distributed Systems?

In distributed projects, you don’t just divide code; you also divide responsibility, data, and communication between autonomous teams (Conway’s Law).

The classic mistake is creating services based on database tables (`UserService`, `ProductService`), which leads to cascading calls and a distributed monolith.

👉🏼 DDD proposes looking for business boundaries instead of arbitrary technical frontiers; therefore, a microservice should naturally map to a Bounded Context.

Protecting the Domain: Hexagonal, Clean, and SOLID

Once you identify your business boundaries, you need tools to protect that core from external contamination:

• Hexagonal and Clean Architecture: They ensure that the core business rules remain independent of the UI, frameworks, and databases using adapters. The domain doesn’t know what REST or AWS is.

• SOLID Principles: They don’t define the domain, but they provide discipline at the module and class level so that the business logic doesn’t get contaminated with technical details of SQL or protocols.

You have explanations about what a Domain is. Let's wrap up for today.

✨ Takeaways

Keep this in mind:

• The domain is the business: The software structure must reflect the business problem, not the chosen technology.

• Poorly defined boundaries = Chaos: The main consequence of not understanding the domain is drawing the wrong borders, causing coupling and architectural debt.

• Isolation tools: DDD is used to model complex domains; Clean, Hexagonal, and SOLID are the shields that prevent technology from muddying that model.

If I had to summarize everything in a single sentence, it would be this:

The structure of your software should reflect the structure of your business, not the structure of your technology.

Understand the domain first. The technology decisions become much easier afterward.

Write it in the comments, I read and reply to all!

If you're a software developer overwhelmed by the increasing number of pull requests to review as AI agents accelerate development, this email is for you.

The problem you have

Let me tell you where you are:

• You and your team adopted AI for development, using Claude Code, Cursor, or GitHub Copilot.

• You clearly see a positive impact; you and your team are able to do more work in less time. You don’t visit Stack Overflow anymore.

• And you want to keep “human in the loop”, meaning, you review all the pull requests opened. Yes, you caught AI in the act for some bugs already! So you have still to pay attention to what goes to production.

What’s your problem? You have many more pull requests to review.

And not only that.

Those pull requests are quite big. Maybe the same size as when your peers coded without AI, but now it’s different.

Before, you had:

And now you have:

👉🏼 In summary, you have more pull requests than ever, and they’re too large to review efficiently.

Does this ring a bell to you? I would love to hear about your experiences with this. Send me an email or drop a comment in Substack.

📧 Let me tell you a story

You are not alone, though. This is becoming a pattern in tech companies during the transition to AI Native.

Many people shared with me on social media how much they're struggling with this challenge. The growing volume of code reviews is consuming more and more of their time. Some sentences that I can write here are:

AI is a code-vomiting machine.

Another sentence:

The machine’s goal is to spend tokens and tokens, so you get code and more code.

👉🏼 The code review phase has become the bottleneck, when before it was the implementation or Product Management.

☝🏼 Is this true? In my opinion, yes, it is true.

You may ask:

Marcos, are we doomed to only do code reviews?

I don’t think so, at least, so far. It took me a while, but I found a way to:

1. Keep the human in the loop for code reviews,

2. And keep the increasing speed of development thanks to AI.

The solution

In a nutshell:

1. Use SKILLs so the agent works with SOLID principles, eventhough your previous code does not follow those.

2. Demand to your agent keep small pull requests, even though they are many. Ensure the agent saves that in its memory.

3. Demand to your agent to write an ADR/code-change-report for the pull request.

Now, let me elaborate on each item.

☝🏼 About the SKILL. You can rather try some from the Internet, like skills.sh, either create your own, or just add that requirement in your prompt.

Why I found this important? Because with that in its memory, the agent tends to create more organized and encapsulated code (which is a benefit of SOLID) and so it will make your code review easier to follow up.

📖 A pro-tip on this: Always start the the plan mode of your favourite AI agent. That helps you to understand what the AI agent will do and what will not do. Always iterate, do not go with the first plan provided; ask questions, so you can understand if the requirements are satisfied, and ensure you understand what will happen in the change.

✌🏼About the small pull requests. The AI tends to generate many code but, you have to rememeber this: the AI agent is there to do what you ask. Yeah, I know, sometime it does not listen properly, and you have to insist. You can ask to split a task in multiple pull requests and, my recommendation is that you explain to the agent why you want it that way: to make the code reviews of the humans more easy.

Why I found this important? As I mentioned before: small pull requests can be reviewed with more love and faster; the process becomes more efficient and effective.

📖 A pro-tip on this: Use the same human to review all the pull requests. Avoid the context switching for your peers, by rotating the responsibility of reviewing the code of your 5 pull requests, so only one person gets into it, making her/his review easier.

🖖🏼 About the ADR/code-change-report. The idea is quite simple:

• Humans read natural language better than code, no matter how expert you are in a concrete language.

• So, having a meaningful text that can help us to understand what has been done, will help us to achieve a better code review.

Maybe the word ADR is too much for a pull request, but I hope you get the point.

If you can ask your peers to keep small pull request, to can for sure demand that to your AI agent.

If you want to go deeper on this, I suggest you to read this post here entitled Code Reviews in the AI ​​Native era.

📖 A pro-tip on this: To achieve this, Wether on the pull request description or in a separated file (HTML, Markdown), you must ask the AI agent to create a:

Summary of the work so the developer to perform the code review can easly understand the changes in the pull request, highligting the important parts to pay extra attention.

Those three points helped me, and so I hope they will help you, to have more efficient and effective code reviews, keeping the pace of more pull requests and ensuring the right quality for the human-in-the-loop code reviews.

Beyond those three points, another practice that helped me was following the I.N.V.E.S.T. principle and taking the time to write clear and small Jira tickets (or whatever tool you use to organize your work).

✨ Takeaways

We started this email saying:

The code review phase has become the bottleneck.

With the solution I brought to you, we are making (yet another) shift left:

We are putting more effort on the previous work with the AI, during the plan of the work to do, before open the pull request.

👉🏼 Because the effort now goes more on the plan phase, you are making the whole process more scalable.

At this point in time, I believe this the way to work with AI agents.

I would love to hear the tips and tricks you use so far to tame the AI agents. Send me an email to write a comment; I read them all!

Best,
Marcos

In today’s issue, I want to share with you one of my failures in communication and how I overcame it.

If you’ve been following me for a while, you’ve already heard a lot about this. I’m not just repeating myself; I’m providing more resources to help you improve the key skill (communication) every Software Engineer needs, especially in the age of Agentic AI.

Three mistakes:

• Reuse the same diagram.

• Focusing on feelings instead of data.

• What to do when the conversation is about bananas?

☝🏼 By the way, this is a concrete example from real life.

Reuse the same diagram

I think this was my main mistake by far.

I had a meeting with the Product team to explain our approach to the roadmap’s requirements and use cases. To support the discussion, I used the same system diagram I use with my fellow engineers, people who have deep technical knowledge and don’t get lost in the moving pieces.

Consequently, the Product team felt the need to clarify every single component in the diagram. This was a natural reaction; they wanted to contribute to the solution and needed to understand what they were looking at. However, we ended up getting bogged down in the details and missed the main objective of the meeting.

👉🏼 To pivot from my mistake, it would be better to use visuals tailored to your audience and keep only what is relevant to the discussion. Otherwise, we risk creating noise, like debating AWS SNS data formats, instead of staying focused on the meeting’s goal.

Focusing on feelings instead of data

Another mistake I used to make was the usage of feelings and memories during the meeting, instead of numbers. This happened to me as well in the example I’m using today.

I went to the meeting with the right preparation. Because of that, I had to start using my brain to make it speak in a way that my audience could understand what I wanted to transmit; This is the basis of communication indeed, and it’s good, but not enough, because you can commit mistakes or forget things properly, and your audience can find a flaw in your speech.

Forget about what you remember in the past. Show data, show numbers! Prepare your meeting to showcase numeric information, with dates, rates, or whatever applies to your use case.

👉🏼 It’s better when you use information that your audience can read and understand by themselves.

What to do when the conversation is about bananas?

This could happen, and it happened.

I found myself having to explain to the Product team why we were using a specific data format for the messages passing through AWS SNS. I can tell you that’s not what I wanted to talk about. At that point in the meeting, it felt like it was too late to try to steer the conversation back to the original topic.

👉🏼 My recommendation at this point is to try to end the meeting, wrap up, and call for another meeting (yeah, I know).

You have to make your audience understand that you need to go through all the points discussed to adapt your solution.

For that, you will invest the time until the new meeting to adapt your visuals and your speech, based on the points discussed above, and remove from the table parts that match with:

1. Bring noise to the conversations.

2. Make the system complex to understand.

3. Not useful for the goal of the meeting.

In order to know if something matches those 3 points, I ask myself: Will my audience ask for “this” that is not relevant to my goal? If yes, drop it.

From here, you will create layered diagrams and speeches, each of which is focused on a different audience you will meet to achieve your goal.

At this stage, you ask the following:

Marcos, what do I mean by layered resources?

I mean that, from the raw and complete information about the topic to discuss, create visuals and speeches for each of the personas/audiences you are targeting.

📖 For example

• For your dev teammates, create visuals and text descriptions that make it pretty clear how your system works, so they do not get surprised when they find “that missing Lambda function there”.

• In the case of your Engineer Manager, maybe you have to scale up +1 level of abstraction. Maybe she/he does not need to know all the possible Kafka topics or microservices in place, but a diagram where is displayed the technologies used, the changes to be done, and the risks.

• Thinking about your Product Manager, definitely, she/he does not need to know if we are using AWS Lambdas or SNS or whatever. Use plain boxes without naming technologies and arrows to join the pieces and showcase the flow.

Keep in mind the visual I gave you in the section “Reuse the same diagram“.

👉🏼 You should go from super-low level to higher layers of abstraction, each of them meant for every kind of persona.

Let’s finish for today.

✨ Takeaways

Always take the time to prepare for your meetings by tailoring them to the specific audience.

It’s easy to let this slip through the cracks, especially when you’re caught up in a high-speed environment and focused on your daily routine. If it happens to you, don’t sweat it. Just schedule another sync to buy yourself some time, go over the main points again, and pivot your presentation to match their level.

In concrete terms, keep this in mind:

• Do not use the same visuals or the same speech to explain a concept to different roles.

• Use layered resources for the different kinds of audiences.

Hope you enjoyed today's email. I would love to hear from you about what are your experiences communicating. Drop me a message, I read them all!

Marcos, we are a 5-person startup, and it’s time to scale up our organization… because the money came in!

First, I said:

Congratulations!

Second, it was about working together on a proposal to scale up their organization.

We worked together in a couple of sessions, and she ended up with a growing plan that makes sense, based on their roadmap.

At some point, she told me:

Marcos, this is gold… this can help many people.

So, a tic happened: Why not provide the very same resources, already organized, to my readers?

In today’s email, I’m sharing a list of resources to help you create a growth plan for your engineering organization, whether you are a 5-person start-up or beyond.

In this email, I will add the links. If you are interested in this topic, I could write a detailed series for it. You tell me 👇🏻

I have 2 major categories for you to go through:

• Reading Content: Content you can read in this newsletter, organized by order

• Video Content: The talks I’ve performed about company growth, which include lessons learned.

Reading Content

• Ensuring to hire the right person

• Do you need a Rockstar developer?

• The dilemma of the person with willingness but lack of experience

• Hiring for an Hypergrowth company

• Hiring going into Hyper Growth - HR

• Hiring going into Hyper Growth - Engineering

• Onboarding Junior profiles in Hyper-growth

Video Content

• [English] Lessons learned hiring as a teamwork - Marcos Fermín Lobo e Inma Jimenez Garcia - DevOpsDays Madrid

• [English] From Cloud Native to AI Native or [Spanish] De Cloud Native a AI Native

• [Spanish] Lecciones aprendidas trabajando en una empresa Unicornio en modo hyper-crecimiento

I want to specially thanks to Jose Emilio Labra, who gave me this amazing opportunity to share my experiences with the students.

Now, let’s jump into it.

When I started my career, I believed that professional growth was a simple matter of time. I thought that after about five years of cranking out code, someone in the company would magically come to pat me on the back and say:

Marcos, we’re going to promote you; it’s your time to lead.

Fortunately, I realized that the real world doesn’t work like that at all.

In today’s issue, I want to share my most sincere experience on how you actually grow and build a career in a tech product company. We will cover:

• The myth of automatic promotion and the two main career paths.

• The radical importance of openness to change.

• Why you must act like the role you want before you get it.

• The vital need to make your work visible to management.

If you’re aiming for a promotion and want to understand how things really work behind the scenes, this edition is for you.

The Myth of Automatic Promotion and the Two Paths

As I was saying, growth in the tech industry has nothing to do with the time you spend warming a chair. In the past, it seemed like the only natural destination for an experienced developer was to become a manager, whether you liked leading people or not.

Luckily, that has changed. Today, you have two main paths to scale:

• The Technical Track (Individual Contributor): This is your path if your passion is to stay close to the code and architecture. You evolve into high-impact roles like Tech Lead, Staff Engineer, or higher, where your focus is on solving strategic architectural challenges without involving yourself in the hierarchical management of people.

• The Management Track (Engineering Manager): Your responsibility shifts. Your core focus is no longer coding, but genuinely caring about the career development of your engineers, aligning product goals, and ensuring your team has what it needs to perform at its best. It’s a different mindset.

Attitude is Everything: Openness to Change

If you just graduated or even if you are already a Senior, there is something fundamental you must internalize: openness to change.

In job interviews, it is assumed that you have a solid programming foundation. What truly sets you apart is your reaction when asked:

I know you master Java, but if the project requires it, would you be willing to code in Rust?

People who show open-mindedness:

yes, I will learn whatever is necessary.

These are precisely those who end up making huge leaps in their careers.

Act Like the Role You Aspire To

I’m going to be direct:

👉🏼 No one is going to come out of nowhere to say:

we’re promoting you,

So then you start acquiring responsibilities.

Especially from Senior roles onwards, you must act like the role you want to obtain before it is officially granted to you.

☝🏼 You must proactively demonstrate that you are capable of making design decisions, arguing at a technical level, and leading de facto. It is the only way to make it clear that the position already belongs to you morally.

Make Your Work Visible

This is, by far, the point where we technical profiles fail the most. I know, for those reading this newsletter, this already sounds familiar to you.

Still.

In an early-stage startup, it’s easy for your manager to see the quality of your work directly. But when the organization scales, your Engineering Manager will be swamped with obligations; they will no longer have eyes to see the daily grind of the whole team.

👉🏼 You have to make it noticeable. It depends exclusively on you.

Strategically leverage your 1-on-1s or your evaluations. Don’t improvise; bring data. Show charts: Look at how the number of bugs in production has dropped since I implemented my initiative,” or “I’ve managed to reduce our infrastructure cost by 12%.” If you don’t value your own effort, no one else is going to come to tell management how great you’ve done.

✨ Takeaways

Let’s wrap up. Load these concepts into your backpack:

• Growth is measured by impact, not years: Seniority does not guarantee promotions.

• Choose your path: Decide if you provide more value solving technical challenges (Individual Contributor track) or empowering other people (Engineering Manager track).

• Embrace flexibility: Your adaptability to new ecosystems is your main competitive advantage.

• Act in the role before you have the title: Lead at the level of the position you want to prove you are ready.

• Visibility is vital: Document, quantify your successes, and proactively present them to your manager in your 1-on-1s.

I hope this edition has given you the focus you need to boost your next professional step with energy. Do you have something to share about it? drop me a message!

Long time since I brought you fresh ideas from other experts from real life, and I come once again with a special guest . I let Julia introduce herself.

Julia is a Senior Localization Engineer at McAfee and the founder of Black Ice (black-ice.ai), a semantic governance platform built for multilingual AI pipelines. With a background in Siri localization at Apple and certification as a sworn translator, she brings a rare mix of linguistic depth and engineering to the question of how meaning travels across languages at scale. She writes The AI-Ready Localizer on Substack for localization professionals, engineers, and product teams navigating the shift to AI-assisted workflows.

Julia gave me an account to give a try at her Black-Ice.ai product, and I can tell it’s really cool, really good user experience, and it’s already cracking!

I want to recommend Julia’s newsletter to all those Engineers, Product Managers, and UI Platform leads who are working on localization challenges.

The AI-Ready Localizer

The AI-Ready Localizer explores how multilingual ontologies, market intelligence, and data governance transform localization from translation into AI-powered, intent-driven global growth.

By Julia | Taking you global

I must confess that I’m really excited about what Julia brings to you. I already read it in advance and found it super useful, to the point that I want to apply it in my Engineering Organization.

If you’re building a SaaS product, you likely have multi-language support. This post is for you, so you don't f*ck up and show 'Hola' to Japanese readers.

Without taking any more time, I hand over to Julia.

Somewhere in your codebase right now, there is a hardcoded string.

Maybe it’s an error message added at 6pm on a Thursday. Maybe it’s a toast notification someone copy-pasted and forgot to wrap. Maybe it’s a button label that’s been there since the MVP and nobody has touched it because it works.

It will ship to your French users as English. And nobody will catch it, because your CI pipeline has no idea it exists.

This is the problem. Let’s talk about how to fix it structurally, not by asking developers to be more careful, but by making the pipeline do the work.

What i18n scanning actually is

i18n scanning is static analysis for your translatable content. The same way a linter catches an undeclared variable or a type checker catches a mismatched return type, an i18n scanner catches:

• Strings rendered directly to the UI without going through a translation function

• Translation keys referenced in code that don’t exist in any locale file

• Translation keys present in locale files that are never referenced in code (dead strings)

• Locale files missing keys that exist in the source language (incomplete translations)

• Strings built by concatenation that are structurally untranslatable

• Plural forms handled incorrectly — or not handled at all

None of these require running the application. They are all detectable from static analysis of your source files and your translation resources. Which means they all belong in CI.

The four failure categories you will actually encounter

Before talking about tools, it helps to be precise about what you’re scanning for. These are the categories that cause real production issues.

1. The hardcoded string

// This will never be translated.
// Your German users will see "No results found" regardless of their locale.
function EmptyState() {
  return <p>No results found</p>
}

// This will be translated, because it goes through the i18n function.
function EmptyState() {
  return <p>{t('search.empty_state')}</p>
}

This is the most common failure and the easiest to catch. A scanner walks your JSX/TSX, finds string literals being rendered directly as text content or passed as props like label= or placeholder=, and flags them.

The tricky cases are strings that aren’t visually obvious: error messages thrown in catch blocks, strings constructed in utility functions far from any component, aria-label attributes, document titles set imperatively with document.title.

2. The untranslatable concatenation

// Looks fine. Completely untranslatable.
const label = "Hello, " + user.name + ". You have " + count + " messages.";

// The problem: word order is not universal.
// Japanese puts the subject last. Arabic has six plural forms.
// Hungarian uses postpositions, not prepositions.
// You cannot translate the fragments independently.

// Correct approach: ICU MessageFormat
const label = t('greeting', { name: user.name, count: count });
// en.json: "greeting": "Hello, {name}. You have {count, plural, one {# message} other {# messages}}."
// ja.json: "greeting": "{name}さん、{count}件のメッセージがあります。"

This is harder to catch automatically because you need to identify strings being concatenated and then rendered, not just any string operation. But AST-based tools can detect the pattern. The signal you’re looking for is: a template literal or string concatenation appearing inside JSX render output or passed to a translation function as a dynamic argument.

3. Key drift

// Code references this key:
t('user.profile.save_button')

// But your en.json has:
{
  "user": {
    "profile": {
      "saveButton": "Save changes"   // camelCase, not snake_case
    }
  }
}

// Result: silent fallback to the key string itself.
// Your button now reads "user.profile.save_button" in production.
// This has happened to everyone. Usually noticed by a user, not a developer.

Key drift happens when code and locale files evolve independently. A rename in one place without the other. A key added during development but never put into the JSON. This should be a hard CI failure — a missing key is a broken string in production.

4. Incomplete locale files

// en.json — your source of truth
{
  "onboarding.step1.title": "Let's get started",
  "onboarding.step1.body": "Tell us about yourself",
  "onboarding.step2.title": "Set up your workspace"   // ← new key, added last sprint
}

// fr.json — what went to translators two sprints ago
{
  "onboarding.step1.title": "Commençons",
  "onboarding.step1.body": "Parlez-nous de vous"
  // onboarding.step2.title is missing
  // Your French users see English here. Or nothing, depending on your fallback config.
}

This is the most common failure in fast-moving products. New strings ship to production in the source language while translations are in progress. Whether this is acceptable depends on your release strategy, but it should always be visible — a metric, a check, a warning. Not a silent gap.

The tools

There are two broad categories: linters that analyse your source code, and validators that analyse your translation resource files. You need both.

For source code analysis (catching hardcoded strings and bad patterns)

• eslint-plugin-i18n-json and eslint-plugin-i18next are the most widely used for i18next-based projects. They flag untranslated string literals in JSX, missing translation function wrappers, and some concatenation patterns.

• @formatjs/eslint-plugin-formatjs does the same for react-intl/formatjs, with additional checks specific to ICU MessageFormat syntax.

• Custom ESLint rules via AST are often necessary for project-specific patterns — for example, strings passed to third-party component props that your off-the-shelf plugin doesn’t know about.

The thing to accept early: no scanner catches everything. They catch the patterns they were written to recognise. Your job is to configure them to match your actual codebase patterns, not to expect full coverage out of the box.

For translation resource validation (catching key drift and incomplete locales)

• i18next-scanner extracts keys referenced in your source and compares them against your locale files. It can output a report of missing keys, unused keys, and coverage per locale.

• @formatjs/cli does key extraction and can enforce that all extracted keys are present in your message files.

• A simple custom script — walk the locale files, compare key sets, output diff — is often worth writing for your specific structure, because your project’s locale file layout is probably not exactly what any off-the-shelf tool expects.

What the pipeline actually looks like

Here is a practical CI pipeline structure. Not every team needs all of this on day one, but this is the shape of a mature setup.

PR opened / push to branch
         │
         ▼
┌─────────────────────────────┐
│  Stage 1: Lint (fast, < 30s) │
│                             │
│  eslint i18n rules          │
│  → fail on hardcoded strings│
│  → fail on bad concat       │
│  → fail on invalid ICU      │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 2: Key validation    │
│                             │
│  Extract keys from source   │
│  Compare against en.json    │
│  → fail on missing keys     │
│  → warn on unused keys      │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 3: Coverage report   │
│                             │
│  Compare en.json vs         │
│  all other locale files     │
│  → fail if coverage < N%    │
│  → post coverage table      │
│    as PR comment            │
└──────────────┬──────────────┘
               │ pass
               ▼
┌─────────────────────────────┐
│  Stage 4: Sync to TMS       │
│  (on merge to main only)    │
│                             │
│  Push new/changed source    │
│  strings to translation     │
│  management system via API  │
└─────────────────────────────┘

A few things worth highlighting in this structure:

Stage 1 and Stage 2 should be hard failures. A hardcoded string is a broken feature for non-English users. A missing key renders as the key name in production. These are bugs, not warnings.

Stage 3 should be configurable by locale. You might tolerate 80% coverage for a language you recently launched and 100% for your primary markets. The important thing is that the gap is visible and tracked, not silent.

Stage 4 is where the pipeline connects to your translation workflow. Most mature TMS platforms have APIs and CI integrations. The pattern is: on merge to main, push new source strings to the TMS; the TMS notifies translators; translated strings are pulled back on a schedule or via webhook before the next release. The pipeline doesn’t block on this — it triggers it.

The pre-commit layer (before CI even runs)

CI catches things before they merge. Pre-commit hooks catch things before they’re even pushed, which is faster feedback and less noise in PR reviews.

Using lint-staged with your i18n ESLint rules, you can run string checks only on files changed in the current commit — keeping it fast enough that developers don’t disable it.

// .lintstagedrc
{
  "*.{js,jsx,ts,tsx}": [
    "eslint --rule 'i18next/no-literal-string: error' --no-eslintrc"
  ]
}

The rule of thumb: everything that can be caught locally should be caught locally. CI is the safety net, not the primary feedback loop.

The one failure nobody talks about: the source string itself

All of the above assumes your English source strings are well-formed and translatable. Often, they aren’t.

// This string will reach your translators exactly like this.
t('save_confirmation', { defaultValue: "Changes saved! 🎉" })

// Problems:
// 1. The emoji may render incorrectly or be culturally inappropriate in some locales.
// 2. "Changes saved" is ambiguous — saved where? As in rescued, or persisted?
// 3. No context about where this appears, what triggered it, or what "changes" means.

A scanner cannot catch these problems. But a string linting step on the source values themselves can catch some of them:

• Emoji in UI strings (flag for review)

• Strings over a length threshold that will break UI in text-expansion languages (German expands ~30%, Finnish can expand ~60%)

• Strings with no translation context/comment attached

• Strings that appear to be sentences but end without punctuation (or vice versa — inconsistent punctuation is a translation signal that something is wrong)

This is the layer most teams never build. It’s also the layer that most directly improves translation quality — because it improves the source before anyone translates it.

Where things break down even with a good pipeline

Having the tooling is not the same as the tooling working. A few failure modes that survive even well-structured pipelines:

The coverage threshold that never moves

Teams set a coverage gate at 80%, ship, and never revisit it. The threshold stops being a quality signal and starts being a number the pipeline checks so everyone can feel fine. Review your thresholds per locale, per quarter.

The scanner that never covers your whole codebase

ESLint i18n rules are easy to configure for your main app code. They are less often configured for your component library, your internal tooling, your admin panel, your email templates. Each of these is a separate surface with its own untranslated strings. Map your surfaces before you assume you’re covered.

The TMS sync that runs but nobody checks

Strings push to the TMS, but the translation workflow on the other side is not set up to handle them promptly. New strings sit untranslated for weeks. By the time translations come back, the feature has been live in English-only for two release cycles.

The pipeline does not fix a broken translation workflow. It just makes the handoff cleaner. The workflow itself needs ownership.

Key naming that carries no meaning

// This is the key you'll be debugging in eighteen months:
t('label_47')

// This is the key that communicates intent to translators and future engineers:
t('checkout.order_summary.total_price_label')

No scanner enforces key naming conventions, but your CI can. A custom ESLint rule that validates key format against a regex is ten lines of code and saves significant cognitive overhead over time.

Final thoughts: language is a build artifact

Here is the mental model shift that makes all of this click.

Your translation files are build artifacts. Like your compiled code, your test coverage report, your bundle size analysis — they have a correct state, and that state can be verified automatically.

A missing translation key is a build error. An untranslated string rendered to a French user is a broken feature. A locale file that hasn’t been synced to the TMS is stale code.

Once you treat it this way, the pipeline work becomes obvious. You already have automated checks for code correctness, test coverage, and bundle size. i18n coverage belongs in the same category, enforced the same way.

The teams that get this right are not the teams that care more about localization. They are the teams that stopped treating localization as someone else’s problem and put it in the pipeline where it belongs.

Before you go, a small meta-note. The i18n pipeline I described above is one I’m actively building with AI. I use Claude and a multi-agent setup to handle different stages of the workflow: scanning for hardcoded strings, extracting keys, flagging concatenation patterns. Then a semantic layer via Black Ice checks terminology consistency, style, and market availability — so a term that works in en-US gets validated before it assumes it works in de-DE or ja-JP. Writing about i18n infrastructure while building it with the same tools is, I’ll admit, a very specific kind of fun.

🫂 Thanks Julia!

Marcos back!

I want to send a deep Thank You to for sharing her experience on the Product Platform area and localization. To learn more from Julia, subscribe NOW to her newsletter 👇

The AI-Ready Localizer

The AI-Ready Localizer explores how multilingual ontologies, market intelligence, and data governance transform localization from translation into AI-powered, intent-driven global growth.

By Julia | Taking you global

🔖 Follow-up readings

The AI-Ready Localizer

Building Globally: A Practical i18n Guide

Internationalization (i18n) isn’t just a language feature. It’s a design constraint, a code architecture choice, and a product strategy…

Read more

a year ago · 22 likes · 1 comment · Julia | Taking you global

When you create the software, sometimes it’s difficult to find your blind spots. But time puts things in perspective, and so you can learn from your mistakes.

In today’s email, I want to share with you the 4 signals that your software is badly designed.

Rigidity

👉🏼 Rigidity is the tendency of software to be difficult to change, even in simple ways.

A system is rigid when a change in one module triggers a cascade of changes in other dependent modules.

The symptom: If you request a change estimated to take two days and it ends up taking two weeks because “one thing led to another,” you have a rigid system.

The cause: It’s usually excessive coupling. Everything is so tightly coupled that you can’t move one piece without it affecting the entire board.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You have an OrderProcessor class with a massive switch statement for calculating shipping costs. If it’s “UPS,” it does one thing; if it’s “FedEx,” it does another. When you want to add “DHL,” you have to modify that class, forcing you to recompile and retest the entire order module.

The Solution: Strategy Pattern (or the Open/Closed Principle). Instead of an internal switch statement, you create a ShippingStrategy interface. Each carrier (UPS, FedEx, DHL) implements this interface. The OrderProcessor now only receives one strategy and calls calculate().

Result: To add a new carrier, you simply create a new class. You don’t touch the existing code.

Fragility

👉🏼 Fragility is the tendency of software to break in many places every time a change is made.

Unlike rigidity, the problem here isn’t the effort of the change itself, but the lack of control over the side effects.

The symptom: You fix a bug in the payments module, and mysteriously, the inventory report generator stops working.

The cause: This usually occurs when there are hidden dependencies or highly intertwined logic where modules know too much about each other’s inner workings.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You have a global variable or a Singleton that stores the “System Configuration.” A developer changes the date format in that configuration for a specific report, and suddenly, the “Payroll” module stops processing payments because it expected the old format. The system broke in a place unrelated to the original change.

The Solution: Encapsulation and Interface Segregation.

Don’t allow everyone to access a global object. Divide the configuration into smaller interfaces (e.g., PayrollConfig, ReportConfig). Each module only sees what it needs.

Result: A change in the reports only affects the reporting interface, keeping payroll safe.

Immobility

👉🏼 Immobility is the inability to reuse software in other projects or even in other parts of the same project.

It occurs when the design is so entangled with its environment that extracting a feature is more costly than rewriting it.

The symptom: You need a validation function that you already implemented in another module, but when you try to copy it, you realize that it also includes the database, the user interface, and three external libraries.

The cause: A design that doesn’t separate business rules from implementation details (such as the database or the framework).

🧐 Yeah, let’s see an example, and how you would solve it.

The Scenario: You created a brilliant algorithm to validate ID numbers (national ID/tax ID). However, the algorithm is written within a UserRegistrationForm class that inherits from a UI library (like React or the Android SDK) and also directly calls the database to check for duplicates.

The Solution: Layered Architecture (Clean Architecture).

Extract the algorithm into a Pure Object Component (POJO) or Use Case. This code should not know anything about buttons or databases. The database is passed to it as an interface (Dependency Inversion).

Result: Now you can copy that validation file and paste it into any other project without carrying over the “garbage” from the interface or the database.

Viscosity

👉🏼 Viscosity refers to the resistance the system offers to doing things “right.”

It is divided into two types:

• Software viscosity: When it is much easier to add a “hack” or a dirty patch that follows the original design and keeps the architecture clean.

• Environment Viscosity: This occurs when the development environment is slow or inefficient (endless compilation times, tests that take hours). This tempts developers to resort to shortcuts to avoid the formal process.

🧐 Let’s see an example, and how you would solve it.

The Scenario: You need to add a field to a form. The “clean” design requires creating a database migration, updating the entity, updating the DTO, and updating the mapper. That takes 1 hour. But you can simply save that extra “hidden” data in a generic text field called “observations” in 5 minutes. If the system takes a long time to compile or testing is slow, you’ll choose the dirty way.

The Solution: Automation and Infrastructure Refactoring.

If the problem is with the environment (slow compilation), you need better machines or to modularize the project. If it’s with the software, you need tools like Lombok or automatic mappers (AutoMapper/MapStruct) that reduce repetitive code (boilerplate).

Result: Doing it right should be almost as fast as doing it wrong. If the right way is easy to follow, developers will follow it.

Alright! Let’s wrap up for today. These four signals (Rigidity, Fragility, Immobility, and Viscosity) are not just theoretical concepts; they are the “smells” that indicate your system is asking for help.

✨ Takeaways

Today’s email has been really software engineering-oriented. Long time since I dedicated one email to this, hope you like it from time to time.

• Design for change: A rigid system is a slow system. Use patterns like Strategy to decouple logic from execution.

• Protect your boundaries: Avoid global states and hidden dependencies to keep fragility under control.

• Decouple from the framework: Your business logic should be able to live anywhere. If it’s stuck in a UI component, it’s immobile.

• Make the “right way” the “easy way”: If doing it right takes too much effort, the system will eventually fill with hacks. Invest in your environment.

☝🏼 Remember: Bad design is not a life sentence. Identifying these signals is the first step toward refactoring and moving toward a more Incremental Architecture.

I’d love to hear from you. Have you identified any of these signals in your current project? Which one do you find the most difficult to fix?

Drop a message in the comments or reply to this email. I read and reply to all!

Best,
Marcos.

👉🏼 It is shipping it with confidence.

Because releasing software should not feel like a coin toss, especially not on a Friday at 6 p.m., when everybody is already mentally halfway into the weekend, and the margin for dealing with surprises is much smaller than we would like to admit.

If every release feels risky, the problem is usually not the release itself. The problem is the system behind it.

In today’s issue, I want to share a different way of looking at that feeling of uncertainty that appears right before going to production, and why, in most cases, it is not something you fix at release time, but something you design away much earlier in the process.

Let’s begin with the elephant in the room.

The invisible weight behind every release

👉🏼 Releases do not become stressful in isolation.

They accumulate friction over time, through a combination of small issues that individually seem manageable, but collectively create a system that is harder to reason about and, therefore, harder to trust.

Some of those signals usually look like this:

• Ownership is not completely clear, so when something goes wrong, there is a small but real hesitation about who should act first.

• Parts of the system are only fully understood by one or two people, which silently increases the perceived risk of touching them.

• Logs exist, but they do not really explain what is happening, forcing you to reconstruct the story under pressure.

• Alerts either come too late or too often, which makes them easy to ignore when they actually matter.

• Environments behave slightly differently, in ways that are not always obvious until something breaks.

None of these things breaks a release on their own.

But together, they create a system where every change feels heavier than it should, and that weight tends to show up exactly when you least want it to: right before going to production.

Confidence is not a feeling, it is a property

👉🏼 Many teams treat confidence as something emotional, something that needs to be discussed or agreed upon before releasing.

Do we feel safe releasing this?

But confidence is not something you convince yourself of in a meeting.

It is something your system gives you, almost by default, when the right properties are in place.

A system that behaves well tends to share a few characteristics:

• It is easy to understand, which means that most engineers can reason about what a change will do before it happens.

• Responsibilities are clear, so when something goes wrong, there is no ambiguity about who owns the next step.

• It explains itself through logs and signals that help you understand what is happening without guesswork.

• It behaves consistently across environments, reducing the number of surprises when moving to production.

When those pieces are in place, confidence stops being a discussion and becomes an outcome.

Where most teams get it wrong

👉🏼 The common mistake is trying to “fix the release” instead of fixing the system that produces that release.

That usually leads to adding more layers around the moment of deployment:

• More checks.

• More approvals.

• More manual verification.

• More last-minute coordination.

All of these can help in the short term, and sometimes they are necessary.

But they rarely address the root of the problem.

Because the release is just the moment where all the properties of your system are tested at once, under real conditions and real pressure.

• If the system is hard to understand, the release will feel risky.

• If the system is inconsistent, the release will feel unpredictable.

• If the system is fragile, the release will feel stressful.

Trying to fix the release without fixing the system is like trying to move faster on a road full of potholes; you might get away with it a few times, but the underlying problem is still there.

A simpler way to think about it

Instead of asking:

Is this release safe?

It is often more useful to ask:

Does our system make safe releases the default?

That shift may seem subtle, but it changes where you put your effort.

It moves your attention:

• From the moment of deployment 👉🏼 to the way the system is built.

• From last-minute checks 👉🏼 to everyday engineering practices.

• From reacting to problems 👉🏼 to designing systems that are easier to trust.

And that is where most of the leverage actually is.

Now, some homework for you.

A small exercise

Think about your last release, not just in terms of code, but in terms of experience.

Try to recall the moments where you slowed down, hesitated, or double-checked something “just in case”, even if everything looked correct on the surface.

Ask yourself:

• Where did I hesitate, even slightly?

• What did I feel the need to double-check before moving forward?

• Which part of the system made me feel uncertain or uncomfortable?

Those moments are not random but signals.

They are pointing to parts of your system that are asking for more clarity, more consistency, or better feedback.

👉🏼 If you start paying attention to those signals, release after release, you are not just making the next deployment safer. You are gradually building a system that is easier to understand, easier to operate, and ultimately easier to trust.

Shipping software will never be completely risk-free, but it should not feel like guesswork either.

And when it does, it is usually telling you exactly where to look.