DEV Community: Alexandre Machado

Fale com o Xerife!!

Alexandre Machado — Sat, 10 Oct 2026 23:18:10 +0000

Como esse papel ajuda a Warren no onboarding, ownership e operação de incidentes emergenciais

Então, qual foi o problema que enxergávamos?
Com o aumento de times e demandas de produto, começamos a sentir nas retrospectivas a necessidade de endereçar algumas tarefas que não se encaixavam muito bem em nossas estruturas de times.

Nesta época tínhamos somente times de produto organizados em um formato de squads e chapters e não tinhamos um time de “devops” definido.

Também, as demandas de infraestrutura estavam crescendo.

Além disso, precisávamos que novos integrantes dos times tivessem contato com nossos pipelines de deploy, entendessem nossa arquitetura de cloud e se sentissem mais seguros para operar, investigar e sugerir mudanças no processo de desenvolvimento, testes e entrega.

Tá, mas de onde surgiu esse nome???

Inicialmente chamamos de devops da semana. Só que esse nome era um pouco restritivo para as responsabilidades que queríamos atribuir.

E xerife tinha também um mindset de empoderamento e engajamento muito interessante para o propósito deste papel.

Precisávamos de um nome que pudesse receber inúmeras atribuições conforme elas surgiam. Algo como um guardião final…

A idéia então começou a ganhar adeptos e fazer sentido…

E foi em julho de 2019 que “oficializamos” para nosso canal interno de tecnologia nosso papel de xerife:

De lá para cá, cada chapter delimitou as responsabilidades do xerife conforme suas necessidades…

Chapter QA
Matheus Angellos, QA Lead: “Vejo que o papel de xerife tem diversos impactos extremamente positivos. O senso de ownership acho que é o maior deles, onde a pessoa tem que estar muito atenta a tudo que ocorre, sabendo que ela querendo ou não é a responsável por aquilo que está subindo, portanto a régua tem que estar sempre muito alta. Também é necessário muitas vezes a análise de quais problemas são de fato impeditivos, quais podem ser contornados futuramente, impactos de outros times que não somente o seu que também estão envolvidos naquele deploy. A necessidade também de ser um ponto de contato com outros xerifes e também todas as pessoas da Warren é algo que faz com que a pessoa saia da zona de conforto, pois sabemos que nem todos se sentem confortáveis com isso, mas é um baita aprendizado. Em relação a novas pessoas que vão chegando, vejo como super positiva essa primeira participação, com o devido suporte é claro, para que desde o princípio a pessoa pegue contexto do produto, das pessoas e dos fluxos da empresa como um todo.”

Olha alguns itens de responsabilidade do xerife de qualidade:

Acompanhar instabilidades gerais
Acompanhar o andamento do processo de deploy para STG na Sexta
Validar o ambiente de STG segunda pela manhã e ir atrás dos xerifes das outras squads e da infra cloud (Oliveira — quase sempre ele) pra garantir que esteja tudo ok
Acessar os ambientes de STG
Acessar a intranet e conseguir fazer buscas e pesquisas tanto no cadastro como no geral
Acompanhar os impedimentos que surgirem durante os testes e acessar os xerifes
Fazer a liberação do deploy, comunicando nos canais #xerifes-and-qas e #dev-geral, para que seja transparente a todos
Fazer o acompanhamento até o deploy virar para produção, o que pode ser feito até remotamente e após o deploy, em produção executar teste de fumaça, realizando login e navegando em uma conta real (pode ser a sua mesmo)

Chapter Android
Onboarding: “O xerife é o papel no chapter responsável por manter a ordem e os bons costumes do nosso pipeline. O principal objetivo é monitorar crashes, garantir que as branches estejam sempre syncadas e organizar nossos milestones semanais no github.”

Chapter iOS
Onboarding: “O xerife é o papel no chapter responsável por acompanhar o andamento dos deploys, fazer rollout do app para a loja e monitorar crashes e bugs. Cada um de nós fica 1 semana no cargo para garantir que tudo ocorra dentro da lei.”

