blogs

Grading at Scale: LLM-as-Judge Without the Reading Marathon

2026-08-23T21:05:54Z

Every team building an LLM-in-the-loop decision system, whether it's approvals, moderation, routing, or classification, eventually adopts the same QA pattern: an LLM...

Linky #37: You can’t know everything up front

2026-08-23T17:18:39Z

This week’s links circle around something I think is foundational to a lot of quality engineering: we can’t know everything up front.

We can test a change, adopt a new practice, build a prototype or run a transformation, but at some point we need feedback from the system to tell us what actually happened.

That means being able to observe what happens, learn from past events, look beyond the immediate team, and hold on to the knowledge we’ve already built up.

For me, a lot of quality engineering is about helping create those feedback loops so we can make better decisions even when we don’t have complete information.

Latest post from the QE Newsletter

I’ve been thinking about what makes a change safe to release, and usually that conversation comes down to whether something has been tested. That’s important because we still need to know something works as intended.

But testing doesn’t make it completely safe to release. We can’t test everything, and sometimes smaller issues can line up in production in just the right way, leading to a much bigger incident.

So alongside testing, we also need to understand what changed and the consequences of being wrong, then detect, contain, and reverse problems if they happen. Together, those factors give us more confidence that we can release safely.

This is a follow-on post to Start with what changed, which dives deeper into understanding what changed and what types of feedback help us reduce the uncertainty around that change.

Problem solving in software is more biology than engineering

Software is being asked to problem-solve more like biology, cognitive science, and all the fields that have always had to develop approaches to study systems we only partially observe.

Interesting post from Cat Hicks. This reminded me of what socio-technical systems and complexity theory show us: we can’t know or see everything about the systems we build and maintain.

Sometimes we need to observe what the system actually does and respond accordingly. So building in ways to better observe our systems and get feedback about how they’re behaving helps us diagnose and respond to issues. Via “Software developers will never read the code again!!” | Cat Hicks

Systems thinkers are not always the most welcome

With quality engineering, you’re often indirectly advocating for systems thinking, but as John Cutler points out, that doesn’t always make you the most welcome person in the organisation if people aren’t ready to hear what you’ve got to say.

As quality engineers, we often look beyond what caused the bug and ask what conditions around the work allowed it to happen. Or when people ask why the team isn’t going faster, we might ask: faster towards what outcome?

Those questions take you beyond what the team directly controls and into the wider system around them. For example, incentives, dependencies, structures and priorities. That can be uncomfortable, but it is often where the more useful changes are. Via A popular podcast guest recently proclaimed “We need systems thinkers!” But there’s a problem | John Cutler

The visible changes are the easy bit

This is from 2024 and one of the big three management consultancies, but it identifies some behaviours companies get wrong when trying to become more agile:

...they do not make the more difficult and substantive changes, such as establishing customer-facing business units fully aligned to value streams, setting up enabling supporting structures that own internal products and platforms, and resetting incentives and rewards.

They have a tendency to focus on the visible aspects of agile, things like tribes, squads, and ceremonies. The deeper changes are much harder because they need buy-in from across the organisation. Many agile transformations focus on tech teams because that’s what they can change.

But the point of the transformation should be to help the organisation achieve better outcomes, not just change how the team works. So judging it by the practices that changed only tells you people are doing things differently. What really counts is whether those changes are shifting the outcomes in a better direction.

Which brings me back to quality engineering. Are we just changing our practices, or are those practices actually changing the conditions that create quality? Via Why Companies Get Agile Right—and Wrong | BCG

Structured debriefs can improve performance by 20–25%

Just in case you needed something to remind people why retros are worth doing. From a 2013 meta-analysis:

- Debriefs are a quick, effective tool for improving team and individual performance.
- Meta-analytic results from 46 independent samples show that debriefs improve performance an average of 20% to 25%. Debriefs work equally well for teams and individuals.
- Debriefs work best when properly aligned: If the goal is to improve team performance, debriefs should be conducted with, measure, and focus on teams rather than individuals (and vice versa).
- Findings suggest that debriefs are even more effective when structured and facilitated.

While the paper doesn’t give you a step-by-step format for running a debrief, it does highlight some of the things that appear to make them work.

Focus on a specific event rather than general strengths and weaknesses. Make the intent learning and improvement, rather than judgement, appraisal or blame. Let the participants do the reflecting and sense-making rather than telling them what went right or wrong. Bring together different perspectives and data to build a clearer picture of what happened.

Retros are a great way to help teams learn from past events, so being able to step in and facilitate one as a QE feels like a really useful skill. It’s also a practical way to model the kinds of learning behaviours that help teams improve. Via Do Team and Individual Debriefs Enhance Performance? A Meta-Analysis

Build to learn and building to earn

strong product teams use AI very differently when they are building to learn (product discovery) versus building to earn (product delivery).

I really like Marty Cagan's idea of building to learn and building to earn. Building to learn is all about prototyping and discovering what the best solution to the problem you’ve identified is.

Whereas building to earn is about creating production-grade software thats reliable, observable, performant and can handle hundreds of use cases and complex business logic.

I like this framing because it makes explicit what each phase of building is trying to accomplish. Building to learn means the solution doesn’t need to be production-grade. It needs to be good enough to learn whether something works and safe enough to throw away without harming users or the business. Building to earn is about taking what you’ve learned and turning it into something that can deliver value reliably at scale.

And when building to learn involves putting something in front of real users or experimenting in production, the ability to detect, contain and reverse changes becomes even more important.

It lets you learn quickly without assuming you’ve already thought of everything that could go wrong. Via The AI Productivity Paradox | Silicon Valley Product Group

Is the code reuse argument dead?

With AI capable of producing code more cheaply and quickly than before, does code reuse matter less? Well, according to Russell Rutledge from the InnerSource Commons Foundation, no:

You don’t get one duplicate. You get a sprawl of near-identical, subtly inconsistent implementations multiplying across the codebase, and inconsistency is exactly where outages and security holes live.

He’s got a point: you’re better off reusing the one auth module that has all the edge cases that your company has discovered and built in rather than each team having to rediscover each one. So what do we do? Well, it’s about using the practices that InnerSource has been advocating all along, except now they’re not just useful for people, but AI too:

Every readiness practice we ever preached - a clear README, real tests, a good-first-issue, a welcoming CONTRIBUTING guide - was designed to help a capable stranger land a change without a personal tour.

