Explore como o AMP, o agente de programação inovador da Sourcegraph, está remodelando o cenário de desenvolvimento em IA ao adotar iteração rápida, raciocínio autônomo e agentes com chamada de ferramentas — e por que as ferramentas tradicionais estão se tornando obsoletas.
O cenário dos agentes de programação em IA está passando por uma disrupção sem precedentes. O que era inovador há seis meses já está ultrapassado. O GitHub Copilot, que foi referência em desenvolvimento assistido por IA, já foi superado por ferramentas mais recentes. O Cursor dominou o mercado como a startup de crescimento mais rápido da história, mas logo enfrentou concorrência de soluções ainda mais avançadas. Neste ecossistema em rápida evolução, a Sourcegraph tomou uma decisão estratégica ousada: em vez de melhorar incrementalmente o produto Cody existente, lançou o AMP — um novo agente de programação construído do zero para estar na vanguarda das capacidades em IA.
Este artigo explora a filosofia, a arquitetura técnica e a estratégia de negócios por trás do AMP, trazendo insights de conversas com a equipe responsável por esta ferramenta revolucionária. Vamos analisar por que abordagens tradicionais de desenvolvimento de produto fracassam na era do avanço acelerado da IA, como agentes com chamada de ferramentas diferem fundamentalmente dos primeiros assistentes de programação em IA e como será o futuro do desenvolvimento autônomo. Acima de tudo, entenderemos por que “o imperador está nu” — por que produtos consolidados, com posições aparentemente inabaláveis no mercado, podem se tornar irrelevantes quase da noite para o dia quando a tecnologia subjacente muda.
{{ youtubevideo videoID=“b4rOVZWLW6E” provider=“youtube” title=“AMP: O Imperador Está Nu – Por Que Agentes de Programação em IA Estão Revolucionando Ferramentas para Desenvolvedores” class=“rounded-lg shadow-md” }}
A evolução do desenvolvimento assistido por IA seguiu uma trajetória clara, cada geração se apoiando na anterior, mas mudando fundamentalmente a forma como desenvolvedores interagem com inteligência artificial. Para compreender a importância do AMP, precisamos primeiro entender o que distingue um agente de programação das formas iniciais de assistência por IA. A jornada começou com o GitHub Copilot, que trouxe sugestões e autocompletar de código diretamente para os editores dos desenvolvedores. O Copilot foi revolucionário por inserir a IA no fluxo de trabalho de desenvolvimento de forma não intrusiva, oferecendo sugestões à medida que o programador digitava. No entanto, o Copilot tinha limitações fundamentais — sugeria código, mas não conseguia executar tarefas complexas, multifásicas ou interagir com o ambiente de desenvolvimento de forma mais ampla.
A geração seguinte trouxe ferramentas como Cursor e Windsurf, que seguiram um caminho diferente criando forks de IDEs que integravam IA de maneira mais profunda ao ambiente de desenvolvimento. Essas ferramentas mostraram que capacidades parcialmente agentizadas — em que a IA pode realizar operações mais complexas dentro do IDE — podiam aumentar significativamente a produtividade do desenvolvedor. Demonstraram que desenvolvedores estavam dispostos a migrar todo o ambiente de desenvolvimento se as capacidades de IA fossem suficientemente avançadas. Mas mesmo essas ferramentas tinham restrições: eram interativas, exigiam entrada e aprovação do desenvolvedor a cada etapa, e não conseguiam operar verdadeiramente de forma autônoma.
Um agente de programação, por outro lado, tem uma arquitetura fundamentalmente diferente. Um agente consiste em três componentes principais: um modelo de linguagem (geralmente de ponta, como Claude 3.5), um prompt de sistema que define o comportamento e as restrições do agente, e um conjunto de ferramentas com prompts associados que descrevem o que cada ferramenta pode fazer. A diferença crucial é que agentes podem operar com permissões explícitas para interagir com sistemas externos — sistemas de arquivos, editores de código, sistemas de controle de versão e mais. Isso significa que um agente pode raciocinar autonomamente sobre um problema, decidir quais ferramentas usar, executá-las, observar os resultados e iterar até que a tarefa seja concluída. Isso é fundamentalmente mais poderoso do que qualquer abordagem anterior, pois permite comportamento realmente autônomo, não apenas sugestões aprimoradas ou assistência interativa.
O cenário tecnológico entrou em uma fase de instabilidade sem precedentes. O que era de ponta há dezoito meses hoje já soa primitivo. O GitHub Copilot, lançado em 2021, foi realmente revolucionário — representou a primeira aplicação mainstream de grandes modelos de linguagem ao desenvolvimento de software. Mas hoje, muitos desenvolvedores sequer o consideram entre as melhores opções de programação assistida por IA. Isso não ocorreu porque o Copilot piorou; é porque a tecnologia subjacente avançou tão rapidamente que toda a categoria mudou. Isso cria um desafio profundo para empresas estabelecidas: como manter um produto de sucesso enquanto o chão sob seus pés está sempre mudando?
O desenvolvimento de produto tradicional assume uma base relativamente estável. Você encontra o product-market fit, escala o produto, implanta práticas de engenharia adequadas, adiciona recursos corporativos, estabelece contratos de longo prazo com clientes. Esse manual funcionou por décadas porque a tecnologia tipicamente evolui gradualmente. Mas na era atual da IA, essa abordagem é prejudicial. Se você otimiza seu produto para escala e estabilidade, fica lento. Se fica lento, perde a próxima onda de inovações. Quando você finalmente adiciona recursos corporativos e certificações de segurança, um novo modelo já foi lançado e tornou a sua abordagem obsoleta.
A Sourcegraph enfrentou exatamente esse dilema com o Cody. Cody era um produto bem-sucedido com clientes corporativos, contratos de longa duração e receita significativa. Mas era fortemente integrado à plataforma Sourcegraph, e assim restrito pelos ciclos de lançamento da plataforma. Quando o Claude 3.5 Sonnet foi lançado e a equipe percebeu que poderia construir algo fundamentalmente diferente — um agente com chamada de ferramentas e raciocínio autônomo — enfrentaram uma escolha: tentar adaptar essas capacidades ao Cody ou começar do zero. Optaram por começar do zero, e essa decisão revela um insight crucial sobre como competir em mercados que evoluem rapidamente.
A principal realização foi que não é viável um modelo de assinatura de US$ 20 para um agente com chamada de ferramentas. Os custos computacionais são fundamentalmente diferentes. Um assistente baseado em chat, como o Cody, pode operar eficientemente em infraestrutura modesta. Um agente que raciocina sobre código, executa ferramentas e itera autonomamente exige muito mais poder computacional. Não é apenas uma questão de preço; é um sinal de que o produto é fundamentalmente diferente e precisa de um outro modelo de negócios, outras expectativas de clientes e uma estratégia de mercado diferente. Ao criar o AMP como um produto separado e de marca própria, a Sourcegraph pôde redefinir completamente essas expectativas. Puderam dizer aos clientes: “Isto não é Cody 2.0. É algo completamente diferente. Custa mais porque faz mais coisas. Funciona diferente porque é construído sobre outra arquitetura.”
Para realmente entender por que o AMP representa uma mudança de paradigma, é necessário compreender em detalhe a arquitetura técnica dos agentes com chamada de ferramentas. Um agente desse tipo não é apenas um modelo de linguagem com acesso a funções. A arquitetura é mais sofisticada e poderosa. O sistema começa com um modelo de linguagem de ponta — no caso do AMP, o Claude 3.5 Sonnet — treinado para entender e usar ferramentas de forma eficaz. O modelo recebe um prompt de sistema que define o seu papel, restrições e objetivos. Crucialmente, o prompt de sistema não é apenas uma instrução casual; é um prompt cuidadosamente trabalhado que molda como o modelo raciocina sobre problemas e decide quais ferramentas usar.
Junto com o prompt de sistema, cada ferramenta tem seu próprio prompt, que descreve o que faz, quais parâmetros aceita, o que retorna e quando deve ser usada. Isso é fundamental porque o modelo precisa entender não só que a ferramenta existe, mas para que serve e quando é apropriado utilizá-la. Por exemplo, um agente pode ter ferramentas para ler arquivos, escrever arquivos, executar código, rodar testes e fazer commits. Cada ferramenta tem uma descrição detalhada que ajuda o modelo a raciocinar sobre qual ferramenta usar em cada situação. O modelo então decide autonomamente usar essas ferramentas, observa os resultados e itera conforme aprende.
O poder dessa arquitetura aparece quando pensamos no que um agente pode fazer. Um desenvolvedor pode pedir ao agente: “implemente um novo recurso de autenticação de usuários neste código.” O agente pode então, autonomamente: ler o código existente para entender a arquitetura, identificar onde a autenticação deve ser integrada, escrever o código necessário, rodar testes para verificar a implementação, lidar com falhas modificando o código e, por fim, fazer o commit das mudanças. Tudo isso sem intervenção humana. O agente raciocina sobre o problema, decide quais ferramentas usar e itera com base no retorno dessas ferramentas.
Isso é fundamentalmente diferente dos antigos assistentes de programação em IA. O Copilot sugere código, mas não executa fluxos de trabalho multifásicos. O Cursor realiza operações mais complexas, mas requer aprovação humana a cada etapa. Um agente pode operar autonomamente mediante permissões explícitas. Isso cria uma nova categoria de capacidade, muito mais poderosa. Mas também traz novos desafios. Agentes autônomos podem cometer erros em escala. Podem executar operações prejudiciais se não forem corretamente restritos. Exigem engenharia cuidadosa de prompts de sistema para garantir que se comportem como esperado. Esses desafios tornam a arquitetura e abordagem do AMP tão relevantes.
Quando a equipe do AMP começou a construir, tomou uma decisão fundamental: velocidade e iteração seriam o principal objetivo de otimização. Todo o restante derivaria dessa decisão. Isso implicou abandonar muitas das práticas que fizeram a Sourcegraph bem-sucedida com o Cody. Sem revisões formais de código. Sem ciclos extensos de planejamento. Sem checklists de segurança e conformidade que levam nove meses para serem concluídos. Em vez disso, a equipe adotou uma mentalidade de projeto pessoal: push direto na main, lançamento 15 vezes por dia, uso contínuo do produto internamente e iteração baseada no uso real.
Essa abordagem parece caótica, e pelos padrões tradicionais de engenharia de software, é mesmo. Mas é exatamente a abordagem correta para um produto que opera na fronteira das capacidades de IA. O motivo é simples: a fronteira está se movendo. A cada poucos meses, um novo modelo é lançado. A cada poucas semanas, surgem novas capacidades. A cada poucos dias, técnicas inéditas de engenharia de prompt ou design de ferramentas são descobertas. Neste ambiente, a capacidade de iterar rapidamente vale mais do que a capacidade de escalar com confiabilidade. Um produto que lança 15 vezes ao dia pode incorporar novas capacidades de modelo poucas horas após o lançamento. Um produto que segue ciclos tradicionais de lançamento ficará meses atrás.
A estrutura da equipe reflete essa filosofia. O núcleo do time AMP é pequeno — cerca de oito pessoas — comparado a organizações maiores. Esse tamanho reduzido é proposital. Permite decisões rápidas e elimina o overhead de comunicação que torna grandes equipes lentas. Todos na equipe têm experiência, o que permite operar sem processos extensos de revisão de código. Usam o produto o tempo todo, então detectam problemas rapidamente e entendem profundamente as necessidades dos usuários. Não buscam construir um produto para todos os desenvolvedores; querem atender quem deseja se mover rápido, ficar na vanguarda das capacidades de IA e está disposto a abraçar novas abordagens de desenvolvimento.
Esse posicionamento é crucial. O AMP não quer ser o GitHub Copilot de todos. Não quer ser a ferramenta padrão de IA para todos os desenvolvedores. Em vez disso, posiciona-se como a ferramenta para desenvolvedores e equipes que querem se mover rápido e permanecer na fronteira. Esse é um mercado muito menor do que “todos os desenvolvedores”, mas é um segmento disposto a pagar significativamente mais por capacidades superiores. O modelo de negócios reflete isso: em vez de uma assinatura mensal de US$ 20, clientes do AMP pagam centenas de dólares por mês. Algumas equipes têm contratos anuais de centenas de milhares de dólares. Isso é possível porque a proposta de valor é extremamente forte para o público-alvo.
Os princípios que orientam o desenvolvimento do AMP — iteração rápida, posicionamento de fronteira e raciocínio autônomo — são diretamente aplicáveis à automação de fluxos de trabalho em geral. O FlowHunt, como plataforma para construção e automação de fluxos de trabalho complexos, enfrenta desafios e oportunidades semelhantes. Assim como o AMP se posiciona para lidar com a próxima geração de capacidades de IA, o FlowHunt pode ajudar organizações a criar fluxos de trabalho resilientes à rápida mudança tecnológica. Focando em flexibilidade, iteração rápida e capacidade de incorporar novas ferramentas e funções rapidamente, o FlowHunt permite que equipes fiquem à frente.
A grande constatação é que, num cenário tecnológico em rápida evolução, a capacidade de adaptação rápida vale mais do que a otimização para o presente. Isso vale tanto para construção de agentes de programação com IA quanto para automação de processos de negócios. A abordagem do FlowHunt — permitir criação, teste e iteração rápida de fluxos — se encaixa perfeitamente nessa filosofia. Equipes podem criar fluxos que incorporam as capacidades mais recentes de IA, testar rapidamente e iterar a partir dos resultados. À medida que novos modelos e ferramentas surgem, os fluxos podem ser atualizados rapidamente, sem necessidade de grandes reengenharias. Esse é o futuro da automação: não processos estáticos e otimizados, mas fluxos dinâmicos e adaptáveis que evoluem com a tecnologia.
O mercado de agentes de programação em IA é um estudo fascinante de como a liderança de mercado pode mudar rapidamente. No início de 2024, o Cursor era amplamente considerado o rei das ferramentas de programação em IA. Era a startup de crescimento mais rápido da história. Desenvolvedores migravam de outras ferramentas para o Cursor em massa. O mercado parecia consolidado. Mas em poucos meses, tudo mudou. Novas ferramentas surgiram. As capacidades evoluíram. Desenvolvedores começaram a fazer outras perguntas. Em meados de 2024, se você perguntasse a um desenvolvedor qual a melhor ferramenta de programação em IA, muitos já não citavam o Cursor. O mercado mudou tão rápido que o antigo líder já não era dominante.
Esse padrão não é exclusivo dos agentes de programação. É uma característica fundamental de mercados onde a tecnologia avança rapidamente. Nesses mercados, a capacidade de adaptação rápida é mais importante que o market share atual. Uma empresa com 30% de market share que consegue iterar rapidamente e incorporar novas capacidades eventualmente superará uma com 50% de market share que é lenta. É por isso que a decisão da Sourcegraph de criar o AMP como produto separado foi tão estratégica. Ao separar o AMP do Cody, libertaram-se das restrições que os tornariam lentos. Podem se mover rápido, iterar rápido e se posicionar na fronteira.
A lição mais ampla é que, em mercados que evoluem rápido, o imperador frequentemente está nu. Produtos estabelecidos e dominantes podem se tornar obsoletos com surpreendente velocidade. Não porque piorem, mas porque a tecnologia muda e eles não conseguem se adaptar. As empresas que vencem são as que entendem essa dinâmica e se posicionam de acordo. Não otimizam para o presente, mas para a capacidade de adaptação ao futuro. Não tentam servir todos os clientes, focam em quem valoriza velocidade e inovação. Não seguem processos tradicionais, adotam práticas que permitem iteração rápida e aprendizado constante.
A discussão sobre o AMP revela um insight importante sobre o futuro dos agentes de IA: a próxima grande mudança será dos agentes interativos para agentes assíncronos. Hoje, a maioria dos agentes de programação em IA opera de forma interativa. O desenvolvedor roda um agente no editor ou CLI, o agente executa operações e o desenvolvedor vê os resultados. Geralmente há um agente rodando por vez, de forma síncrona — o desenvolvedor aguarda a conclusão. Isso já representa um avanço em relação à codificação manual, mas não é o estágio final do desenvolvimento baseado em agentes.
A próxima fronteira são agentes assíncronos rodando 24/7 em segundo plano, em paralelo. Em vez de um agente por vez, você pode ter 10, 50 ou 100 agentes operando simultaneamente em tarefas diferentes. Um pode estar refatorando código em uma parte do projeto, outro escrevendo testes para outro componente, um terceiro analisando performance e sugerindo otimizações. Tudo isso sem intervenção humana e de forma concorrente. As implicações são impressionantes: salto de 10 a 100 vezes na produção de trabalho, mudança fundamental em como equipes de desenvolvimento operam e uma reimaginação completa do que é possível com desenvolvimento assistido por IA.
Essa mudança terá impacto profundo nos custos de inferência, na organização do trabalho das equipes e no significado do papel do desenvolvedor. Também criará novos desafios de qualidade, segurança e garantia de que agentes autônomos não introduzam bugs ou vulnerabilidades em escala. Mas o potencial é enorme. Equipes que souberem aproveitar agentes assíncronos poderão realizar em dias o que hoje leva semanas. Por isso, posicionar-se para mover rápido e se adaptar é tão crítico. As empresas que dominarem os agentes assíncronos eficazes primeiro terão uma vantagem competitiva massiva.
O princípio fundamental da abordagem do AMP é construir para a incerteza. A equipe não sabe exatamente para onde a tecnologia irá, mas sabe que irá mudar. Não sabe quais capacidades serão mais importantes, mas sabe que novas capacidades surgirão. Não sabe como será o mercado em seis meses, mas sabe que será diferente. Diante dessa incerteza, o caminho racional é otimizar para adaptabilidade, não para otimização. Isso significa manter a base de código flexível, capacidade de lançar rapidamente, estar sempre próximo da fronteira das capacidades de IA e ter disposição para descartar abordagens que não funcionam mais.
Esse princípio vale para estrutura de equipe, modelo de negócios e estratégia de clientes. O time é pequeno e experiente, o que permite decisões rápidas. O modelo de negócios é flexível, sem preço ou modelo de usuário fixo, permitindo ajustes rápidos conforme o mercado evolui. A estratégia de clientes foca em desenvolvedores que querem se mover rápido, criando alinhamento natural entre as capacidades da empresa e as necessidades dos clientes. Tudo deriva do princípio de construir para a incerteza e otimizar para adaptabilidade.
Essa é uma abordagem radicalmente diferente do desenvolvimento tradicional de produtos, onde se tenta prever o futuro, construir para escala e otimizar para estabilidade. Mas em mercados onde a tecnologia avança rápido, abordagens tradicionais são prejudiciais. Elas retardam sua empresa, prendem em decisões que logo ficam obsoletas e impedem adaptação. As empresas que vencem nesses mercados são as que abraçam a incerteza, otimizam para adaptabilidade e se movem rápido o suficiente para se manter à frente.
{{ cta-dark-panel heading=“Potencialize Seu Fluxo de Trabalho com o FlowHunt” description=“Veja como o FlowHunt automatiza seus fluxos de conteúdo em IA e SEO — da pesquisa e geração de conteúdo à publicação e análise — tudo em um só lugar.” ctaPrimaryText=“Agende uma Demonstração” ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo" ctaSecondaryText=“Experimente o FlowHunt Grátis” ctaSecondaryURL=“https://app.flowhunt.io/sign-in" gradientStartColor="#123456” gradientEndColor="#654321” gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217” }}
A capacidade de lançar 15 vezes por dia não é acidental; resulta de escolhas arquiteturais deliberadas. A primeira decisão chave foi desacoplar totalmente o AMP da plataforma Sourcegraph. O Cody era integrado à plataforma Sourcegraph, ficando preso aos ciclos de lançamento e restrições de infraestrutura. O AMP foi construído como produto independente, com infraestrutura, pipeline de implantação e cronograma de lançamentos próprios. Esse desacoplamento é crucial pois elimina o overhead de coordenação que torna grandes sistemas lentos. Mudanças no AMP não dependem de alterações na plataforma. Os lançamentos não esperam ciclos da plataforma.
A segunda decisão foi adotar um processo mínimo de revisão de código. A equipe faz push direto na main e lança com frequência. Se algo quebra, corrigem rapidamente. Parece arriscado, mas funciona porque a equipe é pequena, experiente e usa o produto o tempo todo. Detectam problemas rapidamente porque são usuários reais. Corrigem rapidamente porque conhecem o código de cor. Iteram rápido pois não precisam esperar aprovações de revisão. Em uma grande organização isso seria perigoso, mas numa equipe pequena e experiente é extremamente eficaz.
A terceira decisão foi usar intensivamente o próprio produto (“dogfooding”). A equipe usa o AMP para construir o próprio AMP. Isso cria um ciclo de feedback imediato em que qualquer limitação ou problema é imediatamente sentido. Também significa que a equipe está sempre descobrindo novos casos de uso e capacidades. Usando o próprio produto para construir o produto, aprende-se rapidamente o que funciona e o que não funciona. Descobrem-se casos extremos que não apareceriam em testes tradicionais. Desenvolve-se intuição sobre quais recursos importam mais. Por isso o dogfooding é tão poderoso para iteração rápida.
A quarta decisão foi manter a base de código simples e flexível. Em vez de tentar construir um sistema complexo e otimizado, a equipe fez algo fácil de modificar e estender. Assim, podem incorporar rapidamente novas capacidades. Quando um novo modelo é lançado, integram rapidamente. Quando surge uma nova técnica de prompt engineering, experimentam rápido. Quando descobrem uma abordagem melhor para um problema, refatoram sem medo de quebrar dependências. Essa simplicidade e flexibilidade vale mais do que otimização num mercado que evolui rápido.
O modelo de preços do AMP revela importantes lições sobre criação de valor em desenvolvimento assistido por IA. Logo no início, a equipe percebeu que não era possível sustentar um agente com chamada de ferramentas por US$ 20 ao mês. Não era apenas uma questão de preço; era um sinal de que o produto era fundamentalmente diferente e precisava de outro modelo de negócios. Um assistente baseado em chat, como o Cody, pode funcionar de forma eficiente em infraestrutura modesta. Um agente autônomo que raciocina, executa ferramentas e itera exige muito mais recursos computacionais. Os custos de infraestrutura já justificam preços maiores.
Mas o modelo de preços também reflete a proposta de valor. Para um desenvolvedor ou equipe que sabe usar o AMP de forma eficaz, os ganhos de produtividade são enormes. Um agente que implementa recursos, escreve testes e refatora código de forma autônoma pode economizar horas ou dias de trabalho por semana. Para uma equipe, isso representa muito valor. Se o AMP economiza 10 horas por semana e o valor da hora do desenvolvedor é US$ 100, então o AMP gera US$ 1.000 por semana em valor. Cobrar centenas de dólares por mês é uma fração desse valor. Por isso algumas equipes têm contratos anuais de centenas de milhares de dólares — o valor é tão alto que o preço é, na verdade, uma pechincha.
O modelo de negócios também reflete o posicionamento estratégico. Ao cobrar bem mais que ferramentas tradicionais, o AMP sinaliza que é outra categoria de produto. Não compete por preço, mas por capacidade e valor. Isso atrai clientes que valorizam capacidade e valor, e afasta os mais sensíveis a preço. Essa segmentação é perfeita para um produto na fronteira da IA. Você quer clientes que entendam o valor do que é de ponta e estejam dispostos a pagar. Não quer clientes que só buscam o mais barato, pois esses trocam para a próxima oferta barata facilmente.
Um dos aspectos mais interessantes da abordagem da Sourcegraph é como equilibra inovação e estabilidade. A empresa tem um negócio bem-sucedido e lucrativo com Cody e a plataforma Sourcegraph. Esse negócio gera receita que financia a experimentação do AMP. Mas isso também cria tensão organizacional. Como manter um negócio estável e lucrativo enquanto persegue inovação radical? Como manter engenheiros experientes focados no novo produto se têm expertise no produto existente?
A resposta envolve várias decisões. Primeiro, a Sourcegraph decidiu explicitamente não tentar converter clientes do Cody para o AMP. Usam a confiança e receita do Cody para financiar o desenvolvimento do AMP. Isso é crucial. Se tentassem migrar clientes, enfrentariam resistência pois o AMP é fundamentalmente diferente e exige outro padrão de uso. Mantendo Cody e AMP separados, podem atender segmentos distintos e evitar a disrupção de migrar clientes entre produtos tão diferentes.
Segundo, a Sourcegraph montou a equipe do AMP com pessoas sem vícios de experiência em grandes empresas. Alguns dos membros mais eficazes só trabalharam em startups de uma pessoa. Não têm anos de práticas tradicionais enraizadas. Não possuem hábitos de revisões, ciclos de planejamento e otimização. Essa ausência de bagagem é uma vantagem. Podem adotar práticas radicais sem dissonância cognitiva.
Terceiro, a Sourcegraph explicitou que as regras são diferentes para o AMP. O time não segue os mesmos processos do resto da empresa. Não faz revisão formal de código. Não cumpre checklists de segurança e compliance. Não segue os mesmos ciclos de planejamento. Isso é possível porque têm a confiança do cliente. Eles entendem que o AMP é um produto de fronteira e aceitam trade-offs diferentes. Essa separação explícita de regras e processos é fundamental. Se o AMP tivesse que seguir os mesmos processos do restante da empresa, seria lento. Separando as regras, a Sourcegraph cria espaço para inovação radical.
A trajetória do AMP traz lições importantes para organizações em mercados que evoluem rapidamente. A primeira é que o sucesso estabelecido pode se tornar um passivo. O sucesso da Sourcegraph com Cody poderia tê-los aprisionado numa abordagem incremental. Em vez disso, reconheceram que a tecnologia estava mudando e tiveram coragem de começar do zero. Isso exigiu confiança para canibalizar o próprio negócio, sabedoria para entender que o antigo não serviria para o novo, e coragem para buscar uma estratégia radicalmente diferente.
A segunda lição é que velocidade e adaptabilidade valem mais que otimização e escala em mercados que evoluem rápido. O time não tenta construir o sistema perfeito. Faz algo bom o suficiente e que pode ser rapidamente iterado. Não tenta atender todos os clientes. Foca em quem valoriza velocidade e inovação. Não segue processos tradicionais. Adota processos que aceleram a iteração. Esse foco em adaptabilidade sobre otimização é contra-intuitivo, mas correto quando a tecnologia avança rápido.
A terceira lição é que times pequenos e experientes podem superar grandes organizações. O time do AMP tem cerca de oito pessoas. Todos são engenheiros experientes. Trabalham sem revisão formal de código ou planejamento extenso. Lançam 15 vezes ao dia. Usam o produto todo o tempo. Esse time pequeno consegue se mover mais rápido e inovar mais que equipes grandes. Isso porque eliminaram o overhead de comunicação e processos que tornam grandes equipes lentas. Criaram um ambiente onde a iteração rápida é possível.
A quarta lição é que você precisa redefinir expectativas quando o produto muda fundamentalmente. Clientes do Cody tinham expectativas de preço, recursos e funcionamento. Essas expectativas não serviriam para o AMP. Criando um produto separado e uma marca nova, a Sourcegraph pôde redefinir totalmente as expectativas. Essa é uma estratégia poderosa quando seu produto é fundamentalmente diferente do anterior. Em vez de tentar adaptar novas capacidades a um produto antigo, crie algo novo e redefina as expectativas.
O mercado de agentes de programação em IA é caracterizado por mudanças rápidas e liderança instável. A qualquer momento, existe uma “melhor” ferramenta, mas essa posição é instável. O Copilot foi líder por um tempo. O Cursor depois. Agora há vários concorrentes fortes e a liderança é disputada. Essa instabilidade vem do avanço rápido dos modelos e técnicas subjacentes. Quando o Claude 3.5 Sonnet foi lançado, permitiu capacidades inéditas. Quando surgem novas técnicas de prompt engineering, podem ser rapidamente incorporadas. Quando novos modelos aparecem, o cenário competitivo muda.
Nesse contexto, as empresas que vencem são as que se movem e se adaptam rápido. Uma empresa otimizada para estabilidade e escala será lenta para incorporar novas capacidades. Uma empresa otimizada para velocidade e iteração vai incorporar novidades rapidamente. Com o tempo, a mais rápida toma a dianteira. Por isso o foco do AMP em velocidade e iteração é tão estratégico. Otimizando para velocidade, o AMP se posiciona para se manter na frente à medida que a tecnologia evolui.
O mercado também se especializa cada vez mais. Em vez de tentar ser a melhor ferramenta para todos, produtos bem-sucedidos focam em segmentos específicos. O AMP foca em desenvolvedores que querem se mover rápido e estar na fronteira. Outros produtos podem mirar grandes empresas que valorizam estabilidade e suporte. Outros focam em iniciantes que precisam de orientação. Essa especialização é saudável pois permite otimizar para o segmento alvo em vez de tentar ser tudo para todos.
A história do AMP revela verdades fundamentais sobre competição em mercados que evoluem rápido. Produtos estabelecidos e aparentemente inabaláveis podem se tornar obsoletos surpreendentemente rápido quando a tecnologia muda. Empresas que otimizam para estabilidade e escala tornam-se lentas e vulneráveis. As que otimizam para velocidade e adaptabilidade conseguem se manter à frente. O imperador frequentemente está nu — o produto dominante de hoje pode ser irrelevante amanhã se não se adapta à mudança tecnológica. A decisão da Sourcegraph de criar o AMP como produto separado, adotar práticas radicais como push sem revisão de código, priorizar velocidade e iteração sobre otimização e escala, e posicionar o produto na fronteira da IA mostra um entendimento sofisticado de como competir nesses mercados. As lições do AMP vão além dos agentes de programação. Toda organização em um mercado onde a tecnologia avança rápido deve se perguntar se está otimizando para as coisas certas. Você está otimizando para estabilidade quando deveria buscar adaptabilidade? Tentando servir todos os clientes quando deveria focar em um segmento? Seguindo processos tradicionais quando deveria adotar práticas que permitam iteração rápida? As respostas a essas perguntas determinarão se sua organização prospera ou se torna obsoleta diante da mudança tecnológica.
AMP é um agente de programação inovador criado pela Sourcegraph que usa modelos de linguagem avançados com capacidades de chamada de ferramentas para raciocinar e executar mudanças de código de forma autônoma. Diferente do Cody, que era fortemente integrado à plataforma Sourcegraph e restrito pelos seus ciclos de lançamento, o AMP opera de forma independente, com sua própria infraestrutura, permitindo mais de 15 implantações por dia e iteração rápida sobre novas capacidades de modelo.
A Sourcegraph criou o AMP como um produto separado para evitar impactar contratos empresariais existentes e as expectativas dos clientes em relação ao Cody. A mudança de um assistente baseado em chat para um agente com chamada de ferramentas representa uma alteração fundamental em como desenvolvedores interagem com IA. Ao criar uma nova marca e produto, a Sourcegraph pôde redefinir expectativas, avançar sem restrições do legado e se posicionar na vanguarda do desenvolvimento em IA sem alienar a base atual de clientes.
Agentes com chamada de ferramentas são sistemas de IA que combinam um modelo de linguagem, prompts de sistema e ferramentas externas para realizar tarefas autônomas. Diferente de chatbots tradicionais, esses agentes podem interagir com sistemas de arquivos, editores de código e outros ambientes externos mediante permissões explícitas. Isso permite executar fluxos de trabalho complexos e multifásicos de maneira autônoma, tornando-os fundamentalmente mais poderosos para tarefas de desenvolvimento de software.
O AMP está crescendo mais de 50% ao mês, com algumas equipes atingindo taxas anuais de centenas de milhares de dólares. O produto alcançou margens brutas positivas enquanto mantinha esse ritmo de crescimento. A Sourcegraph estrategicamente focou em desenvolvedores que querem evoluir rapidamente e permanecer na vanguarda dos modelos, ao invés de tentar converter todos os desenvolvedores de uma empresa.
A discussão destaca que agentes assíncronos rodando 24/7 em segundo plano dominarão a próxima fase do desenvolvimento em IA. Ao invés de agentes interativos rodando um de cada vez no editor, as equipes rodarão de 10 a 100 agentes simultaneamente e de forma autônoma, criando um salto de 10 a 100 vezes em produtividade e inferência. O segredo do sucesso é posicionar seu produto para se mover rápido e se adaptar à medida que novos modelos e capacidades surgem a cada poucos meses.
Arshia é Engenheira de Fluxos de Trabalho de IA na FlowHunt. Com formação em ciência da computação e paixão por IA, ela se especializa em criar fluxos de trabalho eficientes que integram ferramentas de IA em tarefas do dia a dia, aumentando a produtividade e a criatividade.
Veja como o FlowHunt ajuda equipes a construir, testar e implantar fluxos de trabalho com IA mais rápido do que nunca.
Explore os anúncios do DevDay 2025 da OpenAI, incluindo o Apps SDK, Agent Kit e o Model Context Protocol. Saiba por que o prompting é mais importante do que nun...
Explore como o aprendizado por reforço e o fine-tuning se tornaram a abordagem dominante para otimizar modelos de IA, desde a destilação do GPT-4 até a ascensão...
Descubra como o Ona (antigo Gitpod) está revolucionando o desenvolvimento de software com agentes de codificação por IA que operam em ambientes de nuvem totalme...
Consentimento de Cookies
Usamos cookies para melhorar sua experiência de navegação e analisar nosso tráfego. See our privacy policy.