Chapter Core
Paulo Immig, Tech Lead: A iniciativa do “xerifado” foi criada com o intuito de resolver um problema pontual que era dividir a carga de trabalho que acabava sobrecarregando algumas pessoas chave. No fim das contas o resultado acabou sendo ainda melhor do que essa “rotatividade” de carga de trabalho, acabou se tornando uma prática que acelera a absorção de conhecimento dos novos colaboradores da nossa arquitetura/infraestrutura como um todo, aumenta o ownership e abre espaço para que todos se destaquem.

Chapter API
Raryson Rost, Tech Lead: “Ser xerife é ser responsável por todos ambientes de tecnologia. Acredito que é a atividade que mais gera contexto e o sentimento de como a Warren funciona.

Quando você é xerife você precisa resolver qualquer problema que aconteça com os ambientes. Independente de você ter ou não contexto daquela área.

Isso garante com que o Xerife tenha que conhecer e se comunicar com outras pessoas que geralmente não são da sua stack. Assim o xerife acaba pegando mais contexto de outras áreas e do negócio inteiro.

Também é legal o processo de subxerife que temos, que faz com que o xerife consiga contextualizar e apoiar outra pessoa que está começando nessa jornada. Assim facilitando o caminho e tornando mais divertido.

Acredito que sem o processo de xerife não teríamos como crescer tão independente a nível de chapters. Pois uma chapter ficaria colidindo com outra ou uma pessoa ficaria muito ocupada para sempre.

Com o xerife sendo rotacional e esse papel existindo conseguimos dar escala na manutenção de ambientes, contextualizar e ‘rampar’ novas pessoas no negócio e também começar a criar o sentimento de influência em pessoas que ajudam outros a serem xerife.”

Acompanhe nossas novidades em https://warren.com.br

I Gave Claude Code a Voice on My Windows Laptop. The Slowest Part Is the Voice.

Alexandre Machado — Sat, 10 Oct 2026 22:55:27 +0000

At 18:59 on a Saturday I asked my laptop, in Portuguese, for a short summary of the most important tech news of the week. A voice I had cloned said "Um instante" ("one moment"). Claude Code ran a web search, and about 17 seconds after I stopped talking her answer started coming back as speech. Her pick was Google putting the first prototype satellite of Project Suncatcher in orbit.

Nothing in that loop typed a word. Speech recognition, the voice and the audio pipeline all run on the laptop. The only thing that leaves the machine is the text Claude Code sends to its own API.

The demo is in Portuguese, my first language. Turn on English captions.

AI disclosure: most of the code in this project was written by coding agents (Claude Code, OpenAI Codex and Google Antigravity) under my direction. I drafted this article with Claude from the repo's commit history, design notes and logs, then edited it myself. Every number below comes from those logs.

Where Débora came from

Débora started as a dictation tool. I forked npu-whisper, a Windows app that runs Whisper on Intel's NPU, and turned it into something I use every day: press Ctrl+Space, talk, and the text lands at the cursor. I added NVIDIA support through faster-whisper, a device priority list with fallback (RTX, then NPU, then iGPU, then CPU) and a uv tool install setup so it installs as one command instead of an afternoon of virtualenvs.

The laptop matters for everything that follows: a Core Ultra 9 185H (with an NPU and an Arc iGPU) and an RTX 4070 Laptop GPU with 8 GB of VRAM.

When I wrote about it on LinkedIn, I said the next step was connecting this voice layer to the AI agents I already use in the terminal. About 30 hours and 55 commits later, that step is done. These are the decisions that shaped it, and the place where it is still slow.

Decision 1: a local LLM was good enough to chat, and I still didn't use it

The first version of voice chat ran a local model as the brain. Before replacing it, I benchmarked three on the Arc iGPU with OpenVINO GenAI, int4, same Portuguese conversations, three samples each:

