Desenvolver software com Codex, ChatGPT e IA: guia prático para programadores

Se me tivesses perguntado há alguns anos como seria o desenvolvimento de software daqui a dez anos, provavelmente teria falado de novas linguagens de programação, melhores frameworks ou ambientes de desenvolvimento mais potentes. Hoje, a minha resposta seria completamente diferente. A maior mudança não ocorre nas ferramentas, mas na forma como nós, enquanto programadores, pensamos e trabalhamos.

Enquanto escrevo estas linhas, estou eu próprio a trabalhar num novo sistema de software. Há já algumas semanas que utilizo intensivamente ferramentas modernas de IA, como o Codex e outros modelos linguísticos. No início, senti curiosidade; agora, estou sobretudo impressionado. Não porque a IA de repente faça tudo sozinha, mas porque assume determinadas tarefas de forma surpreendentemente eficaz, possibilitando assim novas formas de trabalhar.

Muitas discussões sobre inteligência artificial giram em torno da questão de saber se, um dia, os programadores se tornarão desnecessários. Com base na minha experiência até agora, considero essa questão pouco útil. Muito mais interessante é a constatação de que o papel do programador está a mudar. O verdadeiro desafio consiste, cada vez menos, em escrever linhas de código isoladas. Em vez disso, torna-se mais importante analisar problemas, compreender sistemas, documentar interligações e disponibilizar as informações corretas à IA.

---

---

O programador como arquiteto

No desenvolvimento de software tradicional, os programadores costumavam dedicar grande parte do seu tempo de trabalho à implementação concreta. Programavam-se funcionalidades, criavam-se bases de dados e corrigiam-se erros. Estas tarefas continuam a existir hoje em dia. No entanto, os sistemas de IA já são capazes de apoiar ou assumir parcialmente muitas dessas tarefas.

Isso faz com que o foco mude. Quem quiser desenvolver com sucesso com IA tem, acima de tudo, de saber o que realmente pretende construir. À primeira vista, isso parece óbvio, mas não é.

Em muitos projetos, grande parte dos problemas não decorre de uma programação deficiente, mas sim de requisitos pouco claros. Se o objetivo não for bem definido, nem mesmo a melhor IA será capaz de ajudar. Na verdade, essas falhas tornam-se muitas vezes ainda mais evidentes com a IA, porque os sistemas funcionam de forma muito rigorosa com base nas informações que recebem.

O programador moderno está, por isso, a tornar-se cada vez mais um arquiteto. Ele concebe a estrutura de um sistema, define processos, descreve interligações e assegura que todos os intervenientes – sejam eles pessoas ou sistemas de IA – tenham a mesma visão do projeto. Quanto maior for um projeto, mais importante se torna esta capacidade.

De programador a gestor de projetos

Uma observação interessante que retirei dos meus próprios projetos é que a comunicação assume hoje em dia uma importância muito maior do que no passado. Quem trabalha com IA passa frequentemente mais tempo com descrições, documentação e conceitos do que com a programação propriamente dita.

Isso não significa que os conhecimentos técnicos deixem de ser importantes. Pelo contrário. Quem não compreender os fundamentos das bases de dados, da arquitetura de software ou dos processos empresariais não conseguirá obter bons resultados, mesmo com a IA. No entanto, o foco está a passar da mera implementação para o controlo.

Pode-se dizer que o programador está cada vez mais a tornar-se o gestor de projeto da sua própria equipa virtual de desenvolvimento. Esta equipa já não é composta exclusivamente por colegas humanos, mas sim por vários sistemas de IA capazes de assumir diferentes tarefas. Uma IA ajuda na arquitetura, outra cria documentação, outra analisa erros e outra ainda desenvolve interfaces de utilizador.

No entanto, a responsabilidade continua a recair sobre o ser humano. A IA apresenta sugestões. Contudo, não toma decisões empresariais, não conhece os objetivos da empresa e também não assume qualquer responsabilidade pelas consequências do seu trabalho.

Por que razão a experiência se torna cada vez mais importante

Algumas pessoas temem que a IA torne os conhecimentos especializados desnecessários. Pela minha experiência, acontece antes o contrário. Quanto maiores forem as possibilidades das ferramentas, mais importante se torna a experiência. Um programador experiente percebe mais rapidamente se uma solução faz sentido. Ele vê relações que uma IA pode não ter tido em conta. Conhece as fontes típicas de erro e consegue questionar os resultados de forma crítica.

É precisamente por isso que os projetos de IA funcionam frequentemente muito bem quando o conhecimento especializado e a inteligência artificial se unem. Os melhores resultados raramente surgem da confiança cega na tecnologia. Surgem quando uma pessoa experiente define o rumo e a IA apoia na implementação.

De certa forma, isso faz-me lembrar a introdução de máquinas modernas em muitos ofícios manuais. As ferramentas tornaram-se mais eficientes, mas o artesão experiente continuou a ser indispensável. Ele apenas teve de aprender a utilizar as novas ferramentas de forma adequada.

Uma nova forma de pensar

Quem hoje desenvolve software com IA não deve, por isso, pensar primeiro no código que a IA deve escrever. A questão mais importante é: como posso descrever o meu projeto de forma a que a IA o compreenda da forma mais completa possível?

É precisamente aqui que começa o verdadeiro trabalho. Não é apenas o prompt que determina o sucesso ou o fracasso. O que é decisivo é o conhecimento que está por trás do prompt. Quem conhece os seus processos, compreende as suas estruturas de dados e consegue formular claramente os seus objetivos, proporciona à IA a base para bons resultados.

Isto implica uma mudança radical no desenvolvimento de software. No futuro, o valor de um programador será cada vez menos medido pela rapidez com que consegue escrever código. A capacidade de analisar sistemas complexos, estruturar conhecimentos e comunicar de forma compreensível assumirá uma importância muito maior.

A boa notícia é esta: estas competências sempre foram valiosas. A IA apenas as torna mais visíveis. E é precisamente por isso que o desenvolvimento de software bem-sucedido com IA não começa com a programação, mas sim com a compreensão.

Primeiro compreender, depois programar

Quem trabalha pela primeira vez com uma IA potente costuma sentir um pequeno surto de entusiasmo. De repente, em poucos minutos, é possível criar coisas que antes levavam horas ou até dias. Uma estrutura de base de dados é rapidamente concebida, uma interface de utilizador surge com um simples clique e até as funções de programação mais complexas aparecem frequentemente no ecrã com uma rapidez surpreendente.

É precisamente aqui que se esconde uma das maiores armadilhas do desenvolvimento de software moderno. A rapidez das ferramentas leva-nos a começar a implementação demasiado cedo. Muitos programadores, empresários e gestores de projeto lançam-se diretamente na programação, apesar de ainda não terem refletido completamente sobre o problema em si. A IA produz então resultados impressionantes, mas acaba por funcionar com base em fundamentos pouco sólidos.

O problema aqui não é a IA. O problema é a descrição incompleta do projeto. Quando uma IA recebe informações erradas ou incompletas, ela tenta, mesmo assim, chegar a uma solução. Muitas vezes, o resultado parece plausível à primeira vista. Só mais tarde se percebe que faltam ligações importantes ou que os pressupostos básicos estavam errados.

Na minha opinião, esta é uma das razões mais comuns pelas quais os projetos perdem tempo desnecessariamente.

A tentação do arranque rápido

Muitos programadores conhecem essa sensação. Temos uma ideia para uma nova aplicação, abrimos o chat de IA e começamos imediatamente com o primeiro prompt.

• „Cria-me um sistema de CRM.“
• „Programa um sistema de gestão de armazéns.“
• „Desenvolve um sistema de gestão de projetos com registo de horas.“

Essas instruções são compreensíveis. Afinal, todos querem ver resultados o mais rapidamente possível. No entanto, é precisamente essa abordagem que muitas vezes leva a que, mais tarde, seja necessário rever grande parte do sistema.

A IA não pode saber quais são as particularidades da tua empresa. Não conhece os teus clientes. Não conhece os teus processos. Não sabe quais as decisões tomadas no passado nem quais as condições que devem ser tidas em conta.

Um programador experiente faria normalmente muitas perguntas a um cliente antes de dar início à implementação propriamente dita. Exatamente a mesma abordagem faz sentido também em projetos de IA.

Em vez de começar imediatamente a programar, é importante esclarecer primeiro algumas questões.

O que é que se pretende criar, afinal?

Esta pergunta pode parecer banal, mas, surpreendentemente, muitas vezes não recebe uma resposta adequada. Por trás de quase todos os projetos de software existem objetivos diferentes. Por vezes, o objetivo é acelerar um fluxo de trabalho. Noutros casos, trata-se de obter melhores análises, reduzir as taxas de erro ou aumentar o nível de automatização.

A IA só consegue tomar decisões sensatas se conhecer esses objetivos. Tomemos como exemplo a gestão de clientes. À primeira vista, parece relativamente simples. No entanto, já após alguns minutos surgem inúmeras questões.

Trata-se apenas de uma gestão de endereços ou de um sistema completo de CRM? Existem pessoas de contacto? São geridas propostas e faturas? O software deve ser multilingue? Existem colaboradores no serviço externo? É necessário ter em conta requisitos de proteção de dados?

Quanto mais precisas forem as respostas a estas perguntas, melhor a IA compreenderá o verdadeiro objetivo do sistema. Por isso, o objetivo deve ser sempre não só descrever o software, mas também o contexto empresarial subjacente.

Os processos são mais importantes do que as funções

Outro erro comum consiste em pensar exclusivamente em termos de funcionalidades. Muitas descrições de projetos incluem expressões como:

• „Diz-se que vai haver um formulário para os clientes.“
• „Deve haver uma função de pesquisa.“
• „Deve ser capaz de criar ficheiros PDF.“

Embora se trate de informações importantes, estas limitam-se a descrever ferramentas. O que é realmente interessante são os processos que estão por trás delas.

• Por que é necessária uma ficha de cliente?
• Quais são os passos seguintes?
• Quem utiliza os dados?
• Que informações serão analisadas posteriormente?

Os sistemas modernos de IA compreendem os processos de forma surpreendentemente eficaz, desde que estes sejam descritos de forma adequada. Por isso, muitas vezes vale a pena documentar fluxos de trabalho completos. O foco não deve estar na pergunta „Que máscara preciso?“, mas sim na pergunta:

„Como é que o utilizador irá trabalhar com o sistema mais tarde?“

Quanto mais detalhadamente este processo for descrito, melhor a IA poderá apresentar sugestões adequadas.

A importância dos dados

Para além dos processos, os dados constituem a base de qualquer software. Muitos programadores subestimam a importância de uma descrição detalhada das estruturas de dados para o sucesso de um projeto de IA.

Se uma IA souber apenas que existem clientes, isso não é de grande utilidade. A informação torna-se significativamente mais valiosa quando se descreve também quais os campos existentes, quais as relações previstas e como os dados serão utilizados posteriormente.

Nos meus projetos, tem-se revelado eficaz apresentar exemplos reais o mais cedo possível. Os conjuntos de dados de exemplo são, muitas vezes, mais elocuentes do que longas descrições teóricas.

Um registo concreto de dados de um cliente, com nome, morada, pessoas de contacto e histórico de comunicações, proporciona frequentemente à IA uma compreensão maior do que vários parágrafos de explicações abstratas. O mesmo se aplica aos dados de base de artigos, projetos, faturas ou qualquer outra informação.

Quanto mais próxima a descrição estiver da realidade futura, melhores serão os resultados.

A fase de análise poupa tempo

Muitas pessoas consideram a análise e a documentação um trabalho preparatório incómodo. Afinal, o que se pretende é ver resultados produtivos o mais rapidamente possível. Paradoxalmente, é precisamente essa impaciência que muitas vezes leva a prazos de desenvolvimento mais longos.

Cada hora investida numa análise rigorosa no início poupa, muitas vezes, várias horas de trabalho de correção mais tarde. Este princípio já se aplicava muito antes da era da inteligência artificial e tem hoje uma importância ainda maior.

Uma IA funciona com extrema rapidez. No entanto, isso também significa que pode reproduzir erros muito rapidamente. Quem desenvolve um sistema cuja descrição não é clara pode acabar por obter, em poucos minutos, centenas de linhas de código para a solução errada.

Por outro lado, quem definir primeiro os requisitos com precisão cria uma base sólida para todas as etapas seguintes.

A compreensão como base para tudo o que se segue

A conclusão mais importante é, portanto, a seguinte: um bom software não surge apenas de bons prompts. Surge de uma compreensão profunda do problema.

Quanto melhor conheceres os objetivos, os processos, os dados e os contextos de um projeto, mais eficaz será a tua colaboração com a IA. Em última análise, a qualidade dos resultados depende menos da inteligência da ferramenta e mais da qualidade das informações que forneceres.

