Posts

O framework Foundation Models da Apple (macOS 26) expõe um LLM de ~3B parâmetros que roda on-device, de graça, sem necessidade de API key. Mas tem um problema: ele só trabalha com Swift. E não qualquer Swift — Swift async. Seu tooling está em Python? Não tem binding. Em Rust? Também não. Um script de shell? Sem chance. O LLM mais barato do mundo (literalmente gratuito) está preso atrás de duas barreiras: o idioma e o modelo de concorrência. ...

Ontem, escrevi uma mensagem de commit com o Claude Code. O diff era uma alteração de uma linha: um erro de digitação em um comentário. Claude Opus leu o diff, pensou por dois segundos e gerou fix: correct typo in auth comment. Para isso, consumiu cerca de 800 tokens de entrada e 30 de saída, a $15 e $75 por milhão, respectivamente. Custo: uma fração de centavo. Mas multiplique isso por 40 commits por dia, 250 dias por ano, em uma empresa com 200 desenvolvedores usando agentes de codificação, e a fração de centavo se transforma em milhares de dólares gastos em uma tarefa intelectual equivalente a colocar band-aids. ...

O Google publicou o TurboQuant em 24 de março. Em 48 horas o paper tinha 575 pontos no Hacker News, as ações da Micron caíram 900 milhões de dólares, e a TechCrunch o comparava com o algoritmo da Pied Piper de Silicon Valley. Um mês depois, a névoa do hype se dissipou o suficiente para responder as únicas perguntas que importam: funciona? Posso usar hoje? E a que ninguém quer fazer: é realmente novo? ...

Você está pagando entre 20 e 200 dólares por mês para acessar LLMs. Claude, GPT, Gemini, o que seja. E a maioria das consultas feitas a partir de seus scripts e ferramentas de desenvolvimento é uma variação disto: “Classifique este erro em uma dessas cinco categorias.” “Dê um nome para essa variável.” “Diga se este commit é um fix, feat ou refactor.” “Resuma este bloco de texto em duas frases.” Enquanto isso, seu Mac com Apple Silicon tem um modelo de linguagem com 3 bilhões de parâmetros, integrado ao sistema operacional, sem custo, sem necessidade de conexão à internet, sem chave de API e sem latência de rede. E provavelmente você não está aproveitando isso. ...

Chega um momento na vida de todo programador com copilotos em que você olha a fatura mensal e pensa: “Tudo bem, mas tem mais assinatura aqui do que no meu plano da academia do bairro”. Esse momento chegou para mim com uma combinação bastante séria: Claude Max 5, Codex Plus e a tentação de experimentar Z.AI com OpenCode para os trabalhos mais baratos. A ideia parecia ótima. Mas o problema é outro: se você coloca três agentes no seu fluxo sem regras, acaba como aquele chefe de obra que tem todo mundo correndo de um lado para outro, mas ninguém segurando o projeto. ...

TL;DR: Se você está no Codex, use um command para controlar a sessão ou a aplicação, e use um skill para ensinar ao agente uma maneira de trabalhar. No Claude Code, a documentação atual já trata as skills como algo invocável com /skill-name, então os dois conceitos se misturam muito mais. No Codex, não: types pode existir como skill e /types ainda assim pode não existir. Existe uma confusão bastante comum quando você migra do Claude Code para o Codex. E isso é compreensível. ...

Imagine que você está construindo um app que analisa conversas de uma equipe de desenvolvimento. A ideia é detectar se o tom da equipe é saudável ou se há sinais de estresse. Você utiliza o NLTagger da Apple porque ele está disponível, é gratuito, funciona on-device e não precisa de servidor. Três linhas de código e tudo parece resolvido. Primeira surpresa: a frase “kill the process and restart the daemon” recebe uma pontuação de -0.6. Negativa. Quase hostil. “Fatal error in memory allocation” ganha um -0.8. E “crash report uploaded successfully” — que literalmente é uma boa notícia — gera um -0.4. ...

TL;DR: Depois de 165 sessões com Claude Code e 27 com Codex CLI, o padrão é claro: Claude para o trabalho interativo em que você precisa pensar em voz alta, Codex para tarefas autônomas que você delega e esquece. Não é sobre qual é melhor, mas sobre quando usar cada um. Meus dados mostram que a combinação é mais eficiente do que qualquer um isoladamente. São nove da manhã, café na mão, e eu tenho uma ideia ainda meio-formada sobre como reestruturar um módulo. Não sei exatamente o que quero. Só sei que o estado atual não me agrada. ...

TL;DR: As ferramentas do Python são há anos um desastre fragmentado e lento. A revolução não veio de dentro do ecossistema: veio do Rust. uv, Ruff e ty — todas escritas em Rust pela Astral — substituíram meia dúzia de ferramentas e são entre 10x e 100x mais rápidas. Parece que afinal o culto do Ferris tinha razão. Você já tentou explicar para alguém como instalar dependências em Python? “Use o pip. Bom, mas dentro de um virtualenv. Ou venv, que é o novo. Mas se você tem várias versões do Python, precisa do pyenv. E para gerenciar o projeto, use o poetry. Ou o pipenv. Ou o pdm. Ou o conda se faz ciência de dados. Ah, e o lock file é gerado por cada ferramenta em um formato diferente. E não esqueça do setup.py. Bom, agora é pyproject.toml. Bom, às vezes as duas coisas.” ...

TL;DR: Meu agente de IA tinha um arquivo de instruções com 246 linhas para gerenciar issues no Linear. Dentre elas, 150 eram gambiarras: UUIDs hardcoded, alternativas com curl, notas explicando “a CLI não suporta X”. Em vez de reescrevê-las, criei uma ferramenta que tornou essas linhas desnecessárias. Agora, essas 150 linhas se reduziram a zero. Você já escreveu um documento de instruções tão longo que a própria extensão dele é prova de que algo está errado? ...