Model	First token	Tokens/s	Followed the long persona prompt
Qwen3-8B	0.3 s	~11	Badly: misread my name, wrote dates as digits, used emoji
Qwen3.5-9B	2.1 s	~6	Yes, but about 4x slower to the first token
Gemma 4 E4B	0.2 to 0.4 s	~15	Yes, every rule, and the only one that used feminine Portuguese forms on its own

Gemma 4 E4B won clearly. It answered "Débora, que dia é hoje?" with the full date spelled out for the speech engine, and asked me to repeat myself when the transcription came out garbled. With Qwen3-8B, every rule I added to the prompt made the answers worse.

I went with Claude Code anyway. A local 4B model can hold a pleasant conversation, but it can't open my repositories, check a container, read the app's own logs or search the web. Claude Code already has the tools, the project context and my instructions. So the split became: Débora owns the ears and the mouth (Whisper and the TTS), and a harness I didn't write owns the thinking. The local model is still in the code as a backend for when I want everything offline.

The obvious cost is latency. A cold claude -p call took 6.1 s for a short question. I measured the other CLIs the same way:

CLI	Version	Cold call
`claude -p`	2.1.295	6.1 s
`codex exec`	0.161.0	6.1 s
`copilot -s -p`	1.0.93	7.9 s
`agy -p`	1.3.2	9.3 s

Six seconds of silence after every sentence would kill a voice conversation. That led to the next decision.

Decision 2: keep one Claude Code process alive

Claude Code can run as a long-lived process that reads and writes JSON lines over stdio. This is roughly how Débora starts it:

claude -p --input-format stream-json --output-format stream-json --verbose \
  --include-partial-messages \
  --session-id <uuid> \
  --permission-mode acceptEdits \
  --permission-prompts host --permission-prompt-tool stdio \
  --append-system-prompt-file <voice-rules.md>

Each flag solves one voice problem:

--include-partial-messages streams text as it is generated, so the TTS can start on the first phrase instead of waiting for the full answer.
--session-id and --resume keep the same conversation across app restarts. I can also open that session in a normal terminal with claude --resume <id> and see everything she did.
--permission-prompt-tool stdio turns every tool permission into a control_request with subtype: "can_use_tool" on stdout. Débora answers on stdin.
--append-system-prompt-file adds the voice-channel rules (short spoken answers, no markdown, numbers and dates written out, the date and language of the session) on top of whatever CLAUDE.md the project already has.

The permission answer is small:

response = ({"behavior": "allow", "updatedInput": request["input"]} if allow else
            {"behavior": "deny", "message": "Permissão negada pela Débora."})
return {"type": "control_response", "response": {
    "subtype": "success", "request_id": request_id, "response": response}}

The default is to deny, with an allowlist for read-only diagnostics. For the demo I had opened it up, which is why the log shows Claude pede permissão: WebSearch followed by permission allowed.

Before writing any of this into the app, I proved it with a throwaway script. Two turns in the same process kept a test word ("jabuticaba") in context. The first text delta took 3.8 s cold and 1.8 s warm. An interrupt sent as a control_request with subtype: "interrupt" ended the turn with terminal_reason: "aborted_streaming", and the process stayed alive. That last part matters, because people talk over a voice assistant all the time.

Decision 3: send the raw transcription, mistakes included

Whisper hears "dictation engine" in a Brazilian accent as "dictêixon engine". My first idea was to have a local LLM clean the transcription before it reached Claude. I tested it, and the cleanup made things worse. It fixed the obvious errors, then "corrected" the project-specific ones into something wrong ("dictêixon engine" became "Decision Engine"), and it added about a second.

Claude Code understood all four raw test requests, because it had the repository open and could see dictation_engine.py sitting right there. So Débora sends the raw text, and the system prompt says it came from speech recognition and may contain errors.

The fix for recognition errors went to the other end of the pipeline:

Claude keeps a small voice memory at ~/.debora/harness/voice_memory.md, one line per correction: - "what was heard" → correct term (optional context). Only sessions started by Débora get this file in their prompt.
The terms from that file, plus the project names found in the working folder (folder name, pyproject.toml, package.json), are passed to Whisper as hotwords, up to 40 terms.