Those readiness practices also reduce the uncertainty when someone else needs to change the code. Good tests, documentation and contribution guidance make more of the context around a component visible.

As QEs, advocating for that kind of readiness feels increasingly useful. It helps teams share the knowledge they’ve already built up, not just with new starters but with the AI tools they’re using too. Via Why AI Needs InnerSource

Enjoyed this Linky? Subscribe to get future Quality Engineering posts and Linkys in your inbox.

Subscribe now

Thanks for reading and subscribing. If you’d like to support the newsletter and get access to my deeper posts and case studies, you can upgrade to paid.

Past Linkys

Puzzle 41

2026-08-23T12:15:02Z

The buttons and lamp obey a fairly simple principle. What is it?

Puzzles supported by these lovely people

Julie Gardiner, Joep Schuurkes, Huib Schoots, Ide Koops, Kris Corbus, Alan Richardson, Rob van Steenbergen, Ioana Chiorean, Peter Houghton, Adun Urke, Christine Yen, Pascal Dufour all support me on Patreon. Not for this puzzle though.

Help me make more and I'll put your name on this list. There are other perks, too, eventually.

Enjoy this? Support another!

Built by James Lyndsay - @workroomprds

Day 14: Test Data Management — Factories, Faker, and Cleanup

2026-08-22T22:00:00Z

TestDataFactory + Faker + fixture cleanup. Dynamic data for parallel-safe tests. Day 14 of 21-Day Challenge.

The post Day 14: Test Data Management — Factories, Faker, and Cleanup appeared first on Software Testing & Automation.

Decoding DeepSeek Harness: The Open-Source Runtime Behind Composable AI Agents

2026-08-22T09:40:11Z

Why the next frontier of agent engineering may be less about the model and more about the system that lets the model safely act, persist…

Continue reading on Data And Beyond »

LLM Cost Testing: Stop AI Bills From Ballooning in CI

2026-08-22T04:39:05Z

Token spend and dollars are a first-class quality gate. Here is the CI playbook to catch a cost regression before your AI feature ships.

The post LLM Cost Testing: Stop AI Bills From Ballooning in CI appeared first on Software Testing & Automation.

LangGraph Checkpoint Testing: What’s New in 4.2.0

2026-08-22T03:41:34Z

AgentQA upgraded to langgraph-checkpoint 4.2.0. Here's what the new omit_expired flag and checkpoint replay mean for deterministic AI agent testing.

The post LangGraph Checkpoint Testing: What’s New in 4.2.0 appeared first on Software Testing & Automation.

Your Test Suite Knows What Broke. It Rarely Knows Why It Matters.

2026-08-22T03:41:01Z

We have spent years making tests executable. AI is exposing how little context we made understandable.

Continue reading on Medium »

MCP 2.0 for QA: A Beginner’s Guide to Model Context Protocol

2026-08-22T03:39:54Z

MCP 2.0 for QA is here. Learn what changed in the Model Context Protocol, how to run and test an MCP server, and why AI agent testing starts at the tool contract.

The post MCP 2.0 for QA: A Beginner’s Guide to Model Context Protocol appeared first on Software Testing & Automation.

Playwright Global Setup and Teardown with TypeScript

2026-08-22T03:37:33Z

Playwright global setup runs your login and database seeding once before all tests. Here's how to wire globalSetup and globalTeardown in TypeScript, with real code and the pitfalls that trip up QA teams.

The post Playwright Global Setup and Teardown with TypeScript appeared first on Software Testing & Automation.

An update on public speaking

2026-08-22T00:00:00Z

Earlier this year, I wrote a blog post about increasing focus in my career. If you haven’t read and/or don’t feel like reading that post, the tl;dr of it is that for a couple of years, I’ve been working on too many things at the same time, which led to

not delivering all of my work at the quality that I want to and can deliver, and
not having enough time for things outside of work, most notably cycling

It is now five months since I wrote that post, and things have changed slightly for the better. I feel like I am working on fewer things in parallel, and, as I expressed, most of my time these days is spent on building my training business and on reading, writing for this blog and especially for my newsletter and studying.

I still do a bit of consulting, but my current engagement is ending soon, and after that, I’m aiming for the consulting that I will do to be solutions-based, instead of based on hourly billing.

One activity on which I expected to spend less time is public speaking. As I said in the blog post:

The public speaking will stay as well, but here too, I will consider and take what comes my way, instead of actively pursuing speaking gigs at meetups and conferences, especially those abroad. I do have a few in-company speaking gigs coming up in the next couple of months, as well as a keynote at an online conference. I enjoy speaking, so I will continue doing talks, but again, pretty much only when I am invited to do so.

I’m not actively pursuing speaking opportunities anymore, which means that it has been quite some time since I submitted a proposal to a Call for Papers. I have made and will keep making an exception and submit proposals for a very short list of conferences, namely

EuroSTAR and AutomationSTAR - because they’re the largest and therefore provide me with a podium to showcase what I do in front of a large audience, and because I really enjoy their events
KWSQA’s Targeting Quality - because I really like their community and because I’ll take every excuse to travel to Canada (I hope to be back in Cambridge, ON, soon)

Even then, my submissions will probably be workshops rather than talks, because workshops are what I do for a living anyway in my training business, and the compensation will often be much better, too.

However, even now that I’m really no longer actively seeking out speaking opportunities, those opportunities still present themselves on a regular basis. I might not do as many talks in 2026 as I did in 2025 (so far, I did 6 this year, where I did 21 in total in 2025), but still, every now and then people and organizations reach out to me to have me as a speaker at their event. And not just online, in person, too.

Now, this might sound strange to some of you, but I’ve never really seen myself as a typical conference speaker. I enjoy doing talks, sure, but I’m not the ‘conference tiger’ taking their talk from one conference to the next as some of my fellow folks in the industry do (and all the best to them!). So, every time people do reach out and ask if I can do a talk at their event, I’m honoured, and often a little surprised, too. Even more so when ask me if I want to do a keynote.

I’ve done a few keynotes so far (more than 5 but less than 10, I lost count), from my first one ever at the Dutch Testing Day in 2018, my first one abroad at UKSTAR in 2019, to the most recent one at the in-company developer conference at a large Dutch bank. And guess what? I actually enjoy doing keynotes. I never really thought I would, but I do.

