#engenharia-de-software
78 posts
2026 - outubro
2 posts2026 - setembro
2 posts2026 - julho
1 post2026 - junho
2 posts2026 - maio
2 posts2026 - abril
1 post2026 - março
2 posts2026 - fevereiro
1 post2026 - janeiro
1 post2025 - maio
1 post2023 - agosto
1 post2022 - outubro
1 post2022 - maio
1 post2021 - outubro
1 post2021 - setembro
1 post2020 - dezembro
1 post2020 - maio
1 post2019 - outubro
1 post2019 - julho
2 posts2019 - junho
1 post2018 - novembro
1 post2017 - agosto
1 post2017 - junho
2 posts2017 - maio
1 post2015 - dezembro
2 posts2015 - novembro
1 post2014 - setembro
1 post2014 - agosto
1 post2014 - março
1 post2014 - janeiro
1 post2013 - novembro
1 post2013 - outubro
1 post2013 - agosto
1 post2013 - junho
1 post2013 - maio
3 posts2013 - abril
1 post2013 - março
1 post2012 - agosto
1 post2012 - julho
1 post2011 - abril
2 posts2010 - julho
1 post2010 - abril
1 post2010 - janeiro
2 posts2009 - novembro
1 post2009 - setembro
1 post2009 - julho
3 posts2009 - junho
1 post2009 - maio
1 post2009 - março
1 post2009 - fevereiro
1 post2008 - dezembro
2 posts2008 - outubro
1 post2008 - julho
2 posts2008 - junho
1 post2008 - fevereiro
1 post2007 - dezembro
1 post2007 - setembro
1 post2007 - julho
1 post2006 - novembro
1 post2006 - outubro
1 post2006 - setembro
1 post2006 - abril
1 post2026 - outubro
2 postsLLMs + Agentes = competente o suficiente
Uma síntese do que venho medindo e escrevendo: os LLMs convergiram. A arquitetura transformer chegou perto do teto, a guerra de parâmetros acabou, e o salto que todos sentimos em 2025 e 2026 veio do harness agêntico (tool calling, prompt caching, sessões longas), não de uma inteligência de base ordens de magnitude maior. Reconto a linha do tempo de 2019 pra cá com fontes, explico por que o agente permite um modelo menos denso, e por que isso já é competente o suficiente pra automatizar engenharia de software de verdade.
Entendendo o Hype do Jev: pra que serve?
O Jev é um classificador hospedado, e o choque de '193x mais rápido' só existe porque muita gente usa LLM de chat como classificador caro. Reproduzo o ensaio do Paulo Câmara, da LUA Vision, com os gráficos dele, explico o que é um classificador e por que é a primeira coisa que um cientista da computação pensa, aponto onde o ensaio pede desconto, comparo com as alternativas abertas Clef e Laya, e fecho com como pensar em ferramenta desse tipo no seu projeto.
2026 - setembro
2 postsOs Limites das LLMs: Boas em reproduzir o que existe. Caras pro que não existe
Todo LLM foi treinado só no que é público, mas 81,5% da atividade no GitHub acontece em repositórios privados e o código de todo software proprietário nunca entrou no treino. Nos meus projetos de retrocomputação senti na pele onde a máquina para: sem referência e sem oráculo, ela gira em força bruta direcionada.
Parem de inventar desculpas e façam mais deploy! Com a IA, a premissa mudou. Entendam.
Com LLM de fronteira errando menos que a maioria dos devs humanos, a única desculpa real pra segurar deploy é a burocracia do seu próprio processo de review. Uso meus projetos open source, CI/CD multiplataforma e números reais de contribuição pra mostrar como faço isso desde fevereiro.
2026 - julho
1 postFiz o Fable 5 analisar código do TikTok, Clash of Kings e Gov.br - Entendendo Fingerprint
Uma análise estática, feita com o Fable 5, compara o fingerprint opaco do TikTok, o UUID persistente do Clash of Kings e os cuidados de privacidade do gov.br, com ressalvas sobre o método.
2026 - junho
2 postsPor que LLMs vão falhar na Sua Empresa?
A tese, assumidamente especulativa, é que LLMs amplificam processos onde pessoas terceirizam decisões. A alternativa proposta são ciclos diários de decisão, implementação, teste e revisão próximos do resultado.
Controvérsia de IA em contribuições de projetos de código aberto - minha opinião
IA em contribuições open source veio para ficar, mesmo trazendo AI slop, regressões e falsos bugs. A saída prática é automatizar triagem e auditoria, sem tirar do humano a decisão final.
2026 - maio
2 postsBoas práticas de projetos de código aberto com LLM - O Mínimo
Projetos open source feitos com LLM só ficam prontos com instalação simples, testes e CI confiáveis e documentação focada no problema. Padronizar releases e deploys torna a automação previsível.
Terminando Minha Maratona de IA: Sucesso ou Fracasso?
Após mais de 500 horas em 24 repositórios, Akita ranqueia seus experimentos e conclui que Codex e Claude Code sustentam programação diária, mas sem revisão e XP a produtividade vira slop.
2026 - abril
1 postClean Code pra Agentes de IA
Clean Code muda de peso quando o leitor primário é um agente: código pequeno, nomes greppáveis, contexto de proveniência, testes headless e regras explícitas reduzem navegação, custo e erros.
2026 - março
2 postsO código fonte do Claude Code vazou. O que achamos dentro.
Analisei o source map que vazou do Claude Code e encontrei features escondidas, memória em camadas, multiagentes e um DRM baseado em xxHash64. O código também expôs um produto difícil de manter.
Software Nunca Está 'Pronto' — 4 Projetos, a Vida Pós-Deploy, e Por Que One-Shot Prompt É Mito
Depois de 125 commits pós-publicação em quatro projetos, bugs reais, novas features, releases e contribuições externas reforçaram minha conclusão: one-shot serve para demo. Produção exige iteração, testes, CI e decisões humanas.
2026 - fevereiro
1 postTestes de Integração em MonoRepo | Bastidores do The M.Akita Chronicles
Testes unitários não bastavam para três apps que compartilham Markdown. Um ambiente de integração com cache, dados reais via rsync, pipeline paralelo e preflight encontrou bugs que mocks escondiam.
2026 - janeiro
1 postVibe Code: Eu fiz um appzinho 100% com GLM 4.7 (TV Clipboard)
Usei o GLM 4.7 para criar o TV Clipboard, um app Go com WebSockets, QR Code e clipboard remoto. Após mais de 10 horas e 250 prompts, ainda precisei revisar segurança, testes e manutenção.
2025 - maio
1 postRANT - LLMs são LOOT BOXES!
Depois de gastar quase USD 150 em testes, concluí que LLMs ajudam em tarefas pequenas, mas programação real continua parecendo uma loot box cara: mais tokens e agentes não garantem código correto.
2023 - agosto
1 post[Akitando] #144 - Modelagem de Software é Difícil? | "Ver" vs "Enxergar"
Modelagem e arquitetura não seguem uma receita pronta: nascem da experiência com problemas e código real. Livros, open source e mentoria ajudam a desenvolver o olhar para tomar decisões melhores.
2022 - outubro
1 post[Akitando] #130 - Rant: Projetos, TESTES e Estimativa??? | Rated-R
Akita defende provas de conceito, testes, pull requests e integração contínua para errar cedo e evitar regressões. Estimativas servem como ordem de grandeza, não como previsões exatas.
2022 - maio
1 post[Akitando] #119 - Rant: Aprendizado na Beira do Caos | Rated R
Cruzo caos, qualidade, Lean, Six Sigma e Agile para explicar por que não existe fórmula de sucesso. O caminho é assumir riscos controlados, testar cedo, errar barato e ajustar continuamente.
2021 - outubro
1 post[Akitando] #106 - Recomendação de Livros - Introdução à Design Emergente
Akita recomenda livros de algoritmos, compiladores, código limpo, agilidade, padrões e DDD, defendendo que eles oferecem fundamentos e vocabulário, mas que o design emerge do código em uso.
2021 - setembro
1 post[Akitando] #104 - RANT: Empreendendo com Software do JEITO ERRADO!
Akita critica empreendedores que tentam especificar tudo, terceirizam o core e economizam na equipe. Sua proposta combina um sócio técnico, um MVP, equipe interna e evolução contínua.
2020 - dezembro
1 post[Akitando] #88 - RANT: Selo de Segurança é Marketing | Entendendo o Fator Humano
Casos de vazamento, phishing e engenharia social mostram que pessoas continuam sendo o elo mais explorado. Processos, auditorias e frameworks ajudam a reduzir riscos, mas não criam segurança absoluta.
2020 - maio
1 postO Resultado do Modelo do Imperial College sobre a COVID-19 pode estar ERRADO
Akita examina a implementação C++ do modelo de COVID-19 do Imperial College, aponta testes insuficientes e resultados divergentes com os mesmos seeds. Sem código histórico e inputs completos, as projeções não podem ser verificadas.
2019 - outubro
1 post[Akitando] #64 - Começando na Carreira de TI | Faculdade? Níveis de Experiência?
Akita compara cursos de Computação, Engenharia de Software e Sistemas de Informação e explica que a senioridade depende de experiência, decisões confiáveis, orientação e revisão de código.
2019 - julho
2 posts[Akitando] #57 - O Guia DEFINITIVO de Organizações | Desconstruindo o Modelo Spotify [RATED R]
Fabio desmonta a ideia de um “Modelo Spotify” copiável e argumenta que squads, tribes e chapters não resolvem organizações desalinhadas. O caminho passa por direção clara, bons profissionais e melhoria contínua.
[Akitando] #55 - Refletindo sobre RESOLUÇÃO de Problemas | O bug do Premiere
Depois de travar o Premiere durante uma edição pesada, Fabio investiga o problema e encontra uma saída sem trocar de hardware, sistema ou ferramenta. A lição é testar hipóteses e reconhecer o que ainda não se sabe.
2019 - junho
1 post[Akitando] #51 - Esqueça Metodologias "Ágeis" | [Rated R]
Fabio critica o Ágil vendido como processo, métrica ou cerimônia e recupera a ideia central: profissionais responsáveis devem usar práticas como XP para entregar valor e tomar decisões reais.
2018 - novembro
1 post[Akitando] #23 - The MM-M: O Melhor Livro de Software?
Akita revisita The Mythical Man-Month, de 1975, para mostrar que comunicação, equipes pequenas, integridade conceitual, testes e construção incremental continuam resolvendo problemas atuais.
2017 - agosto
1 postPor que Falar Mal do Ruby on Rails é Simplesmente Preguiça
Ruby on Rails não morreu nem lidera mais o mercado. Seu legado ajudou a definir o status quo da web, de Git e testes contínuos à nuvem, deploy contínuo e métricas.
2017 - junho
2 postsEstimativas São Promessas - Uma Metáfora Melhor
Estimativas podem virar promessas quando há gestão de risco: trave tempo e custo, priorize os primeiros 20% do escopo e use entregas em staging e velocidade como termômetros para ajustar o rumo.
A Economia do Desenvolvimento de Software
Para pequenas equipes, a economia do software começa pelo menor produto que funciona, levando o tempo em conta e evitando dívida técnica, microsserviços prematuros e otimizações de performance sem necessidade.
2017 - maio
1 postGuilda de Programadores - Religião e Esportes
Akita compares technology communities to religions and sports teams, showing how identity and confirmation bias distort technical choices. Professionals accept trade-offs and own their decisions.
2015 - dezembro
2 postsEx Manga Downloadr - Parte 5: Deixando mais robusto!
Timeouts do MangaFox expose a flaw in Ex Manga Downloadr’s Workflow. O autor usa Task.Supervisor e retries limitados para capturar erros do HTTPotion, deixando a refatoração com GenServer como dívida técnica.
Ex Manga Downloadr - Parte 4: Aprendendo Através do Refactoring
O refactoring do Ex Manga Downloadr troca seis blocos repetidos por macros, melhora o uso do Floki e usa testes online para validar parsers. O projeto chega à versão 1.0.0 com dois arquivos a menos.
2015 - novembro
1 postObservando Processos em Elixir - The Little Elixir & OTP Guidebook
Com GenServer, Supervisor e Observer, mostro um worker sendo reiniciado, um pool de 5 processos sendo reposto e o runtime permanecendo ativo, embora o estado do worker seja perdido.
2014 - setembro
1 post[Off-Topic] Agile: a Verdade por trás do Método
Defendo que Scrum, XP e outras práticas Ágeis não salvam equipes ruins: elas expõem riscos e problemas rapidamente. Agilidade depende de pessoas comprometidas, prática contínua e mudanças concretas de comportamento.
2014 - agosto
1 post[Small Bite] Um pouco tarde: O Grande Debate Sobre TDD
Depois de assistir ao keynote de DHH e ao debate com Martin Fowler e Kent Beck, o autor considera a disputa secundária: seja Test-First ou Test-After, o essencial é escrever testes.
2014 - março
1 post[Off-Topic] Lean está Morto, longa vida à Eficiência
Agile e Lean viraram uma indústria de cursos, certificações e ferramentas que obscurece seus princípios. O texto defende voltar ao básico: entregar valor, evitar desperdício, aprender e questionar.
2014 - janeiro
1 postCodeClimate, Qualidade de Código e os Rubistas Sádicos
Code Climate transforma métricas de complexidade, duplicação, segurança e testes em uma nota contínua para projetos Ruby. Ela ajuda a localizar code smells, mas não substitui a avaliação humana do código.
2013 - novembro
1 post[Off-Topic] Agile feito Errado
O texto argumenta que Agile não salva equipes sem capacidade técnica e comprometimento. Planning, pair programming, qualidade e responsabilidade viram encenação, e maus profissionais precisam ser substituídos.
2013 - outubro
1 post[Off-Topic] Desmontando o #noEstimates
O autor separa projetos de operações contínuas para defender estimativas, objetivos e restrições em projetos. Para ele, restrições impulsionam inovação, mas execução competente pesa mais que qualquer metodologia.
2013 - agosto
1 post[Off-Topic] Estimativas são Promessas. Promessas devem ser cumpridas.
O autor argumenta que estimativas de software são promessas, não previsões, e que cumpri-las exige responsabilidade por comunicação, negociação, tempo e obstáculos, além de código.
2013 - junho
1 postIntrodução à Agilidade
Robert Martin conta como XP, Scrum e Crystal convergiram no Manifesto Ágil de 2001, em Snowbird. Akita critica o processo dogmático e as consultorias que colocam método acima de pessoas e do valor ao cliente.
2013 - maio
3 postsDesmistificando o método Kanban
Kanban é uma técnica do Sistema Toyota de Produção, não seu sinônimo. O texto mostra por que copiar cartões no software não basta sem racionalização, Kaizen e melhoria contínua.
Processos e Metodologias não vão te Ajudar
Processos e metodologias não criam bons desenvolvedores. O texto defende prática contínua e profissionais competentes primeiro, para só então usar técnicas e processos capazes de ampliar seu trabalho.
[Tradução] Padrões: excelência vs. mediocridade
Ao relatar um exercício na Toyota, Jason Yip mostra que o padrão era o tempo do campeão, quatro segundos. O texto contrapõe padrões que limitam a padrões que impulsionam a excelência.
2013 - abril
1 post[Tradução] Estimativa - O Melhor que Podemos Fazer
Ron Jeffries defende estimativas como intervalos de custo e velocidade, usados para testar riscos, decidir a cada duas semanas e orientar o produto sem virar promessa ou negociação.
2013 - março
1 postQuais são algumas das piores práticas para aplicações Ruby on Rails?
Ao revisar projetos Rails problemáticos, o autor aponta falta de testes, SQL manual, N+1, NoSQL sem justificativa e código sem documentação, mostrando como o ActiveRecord reduz 11 queries a 2.
2012 - agosto
1 post[Off-Topic] O Mito do "Legado"
O autor critica a reescrita automática de sistemas legados e conta como consertou, em duas semanas, um ASP com DCOM, preservando o código e conquistando um novo projeto do cliente.
2012 - julho
1 post[Off-Topic] Steve Jobs, The Lost Inverview
Ao comentar a entrevista perdida de Steve Jobs, o autor reforça que uma ideia só ganha valor com execução, refinamento e equipes talentosas, capazes de discutir, errar e melhorar o trabalho.
2011 - abril
2 posts[Off-Topic] Adendo à controvérsia HAML, SASS, Coffeescript: Tamanho do Documento
Akita argumenta que escolher HAML, SASS ou CoffeeScript exige mais que gosto pessoal: manutenção, contrato, fornecedores e contexto do cliente também definem se a troca vale a pena.
A Controvérsia CoffeeScript
Akita explica como SASS, HAML e CoffeeScript transformam código antes da execução e distingue ganhos reais de manutenção no SASS de escolhas estéticas, com custo extra para quem dará suporte.
2010 - julho
1 post[Screencast] Entenda Software da Maneira Correta
Nesta palestra na USP, o autor usa Open Source, Darwin, Galvão Bueno e Dwayne Johnson para questionar por que processos não garantem software de qualidade.
2010 - abril
1 post[Off-Topic] O Programador Humilde, por Edsger W. Dijkstra
Dijkstra defende humildade diante da dificuldade de programar: é melhor evitar bugs desde o início, usar abstrações e linguagens modestas, pois nenhuma ferramenta elimina a complexidade.
2010 - janeiro
2 posts[Off-Topic] Lendo os Princípios Ágeis
Os 12 princípios ágeis precisam ser lidos em conjunto: entregar valor rapidamente não dispensa qualidade, simplicidade, colaboração e melhoria contínua. Manifesto não é receita pronta.
[Off Topic] Dunbar e Cross Functional Teams
Nos experimentos de Dunbar, um laboratório multidisciplinar resolveu em 10 minutos um problema que especialistas em E. coli levaram semanas para vencer. Debate e metáforas fazem novas ideias emergirem.
2009 - novembro
1 post[Off-Topic] Restaurantes e Tecnologia
A analogia com restaurantes separa empresas cujo negócio central é tecnologia das que apenas a usam como suporte. Nas primeiras, programadores devem experimentar e criar ferramentas, como no GitHub.
2009 - setembro
1 post[Off-Topic] Procurar Raciocinar Faz Bem
Programação em par exige piloto e co-piloto ativos, agilidade é accountability, e a discórdia entre Spolsky e Bob Martin vira mote para testar práticas ágeis, entender seus motivos e recusar dogmas.
2009 - julho
3 posts[Tradução] O que faz um bom programador?
Duas traduções defendem que bons programadores priorizam usabilidade, responsabilidade, colaboração e entrega. A segunda acrescenta a preguiça criativa e a humildade de fazer perguntas simples ao depurar.
[Off-Topic] Intervir ou não Intervir? O "Catch-22" dos Co-Pilotos
A partir de acidentes aéreos, o autor adapta o protocolo PACE a equipes de software: perguntar, alertar, desafiar e intervir quando um gerente ignora riscos graves.
[Off-Topic] Autoridade vs Responsabilidade
O autor argumenta que separar autoridade e responsabilidade condena processos ao fracasso. Equipes que respondem pelos resultados devem decidir seu próprio trabalho, com especialistas atuando como consultores.
2009 - junho
1 post[Tradução] Conselhos para Gerentes de Desenvolvimento de Software
Gerald Weinberg mostra como a cultura de culpa e a comunicação incongruente sabotam projetos, enquanto a congruência melhora a resolução de problemas. A mudança passa por seis etapas.
2009 - maio
1 post[Off-Topic] As 5 disfunções de equipes em código
Cinco disfunções de equipes aparecem em anti-padrões como null checks, duplicação, código sem testes e soluções difíceis de entender. Técnicas isoladas não resolvem uma organização baseada em comando e controle.
2009 - março
1 post[Off-Topic] Net Negative Producing Programmer
Fabio apresenta o conceito de NNPP, o programador que produz prejuízo acumulando dívida técnica ou virando ponto único de falha, e distingue esse perfil de juniores dispostos a aprender.
2009 - fevereiro
1 postTradução: Scrum Flácido
Tradução do 'Flaccid Scrum', de Martin Fowler: adotar Scrum sem práticas técnicas afunda o time numa base de código bagunçada. Comento testes, refatoração, integração frequente e propriedade coletiva.
2008 - dezembro
2 postsTradução: Dívida Técnica
Tradução do artigo clássico de Steve McConnell sobre dívida técnica: a diferença entre dívida acidental e estratégica, os juros que atalhos cobram e por que registrar cada dívida no backlog.
Off-Topic: Método Científico vs Cargo Cult
Cargo cult é repetir estruturas sem entender a razão. A saída é testar hipóteses com protótipos descartáveis. Na YellowPages, quatro meses de preparação impediram que quatro de implementação virassem vinte.
2008 - outubro
1 postOff-Topic: O Manifesto Ágil, ou Como se Tornar o Google
Agilidade de verdade nasce de filosofia, confiança e equipes auto-organizadas; metodologia sozinha não basta. Do Manifesto Ágil a Conway, Pareto, Wikipedia e Google: por que cultura open source produz inovação.
2008 - julho
2 postsTradução: Por que você não deve codificar em Português
A tradução defende nomes em inglês para variáveis, funções, classes, campos, bancos e comentários, porque isso facilita manutenção e colaboração internacional. O argumento é pragmático.
Tradução: Regras de Otimização
As regras de otimização são simples: escreva código claro, meça antes de mexer e concentre o esforço nos gargalos comprovados, preservando a manutenção do restante.
2008 - junho
1 postMachucando Código por Diversão e Lucro
Traduzi o keynote de Ryan Davis e gravei um screencast em português sobre cuidar, refatorar e até “machucar” código para evoluir como programador. Os slides também estão disponíveis em PDF.
2008 - fevereiro
1 postTradução: Não sei o que quero, mas sei como conseguir
A tradução separa desenvolvimento iterativo, que espera validar e mudar uma solução, de incremental, que adiciona funcionalidade. O argumento é planejar espaço para descobrir, refinar e descartar.
2007 - dezembro
1 postCuidado com suas Closures
Closures Ruby podem manter vivos objetos e variáveis capturados sem necessidade. O texto explica o problema e sugere criar blocos no menor escopo possível.
2007 - setembro
1 post100% pure Object-Oriented: The Fallacy
O texto questiona a ideia de que mais pureza orientada a objetos torna uma linguagem melhor e defende escolher a tecnologia pelos requisitos concretos de cada projeto.
2007 - julho
1 postGoF Design Patterns - Sobreviveu ao teste do tempo?
A discussão sobre o livro GoF contrapõe críticas à complexidade e à relevância dos patterns com sua utilidade como exemplos de design, desde que não sejam copiados como receitas ou dogmas.
2006 - novembro
1 postMinha Coluna na RubyOnBr: Desenvolvimento Sustentável com Rails
A coluna percorre processos, metodologias e ferramentas para discutir desenvolvimento sustentável com Rails. A conclusão é que todo projeto precisa de algum controle, inclusive no open source, onde mantenedores organizam o trabalho.
2006 - outubro
1 postLivro Free: Getting Real, da 37signals
A 37signals libera Getting Real para leitura online, defendendo software simples, telas reais e decisões baseadas no produto que o usuário vê. A abordagem combina especialmente com web apps que evoluem continuamente.
2006 - setembro
1 postEvolução pela Concorrência
O autor defende que críticas e concorrência fazem tecnologias evoluírem. Em Rails, limitações como internacionalização, legado e tarefas assíncronas já estimularam soluções da comunidade.
2006 - abril
1 postRails Manifesto
O autor apresenta Rails como alternativa ágil à complexidade do J2EE, apoiada em DRY e Convention over Configuration. A proposta é tornar aplicações Web simples e fáceis de adaptar.