Over time the recognizer picks up my project vocabulary, and fewer mistakes reach Claude in the first place.

Decision 4: never lose what the user said

The bug that annoyed me most in testing: I paused mid-sentence, Débora started answering, and the second half of what I said disappeared. The fix touched several parts of the pipeline:

Whisper re-transcribes the growing segment about once a second while I'm still talking (in the demo, 11.9 s of speech transcribed in 0.2 s on the RTX, a real-time factor of 0.02). If the draft looks unfinished, like a trailing "and..." or an ellipsis, the VAD waits 2 s of silence instead of 0.8 s before cutting.
Capture and transcription keep running while Claude thinks and while Débora speaks. Nothing gets muted.
Replies go through a serial queue. Barge-in can interrupt the active turn, drain the rest of Claude's response and send the next utterance in order.
An echo filter compares what the mic heard against the sentences Débora was actually playing (60% token overlap means echo), so on laptop speakers she doesn't answer herself.

The numbers, from the demo log

Step	Turn 1: "Oi Débora, tudo bem?"	Turn 2: tech news
Final transcription after I stopped	~0.2 s	~0.2 s
Claude first token	1.4 s	17.2 s (ToolSearch + WebSearch)
First audio	31.8 s	~4.8 s ("Um instante")
Whole reply spoken	49.2 s	still talking when the log excerpt ends, 52 s in

Claude was fast on the first turn and audio was slow. The first sentence was queued at 2.3 s, but synthesis didn't start until 28 s. VRAM went from 1.3 GB to 5.0 GB in that window, so my reading is that the TTS server was still loading its model. The fix is to start it earlier and warm it up before the first turn.

The second turn shows the real problem. Débora's voice is a clone made with Chatterbox Multilingual from a short reference recording, and on this GPU it synthesizes slower than real time. The chunks in that reply took between 1.1x and 1.4x their own audio length to generate (for example, 5.9 s of work for 5.1 s of speech). Every sentence waits for the previous one, so the gap grows over a long answer.

Claude Code was not the bottleneck. With the process warm, its first token came in 1.4 s on a simple turn, and the web search turn spent its time on tools. What slows the conversation down is the voice: a voice-cloning TTS model sharing 8 GB of VRAM with Whisper on a laptop.

Who actually wrote the code

Most of the 55 commits were written by agents. Claude Code coordinated: it broke the work down, wrote most of the harness and dispatched tasks. Codex picked up work in parallel through codex exec, mostly because I had spare quota there, including the code and security reviews before merging. Antigravity got research questions and UI ideas, like how to show voice mode in both the tray icon and the overlay. Its first pass left some mess behind that Claude later cleaned up.

My part was the one the agents couldn't do. I talked to her while testing, found bugs by ear ("your text gets cut off next to the mascot", "half of my sentence vanished when you interrupted me"), read the logs with them, and decided what stayed. Some of those decisions were about what not to build: no pre-cleanup LLM, no terminal UI for now, and no new Windows-only dependencies.

Limitations

Débora runs her own headless Claude Code session. She can't drive a terminal you already have open.
Claude answers in markdown. Only the speakable part goes to the TTS, and code and lists stay in the overlay and the log.
It is Windows-only today, and the voice chat needs a GPU to be pleasant.
The Whisper language setting matters. If it's set to English, Portuguese speech gets translated before Claude sees it.

What's next

The next piece is automatic hardware distribution. At startup Débora will probe the NPU, the iGPU and the RTX, then decide where Whisper, the TTS and a local model should each run, with a fallback for each component instead of one global device. The goal is to take the voice off the critical path. One option on this laptop is Whisper on the NPU, which would leave the whole RTX to the TTS.

The code is MIT licensed: github.com/alexandre-machado/debora-whisper.