Por isso, o desenvolvimento de software com base em IA bem-sucedido não começa com a primeira linha de código. Começa com a tentativa de compreender o problema de forma tão profunda que outra pessoa – ou mesmo uma inteligência artificial – consiga compreendê-lo e resolvê-lo.

A introdução perfeita a um projeto de IA

Quando um novo colaborador entra numa empresa, normalmente não se limita a colocá-lo num posto de trabalho e dizer-lhe: „Começa a trabalhar.“ Em vez disso, recebe uma formação inicial. Ele fica a conhecer os objetivos da empresa, recebe documentos importantes, compreende os processos e conversa com as pessoas que já têm experiência.

A mesma lógica aplica-se também à colaboração com uma inteligência artificial. No entanto, muitos programadores continuam a tratar a sua IA como se fosse um motor de busca. Fazem perguntas isoladas, dão instruções curtas e depois ficam surpreendidos com resultados incompletos ou inadequados. No entanto, a prática demonstra repetidamente que a qualidade das respostas depende em grande medida da forma como a IA foi implementada num projeto. Uma implementação bem preparada pode fazer a diferença entre resultados medíocres e resultados excecionalmente bons.

Com base na minha própria experiência, aprendi que as primeiras informações que uma IA recebe sobre um projeto têm, muitas vezes, um impacto surpreendentemente grande em todo o seu desenrolar. Quanto melhor for essa base, mais produtiva será a colaboração.

Explicar o projeto de forma compreensível

O primeiro passo consiste em descrever o projeto na sua totalidade. Nesse contexto, muitos programadores cometem o erro de se debruçarem imediatamente sobre os detalhes técnicos. Falam de bases de dados, linguagens de programação ou interfaces antes mesmo de estar claro qual o problema a resolver. Para a IA, porém, o que importa inicialmente é o contexto funcional.

Imagina que pretendes desenvolver um sistema ERP. Em vez de começares diretamente com tabelas e nomes de campos, deves primeiro descrever a quem se destina o software, quais as tarefas que este deve realizar e quais os objetivos a atingir. Uma boa introdução ao projeto responde a perguntas fundamentais:

• Quem irá utilizar o sistema no futuro?
• Que processos devem ser apoiados?
• Que problemas se pretende resolver?
• Que particularidades existem?

Só quando estas relações estiverem claras é que faz sentido entrar nos pormenores técnicos. Podemos comparar isto à construção de uma casa. Antes de se falar de tomadas elétricas ou tubagens de água, deve ficar claro se se pretende construir uma moradia unifamiliar, um edifício de escritórios ou um armazém.

O quadro técnico

Depois de explicados os fundamentos técnicos, passa-se ao ambiente técnico. Trata-se aqui de definir para a IA as condições gerais dentro das quais deverá funcionar. Isso inclui, por exemplo, as linguagens de programação utilizadas, os sistemas de bases de dados, os frameworks ou as plataformas de destino.

Este passo é mais importante do que muitos possam inicialmente supor. Uma solução que faz sentido para uma aplicação web não tem necessariamente de ser adequada para uma aplicação de secretária. Da mesma forma, as capacidades dos diferentes sistemas de bases de dados podem diferir, por vezes, de forma significativa.

Quanto mais concretas forem as condições gerais descritas, mais eficaz será o trabalho da IA. Para tal, não se deve documentar apenas as decisões técnicas atuais, mas também as diretrizes existentes. Talvez já existam sistemas antigos, interfaces existentes ou determinadas normas empresariais. Essas informações também ajudam a IA a desenvolver propostas realistas.

O modelo de dados como base

É, pelo menos, nesta altura que se torna claro por que razão uma boa preparação é tão importante. Em praticamente todos os projetos de software de maior dimensão, os dados desempenham um papel fundamental. Clientes, artigos, projetos, faturas, documentos ou contas de utilizador constituem a base da futura aplicação.

Por isso, vale a pena fornecer à IA uma visão geral do modelo de dados o mais cedo possível. Nesta fase, não se trata de uma documentação técnica perfeita. O importante é, antes de mais, que a IA compreenda as relações fundamentais.

• Que tabelas existem?
• Que objetos estão relacionados entre si?
• Que informações são guardadas?
• Que dados são particularmente importantes?

Quanto mais clara for a descrição desta estrutura, mais fácil será para a IA classificar corretamente os requisitos posteriores. Em muitos projetos, verifica-se que a qualidade das propostas de programação posteriores está diretamente relacionada com a compreensão do modelo de dados. Quem negligencia esta área depara-se frequentemente com mal-entendidos e correções desnecessárias.

Por que razão os dados de exemplo são tão valiosos

Uma das formas mais eficazes de fazer com que uma IA compreenda um sistema consiste em fornecer exemplos reais. As pessoas aprendem frequentemente com exemplos. Os sistemas de IA funcionam de forma semelhante em muitas situações.

Uma descrição teórica de uma base de clientes pode ser útil. No entanto, um conjunto de dados real fornece frequentemente muito mais informações. De repente, a IA reconhece conteúdos típicos, convenções de nomenclatura, formatos de dados e relações. Compreende melhor quais as informações que são realmente relevantes e como estas serão utilizadas posteriormente. O mesmo se aplica aos dados de base de artigos, faturas, projetos ou quaisquer outros objetos dentro de um sistema.

É claro que é necessário ter em conta a proteção de dados e a confidencialidade. Em muitos casos, basta utilizar dados de exemplo anonimizados. O que importa não é a autenticidade das pessoas ou das empresas, mas sim a estrutura da informação.

Aprender a linguagem da IA

Um efeito secundário interessante do trabalho com IA é que os programadores aprendem a descrever os seus próprios sistemas de forma mais clara. Muitas relações que parecem óbvias na nossa mente têm, de repente, de ser formuladas. Isso torna visíveis ambiguidades que antes mal se notavam.

Este processo assemelha-se à elaboração de documentação técnica. Assim que se tenta explicar algo com precisão, é frequente identificar aspetos que ainda não foram totalmente pensados.

É precisamente por isso que a apresentação do projeto não é útil apenas para a IA, mas também, muitas vezes, para o próprio programador. Quem consegue explicar o seu projeto de forma compreensível para uma IA, na maioria das vezes, compreende-o muito melhor.

Um investimento que compensa em muitos aspetos

Alguns programadores consideram, à primeira vista, que uma introdução detalhada ao projeto representa um esforço adicional. Na verdade, porém, trata-se de um dos investimentos mais rentáveis no âmbito de um projeto de IA.

Cada hora investida no início na descrição de objetivos, processos, dados e condições técnicas pode evitar muitas horas de trabalho adicional mais tarde. A IA deixa assim de trabalhar às cegas, passando a basear-se num entendimento comum do projeto.

É precisamente este entendimento comum que constitui a base para tudo o que se segue. É ele que determina se a IA se limita a realizar tarefas isoladas ou se se transforma num verdadeiro parceiro de desenvolvimento.

Por isso, o lançamento de um projeto nunca deve ser visto como uma tarefa incómoda. É o momento em que se lançam as bases para toda a colaboração futura. Quanto mais sólida for essa base, melhores serão, em geral, os resultados.

O contexto é mais importante do que o código

Muitos programadores partem do princípio de que os sistemas modernos de IA são, acima de tudo, particularmente bons a programar. Afinal, os exemplos mais impressionantes são frequentemente demonstrados através de código. Uma IA cria uma página web, desenvolve uma consulta a uma base de dados ou escreve uma função completa em poucos segundos.

No entanto, após alguma experiência prática, o quadro que se apresenta é frequentemente diferente. O verdadeiro ponto forte da IA moderna não reside, em primeiro lugar, na escrita de código. O seu maior trunfo consiste em relacionar informações entre si, identificar padrões e aplicar o conhecimento a novas situações.

É precisamente por isso que o contexto é tão importante. Quando uma IA compreende o contexto, obtêm-se frequentemente resultados surpreendentemente bons. Se esse contexto faltar, ela continua a produzir respostas e código, mas trabalha numa base insegura. A qualidade dos resultados diminui então frequentemente de forma significativa, mesmo que a programação pareça tecnicamente correta.

Na prática, verifica-se repetidamente que não é o código a matéria-prima decisiva de uma IA, mas sim o contexto em que esse código é criado.

Por que é que as instruções curtas muitas vezes dão maus resultados

Quem está a dar os primeiros passos com a IA tem frequentemente a tendência de formular as tarefas de forma muito sucinta. Um prompt típico poderia ser:

„Crie um sistema de gestão de clientes.“

Do ponto de vista técnico, esta afirmação não está errada. No entanto, quase todas as informações importantes ficam por esclarecer.

• Para que setor?
• Para quantos utilizadores?
• Que dados devem ser guardados?
• Que processos devem ser apoiados?
• Que análises são necessárias?
• Que sistemas já existem?

A IA tem de responder a todas estas perguntas por si própria e, inevitavelmente, faz suposições. Algumas delas serão, por acaso, corretas; outras, não. O resultado é comparável ao de um arquiteto a quem se diz apenas:

„Constrói-me uma casa.“

É claro que ele consegue projetar uma casa. No entanto, é pouco provável que esta corresponda exatamente às nossas expectativas. Quanto mais informações relevantes faltarem, maior será a margem de interpretação. E é precisamente essa margem de interpretação que, mais tarde, conduz frequentemente a correções desnecessárias.

A diferença entre informação e contexto

Há um ponto importante que é frequentemente ignorado em muitas discussões sobre IA. Informação e contexto não são a mesma coisa. As informações são factos isolados, por exemplo:

• O sistema utiliza o PostgreSQL.
• Existe uma tabela de clientes.
• A aplicação funciona no navegador.

Essas informações são úteis, mas, na maioria das vezes, não são suficientes. O contexto só surge quando as relações entre essas informações se tornam visíveis.

• Por que se utiliza o PostgreSQL?
• Que papel desempenha a tabela de clientes no sistema global?
• Que utilizadores utilizam a aplicação?
• Que processos empresariais estão associados a isso?

A IA não precisa apenas de factos, mas também do seu significado. Só assim poderá tomar decisões adequadas ao projeto. Quanto mais complexo for um projeto, mais importante se torna esta diferença.

A IA deve compreender a empresa

Uma observação interessante na prática é que os melhores resultados surgem frequentemente quando a IA não só compreende o software, mas também a empresa por trás dele.

Tomemos novamente o exemplo de um sistema ERP. Há uma diferença significativa consoante esse sistema seja desenvolvido para uma empresa de artesanato, um grossista, um consultório médico ou um comerciante online. Muitos requisitos técnicos decorrem diretamente do modelo de negócio.

Quem se limita a explicar à IA apenas a estrutura técnica, deixa-lhe a cargo grande parte da interpretação. Por outro lado, quem descreve também os processos da empresa fornece um contexto muito mais valioso. Por isso, muitas vezes vale a pena apresentar primeiro a organização à IA.

• Como é que a empresa ganha dinheiro?
• Quais são os processos mais importantes?
• Onde surgem os problemas mais comuns?
• Quais são os objetivos do software?

À primeira vista, estas informações podem parecer não ter grande relação com a programação. Na verdade, porém, muitas vezes melhoram consideravelmente a qualidade dos resultados técnicos.

O contexto reduz as decisões erradas

Um dos maiores pontos fortes de um bom contexto de projeto é o facto de as decisões erradas se tornarem significativamente mais raras. Imaginemos que uma IA deve desenvolver uma nova funcionalidade. Sem contexto, ela conhece apenas a tarefa atual. Ela tenta resolvê-la da forma mais eficiente possível.

Com contexto suficiente, ela também sabe:

• a arquitetura do sistema global
• princípios de design existentes
• decisões anteriores
• condições técnicas gerais
• objetivos a longo prazo

Isso permite-lhe adaptar automaticamente muitas sugestões à estrutura existente. A qualidade dos resultados nem sempre melhora gradualmente, mas sim de forma repentina. Por esse motivo, os programadores experientes dedicam frequentemente mais tempo a transmitir o contexto do que a formular tarefas específicas.

A documentação como repositório de contexto

É aqui que se revela a enorme importância de uma boa documentação do projeto. Nenhum programador quer ter de explicar as mesmas informações repetidamente. O mesmo se aplica à colaboração com sistemas de IA.

Uma documentação central serve, portanto, como um repositório permanente de contexto. Nela, é possível reunir informações importantes:

Objetivos do projeto, modelos de dados, decisões de arquitetura, convenções de nomenclatura, especificações técnicas e questões em aberto.

