<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>André N. Darcie</title>
  <subtitle>Blog pessoal de André N. Darcie</subtitle>
  <link href="https://andredarcie.github.io/blog/feed.xml" rel="self"/>
  <link href="https://andredarcie.github.io/blog/"/>
  <updated>2026-05-06T00:00:00Z</updated>
  <id>https://andredarcie.github.io/blog/</id>
  <author>
    <name>André N. Darcie</name>
  </author>
  
  <entry>
    <title>Como escrever código mais confiável com SDD, TDD e agentes de IA</title>
    <link href="https://andredarcie.github.io/blog/posts/tdd-com-agentes-passo-a-passo/"/>
    <id>https://andredarcie.github.io/blog/posts/tdd-com-agentes-passo-a-passo/</id>
    <published>2026-05-06T00:00:00Z</published>
    <updated>2026-05-06T00:00:00Z</updated>
    <content type="html"><![CDATA[<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0bfrcj35rjsuraxe28d6.png" alt="Capa do tutorial de TDD com agentes de IA"></p>
<p>Este tutorial mostra como usar um agente de IA para praticar TDD do zero, partindo de um requisito escrito em linguagem simples até uma implementação refatorada e com testes passando.</p>
<p>Na prática, o que vamos fazer é <strong>Spec-Driven Development alimentando o ciclo TDD</strong>: a especificação gera os testes, os testes guiam a implementação.</p>
<p>O exemplo é um caso de uso simples/abstraído: <strong>criar conta de usuário</strong>.</p>
<blockquote>
<p><strong>Para refletir:</strong> Você conhece ou usa SDD no seu dia a dia?</p>
</blockquote>
<h2>O que é SDD?</h2>
<p>SDD (Spec-Driven Development) é a prática de escrever a especificação antes de qualquer código ou teste. A spec é a fonte da verdade: tudo o que vier depois deve derivar dela.</p>
<table>
<thead>
<tr>
<th>Etapa</th>
<th>O que fazer</th>
</tr>
</thead>
<tbody>
<tr>
<td>Especificar</td>
<td>Descrever o comportamento esperado em linguagem simples</td>
</tr>
<tr>
<td>Validar</td>
<td>Revisar a spec antes de escrever qualquer código</td>
</tr>
<tr>
<td>Derivar</td>
<td>Usar a spec como base para os testes</td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>Para refletir:</strong> Quando você começa uma feature, seu primeiro passo é escrever a spec, o código ou os testes?</p>
</blockquote>
<h2>Passo 1: Definir os requisitos (SDD)</h2>
<p>Antes de escrever qualquer código, escreva o que o sistema precisa fazer em linguagem simples. Use a IA para transformar isso em um documento de requisitos.</p>
<p><strong>Prompt:</strong></p>
<pre><code class="language-markdown">Crie um arquivo .md simples, listando os requisitos
necessários para criar um caso de uso de criar 
conta de usuário com nome, e-mail e senha,
apenas com o básico.
</code></pre>
<p><strong>Resultado:</strong></p>
<pre><code class="language-markdown"># Criar Conta

## O que é isso?
Permite que uma pessoa crie uma conta na plataforma informando seu nome, e-mail e senha.

## O que o usuário precisa informar?
- Nome
- E-mail
- Senha

## Quando o cadastro é recusado?

| Situação | Motivo |
|----------|--------|
| Nome não foi preenchido | O nome é obrigatório |
| Nome tem menos de 3 letras | Nome muito curto para ser válido |
| E-mail não foi preenchido | O e-mail é obrigatório |
| E-mail está no formato errado | Precisa seguir o padrão nome@dominio.com |
| E-mail já foi usado em outro cadastro | Cada conta precisa ter um e-mail único |
| Senha tem menos de 8 caracteres | Senha muito curta |
| Senha não tem letras e números ao mesmo tempo | Senha fraca demais |

## O que acontece quando o cadastro dá certo?
A conta é criada e o sistema confirma com:
- Código único da conta
- Nome cadastrado
- E-mail cadastrado
- Data e hora do cadastro
</code></pre>
<blockquote>
<p><strong>Dica:</strong> Antes de avançar, pergunte à IA se faltou algum edge case. Requisitos incompletos geram testes incompletos.</p>
</blockquote>
<blockquote>
<p><strong>Outra dica:</strong> Peça para um modelo de IA diferente do que você está usando revisar os requisitos e apontar falhas graves, contradições ou cenários não cobertos. Modelos diferentes cometem erros diferentes.</p>
</blockquote>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Faltou alguma coisa importante que não considerei? Algum edge case?
</code></pre>
<h2>Passo 2: Visualizar o fluxo (SDD)</h2>
<p>Com os requisitos prontos, gere um fluxograma para validar o entendimento antes de escrever código.</p>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Com base no arquivo .md criado, crie um fluxograma
da esquerda para a direita exemplificando o fluxo.
</code></pre>
<p><strong>Resultado:</strong></p>
<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zg4no3nsg30meboxxyox.png" alt="Fluxograma do caso de uso CreateUser"></p>
<blockquote>
<p><strong>Por que isso importa?</strong> O fluxograma torna visível a ordem das validações e os caminhos de erro. É mais fácil revisar um diagrama com o time do que revisar código.</p>
</blockquote>
<blockquote>
<p><strong>Para refletir:</strong> Você já usou TDD? Qual foi a maior dificuldade?</p>
</blockquote>
<h2>O que é TDD?</h2>
<p>A partir daqui começa o TDD. O SDD gerou a especificação; o TDD vai usá-la para guiar a implementação.</p>
<p>TDD (Test-Driven Development) é uma técnica de desenvolvimento em três fases:</p>
<table>
<thead>
<tr>
<th>Fase</th>
<th>O que fazer</th>
</tr>
</thead>
<tbody>
<tr>
<td>RED</td>
<td>Escrever os testes antes do código. Eles devem falhar.</td>
</tr>
<tr>
<td>GREEN</td>
<td>Escrever o mínimo de código para os testes passarem.</td>
</tr>
<tr>
<td>REFACTOR</td>
<td>Melhorar o código sem quebrar os testes.</td>
</tr>
</tbody>
</table>
<p><img src="https://andredarcie.github.io/blog/img/tdd.png" alt="TDD vs sem TDD"></p>
<h3>Ameaça e defesa</h3>
<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vy4awm5rtzx1sqa2xa84.png" alt="Diagrama de ameaça e defesa no TDD"></p>
<h2>Passo 3: Criar a classe sem implementação (TDD: RED)</h2>
<p>Crie apenas o esqueleto da classe, com as dependências e a assinatura do método, sem nenhuma lógica. O método deve lançar <code>NotImplementedException</code>.</p>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Crie a classe de Caso de Uso sem implementação alguma no método,
apenas com as dependências possíveis com base nos requisitos.
</code></pre>
<p><strong>Resultado:</strong></p>
<pre><code class="language-csharp">public class CreateUserUseCase
{
    private readonly IUserReadRepository _readRepository;
    private readonly IUserWriteRepository _writeRepository;
    private readonly IPasswordHasher _passwordHasher;

    public CreateUserUseCase(
        IUserReadRepository readRepository,
        IUserWriteRepository writeRepository,
        IPasswordHasher passwordHasher)
    {
        _readRepository = readRepository;
        _writeRepository = writeRepository;
        _passwordHasher = passwordHasher;
    }

    public Task&lt;Result&lt;CreateUserResponse&gt;&gt; ExecuteAsync(CreateUserCommand command)
    {
        throw new NotImplementedException(&quot;Implementação pendente&quot;);
    }
}
</code></pre>
<h2>Passo 4: Escrever os testes (TDD: RED)</h2>
<p>Com a classe vazia criada, peça à IA para escrever os testes baseando-se nos requisitos. Os testes devem falhar neste momento, isso é esperado e correto.</p>
<blockquote>
<p><strong>Uma observação sobre o ritmo:</strong> no TDD clássico, o ciclo é executado um teste por vez: escreve um teste, faz passar, refatora, repete. Aqui estamos escrevendo todos os testes de uma vez antes de implementar, o que é uma adaptação prática para trabalhar com IA.</p>
</blockquote>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Com base no arquivo de requisitos e nessa classe de caso de uso,
escreva os testes unitários que validem cada requisito seguindo o padrão Arrange-Act-Assert, e confirme que eles estão falhando.
</code></pre>
<p><strong>Resultado: testes falhando:</strong></p>
<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kksj373octaqjfva856f.png" alt="Testes falhando, fase RED"></p>
<p>Antes de avançar, verifique se a cobertura está completa.</p>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Esses testes estão cobrindo totalmente os requisitos
ou faltou algum caso?
</code></pre>
<blockquote>
<p><strong>Regra de ouro do TDD:</strong> só avance para o GREEN depois que todos os testes estiverem escritos e falhando pelo motivo certo: <code>NotImplementedException</code>, não erro de compilação.</p>
</blockquote>
<blockquote>
<p><strong>Para refletir:</strong> Por que fechar o agente antes de implementar?</p>
</blockquote>
<h2>Passo 5: Fechar o agente e abrir uma nova sessão</h2>
<p>Antes de implementar, <strong>feche o agente completamente e abra uma nova conversa</strong> ou limpe o contexto do agente, por exemplo com <code>/clean</code>.</p>
<blockquote>
<p>Na fase GREEN, a única fonte da verdade é o teste. Não o requisito, não o fluxograma, não a conversa anterior.</p>
</blockquote>
<h2>Passo 6: Implementar para passar nos testes (TDD: GREEN)</h2>
<p>Na nova sessão, mostre apenas os testes e a classe vazia. O objetivo aqui é <strong>apenas fazer os testes passarem</strong>, sem se preocupar com qualidade, padrões ou boas práticas ainda.</p>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Com base nos testes unitários existentes para a criação de usuário,
crie a implementação do caso de uso.
</code></pre>
<p><strong>Resultado: testes passando:</strong></p>
<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c6grspa2q6ex35m65aks.png" alt="Testes passando, fase GREEN"></p>
<blockquote>
<p><strong>Importante:</strong> nesta fase é normal o código ficar feio. Validações inline, strings hardcoded, acoplamentos diretos, tudo isso é esperado. O que importa é: <strong>os testes passam</strong>.</p>
</blockquote>
<blockquote>
<p><strong>Para refletir:</strong> Com os testes passando, você colocaria esse código em produção?</p>
</blockquote>
<h2>Passo 7: Identificar os problemas (TDD: REFACTOR)</h2>
<p>Com os testes verdes, peça à IA para revisar o código com olhar crítico.</p>
<blockquote>
<p><em>Pergunte o que está errado, não se está certo.</em> Modelos de IA tendem a confirmar o que o usuário quer ouvir. &quot;O código está bom?&quot; quase sempre recebe um &quot;sim&quot;. &quot;Quais são os problemas?&quot; força uma análise real.</p>
</blockquote>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Liste os problemas encontrados no código implementado
com base nas boas práticas de desenvolvimento.
</code></pre>
<p><strong>Resultado:</strong></p>
<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/331j0ug2wvo4qj2kjrdo.png" alt="Problemas encontrados no código"></p>
<h2>Passo 8: Refatorar (TDD: REFACTOR)</h2>
<p>Com a lista de problemas em mãos, peça à IA para corrigi-los. Os testes são a rede de segurança: se alguma refatoração quebrar o comportamento, os testes vão acusar imediatamente.</p>
<blockquote>
<p><strong>Refatorar é mudar como, não o quê.</strong> O comportamento externo deve permanecer idêntico antes e depois. Se um teste quebra durante a refatoração, significa que ele estava testando um detalhe interno de implementação em vez do comportamento, e provavelmente precisa ser revisado junto com o código.</p>
</blockquote>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Refatore esses pontos de melhoria no código.
</code></pre>
<p><strong>Resultado:</strong></p>
<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4oljfano4t7f7kmjq0vh.png" alt="Código refatorado"></p>
<blockquote>
<p>Os problemas encontrados foram violações de SRP (uma classe deve ter apenas uma responsabilidade), OCP (aberto para extensão, fechado para modificação), ISP (interfaces não devem forçar dependências desnecessárias), DIP (dependa de abstrações, não de implementações concretas), DRY (não repita a mesma lógica em lugares diferentes) e um problema de segurança com salt fixo na senha.</p>
</blockquote>
<h2>Passo 9: Confirmar que tudo ainda passa</h2>
<p>Após a refatoração, rode os testes novamente para garantir que nenhum comportamento foi quebrado.</p>
<p><strong>Prompt:</strong></p>
<pre><code class="language-shell">Execute novamente todos os testes.
</code></pre>
<p><strong>Resultado: 24/24 passando:</strong></p>
<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e665v8k8tcvrcjxi92lo.png" alt="Todos os testes passando após refatoração"></p>
<h2>Passo 10: Ir além com Mutation Testing (opcional)</h2>
<p>Escrever os testes a partir dos requisitos, antes de ver qualquer implementação, já é a principal garantia de que os testes validam comportamento e não código. É exatamente o que o fluxo anterior faz.</p>
<p>Para quem quer uma camada adicional de confiança, o Mutation Testing é uma boa opção. Ferramentas como o <strong>Stryker</strong> introduzem bugs propositais no código (mutações) e verificam se algum teste falha. Se nenhum teste detecta a mutação, aquele comportamento não está sendo verificado de verdade.</p>
<p><strong>Prompt:</strong></p>
<pre><code class="language-plaintext">Com base nos testes escritos, quais mutações o Stryker
provavelmente não detectaria? Existe algum comportamento
crítico que não está sendo validado de verdade?
</code></pre>
<p><strong>Para rodar o Stryker em .NET:</strong></p>
<pre><code class="language-shell">dotnet tool install -g dotnet-stryker
dotnet stryker
</code></pre>
<p><strong>O que analisar no relatório:</strong></p>
<table>
<thead>
<tr>
<th>Resultado</th>
<th>Significado</th>
</tr>
</thead>
<tbody>
<tr>
<td>Killed</td>
<td>A mutação foi detectada: teste útil</td>
</tr>
<tr>
<td>Survived</td>
<td>A mutação passou: teste não cobre esse comportamento</td>
</tr>
<tr>
<td>No coverage</td>
<td>Nenhum teste toca aquela linha</td>
</tr>
</tbody>
</table>
<blockquote>
<p><strong>Regra prática:</strong> foque nos <strong>Survived</strong> nas regras de negócio críticas, não tente chegar a 100%.</p>
</blockquote>
<h2>Passo 11: Testar manualmente e em homologação</h2>
<p>Com os testes automatizados passando, valide o comportamento real da feature em ambiente de homologação ou por meio de testes manuais. Ferramentas e integrações que os testes unitários não cobrem só aparecem aqui.</p>
<p>Se algo der errado, não tente corrigir diretamente no código. Volte ao Passo 1 e trate o bug como uma nova demanda: descreva o comportamento incorreto, o que deveria acontecer e o que está acontecendo.</p>
<blockquote>
<p><strong>Por que isso importa?</strong> Um bug corrigido sem teste pode voltar sem que ninguém perceba. O teste que comprova o bug é a garantia de que ele nunca mais vai passar despercebido.</p>
</blockquote>
<blockquote>
<p><strong>Para refletir:</strong> O que você mudaria nesse fluxo?</p>
</blockquote>
<h2>Conclusão</h2>
<p>O ciclo completo ficou assim:</p>
<pre><code class="language-plaintext">[SDD] Requisitos → Fluxograma
[TDD] Esqueleto → Testes falhando → Fechar agente → Implementação passando → Refatoração → Testes passando
[+]   Mutation Testing → Homologação
</code></pre>
<p>TDD com IA significa usar o agente de IA para acelerar cada etapa do ciclo enquanto você, desenvolvedor, mantém o controle das decisões importantes: o que o sistema deve fazer, quais casos precisam ser testados e quando o código está bom o suficiente para ir para produção.</p>
]]></content>
  </entry>
  
  <entry>
    <title>Clair Obscure e o maior problema dos videogames</title>
    <link href="https://andredarcie.github.io/blog/posts/clair-obscure-e-a-acessibilidade-nos-jogos/"/>
    <id>https://andredarcie.github.io/blog/posts/clair-obscure-e-a-acessibilidade-nos-jogos/</id>
    <published>2026-04-23T00:00:00Z</published>
    <updated>2026-04-23T00:00:00Z</updated>
    <content type="html"><![CDATA[<p>Clair Obscure: Expedition 33 foi um dos jogos mais premiados e elogiados de 2025. Sucesso comercial, sucesso de crítica, e com uma reputação que o coloca entre os melhores da história. A minha experiência com ele é mista, e curiosamente acho que ela ilustra com clareza o maior problema estrutural dos videogames: a acessibilidade, no sentido mais amplo da palavra.</p>
<h2>Uma história que deveria ser vista por todos</h2>
<p>A história de Clair Obscure é fantástica. Rica, densa, com personagens memoráveis e um arco narrativo impressionante. Tem um plot twist no nível do melhor que já vi em qualquer mídia, momentos emocionantes, reflexões filosóficas e uma tensão artística que sustenta o jogo inteiro. Se fosse um filme, seria um candidato óbvio ao Oscar.</p>
<p>E é aí que começa o problema.</p>
<h2>O combate por turnos e a quebra de imersão</h2>
<p>Como é um jogo, Clair Obscure tem um sistema de batalha por turnos. Você caminha pelo cenário, se aproxima de um inimigo, e transiciona para uma tela específica de combate, onde você espera o ataque do inimigo, ataca, espera, ataca, e assim por diante. Quando termina, aparece uma tela de finalização da batalha e você volta ao cenário.</p>
<p>Eu não sou fã de batalha por turnos. Para mim, essa transição quebra completamente a imersão. Você está caminhando por um mundo, conhecendo aquele universo, e de repente é arrancado para uma lógica completamente diferente, mecânica e estratégica. Naquele momento você se lembra que está num jogo, e não que está vivendo aquela história.</p>
<p>Não tenho nada contra isso em si. Mas para mim, os momentos mais valiosos nos videogames são justamente aqueles em que você esquece que está num jogo. Quando você anda por um cenário por tempo suficiente, sem interrupções, e aquele mundo passa a existir de verdade na sua cabeça. O combate por turnos inviabiliza esse estado completamente.</p>
<p>Os cenários, por sua vez, são lindos artisticamente, mas labirínticos e muitas vezes confusos. Corredores que se parecem, sem direção clara. Eu me perdia o tempo todo.</p>
<h2>O parry que cansa</h2>
<p>O jogo também usa um sistema de parry, que em outros contextos acho uma mecânica fantástica. Em Sekiro, por exemplo, funciona de forma brilhante. Em Clair Obscure, acaba se tornando mecânico no sentido negativo: você aprende o padrão de ataques de um inimigo, repete o parry nas mesmas janelas, e a batalha se estende por tempo demais nessa repetição previsível.</p>
<p>O resultado é cansaço. Você acerta, acerta, acerta, e em algum momento erra por fadiga e toma dano alto. As batalhas contra chefes são longas. O modo fácil alivia a janela do parry, mas não elimina a obrigação de se engajar com o combate, de pensar nas estratégias, de participar ativamente de algo que você simplesmente não quer estar fazendo.</p>
<p>E eu sou uma pessoa que não faz conteúdo alternativo quando não está curtindo um jogo. Se não estou gostando, não faço side quests, não faço grind, não fico levantando nível para ficar mais forte. Os jogos já são longos demais na história principal. Qualquer coisa além disso é tempo que não tenho nem disposição para gastar.</p>
<h2>O dilema da acessibilidade</h2>
<p>Esse é o nó central. Para consumir uma história incrível, poética, filosófica, com personagens inesquecíveis e um dos melhores plot twists já contados nos videogames, eu sou obrigado a passar por um sistema de combate que simplesmente não é para mim.</p>
<p>Quem pode ver essa história? Apenas quem tem paciência para batalha por turnos, tempo para batalhas longas, disposição para aprender mecânicas e gosto por esse estilo de jogo. São milhões de pessoas, o sucesso comercial comprova isso. Mas é uma fração do público que poderia, e deveria, ter acesso a essa obra.</p>
<h2>A solução que encontrei</h2>
<p>Comprei o jogo no PlayStation 5, mas precisei jogá-lo no computador para usar um trainer, que são modificadores que permitem alterar parâmetros do jogo. Configurei para que meus ataques derrotassem qualquer inimigo em um hit e para que meu personagem fosse invulnerável.</p>
<p>Praticamente ignorei o combate por turnos e fui direto para o que importava: o mundo, os personagens, os diálogos, as cutscenes, a história.</p>
<p>O resultado foi uma obra-prima.</p>
<p>Jogando dessa forma, Clair Obscure está entre os melhores jogos de todos os tempos para mim. Uma das melhores histórias já contadas nos videogames. Quando tudo se revela, quando você entende o que realmente está acontecendo, é de cair o queixo. É daquelas obras que te lembram do que jogos são capazes de fazer de forma que nenhuma outra mídia consegue.</p>
<p>Só que para chegar lá, precisei contornar o jogo.</p>
<h2>O problema que fica</h2>
<p>Essa é a ambiguidade com que fico. Não é crítica ao design em si: batalha por turno é uma escolha legítima, com uma audiência enorme e uma tradição respeitável. O problema é sistêmico: jogos excelentes ficam restritos às pessoas que se encaixam exatamente no perfil de quem gosta de todas as suas mecânicas.</p>
<p>Um filme pode ser visto por qualquer pessoa. Um livro também. Um jogo tem uma barreira de entrada que é a mecânica em si, e quando essa mecânica não é para você, você perde a obra.</p>
<p>Clair Obscure deveria ser visto por todo mundo. A história que ele conta merece isso. Mas a maioria das pessoas nunca vai saber o que perdeu.</p>
]]></content>
  </entry>
  
  <entry>
    <title>Você existe para desordenar o universo</title>
    <link href="https://andredarcie.github.io/blog/posts/voce-existe-para-desordenar-o-universo/"/>
    <id>https://andredarcie.github.io/blog/posts/voce-existe-para-desordenar-o-universo/</id>
    <published>2026-03-14T00:00:00Z</published>
    <updated>2026-03-14T00:00:00Z</updated>
    <content type="html"><![CDATA[<blockquote>
<p>&quot;Que eu me organizando posso desorganizar&quot; - Chico Science, <em>Da Lama ao Caos</em></p>
</blockquote>
<p>Esse post é sobre entropia, termodinâmica e vida. Mais especificamente, sobre por que a vida faz sentido dentro das leis da física, e o que isso diz sobre o papel que ocupamos no universo. Não é sobre como a vida surgiu. Finalmente entendi um conceito que eu queria entender faz tempo. E a melhor forma de explicar começa com uma montanha.</p>
<h2>A montanha e a chuva</h2>
<p>Imagina uma montanha com chuva. As gotas caem aleatoriamente por toda a superfície e começam a descer. No início, o caminho é praticamente aleatório. Mas a montanha tem irregularidades: pequenas fissuras, depressões, variações no terreno. E as gotas que passam por essas irregularidades vão um pouco mais fundo do que as outras.</p>
<p>Com o tempo, essas irregularidades começam a concentrar mais água. E mais água passando pelo mesmo lugar significa mais erosão, o que aprofunda ainda mais o buraco, que atrai ainda mais água. É um ciclo que se alimenta.</p>
<p>Com tempo suficiente, esse processo forma riachos. Riachos formam rios. Rios formam cachoeiras. Uma cachoeira é um sistema complexo, estruturado, eficiente. Mas não houve nenhum projeto por trás disso. Nenhuma intenção. Apenas probabilidade, física e tempo.</p>
<p>O ponto chave é que a cachoeira dissipa energia muito mais rápido do que as gotas dispersas faziam. O sistema se complexificou, e os arranjos mais eficientes foram os que persistiram.</p>
<h2>O Sol, a Terra e as primeiras moléculas</h2>
<p>Agora pega essa mesma lógica e aplica à vida.</p>
<p>O Sol joga energia absurda no planeta Terra em forma de fótons. Essa energia cai por toda parte de forma relativamente aleatória. Mas assim como na montanha, existem irregularidades. No caso da Terra primitiva, eram combinações de moléculas que, por acaso, conseguiam absorver e dissipar essa energia um pouco mais rápido do que o ambiente ao redor.</p>
<p>Essas moléculas eram como as primeiras fissuras na montanha.</p>
<p>Vale deixar claro desde já: esse texto não é sobre a origem da vida. Não sei como a vida surgiu, e ninguém sabe com certeza. A origem da vida é uma das questões mais abertas da ciência, e qualquer afirmação definitiva sobre o assunto seria desonesta. O que existe são hipóteses sérias, como a do mundo de RNA, mas hipóteses não são respostas.</p>
<p>O que me interessa aqui é outra coisa: não o como exatamente, mas o porquê termodinâmico. Por que um universo que tende à desordem produziria algo tão ordenado quanto a vida? Essa pergunta tem uma resposta mais sólida, e é sobre ela que o texto fala.</p>
<p>E aí entra a mesma dinâmica da montanha: moléculas que dissipam energia de forma mais eficiente tendem a persistir mais. O ambiente ao redor vai ficando moldado pela presença delas, assim como o terreno vai sendo moldado pela água. Com o tempo, estruturas mais complexas aparecem — reações que sustentam outras reações, metabolismo, formas de copiar informação. Não porque havia um plano. Mas porque os arranjos que funcionam melhor são os que sobrevivem por mais tempo.</p>
<h2>A vida é termodinâmica</h2>
<p>A conclusão que me impressionou é essa: a vida não é uma exceção às leis da física. É uma consequência delas.</p>
<p>O universo caminha inevitavelmente para o aumento da entropia, que é a tendência de tudo se desordenar. O Sol manda energia organizada para a Terra. E toda essa energia precisa ir embora: no longo prazo, 100% do que entra sai: a Terra irradia de volta ao espaço exatamente o que absorve, só que em forma de calor difuso, radiação infravermelha, desordem. Se não fosse assim, o planeta esquentaria para sempre. A Terra não guarda energia. Ela é um sistema de trânsito. E a forma mais eficiente que esse sistema encontrou, ao longo de bilhões de anos, foi criar estruturas cada vez mais complexas que pegam essa energia organizada e a transformam em desordem o mais rápido possível.</p>
<p>A vida é uma cachoeira feita de química.</p>
<p>E a cachoeira é mais eficiente que as gotas dispersas. Por isso persistiu.</p>
<h2>A inteligência como acelerador</h2>
<p>O que me pegou foi a continuação natural dessa ideia: a inteligência humana segue o mesmo padrão.</p>
<p>A gente constrói coisas. Cidades, indústrias, computadores, aviões, servidores. Tudo isso consome energia de forma massiva e a transforma em calor e desordem. A civilização humana, em escala planetária, dissipa volumes de energia que nenhuma outra estrutura biológica chegou perto.</p>
<p>A complexidade da civilização não é algo separado da natureza. É a continuação do mesmo processo que começou com as primeiras fissuras moleculares na Terra primitiva.</p>
<p>A cachoeira ficou mais complexa. Muito mais.</p>
<h2>O lado estranho disso tudo</h2>
<p>Tem algo perturbador e ao mesmo tempo libertador nessa visão.</p>
<p>A gente costuma pensar que existimos por algum propósito maior, por uma razão especial. E de certa forma existe: do ponto de vista do universo, somos uma das soluções mais elegantes que a física encontrou para acelerar a dissipação de energia. Somos bons no que fazemos. Excepcionalmente bons.</p>
<p>Mas o que a gente faz de concreto para o universo é aumentar a desordem mais rápido.</p>
<p>Isso soa niilista na superfície. Mas penso diferente: significa que a complexidade, a consciência, a inteligência, tudo isso não são acidentes improváveis numa história sem sentido. São um resultado consistente com um universo que tende à entropia e que, ao longo do tempo, favorece formas cada vez mais sofisticadas de dissipar energia.</p>
<p>Você não é um acidente. Você é a solução mais recente para um problema muito antigo.</p>
]]></content>
  </entry>
  
  <entry>
    <title>Usar TDD deixou de ser opcional no mundo dos agentes de IA</title>
    <link href="https://andredarcie.github.io/blog/posts/tdd-no-mundo-dos-agentes/"/>
    <id>https://andredarcie.github.io/blog/posts/tdd-no-mundo-dos-agentes/</id>
    <published>2026-03-12T00:00:00Z</published>
    <updated>2026-03-12T00:00:00Z</updated>
    <content type="html"><![CDATA[<blockquote>
<p><strong>Test-Driven Development (TDD)</strong> é uma prática de desenvolvimento em que você escreve os testes <em>antes</em> de escrever o código. O ciclo é simples: escreva um teste que falha, implemente o mínimo de código para ele passar, refatore. Repetido em loop, isso garante que o código faça exatamente o que foi especificado.</p>
</blockquote>
<p>Muita gente usa IA assim: manda a classe pronta e pede para gerar testes.</p>
<p>O problema é que o modelo só está completando um quebra-cabeça de tokens. Ele gera testes que combinam com o código existente, não necessariamente com o comportamento correto.</p>
<p>Para o modelo, ele não está realmente entendendo o sistema. Ele só está tentando prever o próximo token provável. Então o teste acaba sendo apenas uma continuação lógica do código.</p>
<h2>Invertendo o processo</h2>
<p>O que funcionou para mim foi inverter isso usando TDD.</p>
<ol>
<li>O agente lê os <strong>requisitos funcionais</strong>.</li>
<li><strong>O agente gera testes baseados nesses requisitos.</strong></li>
<li>Eu <strong>limpo o contexto</strong> (novo agente, contexto zerado).</li>
<li>Peço para ele <strong>implementar o código que faça os testes passarem</strong>.</li>
</ol>
<p>Nesse ponto o agente só tem um objetivo claro: <strong>fazer os testes passarem</strong>.</p>
<p>Ele tenta, falha, tenta de novo, em loop, até conseguir.</p>
<h2>Por que isso funciona</h2>
<p>Isso funciona porque <strong>testes são determinísticos</strong>. Para o mesmo código, o resultado sempre será o mesmo.</p>
<p>Já <strong>agentes não são determinísticos</strong>. Existe aleatoriedade, existe alucinação, e nós não temos controle total sobre o que o modelo vai gerar.</p>
<p>Então tudo o que pudermos construir para <strong>conter esse comportamento</strong> ajuda.</p>
<p>Testes acabam virando exatamente isso: <strong>uma espécie de gaiola para controlar o comportamento caótico dos agentes.</strong></p>
<h2>Bugs também</h2>
<p>Já usei essa abordagem em projetos críticos onde bugs simplesmente não eram uma opção. O fluxo era: primeiro fazer o agente criar um teste que realmente quebra e reproduz o problema. Só depois pedir para corrigir.</p>
<p>Porque se você apenas pedir para a IA &quot;arrumar o bug&quot;, ela pode simplesmente inventar uma solução e afirmar que resolveu.</p>
<p>Mas teste não mente.</p>
<p>Teste cria um <strong>feedback loop forçado</strong>.</p>
<h2>Uma boa prática que virou obrigação</h2>
<p>No mundo dos agentes de IA, TDD deixou de ser uma boa prática opcional e passou a ser praticamente obrigatório.</p>
<p>Com código gerado por IA, vimos um boom de testes automatizados. Isso fez uma grande diferença: código sem teste perdeu valor, porque agora gerar testes não custa mais nada. Mas podemos ir a um nível acima. Em vez de gerar testes para o código, geramos testes para os requisitos. Isso é TDD, e é o próximo passo.</p>
<hr>
<p>Também postei esse texto no <a href="https://www.tabnews.com.br/andredarcie/usar-tdd-deixou-de-ser-opcional-no-mundo-dos-agentes-de-ia">TabNews</a>.</p>
]]></content>
  </entry>
  
  <entry>
    <title>The Thinking Game e o AlphaFold</title>
    <link href="https://andredarcie.github.io/blog/posts/the-thinking-game-e-o-alphafold/"/>
    <id>https://andredarcie.github.io/blog/posts/the-thinking-game-e-o-alphafold/</id>
    <published>2026-03-08T00:00:00Z</published>
    <updated>2026-03-08T00:00:00Z</updated>
    <content type="html"><![CDATA[<p>Ontem assisti <em>The Thinking Game</em>, um documentário da Google, mais especificamente do time da DeepMind, que acompanho há muitos anos. Os projetos deles sempre foram interessantes, mas esse novo documentário traz algo que vai além de tecnologia impressionante.</p>
<h2>O começo de tudo: força bruta no xadrez</h2>
<p>Para entender o que a DeepMind está fazendo, vale lembrar o contexto. Quando a IBM criou o Deep Blue para jogar xadrez contra Kasparov, a ideia era simples: provar que um computador consegue vencer o maior jogador do mundo. Xadrez era sinônimo de inteligência, então um computador campeão seria, por extensão, uma máquina inteligente.</p>
<p>Funcionou. Foi um marco. A mídia cobriu intensamente, e o mundo ficou impressionado. Mas uma análise mais precisa revela que foi, essencialmente, força bruta computacional: centenas de milhões de posições por segundo, avaliando muitos movimentos à frente para decidir o próximo. O computador não pensava, ele calculava mais rápido do que qualquer humano poderia.</p>
<p>Hoje temos engines como Stockfish que simplesmente destroem os melhores jogadores do mundo. Mas o método é o mesmo.</p>
<h2>Go: quando força bruta não é suficiente</h2>
<p>O Go é diferente. O tabuleiro é maior, as peças são apenas pretas e brancas, e o número de possibilidades de jogo é maior do que o número de átomos no universo observável. Nenhum computador, por mais rápido que seja, consegue simplesmente calcular tudo.</p>
<p>Para vencer no Go, a DeepMind precisou de uma abordagem diferente: redes neurais artificiais, as <em>Deep Neural Networks</em>. Em vez de analisar todas as possibilidades, o modelo é treinado em um enorme volume de partidas e aprende a reconhecer padrões, a generalizar. Ele não precisa ver tudo: aprende a estimar o que provavelmente é melhor e segue por esse caminho.</p>
<p>O resultado foi o AlphaGo, que venceu um dos maiores jogadores de Go do mundo, o sul-coreano Lee Sedol. E isso importou de uma forma que vai além da tecnologia.</p>
<h2>Por que o AlphaGo foi mais do que uma vitória</h2>
<p>O Go faz parte da cultura do Leste Asiático de uma forma profunda. Na China, integra as chamadas &quot;Quatro Artes&quot; do letrado clássico, ao lado de música, caligrafia e pintura. Na Coreia e no Japão, tem peso cultural semelhante. Em todos esses países, dominar o Go sempre foi associado à inteligência e à capacidade humana. Diferente do xadrez, onde a derrota para uma máquina já era esperada depois do Deep Blue, a queda no Go foi visceral. As pessoas ficaram emocionadas. Havia uma dimensão psicológica, filosófica e cultural naquele momento.</p>
<p>O documentário anterior da DeepMind, sobre o AlphaGo, captura isso muito bem. É, na minha opinião, mais emocionante do que <em>The Thinking Game</em>, mas <em>The Thinking Game</em> traz algo muito mais importante.</p>
<p>Há algo maior acontecendo quando a IA começa a questionar o que nos torna especiais. A gente já passou por isso antes: quando a humanidade descobriu que a Terra não era o centro do sistema solar, nem da galáxia, nem do universo, isso abalou profundamente a percepção que tínhamos de nós mesmos. Questionar a exclusividade da inteligência humana é mais um passo nessa direção, uma lição de humildade que ainda estamos aprendendo a processar.</p>
<h2>O AlphaFold e a maior conquista da IA até hoje</h2>
<p><em>The Thinking Game</em> documenta o AlphaFold, que eu considero a maior conquista prática da inteligência artificial até agora.</p>
<p>Durante 50 anos, cientistas do mundo inteiro investiram tempo, dinheiro e estudo tentando resolver o problema do dobramento de proteínas: como uma sequência de aminoácidos se transforma em uma estrutura tridimensional específica? Era um problema científico aberto, um esforço coletivo sem solução à vista.</p>
<p>A humanidade conseguia descobrir algumas proteínas por ano, a muito custo e muito estudo. O AlphaFold não só resolveu o problema, mas foi além: mapeou e disponibilizou 200 milhões de proteínas para toda a comunidade científica. Simplesmente executou e descobriu todos os padrões possíveis na natureza.</p>
<p>Por isso, o trabalho ganhou o Nobel de Química. É merecido.</p>
<h2>A diferença entre interpolar e descobrir</h2>
<p>A pergunta que as pessoas sempre fazem sobre IA é: ela está apenas interpolando os dados de treino, ou é capaz de resolver problemas genuinamente novos?</p>
<p>Não é a mesma coisa que treinar um modelo em um quiz com perguntas e respostas e depois perguntar sobre o mesmo quiz. Quando a IA consegue resolver um problema que ninguém resolveu antes, como o dobramento de proteínas, a conversa muda completamente.</p>
<p>E as portas que o AlphaFold abriu são enormes: desenvolvimento de remédios, soluções para doenças, possíveis respostas para o aquecimento global, até formas de destruir o plástico que acumulamos no planeta. São possibilidades concretas, não abstrações.</p>
<h2>Conclusão: esperança com os pés no chão</h2>
<p><em>The Thinking Game</em> é um documentário importante para entender o momento em que vivemos. Ele é esperançoso, talvez esperançoso demais em alguns momentos, com uma sensação de que algo absurdo e transformador está prestes a acontecer. Essa parte é mais abstrata e sem muitas conclusões sólidas.</p>
<p>A questão da IA geral, se estamos perto ou longe, se vai acontecer em 30 anos ou em mil anos ou nunca, continua sem resposta. É complicado demais para qualquer previsão honesta.</p>
<p>Mas o AlphaFold é real. É útil. É novo. Fez algo que a ciência não conseguia fazer sozinha, e a DeepMind teve a generosidade de liberar tudo para o mundo.</p>
<p>Isso é o que mais importa no documentário.</p>
]]></content>
  </entry>
  
  <entry>
    <title>Realidade virtual e o gostinho do futuro</title>
    <link href="https://andredarcie.github.io/blog/posts/realidade-virtual/"/>
    <id>https://andredarcie.github.io/blog/posts/realidade-virtual/</id>
    <published>2026-03-08T00:00:00Z</published>
    <updated>2026-03-08T00:00:00Z</updated>
    <content type="html"><![CDATA[<p>Uma coisa que sempre me definiu na relação com tecnologia é buscar a fronteira. Quais são as coisas mais interessantes que estão sendo feitas agora? O que está sendo construído que ainda não chegou para todo mundo?</p>
<p>Foi assim com o primeiro computador, querendo descobrir do que ele era capaz. Foi assim com a internet, que abriu um universo inteiro de possibilidades. E foi assim que cheguei na realidade virtual.</p>
<h2>Meta Quest 2 e a apresentação do futuro</h2>
<p>Ter um Meta Quest 2 foi uma das experiências mais marcantes que tive com tecnologia. Não só pelo que o aparelho oferecia, mas pelo que significava mostrar isso para as pessoas.</p>
<p>Criei um roteiro. Recebia amigos em casa, explicava como colocar o óculos, ajustar as lentes, e via o momento em que eles percebiam que estavam dentro de um ambiente tridimensional. Depois mostrava como os controles com sensores de movimento funcionavam para pegar e interagir com objetos naquele universo. Alguns jogos simples para aquecer.</p>
<p>E então vinha o Half-Life Alyx.</p>
<p>Rodando no computador, com hardware mais potente e gráficos muito mais realistas, era o choque final. Cada pessoa reagia de um jeito diferente, mas todas saíam impressionadas. Ver essa reação era parte da experiência.</p>
<h2>O problema do conteúdo</h2>
<p>O Half-Life Alyx é fantástico. Mostra o que é possível quando você investe de verdade em realidade virtual: gráficos fiéis, ambiente rico, imersão total. É uma prova do que a tecnologia é capaz.</p>
<p>Mas é praticamente a única experiência realmente significativa que tive em VR. O restante dos jogos disponíveis parece mais tech demos, demonstrações do que poderia ser possível no futuro, do que produtos acabados.</p>
<p>E o motivo é simples: realidade virtual é um mercado de nicho. Nenhuma grande empresa vai arriscar o orçamento de um jogo AAA para uma base instalada pequena. Hoje, um jogo de grande orçamento já precisa vender milhões de cópias para ser lucrativo. Um jogo de VR precisa fazer isso com uma fração do público. Os dados financeiros da Valve são privados, mas especula-se que a receita de itens cosméticos no Team Fortress 2 ao longo dos anos supere o que o Half-Life Alyx gerou em vendas.</p>
<p>É um ciclo difícil de quebrar.</p>
<h2>A aposta da Meta e o fim do ciclo</h2>
<p>A única razão pela qual tive acesso a tudo isso foi a Meta decidir investir bilhões por ano em realidade virtual, acumulando prejuízo atrás de prejuízo. Foi uma aposta ousada, quase irracional do ponto de vista financeiro, mas que empurrou a tecnologia para frente e tornou os óculos acessíveis.</p>
<p>Tive o Meta Quest 2. Depois o Meta Quest 3.</p>
<p>E agora esse ciclo chegou ao fim. A Meta cancelou estúdios de jogos AAA que estavam em desenvolvimento, reduziu drasticamente os investimentos em VR e mudou o foco. Era de longe a maior investidora individual da área, embora Sony com o PSVR2 e Apple com o Vision Pro também tenham apostado no setor. Vale lembrar que a aposta original da Meta não era só jogos: era transformar o VR numa plataforma social, com reuniões de trabalho e socialização em ambientes virtuais. Esse projeto fracassou de forma bastante pública, e os avatares sem pernas viraram meme. Com a saída da Meta do centro do palco, o ritmo de evolução vai desacelerar bastante.</p>
<p>A festa acabou, pelo menos por enquanto.</p>
<h2>VR nunca foi para substituir o celular</h2>
<p>Nunca acreditei que a realidade virtual fosse substituir o smartphone como dispositivo de uso cotidiano. A desconexão com o ambiente real é grande demais para algo usado o dia inteiro. Se isso se tornasse o padrão, as pessoas estariam essencialmente vivendo numa Matrix.</p>
<p>Sempre vi o VR como algo para jogar videogame: você coloca o óculos num momento do dia, joga, tira e volta para a vida normal. Pontual, intencional, separado.</p>
<p>O que me convence mais como substituto do celular é a realidade aumentada e a realidade mista. Você continua vendo o mundo real, mas com elementos virtuais sobrepostos. Me lembro de estar lavando louça com o Meta Quest 3 e abrir uma tela gigante do YouTube flutuando acima da pia, com as mãos livres, podendo posicionar a tela onde quisesse. Aquilo parecia o futuro de verdade.</p>
<h2>O caminho que faz sentido</h2>
<p>O problema dos headsets atuais é físico: pesam no rosto, cansam a vista, secam os olhos. E tem outro fator que barra muita gente antes mesmo disso: o enjoo de movimento. Uma parcela significativa das pessoas não consegue usar VR por mais de alguns minutos sem sentir náusea. É uma limitação fisiológica real, que restringe o público de formas que nenhuma atualização de software resolve facilmente. A resolução ainda não é suficiente para uso prolongado. A tecnologia está no caminho certo, mas ainda não chegou lá.</p>
<p>E é por isso que a aposta mais viável parece ser os óculos. A Meta está indo nessa direção com os Ray-Ban com câmera integrada, o Meta Ray-Ban Display que projeta informações diretamente no campo de visão, e integração com IA para entender o ambiente ao redor e responder perguntas em tempo real.</p>
<p>Esse é o caminho da massificação. É um produto que as pessoas conseguem usar no dia a dia sem sacrificar conforto. A Apple também tem uma visão diferente com o Vision Pro, focada em produtividade e consumo de mídia, mas ao preço de US$ 3.499, o que mostra que a tecnologia ainda está longe de ser acessível para a maioria. A realidade virtual imersiva vai ter que esperar mais.</p>
<h2>Uma despedida por enquanto</h2>
<p>Fico muito feliz de ter vivido isso. De ter tido o gostinho do futuro, de saber que aquela experiência com o Half-Life Alyx é legítima, que é real o que ela promete. Quando óculos de VR forem baratos, leves e resolverem os problemas de hoje, vai ser impossível não dominar o mercado. Todo mundo vai querer um.</p>
<p>Mas ainda estamos longe disso.</p>
<p>Ao mesmo tempo, tenho uma ambiguidade sobre óculos de uso constante. Uma das coisas mais valiosas da vida é justamente poder largar o celular e viver o mundo real. Desconectar das telas, descansar os olhos, descansar a mente. O celular já roubou muito isso da gente. Um óculos grudado no rosto o dia inteiro parece um passo na direção errada para a saúde e para a qualidade de vida.</p>
<p>É uma tecnologia fantástica. Mas espero que a gente saiba usá-la com mais equilíbrio do que usou o smartphone.</p>
]]></content>
  </entry>
  
  <entry>
    <title>A minha relação com a verdade</title>
    <link href="https://andredarcie.github.io/blog/posts/minha-relacao-com-a-verdade/"/>
    <id>https://andredarcie.github.io/blog/posts/minha-relacao-com-a-verdade/</id>
    <published>2026-03-08T00:00:00Z</published>
    <updated>2026-03-08T00:00:00Z</updated>
    <content type="html"><![CDATA[<p>Verdade, pra mim, é uma coisa complicada. O que eu consigo chamar de verdade é basicamente aquilo que você consegue provar. Não que tudo que não pode ser provado seja necessariamente mentira. Mas na busca por verdades, o caminho passa pela busca de provas.</p>
<h2>Como buscar a verdade</h2>
<p>Se eu afirmo algo e não tenho certeza, vou recorrer à pesquisa. E na internet existem fontes mais e menos confiáveis para isso.</p>
<p>O Google Scholar, por exemplo, permite encontrar e acessar artigos científicos, embora muitos estejam atrás de paywall e exijam acesso institucional ou pagamento. A Wikipédia é a maior enciclopédia do mundo, construída coletivamente e sem fins lucrativos. Ela tem erros, as pessoas erram, mas o esforço coletivo tende a ser bem mais preciso do que o que circula em redes sociais como Instagram, Facebook ou grupos de WhatsApp, onde uma busca simples frequentemente revela que o que você acabou de ler é uma inverdade absurda.</p>
<p>O Archive.org, com sua Wayback Machine, é outro recurso útil: permite ver versões antigas de páginas da internet, o que ajuda a verificar se uma informação foi alterada ou simplesmente deletada.</p>
<p>A Wikipédia também não é uma fonte final. Ela é um agregador: você lê o artigo para entender o assunto e, a partir das referências, vai até a fonte original da informação. Esse caminho até a fonte é o passo que a maioria das pessoas ignora.</p>
<p>Antes da internet, essa pesquisa seria feita numa biblioteca: ir até a categoria do assunto, pegar um livro clássico da área, consultar o índice. Mas uma biblioteca é física. Você pode estar numa cidade que não tem uma biblioteca grande, ou que não tem biblioteca alguma. A internet, bem ou mal, democratizou o acesso à informação de uma forma que a humanidade nunca tinha experimentado antes.</p>
<p>A questão é sempre a mesma, independente do meio: senso crítico. Qualquer informação que você consuma, seja num livro, numa biblioteca ou na internet, pode ser falsa. Fontes mais confiáveis existem, e é importante saber distingui-las.</p>
<p>Vale lembrar também que as redes sociais não são neutras nesse processo. Os algoritmos foram projetados para maximizar engajamento, e o que mais engaja é o que já confirma o que você acredita. O resultado são câmaras de eco: ambientes onde você consome cada vez mais do que já concorda, sem contato real com perspectivas diferentes ou com informações que contradizem suas crenças.</p>
<h2>Como a ciência cria verdades</h2>
<p>Até mesmo artigos científicos precisam ser tratados com cuidado. Um único artigo que afirma algo não é suficiente. Outros pesquisadores, em outros lugares do mundo, precisam tentar reproduzir as mesmas condições e obter os mesmos resultados. Essa é a grande dificuldade e ao mesmo tempo a grande força da ciência: você só valida algo através de evidências, testes e hipóteses que resistem à repetição.</p>
<p>E o mecanismo falha com mais frequência do que se imagina. Existe uma crise de replicação real, especialmente em áreas como psicologia e nutrição, onde uma parcela significativa de estudos publicados não consegue ser reproduzida por outros pesquisadores. A ciência tem o processo certo, mas ele não é imune a erros, pressões de publicação e vieses.</p>
<p>A ciência não é perfeita. Não é completa. Não sabe tudo sobre o universo e não está certa sobre tudo. Mas eu acredito que ela é o mecanismo de pensamento mais eficiente que o ser humano já criou para a busca de verdades.</p>
<p>E há uma forma prática de verificar isso: se eu uso verdades da física, da química, da biologia e da engenharia, consigo construir prédios, pontes, carros, computadores, celulares, espaçonaves. O que prova melhor que aquela base é sólida do que conseguir construir algo que realmente funciona com ela? As pessoas usam celulares e internet o tempo inteiro. Tudo isso se baseia em leis da física. Se essas leis estivessem completamente erradas, como seríamos capazes de construir algo tão absurdamente complexo?</p>
<h2>Evidências além do testemunho</h2>
<p>Se eu afirmo que alguém entrou na minha casa e roubou algo, meu testemunho sozinho não é suficiente. Posso mentir. O que fortalece a afirmação são as evidências: imagens de câmeras da rua, câmeras internas, vestígios materiais que a pessoa deixou. Testemunhos de outras pessoas. Evidências que vão além da minha palavra.</p>
<p>Só o testemunho não basta. Evidências materiais e independentes são o que sustentam uma verdade.</p>
<h2>A verdade no cotidiano não é tão importante quanto parece</h2>
<p>Aqui vem o ponto que eu acho mais interessante: a verdade não é tão importante assim na maior parte da vida cotidiana.</p>
<p>Não estou falando de mentir por má-fé ou por um ato antiético. Estou falando sobre a verdade dos fatos, das afirmações do dia a dia.</p>
<p>O nosso cérebro não é confiável para resgatar memórias. Ele preenche lacunas que não estão lá, distorce, cria memórias inteiras sem que a gente perceba. Quando você está numa mesa de amigos relembrando algo engraçado que aconteceu no passado, a versão que você conta provavelmente não é exatamente como aconteceu. Mas ninguém está buscando precisão. Estão buscando conexão, diversão, pertencimento.</p>
<p>Buscar precisão na verdade em toda conversa social é simplesmente cansativo e desnecessário. E a pessoa que faz isso é o chato da festa. A pessoa mais difícil de aguentar num churrasco, num bate-papo, numa reunião de família.</p>
<p>Vi um estudo que mostrava que as pessoas escolhem suas ideologias políticas muito mais pela identidade de grupo do que pela busca da verdade. Pertencer a um grupo, vestir uma camisa, ter uma identidade coletiva: isso é uma necessidade humana. E essa necessidade frequentemente sobrepõe a busca por fatos. Na política, validar a sua ideologia acaba sendo mais importante do que verificar se o que você está afirmando é real.</p>
<p>Isso se conecta ao viés de confirmação: a tendência de buscar, interpretar e lembrar informações de um jeito que confirme o que já acreditamos. Não é algo que fazemos conscientemente. O cérebro faz isso sozinho, o tempo inteiro. E um detalhe curioso da pesquisa nessa área é que pessoas com maior capacidade cognitiva não são necessariamente mais imunes a esse viés, elas são apenas mais habilidosas em racionalizar a posição que o seu grupo já defende.</p>
<p>Junto a isso, as pessoas confiam muito mais em histórias pessoais do que em dados. &quot;Meu avô fumou a vida toda e viveu 90 anos&quot; convence emocionalmente muito mais do que qualquer estatística de saúde pública. Evidência anedótica é poderosa porque é concreta, humana e fácil de visualizar. Dados são abstratos. E é por isso que falsidades com uma boa história por trás se espalham com tanta facilidade.</p>
<p>Pessoas no espectro autista, por exemplo, tendem a ter uma fixação maior pela verdade, pelos fatos, por regras fixas. E justamente por isso frequentemente têm o convívio social mais difícil.</p>
<p>A conclusão prática é que a verdade é útil para construir pontes, celulares e espaçonaves, mas para a vida social e para o trabalho ela opera de forma diferente. No trabalho, muita coisa vem da intuição, do feeling, do que você acha que provavelmente é o mais certo. Não existe rigor científico no dia a dia profissional. O objetivo é criar coisas que funcionem e sejam úteis.</p>
<h2>LLMs e a verdade numa perspectiva interessante</h2>
<p>Tem algo engraçado na preocupação que as pessoas têm com LLMs, como ChatGPT, Gemini e Claude, e a questão das alucinações: quando o modelo não sabe a resposta, ele inventa com muita fluência e convicção. Essa é uma preocupação legítima e importante.</p>
<p>Mas é irônico, porque durante muito tempo me preocupei com a verdade enquanto via pessoas ao meu redor, principalmente em relação à política, não se preocupando com isso. E agora a preocupação com a verdade surge com força quando o assunto é inteligência artificial.</p>
<p>Na prática: se você tem um tio que acredita em terraplanismo e em teorias da conspiração, esse tio pode ser menos preciso do que o ChatGPT numa ampla variedade de assuntos. O modelo também erra e alucina, e quando não sabe a resposta inventa com bastante fluência.</p>
<p>Uma LLM só precisa mentir menos do que a maioria das pessoas para já ser bastante efetiva. E eu acho que as pessoas mentem muito, não necessariamente por má intenção, mas por simplesmente não se importarem tanto em validar o que estão dizendo.</p>
<p>Essa é a minha relação com a verdade.</p>
]]></content>
  </entry>
  
  <entry>
    <title>Pela primeira vez, consigo criar na velocidade que tenho ideias</title>
    <link href="https://andredarcie.github.io/blog/posts/criar-na-velocidade-das-ideias/"/>
    <id>https://andredarcie.github.io/blog/posts/criar-na-velocidade-das-ideias/</id>
    <published>2026-03-08T00:00:00Z</published>
    <updated>2026-03-08T00:00:00Z</updated>
    <content type="html"><![CDATA[<p>Pela primeira vez na minha vida, estou conseguindo criar coisas na mesma velocidade em que penso. E isso muda fundamentalmente a relação que eu sempre tive com as minhas próprias ideias.</p>
<p>Sempre fui aquela pessoa que vive no mundo dos pensamentos. O tipo que está sentado numa sala de aula, olhando para o professor aparentemente concentrado, e na verdade está pensando um monte de coisas que não têm nada a ver com a aula. Distraído não por falta de interesse, mas por excesso de pensamento. A cabeça sempre cheia, sempre produzindo. O problema era que o mundo real nunca acompanhava esse ritmo.</p>
<h2>O começo: tentar colocar a cabeça no mundo</h2>
<p>Desde criança, a criatividade sempre esteve lá. Nas brincadeiras, nas histórias que eu inventava, nos projetos que eu tentava montar com o que tinha à mão.</p>
<p>Lembro de construir um computador de papelão e tentar fazer ele ter mudanças de tela através de um rolo que eu girava. E quando comprei cola quente, comecei a montar cidades de papelão e isopor. Sempre tentando colocar as ideias da minha cabeça no mundo físico. Mas o mundo físico tem limites. Isopor custa dinheiro. Você corta, pinta, cola, e no final tem uma cidade estática, sem nada de dinâmico.</p>
<p>O computador mudou isso.</p>
<h2>O limite da programação</h2>
<p>Com o computador, eu pude criar universos próprios. Dinâmicos, vivos, interativos. No começo, sem saber programar, eu usava o RPG Maker e ferramentas mais acessíveis, e conseguia de fato criar coisas: jogos, histórias, mecânicas. A cabeça nunca parava de gerar ideias.</p>
<p>Mas sempre havia um teto. Quando a ideia exigia programação de verdade, eu travava. Precisava pedir ajuda para alguém que soubesse, depender de outra pessoa para dar o próximo passo nas minhas próprias criações.</p>
<h2>Aprender a programar e o tempo que sumiu</h2>
<p>Com o tempo, fiz faculdade de ciência da computação e comecei a trabalhar como desenvolvedor web. Aprendi orientação a objetos, aprendi como as coisas funcionam de verdade. E cheguei num ponto em que eu sabia que conseguia fazer qualquer coisa: bastava ter tempo.</p>
<p>Aí o tempo sumiu.</p>
<p>A vida foi se enchendo. Restavam algumas horas à noite, às vezes já cansado demais para criar alguma coisa. O fluxo de ideias continuava o mesmo de sempre, mas o tempo disponível para executá-las foi encolhendo. Havia também a necessidade de lazer, de vida social, de simplesmente descansar.</p>
<p>Cheguei a criar uma planilha com todas as ideias de projetos que eu tinha, tentando avaliar por onde começar. Mas ao olhar para aquela lista, tudo parecia demorado e trabalhoso. Cada item representava meses, talvez anos de trabalho. E isso desanimava. Muitas ideias ficaram exatamente ali, naquela planilha, sem sair do lugar.</p>
<h2>O salto</h2>
<p>Daí vieram os agentes de IA.</p>
<p>As LLMs, o ChatGPT, já tinham ajudado bastante com pesquisa, organização de ideias, estudo. Mas nunca foram tão eficientes na programação em si, que é a ferramenta que eu uso para criar coisas. O que mudou tudo foram os agentes: Claude Code, Codex e similares. Eles aceleraram de forma absurda o processo de construir algo e criar coisas cada vez mais complexas.</p>
<p>E isso é algo inédito. Nunca na minha vida inteira eu tive ideias que puderam ser colocadas em prática e validadas em tempo real. Agora eu tenho uma ideia, começo a construir, vejo funcionar, e isso gera novas ideias, novas possibilidades, que voltam para o ciclo imediatamente.</p>
<h2>A velocidade do pensamento</h2>
<p>O que os agentes de IA me deram foi algo que eu nunca tinha tido: a execução na mesma velocidade do pensamento.</p>
<p>A minha mente sempre funcionou rápido. Ideias aparecem, se ramificam, se conectam. O gargalo nunca foi pensar, foi transformar o pensamento em algo real. Cada ideia que eu tive na vida precisou atravessar um funil longo: aprender o que eu não sabia, escrever o código, depurar, iterar. Semanas, às vezes meses, para validar se algo funcionava. Na prática, a maioria das ideias morria antes de chegar lá.</p>
<p>Agora esse funil quase não existe. Eu tenho uma ideia, começo a construir, vejo funcionar, e isso gera novas ideias que voltam para o ciclo imediatamente. O tempo entre pensar e ter algo concreto na mão caiu para minutos. Todos os dias.</p>
<p>É a primeira vez na minha vida que a velocidade de criar acompanha a velocidade de pensar. E isso muda tudo, porque ideias que antes seriam inviáveis, que eu descartaria antes mesmo de começar, agora simplesmente são possíveis.</p>
<p>É uma experiência única. E a sensação é de que eu mal estou começando.</p>
]]></content>
  </entry>
  
  <entry>
    <title>Skyrim e o meu gosto pessoal para jogos</title>
    <link href="https://andredarcie.github.io/blog/posts/skyrim-e-meu-gosto-pessoal/"/>
    <id>https://andredarcie.github.io/blog/posts/skyrim-e-meu-gosto-pessoal/</id>
    <published>2026-03-04T00:00:00Z</published>
    <updated>2026-03-04T00:00:00Z</updated>
    <content type="html"><![CDATA[<p>O The Elder Scrolls Skyrim foi o primeiro grande jogo em que investi muitas horas. É engraçado, mas demorou anos para eu descobrir o que era de fato o meu gosto pessoal para jogos, e acho que isso é difícil para quem sempre quis manter a mente aberta, experimentando os mais variados tipos de experiências.</p>
<p>Por um lado, você percebe que gosta de coisas que nem imaginava que poderia gostar, justamente por se esforçar em conhecer o novo. Por outro, a variedade é enorme: jogos premiados, os mais vendidos, os mais populares, com muitos critérios para descobrir um jogo e querer acessá-lo. No fim, eu não sabia exatamente o que queria. Acho que amadureci muito nesse sentido quando tive um PlayStation 5, um Nintendo Switch, uma assinatura do Game Pass e um Meta Quest. Em um momento da minha vida, eu tinha todas as plataformas.</p>
<p>Com o Nintendo Switch, fui atrás dos grandes exclusivos da Nintendo, dos clássicos do Nintendinho e do Super Nintendo. Comecei a comparar esses jogos com os do PlayStation 4 e 5, e com os jogos de PC que já jogava há mais tempo. Foi nesse processo que fui percebendo o que o Skyrim significava para mim.</p>
<p>Não sei se o Skyrim moldou o meu gosto pessoal ou se o meu gosto já existia e o Skyrim foi exatamente aquilo que eu precisava encontrar. Criatura e criador. O jogo tem características que parecem intencionais e outras nem tanto, e as não intencionais também funcionam muito bem.</p>
<h2>RPG casual e acessível</h2>
<p>O Skyrim é um RPG de mundo aberto focado em exploração, mas casual e acessível. Ele simplifica sistemas que em outros jogos do gênero são complexos ao ponto de intimidar.</p>
<p>Quando joguei Baldur's Gate 3, um dos RPGs mais premiados dos últimos anos, senti que precisaria parar e estudar os sistemas antes de conseguir jogar de verdade. Havia a sensação de que seria necessário entender as regras de Dungeons &amp; Dragons, não só a mecânica, mas a lore e o mundo inteiro, porque logo de início o jogo te apresenta uma quantidade enorme de criaturas, possibilidades e regras. O resultado é uma sobrecarga.</p>
<p>O Skyrim é o oposto. Os sistemas são simples, e mesmo sem entendê-los completamente, a diferença é quase imperceptível. É essencialmente um jogo de ação em primeira pessoa onde os erros têm um custo baixo. Comecei a jogá-lo sem saber quase nada sobre RPGs e fui bem-sucedido nisso.</p>
<p>As interfaces são diretas. A árvore de habilidades é acessada olhando para o céu estrelado dentro do menu, intuitiva e visualmente agradável. Posso focar em ser furtivo, mago, bárbaro ou arqueiro, destravando habilidades conforme ganho experiência. O inventário é uma lista simples e transparente, que não esconde o jogo ao fundo. Quando mato um inimigo, posso pegar tudo que ele carrega: a espada, a roupa, qualquer coisa.</p>
<h2>Sem classe definida, sem ansiedade</h2>
<p>No Skyrim, não há escolha de classe no início. Não existe aquela obrigação de pesquisar builds, assistir vídeos, ler guias para decidir que tipo de personagem criar e carregar essa decisão por todo o jogo.</p>
<p>Você escolhe uma raça e começa a jogar. A classe emerge naturalmente do que você faz. Eu sempre criei combinações estranhas: um mago com habilidade de cura que lutava como bárbaro empunhando um machado, recorrendo à magia de fogo quando o machado não resolvia, e ao arco e flecha quando queria dar um acerto crítico na cabeça de um inimigo.</p>
<p>Eu simplesmente fazia o que queria, sem barreiras, obedecendo apenas à minha vontade de me divertir naquele mundo aberto e livre.</p>
<p>Essa liberdade reduz enormemente a carga mental. Grandes RPGs como Mass Effect, Fallout e o próprio Baldur's Gate priorizam a escolha e seu impacto: você pode tomar uma decisão e um personagem importante morre, e isso muda a história. Essa é a essência do roleplaying, a liberdade radical de decidir. Mas essa liberdade tem um peso.</p>
<p>No Skyrim, as decisões raramente mudam muita coisa. Isso pode ser visto como uma limitação do gênero, ou simplesmente algo que ficou de fora. Mas para mim é um benefício enorme: toda vez que abro o jogo, não estou ansioso com as consequências das minhas escolhas. Posso jogar cansado, à noite, com a cabeça cheia depois do trabalho, sem medo de cometer um erro irreversível e ter que voltar ao save.</p>
<p>O Baldur's Gate exige que eu esteja mentalmente preparado para jogar. O Skyrim não exige nada além de vontade.</p>
<h2>Um comfort game contemplativo</h2>
<p>O Skyrim se tornou uma experiência completamente contemplativa. Um comfort game, um walking simulator. Tudo o que ele fez, intencional ou não, o tornou mais imersivo. Você caminha por aquele mundo, vê o céu, as estrelas à noite, as florestas, as cavernas, e segue sem muita preocupação com sistemas.</p>
<p>Em vez de planilhas de números, combinações de builds e menus sobre menus, você simplesmente vive naquele mundo. Contempla as vistas, luta com esqueletos em cavernas, segue em frente.</p>
<p>Foi aí que encontrei o meu gosto real para videogames: jogos que me relaxam, que trazem paz, aconchego e contemplação. Que me tiram do caos do mundo real, do estresse do trabalho, das frustrações da vida, e me colocam num lugar confortável.</p>
<p>Skyrim define o meu gosto pessoal para jogos.</p>
]]></content>
  </entry>
  
</feed>