One question, because I haven't solved it: has anyone gotten a local, voice-cloned TTS running faster than real time on 8 GB of VRAM? Which model, and what did it cost you in quality?

mARC – IRC-style AI agent team for Claude Code that runs its own repo

Alexandre Machado — Mon, 06 Jul 2026 20:49:12 +0000

I've spent the last months running my repos with an AI team instead of an AI assistant. Today I'm releasing the thing that made it work: mARC, an IRC-style agent team for Claude Code.

The problem first. A single AI coding session is a brilliant engineer with no memory, no process, and no colleagues. It writes code fast and loses track faster. Decisions evaporate when the chat ends. Work happens that no board ever sees. And the same session that wrote the code is the one that reviews it, which means nobody reviews it. A smarter model doesn't fix any of this. Teams weren't invented because engineers were dumb. They were invented because shipping needs structure.

So mARC gives the AI a team structure instead of a bigger brain. When you open the channel you talk to @techlead, an operator that behaves like a tech lead, not like a code generator. Five specialists idle in the channel until pinged: an engineer, an SRE, a designer, a security reviewer, and a researcher. You say "users are getting pinged when we save issues, fix it". The tech lead writes the spec, opens a GitHub issue, puts it on the Project board, dispatches the engineer in the background, and keeps talking to you while the work runs.

Four rules turn this into a team instead of a fan-out script.

Specs before dispatch. A vague task produces a vague PR. The operator won't delegate anything that lacks a goal, acceptance criteria, affected files, and constraints. If something's missing it asks you first, because one question now is cheaper than a reverted PR later.

The board is the source of truth, and it gets audited. Work lives in GitHub Issues and a Project board, not in the chat scrollback. Before dispatching anything, the operator checks the board against reality: merged PRs, deploys, CI. Boards lie. Merged PRs don't. Status actually means something here. Blocked means it needs you. Done means merged and validated.

Nothing merges without a review the author can't skip. Every PR gets a security pass on its diff before merge. The reviewers are read-only by contract: the security agent and the researcher physically have no write tools. At one point we considered giving them a scoped write folder. The researcher went off, read OWASP's LLM guidance and GitHub's token-hardening docs, and came back recommending against its own write access. The idea died in review, where it belonged.

The process itself is versioned. When something goes wrong, the lesson doesn't die in the chat. It lands in the playbook via PR and gets reviewed like any code. The team that made the mistake ships the rule that prevents it.

Does this actually work? mARC runs its own repository, and every issue, PR, security review, and decision record of the team building the team is public. Including the embarrassing ones.

My favorite: the team's own issue template was writing handles like @dev into GitHub issue bodies. Those are real GitHub accounts owned by real strangers, and they got mentioned on every issue we filed. One release even listed them as contributors. The team fixed the template, sanitized 14 historical issues, and added a CI gate so it can't happen again. Then the security review of that fix caught that the gate was case-sensitive, so @Dev would have slipped through. One grep flag. That's what a second pair of eyes is for.

There's more in the record. A config migration where the security reviewer probed the new parser with hostile values and got two hardenings merged before the PR landed. A day when I dispatched two writing agents in parallel without isolating their worktrees and one clobbered the other's checkout. The recovery and the dispatch rule that came out of it are both public.

To be clear about what this is not: it's not the demo where an agent writes a TODO app in one take. It's slower and noisier than that, on purpose. Specs before dispatch, review before merge, and a paper trail a human can audit six months later. The board isn't a visualization of what the AI did. It's the real board. I can grab any item on it and do it myself.

Try it in two minutes. You need Claude Code and a GitHub repo:

/plugin marketplace add NexaDuo/mARC
/plugin install marc@nexaduo
/marc:tech-lead

No config, no signup. It discovers your repo at runtime: org, board, paths. If you want the binding to persist across sessions, /marc:init scaffolds a team.toml, shows you every file before it writes anything, and writes nothing without your yes.

The repo is the real landing page: github.com/NexaDuo/mARC. The whole history of an AI team running itself is in there, embarrassments included.