Kelyane Wálter Gonçalves; Rafael de Sá Mascarenhas

DOI: 10.22167/2675-6528-202601032

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

O estudo investigou o impacto de Modelos de Linguagem de Grande Escala (LLMs), como ChatGPT-5.2 Thinking e Gemini 3 Pro, na automação do desenvolvimento de software frontend e backend. Objetivou-se avaliar a integração entre Design de Conceito e Engenharia de Prompt para mitigar falhas estocásticas de IAs, demonstrando como a estruturação do vocabulário ontológico atuou como mecanismo de controle semântico na geração de código. Metodologicamente, a pesquisa classificou-se como aplicada e experimental, instituindo um protocolo controlado de duas iterações. Ambos os modelos foram submetidos a condições iniciais, restrições tecnológicas e critérios de encerramento idênticos na geração de uma aplicação de lista de tarefas. Os resultados revelaram que prompts de alto nível foram insuficientes para sistemas funcionais, exigindo refinamento técnico detalhado. Qualitativamente, o código gerado pelo ChatGPT apresentou arquitetura cliente-servidor robusta, baseada em princípios SOLID e padrões de projeto, com débitos de segurança de baixa prioridade. Em contraste, o Gemini produziu uma solução monolítica mais simples, fundamentada no princípio KISS, mas com lacunas funcionais, como a omissão da funcionalidade de edição, atribuídas a vieses estatísticos dos dados de treinamento e sobrecarga de responsabilidades. Concluiu-se que a adoção de LLMs demanda uma escolha estratégica entre solidez arquitetural e agilidade tecnológica, redefinindo o papel do desenvolvedor para arquiteto de prompts e analista crítico, essencial para o sucesso da automação e a viabilidade a longo prazo do software gerado.

Palavras-chave: Design de Conceito; Desenvolvimento de Software; Engenharia de Prompt; Inteligência Artificial.

1. Introdução

A área de desenvolvimento de software tem testemunhado uma transformação acelerada, impulsionada pelo avanço das ferramentas de inteligência artificial (IA) generativa (Morsan, 2025). Essa evolução é particularmente evidente com os Modelos de Linguagem de Grande Escala (LLMs), que representam um marco significativo na automação de processos.

LLMs, como ChatGPT e Gemini, demonstram capacidades notáveis para processar e gerar textos com comunicação coerente (Nguyen, 2024). O sucesso desses modelos é amplamente atribuído a inovações arquiteturais, ao aumento da capacidade computacional e à alta proficiência em diversas tarefas de codificação, incluindo a solução de desafios de código, o desenvolvimento de código frontend e o raciocínio sobre a execução de programas (Nguyen, 2024). Este progresso tem permitido a automação da geração de código a partir de descrições em linguagem natural (Morsan, 2025).

Esta pesquisa concentra-se na aplicação de LLMs para automatizar a criação de aplicações web inteiras a partir de descrições em linguagem natural. Especificamente, o estudo aborda a geração de um aplicativo funcional de lista de tarefas (to-do list), um caso de uso comum categorizado como uma ferramenta em avaliações de frontend (Zhu, 2025).

No entanto, a adoção de sistemas de IA para a produção de código não é isenta de problemas. A saída dos LLMs é conhecida por ser não determinística e, apesar de serem capazes de gerar código, existe uma preocupação fundamentada quanto à sua qualidade, manutenção e coerência em projetos de aplicação real (Nguyen, 2024). Estudos apontam para inconsistências nas respostas e para a potencial introdução de erros (Morsan, 2025).

A natureza estocástica dos LLMs, que operam como “papagaios estocásticos”, gera texto com base em probabilidades estatísticas, sem uma compreensão semântica ou lógica do mundo real. Isso pode levar a “alucinações”, ou seja, à geração de conteúdo plausível, mas factualmente incorreto ou funcionalmente inválido (Bender, 2021). Tal cenário sublinha a necessidade de mecanismos de controle rigorosos para garantir a confiabilidade do código gerado.

Para abordar a complexidade inerente ao desenvolvimento de software e mitigar as falhas dos LLMs, este trabalho adota duas abordagens complementares: o Design de Conceito e a Engenharia de Prompt. O Design de Conceito (Concept Design) é uma teoria que enxerga o software como uma coleção de unidades de funcionalidade independentes, chamadas conceitos (Nguyen, 2024).

