Por que decidi criar o Neurodiário
Criei um aplicativo no GPT Codex para resolver uma necessidade pessoal: organizar tarefas, acompanhar minha rotina e registrar informações que poderiam ajudar nas consultas. Dei a ele o nome de Neurodiário. Como profissional de auditoria interna e auditoria contínua, estou acostumado a transformar dados em informações úteis. Dessa vez, levei essa lógica para um projeto pessoal e explorei, na prática, o desenvolvimento de aplicativos com inteligência artificial.
Meu objetivo inicial era construir um aplicativo desktop para apoiar a organização e o automonitoramento no contexto do TDAH e das altas habilidades/superdotação. Queria acompanhar prazos, recorrências, pensamentos, emoções e sono sem depender apenas da memória. A necessidade ia além de cadastrar uma tarefa: eu queria saber o que estava previsto, o que havia sido realizado e o que precisava de atenção. Também queria reunir registros para conversar com psicólogo e psiquiatra.
Eu já havia abordado a criação de soluções pelas áreas de negócio no artigo Power Apps: crie aplicativos a partir dos dados. Com o Neurodiário, explorei outra possibilidade: descrever requisitos em linguagem natural e contar com o Codex para desenvolver o código. Meu conhecimento de lógica, dados e processos continuou sendo útil, principalmente para explicar o resultado esperado e avaliar se a solução atendia à necessidade.
As funções que implementei no aplicativo
No Neurodiário, implementei o registro de tarefas, o acompanhamento de rotinas e consultas, o controle de medicamentos, lembretes e um cronômetro Pomodoro para organizar períodos de foco. Também incluí registros de pensamentos, sono, emoções e consumo de álcool. Reuni essas funções em um mesmo aplicativo para acompanhar diferentes aspectos do cotidiano e consultar o histórico quando necessário.
Adotei uma aplicação local, com Tauri 2, React, TypeScript, Rust e SQLite. Em termos práticos, construí um programa para o computador, com interface visual e banco de dados local, sem exigir conta, nuvem ou telemetria no MVP. Minha intenção era manter o funcionamento cotidiano independente de um serviço online. Essa decisão também me fez considerar a responsabilidade de cuidar do computador e dos dados armazenados nele.
Incluí relatórios para reunir informações registradas e apoiar a conversa com profissionais de saúde. No acompanhamento das rotinas, passei a ter indicadores de atividades concluídas no horário, realizadas com atraso ou não realizadas. Vejo uma aproximação com o raciocínio que apresentei em Auditoria Contínua: mapeando padrões, desvios e causa raiz: organizar registros ajuda a formular perguntas melhores. No Neurodiário, porém, trato os dados como apoio à reflexão, sem atribuir ao aplicativo a função de diagnosticar ou recomendar tratamentos.
Prompts e aprendizados ao desenvolver com o Codex
Para organizar o desenvolvimento, preparei um roteiro dividido em etapas. Um dos trechos desse roteiro dizia: “Antes de editar, inspecione o repositório e apresente um plano curto. Preserve decisões existentes e não reescreva módulos sem necessidade.” Esse exemplo resume uma orientação que considero essencial: dar contexto, definir o alcance da mudança e preservar o que já foi construído. Reproduzo aqui trechos do roteiro, sem tratá-los como uma transcrição completa das sessões de desenvolvimento.
Outro trecho orientava: “Implemente a menor fatia vertical completa.” Entendo isso como desenvolver uma função pequena, mas utilizável de ponta a ponta. No cadastro de uma tarefa, por exemplo, eu preciso conseguir preencher, salvar e consultar o registro. Para correções, o roteiro também trazia: “Explique a causa raiz mais provável, confirme-a inspecionando os arquivos relevantes e aplique a menor correção segura.” Assim, consigo direcionar a investigação para um problema definido.
Também deixei explícito no roteiro o que esperava ao final de cada etapa: arquivos alterados, decisões, comandos executados, resultados dos testes, limitações e um roteiro de teste manual. Para mim, essa organização tem relação direta com a padronização de scripts que expliquei no artigo ACL Analytics: como criar um script padrão, publicado no LinkedIn. Preciso compreender o que foi feito e ter condições de verificar o resultado.
Meu principal aprendizado foi perceber o quanto a qualidade da especificação influencia o desenvolvimento. Pedir uma tela é diferente de explicar seus campos, regras, validações e comportamento esperado. Também considero essencial preservar versões estáveis e revisar as alterações, assunto que apresentei em Git: controle de versões. Vejo no Codex uma forma de acelerar a implementação, mas continuo responsável por decidir o que construir e avaliar se funciona.
Tokens, limites de 5h e 7d e tempo de criação
Para planejar o uso do Codex, considero as janelas de 5 horas e 7 dias quando aplicáveis ao plano: são períodos de contabilização e renovação da cota, não horas obrigatórias de trabalho nem prazo para concluir o aplicativo. O saldo de uma janela curta não elimina um limite semanal atingido. Consulto o painel para verificar disponibilidade e renovação, conforme a documentação oficial de uso do Codex.
Tokens são unidades de informação processadas pelo modelo. Prompts, arquivos, histórico, resultados de ferramentas e respostas participam desse consumo. A cota não depende somente do tamanho da minha pergunta: modelo, complexidade, raciocínio e contexto também influenciam.
Para aproveitar melhor a cota, minha recomendação é definir uma entrega por etapa, fornecer apenas os arquivos relevantes e pedir respostas proporcionais à tarefa. Mantenho como orientação um AGENTS.md curto, com regras estáveis, e um resumo atualizado das decisões e pendências. Ao retomar o projeto, isso permite reduzir explicações repetidas. Para investigar um erro, prefiro informar o comportamento esperado, o observado e a mensagem correspondente, preservando os detalhes necessários ao diagnóstico.
Sobre o tempo de criação, consigo situar os principais marcos: em 5 de agosto de 2026, organizei o roteiro; em 7 de agosto, a implementação tinha sido um sucesso; em 11 de agosto, descrevi o MVP em fase final. Portanto, entre o roteiro e esse estágio passaram-se cerca de seis dias corridos, com um primeiro resultado positivo em aproximadamente dois dias.
Levo dessa experiência uma aplicação direta para a auditoria interna: posso explorar a IA para construir protótipos, organizar informações e desenvolver ferramentas de apoio à auditoria contínua, mantendo critérios claros e validação dos resultados. É uma extensão da discussão que apresentei em Tecnologias de Análise de Dados na Auditoria Interna, no LinkedIn. O Neurodiário começou com uma necessidade pessoal e se tornou um exercício de especificação, desenvolvimento e análise crítica. Qual problema do seu dia a dia poderia ser o ponto de partida para um aplicativo?