DEV Community: Elves Santos

Velocidade de entrega e custo de manutenção pós IA

Elves Santos — Thu, 27 Aug 2026 13:58:08 +0000

Entregar ficou rápido demais. O problema é que manter continuou custando o mesmo preço de sempre.

Tabela de Conteúdo

O dia que a conta chegou
A gente tá comemorando a parte barata
Se isso quebrar às 3 da manhã, eu consigo debugar sem reabrir o chat?
O gargalo só mudou de lugar
O que eu faço hoje
No fim das contas, o trabalho virou escolher

O dia que a conta chegou

Vou começar confessando uma coisa.

Teve uma feature esse ano que eu entreguei numa manhã. Uma manhã. CRUD de fórmulas de análise: o cliente queria configurar a própria conta de infestação em vez de pedir pra gente cravar no código. Migration, 4 rotas novas, uma tela de 949 linhas, e o melhor pedaço, que foi trocar 208 linhas de estratégia de cálculo hardcoded por 50 linhas chamando um avaliador de fórmula. 11h17 da manhã o PR do front tava aberto. 11h32 o do back. Fui almoçar me achando o cara.

Duas semanas depois apareceram 3 tipos de análise novos. E alguém (eu) entrou no servidor e adicionou as 3 estratégias hardcoded de volta, no mapa que o motor genérico tinha aposentado 14 dias antes. O diff parte da versão antiga do arquivo. Quem escreveu aquilo não achou o caminho novo. Não entendeu que existia um caminho novo.

27 dias depois eu voltei de novo, porque quando um tipo de análise não tinha fórmula o código fazia throw new Error(JSON.stringify({...})). Uma exceção com JSON dentro da mensagem, que o handler HTTP tinha que abrir pra saber o que dizer pro usuário. Consertar isso custou 35 linhas de código e 175 de teste. 5 vezes mais teste que código, escrevendo teste pra um caso que eu deveria ter pensado na manhã em que "entreguei".

Hoje, 5 meses depois, o arquivo tem 268 linhas e ainda carrega um comentário meu: // Keep for backwards compatibility with tests. Um mapa de 16 entradas que nenhuma linha de produção lê. Ele tá lá porque 14 asserções do teste dependem dele, e ninguém (eu) teve a tarde sobrando pra desmontar. O arquivo de teste tem 351 linhas. É maior que o serviço que ele testa.

A manhã eu economizei. Os três retornos ao arquivo, não.

Ó, e antes que alguém entenda errado: eu uso IA todo santo dia, em tudo. Não é papo de "IA é ruim" não. É outra coisa.

A gente tá comemorando a parte barata

Pensa comigo no que a IA realmente barateou.

Boilerplate, DTO, migration, aquele CRUD que você já fez 40 vezes na vida, o esqueleto de um módulo novo, entender uma lib que você nunca tinha aberto. Tudo isso ficou absurdamente mais barato e eu não quero de volta nem por decreto.

Mas repara: tudo isso é o momento em que o código nasce.

E software não passa a vida nascendo. Software passa a vida sendo lido, debugado, alterado às pressas na sexta e explicado pra alguém que entrou no time mês passado. Essa parte aí continua custando o mesmo tanto que custava em 2019. Talvez mais, porque agora tem mais código.

Então quando você olha e fala "cara, eu tô 3x mais produtivo", pode ser verdade. Mas provavelmente você tá medindo só o pedaço que já era o mais rápido do processo.

Se isso quebrar às 3 da manhã, eu consigo debugar sem reabrir o chat?

Se eu pudesse deixar uma pergunta só desse artigo, seria o título dessa seção. Faz ela antes de mergear.

Se a resposta for não, você não terminou. Você só empurrou.

Tem uma versão mais dura dessa pergunta, que é: você consegue explicar por que aquilo tá daquele jeito pra uma pessoa que nunca viu esse código? Porque se você não consegue, quem tem ownership daquele arquivo não é você. E o modelo não vai estar de plantão com você no dia do incidente, isso eu garanto.

De novo, não é pra escrever tudo na mão. É pra ler antes de aceitar. Ler de verdade, linha por linha, com o dedo na tela se precisar.

