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 focada em desenvolvedores; antes da Shuttle, ele ocupou cargos como Diretor de Risco da Provenance Technologies Ltd, onde trabalhou em estratégias de fundos de hedge quantitativos, e anteriormente em cargos de tecnologia e dados em Londres e no Google.

Shuttle é uma plataforma de infraestrutura de nuvem de código aberto que simplifica o desenvolvimento e implantação de back-end, derivando infraestrutura de anotações de código, permitindo que os desenvolvedores se concentrem em escrever código em Rust ou outras linguagens sem gerenciar arquivos de configuração separados ou configurações de nuvem complexas; a plataforma permite implantação rápida, provisionamento de recursos fora da caixa e escalabilidade sem interrupções, e é usada 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 foi o momento ou frustração que finalmente o levou 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 – doutores, 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: torná-lo vivo com segurança, escalá-lo, conectar serviços de nuvem. Foi aí que tudo desacelerou. Em um momento, mais da metade de nossa equipe de engenharia estava fazendo trabalhos de DevOps apenas para manter os sistemas em execução.

O que me ficou não foi a sofisticação do código ou da matemática. Foi assistir a pessoas altamente capazes queimando a maior parte de seu 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 com confiabilidade” – é 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 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 “tornar a infraestrutura funcional 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 contra 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. Do seu ponto de vista, 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 esboçará. 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 ponto de extremidade 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, mas ficam presas por dias tentando implantá-los com segurança. Às vezes, a IA piora as coisas 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 próprio código?

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. Os 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 em demonstrações. Em sistemas reais, desmoronou. A IA produziria configurações que estavam quase certas, mas não exatamente – permissões muito amplas, escolhas de recursos estranhas, configurações que se tornariam caras silenciosamente.

Isso nos ensinou algo crítico: em produção, a 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 pode correr solta. Esse é o desafio técnico que torna a produção de aplicações geradas 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 mudam de um protótipo para um back-end de produção pronto?

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 a lógica da 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 a implantação, orquestrar serviços.

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

Para alguém que está mudando de um protótipo para uma 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 escala. O Neptune ponteia a lacuna entre “Eu construí algo” e “está funcionando com confiabilidade 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 massive – e você perdeu as pessoas.

Aprendemos cedo que qualquer coisa 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 limites.” Essa é a diferença entre um demonstração divertida 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 compensações 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 no Neptune hoje, seja desenvolvedores solo, 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 infraestruturas de nuvem complexas.

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 de produção implantável?

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ê lhes 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 com que o desenvolvedor traduza sua aplicação em infraestrutura de nuvem, o Neptune entende a aplicação e gera a infraestrutura ao seu redor. É uma abordagem nativa de IA para DevOps: o código é o projeto, 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 os 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 continuarão a melhorar a si mesmos 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 precisará ser executado em algum lugar. Ainda precisará 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 leva do código para um serviço de produção totalmente em execução e escalável.

Se a criatividade se tornar ilimitada, a infraestrutura não pode ser o constrangimento. À medida que os agentes de IA e os produtos que se auto-evoluem se tornam normais, nosso trabalho é tornar a interação com a infraestrutura de nuvem sem esforço, 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 contra a infraestrutura.

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