Uma IA pode escrever rapidamente a integração que eu pedir. Se eu escolher mal o que integrar, ela também acelera a construção do problema.
No desenvolvimento do Garfim, uso essas ferramentas para implementar, comparar caminhos e revisar código. O tempo economizado abre espaço para perguntas que um aplicativo precisa responder: de onde vêm os números, quanto custa cada uso e o que acontece quando um serviço falha?
São decisões que chegam até quem usa, mesmo quando ficam escondidas atrás de uma tela simples.
Reconhecer arroz é uma etapa. Calcular a porção é outra
Quando a IA identifica um alimento na foto, ainda falta associá-lo a uma quantidade e a uma referência nutricional. Essas etapas podem errar de maneiras diferentes.
O Garfim usa dados da TACO, uma tabela brasileira de composição de alimentos, e referências de medidas caseiras do IBGE. Quando há uma correspondência na base, o cálculo usa aqueles dados. Quando falta uma referência, o resultado precisa deixar claro que é uma estimativa.
Isso exige cuidado com nomes, unidades e preparo. A palavra reconhecida pode parecer correta, enquanto a associação usada no cálculo está errada. Por isso, avalio a ligação entre reconhecimento e base de dados, além da resposta isolada do modelo.
Para quem trabalha com IA, esse é um ponto que merece atenção: uma resposta plausível pode atravessar várias etapas antes de virar um número na tela. É preciso saber de onde ele veio.
O modelo precisa funcionar dentro de uma rotina
Comida brasileira, tempo de resposta, custo e consistência do formato são critérios da escolha. Uma demonstração bem-sucedida responde pouco sobre o comportamento ao longo de muitas refeições.
Se a resposta demora, a pessoa fica esperando com o prato à frente. Se chega em um formato inesperado, o aplicativo precisa lidar com isso. Se cada análise custa mais do que o produto consegue sustentar, o problema aparece na operação.
Organizei a integração do Garfim para permitir comparar e trocar modelos sem reconstruir todo o aplicativo. Assim, a escolha pode acompanhar o que os testes e o uso mostrarem.
O preço também aparece no código
Definir um plano gratuito obriga a decidir como contar o uso. Cobrar uma assinatura exige saber quando liberar acesso, quando restaurá-lo e o que fazer depois de um vencimento.
Até uma tentativa repetida merece atenção. Se a conexão cai e a pessoa toca novamente, o sistema precisa entender se está recebendo uma nova ação ou a repetição da anterior. Caso contrário, uma interface simples pode esconder registros ou cobranças indevidas.
Procuro trazer essas perguntas para o desenvolvimento cedo. Deixá-las para o fim costuma obrigar a rever um caminho que já parecia pronto.
A revisão acompanha a velocidade
O celular reúne a câmera e o registro das refeições; outros serviços cuidam da conta, dos dados e do reconhecimento. Essa divisão permite ajustar uma parte, mas exige conferir o percurso inteiro: uma análise concluída no servidor ainda precisa chegar à tela para ser útil.
Meu trabalho inclui entender como essas partes se comportam juntas. Peço ajuda à IA para explorar soluções e construir testes, mas preciso avaliar se o resultado atende à intenção e aos casos de erro.
A velocidade é valiosa quando encurta o caminho até uma versão que posso examinar. É nesse exame — da origem dos dados ao que a pessoa vê quando algo falha — que boa parte das decisões de produto acontece.