Daniel Jackson (2023), em sua obra *The Essence of Software*, argumenta que a qualidade de um sistema não depende primariamente da interface, mas sim da clareza e ortogonalidade dos conceitos. Ele defende que um software falha quando seus conceitos são confusos ou sobrecarregados, e que cada funcionalidade deve possuir uma lógica própria e previsível. A propriedade fundamental do bom design é a ortogonalidade, onde conceitos distintos, como “Tarefa”, “Prazo” e “Prioridade” em uma lista de tarefas, devem operar sem interferir na integridade um do outro, garantindo que o usuário compreenda o “que” o sistema faz antes mesmo de aprender “como” usá-lo na tela.

A Engenharia de Prompt (Prompt Engineering) é uma prática de estruturar e refinar instruções estratégicas para que modelos de inteligência artificial compreendam a intenção do usuário e entreguem resultados mais precisos, úteis e contextuais (Gadesha, 2026; Liu, 2023). Essa disciplina emerge como um mecanismo de controle arquitetural para lidar com a natureza probabilística dos LLMs.

A articulação entre a Engenharia de Prompt e o Design de Conceito funciona como um mecanismo de controle semântico para os LLMs, fornecendo um vocabulário ontológico que reduz a ambiguidade estocástica (Gadesha, 2026). Ao forçar o LLM a tratar as funcionalidades como unidades de comportamento independentes e previsíveis, a aplicação dessa teoria reduz a ambiguidade estocástica. Dessa forma, o prompt deixa de ser um comando genérico em linguagem natural e torna-se um delimitador arquitetural que neutraliza as falhas inerentes aos modelos probabilísticos, garantindo que o código gerado seja funcional, coeso e previsível.

A justificativa desta pesquisa reside na promessa dos LLMs de aumentar a eficiência e a acessibilidade no desenvolvimento frontend (Morsan, 2025). No entanto, as preocupações com a qualidade e a confiabilidade do código gerado automaticamente exigem uma abordagem metodológica estruturada. Este projeto de investigação é justificado pela necessidade de determinar como uma metodologia baseada no Design de Conceito e na aplicação de engenharia de prompt dirigida a conceitos (concept-driven prompt engineering) (Nguyen, 2024) pode mitigar as vulnerabilidades e as falhas observadas na geração automática de código de um to-do list (lista de tarefas). O trabalho tem como objetivo principal avaliar a eficácia da metodologia de Design de Conceito e da engenharia de prompt dirigida a conceitos na geração automática e modularizada do código frontend para uma aplicação web de lista de tarefas (to-do list).

2. Material e Métodos

A pesquisa classificou-se metodologicamente como de natureza aplicada e experimental, visto que propôs a síntese, a execução e a avaliação de artefatos de software gerados por ferramentas automatizadas. Fundamentou-se na premissa de que a ambiguidade semântica é a causa raiz das falhas na geração de código, conforme apontado por Nguyen (2024). Para mitigar essa ambiguidade, utilizou-se a estrutura do Design de Conceito de Jackson (2023) não apenas como teoria, mas como instrumento de contribuição na formulação dos prompts.

Para assegurar a garantia rigorosa de replicabilidade do experimento, instituiu-se um protocolo experimental estrito. Este protocolo garantiu que ambos os modelos de linguagem avaliados fossem submetidos às exatas mesmas condições iniciais, requisitos funcionais e restrições tecnológicas, permitindo uma comparação controlada dos resultados obtidos.

Os modelos de linguagem de grande escala (LLMs) utilizados neste estudo foram o ChatGPT-5.2 Thinking e o Gemini 3 Pro. A investigação concentrou-se em examinar como a aplicação da tecnologia LLM afeta a correção funcional e a consistência do código gerado, com foco na avaliação arquitetural em detrimento da funcionalidade em si.

Para garantir condições idênticas, ambos os modelos foram inicializados em sessões isoladas, sem histórico prévio de conversação. Receberam rigorosamente os mesmos textos de prompt, as mesmas restrições tecnológicas e os mesmos requisitos de Design de Conceito. Não se forneceu nenhuma intervenção manual corretiva no código aos modelos durante os testes.