Novas equipas ou novos sistemas de IA podem, posteriormente, aceder a esta documentação e familiarizar-se com o projeto. Quanto mais abrangente for um projeto, mais importante se torna esta abordagem. De certa forma, isto cria uma espécie de memória coletiva do projeto. Não são apenas as pessoas que beneficiam com isso, mas também a IA.

Mais contexto não significa mais texto

É aqui que surge frequentemente um mal-entendido. Mais contexto não significa, automaticamente, produzir o maior número possível de páginas de texto.

O que importa é a relevância da informação. Uma descrição precisa de cinco páginas pode ser muito mais valiosa do que cinquenta páginas de texto desestruturado. A arte consiste em fornecer as informações que são realmente importantes para a compreensão de um projeto. Entre elas destacam-se, em particular:

• Objetivos
• Processos
• Estruturas de dados
• condições técnicas gerais
• Decisões arquitetónicas
• exemplos reais

Quem documentar bem estas áreas, na maioria das vezes já estará a criar uma excelente base.

Por que razão o contexto se torna mais importante do que a programação a longo prazo

Quanto mais eficientes se tornam os sistemas de IA, tanto mais o foco passa da programação propriamente dita para a transmissão de conhecimento.

O código está a tornar-se, cada vez mais, um recurso que pode ser gerado automaticamente. O contexto, por outro lado, continua a ser uma tarefa humana. Só as pessoas conhecem os objetivos de uma empresa. Só as pessoas compreendem os contextos políticos, organizacionais ou económicos. Só as pessoas podem definir a direção que um projeto deve seguir a longo prazo.

A IA pode utilizar esse conhecimento, ampliá-lo e traduzi-lo em soluções técnicas. No entanto, não é capaz de o gerar de forma autónoma. Por isso, é provável que, no futuro, o contexto se torne um dos recursos mais valiosos do desenvolvimento de software.

Quem fornece o contexto adequado a uma IA obtém, muitas vezes, resultados surpreendentemente bons. Quem, por outro lado, ignora este passo, verificará frequentemente que mesmo um código escrito na perfeição não conduz automaticamente a um bom software. Afinal, um software de sucesso não resulta de linhas de código isoladas, mas sim da compreensão das relações contextuais das quais essas linhas de código emanam.

A divisão de grandes projetos em chats de especialistas

Quem desenvolve pela primeira vez com um software de IA costuma trabalhar numa única conversa. É natural. Começa-se com uma ideia, descreve-se os requisitos e desenvolve-se o projeto passo a passo.

Em projetos de pequena dimensão, esta abordagem funciona frequentemente muito bem. Uma única aplicação, um script ou uma base de dados de dimensão reduzida podem ser facilmente acompanhados numa conversa por chat.

No entanto, à medida que a dimensão do projeto aumenta, os requisitos vão mudando. De repente, surgem inúmeras tabelas, várias funções de utilizador, múltiplas interfaces, documentação extensa e centenas de decisões tomadas ao longo do desenvolvimento. Ao mesmo tempo, surgem novos requisitos, enquanto as informações mais antigas vão ficando cada vez mais em segundo plano.

É, pelo menos, nesta altura que se torna evidente uma conclusão importante: os grandes projetos de software devem ser estruturados da mesma forma que as grandes empresas.

Ninguém esperaria que um único colaborador fosse, ao mesmo tempo, diretor executivo, contabilista, comercial, programador, designer e técnico de apoio. É precisamente por isso que, ao trabalhar com IA, vale a pena separar as diferentes áreas de responsabilidade.

A ideia de que uma única conversa acompanhe de forma permanente um grande projeto na sua totalidade é, sem dúvida, tentadora, mas torna-se cada vez mais impraticável à medida que a complexidade aumenta.

A ideia por trás dos chats com especialistas

Uma das formas mais eficazes em projetos de IA de maior dimensão consiste em criar vários chats com áreas de responsabilidade claramente definidas. Cada um desses chats tem um foco específico e, com o tempo, acaba por desenvolver uma espécie de especialização.

O princípio lembra as equipas de desenvolvimento tradicionais. Numa empresa, é frequente haver especialistas em bases de dados, interfaces de utilizador, infraestruturas, documentação ou controlo de qualidade. Ninguém tem de fazer tudo ao mesmo tempo.

Este mesmo conceito aplica-se surpreendentemente bem aos sistemas de IA. Em vez de escrever todas as perguntas num único chat, os diferentes temas são distribuídos de forma específica por várias áreas. Desta forma, as conversas mantêm-se mais organizadas e a IA pode concentrar-se mais na sua área de responsabilidade específica. Ao mesmo tempo, reduz-se o risco de que informações importantes se percam entre tantos temas diferentes.

O chat de arquitetura

O chat de arquitetura constitui frequentemente o centro estratégico de um projeto. É aqui que se tomam as decisões fundamentais.

• Que estruturas de dados devem ser utilizadas?
• Como é a arquitetura do sistema?
• Que módulos existem?
• Quais são as convenções de nomenclatura aplicáveis?
• Que princípios técnicos devem ser respeitados?

Esta conversa centra-se menos nas linhas de código individuais e mais no panorama geral.

Em muitos projetos, tem-se revelado eficaz documentar as decisões de arquitetura de forma o mais centralizada possível, em vez de as alterar constantemente entre diferentes canais de chat. Isto cria uma base sólida para todos os trabalhos futuros.

O chat de arquitetura torna-se, de certa forma, a memória técnica do projeto.

O chat do backend

Enquanto o chat de arquitetura aborda questões fundamentais, o chat de backend concentra-se na lógica de negócio propriamente dita. É aqui que se desenvolvem consultas à base de dados, interfaces, automatizações e processos complexos.

Nesta área, a IA pode concentrar-se inteiramente nos requisitos técnicos, sem ser constantemente distraída por questões de design ou de documentação.

Especialmente em projetos de maior dimensão, esta separação conduz frequentemente a resultados significativamente melhores. Com o tempo, o chat de backend torna-se um especialista em procedimentos internos e processos técnicos. Desta forma, a colaboração torna-se mais eficiente e transparente.

O chat do front-end

As interfaces de utilizador seguem frequentemente regras totalmente diferentes das dos sistemas de backend. Aqui, a facilidade de utilização, a navegação, os layouts e os fluxos de trabalho assumem um papel central. Um chat front-end pode abordar especificamente estas questões.

• Que informações devem estar visíveis?
• Que campos de preenchimento são necessários?
• Como deve ser a estrutura de uma máscara?
• Que etapas um utilizador percorre durante o seu trabalho?

Como este chat não precisa de lidar simultaneamente com lógica complexa de bases de dados ou questões de arquitetura, pode concentrar-se muito mais na perspetiva do utilizador.

Os programadores, em particular, tendem por vezes a dar mais importância aos aspetos técnicos do que à facilidade de utilização. Um chat integrado no front-end ajuda a melhorar esse equilíbrio.

O chat de documentação

Muitos projetos fracassam não por causa da tecnologia, mas devido à falta de documentação. No início, tudo parece lógico e óbvio. No entanto, alguns meses depois, já ninguém se lembra por que razão foram tomadas determinadas decisões.

Neste contexto, um chat dedicado à documentação pode trazer enormes vantagens. A sua função consiste em registar decisões técnicas, criar resumos do projeto, documentar alterações e disponibilizar o conhecimento a longo prazo.

Este chat deve colaborar o mais estreitamente possível com as restantes áreas do projeto. Sempre que forem criadas novas funcionalidades ou tomadas decisões de arquitetura, a documentação pode ser atualizada.

Assim, vai-se criando, passo a passo, uma valiosa obra de referência para todo o projeto.

O chat de garantia de qualidade

Uma abordagem particularmente interessante consiste em atribuir à IA um papel adicional como verificador. Em vez de desenvolver novas funções, este chat verifica o trabalho de outros chats. Ele analisa:

• possíveis erros
• Problemas de segurança
• Inconsistências
• Riscos de desempenho
• Lacunas na documentação

Este procedimento lembra as revisões de código clássicas nas equipas de desenvolvimento. A grande vantagem reside no facto de permitir a emergência de diferentes perspetivas.

Enquanto uma conversa sobre desenvolvimento se concentra frequentemente em implementar uma tarefa o mais rapidamente possível, a conversa sobre controlo de qualidade analisa criticamente a mesma solução e procura especificamente pontos fracos. Esta instância de controlo adicional pode aumentar consideravelmente a qualidade de um projeto.

A base de conhecimento comum

No entanto, vários chats entre especialistas só funcionam bem se tiverem acesso à mesma base de conhecimento. É precisamente por isso que a documentação central do projeto desempenha um papel tão importante. Todos os chats devem ter acesso às mesmas informações básicas:

Objetivos do projeto, decisões arquitetónicas, modelos de dados, convenções de nomenclatura e requisitos técnicos.

Desta forma, não se cria uma miscelânea de subprojetos independentes uns dos outros, mas sim um sistema comum com uma estrutura clara. Poder-se-ia dizer que a documentação constitui a linguagem comum de todos os chats.

Sem essa linguagem comum, corremos o risco de mal-entendidos e resultados contraditórios.

A IA como equipa virtual de programadores

Quanto mais tempo se trabalha com este método, mais evidente se torna uma ideia interessante. Os sistemas modernos de IA comportam-se cada vez mais como uma equipa virtual de programadores.

É claro que não se trata de pessoas reais. No entanto, muitos princípios organizacionais comprovados dos projetos de software clássicos podem ser aplicados de forma surpreendentemente eficaz. Em vez de recorrer a um único profissional multifacetado, surgem várias funções especializadas com responsabilidades bem definidas.

Desta forma, os projetos tornam-se mais claros, mais fáceis de acompanhar e, muitas vezes, de melhor qualidade. Especialmente em projetos de maior dimensão, esta abordagem pode fazer uma enorme diferença. Afinal, o desenvolvimento de software bem-sucedido não se resume apenas à programação. Envolve planeamento, arquitetura, documentação, garantia de qualidade e comunicação.

Quanto melhor estas áreas forem separadas umas das outras e, ao mesmo tempo, interligadas, tanto maior será, em regra, o sucesso de todo o projeto. E é precisamente aqui que os chats com especialistas revelam o seu maior ponto forte.

A documentação central do projeto

Quase todos os grandes projetos de software começam com uma visão clara. Os objetivos são conhecidos, os requisitos parecem acessíveis e as decisões mais importantes estão presentes na mente de todos os envolvidos. Nesta fase inicial, surge frequentemente a impressão de que uma documentação extensa não é, na verdade, necessária. Afinal, sabemos nós próprios por que razão foram tomadas determinadas decisões. As estruturas de dados são familiares, os processos são compreensíveis e a arquitetura parece lógica.

No entanto, a cada dia de desenvolvimento que passa, a situação muda. São adicionadas novas funcionalidades. Os requisitos alteram-se. As decisões anteriores são ampliadas ou ajustadas. Juntam-se novos programadores ao projeto. São abertos novos chats de IA. Surgem exceções e casos especiais. O que há poucas semanas era ainda algo totalmente natural começa lentamente a perder-se.

É precisamente neste ponto que se revela o verdadeiro valor de uma boa documentação de projeto. A sua finalidade não é, em primeiro lugar, produzir papel ou encher pastas. A sua função mais importante consiste em tornar o conhecimento permanentemente acessível. Poder-se-ia dizer que a documentação se torna a memória do projeto.

Por que razão os projetos de IA exigem tanta documentação

Curiosamente, a documentação não se torna menos importante com os sistemas modernos de IA, mas sim significativamente mais importante. Nos projetos tradicionais, era possível reter muita informação na memória ou transmiti-la através de conversas. No entanto, quando se trabalha com sistemas de IA, isso só é possível de forma limitada.

• Cada nova conversa começa, inicialmente, sem qualquer informação sobre o projeto.
• Cada nova conversa só tem acesso às informações que lhe são fornecidas.
• Qualquer IA adicional necessita de contexto para poder funcionar de forma eficaz.

Por isso, surge uma nova exigência: o conhecimento tem de ser armazenado de forma sistemática. A documentação deixa assim de ser apenas uma ajuda para as pessoas, passando a ser, simultaneamente, uma fonte de conhecimento para os sistemas de IA. Quanto mais abrangente for um projeto, maior será esta vantagem.

Uma boa documentação permite que os novos utilizadores se tornem produtivos em poucos minutos, em vez de ter de explicar repetidamente informações importantes.

O que deve ser documentado

Uma pergunta frequente é: que conteúdos é que, afinal, têm de ser documentados? A resposta é mais simples do que muitos pensam. Acima de tudo, devem ser documentadas as decisões. O código-fonte pode ser recriado ou analisado a qualquer momento. O que se torna mais difícil são as reflexões que estão por trás do código.

