COMO CRIAR UM SISTEMA EM ALGUNS PASSOS
Hoje venho aqui para dar mais do que um depoimento. Quero também dar uma pequena aula — não sobre programação, porque definitivamente não sou a pessoa mais indicada para isso — mas sobre uma facilidade que encontrei em uma ferramenta chamada Codex, que, curiosamente, tive muita resistência para baixar durante bastante tempo.
Desde o início do ano, meu amigo Edu Bertin já utilizava a ferramenta e, de lá para cá, desenvolveu mais de seis sistemas. Mas eu, que sempre fui curioso e gostei de tecnologia, nunca me senti capaz de programar. Por isso, nem dei muita chance para a plataforma quando meu amigo falava: “Cara, baixa o programa para você ver como é”. Na minha cabeça, desenvolver um sistema significava saber códigos, linguagens de programação e uma infinidade de comandos que eu simplesmente não conhecia.
Eis que, no início do mês de agosto, outro amigo meu, Marcos Paulo, que já utilizava a ferramenta para desenvolver um jogo — olha que louco isso — me pediu para baixar e fazer o registro. Dessa forma, ele ganharia mais alguns tokens, os créditos utilizados na ferramenta, e poderia continuar desenvolvendo seu projeto. Foi então que finalmente baixei o Codex, comecei a conversar com ele e entender um pouco melhor como aquilo funcionava.
Foi aí que tudo floriu.
A ideia do Painel do Blog do Carro
Tudo começou com um problema relativamente simples. Eu precisava organizar as ofertas que seriam publicadas nos grupos ligados ao Blog do Carro e queria diminuir ao máximo o trabalho manual envolvido nisso. A ideia inicial não era criar uma plataforma gigantesca ou desenvolver algo revolucionário. Eu queria um sistema que recebesse uma lista de links de produtos e organizasse automaticamente quando cada oferta deveria ser publicada.
Comecei explicando a ideia para o Codex mais ou menos da mesma maneira que explicaria para um amigo. Eu queria criar listas, colocar vários links dentro delas e depois escolher quantas ofertas deveriam ser enviadas por dia, em quais dias da semana e dentro de qual intervalo de horário. Poderia determinar, por exemplo, que 15 ofertas fossem distribuídas automaticamente entre 8h e 18h.
A partir daí, o sistema deveria fazer o trabalho repetitivo por mim: escolher os produtos, sortear os horários e montar a programação daquele dia. Conforme começamos a desenvolver, porém, novas necessidades foram aparecendo e aquilo que parecia um projeto pequeno começou a ganhar corpo. Criamos uma área de Listas, outra de Definições e uma tela de Auditoria, onde consigo visualizar tudo aquilo que está programado para ser enviado.
Também nasceu um recurso que chamamos de Roll. Se eu olhar para a programação e não quiser determinada oferta naquele momento, posso substituí-la por outra sem precisar desmontar toda a agenda do dia. Depois vieram outras necessidades, como integração com WhatsApp, gerenciamento de usuários, atualização do próprio sistema e a possibilidade de, futuramente, incluir outros módulos de automação.
Foi nesse momento que percebi uma coisa curiosa: aquilo já não era mais apenas “um programinha para mandar links”. Estávamos construindo um sistema de verdade. E boa parte dele nasceu simplesmente porque eu conseguia explicar o que queria, testar o resultado e voltar dizendo: “Isso aqui ficou legal, mas não era exatamente o que eu estava imaginando. Vamos mudar dessa forma”.
COMO O CODEX ORDENA AS PARADAS?
Talvez essa tenha sido a maior surpresa para alguém como eu, que nunca se considerou capaz de programar. Você não precisa necessariamente chegar com o sistema inteiro desenhado, saber quais tecnologias utilizar ou conhecer todos os problemas que vão aparecer no caminho. Eu tinha uma ideia e uma necessidade. O Codex começou a ajudar a transformar aquilo em pequenas etapas que poderíamos executar e testar.
Por trás do nosso painel existe uma estrutura que, antes dessa experiência, provavelmente me faria desistir antes mesmo de começar se alguém tentasse explicar tudo de uma vez. Temos interface, servidor, banco de dados, rotinas automáticas e várias tecnologias trabalhando juntas. Só que eu não precisei aprender tudo isso antes de começar. Fomos descobrindo e implementando cada parte conforme o próprio projeto exigia.
Primeiro precisávamos colocar o painel de pé. Depois vieram as listas, o armazenamento dos produtos, as definições de quantidade e horários, o planejamento diário e a possibilidade de alterar esse planejamento. Quando uma etapa funcionava, partíamos para a próxima. Quando alguma coisa quebrava, voltávamos, tentávamos entender o motivo e fazíamos outra tentativa.
É justamente aqui que acredito estar uma das maiores mudanças proporcionadas pela inteligência artificial para pessoas que têm ideias, mas não são programadoras. Você continua precisando pensar, explicar corretamente o problema, testar aquilo que foi criado e perceber quando alguma coisa não está funcionando como deveria. O Codex não lê sua mente e também não transforma uma explicação ruim em um sistema perfeito.
Mesmo assim, aquela distância gigantesca que existia entre “eu tive uma ideia” e “eu tenho alguma coisa funcionando na minha tela” ficou muito menor. Em vários momentos eu simplesmente descrevi uma tela, um botão ou determinado comportamento que imaginava e, algum tempo depois, estava clicando naquilo dentro do meu próprio sistema. Para quem sempre olhou programação como algo distante demais, isso muda completamente a maneira de enxergar uma ideia.
O QUE SÃO TOKENS (E COMO UTILIZÁ-LOS COM SABEDORIA)
Aqui entra uma parte importante dessa história. Usar inteligência artificial para desenvolver não significa ter uma máquina mágica trabalhando infinitamente para você. Existe um custo computacional em cada conversa e em cada tarefa executada. De maneira bastante simplificada, podemos pensar nos tokens como pequenas unidades utilizadas pela inteligência artificial para processar aquilo que você envia e também aquilo que ela produz.
Quanto maior e mais complexo vai ficando o projeto, mais importante se torna utilizar esses recursos com inteligência. Uma instrução mal explicada pode fazer o Codex seguir por um caminho completamente diferente daquele que você imaginava. Depois será necessário explicar novamente, desfazer alterações, reconstruir alguma coisa e gastar mais tempo e mais créditos para chegar ao mesmo lugar.
Foi justamente trabalhando no painel que comecei a perceber a importância de pensar um pouco antes de simplesmente escrever “faz isso”. Qual é exatamente o objetivo daquela alteração? O que já está funcionando e não pode ser quebrado? Qual resultado eu espero encontrar quando terminar? Quanto mais claro você consegue ser nessas respostas, maiores são as chances de a ferramenta entender aquilo que realmente precisa ser feito.
É quase como trabalhar com outra pessoa. Se você pedir para alguém “melhorar essa tela”, cada pessoa pode interpretar “melhorar” de uma maneira diferente. Agora, se explicar que quer manter toda a estrutura, diminuir determinado botão, acrescentar uma função específica e não mexer no restante, o objetivo fica muito mais claro. Com o Codex acontece algo parecido, e aprender a conversar com a ferramenta acabou se tornando uma parte importante do próprio desenvolvimento.
Mas existe outra lição que aprendi gastando tokens: às vezes você explica direito, a ferramenta entende o problema, a solução parece fazer sentido e, ainda assim, dá tudo errado. (isso frusta muito)
NEM TUDO SÃO FLORES
Se eu encerrasse este artigo dizendo que baixei o Codex, tive uma ideia e alguns dias depois tudo estava funcionando perfeitamente, estaria mentindo. Nosso painel ainda está em desenvolvimento e, neste momento, estamos justamente parados em uma das etapas mais importantes. Precisamos fazer o sistema receber um link de produto do Mercado Livre e identificar corretamente as informações daquele anúncio para que, posteriormente, consiga montar e enviar a oferta.
No começo, parecia uma tarefa relativamente simples. O usuário colocaria o link, o sistema encontraria o produto e buscaria as informações necessárias. Na prática, entramos em uma sequência de tentativas que consumiu bastante tempo e também uma quantidade considerável dos nossos créditos. Tentamos diferentes maneiras de interpretar os links, lidar com redirecionamentos e descobrir como obter os dados dos produtos de forma confiável.
Quando percebemos que tentar depender diretamente da página do anúncio não seria uma boa solução, partimos para a integração oficial com a API do Mercado Livre. Criamos a aplicação, configuramos as informações necessárias, trabalhamos com autenticação, Client ID, Client Secret e finalmente conseguimos fazer o processo de autorização funcionar. Naquele momento, a sensação era de que tínhamos resolvido o maior problema e finalmente poderíamos seguir adiante.
Só que não foi isso que aconteceu. Mesmo depois de todo esse trabalho, os links reais que seriam utilizados no painel continuaram apresentando problemas na identificação dos produtos. Fizemos novas tentativas, alteramos partes do sistema, testamos caminhos diferentes e gastamos mais créditos tentando descobrir onde estava o erro. Em alguns momentos parecia que estávamos a uma pequena correção de resolver tudo; em outros, voltávamos praticamente ao ponto de partida.
E até a publicação deste artigo, continuamos parados exatamente nessa etapa.
Nosso sistema ainda não está pronto. Quando estiver, provavelmente voltarei aqui para contar o restante dessa história, inclusive para explicar como finalmente conseguimos superar o problema que hoje ainda nos mantém presos na leitura dos produtos do Mercado Livre. Por enquanto, tenho um painel funcionando, algumas boas horas de aprendizado, vários tokens gastos e uma visão completamente diferente sobre aquilo que uma pessoa sem experiência em programação consegue construir atualmente.
O que você está esperando para começar a colocar o seu sonho de automatizar alguma coisa em prática?