That wasn’t always the case, by the way. In the past, after my first few keynotes, every time I thought ‘well that surely was the last one ever’. I’d seen so many other people deliver brilliant, inspiring, clever, moving keynotes, I thought I could never do that. Still don’t think I can. And that’s fine with me.

The talks I do, and enjoy doing, are about how we can and should do things better, mostly in test automation. Often, that will include some code or even a live demo. My talks are distilled from 20 years of experience in the field, and all the lessons I learned along the way. You might not get life-changing insights, but you’ll get practical advice, wrapped in ugly retro slides, with some references to 90s pop culture and bad jokes thrown in.

Turns out, there are events that are happy to have such a talk as a keynote. Next to the in-company developer conference I mentioned, I’m also doing a keynote at the online day of Testear.la and at this year’s CypressConf. I’ve even got my first keynote for 2027 lined up already, and I’m really looking forward to speaking at the inaugural Taqelah Testing Conference in Singapore in March.

Because I don’t actively pursue speaking opportunities, but will happily accept what comes my way, I have more time to create new, original, customized talks for these events, too. Two out of the three keynotes I do this year are developed specifically for the event. Come to think of it, that’s exactly what I do in my training business as well: no off-the-shelf standardized courses and workshops, but tailored engagements pretty much every time.

And that’s exactly how I like it best.

If your event is looking for a keynote speaker bringing in a customized, brand new talk with practical advice and lessons learned in 20 years of test automation, and if you think your audience can deal with my ugly retro slides and lame jokes, let’s talk.

Job Hunt With a Bot?

2026-08-22T00:00:00Z

I need to look for a job, so I made a Job Hunt bot on Grok Bot. It looked me up online, found roles, and can even do interview prep.

Day 13: Debugging — Trace Viewer, UI Mode, and Inspector

2026-08-21T22:00:00Z

3 debugging tools: Trace Viewer, UI Mode, Inspector. 60-second debugging workflow. Day 13 of 21-Day Challenge.

The post Day 13: Debugging — Trace Viewer, UI Mode, and Inspector appeared first on Software Testing & Automation.

Most coding agent benchmarks skip large-scale refactoring. Not this one.

2026-08-21T11:54:00Z

New SWE-Bench ProMax reveals where coding agents can’t measure up. Experts weigh in on why.

My website, as seen by BearQ

2026-08-21T10:12:20Z

I’m partnering with SmartBear on a sponsored series of content about tools for the AI era. As always, all opinions are entirely my own. I have a long-standing suspicion of tools that promise to find problems for me, and it comes from watching what happens to them about three months into the journey. Somebody switches […]

LLM Hallucination Testing: How to Catch AI Making Things Up

2026-08-21T04:39:15Z

A hallucination is fluent, confident, and wrong. Learn how QA teams detect AI making things up, with DeepEval, Ragas, and PromptFoo code you can run in CI today.

The post LLM Hallucination Testing: How to Catch AI Making Things Up appeared first on Software Testing & Automation.

n8n 2.35.3: The QA Upgrade Checklist Before You Deploy

2026-08-21T03:39:43Z

n8n 2.35.3 shipped an API migration (Google Ads v21 to v25) and an OAuth scope change. Here is the QA upgrade checklist to test triggers, branches, credentials, and failure paths before you deploy.

The post n8n 2.35.3: The QA Upgrade Checklist Before You Deploy appeared first on Software Testing & Automation.

Playwright UI Mode: Time Travel Debugging in TypeScript

2026-08-21T03:39:16Z

Playwright UI Mode is the fastest way to turn a red test green. Learn time-travel debugging, Pick Locator, watch mode, and trace reading in TypeScript.

The post Playwright UI Mode: Time Travel Debugging in TypeScript appeared first on Software Testing & Automation.

Selenium vs Playwright in 2026: Which One Should You Learn?

2026-08-21T03:38:39Z

Compare Selenium vs Playwright in 2026: GitHub stars, npm and PyPI downloads, and real hiring demand. See which framework to learn first.

The post Selenium vs Playwright in 2026: Which One Should You Learn? appeared first on Software Testing & Automation.

Dívida Técnica: A Conta Que Você Já Está Pagando Parcelada

2026-08-20T16:47:34Z

Você já viveu essa cena. O time levanta que o motor de cobrança precisa ser reestruturado. Alguém monta um slide. A palavra “refatoração” aparece três vezes, “acoplamento” aparece duas, e há um diagrama com muitas setas. A reunião termina com um “faz sentido, vamos avaliar no próximo trimestre” — que é a forma corporativa de dizer não sem ter que justificar.

A explicação confortável para o que aconteceu é que a diretoria não entende de tecnologia. A explicação honesta é mais desconfortável: o pedido foi feito numa moeda que ninguém do outro lado da mesa sabe converter.

O problema raramente é indiferença. Executivos aprovam investimentos difíceis o tempo todo — trocam o core bancário, compram empresa, aceitam três anos de payback. O que eles não fazem é aprovar algo que chega descrito em qualidade de código, cobertura de teste e framework depreciado, sem nenhuma tradução para receita, custo, risco ou posição competitiva. E há uma falha ainda mais comum: apresentar um caso genérico e único para todo mundo ao mesmo tempo, obrigando cada executivo a fazer a tradução sozinho — o que, na prática, termina em decisão nenhuma.

A escala do problema não é anedota. Numa pesquisa da McKinsey com 50 CIOs de instituições financeiras e empresas de tecnologia com receita acima de US$ 1 bilhão, os entrevistados estimaram que a dívida técnica representa entre 20% e 40% do valor de todo o parque tecnológico antes da depreciação, e relataram que de 10% a 20% do orçamento nominalmente destinado a produtos novos acaba desviado para resolver problemas decorrentes dela. Do outro lado da régua, o CISQ estimou o custo da má qualidade de software nos Estados Unidos em US$ 2,41 trilhões, com a dívida técnica acumulada em torno de US$ 1,52 trilhão.

Obrigado por ler Crônicas de um Programador Pragmático! Inscreva-se gratuitamente para receber novas publicações e apoiar meu trabalho.

Pilar 01: Recupere o significado da metáfora antes de usá-la

Você não consegue precificar um conceito que cada pessoa na sala entende de um jeito. E “dívida técnica” virou exatamente isso: um guarda-chuva onde cabe desde uma falha arquitetural que impede a empresa de lançar produto até o desgosto de alguém com o nome de um pacote.