• Por que razão foi escolhida essa arquitetura?
• Por que é que a tabela foi estruturada desta forma?
• Por que razão uma interface foi implementada desta forma e não de outra?
• Por que razão foi rejeitada uma solução alternativa?

É precisamente esse tipo de informação que muitas vezes se perde quando não existe documentação. Quando, alguns meses depois, é necessário fazer uma alteração, mesmo os programadores mais experientes muitas vezes já não se lembram de todos os pormenores que estiveram na base das decisões anteriores. Uma boa documentação preserva esse conhecimento a longo prazo.

A visão geral do projeto como ponto de partida

Toda a documentação deve começar com uma visão geral clara do projeto. Esta secção serve de ponto de partida para todos os envolvidos. Aqui é explicado:

• Qual é o objetivo do projeto?
• Que problemas se pretende resolver?
• Quais são os principais módulos disponíveis?
• Que tecnologias são utilizadas?
• Qual é a visão a longo prazo que se pretende alcançar?

Esta secção não precisa de ser muito extensa. Muitas vezes, bastam algumas páginas. O importante é que um novo programador ou um novo chat de IA compreenda rapidamente do que se trata.

A visão geral do projeto constitui, de certa forma, o mapa de todo o empreendimento. Sem esse mapa, mesmo os detalhes individuais bem documentados tornam-se rapidamente confusos.

Documentar o modelo de dados

De acordo com a visão geral do projeto, o modelo de dados é um dos componentes mais importantes da documentação. Praticamente todas as aplicações se baseiam em dados. Clientes, artigos, projetos, faturas, utilizadores ou documentos estão interligados entre si e constituem a base do sistema. Por isso, deve ser documentado:

• Que tabelas existem?
• Quais são os campos mais importantes?
• Que relações existem?
• Quais são as regras comerciais aplicáveis?

Não se trata apenas de informações técnicas. O significado técnico dos dados é igualmente importante. Muitas vezes, o nome de um campo, por si só, pouco diz. Só a descrição da sua função deixa claro por que razão existe e como deve ser utilizado.

Para os sistemas de IA, este contexto é particularmente valioso. Quanto melhor forem descritas as estruturas de dados, tanto mais precisas poderão ser as sugestões posteriores.

---

Inquérito atual sobre a utilização de sistemas locais de IA

---

Registar as decisões de arquitetura

Uma das maiores fraquezas de muitos projetos reside no facto de as decisões de arquitetura serem tomadas apenas verbalmente. No momento da decisão, tudo parece lógico. No entanto, alguns meses depois, muitas vezes não fica claro por que razão se optou por um determinado caminho.

É precisamente por isso que vale a pena registar as decisões importantes. Não só a decisão em si deve ser documentada, mas também a sua fundamentação.

• Que alternativas foram consideradas?
• Por que é que foram rejeitados?
• Quais são as vantagens da solução escolhida?

Esta abordagem permite, muitas vezes, poupar imenso tempo mais tarde. Em vez de terem de retomar discussões antigas, os programadores e os sistemas de IA podem recorrer às informações já disponíveis.

Questões pendentes e problemas conhecidos

Uma boa documentação não descreve apenas o estado atual, mas também o que ainda não está concluído. Muitos projetos sofrem com o facto de as tarefas pendentes estarem dispersas por vários locais. Uma parte encontra-se em e-mails, outra em notas, e outra ainda em históricos de chat.

Isso faz com que se percam informações importantes. Tem-se revelado eficaz reunir centralmente os pontos pendentes. Entre estes incluem-se, por exemplo: ampliações planeadas, dívida técnica, erros conhecidos, sugestões de melhorias e ideias futuras.

Isto proporciona uma visão geral valiosa, especialmente em projetos de longo prazo. Os novos programadores ou sistemas de IA identificam imediatamente quais os temas já conhecidos e quais os trabalhos que ainda estão por realizar.

A documentação como um sistema dinâmico

Um erro comum é considerar a documentação como uma tarefa pontual. Elabora-se alguns documentos no início do projeto e, depois, quase não se atualizam. Desta forma, a documentação perde rapidamente o seu valor. Uma boa documentação de projeto é dinâmica. Ela cresce à medida que o projeto avança. As novas decisões são incorporadas. As alterações são registadas. As informações desatualizadas são atualizadas ou removidas.

Idealmente, isto deve ser feito de forma contínua durante o desenvolvimento. Os sistemas modernos de IA podem até mesmo dar um apoio ativo neste processo. Podem criar resumos, documentar alterações ou atualizar conteúdos existentes. Isto reduz consideravelmente o trabalho envolvido.

O investimento mais importante de um projeto

Muitos programadores investem avultadas quantias em hardware, licenças de software ou serviços externos. No entanto, um dos recursos mais valiosos é frequentemente subestimado: o conhecimento sobre o próprio projeto.

É precisamente esse conhecimento que a documentação preserva. Ela garante que as experiências não se percam. Evita que as mesmas perguntas tenham de ser respondidas repetidamente. E cria uma base comum para as pessoas e os sistemas de IA.

Quanto maior for um projeto, mais importante se torna esta função. Quem negligencia a documentação poupa tempo a curto prazo, mas acaba por perder muitas vezes muito mais tempo a longo prazo. Por outro lado, quem cria desde cedo um sistema centralizado de conhecimento estabelece uma base que pode trazer benefícios ao longo de vários anos.

Por isso, a documentação do projeto é muito mais do que uma simples compilação de informações técnicas. É a memória coletiva de um projeto – e, como tal, um dos pré-requisitos mais importantes para o sucesso do desenvolvimento de software com IA.

Vibe Coding, estrutura e a nova geração do desenvolvimento de software

O vídeo incluído complementa o conteúdo deste artigo de forma interessante e mostra como as ferramentas modernas de IA já podem ser utilizadas hoje em dia para desenvolver aplicações próprias com um esforço de programação relativamente reduzido. Destaca-se, em particular, o enfoque numa abordagem estruturada. Em vez de simplesmente deixar a IA „programar à toa“, é demonstrado como as ideias devem ser inicialmente planeadas de forma clara, as estruturas de bases de dados construídas e as interfaces definidas.

Desenvolvimento de software com IA: o caminho certo (em vez do caos) | Sebastian Claes

É precisamente esta abordagem que coincide com uma das principais mensagens deste artigo: o desenvolvimento de software bem-sucedido não começa com o código, mas sim com a compreensão dos requisitos e dos processos. O vídeo destaca ainda ferramentas atuais como o n8n, o Supabase e o MCP, bem como as possibilidades oferecidas pelos fluxos de trabalho automatizados. Particularmente valiosas são as observações sobre erros típicos no chamado „Vibe Coding“ e as recomendações para aplicações estáveis, escaláveis e sustentáveis a longo prazo. Assim, o vídeo oferece uma visão prática da colaboração moderna entre programadores e inteligência artificial.

Sugestões iniciais para novas conversas

Um dos maiores pontos fortes dos sistemas modernos de IA é a sua capacidade de se familiarizarem rapidamente com temas complexos. Ao mesmo tempo, é precisamente este aspeto que constitui também uma das suas maiores fraquezas.

Cada nova conversa começa, inicialmente, sem que o modelo tenha conhecimento do teu projeto. É claro que os modelos modernos possuem um vasto conhecimento geral. Conhecem linguagens de programação, bases de dados, frameworks e muitos conceitos técnicos. O que, no entanto, não conhecem são as particularidades do teu projeto.

Eles não sabem quais as decisões de arquitetura que já foram tomadas. Não conhecem as tuas convenções de nomenclatura. Não sabem nada sobre discussões anteriores nem sobre os objetivos subjacentes a determinadas funcionalidades.

Muitos programadores subestimam este aspeto. Abrir um novo chat, fazem uma pergunta técnica e depois ficam surpreendidos por a resposta não se adequar perfeitamente ao projeto em questão. No entanto, a causa muitas vezes não reside na qualidade da IA, mas sim na falta de uma introdução ao projeto. É precisamente aqui que os «startprompts» entram em ação.

O que é, afinal, um prompt de inicialização

Um prompt inicial não é, no fundo, mais do que uma introdução padronizada para novas conversas. Contém as informações mais importantes de que um sistema de IA necessita para se orientar no projeto o mais rapidamente possível. Pode ser comparado ao dossier de integração de um novo colaborador. Em vez de ter de explicar as mesmas informações de novo todas as vezes, a IA recebe as condições gerais mais importantes logo no início. Isto cria um entendimento comum sobre o modo de funcionamento, ainda antes de a tarefa propriamente dita começar.

Uma boa instrução inicial não só poupa tempo como também garante que os diferentes chats funcionem de forma coerente e tomem decisões semelhantes. Quanto maior for um projeto, mais valioso se torna este efeito.

Definir claramente o papel da IA

Um dos métodos mais eficazes consiste em atribuir à IA um papel específico logo no início. Muitos programadores limitam-se a incluir requisitos técnicos nos seus prompts. No entanto, muitas vezes obtêm-se melhores resultados quando se descreve também a perspetiva pretendida.

Por exemplo, uma IA pode desempenhar funções como arquiteto de software, programador sénior, especialista em bases de dados, testador ou redator de documentação. Isso faz com que a qualidade das respostas mude frequentemente. A IA recebe um quadro de referência claro e consegue adaptar melhor as suas sugestões à tarefa em questão.

Num chat sobre arquitetura, ela definirá prioridades diferentes das que definiria num chat sobre testes ou documentação. Esta definição clara de funções cria uma estrutura e reduz os mal-entendidos.

A documentação do projeto como leitura obrigatória

A documentação central do projeto deve constituir uma componente particularmente importante de muitos prompts iniciais. Idealmente, a IA deve ser instruída a familiarizar-se primeiro com as informações disponíveis, antes de elaborar alterações ou sugestões.

Este passo é esquecido com uma frequência surpreendente. No entanto, muitos problemas surgem precisamente porque os novos chats funcionam sem ter em conta as decisões já tomadas. Quando a documentação é integrada de forma consistente, a qualidade da colaboração melhora frequentemente de forma significativa.

A IA identifica relações mais rapidamente. Compreende melhor as estruturas existentes e tem automaticamente em conta decisões anteriores. Isto resulta numa consistência significativamente maior no âmbito do projeto.

Poder-se-ia dizer: a documentação fornece o conhecimento, enquanto o prompt de início garante que esse conhecimento seja efetivamente utilizado.

Estabelecer regras uniformes

À medida que a dimensão dos projetos aumenta, surge frequentemente a necessidade de regras bem definidas.

• Como devem ser nomeados os campos?
• Quais são as normas de documentação aplicáveis?
• Que princípios de arquitetura devem ser respeitados?
• Quais são as diretrizes de programação obrigatórias?

Uma boa instrução inicial pode consolidar essas regras de forma duradoura. Assim, não é necessário explicá-las novamente a cada nova tarefa. A IA já conhece as diretrizes e pode adaptar as suas sugestões em conformidade.

Este efeito não deve ser subestimado. Muitas pequenas inconsistências surgem simplesmente porque as regras não são comunicadas de forma coerente. As instruções iniciais ajudam a reduzir precisamente este problema.

Diferentes mensagens de início para diferentes tarefas

Ao longo de um projeto, verifica-se frequentemente que nem todos os canais de chat têm os mesmos requisitos. Um canal de chat dedicado à arquitetura necessita de informações diferentes das de um canal de chat dedicado à documentação. Um canal de chat de testes funciona de forma diferente de um canal de chat de front-end.

Por isso, muitas vezes vale a pena criar vários prompts iniciais. O núcleo comum permanece sempre o mesmo. Todos os chats têm a mesma visão geral do projeto, a mesma documentação e as mesmas regras básicas.

No entanto, é possível definir complementos específicos para cada tarefa.

• O chat sobre arquitetura centra-se em decisões a longo prazo.
• O chat no backend: implementação técnica.
• O chat de documentação sobre rastreabilidade e preservação do conhecimento.
• O chat sobre garantia de qualidade: análise de erros e revisão crítica.

Esta especialização conduz frequentemente a resultados significativamente melhores do que os obtidos com um prompt padrão universal.

As mensagens iniciais evoluem à medida que o projeto avança

Um erro comum é criar um prompt de início uma vez e nunca mais o ajustar. Na prática, porém, qualquer projeto de grande dimensão está em constante evolução.

Surgem novos módulos. Os processos mudam. São tomadas novas decisões técnicas. Por isso, os prompts de inicialização também devem ser revistos regularmente. O que era suficiente há alguns meses pode já estar incompleto hoje.