Ler 200 linhas leva uns 10 minutos. Debugar 200 linhas que você nunca leu leva um dia. Essa conta nunca mudou e não vai mudar.

E olha, tem um detalhe que eu demorei pra perceber: a IA quase nunca te devolve a solução mínima. Ela te devolve a completa. Com uma abstração que você não pediu, um parâmetro opcional "pra ficar flexível", uma interface pra um caso de uso que não existe no seu projeto. Você pediu uma função, voltou um framework.

E cada uma dessas linhas é uma linha que alguém do time vai ter que ler algum dia. Ninguém escreve isso no card, mas tá lá.

O gargalo só mudou de lugar

Essa aqui eu vi acontecer no time e demorei pra entender. E ela corta dos dois lados.

O primeiro corte é no review. A gente aumentou muito a velocidade de quem escreve e não aumentou nada a de quem revisa. Continua sendo o mesmo cérebro humano, com as mesmas 24 horas, agora com PR de 40 arquivos caindo na fila.

Aí acontece o que sempre acontece quando a fila cresce. O revisor começa a bater o olho no resumo das mudanças (o diff), ver que os testes passaram e mandar aquele "por mim tá bom" (o famoso LGTM, de looks good to me). Todo mundo aqui já fez isso, inclusive eu. Não vamos fingir que não.

Só que aí você tem código que ninguém escreveu de verdade sendo aprovado por ninguém de verdade, indo pra produção onde tem cliente pagando. E quando quebra, tem duas pessoas envolvidas e nenhuma das duas sabe o que aquilo faz.

Passar o review pra IA também não resolve. Na minha opinião, ajuda a pegar coisa boba, tipo, ajuda mesmo. Mas o review não existe só pra achar bug; existe pra pelo menos duas pessoas do time saberem que aquele código existe.

O segundo corte é no seu preço, e esse é o que mais me incomoda.

No dia em que você entrega em 2 horas uma coisa que levaria 2 dias, o prazo daquela coisa virou 2 horas. Pra sempre. Ninguém volta atrás e pergunta "opa, mas quanto disso foi porque a IA acertou de primeira e quanto foi sorte?". A régua sobe e ela não desce nunca mais.

Aí chega o problema chato de verdade, aquele que não tem resposta pronta em lugar nenhum, que exige você sentar e pensar por 3 dias. E agora você tá devendo uma velocidade que na real você nunca teve.

Se você é PJ e cobra por escopo então, pior ainda. Você acabou de deflacionar seu próprio preço e ficou com a manutenção no colo de graça. Eu entreguei numa manhã e voltei naquele arquivo 3 vezes depois. Cobrei a manhã. As 3 voltas eu paguei do meu bolso, com o meu tempo.

E é aí que eu fico travado: como é que eu continuo usando isso, que é bom demais pra abrir mão, sem entregar de graça o controle do que entra no código e o preço do meu trabalho?

O que eu faço hoje

Hoje eu atuo como desenvolvedor PJ, e eu elaborei um processo de pensamento pra me ajudar a lidar com situações como essa. Esse processo, como estou chamando, foi resultado de muitos erros que eu cometi durante o uso de IA no meu trabalho.

Eu descrevo o problema, não o código. Antes eu pedia "escreve uma função que faz X" e recebia a tal solução completa. Hoje eu falo:

o que já existe no projeto,
qual a restrição,
e principalmente o que eu não quero.

Cortou muita abstração aleatória. E continuo:

Eu peço a versão pequena, explicitamente. "Faz o mais simples que resolve, sem generalizar". Você não faz ideia do tanto de código que some quando você pede isso.

A descrição do PR eu escrevo eu mesmo, do zero. O "como" pode vir gerado, tudo bem. O "por quê" é a única parte que não dá pra regenerar depois, e é justamente a que o meu eu de daqui a 6 meses vai precisar.

Se saiu um PR monstro, eu quebro. Mesmo dando trabalho. O tamanho que cabe na cabeça de uma pessoa não mudou porque a IA chegou.

E teste eu concentro onde dói. Caso feliz a IA cobre sozinha e é justamente o que menos quebra. O que quebra é falha de rede, payload torto, aquele dado legado que só existe naquele cliente antigo. É lá que mora o prejuízo.

