A pilha exata de entrega de IA que um CPO utiliza para reduzir o retrabalho em 25%
A IA pode gerar código em segundos. Mas, sem arquitetura, apenas ajuda a lançar mais rapidamente a coisa errada. Nesta entrevista, um CPO e Diretor de Engenharia partilha o sistema de IA orientado pela arquitetura que utiliza para reduzir para metade o tempo de prototipagem, diminuir o retrabalho em 25% e conceber salvaguardas para um ciclo de vida de desenvolvimento de software (SDLC) potenciado por IA.
Yurii Lozinskyi
O CPO e Diretor de Engenharia da Verysell
Liderança em IA: A IA transfere a gestão de projetos da coordenação para a conceção de sistemas, reduzindo as tarefas manuais através da integração da IA.
Papel da arquitetura: Uma arquitetura robusta evita o caos na entrega de IA, alinhando o trabalho gerado por IA com os padrões de qualidade e os objetivos.
Eficiência da prototipagem: A IA orientada pela arquitetura reduz drasticamente os custos, acelerando os protótipos desde a ideia até ao modelo funcional em poucos dias.
Valor dos engenheiros: A IA aumenta o valor dos engenheiros seniores ao melhorar a conceção arquitetural e reduzir a programação aleatória.
Mudança na gestão de projetos: As funções futuras de gestão de projetos utilizarão a IA para a coordenação, concentrando-se mais na conceção, na estratégia e na governação.
Yurii Lozinskyi é o CPO e Diretor de Engenharia da Verysell AI, onde lidera a implementação de soluções de IA. Com 25 anos de experiência, transformar iniciativas de software e IA em resultados empresariais mensuráveis é a sua especialidade.
Por isso, sentámo-nos com ele para saber como o faz. Eis o que nos disse.
Garantir que a IA não é apenas um brinquedo vistoso
Sou um líder de produto e engenharia que vive no ponto de encontro entre sistemas de IA, desenvolvimento de software e realidade empresarial. Passei mais de 15 anos a desenvolver e lançar soluções nos setores bancário, segurador, das plataformas ITSM/MSP, do retalho e dos cuidados de saúde. E, de alguma forma, continuo a voltar ao setor dos seguros, porque é aí que a complexidade e o impacto são ambos elevados.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Atualmente, não dirijo projetos no sentido tradicional. Concebo a forma como os projetos devem ser executados e tento manter-me envolvido durante a implementação. Isso significa modelos operacionais, padrões de implementação potenciados por IA e roteiros de validação de hipóteses em várias equipas e com vários clientes.
Em suma, o meu trabalho diário consiste em garantir que a IA não é um brinquedo vistoso à margem, mas faz parte da forma como o trabalho é definido, executado e governado de ponta a ponta.
Como a IA transforma a gestão de projetos, passando da coordenação para a conceção de sistemas
A liderança da implementação está a passar da gestão de calendários para a conceção de sistemas. Passo muito menos tempo em reuniões de acompanhamento ou a redigir manualmente artefactos que as máquinas agora produzem em segundos. Se a IA me puder ajudar a escrever a primeira versão de um plano ou de um resumo, terei todo o gosto em deixá-la fazê-lo.
Muitos gestores de projetos ainda passam atualmente 40–60% do seu tempo a solicitar atualizações sobre o estado das tarefas, a elaborar relatórios manualmente, a identificar riscos básicos e a transferir informação entre ferramentas e pessoas. Num ambiente aumentado por IA, esse valor desce para menos de 10–15%, uma vez que agentes integrados tratam das atualizações, dos resumos, dos lembretes e das escaladas simples no Jira/Linear, Slack/Teams e nos documentos.
A contrapartida é que o meu trabalho subiu um nível: preocupo-me com restrições, critérios de aceitação, limites de segurança e ciclos de feedback. Por outras palavras, concebo os "trilhos" nos quais as pessoas e os agentes de IA operam.
Tenho uma inclinação para a arquitetura: utilizo o modelo C4 e a ISO/IEC 25010 como estrutura para os Documentos de Visão da Arquitetura e, depois, utilizo-os como instruções. Essa é a parte divertida — tratar a arquitetura como uma API para a IA. Os seus documentos de arquitetura não são material esquecido numa prateleira, mas combustível para um ciclo de vida de desenvolvimento de software (SDLC) potenciado por IA. Voltarei a este tema dentro de instantes.
A IA torna trivial avançar rapidamente, por isso o meu papel é garantir que avançamos rapidamente na direção certa. Assim, em vez de perguntar: "Quem está a fazer o quê esta semana?", pergunto: "O nosso sistema torna difícil lançar rapidamente a coisa errada?"
A IA torna trivial avançar rapidamente, por isso o meu papel é garantir que avançamos rapidamente na direção certa.
Porque é que a arquitetura evita o caos de implementação provocado pela IA
Gosto do C4, da ISO 25010 e dos Documentos de Visão da Arquitetura porque constituem uma espinha dorsal para integrar a IA na implementação. Sem essa espinha dorsal, a IA pode rapidamente tornar-se mais uma fonte de caos na implementação.
Especificamente:
- O C4 fornece à IA um mapa do sistema. Em vez de "Escreve apenas algum código", podemos dizer: "Neste contexto e neste contentor, tendo em conta estas interfaces, implementa esta alteração." Isto mantém o trabalho gerado pela IA dentro de limites arquiteturais claros.
- A ISO 25010 define o que é "bom" para além de "compila". Traduzimos os seus atributos de qualidade em cenários concretos — desempenho, segurança, manutenibilidade, fiabilidade — e incorporamo-los nas instruções e nos critérios de aceitação. A IA gera então provas de conceito e testes alinhados com expectativas de qualidade explícitas, e não apenas com a funcionalidade.
- Os Documentos de Visão da Arquitetura integram tudo. Ligam os objetivos empresariais, as perspetivas C4 e os cenários de qualidade ao estilo ISO numa única narrativa, tanto para as pessoas como para a IA. Para as pessoas, servem como artefacto de alinhamento. Para a IA, fornecem a principal fonte de contexto para gerar código, testes e documentação.
Em conjunto, transformam a IA de um superpoder aleatório num componente controlado de um SDLC potenciado por IA, com limites claros, rastreabilidade e uma compreensão partilhada do que pretendemos desenvolver.
Como reduzir o custo de errar com protótipos de IA orientados pela arquitetura
Eis um exemplo. Tínhamos uma funcionalidade de correspondência com IA que, no “mundo antigo”, teria demorado aproximadamente duas semanas a passar da ideia a um protótipo clicável.
Em vez de começarmos com tickets do Jira e prompts improvisados, escrevemos primeiro um Documento de Visão da Arquitetura curto. Desenhámos diagramas ao estilo C4: contexto do sistema, contentores envolvidos, componentes principais, além de alguns cenários de qualidade inspirados na ISO 25010 (por exemplo, latência, auditabilidade e tratamento de erros).
Depois, tratámos essa arquitetura como uma API para a IA:
- Introduzimos o Documento de Visão e os excertos C4 no nosso assistente de programação como única fonte de verdade para os prompts.
- Pedimos-lhe que gerasse a estrutura inicial, a lógica do fluxo principal e os primeiros testes dentro dos contentores e interfaces especificados.
Não está a pedir à IA “Escreve-me algum código”, mas sim “Implementa esta interação específica com estas restrições e estes atributos de qualidade”. É um jogo completamente diferente. E produziu uma PoC coerente em alguns dias, em vez de termos de programar tudo manualmente de raiz.
Os engenheiros continuaram a rever e a corrigir as coisas, mas:
- O tempo entre “devíamos experimentar isto” e “as partes interessadas conseguem percorrer um protótipo funcional” passou de cerca de dez dias úteis para três ou quatro. É quase injusto o quão rapidamente se consegue obter um protótipo credível quando a arquitetura fundamenta os prompts, em vez de estes se basearem em desejos vagos.
- Registámos menos 20–25% de ciclos de retrabalho, porque o código gerado pela IA já respeitava os limites e padrões incorporados na arquitetura.
- Os engenheiros comunicaram passar cerca de 20% menos tempo em código repetitivo e código de ligação, eliminando efetivamente a necessidade de uma função separada de “engenheiro de integração”.
- A cobertura de testes para essa parte foi superior logo na primeira tentativa, uma vez que o assistente utilizou os cenários de qualidade documentados para sugerir testes de casos-limite que provavelmente não teríamos escrito tão cedo.
Por outras palavras, quando tornámos a arquitetura explícita e estruturada, a IA deixou de se comportar como um preenchimento automático inteligente e começou a agir mais como um engenheiro júnior que compreende verdadeiramente o mapa do sistema, escreve documentação excelente e nunca dorme.
E, mais importante ainda, reduziu o custo de errar, que é precisamente o que se pretende em domínios complexos.
Porque é que a IA torna os engenheiros seniores mais valiosos, e não menos
Apesar do que possa pensar, a IA torna os engenheiros seniores mais valiosos, e não menos.
Se integrar a IA numa arquitetura fraca e com pouco discernimento, obterá uma confusão mais rápida. Coloque-a sob a orientação de um arquiteto forte e, de repente, um sénior consegue explorar cinco arquiteturas antes do almoço e ainda ter tempo para falar com as partes interessadas.
A IA colmata algumas lacunas de competências, mas amplia a diferença entre programar ao acaso e conceber de forma intencional.
Se integrar a IA numa arquitetura fraca e com pouco discernimento, obterá uma confusão mais rápida. Coloque-a sob a orientação de um arquiteto forte e, de repente, um sénior consegue explorar cinco arquiteturas antes do almoço e ainda ter tempo para falar com as partes interessadas.
Adeus, analista de negócio — bem-vindo, especialista no domínio.
Que tarefas de entrega devem ser automatizadas primeiro com IA
Atualmente, as partes do trabalho de entrega mais propícias à automatização são as atividades “ricas em contexto, repletas de padrões e com pouco ego”:
- Tal como mencionado, gerar código e testes de PoC a partir de Documentos de Visão da Arquitetura e especificações C4/ISO 25010
- Redigir registos de decisões, opções de conceção e listas de riscos
- Transformar discussões confusas do Slack em algo que o seu futuro eu consiga ler sem chorar
A IA é excelente a fazer sugestões; é péssima a assumir responsabilidades. É aqui que os humanos continuam a dominar por completo:
- Definir o problema
- Ponderar o risco face à rapidez
- Lidar com limites regulamentares e éticos
- Decidir quando algo que está “tecnicamente correto” continua a ser a coisa errada a lançar
O ponto ideal, neste momento, é comprimir os ciclos iniciais de descoberta e conceção. Os agentes são bons a transformar uma especificação coerente em caminhos plausíveis. Ainda não compreendem quando um caminho está errado do ponto de vista político, ético ou estratégico, por isso os humanos continuam firmemente no comando.
Porque devem os gestores de projeto dar prioridade aos ciclos de retorno em vez da formalidade
A gestão de projetos tradicional inclui frequentemente muitos rituais sem um propósito claro. Estou a afastar-me disso em direção a sistemas que dão prioridade ao retorno em vez da formalidade.
Na prática, isso significa:
- Menos planos monolíticos; mais hipóteses pequenas e testáveis
- Menos grandes reuniões de acompanhamento; mais atualizações assíncronas resumidas automaticamente pela IA
- Menos documentos de requisitos excessivamente extensos; mais Documentos de Visão da Arquitetura vivos, sobre os quais tanto os humanos como a IA podem agir
Continuamos a dar importância a datas, orçamentos e riscos. Mas deixamos a IA tratar da contabilidade administrativa para que os humanos se possam concentrar na conceção, nas decisões e na realidade das partes interessadas.
A ironia é que, quando se remove metade do ritual, as pessoas respeitam mais a estrutura que resta.
A ironia é que, quando se remove metade do ritual, as pessoas respeitam mais a estrutura que resta.
Como as integrações de IA simplificam a entrega de projetos no GitHub e em CI/CD
De uma perspetiva técnica, “trabalhar de forma leve” significava integrar a IA diretamente no repositório e nos ambientes, em vez de simplesmente adicionar outro painel.
Especificamente, integrámos um assistente de programação com IA chamado Codex nos nossos repositórios GitHub e no processo de CI/CD. Os engenheiros trabalham no seu IDE habitual, mas o assistente consegue ver a estrutura do repositório e fazer tudo o que mencionei acima a partir de diagramas de arquitetura ao estilo C4 e de um Documento de Visão da Arquitetura. A cerca de $20 USD por engenheiro por mês, isto é mais barato do que praticamente qualquer outra alavanca de produtividade que se possa utilizar.
Além disso, utilizamos uma automatização simples da implementação (processos baseados no GitHub), para podermos implementar alterações assistidas por IA num ambiente de protótipo dedicado com um único clique.
Até a geração de instruções é parcialmente automatizada: um modelo moderno da classe GPT (GPT-5.2) consegue gerar instruções estruturadas para ferramentas como o Eraser a partir dos nossos Documentos de Visão da Arquitetura.
A chave é que tudo isto funciona dentro de salvaguardas padrão: os engenheiros continuam a rever cada pedido de integração, o CI/CD continua a ser executado e nada chega à produção sem aprovação humana. A IA acelera as partes aborrecidas; os humanos continuam responsáveis pela conceção, pelo risco e pela decisão final.
Porque é que os protótipos de IA redefinem os rituais de entrega
Tudo isto teve um grande impacto nos nossos rituais de entrega.
Definir o âmbito costumava ser: “Vamos falar durante horas e depois escrever um documento que todos iremos ignorar.” Agora é: “Vamos chegar rapidamente a um protótipo e discutir com algo interativo.”
Começamos com um resultado de alto nível, registamo-lo num Documento de Visão da Arquitetura, esboçamos vistas C4 e, em seguida, utilizamos a IA para gerar uma PoC ou, pelo menos, uma simulação realista. De repente, todos têm uma opinião — porque existe algo concreto a que reagir.
Por outras palavras, alcançamos o alinhamento em torno do comportamento, não de listas de tópicos.
Validamos utilizando uma combinação de testes gerados por IA (ótimos para cobertura e regressão) e cenários concebidos por humanos (ótimos para o discernimento e para casos-limite invulgares).
E transferimos a gestão da execução de “atribuir tarefas” para “conceber fluxos”: quem ou o que deve ver esta tarefa a seguir e com que contexto?
Como é uma pilha de entrega de IA simples
A minha pilha é opinativa, mas simples.
Para a arquitetura e o alinhamento, utilizo diagramas ao estilo C4 e Documentos de Visão da Arquitetura, elaborados em ferramentas como o Eraser. Isto facilita a sua iteração diante das pessoas e, depois, a sua utilização como entrada para a IA.
Para as especificações, prefiro documentos baseados primeiro em texto, que descrevam a intenção, as restrições e os atributos de qualidade de uma forma que um LLM consiga compreender.
Do lado da engenharia, utilizo IDE modernos com uma forte assistência de IA e ferramentas como o Claude Code e o Codex para gerar implementações de PoC e testes diretamente a partir desses artefactos de arquitetura. Deliberadamente, ainda não deleguei funcionalidades completas de produção à IA. Esta redige, cria estruturas iniciais e apresenta propostas. Os engenheiros — os verdadeiros — continuam a decidir o que entra em produção.
É importante salientar que cada uma destas ferramentas deixou de ser uma ilha. Estão agora ligadas a um SDLC alimentado por IA: os requisitos, a arquitetura, a programação, os testes e até a governação têm todos uma camada de assistência.
Na prática, espero que esta mudança permita obter ganhos de produtividade de aproximadamente 18-25% em toda a entrega. Mas, para ser claro, esse número depende muito do ponto de partida de uma organização — da maturidade, dos processos existentes e da disciplina de arquitetura.
Como a adoção seletiva de ferramentas melhora a entrega de IA
Ao longo do último ano, começámos deliberadamente a substituir e testar ferramentas, em vez de tentarmos “ativar a IA” em tudo ao mesmo tempo.
Do lado da entrega, introduzimos o Miro para a elaboração ligeira de roteiros e sessões de trabalho de arquitetura, mas apenas como projeto-piloto em alguns projetos pequenos. O nosso objetivo era avaliar até que ponto os quadros do Miro, combinados com resumos gerados por IA, poderiam substituir apresentações longas e documentos de alinhamento manuais. Os primeiros sinais são positivos, mas ainda precisamos de finalizar e expandir a abordagem antes de esta se tornar a opção predefinida.
Para a documentação e as especificações, mantivemos uma ferramenta de documentação baseada primeiro em texto para os Documentos de Visão da Arquitetura. Acrescentámos assistência de IA sobre essa ferramenta com GPTs personalizados muito simples — retirando discretamente documentos de especificações grandes e estáticos que não estávamos a manter e que não se traduziam bem em instruções.
Já referi isto acima, mas, do lado da engenharia, adicionámos o Codex como assistente de programação com IA, integrado no nosso repositório Git e no pipeline de CI, para criar estruturas iniciais de PoC e gerar testes, mantendo simultaneamente os nossos IDE e ferramentas de implementação existentes. Por outras palavras, ainda não estamos a substituir a pilha. Acrescentamos a IA sobre a pilha, onde esta poupa claramente tempo, começando por projetos-piloto controlados antes de implementar qualquer alteração em toda a empresa.
Ainda não estamos a substituir a pilha. Acrescentamos a IA sobre a pilha, onde esta poupa claramente tempo, começando por projetos-piloto controlados antes de implementar qualquer alteração em toda a empresa.
Para onde vai a gestão de projetos nos próximos cinco anos
Daqui a cinco anos, o “gestor de projetos”, enquanto função puramente de coordenação, terá em grande parte desaparecido na área tecnológica. O trabalho continuará a existir, mas os agentes de IA incorporados tratarão da maior parte da coordenação, do acompanhamento e dos relatórios dentro das suas ferramentas.
As pessoas anteriormente conhecidas como PMs subirão na hierarquia para conceber SDLC alimentados por IA e modelos de governação, ou mudarão lateralmente para funções de produto e estratégia.
Os painéis de desempenho dos PMs deixarão de se centrar em “dentro do prazo / dentro do orçamento” e passarão a focar-se num pequeno conjunto de métricas do sistema que estes influenciam ativamente: tempo de entrega das alterações, taxa de defeitos que chegam à produção, latência das decisões, volume de experiências e níveis de confiança das partes interessadas. A IA fará a maior parte da contagem. Os PMs serão responsáveis por garantir que esses números evoluem na direção certa — não por terem acompanhado mais tarefas, mas por terem concebido melhores formas de trabalhar.
Os PMs que permanecerem na “gestão de estados” serão discretamente substituídos por robôs que fazem esse trabalho 24 horas por dia, 7 dias por semana, e não se importam de atualizar seis painéis ao mesmo tempo.
Porque os gestores de produto devem tratar a IA como um colega de equipa, não como um tema a aprender
O meu conselho: parem de tentar “aprender IA” como se fosse uma nova estrutura e tratem-na como um novo tipo de colega de equipa, com pontos fortes e limitações específicos. Nós chamamos-lhe, a brincar, "gptBuddy".
Escolham um fluxo de trabalho, uma equipa e uma métrica que sejam importantes, e realizem uma experiência rigorosa. Se não virem uma melhoria significativa, alterem a configuração ou parem.
O verdadeiro valor da IA parece aborrecido para quem observa de fora. Não é o tipo de coisa de ficção científica que as pessoas esperam. São ganhos pouco glamorosos e cumulativos: geração de testes, limpeza de documentação, criação de estruturas, exploração de variantes, e por aí fora.
Ao mesmo tempo, desviem o olhar das ferramentas e delineiem como seria um SDLC com recurso a IA para a vossa organização. Se não o fizerem, outra pessoa fá-lo-á — e as respetivas equipas avançarão mais depressa, com menos reuniões e menos drama.
Parem de tentar “aprender IA” como se fosse uma nova estrutura e tratem-na como um novo tipo de colega de equipa, com pontos fortes e limitações específicos.
Acompanhe
Pode acompanhar Yurii Lozinskyi no LinkedIn e no Dev.to, onde partilha os seus conhecimentos técnicos sobre IA, engenharia, produto e entrega. E visite a Verysell AI.
Em breve haverá mais entrevistas com especialistas no The Digital Project Manager!