Tem-se revelado eficaz considerar os prompts de início como documentos dinâmicos. Estes evoluem em paralelo com o projeto e refletem o seu estado atual. Desta forma, os novos chats mantêm-se sempre atualizados com as informações mais recentes.

A IA deve pensar por si própria, não apenas executar

Um aspeto interessante dos sistemas modernos de IA é que não se limitam a executar instruções. Também são capazes de questionar, analisar e sugerir melhorias. Por isso, uma boa frase inicial não deve conter apenas comandos.

Muitas vezes, vale a pena solicitar expressamente à IA que assinale possíveis problemas. Por exemplo, pode-se definir que as inconsistências devem ser comunicadas ou que as violações da arquitetura devem ser ativamente abordadas. Desta forma, a IA passa de uma mera ferramenta a um interlocutor adicional.

É claro que não substitui a decisão humana. No entanto, pode ajudar a identificar os riscos numa fase precoce.

O caminho para uma abordagem profissional

Muitos programadores começam a trabalhar com IA de forma espontânea e intuitiva. Isso é perfeitamente normal. No entanto, à medida que os projetos vão ganhando dimensão, torna-se evidente que os processos estruturados oferecem enormes vantagens.

Os prompts iniciais fazem parte desses processos. Estabelecem uma base comum para todas as conversas, reduzem as repetições e garantem resultados consistentes. Acima de tudo, permitem a transmissão sistemática de conhecimento.

É precisamente este aspeto que, provavelmente, se tornará cada vez mais importante no futuro. Pois quanto maiores forem os projetos e quanto mais potentes forem os sistemas de IA, tanto mais a qualidade da preparação será determinante para o sucesso de um projeto.

Um bom prompt inicial é, portanto, muito mais do que apenas algumas frases introdutórias. É o bilhete de entrada para um projeto. E, muitas vezes, é precisamente esse bilhete de entrada que determina o grau de produtividade da colaboração que se seguirá.

Desenvolvimento iterativo em vez de prompts gigantescos

Quem trabalha com IA moderna pela primeira vez procura frequentemente aquele prompt milagroso que resolve todos os problemas. A ideia é tentadora. Descreve-se o projeto com o máximo de pormenor possível, clica-se em „Enviar“ e, pouco tempo depois, obtém-se um conceito pronto, uma estrutura de base de dados completa ou até mesmo um sistema de software inteiro.

À primeira vista, esta abordagem parece lógica. Afinal, os sistemas modernos de IA possuem capacidades impressionantes. Então, por que não tentar fazer com que realizem o máximo de trabalho possível de uma só vez?

No entanto, a prática mostra uma realidade diferente. Quanto maior e mais complexa for uma tarefa, mais importante se torna uma abordagem estruturada. Os melhores resultados raramente surgem de um único prompt gigantesco. Surgem, sim, de várias etapas que se complementam.

Tal como uma casa não é construída numa única etapa, mas sim através de um processo que inclui o planeamento, a fundação, a estrutura, o acabamento interior e os detalhes finais, também o software de sucesso é desenvolvido passo a passo. A IA acelera este processo, mas não o substitui.

Por que é que os grandes desafios são problemáticos

Muitos programadores enfrentam inicialmente um fenómeno semelhante. Formulam um requisito muito abrangente e recebem uma resposta impressionante. No entanto, ao analisarem a resposta com mais atenção, percebem que faltam detalhes importantes ou que certas premissas não se adequam ao projeto.

Isso não se deve ao facto de a IA funcionar mal. Pelo contrário, a complexidade da tarefa aumenta com cada requisito adicional. Quanto maior for a tarefa, mais interligações é necessário ter em conta simultaneamente. Ao mesmo tempo, aumenta a probabilidade de que alguns aspetos sejam ignorados ou mal interpretados.

Isto pode rapidamente causar problemas, especialmente em projetos de software de maior dimensão. Um pequeno erro no modelo de dados pode ter repercussões em inúmeras outras áreas. Um requisito pouco claro pode vir a exigir um trabalho de correção extenso. Por isso, na maioria das vezes, faz mais sentido dividir projetos de grande dimensão em etapas mais pequenas e controláveis.

O poder dos pequenos passos

Um efeito interessante dos sistemas modernos de IA é a sua capacidade de reagir com uma rapidez extraordinária a novas informações. Isso torna a abordagem iterativa particularmente atraente.

Em vez de se pretender desenvolver um sistema completo de uma só vez, começa-se por trabalhar numa pequena parte do mesmo. Esta é analisada, melhorada e documentada. Só depois se passa à etapa seguinte.

Este procedimento assemelha-se aos métodos modernos de desenvolvimento ágil. Em vez de se trabalhar durante meses para alcançar um grande resultado final, obtêm-se muitos pequenos resultados intermédios. Cada um desses resultados pode ser avaliado e, se necessário, corrigido. Desta forma, o risco diminui consideravelmente. Os erros são detetados mais cedo e os ajustes podem ser implementados com maior facilidade.

Do geral ao pormenor

Uma boa prática consiste em definir, em primeiro lugar, o contexto geral. No início, surgem perguntas como:

• Que problema se pretende resolver?
• Quais são os módulos principais necessários?
• Que utilizadores trabalham com o sistema?
• Que dados é necessário gerir?

Só depois de esclarecidos estes fundamentos é que se passa ao nível seguinte.

• A seguir, descrevemos cada um dos módulos com mais pormenor.
• Em seguida, são criados modelos de dados, processos e interfaces de utilizador.
• Seguem-se, em seguida, detalhes técnicos e implementações concretas.

Esta transição gradual do geral para o específico tem uma grande vantagem. A IA pode desenvolver cada nível com base nas decisões já confirmadas. Isto resulta numa estrutura significativamente mais estável.

A importância dos exames intercalares

Um erro comum consiste em aceitar os resultados imediatamente, sem os questionar devidamente. Precisamente porque a IA funciona tão rapidamente, surge por vezes a tentação de avançar imediatamente para o passo seguinte. A longo prazo, porém, é frequentemente mais sensato fazer uma pausa consciente após cada etapa importante.

• O resultado está de acordo com os objetivos do projeto?
• Foram tidos em conta todos os requisitos?
• Existem possíveis pontos fracos?
• As decisões estão devidamente documentadas?

Embora essas verificações intercalares demorem algum tempo, muitas vezes poupam um esforço considerável nas fases posteriores do projeto. Quanto mais cedo os problemas forem detetados, mais barato será corrigi-los.

As iterações como processo de aprendizagem

Outra vantagem do desenvolvimento iterativo é que não é só a IA que aprende, mas também o próprio programador. Muitos requisitos só se tornam realmente visíveis durante o trabalho.

• Um processo que, à primeira vista, parecia fazer sentido pode acabar por revelar-se impraticável.
• É necessário ampliar uma estrutura de dados.
• Uma interface de utilizador necessita de informações adicionais.

Essas descobertas fazem parte de qualquer projeto. A abordagem iterativa não as transforma em problemas, mas sim numa parte natural do desenvolvimento. Cada iteração melhora a compreensão comum do sistema. Desta forma, a qualidade vai aumentando passo a passo.

Por que razão a perfeição raramente faz sentido no início

Muitos programadores tentam encontrar soluções perfeitas logo nas primeiras conversas. Isso é compreensível, mas muitas vezes não é necessário. Na prática, os melhores sistemas desenvolvem-se geralmente através de muitas pequenas melhorias.

A primeira versão de um modelo de dados não precisa de ser perfeita. O mesmo se aplica à primeira interface de utilizador. O mais importante é criar uma base funcional que possa ser posteriormente aperfeiçoada.

É precisamente aqui que a IA demonstra os seus pontos fortes. Permite ajustes rápidos e apoia melhorias contínuas. Isso torna muito mais fácil testar ideias e otimizá-las gradualmente.

A IA como parceiro de treino

Quem trabalha de forma iterativa não utiliza a IA apenas como uma ferramenta de execução. Ela torna-se um interlocutor. É possível debater novas ideias. É possível comparar alternativas. É possível analisar riscos.

Isso torna o desenvolvimento mais dinâmico. Em vez de ter de esperar muito tempo pela concretização de uma ideia, surgem em pouco tempo propostas concretas, que podem depois ser avaliadas e aperfeiçoadas.

Este diálogo conduz frequentemente a melhores resultados do que planos rígidos elaborados ao longo de vários meses.

O caminho para um resultado melhor

Quanto maior é um projeto, mais evidente se torna a vantagem da abordagem iterativa. Os grandes sistemas raramente resultam de um único projeto genial. Surgem, sim, de muitas decisões que se complementam.

• Cada passo traz novos conhecimentos.
• Cada iteração melhora a compreensão.
• Cada verificação melhora a qualidade.

Os sistemas modernos de IA aceleram consideravelmente este processo. No entanto, não o substituem. Por isso, os programadores devem resistir à tentação de tentar resolver tudo numa única instrução gigantesca.

Os projetos de maior sucesso não resultam, na maioria das vezes, do maior prompt. Resultam de muitos pequenos passos bem pensados que, em conjunto, formam um todo. E é precisamente aí que reside uma das lições mais importantes do desenvolvimento moderno de software baseado em IA.

A IA como equipa virtual de programadores

Muitas pessoas ainda encaram a inteligência artificial como uma ferramenta particularmente poderosa. Esta perspetiva não está errada, mas muitas vezes fica aquém da realidade. Quem trabalha há algum tempo com sistemas modernos de IA acaba, mais cedo ou mais tarde, por ter uma experiência interessante. A colaboração parece cada vez menos a utilização de uma ferramenta e cada vez mais o trabalho em equipa.

É claro que a IA não possui consciência, nem interesses próprios, nem responsabilidade pessoal. No entanto, pode assumir diferentes funções, trazer diferentes perspetivas e realizar tarefas que, anteriormente, teriam sido distribuídas por vários colaboradores.

É precisamente aqui que reside uma das evoluções mais interessantes do desenvolvimento de software moderno. Muitas vezes, a verdadeira força não reside no facto de uma única IA ser particularmente inteligente, mas sim na combinação de vários métodos de trabalho especializados.

Isso não significa que o programador seja substituído. O seu papel passa, antes, a centrar-se na coordenação, na gestão e no controlo de qualidade.

Por que razão uma única perspetiva muitas vezes não é suficiente

Nos projetos de software tradicionais, raramente todos os envolvidos partilham a mesma perspetiva. Um arquiteto pensa de forma diferente de um programador. Um testador tem em conta outros aspetos do que um designer. Um gestor de projeto coloca questões diferentes das de um especialista em bases de dados. Estas diferentes perspetivas têm uma grande vantagem: os erros são detetados mais cedo e as soluções são analisadas sob vários ângulos.

É precisamente este princípio que se aplica surpreendentemente bem aos sistemas de IA. Em vez de utilizar a IA exclusivamente como programadora, é possível atribuir-lhe várias funções e fazer com que analise a mesma questão sob diferentes perspetivas.

Isso resulta frequentemente em resultados significativamente melhores. Um chat de arquitetura pode, por exemplo, conceber uma solução, enquanto um chat de garantia de qualidade analisa criticamente essa mesma solução.

Embora o debate tenha lugar em diferentes instâncias de IA, segue os mesmos princípios que se aplicam às equipas de desenvolvimento tradicionais.

O arquiteto de software virtual

A função do arquiteto de software é particularmente importante. Esta conversa centra-se menos nas funcionalidades individuais e mais nas consequências a longo prazo das decisões tomadas.

• Que estrutura é a mais adequada?
• Que módulos devem ser separados?
• Como se podem ter em conta futuras ampliações?
• Que riscos decorrem de determinadas decisões de design?

Enquanto os programadores estão frequentemente, e compreensivelmente, concentrados na tarefa em mãos, o arquiteto virtual analisa o sistema na sua totalidade. Isto cria uma camada adicional de segurança.

Muitos problemas futuros podem ser evitados se as questões fundamentais de arquitetura forem cuidadosamente ponderadas numa fase inicial. Especialmente em projetos de maior dimensão, este papel pode gerar um enorme valor.

O programador virtual

O papel mais evidente continua a ser, naturalmente, o do programador. É aqui que surgem soluções concretas, consultas a bases de dados, interfaces, interfaces de utilizador e lógica de negócio. A produtividade dos sistemas modernos de IA é impressionante nesta área. Tarefas que antes levariam várias horas ou dias a realizar podem, muitas vezes, ser preparadas em poucos minutos.

No entanto, há um ponto importante que não deve ser esquecido. A rapidez da implementação não deve levar a que se prescinda da análise e da verificação. Mesmo o melhor programador virtual necessita de orientações claras, objetivos compreensíveis e uma documentação sólida.

Quanto melhor for essa base, melhores serão, em geral, os resultados.