Sobre o preço, mudou uma coisa também: eu parei de estimar código e comecei a estimar problema resolvido. Não é a manhã que eu vou passar escrevendo, é o mês em que aquilo vai ficar de pé.

No fim das contas, o trabalho virou escolher

Eu não sei se essa é a leitura certa, é o que eu enxerguei até agora mexendo com isso no dia a dia.

Mas acho que a IA não acabou com o trabalho de engenharia, ela acabou com a parte mecânica dele. E ao acabar com a parte mecânica, ela deixou exposta a parte que a gente sempre conseguiu empurrar com a barriga: entender o sistema, decidir com critério, e sustentar aquilo em produção depois.

Quem só digitava rápido perdeu vantagem. Quem consegue olhar pra 200 linhas geradas e falar "isso aqui tá errado, e o motivo é esse" ficou mais valioso, não menos. E repara no que essa pessoa tá fazendo de verdade: ela avaliou as opções e escolheu qual desvantagem ela topa carregar. O mercado chama isso de trade-off, e é literalmente o trabalho que sobrou pra gente. Generalizar agora e pagar complexidade, ou hardcodar hoje e pagar depois. Não existe escolha sem conta pra pagar, existe escolha feita com os olhos abertos e escolha feita no automático.

Velocidade de entrega é fácil de mostrar em daily. Custo de manutenção fica escondido até o dia que ele te acha.

Então gera, sim, gera bastante. Só lê o que você gerou antes de assinar embaixo.

Da comunidade para a comunidade.

Bebe água e a gente se vê no próximo artigo.

The 4 classic bugs every multi-service Node.js app hits (and how to stop reinventing the wheel)

Elves Santos — Wed, 22 Apr 2026 02:26:00 +0000

Every time I read a post-mortem from a different team, at least one of these four bugs is in it.

Customer charged twice. Inventory locked because payment crashed. We hammered the Twilio API in a loop until we got banned. Or, the 3 a.m. classic, a pod died mid-flow and the retry ran everything from scratch, including the step that had already gone out.

Always the same four. And always someone reinventing (badly) the wheel to fix them.

This post is about those four bugs, why they keep showing up, and the library I wrote to stop reinventing them. It is called kompensa. It is on npm, TypeScript-native, 20 KB, zero runtime dependencies.

Bug 1: the customer was charged twice

The most expensive scenario. Your checkout endpoint starts processing the order, the charge goes out to Stripe, but before the response comes back the client loses its connection. The mobile app has no idea if it went through, so it retries. Your API receives the POST again. And charges again.

Everyone's first fix: add a processed_requests table with a hash of the request body as a unique key, check it at the top of the handler. Works, until someone does an UPDATE on the customer's order without reprocessing payment and you realize the wrong key was in the wrong table. Or until someone adds a timestamp field to the request and every retry becomes a "new" request.

The right way is to make idempotency a first-class concept in your flow, not a side table, but the identifier that drives all behavior.

In kompensa you pass an idempotencyKey when you execute the flow. The first time, the flow runs for real. The second time with the same key, it returns the cached result without touching any side effect.

import { createFlow } from 'kompensa';

const checkout = createFlow<{ orderId: string }>('checkout')
  .step('charge', {
    run: async (ctx) => stripe.charge({
      amount: 9900,
      orderId: ctx.input.orderId,
    }),
  });

// First call: Stripe is hit.
const result1 = await checkout.execute(
  { orderId: 'ord_42' },
  { idempotencyKey: 'ord_42' },
);

// Second call with the same key: returns result1, Stripe is NOT called.
const result2 = await checkout.execute(
  { orderId: 'ord_42' },
  { idempotencyKey: 'ord_42' },
);

The rule: the key is a business identifier the client controls. The Stripe Idempotency-Key header works. The order_id works. Date.now() does NOT work, because every retry generates a new key and you are back to square one.

Bug 2: the inventory got stuck because the payment crashed

The second most expensive bug, and the one that floods the support Slack.

The flow is: reserve stock, charge the card, issue an invoice, hand off to shipping. Suppose the reserve succeeds, the charge succeeds, but the invoice fails because the customer's tax ID came back invalid from the tax service.