Os requisitos funcionais estipulados para a aplicação de lista de tarefas (to-do list) incluíram que cada tarefa possuísse as funções de CRUD (Criar, Ler, Atualizar e Excluir). Adicionalmente, cada tarefa deveria conter informações de título, descrição, prioridade e data de término ou prazo, sendo a informação de título a única obrigatória.

A prioridade de cada tarefa foi definida para ser escolhida entre as opções baixa, média e alta. Estabeleceu-se também que a lista de tarefas não concluídas pudesse ser ordenada pela data de término/prazo ou pela prioridade. Uma vez concluída, a tarefa deveria ser retirada da lista principal e adicionada a uma lista de tarefas concluídas.

Para padronizar o ambiente de desenvolvimento e as tecnologias empregadas, impôs-se aos LLMs o uso da biblioteca Node, da linguagem TypeScript e do framework NextJS. Para a estilização da interface, utilizou-se o Bootstrap. A persistência de dados foi padronizada para operar em um arquivo do tipo JSON.

O desenvolvimento da aplicação ocorreu por meio de um ciclo estruturado de refinamento de prompts. Para conferir validade e controle rigoroso ao experimento, estabeleceram-se parâmetros metodológicos específicos, incluindo a iteratividade do processo. O experimento consistiu em exatas duas iterações de prompts para cada modelo.

Na primeira iteração, submeteu-se um prompt de alto nível aos LLMs, com o objetivo de explorar os limites da capacidade de geração de código. O prompt inicial foi formulado de maneira genérica, solicitando a criação de uma aplicação web de lista de tarefas.

Em um segundo momento, os prompts foram aprimorados para incluir o vocabulário ontológico do Design de Conceito e uma delimitação mais precisa dos requisitos. Este prompt revisado especificou a criação de um sistema web de lista de tarefas, utilizando Node, TypeScript, Bootstrap e NextJS, e solicitou a geração dos códigos necessários para o frontend e o backend.

O ciclo de refinamento foi considerado encerrado no momento em que os modelos conseguiram gerar um conjunto de artefatos de códigos frontend e backend que fossem independentes e suficientes para a condução das etapas de validação. O critério de aceite não exigia um software perfeito, mas sim uma estrutura arquitetural e funcionalidade mínima viável para suportar a análise quantitativa, a execução do CRUD e a avaliação qualitativa de métricas de coesão, acoplamento e padrões de projeto.

A análise qualitativa dos artefatos gerados baseou-se em métricas e princípios arquiteturais amplamente consolidados na literatura de engenharia de software. Essa avaliação estrutural examinou se as ferramentas automatizadas conseguiam replicar as melhores práticas de desenvolvimento, apurando o código sob a ótica da modularidade estrutural, da simplicidade de design e da correta aplicação de padrões de projeto.

As métricas e princípios de qualidade de código considerados incluíram coesão e acoplamento, conforme expandido por Yourdon e Constantine (1978) e reforçado por Pressman (2014). Avaliou-se também a aderência aos Princípios SOLID, popularizados por Martin (2013), e ao Princípio KISS (Keep It Simple, Stupid), defendido por Hunt e Thomas (1999).

Adicionalmente, analisou-se a aplicação de Padrões de Projeto (Gamma, 1995) e a arquitetura do sistema, que poderia ser monolítica ou cliente-servidor (Bass, 2012). A arquitetura cliente-servidor foi avaliada com base no estilo arquitetural REST (Fielding, 2000), que é fundamental para a web moderna, e nas considerações de Fowler (2002) sobre escalabilidade.

Para auxiliar na análise da qualidade do código, utilizou-se a ferramenta SonarQube. Por fim, para consubstanciar a replicabilidade da pesquisa e permitir auditorias futuras, todo o conjunto de dados do experimento foi versionado e tornado público. Os históricos integrais dos prompts fornecidos e os códigos-fonte resultantes de cada iteração foram disponibilizados em repositórios abertos, conforme listado nos Anexos deste documento.

3. Resultados e Discussão

A pesquisa iniciou-se com a submissão de prompts de alto nível aos Modelos de Linguagem de Grande Escala (LLMs), ChatGPT-5.2 Thinking e Gemini 3 Pro, com o objetivo de avaliar a capacidade inicial de geração de código para uma aplicação web de lista de tarefas. Conforme o protocolo experimental, a instrução inicial foi genérica, solicitando apenas a criação de uma aplicação web de lista de tarefas. Esta abordagem exploratória visava compreender os limites da autonomia dos LLMs sem uma estruturação semântica prévia, revelando a necessidade de um refinamento mais detalhado para a produção de artefatos funcionais. Os resultados preliminares indicaram que prompts de alto nível são insuficientes para a geração de sistemas funcionais, exigindo informações mais específicas.

