Como o IBM Bob me ajudou a transformar uma ideia em uma aplicação fullstack e por que a parte mais difícil não foi pedir para a IA escrever código.

Vou começar confessando uma coisa.

Quando comecei a estudar desenvolvimento na era dos agentes de IA, uma das primeiras coisas que pensei foi:

"Então agora eu posso pedir para a IA fazer o projeto para mim?"

A resposta curta é: pode.

Mas isso não significa que você deveria.

E foi justamente essa diferença que começou a mudar minha forma de enxergar programação.

De "escreva o código" para "me ajude a construir"

Durante muito tempo, quando eu encontrava alguma coisa que não sabia programar, minha tendência era procurar uma solução pronta.

Com os agentes de IA, isso ficou ainda mais fácil.

Eu poderia simplesmente escrever:

"Crie uma aplicação de tarefas com inteligência artificial."

E esperar.

Só que existe um problema nessa abordagem:

se eu não sei o que estou construindo, como vou saber se a resposta da IA está certa?

Foi aí que comecei a entender uma coisa que apareceu várias vezes durante meus estudos sobre agentes:

A IA pode acelerar a implementação, mas a responsabilidade pela decisão continua sendo humana.

Essa mudança de perspectiva foi uma das partes mais importantes do desafio da DIO.

A ideia virou o TaskFlow

O projeto que desenvolvi foi o TaskFlow, uma aplicação de gerenciamento de tarefas com um assistente de inteligência artificial chamado Flow.

A proposta era criar algo que não fosse somente uma lista de tarefas.

Eu queria experimentar uma pergunta:

E se a própria aplicação pudesse entender o que eu preciso fazer e me ajudar a transformar uma intenção em tarefas?

Foi aí que o Flow entrou.

A aplicação passou a combinar:

• gerenciamento de tarefas;
• prioridades;
• status;
• dashboard;
• autenticação;
• perfil;
• configurações;
• histórico de conversas;
• e um assistente de IA.

No fim, o projeto acabou ficando bem maior do que aquela primeira ideia.

E foi aí que começou a ficar interessante.

O IBM Bob não virou meu "programador particular"

Uma das coisas que mais mudou minha visão foi perceber que utilizar um agente não significa abandonar o processo de desenvolvimento.

O IBM Bob participou de diferentes momentos do projeto.

Ele ajudou no planejamento, na estruturação, na implementação, na integração com IA, na identificação de problemas e na documentação.

Mas eu ainda precisava tomar decisões.

Eu precisava olhar para o resultado e perguntar:

"Isso realmente faz sentido?"

E essa pergunta é mais importante do que parece.

Porque gerar código é relativamente fácil quando temos uma ferramenta capaz de fazer isso rapidamente.

O difícil é avaliar o código.

Quando a IA deixa de ser resposta e começa a ser ferramenta

Uma das partes que mais gostei no TaskFlow foi a integração do Flow com o Gemini.

O frontend não envia diretamente uma chave da API para o navegador.

O fluxo ficou aproximadamente assim:

Usuário
 ↓
TaskFlow
 ↓
Backend
 ↓
Gemini
 ↓
Resposta
 ↓
TaskFlow

Isso me fez perceber uma coisa que muitas vezes fica escondida quando estamos começando:

usar IA em uma aplicação não é simplesmente colocar um chatbot na tela.

Existem questões de arquitetura, segurança, contexto, tratamento de respostas e integração com o restante do sistema.

O Flow também recebeu contexto

Outro ponto interessante foi fazer a IA conhecer o estado das tarefas.

Antes de enviar a mensagem ao modelo, o sistema constrói um contexto com informações como:

• tarefas pendentes;
• tarefas concluídas;
• prioridades;
• descrições;
• mensagem enviada pelo usuário.

Isso significa que o Flow não está respondendo completamente no escuro.

Ele recebe informações sobre o estado atual da aplicação.

E aí comecei a enxergar uma diferença importante entre:

"perguntar alguma coisa para uma IA"

e

"integrar um modelo de IA dentro de um sistema."

São problemas diferentes.

Uma das partes mais legais: a IA pode criar tarefas

Eu queria ir um pouco além de:

"Olá, como posso ajudar?"

Então defini um formato estruturado para determinadas solicitações.

Quando o usuário pede para criar tarefas, o Flow retorna uma estrutura JSON.

Por exemplo, conceitualmente:

{
"tasks": [
  {
    "title": "Estudar TypeScript",
    "description": "Revisar interfaces e tipos",
    "priority": "high"
  }
]
}

A aplicação interpreta essa resposta e transforma o resultado em tarefas reais.

Nesse momento aconteceu uma mudança importante na minha cabeça.

A IA deixou de ser apenas uma "caixa de texto".

Ela passou a participar de uma operação do sistema.

Mas aqui existe uma diferença importante

Depois de estudar mais sobre agentes, percebi que ainda existe espaço para evoluir.

O Flow possui uma integração de IA e consegue executar uma ação estruturada, mas ele ainda não representa todo o conceito de um agente autônomo.

Um sistema mais agentic poderia seguir algo como:

Objetivo
 ↓
Perceber contexto
 ↓