Lição 1.1 → A metáfora nasceu num banco, e nasceu para falar com executivos

Ward Cunningham cunhou o termo em 1992, num relatório de experiência apresentado na OOPSLA sobre o WyCash — um sistema de gestão de portfólio. Ele estava cercado de gente de finanças, precisava justificar tempo investido em melhorar código existente, e escolheu deliberadamente uma linguagem que aquela audiência já dominava.

Repare na ironia: a metáfora foi inventada como ferramenta de comunicação com o C-level, dentro de uma empresa financeira. Nós é que a sequestramos e transformamos em jargão interno de engenharia.

E há uma segunda perda, mais séria. Numa entrevista de 2009, Cunningham voltou ao tema para dizer que a metáfora nunca foi sobre código bagunçado, e sim sobre o custo de operar com um entendimento incompleto do domínio. Michael Feathers formulou isso da maneira mais útil que já vi: dívida técnica é a distância acumulada entre o seu entendimento do problema e o entendimento que o sistema reflete. Você começa codificando o que entendeu; depois aprende mais; se o código não acompanha o aprendizado, você passa a tropeçar num descompasso conceitual toda vez que mexe ali.

Essa definição é infinitamente mais defensável numa reunião do que “o código está ruim”. Porque ela é verificável: quantas vezes, no último trimestre, uma regra de negócio nova exigiu contornar o modelo em vez de usá-lo?

Lição 1.2 → Classifique a dívida antes de cobrá-la

Nem toda dívida tem a mesma origem, e a origem muda completamente quem deve responder por ela.

Steve McConnell, num artigo da IEEE Software de 2007, propôs a primeira taxonomia séria: dívida não intencional, produzida por desconhecimento ou processo falho; dívida de curto prazo, assumida deliberadamente por um ganho imediato; e dívida de longo prazo, acumulada pela evolução natural do sistema. Foi ele também quem tornou explícito o par principal/juros.

Martin Fowler foi além em 2009 com o quadrante de dívida técnica, cruzando dois eixos:

                    PRUDENTE              IMPRUDENTE
                ┌─────────────────────┬─────────────────────┐
   DELIBERADA   │ "Entregamos agora,  │ "Não temos tempo    │
                │  refatoramos no     │  para desenhar       │
                │  próximo ciclo"     │  isso direito"       │
                ├─────────────────────┼─────────────────────┤
   INADVERTIDA  │ "Agora entendemos   │ "O que é camada     │
                │  como deveria       │  de domínio?"        │
                │  ter sido feito"    │                      │
                └─────────────────────┴─────────────────────┘

Por que isso importa numa conversa com gestão? Porque muda o pedido. Dívida deliberada e prudente é uma promessa que a empresa fez a si mesma e agora precisa honrar — você está cobrando uma decisão anterior, não pedindo um favor. Dívida inadvertida e prudente é aprendizado do domínio; é o quadrante mais honesto e o mais fácil de defender, porque ninguém errou. Já dívida imprudente, deliberada ou não, é um problema de processo ou de capacitação — e apresentá-la como se fosse trade-off estratégico é desonesto e, pior, não resolve, porque a mesma dívida vai voltar em seis meses pela mesma porta.

Lição 1.3 → Diga em voz alta qual dívida você não vai pagar

Este é o movimento mais contraintuitivo do artigo e talvez o de maior retorno.

Quem chega no fórum de arquitetura pedindo para zerar a dívida está pedindo para não ser levado a sério — porque zerar dívida significaria alocar todo o recurso disponível em remediação, sem construir nada que diferencie a empresa. A própria McKinsey é explícita ao dizer que o objetivo não é chegar a zero, e a orientação prática é que raramente compensa reduzir abaixo de algo em torno de 10%: parte da dívida simplesmente nunca vale o custo de pagar.

Então inverta. Leve uma lista de três itens que o seu time decidiu conscientemente não corrigir, com a razão de cada um: “esse módulo é feio mas não é tocado há dois anos e não é caminho crítico”, “essa duplicação é intencional para desacoplar dois times”, “esse serviço vai ser desligado em 2027, não vamos investir nele”.

O efeito prático

No instante em que você mostra o que decidiu não fazer, o seu pedido deixa de ser preferência estética e passa a ser priorização. Você para de ser o engenheiro que sempre quer reescrever tudo e vira a pessoa que já filtrou o ruído antes de ocupar o tempo da liderança. Isso não é técnica de retórica — é o subproduto natural de ter feito o trabalho de análise de verdade.

Pense comigo — antes de dizer a palavra “dívida”

Isso atrapalha o negócio ou atrapalha a mim? A pergunta honesta é: se ninguém mais mexer nesse código nos próximos dois anos, alguma coisa acontece? Se a resposta é não, você tem uma preferência, não uma dívida.
Em que quadrante isso está? Se for deliberada e prudente, quem prometeu pagar? Quando? Está registrado em algum lugar, ou só na memória de quem estava na sala?
Qual é a distância entre o sistema e o meu entendimento atual do domínio? Conte as vezes em que uma regra nova precisou de gambiarra em vez de encaixar no modelo. Esse número é a sua evidência.
O que eu vou dizer que NÃO vamos corrigir? Se você não consegue nomear três itens, você ainda não priorizou — só listou incômodos.

Pontos altos do Pilar 1

A metáfora nasceu para conversar com executivos, dentro de uma empresa financeira. Nós a transformamos em jargão de engenheiro.
Dívida é a distância entre o sistema e o entendimento atual do domínio — não a feiura do código.
Levar uma lista do que você decidiu não corrigir transforma o pedido de preferência em priorização.

Pilar 02: Traduza para a moeda de quem decide

O diretor não precisa entender o problema técnico. Precisa entender a unidade de medida. E, felizmente, a unidade certa já existe e é justamente a que ele usa todos os dias.

Lição 2.1 → Separe principal de juros — e apresente os dois

A referência aqui é o livro de Philippe Kruchten, Robert Nord e Ipek Ozkaya, Managing Technical Debt: Reducing Friction in Software Development (SEI Series, 2019), que dedica um capítulo inteiro à distinção entre principal e juros, custo e valor, dívida potencial e dívida efetiva.

A tradução é direta:

Principal — o custo de remediar. É um número único, em horas ou reais, com data.
Juros — o arrasto recorrente que você paga todo mês por não ter remediado. É um número por período.