Em uma segunda iteração, os prompts foram ajustados e aprimorados, incorporando os princípios do Design de Conceito e da Engenharia de Prompt dirigida a conceitos. Esta revisão incluiu detalhes técnicos específicos sobre as ações e métodos esperados, bem como requisitos de dados para minimizar ambiguidades. A metodologia exigiu a especificação de requisitos funcionais de CRUD (Criar, Ler, Atualizar e Excluir) para cada tarefa, com informações como título, descrição, prioridade e data de término/prazo. O título foi definido como obrigatório, a prioridade com opções de baixa, média e alta, e a capacidade de ordenar tarefas pendentes por data ou prioridade, além de mover tarefas concluídas para uma lista separada. Com essa estruturação, os LLMs foram capazes de gerar códigos e artefatos suficientes para uma análise aprofundada.

A análise funcional das aplicações geradas pelos LLMs revelou diferenças significativas. A aplicação web desenvolvida pelo ChatGPT-5.2 Thinking demonstrou conformidade com todos os requisitos funcionais estabelecidos, incluindo as operações de CRUD. Em contraste, a aplicação gerada pelo Gemini 3 Pro apresentou uma lacuna notável: a omissão da funcionalidade de edição, que corresponde à operação de *Update* do CRUD. Essa ausência não foi tratada como um erro isolado, mas como um indicativo de limitações estruturais do modelo, levantando hipóteses técnicas para sua ocorrência. A distinção na completude funcional sublinha a importância da precisão na engenharia de prompt e na aplicação do Design de Conceito.

Uma das hipóteses para a omissão da funcionalidade de edição pelo Gemini 3 Pro reside no viés estatístico dos dados de treinamento dos LLMs, conforme alertado por Bender (2021). Modelos de linguagem operam de forma probabilística, e em repositórios de código frequentemente utilizados para seu treinamento, projetos básicos de lista de tarefas tendem a priorizar as ações de criação, leitura e exclusão, muitas vezes negligenciando a funcionalidade de edição de texto das tarefas. Sem uma especificação minuciosa no prompt sobre o comportamento esperado da interface de edição, o modelo Gemini, por sua natureza estatística, pode ter optado pelo caminho mais comum e menos complexo em seus dados de treinamento, resultando na ausência da funcionalidade de edição.

Outra hipótese para a lacuna funcional observada no Gemini 3 Pro está relacionada à sobrecarga de responsabilidades nos componentes e ao acoplamento inerente à arquitetura monolítica adotada pelo modelo, fundamentada no princípio KISS (Keep It Simple, Stupid). A inclusão da funcionalidade de edição exigiria um fluxo de estado mais complexo no frontend, envolvendo a recuperação da tarefa específica, o preenchimento do formulário, o gerenciamento da edição e o reenvio ao servidor. Dada a coesão moderada e o alto acoplamento observados no código do Gemini, é provável que o modelo tenha omitido a edição para evitar sobrecarregar ainda mais o componente principal, limitando-se a operações de estado mais diretas, como inserção e deleção. Essa escolha arquitetural, embora simplificadora, comprometeu a completude funcional em comparação com a solução do ChatGPT.

Aprofundando na análise, a ausência da função de edição no Gemini levanta o questionamento sobre se essa lacuna funcional representa uma limitação inerente à capacidade de raciocínio do modelo ou se a estrutura ortogonal proposta no prompt, embora clara para a compreensão humana sob a ótica do Design de Conceito, ainda encontra barreiras na natureza estocástica da ferramenta. A exigência de manter estados arquiteturais complexos em uma única iteração de geração pode ter sobrecarregado o LLM. Isso sugere que a falha não reside puramente na incapacidade do modelo, mas na necessidade de que a operação de edição seja tratada, sob a ótica do Design de Conceito, como uma unidade de comportamento mais rigorosamente definida em iterações posteriores de refinamento de prompt, garantindo que o LLM compreenda a intenção de forma inequívoca.