O testador virtual

Há uma função que ainda é subestimada em muitos projetos: a do testador. Os programadores concentram-se, compreensivelmente, em criar soluções. Os testadores concentram-se em encontrar problemas.

Esta abordagem é fundamentalmente diferente. Um chat de teste pode procurar pontos fracos de forma específica. Pode simular situações de erro, analisar condições limite e colocar questões críticas.

• O que acontece se os dados introduzidos forem inválidos?
• Como é que o sistema reage quando faltam dados?
• Que problemas de segurança poderão surgir?
• Que casos específicos foram ignorados?

Esta perspetiva conduz frequentemente a conclusões que não eram visíveis durante o próprio processo de desenvolvimento. Por isso, vale frequentemente a pena submeter as novas funcionalidades à análise de uma função de IA independente.

O autor de documentação virtual

A documentação raramente está entre as tarefas mais populares de um projeto. Ao mesmo tempo, é uma das mais importantes. Um redator de documentação virtual pode ajudar a preservar o conhecimento de forma sistemática. Ele elabora descrições de projetos, documenta decisões, resume reuniões e atualiza a documentação técnica.

A vantagem principal reside no facto de este trabalho poder ser realizado em paralelo com o desenvolvimento. Em vez de se ter de recuperar a documentação apenas no final, esta torna-se uma parte integrante e contínua do projeto.

Desta forma, o conhecimento permanece permanentemente disponível e os novos membros da equipa – sejam eles humanos ou IA – podem integrar-se muito mais rapidamente.

O crítico virtual

Um papel particularmente interessante é o do avaliador crítico. Este chat tem um objetivo diferente do dos restantes participantes.

Ele não deve concordar. Deve questionar.

Ele analisa pressupostos, procura pontos fracos e verifica se as decisões fazem realmente sentido. Os programadores, em particular, tendem por vezes a apegar-se a uma determinada solução. É humano. Um chat de IA crítico pode ajudar a revelar perspetivas alternativas.

• Talvez haja uma solução mais simples.
• Talvez tenha sido esquecido um requisito importante.
• Talvez surjam riscos a longo prazo.

Essas dicas são frequentemente extremamente úteis.

O ser humano continua a ser o gestor do projeto

Apesar de todo o entusiasmo em torno dos sistemas modernos de IA, há algo que deve ficar claro. A responsabilidade continua a ser do ser humano. A IA pode fazer sugestões. Pode analisar, verificar e documentar. Pode até simular diferentes perspetivas. No entanto, as decisões finais continuam a ser tomadas pelo programador, pelo empresário ou pelo gestor de projeto.

Isso também faz sentido. Só as pessoas conhecem os objetivos comerciais de um projeto. Só as pessoas conseguem avaliar de forma completa os aspetos económicos, jurídicos ou estratégicos.

A IA amplia as possibilidades. No entanto, não substitui a responsabilidade.

O futuro do trabalho em equipa

Quanto mais tempo se trabalha com IA, mais evidente se torna que os projetos bem-sucedidos se assemelham cada vez mais a uma colaboração entre pessoas e especialistas digitais. O programador já não trabalha sozinho. Ao mesmo tempo, também não é substituído. Em vez disso, surge uma nova forma de trabalho em equipa.

É uma pessoa que define o rumo, toma as decisões e assume a responsabilidade pelos resultados. Várias funções especializadas de IA apoiam-na na análise, no desenvolvimento, na documentação, nos testes e na garantia da qualidade.

É precisamente aí que poderá residir uma das maiores mudanças dos próximos anos. O que será decisivo não é a questão de saber se a IA substituirá as pessoas, mas sim a questão de saber até que ponto as pessoas aprenderão a colaborar com uma equipa de desenvolvimento virtual.

Quem dominar esta colaboração poderá, no futuro, implementar projetos de software de forma mais rápida, mais estruturada e com maior qualidade do que nunca.

Agentes de IA, competências e a próxima etapa evolutiva do desenvolvimento de software

O vídeo incorporado do Fraunhofer IEM retoma uma ideia que também é abordada várias vezes neste artigo: o futuro do desenvolvimento de software poderá ser menos marcado por aplicações individuais e, em vez disso, muito mais influenciado pelo conhecimento, pelo contexto e por agentes de IA especializados. No centro estão as chamadas „competências“ – módulos estruturados de conhecimento e tarefas que permitem aos sistemas de IA executar atividades complexas de forma autónoma.

Agentes de IA e competências: o fim do desenvolvimento de software tradicional? | Fraunhofer IEM

Particularmente interessante é o paralelo com o desenvolvimento moderno de software baseado em IA: já não são as linhas de código individuais que estão em primeiro plano, mas sim a descrição de processos, regras e relações. O vídeo explica de forma compreensível como tecnologias como o MCP (Model Context Protocol), sistemas de agentes e fontes de conhecimento centrais podem interagir. É também discutida a questão de saber se o software clássico será, a longo prazo, complementado ou parcialmente substituído por sistemas de agentes flexíveis. Independentemente da rapidez com que esta evolução avance, o vídeo demonstra de forma impressionante por que razão o contexto, a documentação e a gestão do conhecimento poderão vir a ser, no futuro, alguns dos recursos mais importantes dos projetos de software modernos.

Erros típicos no desenvolvimento apoiado por IA

A história da tecnologia revela repetidamente um padrão semelhante. Assim que novas ferramentas se tornam disponíveis, muitas pessoas concentram-se inicialmente nas possibilidades e muito menos nos riscos. Foi assim com os primeiros computadores, com as bases de dados, com a introdução da Internet e, hoje em dia, com a inteligência artificial.

O entusiasmo é compreensível. Os sistemas modernos de IA conseguem realizar, em poucos minutos, tarefas que antes levariam horas ou dias. Analisam requisitos, elaboram conceitos, escrevem código e ajudam na documentação.

No entanto, é precisamente essa rapidez que, por vezes, causa problemas. Muitos erros não ocorrem porque a IA faz um mau trabalho. Ocorrem porque as pessoas interpretam mal o funcionamento da IA ou negligenciam princípios fundamentais.

Quem pretenda ter sucesso a longo prazo no desenvolvimento com IA deve, por isso, conhecer os obstáculos mais comuns.

Erro n.º 1: Falta de contexto

O erro provavelmente mais comum consiste em fornecer pouca informação à IA. Muitos programadores definem tarefas muito sucintas e, mesmo assim, esperam resultados de alta precisão.

• A IA deve desenvolver uma função, mas não conhece o projeto.
• Ela tem de conceber uma estrutura de base de dados, mas não sabe nada sobre os processos empresariais.
• Ela deve criar uma interface de utilizador, mas não conhece os futuros utilizadores.

É claro que a IA pode, mesmo assim, fornecer respostas. Ela tentará fazer suposições plausíveis com base no seu conhecimento geral. O problema é que essas suposições não se adequam necessariamente ao teu projeto. Quanto maior for a lacuna de conhecimento, maior será a probabilidade de mal-entendidos.

Por isso, aplica-se uma regra simples: quando um resultado não corresponde às expectativas, a causa muitas vezes não reside na IA, mas sim na falta de contexto.

Erro n.º 2: Tarefas demasiado amplas

Outro erro comum consiste em atribuir demasiadas tarefas à IA ao mesmo tempo. Os principiantes, em particular, tendem a formular instruções muito abrangentes. Pretendem desenvolver um sistema ERP completo, planear uma plataforma inteira ou criar um software empresarial completo.

É compreensível pensar assim. Afinal, o desempenho dos modelos modernos é impressionante. Na prática, porém, os melhores resultados surgem geralmente através de um processo gradual. Os grandes projetos devem ser divididos em tarefas mais pequenas e claramente definidas.

• Primeiro, desenvolve-se a arquitetura.
• Em seguida, o modelo de dados.
• Em seguida, os módulos individuais.
• Depois, as interfaces de utilizador.
• Por fim, testes e otimizações.

Esta abordagem não só melhora a qualidade dos resultados, como também facilita o controlo. É muito mais fácil verificar pequenos passos do que soluções completas e de grande envergadura.

Erro n.º 3: Falta de documentação

Muitos programadores já conhecem este problema de projetos tradicionais. Enquanto tudo ainda está fresco na memória, a documentação parece supérflua. Algumas semanas ou meses depois, a situação costuma ser bem diferente.

• Por que razão foi criada esta tabela?
• Por que razão foi tomada essa decisão arquitetónica?
• Por que razão se optou por uma determinada solução?

Sem documentação, essas informações perdem-se. Nos projetos de IA, este erro tem frequentemente um impacto ainda maior. Os novos chats não têm conhecimento das conversas anteriores. Os novos membros do projeto não conhecem o contexto. As decisões importantes têm de ser explicadas repetidamente.

Isso dá origem a discussões desnecessárias e à duplicação de esforços. Por isso, uma documentação de projeto rigorosa é um dos fatores mais importantes para o sucesso do desenvolvimento de software moderno.

Erro n.º 4: Confiança cega

A qualidade dos sistemas de IA atuais pode ser impressionante. É precisamente por isso que, por vezes, surge uma tentação perigosa. Começamos a deixar de questionar suficientemente os resultados. Este erro ocorre com especial frequência entre os programadores que acabaram de alcançar os seus primeiros grandes sucessos com a IA.

De repente, as consultas complexas passam a funcionar. As interfaces são criadas automaticamente. A documentação é gerada em poucos minutos. No entanto, apesar de todos os avanços, um facto importante permanece:

• A IA pode cometer erros.
• Ela pode interpretar mal as relações entre as coisas.
• Pode partir de pressupostos desatualizados.
• Pode desenvolver soluções técnicas que, embora pareçam plausíveis, apresentam, no entanto, pontos fracos.

Por isso, qualquer decisão importante deve ser analisada. A confiança faz sentido. A confiança cega, por outro lado, raramente.

Erro n.º 5: Saltar de chat em chat sem uma estrutura definida

À medida que a experiência em projetos aumenta, surgem frequentemente muitos chats diferentes. Em princípio, isso faz sentido. No entanto, torna-se problemático quando não existe uma estrutura comum. Nesse caso, as informações importantes ficam dispersas por vários locais.

• As decisões de arquitetura são tomadas num chat.
• As documentações são criadas noutro local.
• As novas funcionalidades estão a ser desenvolvidas numa terceira versão.

Após algumas semanas, já ninguém sabe ao certo onde se encontra cada informação. O resultado são contradições, incoerências e trabalho extra desnecessário. Por isso, os projetos devem ser organizados de forma clara desde o início.

Os chats especializados são úteis, mas requerem uma base de conhecimento comum e uma documentação centralizada. Só assim é possível criar um sistema global coerente.

Erro n.º 6: Considerar a IA como um oráculo

Outro erro de raciocínio consiste em considerar a IA como uma autoridade infalível. Muitas respostas parecem ter sido formuladas de forma convincente. É precisamente aí que, por vezes, reside o perigo. A IA apresenta frequentemente as suas sugestões com grande segurança, mesmo quando existem incertezas. Isso não significa que ela esteja a enganar deliberadamente. Ela funciona simplesmente com base em probabilidades estatísticas.

Por isso, devemos aprender a analisar as respostas de forma crítica. Nem toda a formulação elegante é automaticamente correta. Nem toda a explicação que soa técnica é automaticamente correta. A IA fornece sugestões, não verdades absolutas.

Quanto mais cedo se interiorizar esta atitude, melhor será a colaboração.

Erro n.º 7: Não adaptar os processos

Alguns programadores tentam trabalhar com a IA exatamente da mesma forma que faziam antes, sem a IA. Utilizam as novas ferramentas apenas como um gerador de código mais rápido.

Com isso, desperdiçam grande parte do seu potencial. O verdadeiro ponto forte da IA moderna não reside apenas na escrita de código. Reside na análise, na documentação, no planeamento, na garantia de qualidade e na gestão do conhecimento.

Quem não adapta a sua forma de trabalhar acaba por aproveitar apenas uma pequena parte das possibilidades disponíveis. Por isso, os programadores de sucesso aprendem a aperfeiçoar os seus processos. Integram a IA de forma sistemática nos seus fluxos de trabalho e criam novas formas de colaboração.

Os erros fazem parte do processo de aprendizagem

Apesar de todos os avisos, não se deve esquecer um ponto importante. Os erros são normais. Qualquer nova tecnologia requer experiência. Ninguém cria, desde o início, prompts perfeitos, documentações perfeitas ou processos perfeitos.

Afinal, a colaboração com a IA é também uma competência que se desenvolve através da experiência prática. A cada projeto, aumenta a compreensão sobre quais as informações que são importantes, quais os métodos de trabalho que funcionam e quais os erros que devem ser evitados.

