---
title: "Agora construímos em três meses o que levava três anos. É aí que começa a parte difícil. | Guardian360"
description: "Em três meses, um punhado de pessoas reconstruiu a nossa plataforma Lighthouse com mais funcionalidades novas do que costumávamos entregar em três anos. A IA removeu a nossa restrição mais antiga e expôs uma nova: quando construir deixa de ser escasso, a implementação passa a sê-lo."
url: https://guardian360.net/pt/blog/we-now-build-in-three-months-what-took-us-three-years/
locale: en
source: guardian360.net
---
[← Todos os artigos](https://guardian360.net/pt/blog/)

Opinião

# Agora construímos em três meses o que levava três anos. É aí que começa a parte difícil.

Por Jan Martijn Broekhof · 12 de outubro de 2026

Algo mudou na nossa equipa de desenvolvimento este ano, e ainda me estou a habituar. Nos últimos três meses, um punhado de pessoas na Guardian360 reconstruiu a nossa plataforma Lighthouse e estendeu-a com mais funcionalidades novas do que costumávamos entregar em mais de três anos. Não contratámos uma equipa maior e não encontrámos um orçamento maior. O desenvolvimento de software assistido por IA simplesmente removeu a restrição que moldou todas as decisões de roadmap que alguma vez tomámos: a escassez de pessoas e de ferramentas.

Isso parece uma boa notícia, e em grande medida é. Mas expôs uma nova restrição, e não está onde eu esperava encontrá-la. Quando construir deixa de ser escasso, a implementação passa a sê-lo. Os nossos parceiros, os managed service providers (MSPs) que entregam a nossa plataforma de cibersegurança aos seus clientes, não conseguem absorver funcionalidades novas à velocidade a que agora as conseguimos produzir. E duas outras questões não me largam. Será que software construído tão depressa é de facto seguro? E poderá mais funcionalidade corroer a simplicidade que sempre nos distinguiu?

## O que muda quando construir deixa de ser o estrangulamento?

Durante a maior parte da história da Guardian360, o nosso roadmap era uma lista de coisas que queríamos construir, ordenadas pelo que podíamos dar-nos ao luxo de construir. Os parceiros pediam determinadas funcionalidades durante anos, e muitos deles tinham de esperar.

Hoje, os nossos programadores trabalham lado a lado com IA para a geração de código, para os testes e para a documentação. Começámos com o Claude, o modelo da Anthropic, e estamos cada vez mais a mover esse trabalho para o Hermes. O Hermes não é um modelo, mas uma camada que construímos nós próprios. Usa modelos de linguagem de grande dimensão em código aberto para alimentar aquilo a que chamamos um cérebro da empresa, e facilita os agentes de IA que nos ajudam numa ampla variedade de tarefas. O Hermes, e os modelos em código aberto que utiliza, correm no nosso próprio cluster de servidores nos Países Baixos, e isso é tanto uma questão de princípio como de ordem prática. O Claude nunca teve acesso a dados de clientes na nossa plataforma, porque os nossos acordos de parceria não permitem que esses dados saiam da EU. Mover mais do nosso trabalho para infraestrutura que controlamos segue a mesma lógica.

Estamos longe de ser uma exceção. De acordo com o 2026 GenAI Code Security Report da Veracode, a IA gera atualmente cerca de metade de todo o código submetido. A questão já não é se as equipas de software usam IA, mas o que acontece a seguir.

## Será que software construído com IA é de facto seguro?

Esta é a preocupação que levo mais a sério, e suspeito que seja a primeira pergunta que muitos leitores vão fazer. A investigação dá poucos motivos para conforto. A Veracode descobriu que cerca de 44 por cento das tarefas de geração de código por IA introduziram uma vulnerabilidade de risco, com uma taxa média de aprovação de segurança de 56 por cento, quase sem alteração face aos 55 por cento do seu primeiro relatório. O estudo de abril de 2026 da IOActive analisou quase 20.000 amostras de código e concluiu que 31,6 por cento das amostras geradas por IA eram totalmente exploráveis; nenhum modelo produziu resultados inteiramente seguros.

O que me preocupa ainda mais é a distância entre a perceção e a realidade. A Cloud Security Alliance reporta que mais de 75 por cento dos programadores num inquérito acreditavam que o código gerado por IA é mais seguro do que o código escrito por humanos, ao passo que 56 por cento admitiam que este introduz frequentemente problemas de segurança. A velocidade dá a sensação de competência. Não é.

A conclusão da IOActive é que as organizações têm de tratar o resultado da IA como input não fiável e impor uma revisão de segurança obrigatória antes da implementação. É exatamente assim que trabalhamos: a IA pode escrever o código, mas cada alteração é revista por uma pessoa que a compreende antes de chegar a produção. Estamos agora a dar um passo em frente, virando o nosso próprio pentesting por IA contra nós mesmos, incluindo a análise crystal box do nosso próprio código-fonte, em que os agentes de teste têm acesso total ao código. Fazemos essa análise com vários modelos diferentes, para que os pontos cegos de um modelo tenham menos probabilidade de passar despercebidos.

O mesmo princípio molda o pentesting por IA que estamos a levar aos nossos parceiros, em que a IA realiza o teste e o consultor do parceiro assina-o. Os programadores parecem partilhar este instinto. No Developer Survey de 2026 da Stack Overflow, quase metade dos inquiridos disse confiar no resultado da IA quando o consegue verificar, ao passo que apenas 6,6 por cento confiariam uma decisão importante à IA.

## Porque é que mais funcionalidades não significam automaticamente mais valor?

A segunda preocupação é menos técnica, mas igualmente real. A No Jitter descreveu recentemente uma “enxurrada de funcionalidades” no software de comunicações, em que os fornecedores lançam centenas de novas funcionalidades por ano enquanto a adoção fica para trás. Os benchmarks da Pendo sugerem que cerca de 80 por cento das funcionalidades construídas nunca atingem uma adoção significativa, e que 6,4 por cento das funcionalidades geram 80 por cento de todos os cliques. Esse padrão existia muito antes da IA. A IA simplesmente torna mais barato repeti-lo.

A Guardian360 sempre tentou oferecer uma plataforma que um MSP consiga explicar a um membro de um conselho de administração em poucos minutos. Cada funcionalidade que acrescentamos torna isso mais difícil. O custo de construir uma funcionalidade colapsou; o custo de a compreender não.

Os nossos parceiros já carregam bastante complexidade. Uma investigação da CRN, publicada pelo fornecedor de segurança Coro, concluiu que os MSPs gerem entre 6 e 20 ou mais fornecedores para entregar serviços de segurança, avaliam a integração entre essas ferramentas em apenas 6,2 em 10, e que apenas 7 por cento estão satisfeitos com o retorno das suas ferramentas de segurança. A última coisa de que precisam de nós é de mais uma camada de complexidade, por mais bem-intencionada que seja.

## Para onde se moveu o estrangulamento?

A investigação DORA da Google oferece uma lente útil. O seu relatório de 2025 concluiu, pela primeira vez, uma relação positiva entre a adoção de IA e o throughput de entrega, mas a adoção de IA continuava correlacionada com menor estabilidade de entrega: mais falhas de alteração, mais retrabalho e recuperação mais longa. A DORA concluiu também que a IA tende a espelhar e a amplificar os traços organizacionais existentes, para melhor e para pior.

Eu estenderia essa observação para além da equipa de desenvolvimento. Uma funcionalidade só cria valor quando um parceiro a compreende, a configura, a explica a um cliente e constrói um serviço à sua volta. Essa cadeia corre à velocidade humana. A IA acelera o primeiro elo e deixa o resto intacto, o que significa que a fila simplesmente desce a jusante, para os nossos parceiros e os seus clientes.

O inquérito da Stack Overflow aponta na mesma direção: as pessoas confiam naquilo que conseguem verificar. Um parceiro que nunca viu uma funcionalidade a funcionar não a consegue verificar, não a consegue explicar e não a vai vender.

## Devemos simplesmente abrandar?

Alguns parceiros defenderiam exatamente isso: parem por uns tempos, estabilizem, deixem-nos apanhar o atraso. É um argumento justo e em parte concordo com ele. Um fornecedor que lança mais depressa do que o seu canal consegue acompanhar está a otimizar para a sua própria satisfação, não para a dos seus parceiros.

No entanto, abrandar artificialmente desperdiçaria uma oportunidade que os pequenos fornecedores europeus raramente têm. A resposta, acredito, é disciplina e não travagem. Isso significa decidir o que não lançar, tratar a simplicidade como um requisito de design e não como uma reflexão posterior, e envolver os parceiros antes de uma funcionalidade estar terminada, e não depois.

Parte dessa disciplina está incorporada na própria plataforma. Estamos a introduzir workspaces: em vez de apresentar todas as funcionalidades num único ecrã, agrupamos a funcionalidade por tarefa, para que um parceiro veja apenas aquilo que o trabalho em mãos exige. A interface guiada por IA leva isto mais longe. Páginas, relatórios e navegação passam a ser definições em vez de código, e um agente constrói a vista que um utilizador pede dentro dos limites do seu papel. Isto já não é um conceito. Vamos mostrá-lo a funcionar a 3 de novembro, e queremos feedback honesto dos nossos parceiros sobre se de facto os ajuda.

Há uma segunda forma de manter a complexidade baixa: deixar a plataforma fazer mais do trabalho. Hoje, o Lighthouse diz-te o que poderia ser melhorado. No futuro, também o vai corrigir, onde o parceiro e o seu cliente o permitirem. Cada tarefa que a plataforma assume é uma tarefa que um parceiro já não tem de aprender, explicar ou agendar.

## Porque é que estamos a abrir as portas da sala de controlo

O logótipo da Guardian360 contém um farol, e a metáfora nunca me pareceu tão certeira. Um farol só é útil se a sua luz chegar à costa. Podemos construir a luz mais brilhante do mundo, mas são os nossos parceiros que a levam aos seus clientes.

É por isso que vamos receber [“Uma vista da sala de controlo”](https://guardian360.net/pt/a-view-from-the-control-room/) na terça-feira, 3 de novembro de 2026, das 09:30 às 13:00, no Van der Valk Hotel em Woerden. Vamos mostrar o que construímos, a correr ao vivo em vez de em slides, e dar um primeiro vislumbre do que a Guardian360 vai entregar em 2027. A participação é gratuita, há lugar para cerca de 50 convidados, e as inscrições estão abertas até 30 de outubro. Mais do que as demonstrações, valorizo a conversa. Prefiro ouvir a 3 de novembro que algo é demasiado complexo do que descobri-lo nos números de adoção daqui a um ano.

## Então, qual é agora a tua restrição?

Se construir também já não é a tua restrição, e para muitos MSPs esse momento está mais perto do que parece, qual é? Para nós, a resposta é clara. Quando construir deixa de ser escasso, a implementação passa a sê-lo. É aí que começa a parte difícil, e é um trabalho que só podemos fazer em conjunto com os nossos parceiros.

## Fontes

- Veracode: 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up (July 2026)
- IOActive: The Security Gap in AI-Generated Code (April 2026)
- Cloud Security Alliance: Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale (April 2026)
- IT Brief UK: Stack Overflow survey finds developers wary of AI tools (October 2026)
- Google Cloud / DORA: Announcing the 2025 DORA report: State of AI-assisted Software Development
- No Jitter: Vendors ship thousands of features, users adopt dozens (July 2026)
- Coro / CRN: Your Tool Stack Is Eating Your Margins (August 2026)
- Guardian360: A view from the control room, event 3 November 2026