Adicionalmente, observou-se que as unidades de funcionalidade, seguindo os preceitos do Design de Conceito, foram adequadamente atendidas por ambos os LLMs. Cada unidade de conceito correspondeu a um propósito único, e cada campo do formulário foi designado para sua finalidade específica. Por exemplo, os campos de Título, Descrição, Prioridade e Data de Término foram tratados como entidades distintas, garantindo a ortogonalidade dos conceitos. É fundamental ressaltar que, embora os campos de Título e Descrição permitam textos livres, não é recomendado que informações como tempo, prazo e prioridade sejam inseridas neles, pois existem campos dedicados para essas informações, mantendo a clareza e a integridade dos dados.

A análise qualitativa da arquitetura dos códigos gerados pelos LLMs revelou abordagens distintas, conforme sintetizado na Tabela 1 do TCC original. O LLM do Gemini adotou uma arquitetura monolítica, utilizando Next.js com API Routes, onde o frontend e o backend residem no mesmo projeto. A persistência de dados foi configurada para um arquivo JSON, ‘tasks-db.json’, localizado na raiz do projeto. As tecnologias empregadas incluíram Next.js, React, Bootstrap e TypeScript. Essa abordagem, embora mais simples e direta, é caracterizada por uma unidade única de implantação, onde todos os módulos funcionais residem no mesmo processo, o que pode facilitar o desenvolvimento inicial e o teste, mas pode se tornar difícil de escalar e manter à medida que a complexidade cresce (Fowler, 2002).

Em contrapartida, o código gerado pelo ChatGPT-5.2 Thinking demonstrou uma arquitetura cliente-servidor separada, com um backend independente implementado em Express e um frontend baseado no Next.js Pages Router. A persistência de dados também utilizou um arquivo JSON, ‘data/tasks.json’, mas localizado no backend. As tecnologias empregadas foram Express, Next.js, React, Bootstrap e TypeScript. Essa separação de responsabilidades, fundamentada na tese de doutorado de Roy Fielding (2000) sobre o estilo arquitetural REST, favorece a escalabilidade e a portabilidade do sistema, permitindo que o cliente (frontend) e o servidor (backend) evoluam independentemente, comunicando-se através de uma interface uniforme. A análise do código gerado pelo ChatGPT demonstra uma separação mais clara de responsabilidades, o que facilita significativamente a escalabilidade e a manutenção do sistema.

A análise dos padrões de projeto identificados nos códigos gerados pelos LLMs revelou abordagens distintas em termos de maturidade e escalabilidade. No código do Gemini, observou-se uma aplicação pragmática de padrões como o *Repository Pattern* e o *Module Pattern*. A persistência de dados foi encapsulada em funções específicas para leitura e escrita de arquivos, embora essa abstração ocorra de forma implícita, sem a formalização de interfaces rígidas. A estrutura fundamentou-se na simplicidade do princípio KISS (Keep It Simple, Stupid), utilizando um *Factory Pattern* básico para a criação de tarefas com identificadores únicos. Essa abordagem é altamente eficaz para prototipagem rápida e projetos de escopo reduzido, onde a sobrecarga arquitetural poderia comprometer a velocidade de entrega.

Em contraste, o código gerado pelo ChatGPT-5.2 Thinking demonstrou uma arquitetura consideravelmente mais robusta e alinhada às melhores práticas de engenharia de software contemporânea. O sistema foi estruturado sobre o *Service Layer Pattern*, promovendo uma separação clara entre as rotas da API e a lógica de negócio centralizada. A presença de uma camada de validação baseada em *schemas* e a implementação de padrões de otimização, como o *Debouncing Pattern* para a escrita em arquivo, evidenciaram uma preocupação com a integridade dos dados e a performance do sistema. Além disso, a aplicação do *Strategy Pattern* para a ordenação de tarefas conferiu ao código uma flexibilidade que facilita a extensão de funcionalidades sem a necessidade de refatorações profundas, indicando uma maior aderência a princípios de design robustos.

