Pensamento computacional: do problema ao passo a passo

Eu sempre fui builder. Mesmo formado em Ciência da Computação, passei boa parte da carreira construindo com ferramentas de pouco ou nenhum código e escrevendo, no máximo, um bocadinho de script — os repositórios antigos do meu GitHub trazem na descrição, com toda a honestidade, “meus scripts preguiçosos”. O motivo é simples: eu sempre achei programar um saco. Caçar bug, decorar framework, lidar com a mania de cada linguagem. Eu queria o produto funcionando, não a cerimônia.

Hoje eu não programo — e interajo com código o dia inteiro. Acho ótimo. A parte chata passou para o agente. A parte que sempre me interessou ficou comigo, e é dela que este capítulo trata.

Dá para ver essa virada nos meus próprios textos. Durante anos, minha maior decisão ao escolher uma ferramenta de pouco código foi do que eu abriria mão para ganhar pronto. Com agentes que programam, essa conta mudou. Hoje eu mexo em código sem abrir o código: questiono, documento as decisões e peço explicações.

O que mudou, e o que não mudou?

Mudou quem lida com a sintaxe. Vírgula no lugar errado, versão de biblioteca, mensagem de erro indecifrável: isso deixou de ser barreira de entrada.

Não mudou que alguém precisa transformar um problema bagunçado em algo que uma máquina consiga executar. Isso tem nome: pensamento computacional. Jeannette Wing, que popularizou o termo, já defendia que é uma habilidade para todo mundo, não só para quem é da computação.

No Brasil isso virou diretriz. As Diretrizes Curriculares Nacionais de Administração pedem que a pessoa formada saiba:

formular problemas e suas soluções, de forma que as soluções possam ser efetivamente realizadas por um agente de processamento de informações, envolvendo as etapas de decomposição dos problemas, identificação de padrões, abstração e elaboração de sequência de passos para a resolução.

“Um agente de processamento de informações.” Quando foi escrita, era uma expressão abstrata. Hoje é literal: é o agente de IA aberto na sua tela, esperando você formular o problema.

É o foco da disciplina que eu dou na FGV EPPG: entender que dá para automatizar com código, de forma determinística, e que a IA precisa ser usada de um jeito que forme o nosso pensamento crítico, não que o substitua.

Como se pensa um problema para uma máquina?

Use o problema da Lia como exemplo — adolescentes que param de ir à escola e uma equipe pequena para ir atrás.

1. Decompor. “Reduzir a evasão” não é um problema que se resolva; é um guarda-chuva. Quebrado em partes: saber quem está faltando; decidir quem procurar primeiro; fazer o contato; registrar o que aconteceu; aprender com o registro. Cada parte tem dono, dado e prazo diferentes.
2. Reconhecer padrões. Faltas às sextas no turno da noite. Ausência que começa depois das férias de julho. Irmãos que somem juntos. Padrão é o que permite sair do caso a caso.
3. Abstrair. Decidir o que importa e o que fica de fora. Para a primeira triagem, importa a sequência de faltas; não importa o nome, o endereço nem a nota de matemática. Abstrair bem é, de quebra, proteger dado (capítulo 5).
4. Escrever o passo a passo. O algoritmo: uma sequência sem ambiguidade, que duas pessoas diferentes — ou uma pessoa e uma máquina — executariam do mesmo jeito.

Você consegue desenhar o seu processo?

Um jeito de testar se você entende um processo é tentar desenhá-lo como fluxo: o que entra, o que se repete, onde se decide, o que sai. Se você não consegue, o problema ainda não está pronto para ser automatizado — por IA ou por qualquer outra coisa.

Duas coisas valem ouro nesse exercício. A primeira: o número cinco. Ele não é técnico, é uma decisão que alguém precisa tomar e justificar — por que cinco faltas e não três? A segunda: o passo que é de gente. Ele está no fluxo por escolha, não por limitação da tecnologia.

Então eu não preciso aprender a programar?

É a pergunta que sempre aparece. Escrever código, provavelmente não. Entender cinco conceitos, sim — porque são eles que permitem ler o que o agente fez e pedir melhor. Eu explico isso em uma hora:

1. Variável: uma caixinha com nome que guarda um valor. faltas = 7.
2. Lista: várias caixinhas em fila. Uma coluna de planilha é uma lista. É o vetor do capítulo 2.
3. Condicional: o SE das planilhas. Se você sabe usar =SE(A1>=5;"contatar";"ok"), você já programa.
4. Loop: “faça isto para cada linha”. É o que a planilha não deixa muito claro e o que dá superpoder: seis linhas ou seis milhões, o código é o mesmo.
5. API: a porta pela qual um programa conversa com outro. Quando o agente “consulta a base oficial” ou “cria um cartão no quadro”, foi por uma API.

Com esses cinco, a maior parte dos scripts que um agente escreve deixa de ser hieróglifo. Os tutoriais que eu uso em aula estão abertos no meu GitHub — e um bom exercício é abrir qualquer um deles em um assistente e pedir: “me explica o que está acontecendo aqui, linha por linha”.

Do que é feito um “sisteminha”?

Quando alguém diz “quero um sisteminha”, está pedindo três coisas sem saber:

Entre as camadas, e entre o seu sistema e o resto do mundo, ficam as APIs.

Saber disso muda a conversa com um agente ou com uma ferramenta que gera aplicativos. “Ficou feio” é pedido de frente. “Está contando errado” é pedido de regra. “Sumiu o que eu cadastrei ontem” é problema de dados. Quem aponta a camada certa resolve em uma mensagem o que levaria dez.

A outra ideia que vem junto é modularizar: cada pedaço faz uma coisa só. A contagem de faltas não deveria saber nada sobre a cor do botão. Pedaços pequenos e independentes são mais fáceis de testar, de trocar — e de entregar a um agente sem medo de ele quebrar o resto. É o básico técnico que eu vejo gente de operações pegar rápido: modularizar, cada passo fazendo uma coisa só, chave que não fica exposta e versionamento.

Como pedir?

No mundo de produto, o documento que descreve o que vai ser construído chama-se PRD (product requirements document). Você não precisa de quarenta páginas. Precisa de sete linhas — e elas são, na prática, o contexto do próximo capítulo:

Problema:      adolescentes param de frequentar e a equipe só descobre semanas depois.
Quem usa:      3 pessoas da equipe de campo e 1 coordenadora. Quase sempre no celular.
O que entra:   a lista semanal de frequência de cada escola (códigos, não nomes).
O que sai:     a lista de quem tem 5 ou mais faltas seguidas, da mais longa para a mais curta.
Regras:        ninguém é rotulado como "de risco"; a lista mostra a situação, não a pessoa.
               A decisão de procurar a família é sempre de alguém da equipe.
O que NÃO faz: não envia mensagem sozinho; não guarda endereço; não cruza com benefício social.
Deu certo se:  a lista bate com 10 casos que a equipe contou à mão.

As linhas mais importantes são as duas últimas. Dizer o que o sistema não faz é onde moram a ética e a segurança. E dizer como você vai conferir é o que separa construir de torcer.

O que isso tem a ver com autonomia?

Eu comecei a escrever sobre construir sem depender de time de desenvolvimento muito antes da IA generativa — anos atrás publiquei um guia de como montar MVPs sem dev. O que as ferramentas de pouco código prometiam, a IA generativa entregou em outra escala: hoje uma pessoa que entende de um problema consegue chegar a um produto funcionando.

Acho isso muito massa. Como escrevi quando ainda apanhava das primeiras ferramentas: velocidade não é o diferencial, a autonomia é. Mais gente pode construir, porque construir passou a ser em linguagem natural.

E acho que tem uma condição. As ferramentas democratizaram o fazer; o pensar continua sendo de cada pessoa. Quem não sabe decompor um problema pede “um app de evasão escolar” e recebe um app genérico e bonito. Quem sabe, pede sete linhas — e recebe o que precisa.

Letramento em IA generativa e pensamento computacional são as duas pernas da mesma autonomia. Uma sem a outra manca.