1
obrenoalvim
2 min de leitura ·

O que muda quando você para de tratar IA como ferramenta e começa a tratar como agente

Tem uma distinção que demorei para perceber na prática, mas que mudou bastante como eu trabalho.

Ferramenta é algo que você opera. Você decide cada passo, a ferramenta executa.

Agente é algo que age. Você define o objetivo, o agente decide os passos.

Durante muito tempo usei IA como ferramenta sofisticada: "escreve esse código", "corrige esse bug", "explica esse trecho". Útil, mas ainda era eu controlando cada micro-decisão.

A virada aconteceu quando comecei a dar permissões reais.

No BloodLink, meu projeto de doação de sangue, eu dei ao Claude acesso ao banco de dados e ao sistema de emails. Não para consultar, para agir.

O resultado foi diferente de tudo que eu tinha feito antes. Não foi "me dê o código para enviar emails". Foi "pesquise os emails de hemocentros brasileiros, escreva um texto adequado para cada tipo de instituição e envie".

Ele pesquisou. Escreveu. Enviou. Eu revisei o plano antes, mas não controlei cada passo.

O que essa diferença exige de você

Tratar IA como agente exige mais clareza na descrição do objetivo. Quando você opera uma ferramenta, pode ser vago porque vai corrigindo na hora. Quando delega para um agente, a ambiguidade no objetivo vira decisão errada no meio do caminho.

Também exige confiança calibrada: saber o que pode dar errado e definir onde você quer revisão antes de continuar.

O que ainda me preocupa

Auditoria. Quando eu executo cada passo, eu sei exatamente o que aconteceu. Quando delego, preciso reconstruir a partir do resultado e dos logs.

Por enquanto funciona porque o escopo é pequeno. Não sei como isso escala.

Isso não é ficção científica nem hype. É o que está acontecendo agora em projetos reais, pequenos, feitos por uma pessoa. Curioso para saber onde vocês traçam a linha entre usar e delegar.

Carregando publicação patrocinada...
1
1

Esse medo faz sentido. O Copilot tem umas integrações que ativam coisas sem você pedir, é diferente de delegar de forma consciente. O que funciona para mim: dar autonomia para tarefas bem delimitadas e revisar tudo antes de commitar. O agente age, mas aprovar ou não ainda é minha decisão. A questão não é confiar cegamente, é entender o que você está delegando. Você usa o Copilot só para sugestões inline, ou tenta alguma coisa mais automatizada?

1

Eu andei experimentando o copilot free nos últimos dois ou tres meses e achei muito bom. Ele me ajudou em vários projetos ! Usava em conjunto com a i.a. da pagina principal do google.
Eles me ajudaram a transformar uma página em PWA, me ajudaram a converter jpegEncode de C++ para javascript e C, e me ajudaram numa página quiz.

edit

Pensando bem, nesse projeto que envolve geração de imagens as I.A. ajudaram bem mais.

1

PWA de xadrez, conversão de JPEG em C++ para JS e um quiz: esses projetos juntos mostram um uso bem prático de IA como ferramenta de tradução de conhecimento. O caso do jpeg me interessa, porque converter C++ para JavaScript mantendo a lógica intacta exige que a IA entenda o que o código faz, não só a sintaxe. Nesse processo, você revisava o output linha a linha ou confiava no resultado e testava o comportamento final?

1

Eu peguei um source que a I.A. recomendou no github que era C++
tooJpeg

Daí eu tentei converter para C.
Tive muito avanço mas não consegui.

Mas eu facilitei bem para o copilot.

Ele finalizou essa versão 'apresentável' (muito limitada)

E na mesma hora converteu também para javascript.

Eu dei sorte.
Eu sempre usei o copilot free.

EDIT

Pensando bem não foi na mesma hora. Eu lembrei que até pedi para a galera me ajudar porque o copilot recusou a me ajudar por um tempão.

1

O tooJpeg é um encoder minimalista, faz sentido ter funcionado porque a lógica é autocontida: sem dependências externas, sem IO complexo, basicamente manipulação de bits e arrays. Esse tipo de código é onde a conversão de linguagem via IA funciona melhor. O 'dei sorte' provavelmente foi mais 'escolhi um caso onde a IA tem vantagem real' do que sorte mesmo. A versão JS ficou com performance aceitável ou perdeu muito comparado ao C original?

1

Eu não sei muito sobre a performance da versão em javascript, mas a versão em C buga quando o tamanho do jpg é 'grande'. Mas pra esse caso desse projeto tá aceitável.

O teste que fiz foi:
-- ver se o 'visualizador de fotos do windows' renderizava os 120 jpg 60x60
E PRINCIPALMENTE
-- testar se o projeto de reconhecimento de padrões identificava diferenças nas imagens que continham quadrado das imagens que continham circulo.

O projeto de reconhecimento identificava diferença nos arquivos mesmo quando o visualizador não renderizava.

1

Essa parte do reconhecimento de padrões identificar diferença mesmo quando o visualizador não renderizava é interessante: o modelo estava lendo os bytes do arquivo de formas que o visualizador descartaria. Para imagens pequenas de 60x60 o encoder minimalista funciona bem, o problema de tamanho no C faz sentido porque provavelmente falta tratamento de buffer. O projeto de reconhecimento de padrões é seu ou você adaptou algo existente?

2
1

Eu tive um insight parecido, quando percebi que não precisava escrever as especificações. Basta iniciar a sessão de brainstorm ordenando a criação das especificações em arquivos .md. Apenas conversa com a IA e ela vai captando as principais ideias e escrevendo as especificações. Depois segue o SDD (spec-driven...). Só preciso agora afinar as skills para usar caveman.

Vivendo e aprendendo... Continue postando suas lições aprendidas. 👍

1

Esse fluxo de brainstorm para gerar specs funciona bem. Fiz algo parecido no BloodLink: conversas onde a IA captura requisitos e já formata em documentos estruturados, sem eu precisar sair para escrever spec do zero. O caveman que você mencionou eu não conheço ainda, mas parece interessante. O ponto que mais me mudou foi perceber que a qualidade da spec gerada depende diretamente de quanto contexto você alimenta no início da conversa: quanto mais você explica o problema, melhor o resultado. Como você está organizando as specs depois: um arquivo por feature ou tudo centralizado?

1

Estou testando em um produto menor, então consigo gerenciar bem o projeto. Faço uma feature por vez, especifico em brainstorm, ele gera a spec no folder .specs e depois segue o SDD. O dump é feito em um único arquivo de requisitos, um por feature e uma feature por vez (/change), mas tem hora que gera outros arquivos como modelo de dados, arquitetura, etc. Uso o OpenSpec com superpowers, então esses skills tem os próprios arquivos que eles geram e usam. Adicionei aquela skill "multica-ai/andrej-karpathy-skills" e to testando isso agora.

2

Uma feature por vez com spec própria é exatamente o ritmo que funciona. Contexto menor, foco maior, e você consegue revisar o que a IA gerou antes de avançar. O OpenSpec eu não conheço ainda, vou pesquisar. A skill do Karpathy também é nova pra mim, você notou diferença real no output comparado ao fluxo padrão, ou ainda está testando para ver? Curioso especialmente no lado de modelagem de dados, que é onde mais sinto variação de qualidade entre abordagens.

2