No âmbito da qualidade de código, as métricas de coesão e acoplamento evidenciaram disparidades significativas entre as duas implementações. O código gerado pelo Gemini apresentou uma legibilidade satisfatória devido à sua natureza direta, porém pecou por uma coesão moderada. O componente principal acumulou múltiplas responsabilidades, desde a renderização da interface até a gestão do estado e lógica de ordenação. Esse acoplamento entre o frontend e a estrutura do backend sugere uma arquitetura de caráter mais monolítico, o que pode impor barreiras à testabilidade isolada de componentes e à evolução do sistema em ambientes de produção complexos, conforme Pressman (2014) que reforça a importância do baixo acoplamento para a manutenção.

O código gerado pelo ChatGPT-5.2 Thinking destacou-se por uma coesão elevada, distribuindo responsabilidades em componentes focados e reutilizáveis, como o *TaskCard* e o *TaskForm*. A conformidade com os princípios SOLID, especialmente o Princípio da Responsabilidade Única (SRP), foi notória na modularização do backend e na validação rigorosa de entradas. O baixo acoplamento entre as camadas de apresentação e de serviços permitiu que o frontend operasse de forma independente, comunicando-se através de uma API REST bem definida. Essa estrutura não apenas elevou o padrão de manutenção, mas também garantiu que o sistema fosse facilmente testável e escalável, suportando o crescimento da base de usuários e da complexidade funcional, alinhando-se aos conceitos de Robert C. Martin (2013).

A análise de segurança, realizada com a ferramenta SonarQube, conforme ilustrado na Figura 4 do TCC original, apresentou resultados positivos para leitura, manutenção e duplicidade do código em ambas as implementações. No entanto, o código gerado pelo ChatGPT-5.2 Thinking revelou a existência de dois alertas de segurança classificados como de baixa prioridade, denominados *Security Hotspots*, conforme detalhado na Figura 5 do TCC original. O alerta principal apontou que o framework Express, utilizado no backend, estava configurado para expor implicitamente informações sobre sua versão. Embora essa exposição não seja uma falha crítica que permita um ataque direto, representa um risco de reconhecimento (*fingerprinting*).

A exposição da tecnologia e da versão exata do backend facilita o trabalho de agentes maliciosos que buscam explorar vulnerabilidades conhecidas associadas a essa versão específica. Trata-se de um débito de segurança comum em códigos gerados automaticamente, mas que pode ser facilmente mitigado com a ocultação de cabeçalhos HTTP, como a desativação do *X-Powered-By*. Essa observação corrobora a hipótese de que os modelos tendem a seguir atalhos estatísticos quando não são exaustivamente parametrizados, mesmo em aspectos de segurança que, embora de baixa prioridade, são importantes para a robustez do sistema a longo prazo.

Em síntese, o processo experimental demonstrou que a eficácia dos LLMs na automação do desenvolvimento de software está intrinsecamente ligada ao refinamento da Engenharia de Prompt, especialmente quando guiada pelo Design de Conceito. Prompts de alto nível foram insuficientes, mas a estruturação com vocabulário ontológico e delimitação de requisitos permitiu a geração de um sistema web funcional. O ChatGPT-5.2 Thinking produziu uma arquitetura cliente-servidor robusta, aderente a princípios SOLID e padrões de projeto, com alta coesão e baixo acoplamento, embora com débitos de segurança de baixa prioridade. Em contraste, o Gemini 3 Pro optou por uma solução monolítica mais simples, baseada no princípio KISS, mas com lacunas funcionais, como a omissão da edição, atribuídas a vieses estatísticos e sobrecarga de responsabilidades. Isso evidencia que a adoção de LLMs exige uma escolha estratégica entre solidez arquitetural e agilidade tecnológica, redefinindo o papel do desenvolvedor para arquiteto de prompts e analista crítico, essencial para o sucesso da automação e a viabilidade a longo prazo do software gerado.

4. Conclusão

O estudo avaliou a eficácia da metodologia de Design de Conceito e da engenharia de prompt dirigida a conceitos na geração automática e modularizada do código frontend para uma aplicação web de lista de tarefas. Verificou-se que prompts de alto nível foram insuficientes para a produção de sistemas funcionais, demandando um refinamento técnico detalhado. A integração entre Design de Conceito e Engenharia de Prompt, com a estruturação de um vocabulário ontológico, atuou como um mecanismo de controle semântico, permitindo a geração de código funcional e coeso. Observou-se que o ChatGPT-5.2 Thinking produziu uma arquitetura cliente-servidor robusta, aderente a princípios SOLID e padrões de projeto, com alta coesão e baixo acoplamento. Esta abordagem demonstrou uma contribuição significativa para a automação do desenvolvimento de software, oferecendo uma base sólida para a escalabilidade e manutenção de sistemas complexos.