Quase todo engenheiro apresenta só o principal: “são seis semanas de duas pessoas”. E é exatamente por isso que o pedido é arquivado — porque, isolado, o principal é puro custo. Sem os juros ao lado, você está pedindo para a empresa gastar seis semanas em troca de nada visível.

Com os juros, a conversa muda de natureza. Deixa de ser “quero gastar” e passa a ser “estamos gastando, só que parcelado e sem abater o saldo devedor”.

Lição 2.2 → Os juros são invisíveis por natureza — o seu trabalho é dar rosto a eles

Juros de dívida técnica não aparecem em nenhuma linha de orçamento. Eles se escondem dentro de custos que já foram normalizados pela organização: plantão, conciliação manual, retrabalho, incidente, prazo de entrega que ninguém mais questiona porque “sempre foi assim”.

Vamos a um caso concreto do nosso mundo. Motor de cobrança sem reprocessamento idempotente:

PRINCIPAL
  6 semanas × 2 engenheiros ................... R$  96.000

JUROS (por ano, hoje)
  Conciliação manual pós-falha
    4h/semana × 52 × R$ 120/h ................. R$  24.960
  Plantão acionado por reprocesso duplicado
    ~2 incidentes/mês × 5h × 2 pessoas ........ R$  28.800
  Retrabalho de atendimento (estorno indevido)
    ~35 casos/mês × 40 min × R$ 45/h .......... R$  12.600
  Janela de entrega travada
    3 iniciativas adiadas no ano (ver adiante)
  ─────────────────────────────────────────────────────────
  Subtotal mensurável ......................... R$  66.360/ano

Duas coisas acontecem quando você apresenta assim. Primeiro, o principal deixa de ser caro: R$ 96 mil contra R$ 66 mil por ano é payback em pouco mais de dezoito meses, e todo diretor sabe ler payback. Segundo — e mais importante — você acabou de tornar visível um gasto que a empresa já vinha fazendo sem saber que fazia.

A frase que funciona

“A gente já pagou o principal dessa dívida uma vez e meia nos últimos doze meses. Só que parcelado, em plantão e conciliação manual — e sem abater um centavo do saldo devedor.”

Não é retórica. É a descrição literal do que está acontecendo.

Lição 2.3 → Quantifique o custo de atraso — porque a intuição alheia sobre ele é péssima

Repare que na conta acima ficou uma linha em aberto: “3 iniciativas adiadas no ano”. Essa linha costuma ser a maior de todas, e quase ninguém a preenche.

O conceito é o Custo de Atraso, formulado por Donald Reinertsen em The Principles of Product Development Flow (2009). Ele mede o impacto econômico do tempo sobre a realização de valor: receita não realizada, custo de oportunidade e riscos que se acumulam enquanto algo espera na fila. O conselho dele é célebre — se você só puder quantificar uma coisa, que seja o custo de atraso.

E há dois dados no trabalho de Reinertsen que valem ouro numa reunião:

Cerca de 85% dos gestores de produto não conhecem o próprio custo de atraso.
Quando estimam por intuição, as estimativas divergem entre si numa proporção de até 50 para 1.

Traduzindo: quem chega com esse número calculado tem uma vantagem informacional enorme sobre todo mundo que chega com sensação — inclusive sobre pessoas hierarquicamente acima. Não porque seja mais inteligente, mas porque fez uma conta que os outros presumiram impossível.

O caso mais citado é o da Maersk Line: uma funcionalidade que ficou 38 semanas parada em filas, com custo de atraso superior a US$ 200 mil por semana — perto de US$ 8 milhões em receita não realizada por algo que ninguém percebia como custo, porque fila não aparece em relatório.

Para ordenar iniciativas concorrentes, Reinertsen propõe o CD3: custo de atraso dividido pela duração. É a régua que responde à pergunta que o seu gestor realmente tem — não “isso é importante?”, mas “isso é mais importante do que as outras sete coisas que estão na minha mesa?”.

Aplicando ao domínio bancário

Uma integração de Pix travada por um mês não custa “um mês de time”. Custa a receita de tarifa não capturada nesse mês, mais o custo de aquisição dos clientes que abriram conta em outro lugar, mais o risco de multa se houver prazo regulatório envolvido. Quando você monta essa conta, descobre com frequência que o custo de atraso é uma ordem de grandeza maior do que o custo do trabalho — e essa é a informação que muda a decisão.

Pense comigo — antes de apresentar um número

Eu estou apresentando principal, juros, ou os dois? Se for só o principal, você está pedindo custo puro. Sem os juros, a resposta racional do outro lado é não.
Onde os juros estão escondidos hoje? Plantão, conciliação manual, retrabalho de atendimento, prazo inflado. Procure em orçamentos que já existem e ninguém questiona.
Quanto custa cada semana de atraso? Receita não capturada, custo de oportunidade, exposição regulatória. Se você nunca fez essa conta, faça uma vez — o resultado costuma surpreender você antes de surpreender o gestor.
Isso é mais importante do que as outras coisas na mesa dele? Essa é a pergunta real. Responder a ela com CD3 é mais honesto do que responder com convicção.

Pontos altos do Pilar 2

Principal e juros é a estrutura mental que a área financeira já domina. Use a linguagem dela em vez de inventar a sua.
Juros de dívida técnica se pagam parcelados e invisíveis — dar rosto a eles é metade do trabalho de convencimento.
Quantifique o custo de atraso: a intuição alheia sobre ele erra por ordens de grandeza, e quem calculou tem vantagem informacional real.

Pilar 03: Meça sem fingir precisão

Vamos para o pilar que separa o profissional maduro do vendedor interno. Porque o Pilar 2 tem um efeito colateral perigoso: quando você aprende a produzir números, fica tentador produzi-los com uma confiança que os dados não sustentam.

E diretor experiente detecta falsa certeza. Uma vez detectada, tudo que você disser depois entra com desconto — inclusive o que era verdade.

Lição 3.1 → Medir é reduzir incerteza, não eliminá-la

A referência é Douglas Hubbard, How to Measure Anything: Finding the Value of “Intangibles” in Business. A tese central liberta o engenheiro do impasse mais comum: “não dá para medir isso”.

Hubbard trata medição como redução de incerteza baseada em observação — não como obtenção de certeza. E faz questão de distinguir as duas coisas: reduzir incerteza é possível, eliminá-la não é, porque o mundo é complexo demais. A consequência prática é enorme: mesmo uma redução modesta de incerteza já tem valor econômico, e organizações deixam muito valor na mesa ao operar por intuição quando técnicas simples dariam clareza suficiente para escolher melhor.