É precisamente por isso que não se deve considerar os contratempos como um fracasso. Muitas vezes, são apenas sinais de que um processo pode ser melhorado.

Quando se analisam os erros mais comuns, surge um padrão interessante. A maioria dos problemas tem, surpreendentemente, muito pouco a ver com programação. Eles resultam da falta de informação, da falta de estrutura, de documentação insuficiente ou de expectativas erradas.

A implementação técnica nem sempre é o maior desafio. O verdadeiro desafio consiste em organizar o conhecimento, tornar as relações compreensíveis e estruturar de forma eficaz a colaboração entre o ser humano e a IA.

Quem dominar estes princípios básicos evitará automaticamente muitos dos erros típicos. E é precisamente isso que, no final, resulta não só num código melhor, mas também, na maioria das vezes, num software significativamente melhor.

NÃO uses o Codex antes de veres este vídeo! (A SuperApp do ChatGPT) | IA Everlast

Exemplo prático de um projeto de maior dimensão

Até agora, temos abordado principalmente os princípios. Falámos sobre a razão pela qual o contexto é mais importante do que o código, por que razão a documentação desempenha um papel central e como os projetos de maior dimensão podem ser distribuídos por vários chats especializados.

Mas como é que tudo isto se traduz na prática? A resposta é: de forma surpreendentemente pouco espetacular.

Muitas pessoas imaginam o desenvolvimento baseado em IA como se bastasse introduzir um único prompt e, poucas horas depois, obter um sistema de software pronto a usar. Essas ideias são ainda reforçadas por vídeos promocionais e demonstrações impressionantes.

A realidade é outra. Mesmo com a IA, os grandes projetos vão surgindo passo a passo. A diferença não reside no facto de o planeamento e a estrutura se tornarem supérfluos. Pelo contrário: tornam-se mais importantes do que nunca.

Para ilustrar isto, analisaremos neste capítulo um exemplo típico do desenvolvimento de um sistema de software de grande dimensão. Não se trata de um produto específico, mas sim de um processo de desenvolvimento generalizado, tal como pode ocorrer em muitos projetos.

A ideia do projeto

Quase todos os projetos começam com uma ideia. Identifica-se um problema, uma lacuna no mercado ou um fluxo de trabalho ineficiente e, a partir daí, desenvolve-se uma visão para uma nova solução de software.

É precisamente neste ponto que, muitas vezes, se inicia a primeira colaboração com a IA. Em vez de se falar logo de bases de dados ou interfaces de utilizador, começa-se por descrever o objetivo propriamente dito.

• Que problema se pretende resolver?
• Quem irá utilizar o software mais tarde?
• Que vantagens é que ela oferece?
• Que soluções já existem?

Este primeiro passo parece muitas vezes simples, mas reveste-se de enorme importância. Quanto mais clara for a formulação da ideia do projeto, mais fácil será para a IA contextualizar as decisões posteriores. Uma boa descrição do projeto torna-se, assim, uma espécie de bússola para todas as fases de desenvolvimento seguintes.

O modelo de dados está a ser desenvolvido

Depois de definido o objetivo principal, começa a estruturação propriamente dita do projeto. Em muitos casos, concentra-se inicialmente nos dados.

• Que informações devem ser guardadas?
• Que objetos existem?
• Que relações existem entre eles?

É aqui que se revela já uma das grandes vantagens dos sistemas modernos de IA. Estes podem ajudar a revelar relações que, por si só, poderíamos ter ignorado.

Ao mesmo tempo, a responsabilidade recai sobre o programador. A IA pode apresentar sugestões, indicar alternativas e conceber estruturas. No entanto, a adequação dessas sugestões continua a ter de ser avaliada por especialistas.

Muitas vezes, são elaborados vários esboços, que são posteriormente discutidos e aperfeiçoados. O objetivo não é criar um modelo de dados o mais rapidamente possível, mas sim desenvolver um modelo de dados que se mantenha viável a longo prazo.

A arquitetura é definida

À medida que os dados se tornam mais claros, inicia-se a fase seguinte. Surge agora a questão de saber como é que os diferentes componentes do sistema devem interagir entre si.

• Que módulos são necessários?
• Que interfaces são necessárias?
• Como é que as extensões devem ser integradas posteriormente?

É precisamente nesta fase que se revela a vantagem dos chats especializados. Um chat de arquitetura pode concentrar-se em questões estruturais de longo prazo, enquanto outros chats já desenvolvem os primeiros conceitos detalhados.

Paralelamente, a documentação do projeto vai crescendo. Todas as decisões importantes são registadas. Não só o resultado, mas também a justificação por trás dele. Desta forma, vai-se criando, passo a passo, uma base de conhecimento compreensível.

Os primeiros protótipos

Chega um momento em que a teoria se encontra com a prática.

• Os primeiros protótipos estão a ser criados.
• As interfaces de utilizador são concebidas.
• As consultas à base de dados estão a ser testadas.
• Os fluxos de trabalho são simulados.

É aqui que muitos programadores observam um efeito interessante. Os primeiros resultados visíveis são extremamente motivadores. Ao mesmo tempo, surgem novas questões que ainda não eram visíveis durante a fase de planeamento. Talvez faltem determinados campos. Talvez seja necessário ajustar alguns processos. Talvez se verifique que uma suposição inicial não é viável.

Isso é perfeitamente normal. O desenvolvimento de software não é um processo linear. Mesmo com a IA, a qualidade resulta da iteração e da melhoria contínua.

A colaboração entre várias funções de IA

À medida que a dimensão dos projetos aumenta, a divisão de tarefas torna-se cada vez mais importante. O programador já não trabalha com uma única IA, mas sim com várias funções especializadas.

• Um chat analisa a arquitetura.
• Outro desenvolve funcionalidades.
• Um terceiro documenta as decisões.
• Um quarto analisa possíveis pontos fracos.

Isto dá origem a um modo de trabalho surpreendentemente semelhante ao das equipas de desenvolvimento tradicionais. A diferença fundamental reside no facto de estas funções serem flexíveis e poderem alternar muito rapidamente entre diferentes tarefas.

No entanto, o controlo central continua a estar nas mãos do ser humano. É ele quem decide quais as sugestões que serão aceites e quais as que não serão.

A importância da documentação contínua

À medida que os projetos de maior envergadura avançam, torna-se cada vez mais evidente a razão pela qual a documentação desempenha um papel tão fundamental. No início, o projeto ainda parece acessível. No entanto, após alguns meses, existem frequentemente centenas de decisões, inúmeros módulos e uma grande variedade de pormenores técnicos.

Sem documentação, uma parte significativa deste conhecimento iria perder-se. Por isso, a documentação não é vista como uma obrigação incómoda, mas sim como uma componente ativa do desenvolvimento. Desta forma, os novos colaboradores podem integrar-se rapidamente. As decisões anteriores permanecem compreensíveis. A longo prazo, todo o projeto torna-se mais fácil de manter.

Especialmente no desenvolvimento baseado em IA, este aspeto é um dos fatores de sucesso mais importantes de todos.

As mudanças inevitáveis

Nenhum grande projeto de software permanece inalterado. Surgem novos requisitos. Os desejos dos clientes mudam. As tecnologias continuam a evoluir. Algumas ideias revelam-se excelentes, outras menos viáveis.

Por isso, toda a arquitetura deve possuir flexibilidade suficiente para se adaptar às mudanças. Aqui fica mais uma vez patente a importância de uma documentação bem organizada e de uma estrutura clara. Quanto melhores forem as bases, mais fácil será implementar ajustes posteriores.

A IA pode ajudar a analisar o impacto das alterações e a desenvolver alternativas. No entanto, a decisão estratégica continua a ser da responsabilidade do programador.

O que os projetos bem-sucedidos têm em comum

Quando se analisam vários projetos de IA, observam-se sempre padrões semelhantes. Os projetos bem-sucedidos começam com uma visão clara. Possuem uma estrutura compreensível. Documentam as decisões importantes. Dividem as tarefas de grande envergadura em partes mais pequenas.

E não encaram a IA como uma solução mágica, mas sim como um parceiro eficaz no âmbito de um processo de desenvolvimento mais vasto. O verdadeiro ponto forte da IA moderna não reside na capacidade de criar software com um simples clique. O seu ponto forte reside no apoio que presta aos programadores nas fases de análise, planeamento, implementação e documentação. É precisamente isso que dá origem a novas possibilidades.

O caminho é mais importante do que o primeiro prompt

Quem desenvolve com IA pela primeira vez procura frequentemente o prompt perfeito. Após alguns projetos de maior envergadura, essa perspetiva costuma mudar. O sucesso de um projeto raramente depende de uma única entrada. O que é decisivo é, antes de mais, todo o processo.

• A ideia do projeto.
• A análise.
• A arquitetura.
• A documentação.
• A colaboração entre diferentes funções.
• A melhoria contínua.

A IA pode apoiar todas estas áreas. No entanto, não substitui a necessidade de pensar de forma estruturada e de trabalhar de forma sistemática. Por isso, o desenvolvimento bem-sucedido apoiado pela IA assemelha-se, em última análise, ao desenvolvimento de software bem-sucedido em geral.

A diferença reside apenas no facto de hoje dispormos de ferramentas significativamente mais poderosas. E é precisamente por isso que não será o melhor prompt a determinar o sucesso de um projeto, mas sim a qualidade de todo o processo de desenvolvimento.

O futuro do desenvolvimento de software

Ao acompanhar o debate atual sobre a inteligência artificial, é fácil ficar com a impressão de que tudo já está decidido. Uns estão convencidos de que os programadores em breve se tornarão desnecessários. Outros consideram a IA uma moda passageira que desaparecerá dentro de alguns anos.

Com base na minha experiência até agora, considero ambas as perspetivas demasiado simplistas. O verdadeiro desenvolvimento está apenas a começar.

Enquanto escrevo este artigo, estou a trabalhar num projeto de software de grande envergadura que está a ser desenvolvido com o apoio da IA desde o início. Não se trata apenas de deixar a IA escrever código. O que é muito mais interessante é a questão de saber como os processos de desenvolvimento mudam quando, de repente, se tem à disposição um assistente inteligente de forma permanente.

Já após algumas semanas, tornam-se evidentes diferenças significativas em relação ao método de trabalho tradicional. As ideias podem ser avaliadas mais rapidamente. Os conceitos surgem em menos tempo. A documentação vai-se acumulando quase automaticamente à medida que o projeto avança. Ao mesmo tempo, porém, torna-se também evidente que os bons resultados continuam a depender de estruturas claras, de um planeamento rigoroso e de uma comunicação compreensível.

As ferramentas mudam. Os princípios fundamentais do bom desenvolvimento de software permanecem surpreendentemente constantes.

Da programação ao pensamento sistémico

Durante muitas décadas, a programação propriamente dita esteve no centro das atenções. Quem quisesse desenvolver software tinha de dominar linguagens de programação, aprender a utilizar bibliotecas e escrever grandes quantidades de código por conta própria.

Este panorama está a mudar cada vez mais. O código está a tornar-se, cada vez mais, um recurso que pode ser automatizado. O verdadeiro desafio está a passar a centrar-se na análise, na arquitetura e na compreensão do sistema.

É provável que o programador do futuro dedique menos tempo à programação de funções individuais e muito mais tempo a descrever sistemas, analisar requisitos e coordenar interligações.

A capacidade de formular conceitos complexos de forma compreensível torna-se, assim, mais importante do que nunca. De certa forma, estamos a assistir a um regresso aos verdadeiros fundamentos do desenvolvimento de software. O foco não está na sintaxe de uma linguagem de programação, mas sim na compreensão do problema.

A documentação torna-se um elemento central

Já hoje se observa claramente uma tendência. Enquanto antigamente a documentação era frequentemente vista como um mal necessário, está a tornar-se cada vez mais o elemento central de muitos projetos.

Os sistemas de IA só conseguem trabalhar com o conhecimento que lhes é disponibilizado. Quanto melhor for a documentação de um projeto, mais produtiva poderá ser a colaboração. Isto dá origem a uma mudança interessante.

A documentação já não se destina exclusivamente às pessoas. Torna-se, simultaneamente, uma base de conhecimento para assistentes digitais. Poder-se-ia dizer que os projetos modernos consistem, cada vez mais, em dois níveis. Por um lado, está o software propriamente dito. Por outro lado, está a base de conhecimento, que descreve por que razão esse software existe e como funciona.

É provável que, no futuro, estas duas áreas se tornem cada vez mais interligadas.

Equipas virtuais em vez de ferramentas individuais