The request breaks, you return a 500. But the stock is reserved. And the card is debited.

In the next 10 minutes you have two paths: either the customer complains (and you find out), or nobody complains and that SKU stays marked unavailable forever. On a normal day, this breaks your Black Friday.

The solution to this kind of flow is the Saga pattern. Each step has a semantic inverse. When a step fails, you walk backward through the steps that succeeded, running each inverse.

const checkout = createFlow<{ orderId: string }>('checkout')
  .step('reserveStock', {
    run: async (ctx) => inventory.reserve(ctx.input.orderId),
    compensate: async (_ctx, reservation) => inventory.release(reservation.id),
  })
  .step('charge', {
    run: async (ctx) => stripe.charge(ctx.input.orderId),
    compensate: async (_ctx, charge) => stripe.refund(charge.id),
  })
  .step('issueInvoice', {
    run: async (ctx) => taxService.issue(ctx.input.orderId),
    // no compensate: issuing the invoice is the last step, nothing to roll back
  });

If issueInvoice errors out, stripe.refund runs automatically, then inventory.release runs automatically, and the FlowError thrown by execute() carries the original error plus any compensation errors that happened along the way.

The important part: if the compensation itself fails (the refund didn't go through), that error is collected, not masked. You know both what broke and what couldn't be rolled back, which is the worst case, and needs to page a human immediately.

Bug 3: the dumb retry loop that hammered the external API until it got banned

Less catastrophic, but it happens every week.

Someone wrote while (true) { try { ... } catch {} } around a call that sometimes fails. Or added a retry to axios/fetch without backoff. What this does: on a transient failure (503 from the provider, network timeout, 429 throttling), you bombard the upstream service in a loop until, two seconds later, you have either succeeded or been IP-banned.

A correct retry has three ingredients:

Exponential backoff: each attempt waits longer than the previous one.
Jitter: a bit of randomness so all your pods do not retry at the same time (thundering herd).
Transient vs. permanent distinction: a 400 will never succeed, so do not retry it.

import { createFlow, PermanentError, TransientError } from 'kompensa';

const flow = createFlow('payment').step('charge', {
  run: async (ctx) => {
    const res = await fetch('https://api.stripe.com/v1/charges', {
      method: 'POST',
      body: JSON.stringify(ctx.input),
      signal: ctx.signal,   // respects timeout and cancellation
    });

    if (res.status === 429 || res.status >= 500) {
      throw new TransientError(`stripe ${res.status}`);
    }
    if (!res.ok) {
      // 400, 401, 402, 404: no point retrying
      throw new PermanentError(`stripe rejected: ${res.status}`);
    }
    return res.json();
  },
  retry: {
    maxAttempts: 5,
    backoff: 'exponential',
    initialDelayMs: 200,
    maxDelayMs: 10_000,
    jitter: true,
  },
  timeout: 10_000,
});

With that you wait 200ms, 400ms, 800ms, 1.6s, 3.2s between attempts (with jitter randomizing each one). If it is a 400 from Stripe, zero retries. If it is a 503, retry with backoff up to the fifth attempt.

The difference between this and while(true) try catch is not academic: it is the difference between "your integration works under pressure" and "your IP got banned by Stripe and you need to open a ticket with them".

Bug 4: the pod crashed mid-flow and the retry ran everything again

The subtlest one, and the most fatal when it happens.

Your service instance went down after charging the card but before creating the shipment. The job queue (BullMQ, SQS, whatever) re-delivers the job. The worker loads the payload, runs the flow from the top, and charges the customer again.

Idempotency from Bug 1 helps, but only if you have idempotency inside the flow. If your steps are hand-rolled try/catch blocks, an idempotent charge does not save you from double-booking shipping.

The correct fix is to persist the flow state at every transition, and on retry, continue from where it stopped. Every successful step writes a record. If the process dies, the next execution looks at the record and skips the completed steps.

In kompensa this is automatic once you plug in a durable adapter (Postgres or Redis):

import { Pool } from 'pg';
import { createFlow } from 'kompensa';
import { PostgresStorage } from 'kompensa/storage/postgres';

const storage = new PostgresStorage({
  pool: new Pool({ connectionString: process.env.DATABASE_URL }),
});
await storage.ensureSchema();  // creates the kompensa_states table

const checkout = createFlow<CheckoutInput>('checkout', { storage })
  .step('reserveStock', { run: reserveStock, compensate: releaseStock })
  .step('charge',       { run: charge,       compensate: refund       })
  .step('ship',         { run: ship                                    });

// Worker processing a job
worker.process(async (job) => {
  return checkout.execute(job.data, {
    idempotencyKey: `order-${job.data.orderId}`,
  });
});

If the worker crashes after charge but before ship, the next consumer that picks up the same job (with the same idempotencyKey) loads the persisted state, sees that charge already finished as success, and continues straight to ship. No duplicate charge, no duplicate reservation.

On top of that, the Postgres adapter holds a pg_advisory_lock on the connection, so even if two workers race for the same job at the same time, only one passes the "load state" gate. The other one waits or fails fast (configurable), depending on your policy.

Putting it all together

The honest way to show this is a full checkout: reserve, charge, invoice.

import { Pool } from 'pg';
import { createFlow, FlowError, LockAcquisitionError } from 'kompensa';
import { PostgresStorage } from 'kompensa/storage/postgres';

const storage = new PostgresStorage({
  pool: new Pool({ connectionString: process.env.DATABASE_URL }),
});
await storage.ensureSchema();

const checkout = createFlow<CheckoutInput>('checkout', {
  storage,
  lockWaitMs: 0,   // if another worker is already processing this key, fail fast
  defaultRetry: { maxAttempts: 3, backoff: 'exponential', initialDelayMs: 200 },
})
  .step('reserveStock', {
    run:        (ctx) => inventory.reserve(ctx.input.items),
    compensate: (_ctx, res) => inventory.release(res.reservationId),
  })
  .step('charge', {
    run:        (ctx) => stripe.charge(ctx.input.userId, ctx.input.amount),
    compensate: (_ctx, c) => stripe.refund(c.id),
    timeout: 10_000,
  })
  .step('issueInvoice', {
    run: (ctx) => taxService.issue(ctx.input.orderId, ctx.results.charge.id),
  });

app.post('/checkout', async (req, res) => {
  const idempotencyKey = req.header('Idempotency-Key');
  if (!idempotencyKey) return res.status(400).json({ error: 'missing key' });

  try {
    const result = await checkout.execute(req.body, { idempotencyKey });
    res.json(result);
  } catch (err) {
    if (err instanceof LockAcquisitionError) {
      return res.status(409).json({ error: 'in progress, retry shortly' });
    }
    if (err instanceof FlowError) {
      // Everything already compensated. Client sees a clean business error.
      return res.status(422).json({
        error: err.message,
        failedAt: err.failedStep,
      });
    }
    throw err;
  }
});

Twenty lines of endpoint and you get:

Idempotency (the client can retry freely).
Exponential backoff with jitter on the payment step.
Per-step timeout.
Saga compensation on the inventory and card.
Distributed lock, so you never have two workers on the same key.
Resume after crash.
Structured errors separating "another worker is processing this" from "the flow failed and was already rolled back".

Compare that with the nested try/catch version that usually lives there. Not the same language.

When NOT to use this

Being honest with myself and with you: kompensa has a deliberately small scope.

If your workflow runs for days, has steps waiting for human approval, needs deterministic history replay, or has to coordinate across a fleet of workers with cross-workflow signals, you want Temporal or AWS Step Functions. Kompensa does not replace either of them. It lives inside your process, the flow runs in seconds to minutes, and it has no history, no replay, no separate worker service.

It is the reliability layer inside your service, not an external orchestrator.

For most checkouts, onboardings, order syncs, and payment flows I have seen, that is what you actually need. Temporal is overkill for 90 percent of cases.

Try it

npm install kompensa

The code is open on GitHub, fully TypeScript, zero runtime dependencies, ESM plus CJS. It ships with 73 tests (50 unit plus 23 integration against real Postgres 17 and Redis 7), including a crash simulation that uses pg_terminate_backend to prove the lock releases when the worker dies.

Feedback is welcome. MIT, at github.com/sirelves/kompensa.

Anyone who has ever lost a night debugging stuck inventory will understand.