Ele também é direto sobre por que as pessoas acham que algo não pode ser medido, e nenhuma das razões tem a ver com o objeto: ou a definição de medição está mal compreendida, ou o objeto da medição não foi bem definido, ou os métodos disponíveis são desconhecidos. Na esmagadora maioria dos casos em engenharia, o problema é o segundo — “a dívida do motor de cobrança” não é mensurável, mas “horas de plantão por mês atribuíveis a reprocesso duplicado” é trivial.

Lição 3.2 → Decomponha, depois fale em faixas de 90%

Duas técnicas específicas, ambas do arsenal de Hubbard, e ambas aplicáveis na próxima segunda-feira.

Decomposição. Só quebrar uma estimativa muito incerta em componentes menores já produz uma melhora substancial na estimativa — antes mesmo de coletar qualquer dado novo. Foi o que fizemos na tabela de juros do Pilar 2: ninguém sabe responder “quanto custa essa dívida”, mas todo mundo consegue estimar horas de plantão, número de incidentes e custo-hora.

Intervalo de confiança de 90%. Em vez de um número, você declara uma faixa que tem 90% de chance de conter o valor real. E há um teste simples para calibrar os limites: um intervalo de 90% implica 5% de chance de o valor real estar acima do teto e 5% abaixo do piso. Então pergunte-se se você está 95% seguro de que o valor real fica abaixo do teto que escreveu. Se não estiver, suba o teto. Faça o mesmo com o piso.

✗  "Isso vai economizar R$ 480 mil por ano."

✓  "Entre R$ 320 mil e R$ 700 mil por ano, com 90% de confiança.
    A maior fonte de incerteza é o volume de incidentes —
    trabalhamos com 18 a 30 por trimestre; se ficar perto de 18,
    o retorno vai para a ponta de baixo da faixa."

A segunda versão parece mais fraca. Não é. Ela é a única das duas que sobrevive a uma auditoria dos números daqui a um ano — e, portanto, a única que constrói credibilidade em vez de gastá-la.

Há ainda um efeito que vale mencionar: pessoas não são naturalmente boas em produzir intervalos calibrados, mas essa é uma habilidade treinável, com melhora mensurável por repetição e feedback. Vale exercitar em time, comparando estimativas passadas com resultados reais.

Lição 3.3 → Use evidência de sistema, não evidência de opinião — e pare de medir o que não muda a decisão

Números que você produziu sozinho, sobre o seu próprio pedido, têm um problema óbvio de credibilidade. Por isso vale ancorar parte do argumento em métricas que o time já coleta e que não foram inventadas para essa reunião.

As métricas DORA — lead time para mudança, frequência de deploy, taxa de falha de mudança e tempo de restauração de serviço, popularizadas em Accelerate, de Nicole Forsgren, Jez Humble e Gene Kim — funcionam bem porque descrevem o comportamento do sistema ao longo do tempo, não a sua opinião sobre ele. “A taxa de falha de mudança nesse serviço é 3× a média dos demais, há seis trimestres” é um fato observável.

Com uma ressalva que aumenta a sua credibilidade justamente por ser dita em voz alta: DORA é indicador de sistema e de time, não instrumento de avaliação individual. Se você não disser isso, alguém em algum momento vai usar o seu gráfico para avaliar pessoas, e o dano será atribuído a você.

Por fim, o critério que economiza semanas de análise, também de Hubbard: se a informação não tem influência sobre a decisão, ela não tem valor. Antes de o time gastar duas sprints instrumentando algo, pergunte qual o limiar em que aquele número mudaria a escolha. Se não existe limiar — se o “sim” ou “não” será o mesmo em qualquer resultado — a medição é curiosidade, não evidência.

Pense comigo — antes de dizer que tem certeza

Eu consigo decompor isso em três coisas que eu de fato observo? Se não consigo, o problema não é falta de dado — é que a variável ainda não foi definida direito.
Estou 95% seguro de que o valor real fica abaixo do meu teto? Se hesitei, o teto está baixo demais. Suba antes que a realidade suba por mim.
O que eu explicitamente não sei aqui? Declarar isso primeiro tira do outro lado o trabalho de descobrir depois — e é a diferença entre ser corrigido e ser desacreditado.
Se esse número der o contrário do que eu espero, a minha recomendação muda? Se não muda, eu não estou medindo. Estou procurando munição.

Pontos altos do Pilar 3

Medir é reduzir incerteza, não eliminá-la — e reduzir já é suficiente para decidir melhor.
Fale em faixas de 90%. Ponto único é promessa disfarçada de análise, e ela vence com juros.
Declarar o que você não sabe aumenta, não diminui, o peso do que você sabe.

Pilar 04: Classifique a decisão antes de pedir a decisão

Grande parte da fricção entre engenharia e gestão vem de um erro de enquadramento: tratamos decisões muito diferentes com o mesmo protocolo. Coisas triviais viram reunião de arquitetura; coisas irreversíveis são resolvidas numa thread de Slack de quinze minutos.

Lição 4.1 → Porta de uma via ou porta de duas vias

A formulação mais útil que o mercado produziu sobre isso está na carta de acionistas da Amazon. Decisões Tipo 1 são portas de uma via: consequentes e irreversíveis ou quase, e devem ser tomadas com método, lentidão, deliberação e consulta. Decisões Tipo 2 são portas de duas vias: reversíveis, e podem — devem — ser tomadas rapidamente por indivíduos ou grupos pequenos.

O diagnóstico que acompanha a ideia é o que interessa: à medida que organizações crescem, elas tendem a aplicar o processo pesado de Tipo 1 à maioria das decisões, inclusive às de Tipo 2. O resultado é lentidão, aversão a risco irrefletida, experimentação insuficiente e, por consequência, menos invenção.

Aplicando ao nosso ofício, com a nuance honesta: em software, quase nada é porta de uma via de verdade, porque quase tudo pode ser mudado com trabalho suficiente. A pergunta prática não é “é reversível?”, e sim “é reversível a que custo?”.