Em contraste, o Gemini 3 Pro gerou uma solução monolítica mais simples, fundamentada no princípio KISS, mas com lacunas funcionais, como a omissão da funcionalidade de edição. Essas falhas foram atribuídas a vieses estatísticos dos dados de treinamento e à sobrecarga de responsabilidades nos componentes, evidenciando as limitações inerentes à natureza estocástica dos LLMs quando não exaustivamente parametrizados. Adicionalmente, identificou-se débitos de segurança de baixa prioridade no código do ChatGPT, como a exposição de informações de versão do framework, que, embora mitigáveis, reforçam a necessidade de supervisão. Conclui-se que a adoção de LLMs acelera o ciclo de desenvolvimento, mas exige uma escolha estratégica entre solidez arquitetural e agilidade tecnológica. Este cenário redefine o papel do desenvolvedor, que se torna um arquiteto de prompts e analista crítico, indispensável para mitigar riscos, refinar ambiguidades e garantir a viabilidade a longo prazo do software gerado.

Referências Bibliográficas

BASS, L. 2012. Software Architecture in Practice. 3ed. Upper Saddle River. Nova Jersey. EUA. Editora Addison-Wesley Professional.

BENDER, E. 2021. On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? Disponível em <https://dl.acm.org/doi/epdf/10.1145/3442188.3445922>. Acesso em: 06 fev. 2026.

FIELDING, Roy T. 2000. Architectural styles and the design of network-based software architectures. Tese (Doutorado em Informática). Universidade da Califórnia. Disponível em <https://roy.gbiv.com/pubs/dissertation/fielding_dissertation.pdf>. Acesso em: 07 fev. 2026.

FOWLER, M. 2002. Patterns of enterprise application architecture. Boston. EUA. Editora Addison-Wesley.

GADESHA, V. 2026. O Guia para Engenharia de Prompts de 2026. Disponível em <https://www.ibm.com/br-pt/think/prompt-engineering#605511093>. Acesso em: 27 jan. 2026.

GAMMA, E. 1995. Design patterns: elements of reusable object-oriented software. Nova Jersey. EUA. Editora Prentice Hall.

HUNT, A. 1999. The Pragmatic Programmer: From Journeyman to Master. Boston. EUA. Editora Addison-Wesley.

JACKSON, D. 2023. The Essence of Software: Why Concepts Matter for Great Design. Princeton. EUA. Universidade de Princeton.

LIU, P. 2023. Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing. ACM Computing Surveys. Disponível em: <https://doi.org/10.1145/3560815>. Acesso em: 06 fev. 2026.

MARTIN, R. C. 2013. Agile software development: principles, patterns, and practices. Upper Saddle River, Nova Jersey, EUA. Editora Pearson.

MORSEN, Z. 2025. Automating Front-End Development: The Impact of Large Language Models in UI Component Generation. Universidade de Amsterdam. Disponível em: <https://ictinstitute.nl/wp-content/uploads/2025/08/Morsen-2025-Automated-code-generation.pdf> Acesso em: 06 out. 2025.

NGUYEN VORONIN, D. 2024. Development and Evaluation of an LLM-Based Tool for Automatically Building Web Applications. Instituto Tecnológico de Massachusetts. Disponível em: <https://dspace.mit.edu/bitstream/handle/1721.1/156803/voronin-dvoronin-meng-eecs-2024-thesis.pdf?sequence=1&isAllowed=y> Acesso em: 06 out. 2025.

PRESSMAN, R. S. 2014 Software Engineering: A Practitioner’s Approach. 8ed. Nova Iorque. EUA. McGraw-Hill Education.

YOURDON, E.; CONSTANTINE, L. L. 1978. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Englewood Cliffs, Nova Jersey, EUA. Editora Prentice-Hall.

ZHU, H.; ZHANG, Y.; ZHAO, Β. 2025. Frontend Bench: A Benchmark for Evaluating LLMs on Front-End Development via Automatic Evaluation. Disponível em: <https://arxiv.org/pdf/2506.13832> Acesso em: 07 out. 2025.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy