Nodar Daneliya, CEO e Co-fundador da Shuttle – Série de Entrevistas

Nodar Daneliya, CEO e Co-fundador da Shuttle – Série de Entrevistas: Nodar Daneliya atua como Co-fundador e CEO da Shuttle desde a fundação da empresa em 2019, liderando seu crescimento de uma startup de verão do YC em 2020 para uma empresa de engenharia de plataforma de desenvolvedor; antes da Shuttle, ele ocupou cargos como Chief Risk Officer na Provenance Technologies Ltd, onde trabalhou em estratégias de hedge fund quantitativo, e anteriormente em funções de tecnologia e dados em Londres e na Google.

Shuttle é uma plataforma de infraestrutura de nuvem de código aberto que simplifica o desenvolvimento e a implantação de back-end, derivando a infraestrutura de anotações de código, permitindo que os desenvolvedores se concentrem em escrever código Rust ou outros sem gerenciar arquivos de configuração separados ou configurações de nuvem complexas; a plataforma permite a implantação rápida, a provisionamento de recursos fora da caixa e o dimensionamento sem interrupções, e é utilizada por dezenas de milhares de engenheiros com mais de 130.000 implantações, visando estender sua experiência de zero-configuração, assistida por IA, para todos os idiomas e integrar com ferramentas como GitHub Copilot e Cursor.

Qual momento ou frustração acabou por levá-lo a co-fundar a Shuttle, e qual problema você estava tentando resolver no início?

O ponto de virada ocorreu durante meu tempo liderando negociações em um fundo de hedge quantitativo. Tínhamos engenheiros excepcionais – PhDs, pessoas seniores de plataforma, pesquisadores de ML – mas mesmo com esse talento, a infraestrutura de nuvem era o gargalo constante. Construir um modelo de negociação ou serviço de back-end não era a parte difícil. O problema era a implantação: colocá-lo ao vivo de forma segura, dimensioná-lo, conectar serviços de nuvem. Foi onde tudo desacelerou. Em um momento, mais da metade de nossa equipe de engenharia estava fazendo trabalho de DevOps apenas para manter os sistemas em execução.

O que me impressionou não foi a sofisticação do código ou a matemática. Foi assistir a pessoas altamente capazes gastando a maior parte do tempo lutando contra a nuvem em vez de construir o que realmente importava. Ninguém queria fazer esse trabalho, mas era inevitável. Essa fricção – a lacuna entre “eu construí algo” e “está funcionando de forma confiável” – é o que a Shuttle foi criada para resolver.

A Shuttle foi fundada em 2019, antes da onda atual de ferramentas de codificação de IA. Como sua visão original evoluiu à medida que o desenvolvimento assistido por IA se tornou mainstream?

O problema central permaneceu o mesmo, mas a IA o amplificou dramaticamente. Quando começamos, a infraestrutura já era o fator limitante para equipes de engenharia fortes. Quando ferramentas como Copilot, Cursor e Claude apareceram, esse gargalo se tornou impossível de ignorar.

De repente, os desenvolvedores podiam gerar aplicativos completos em minutos, mas esses aplicativos atingiam um muro imediatamente. A IA pode escrever código, mas não pode configurar e gerenciar recursos de nuvem de forma confiável. A lacuna que estávamos resolvendo se tornou muito maior e muito mais urgente. Milhões de pessoas agora estão construindo protótipos, mas apenas uma fração chega à produção.

A visão evoluiu de “tornar a infraestrutura mais fácil para os desenvolvedores” para “fazer a infraestrutura funcionar para uma nova geração de construtores” – fundadores solo, pequenas equipes e agentes de IA que podem criar código de back-end, mas não têm interesse em lutar com a configuração de nuvem. Não estamos mais servindo apenas engenheiros tradicionais. O público explodiu.

Ferramentas de IA como Cursor e GitHub Copilot mudaram a forma como os desenvolvedores escrevem código. Na sua perspectiva, quais partes do ciclo de vida do software melhoraram mais, e onde as equipes ainda lutam?

A geração de código deu um salto à frente. Essa parte está quase resolvida. Você pode descrever uma funcionalidade, e a IA a estruturará. O frontend se beneficiou especialmente porque os padrões são bem compreendidos – componentes, estilos, layouts.

Onde as equipes lutam é em tudo o que vem depois: implantação, infraestrutura, operações. A IA pode gerar um endpoint de API, mas não pode criar automaticamente o banco de dados, armazenamento, fila, rede, permissões ou pipeline de implantação que o torna real. A infraestrutura de back-end não acompanhou o ritmo da geração de código.

O resultado é um progresso desigual. Em vez de as coisas se tornarem mais simples de ponta a ponta, novos pontos de pressão surgem. As equipes geram back-ends inteiros em minutos, então ficam presas por dias tentando implantá-los com segurança. Às vezes, a IA torna as coisas piores, produzindo mais código do que as equipes podem realmente executar ou manter. É aí que a fricção real vive agora.

A implantação é frequentemente descrita como o maior gargalo para aplicações geradas por IA. O que especificamente torna a produção desses sistemas tão desafiadora em comparação com a geração do código em si?

O problema é a confiabilidade e as consequências. A geração de código é perdoável – se a IA comete um erro, você vê imediatamente e corrige. Erros de infraestrutura são diferentes. Uma permissão errada, um recurso mal configurado, uma suposição errada sobre custo ou segurança, e você criou um problema real que pode não surgir até mais tarde.

No início, tentamos deixar a IA inferir livremente a infraestrutura a partir do código da aplicação. Parecia ótimo nos demos. Em sistemas reais, desmoronou. A IA produziria configurações que estavam quase certas, mas não quite – permissões muito amplas, escolhas de recursos estranhas, configurações que se tornariam caras silenciosamente.

Isso nos ensinou algo crítico: em produção, inteligência sem limites cria problemas. A IA não precisa de mais liberdade. Ela precisa de melhores trilhos. Você tem que projetar sistemas onde a IA possa sugerir e acelerar, mas não possa correr selvagem. Esse é o desafio técnico que torna a produção de aplicativos gerados por IA muito mais difícil do que gerar o código.

A Shuttle recentemente introduziu o Neptune como a próxima evolução de sua plataforma. O Neptune é descrito como um engenheiro de plataforma de IA universal – o que isso significa em termos práticos para os desenvolvedores que passam de um protótipo para um back-end pronto para produção?

O Neptune atua como a camada ausente entre o código e a produção. Em termos práticos, isso significa que os desenvolvedores – ou agentes de IA – podem se concentrar em escrever lógica de aplicação, e o Neptune lida com tudo o mais: entender quais recursos de infraestrutura são necessários, provisionar recursos, gerenciar segredos, lidar com implantação, orquestrar serviços.

Em vez de fazer os desenvolvedores traduzirem sua aplicação para infraestrutura de nuvem, o Neptune entende a aplicação e gera a infraestrutura em torno dela. Seu código é o plano. O Neptune constrói o ambiente necessário para executá-lo. Nenhum Dockerfile, nenhum Terraform, nenhuma configuração interminável.

Para alguém que passa de um protótipo para a produção, isso significa que você não atinge o muro onde você precisa aprender DevOps. A aplicação que você construiu continua funcionando à medida que você a dimensiona. O Neptune ponteia a lacuna entre “eu construí algo” e “está funcionando de forma confiável em produção”.

À medida que os desenvolvedores confiam cada vez mais na IA para gerar sistemas de back-end, como você equilibra a velocidade e a abstração com a necessidade de controle, segurança e observabilidade?

A confiança é a resposta. Na infraestrutura, a confiança importa mais do que a capacidade. Uma surpresa ruim – um buraco de segurança, uma implantação quebrada, uma conta de nuvem massiva – e você perdeu as pessoas.

Aprendemos cedo que tudo o que a IA toca precisa ser compreensível e revisável. Mesmo que um desenvolvedor não tenha configurado algo manualmente, ele ainda precisa ver o que está acontecendo e por quê. É por isso que o Neptune usa regras de infraestrutura determinísticas. A IA pode sugerir e acelerar, mas tudo o que ela faz está fundamentado em especificações que são revisáveis, previsíveis e testáveis.

A mudança que fizemos foi de “IA decide” para “IA propõe dentro de restrições”. Essa é a diferença entre um demo divertido e algo que você pode confiar quando importa. Os desenvolvedores não estão gastando menos tempo tomando decisões – estão gastando menos tempo digitando e mais tempo decidindo o que deve existir, o que é aceitável, quais compromissos fazem sentido. As melhores equipes tratam a IA como um engenheiro júnior muito capaz: útil, produtivo, mas não no comando.

Quais tipos de equipes estão vendo o valor mais forte do Neptune hoje, seja solos desenvolvedores, startups ou organizações de engenharia maiores?

O perfil mudou dramaticamente. Originalmente, no lado Rust, tínhamos uma base diversa – desenvolvedores individuais, startups em estágio inicial, scaleups, até equipes de empresas em automotivo, IoT, finanças, criptomoedas, em qualquer lugar onde a confiabilidade e o desempenho importam. Essas equipes queriam o poder do Rust sem a sobrecarga de gerenciar infraestrutura de nuvem complexa.

Mas ao longo do último ano, o surgimento do desenvolvimento impulsionado por IA mudou completamente quem constrói software. Agora vemos fundadores solo, desenvolvedores indie, agentes de IA, pequenas equipes e empresas de software tradicionais gerando código de back-end a uma velocidade sem precedentes. O público não é mais apenas engenheiros seniores em campos especializados.

Vemos regularmente fundadores solo e pequenas equipes irem de uma ideia para um back-end implantado em uma única sessão porque não precisam gastar dias configurando. Não é apenas tempo economizado – é momentum preservado, o que é tudo no início. É aí que o valor mais forte aparece: pessoas que podem construir, mas não querem se tornar especialistas em infraestrutura apenas para colocar suas ideias ao vivo.

Do ponto de vista técnico, como o Neptune lida com a configuração do ambiente, gerenciamento de segredos e orquestração de infraestrutura ao transformar código gerado por IA em um back-end pronto para produção?

O Neptune trata o código e a infraestrutura como um sistema unificado. A maioria das ferramentas de implantação age como um serviço de entrega – você traz um contêiner, e elas tentam executá-lo. Isso ainda deixa você responsável por costurar recursos de nuvem, escrever configuração, lidar com variáveis de ambiente, gerenciar segredos, provisionar bancos de dados.

O Neptune inverte esse modelo. Em vez de fazer o desenvolvedor traduzir sua aplicação para infraestrutura de nuvem, o Neptune entende a aplicação e gera a infraestrutura em torno dela. É uma abordagem nativa de IA para DevOps: o código é o plano, e o Neptune constrói o ambiente necessário para executá-lo – incluindo gerenciamento de segredos, configuração de ambiente e orquestração de recursos.

A chave é que a IA trabalha dentro de regras de infraestrutura determinísticas. Ela não pode produzir configurações arbitrárias. Tudo permanece revisável e previsível, o que é essencial para segurança e controle de custos em ambientes de produção.

Olhando para o futuro, como você vê o papel do Neptune evoluindo em um ecossistema onde sistemas de IA cada vez mais constroem, implantam e gerenciam outros sistemas de software?

Estamos nos movendo em direção a um mundo onde a lacuna entre uma ideia e um produto funcionando é próxima de zero. Muito em breve, os produtos não serão apenas construídos mais rapidamente – eles serão continuamente aprimorados com base em feedback em tempo real de como as pessoas realmente os usam.

Nesse mundo, o software não será estático. Aplicativos, agentes e sistemas serão criados, modificados e evoluídos constantemente. Tudo isso ainda precisa ser executado em algum lugar. Ainda precisa de infraestrutura, permissões, recursos e confiabilidade.

Nosso objetivo de longo prazo é nos tornarmos o sistema padrão para DevOps assistido por IA – essencialmente o Engenheiro de Plataforma de IA. Seja o código escrito por um desenvolvedor no Cursor ou gerado autonomamente por um agente de IA, o Neptune deve ser a camada que o leva do código para um serviço totalmente em execução, escalável e de nível de produção.

Se a criatividade se tornar ilimitada, a infraestrutura não pode ser o constrangimento. À medida que os agentes de IA e os produtos autoevoluídos se tornam normais, nosso trabalho é tornar a interação com a infraestrutura de nuvem invisível, previsível e segura. Estamos focados em tornar isso invisível, para que os desenvolvedores, fundadores e empresas possam se concentrar em criar valor em vez de lutar com a infraestrutura.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Shuttle.