PORTA DE UMA VIA (ou quase)          PORTA DE DUAS VIAS
─────────────────────────────        ─────────────────────────────
Modelo de dados do razão             Biblioteca de cliente HTTP
Chave de partição no DynamoDB        Estratégia de cache
Provedor de core banking             Formato de log
Contrato de API pública              Ferramenta de observabilidade
Esquema de chaves de idempotência    Framework de teste

E aqui está o movimento que muda a reunião: declare a classificação antes de pedir a decisão. “Essa é reversível, sugiro decidirmos hoje e revisarmos em 60 dias” devolve poder ao gestor e elimina o teatro de aprovação. “Essa é de uma via, custa aproximadamente X para reverter, e por isso trouxe três alternativas com as consequências de cada uma” comunica seriedade sem drama.

Lição 4.2 → Instrumente a decisão: ADR, registro de dívida e pre-mortem

Três ferramentas concretas que transformam conversa de corredor em evidência auditável.

ADR — Architecture Decision Record. Formato proposto por Michael Nygard: contexto, decisão, consequências. O campo que quase todo mundo esquece é o das alternativas descartadas e por quê. É esse campo que protege você da pergunta “por que ninguém pensou nisso?” dois anos depois, feita por alguém que não estava na sala. Um ADR de meia página é o registro mais barato de responsabilidade compartilhada que existe.

Registro de dívida técnica. Kruchten, Nord e Ozkaya recomendam manter um registro explícito, com os itens de dívida armazenados nas mesmas ferramentas de trabalho do time e dentro de um único backlog. A lógica é simples e boa: dívida, assim como defeito e funcionalidade, representa trabalho a ser feito — então precisa ser visível e planejável, não viver numa planilha paralela que só engenheiro abre.

Isso resolve, de quebra, o problema da Lição 1.2: quando a dívida deliberada é registrada no momento em que é contraída, cobrar o pagamento depois deixa de ser opinião e passa a ser conferência.

Pre-mortem. Técnica de Gary Klein: reúna o time, declare que estamos um ano no futuro e o projeto fracassou, e peça a autópsia. Funciona porque inverte o incentivo social — em vez de precisar ter coragem para levantar um risco na frente do patrocinador, a pessoa é convidada a fazê-lo. Numa cultura em que ninguém quer ser o pessimista da sala, isso muda o que chega à mesa.

Lição 4.3 → Saber perder é parte da técnica

Você vai perder discussões. Vai apresentar a conta certa, com a faixa calibrada e o custo de atraso, e mesmo assim a decisão vai ser outra — por razões que talvez nem lhe contem, porque nem toda informação é sua para ter.

O complemento indispensável dos Tipos 1 e 2 é o disagree and commit: seguir adiante mesmo sem consenso, especialmente quando a decisão é reversível e o custo de estar errado é baixo. Mas a prática exige duas coisas que costumam ser omitidas:

Registrar a discordância sem sabotar a execução. Um parágrafo no ADR — “esta opção foi escolhida contra a recomendação da engenharia, pelas razões X; o risco identificado é Y; sugerimos revisar em Z” — é registro, não é passivo-agressividade. O que é passivo-agressivo é executar mal para provar o ponto.
Não cobrar a fatura depois. Quando o risco se materializa, a tentação de dizer “eu avisei” é enorme e o retorno é zero. O profissional que ganha autoridade de verdade é o que aparece com a solução e deixa o registro falar sozinho — ele está lá, datado, e todo mundo sabe.

Perder bem é o que compra o direito de ser ouvido na próxima. E vai haver próxima.

Pense comigo — antes de marcar a reunião

Essa porta é de uma via ou de duas — e reverter custa quanto? Se for barata de reverter, talvez você não precise de aprovação nenhuma. Precise de um prazo para reavaliar.
Estou pedindo decisão ou pedindo cobertura? São coisas diferentes, e misturá-las é o que faz reuniões de arquitetura durarem duas horas sem concluir nada.
Se isso der errado em um ano, qual será a explicação? Faça o pre-mortem antes de a decisão sair, não depois do incidente.
Se eu perder essa, eu executo bem mesmo assim? Se a resposta honesta for “não com vontade”, o problema deixou de ser técnico.

Pontos altos do Pilar 4

Diga se a porta é de uma via ou de duas antes de pedir aprovação — isso define o processo inteiro e devolve poder a quem decide.
Tratar decisão reversível como irreversível é a forma mais cara de parecer prudente.
ADR, registro de dívida e pre-mortem convertem memória de corredor em evidência datada.

Pilar 05: Construa crédito antes de precisar dele

Vamos ser explícitos sobre o que este pilar não é. Não é sobre puxar conversa no cafezinho, não é sobre virar amigo do diretor, não é sobre política de corredor. É sobre uma coisa só, e ela é mensurável: histórico de previsões cumpridas.

Há uma leitura incômoda que sustenta o pilar inteiro: dívida técnica não é, na origem, um problema técnico. Ela se manifesta como rigidez no sistema, mas é subproduto de problemas de processo e comunicação, com raiz na cultura da organização. Empresas muito siladas — onde engenharia, produto e design trabalham isolados — acumulam muito mais dívida, porque decisões de trade-off tomadas no código ficam a camadas de distância da necessidade real do cliente. Onde falta confiança, sobra dívida.

Lição 5.1 → Um caso por interlocutor, não um caso genérico para todos

Este é o erro mais caro e o mais fácil de corrigir. O mesmo problema técnico precisa de argumentos diferentes conforme quem está do outro lado:

CFO / diretor financeiro — risco financeiro quantificado, payback, custo evitado. Fale em principal, juros e prazo de retorno.
Diretor comercial / de receita — churn, capacidade do time de vendas continuar vendendo, prazo de entrega prometido a cliente.
Produto — proteção do roadmap. O argumento vencedor é: quantas entregas suas eu destravo, e quando.
Risco e compliance — exposição regulatória, rastreabilidade, prazo de resposta a demanda de auditoria. Num banco, esse costuma ser o interlocutor mais poderoso e o menos procurado por engenheiros.

Apresentar um único caso genérico para todos ao mesmo tempo obriga cada pessoa a traduzir sozinha para a própria realidade — e o resultado quase sempre é decisão nenhuma. Não porque discordem, mas porque ninguém se sentiu diretamente endereçado.

Lição 5.2 → Pense em campanha, não em reunião única — e volte com o número prometido

Ninguém aprova investimento estrutural na primeira exposição ao tema. Vale pensar como publicitário pensa: alcance e frequência. Quantas pessoas o argumento atinge, e quantas vezes.

