VibeCode, I.A para construir projetos?

Esse final de semana busquei novas formas de construir Apps em Flutter, estava/estou a utilizar Bloc, mas queria ampliar meu baralho de soluções e conhecimento, foi quando encontrei o Command Pattern +MVVM + Provider sugerido pela equipe do Flutter, já possuía conhecimento em Provider e MVVM, mas nunca havia construído com o Command.

Foi um desafio interessante, pedi ao agente de IA do copilot para gerar um objeto de estudo para mim, criei um prompt do projeto pratico, e fui estudar.

Command Pattern + MVVM + Provider — a arquitetura recomendada pela equipe do Flutter

A estrutura é similar ao BLoC:

MVVM + Command BLoC

Command encapsula a ação ---- Event dispara a intenção

ViewModel gerencia o estado ---- BLoC gerencia o estado

State representa o estado da View

O ViewModel gerencia o estado da View através de objetos State tipados (sealed classes).

O Command transforma cada ação do usuário em um objeto reutilizável, com seu próprio ciclo de vida (isLoading, result, error), facilitando composição, testes e rastreamento de operações

Um pequeno adendo não tão pequeno:

Quando pedi a I.A para construir o projeto por inteiro, apesar de funcional, o app ainda possuía erros de arquitetura, apesar de eu ter sido expresso quanto ao uso do Clean Architecture.

O Command foi construído, mas nunca usado, tive que pô-lo na mão.

Com isso, o ViewModel ficou muito poluído com variáveis de controle de estado, poluindo o código e dificultando a depuração.

Criei uma classe State para cada View, tendo em vista que ViewModel e View possuem relação um para um.

Depois criei um metodo privado na ViewModel com a seguinte assinatura _emit(State state);

E nas funções que chamam os Commands, conforme a requisição fui alterando o estado.

Sem falar dos erros de construção de widget no Flutter, que ainda terei de rafatorar alguns.

Passar widgets via função no Flutter e quase um crime, e foi isso que o agent fez!

O framework penaliza muito essa construção de tela, pois pode haver rebuilds desnecessários, causando toda a reconstrução da sub-arvore de widgets na função.

O correto: criar widgets com StateLessWidget e StatefulWidget, ao realizar essa construção o Flutter criar o próprio Element desse widget na arvore de elementos e se o widget for instanciado com const ou se suas propriedades não mudarem, o framework é inteligente o suficiente para pular a reconstrução daquela parte inteira da árvore (short-circuiting).

O widget retornado pela função utiliza o BuildContext do pai. Isso significa que, se você tentar acessar um Provider ou Theme que foi injetado dentro dessa própria função, a busca falhará ou retornará dados incorretos, pois o contexto de busca é o ancestral, não o escopo atual.

Com Classes: Cada classe Widget tem seu próprio BuildContext associado ao seu Element. Isso garante o escopo correto para lookups na árvore.

Aqui foram apenas alguns problemas, enfim...

Pedir a I.A para escrever código e ate divertido, você vê a coisa tomando forma, te retorna uma dopamina, mas não se engane, caso não saiba o que ela esta fazendo, você esta ou estará em apuros, sempre construa suas próprias aplicações com seus conhecimentos, peca a I.A para implementar algo de rotina, boiler-plate, estrutura básica, manejar pastas, mostrar ou buscar uma documentação de uma tecnologia, API, stack, resumindo a faca executar o trabalho chato. A logica, a engenharia, VOCE DEVE REALIZAR ISSO!!!

link do projeto abordado: https://github.com/DanielBrown1998/planning_poker