A colaboração com a IA também irá continuar a evoluir. Atualmente, muitos programadores ainda trabalham com chats individuais ou modelos isolados. No futuro, provavelmente iremos trabalhar cada vez mais com grupos inteiros de sistemas de IA especializados.

• Um sistema planeia a arquitetura.
• Outro desenvolve funcionalidades.
• Outro realiza testes.
• Outro é responsável pela documentação.

Nesse contexto, o ser humano assume o papel de gestor de projeto e decide o rumo a seguir. Este modelo assemelha-se, já hoje, de forma surpreendentemente semelhante às equipas de desenvolvimento clássicas. A única diferença reside no facto de os membros da equipa serem digitais e poderem alternar entre diferentes tarefas em questão de segundos.

A importância da experiência humana

Apesar de todos os avanços técnicos, uma verdade permanece. A experiência não perde importância. Pelo contrário. Quanto mais poderosas se tornam as ferramentas, mais valiosa se torna a capacidade de tomar boas decisões.

• Uma IA pode fazer sugestões.
• Ela sabe analisar.
• Ela pode apresentar alternativas.
• Ela consegue até encontrar erros.

No entanto, a responsabilidade pelas decisões finais continua a recair sobre o ser humano. Quem compreende os processos, identifica as interligações e é capaz de pensar a longo prazo continuará a ter uma enorme vantagem no futuro.

A verdadeira força não advém apenas da IA. Ela resulta da combinação da experiência humana com a inteligência artificial.

Do chat com IA à memória do projeto

Quem desenvolve projetos de software de grande dimensão com IA rapidamente percebe que o gargalo não é o código, mas sim o conhecimento sobre o projeto. Requisitos, decisões de arquitetura, modelos de dados e discussões acumulam-se frequentemente ao longo de semanas ou meses. É precisamente aqui que surge uma ligação interessante com o tema da exportação de dados. Pois muitas destas informações já estão disponíveis nas conversas anteriores sobre IA. Quem Histórico de chat exportado e arquivado sistematicamente, cria as bases para uma memória de projeto a longo prazo. Em vez de ter de explicar repetidamente decisões importantes, as análises, os conceitos e as soluções anteriores podem permanecer disponíveis de forma permanente. Assim, a partir de conversas individuais, surge passo a passo uma base de conhecimento que pode ser utilizada posteriormente para documentação, desenvolvimento e até mesmo para sistemas de IA próprios. O desenvolvimento de software com IA significa, portanto, não apenas uma programação mais rápida, mas também a construção consciente de um arquivo de conhecimento digital.

A minha conclusão pessoal

Quando reflito sobre as minhas experiências até agora com o desenvolvimento apoiado por IA, há uma coisa que me salta à vista:

A tecnologia não me levou a pensar menos. Levou-me a pensar de forma diferente. Muitas tarefas que antes ocupavam uma parte considerável do meu tempo de trabalho podem hoje ser realizadas muito mais rapidamente. Ao mesmo tempo, a importância da estrutura, do planeamento e da documentação aumentou.

É precisamente no meu projeto atual que se torna cada vez mais evidente o quão valiosos são um contexto bem definido, uma base de conhecimento centralizada e processos claramente definidos. Não é um único prompt que faz a diferença. Não é uma única linha de código. Nem mesmo o sistema de IA utilizado.

O fator decisivo é a capacidade de estruturar o conhecimento e de definir uma orientação clara para um projeto.

Talvez, daqui a alguns anos, olhemos para a época atual como se fosse a introdução da Internet ou dos primeiros computadores pessoais. Muitas possibilidades já são visíveis, mas ainda é difícil avaliar completamente as consequências a longo prazo.

No entanto, uma coisa parece já ser provável hoje em dia. O desenvolvimento de software vai mudar. Não porque as máquinas passem subitamente a fazer tudo sozinhas, mas porque as pessoas passaram a dispor de novas ferramentas que ampliam as suas capacidades. Quem utilizar estas ferramentas de forma sensata poderá trabalhar de forma mais produtiva, aprender mais rapidamente e realizar projetos de maior envergadura do que nunca.

Por isso, o futuro provavelmente não pertence nem apenas ao ser humano, nem apenas à inteligência artificial. Pertence à colaboração entre ambos. E é precisamente essa colaboração que não começa com o código.

Começa com uma ideia, uma estrutura clara e a vontade de experimentar coisas novas.

---

---

Perguntas mais frequentes

1. Será que uma IA já é capaz, hoje em dia, de desenvolver projetos de software completos sozinha?
   Os sistemas modernos de IA são capazes de assumir partes impressionantes de um projeto de software. Podem conceber modelos de dados, gerar código-fonte, desenvolver interfaces, redigir documentação e até criar testes. No entanto, o desenvolvimento de software de sucesso não se resume apenas à escrita de código. É necessário compreender os requisitos, analisar os processos de negócio, tomar decisões e verificar os resultados. Estas tarefas continuam a ser da responsabilidade do ser humano. A IA pode aumentar significativamente a produtividade, mas não substitui a necessidade de conhecimentos especializados, experiência e gestão de projetos.
2. Qual é a IA mais adequada para o desenvolvimento de software?
   Não existe uma resposta única. Os diferentes sistemas têm pontos fortes distintos. Alguns modelos destacam-se especialmente em questões de arquitetura, outros na geração de código ou na documentação. Muitas vezes, o que é decisivo não é tanto a escolha da ferramenta, mas sim a qualidade das informações fornecidas. Mesmo a IA mais potente só consegue trabalhar com o conhecimento que lhe é disponibilizado. Bons processos, documentação clara e um contexto bem definido são, na maioria das vezes, mais importantes do que a designação concreta do modelo.
3. É preciso saber programar para desenvolver software com IA?
   Os conhecimentos técnicos básicos continuam a ser extremamente valiosos. Embora os sistemas de IA possam assumir muitas tarefas de programação, é necessário avaliar os resultados, detetar erros e tomar decisões. Quem compreende bases de dados, arquitetura de software e processos empresariais obtém, em regra, resultados significativamente melhores. Embora o obstáculo à entrada no mercado tenha diminuído consideravelmente, o conhecimento especializado continua a ser uma importante vantagem competitiva.
4. Por que é que o contexto desempenha um papel tão importante no desenvolvimento da IA?
   Inicialmente, a IA não conhece o teu projeto. Não conhece os teus objetivos, nem os teus processos ou estruturas de dados. Sem contexto suficiente, tem de fazer suposições. Quanto mais informações relevantes estiverem disponíveis, melhor poderá desenvolver soluções adequadas. Em muitos projetos, a qualidade dos resultados depende mais do contexto fornecido do que da tarefa em si.
5. Qual deve ser a extensão da documentação de um projeto?
   Uma boa documentação deve ser suficientemente completa para tornar as relações compreensíveis, mas sem se tornar desnecessariamente complicada. São importantes os objetivos do projeto, os modelos de dados, as decisões de arquitetura, as convenções de nomenclatura, as tarefas pendentes e as condições técnicas gerais. O objetivo não é a quantidade máxima de texto, mas a máxima compreensibilidade. Uma documentação clara é muitas vezes mais valiosa do que centenas de páginas de informações desestruturadas.
6. Por que razão se deve dividir projetos de maior dimensão por vários chats de IA?
   À medida que a dimensão dos projetos aumenta, também aumentam a complexidade e a quantidade de informação. Quando todos os temas são tratados num único chat, as informações importantes acabam frequentemente por se perder. A divisão em chats dedicados à arquitetura, ao desenvolvimento, à documentação e aos testes permite definir responsabilidades mais claras e proporcionar uma maior clareza. Ao mesmo tempo, permite aproveitar de forma específica as diferentes perspetivas.
7. O que é um prompt de inicialização e por que é importante?
   Uma mensagem inicial serve como uma introdução padronizada para novas conversas. Descreve o projeto, remete para a documentação, define regras e explica o papel pretendido para a IA. Desta forma, as novas conversas obtêm imediatamente o contexto necessário. Isto poupa tempo, reduz mal-entendidos e garante resultados consistentes ao longo de todo o projeto.
8. Todas as decisões devem ser documentadas?
   Nem todos os pormenores precisam de ser documentados. O que importa, acima de tudo, são as decisões que possam vir a ter repercussões na arquitetura, no modelo de dados ou nos processos. É particularmente importante documentar os fundamentos por trás de uma decisão. Muitas vezes, o problema não é a decisão em si, mas sim o facto de, mais tarde, nos esquecermos das considerações iniciais.
9. Como se pode evitar que a IA desenvolva soluções erradas?
   Não existe segurança a 100 %. A melhor estratégia assenta em vários pilares: fornecer contexto suficiente, dividir as tarefas em passos mais pequenos, verificar os resultados, realizar testes e documentar as decisões importantes. A IA deve ser vista como um apoio, e não como uma autoridade infalível.
10. Qual é a importância de dados reais?
    Os dados de exemplo estão entre as ferramentas mais eficazes que existem. Ajudam a IA a compreender melhor as estruturas, as relações e os casos de utilização típicos. Muitas vezes, alguns conjuntos de dados realistas proporcionam uma compreensão maior do que várias páginas de descrições teóricas. É evidente que a proteção de dados e a confidencialidade devem ser tidas em conta neste contexto.
11. A IA também pode ajudar em projetos de software já existentes?
    Sim. Os sistemas já existentes beneficiam frequentemente do apoio da IA. É possível ampliar a documentação, analisar o código antigo, compreender as estruturas de dados e planear novas funcionalidades. No entanto, é essencial que haja informações suficientes disponíveis sobre o sistema existente. Quanto melhor for a documentação inicial, mais eficaz será a colaboração.
12. Que papel continuará a desempenhar o programador no futuro?
    O papel está a mudar cada vez mais, passando da mera programação para a análise, a arquitetura, a comunicação e o controlo de qualidade. Os programadores estão a tornar-se, cada vez mais, gestores de projeto e arquitetos de sistemas. A capacidade de descrever relações complexas de forma compreensível está a tornar-se cada vez mais importante. A programação continua a ser relevante, mas já não está necessariamente no centro das atenções.
13. Como lidar com respostas contraditórias da IA?
    As contradições são normais. Diferentes conversas ou modelos podem sugerir soluções diferentes. É precisamente por isso que as decisões importantes devem ser sempre tomadas com base em critérios transparentes. As regras de arquitetura, a documentação e os testes ajudam a avaliar objetivamente a qualidade das diferentes propostas.
14. Deve-se conceder à IA acesso a toda a documentação do projeto?
    Em princípio, sim, desde que a proteção de dados, a confidencialidade e as diretrizes da empresa o permitam. Quanto melhor a IA compreender o projeto, tanto mais valiosos serão, na maioria das vezes, os resultados. Especialmente no caso de projetos de longo prazo, vale a pena integrar de forma consistente as fontes de conhecimento centrais e mantê-las atualizadas.
15. De que forma a IA está a alterar os prazos de desenvolvimento dos projetos de software?
    Muitas tarefas podem ser realizadas muito mais rapidamente do que antes. Conceitos, documentação, modelos de dados e primeiros protótipos são frequentemente criados numa fração do tempo que antes era necessário. Ao mesmo tempo, a necessidade de planeamento, testes e controlo de qualidade mantém-se. Por isso, os bons projetos não se tornam automaticamente mais agitados, mas sim, muitas vezes, mais estruturados e produtivos.
16. As pequenas empresas podem beneficiar do desenvolvimento de software baseado em IA?
    São precisamente as empresas de menor dimensão que, muitas vezes, beneficiam de forma mais significativa. Onde antes eram necessárias equipas inteiras, hoje em dia um único programador ou pequenos grupos conseguem concretizar projetos que, no passado, dificilmente teriam sido economicamente viáveis. A IA reduz as barreiras à entrada e aumenta a produtividade, sem exigir grandes investimentos em equipas de desenvolvimento de grande dimensão.
17. Quais são os erros mais comuns cometidos pelos principiantes?
    Os erros mais comuns são a falta de contexto, a ausência de documentação, tarefas demasiado amplas e a confiança cega nos resultados da IA. Muitos utilizadores concentram-se inicialmente em prompts isolados e subestimam a importância da estrutura, da gestão do conhecimento e da organização do projeto a longo prazo.
18. Será que a IA irá substituir completamente o desenvolvimento clássico de software?
    Na situação atual, isso parece improvável. É mais provável que se verifique uma mudança profunda na forma de trabalhar. Muitas atividades técnicas serão automatizadas ou significativamente aceleradas. Ao mesmo tempo, a análise, a comunicação, a arquitetura e o pensamento estratégico ganham importância. O futuro do desenvolvimento de software deverá residir menos na substituição do ser humano e mais numa colaboração cada vez mais estreita entre a experiência humana e a inteligência artificial.

---

---