Na prática, isso significa que o tema aparece em três ou quatro contextos antes de virar pedido formal — uma menção no relatório mensal, um dado no pós-mortem de um incidente, uma conversa de dez minutos com produto, um slide de contexto numa apresentação sobre outra coisa. Quando o pedido formal chega, ele não é novidade para ninguém. É a conclusão de algo que a organização já vinha percebendo.

A parte que quase todo mundo pula

Se você pediu aprovação prometendo “reduzir em 40% o tempo de resposta a incidente de liquidação”, volte em 90 dias com esse número exato, na mesma linguagem, mesmo que ele tenha ficado em 22%.

Sem isso, a próxima proposta parte do zero — e a organização aprende que investimento em engenharia é um lugar para onde recursos vão e do qual nenhuma notícia volta. Ter entregado 22% e reportado honestamente constrói mais crédito do que ter entregado 40% e nunca ter contado.

Lição 5.3 → Não use medo como alavanca — e reconheça que parte da desconfiança é merecida

O apelo catastrofista funciona uma vez. “Se não fizermos isso, o sistema vai cair” produz atenção imediata na primeira ocorrência. Na segunda, você é o engenheiro que grita lobo. Na terceira, o risco real que você trouxer vai ser descontado exatamente como os anteriores — e o custo desse desconto não é seu, é da empresa.

Existe uma versão mais honesta e mais eficaz: apresentar probabilidade e consequência separadas. “A chance de isso causar indisponibilidade no próximo semestre é baixa, algo entre 10% e 20%. Mas, se acontecer durante fechamento, o impacto é alto e não temos plano de contingência.” Isso é informação. O outro é chantagem emocional com sotaque técnico.

E cabe uma dose de honestidade coletiva para fechar o pilar. Parte da resistência que encontramos não é preconceito contra tecnologia — é histórico. Nós já pedimos reescrita completa que não entregou nada. Já chamamos preferência de arquiteto de necessidade de negócio. Já estimamos três meses para algo que levou onze e nunca voltamos para explicar por quê. Se formos honestos, temos uma parcela real de responsabilidade pela dificuldade que temos hoje em ser levados a sério.

A boa notícia é que crédito se reconstrói exatamente do mesmo jeito que se perde: uma previsão por vez.

Pense comigo — antes de pedir qualquer coisa

Qual foi a última previsão que eu fiz para essa pessoa, e ela se cumpriu? Se você não lembra, ela lembra. Essa é a sua linha de crédito.
Estou falando com o interlocutor certo, na moeda dele? Em banco, risco e compliance frequentemente têm mais poder de destravar orçamento do que tecnologia — e quase nunca são procurados.
Esta é a primeira vez que essa pessoa ouve falar disso? Se for, o pedido é prematuro. Primeiro o tema precisa existir; depois ele vira decisão.
Estou usando risco como informação ou como pressão? Se a frase precisa de tom dramático para funcionar, o número por trás dela provavelmente é fraco.

Pontos altos do Pilar 5

Credibilidade é ativo acumulado, não argumento apresentado. Ela se constrói muito antes da reunião em que você vai precisar dela.
Um caso por interlocutor. O caso genérico obriga cada um a traduzir sozinho, e o resultado é decisão nenhuma.
Voltar com o número prometido — mesmo quando ele decepciona — vale mais do que superar a meta em silêncio.

O que muda na segunda-feira

Os cinco pilares não são cinco assuntos. São uma sequência única, e ela cabe em cinco perguntas feitas na ordem certa, antes de abrir qualquer slide:

A linha de raciocínio, em cinco perguntas

O que é essa dívida, na definição precisa? Distância entre o sistema e o entendimento atual do domínio — não estética. E em que quadrante ela está.
Qual é o principal e quais são os juros, em reais e por período? Incluindo o custo de atraso das iniciativas que ela trava.
Qual é a minha faixa de 90%, e o que eu explicitamente não sei? Ponto único é promessa; faixa é análise.
Essa porta é de uma via ou de duas, e reverter custa quanto? Isso define quem decide e com que velocidade.
Eu tenho crédito para pedir isso — e vou voltar com qual número, em quanto tempo?

Repare no que essas perguntas têm em comum: nenhuma delas é sobre convencer. Todas são sobre fazer o trabalho de análise antes de ocupar o tempo de outra pessoa. A persuasão, quando aparece, é consequência — não método.

E vale terminar situando isso no momento que estamos vivendo. Se a IA de fato funciona como amplificador — acelerando quem tem fundamento e multiplicando o caos de quem não tem —, então a capacidade de traduzir risco técnico em decisão de negócio deixou de ser um diferencial de senioridade. Virou requisito. Times vão produzir código mais rápido do que a organização consegue avaliar, e a pessoa capaz de dizer, com número e com faixa de confiança, onde vale a pena desacelerar, passa a ser a mais valiosa da sala.

Quem só souber descrever o problema em termos de engenharia vai continuar tendo o pedido arquivado. Só que agora mais rápido.

A boa notícia — e é uma notícia boa de verdade — é que nada aqui exige talento especial. Exige uma planilha, uma conversa de minutos com quem entende do negócio, e a disciplina de voltar em noventa dias com o resultado. É trabalho, não dom.

Para ir além

Kruchten, Nord & Ozkaya — Managing Technical Debt: Reducing Friction in Software Development (SEI Series, 2019). A referência definitiva sobre principal, juros e registro de dívida.
Donald Reinertsen — The Principles of Product Development Flow (2009). Custo de atraso e CD3.
Douglas Hubbard — How to Measure Anything. Decomposição, intervalos calibrados e valor da informação.
Forsgren, Humble & Kim — Accelerate. As quatro métricas e a evidência empírica por trás delas.
Kim, Behr & Spafford — The Phoenix Project. Romance sobre um líder de TI que aprende justamente a traduzir problema de tecnologia em termo de negócio. Boa porta de entrada.
Michael Feathers — Toward a Galvanizing Definition of Technical Debt (ensaio). A definição que salva a metáfora.
Martin Fowler — TechnicalDebtQuadrant (bliki) e Steve McConnell — Managing Technical Debt (IEEE Software, 2007).
Relatórios — DORA 2025 (State of AI-assisted Software Development), CISQ 2022 (Cost of Poor Software Quality), McKinsey (Tech debt: Reclaiming tech equity).