Raciocinar
 ↓
Escolher ferramenta
 ↓
Executar ação
 ↓
Observar resultado
 ↓
Decidir próximo passo

Isso me fez perceber que "ter IA" e "ser agentic" não são exatamente a mesma coisa.

E essa foi uma das coisas que mais gostei nesse desafio:

o projeto não terminou quando o código funcionou.

Ele abriu novas perguntas.

A parte que ninguém mostra: o código nem sempre sai perfeito

Se existe uma coisa que aprendi usando IA para desenvolver, é que receber código rapidamente não significa receber código perfeito.

É necessário revisar.

Testar.

Questionar.

Encontrar inconsistências.

E, algumas vezes, voltar para uma parte que parecia pronta.

Foi justamente aí que comecei a entender melhor o papel do desenvolvedor na era dos agentes.

Não é:

Humano → pede
IA → faz
Humano → aceita

É mais parecido com:

Humano
 ↓
define objetivo
 ↓
agente
 ↓
gera solução
 ↓
humano revisa
 ↓
testa
 ↓
corrige
 ↓
aprende

A IA participa do processo.

Mas a decisão continua sendo minha.

E nem tudo no meu projeto está perfeito

E eu faço questão de dizer isso.

O TaskFlow ainda tem pontos que podem evoluir.

Por exemplo, uma das melhorias que identifiquei depois da revisão foi a necessidade de ampliar a cobertura de testes automatizados.

Também existem pontos de segurança que merecem endurecimento antes de considerar o projeto pronto para um cenário de produção mais sério.

Isso não diminui o projeto.

Na verdade, para mim, demonstra uma coisa que estou começando a entender sobre desenvolvimento:

um projeto não precisa estar perfeito para ser uma boa experiência de aprendizado.

Ele precisa ser analisado com honestidade.

O que eu aprendi de verdade

No começo, eu achava que a maior habilidade para trabalhar com IA seria aprender a escrever prompts perfeitos.

Hoje eu vejo de outra forma.

Prompt é importante.

Mas não é suficiente.

Eu preciso saber:

• o que quero construir;
• qual problema estou tentando resolver;
• quais requisitos existem;
• como dividir o problema;
• como avaliar uma solução;
• como testar;
• como identificar um erro;
• como questionar uma resposta da IA;
• e quando não confiar cegamente no que ela produziu.

Ou seja:

quanto mais autonomia eu dou para a IA, mais importante fica minha capacidade de supervisioná-la.

Do Dev ao Orquestrador

Talvez essa seja a maior lição que levo desse desafio.

Eu costumava enxergar programação principalmente como:

escrever código.

Agora estou começando a enxergar desenvolvimento como:

resolver problemas utilizando código, ferramentas, arquitetura, testes e decisões.

O agente pode ajudar a escrever.

Pode pesquisar.

Pode sugerir.

Pode analisar.

Pode corrigir.

Pode acelerar tarefas.

Mas alguém precisa definir:

"É isso mesmo que devemos construir?"

E depois:

"Essa solução realmente está boa?"

Esse alguém ainda é o desenvolvedor.

O próximo passo

O TaskFlow não termina aqui.

Agora que consegui construir uma primeira versão, consigo enxergar várias possibilidades:

• aumentar a cobertura de testes;
• melhorar a segurança;
• tornar o Flow mais agentic;
• adicionar ferramentas específicas para o agente;
• melhorar a memória e o contexto;
• criar fluxos de aprovação humana;
• melhorar observabilidade;
• evoluir a arquitetura;
• e continuar aprendendo.

Talvez essa seja a parte mais interessante de aprender programação com agentes de IA.

Você termina um projeto com mais respostas.

Mas também termina com perguntas melhores.

Afinal, quem programou o TaskFlow?

Essa pergunta parece simples.

Mas minha resposta mudou durante o projeto.

No início, eu poderia dizer:

"Eu programei."

Depois:

"O IBM Bob me ajudou a programar."

Hoje eu prefiro dizer:

"Eu construí o projeto com o apoio de um agente de IA."

Porque existe uma diferença enorme entre essas três frases.

O agente acelerou o processo.

Gerou ideias.

Ajudou com código.

Ajudou a encontrar caminhos.

Mas eu precisei entender o problema, tomar decisões, revisar resultados e aprender com os erros.

E talvez seja justamente esse o papel do desenvolvedor na era dos agentes:

não competir com a IA para ver quem escreve mais código.

Mas aprender a construir coisas melhores sabendo quando deixar a IA agir e quando parar, pensar e dizer:

"Espera. Quero entender isso primeiro."

💬 E agora quero saber de você

Se você está aprendendo programação e usando IA para desenvolver:

você sente que a IA está ajudando você a aprender de verdade ou existe o risco de começar a depender dela sem entender o código que está sendo produzido?

Quero muito saber como outras pessoas estão vivendo essa experiência. 👇

🔗 Projeto

O código do TaskFlow está disponível no GitHub:

TASKFLOW — IBM Bob

Desenvolvido como parte da jornada de aprendizado na DIO.me, explorando desenvolvimento fullstack e o uso de agentes de IA no processo de desenvolvimento.