Nodar Daneliya, CEO y Co-fundador de Shuttle – Serie de Entrevistas

Nodar Daneliya, CEO y Co-fundador de Shuttle – Serie de Entrevistas: Nodar Daneliya ha sido Co-fundador y CEO de Shuttle desde su fundación en 2019, liderando su crecimiento desde una startup de verano de YC 2020 hasta una empresa de ingeniería de plataforma para desarrolladores; antes de Shuttle, ocupó cargos como Director de Riesgos de Provenance Technologies Ltd, donde trabajó en estrategias de fondos de cobertura cuantitativos, y anteriormente en roles de tecnología y datos en Londres y en Google.

Shuttle es una plataforma de infraestructura en la nube de código abierto que simplifica el desarrollo y la implementación de backend al derivar la infraestructura de anotaciones de código, lo que permite a los desarrolladores centrarse en escribir código en Rust u otros lenguajes sin tener que gestionar archivos de configuración separados o configuraciones de nube complejas; la plataforma permite la implementación rápida, la provisión de recursos fuera de la caja y el escalado sin problemas, y es utilizada por decenas de miles de ingenieros con más de 130.000 implementaciones, con el objetivo de extender su experiencia de configuración cero, asistida por IA, a todos los lenguajes y integrarse con herramientas como GitHub Copilot y Cursor.

¿Qué momento o frustración te llevó a co-fundar Shuttle, y qué problema estabas tratando de resolver al principio?

El punto de inflexión llegó durante mi tiempo como líder de trading en un fondo de cobertura cuantitativo. Teníamos ingenieros excepcionales – doctorados, personas senior de plataforma, investigadores de ML – pero incluso con ese talento, la infraestructura en la nube era el cuello de botella constante. Construir un modelo de trading o un servicio de backend no era lo difícil. El problema era la implementación: llevarlo a producción de manera segura, escalarlo, conectar servicios de nube. Ese era el punto en el que todo se ralentizaba. En un momento, más de la mitad de nuestro equipo de ingenieros estaba haciendo trabajo de DevOps solo para mantener los sistemas en funcionamiento.

Lo que me quedó grabado no fue la sofisticación del código o las matemáticas. Fue ver a personas muy capaces quemar la mayor parte de su tiempo luchando contra la nube en lugar de construir lo que realmente importaba. Nadie quería hacer ese trabajo, pero era inevitable. Esa fricción – la brecha entre “he construido algo” y “está funcionando de manera confiable” – es lo que Shuttle se creó para resolver.

Shuttle se fundó en 2019, antes de la actual ola de herramientas de codificación asistidas por IA. ¿Cómo ha evolucionado tu visión original a medida que el desarrollo asistido por IA se ha vuelto mainstream?

El problema central permaneció igual, pero la IA lo amplificó dramáticamente. Cuando empezamos, la infraestructura ya era el factor limitante para equipos de ingeniería sólidos. Cuando aparecieron herramientas como Copilot, Cursor y Claude, ese cuello de botella se volvió imposible de ignorar.

De repente, los desarrolladores podían generar aplicaciones completas en minutos, pero esas aplicaciones chocaban con un muro inmediatamente. La IA puede escribir código, pero no puede configurar y gestionar recursos de nube de manera confiable. La brecha que estábamos resolviendo se volvió mucho más ancha y más urgente. Millones de personas ahora están construyendo prototipos, pero solo una fracción logra llegar a la producción.

La visión evolucionó de “hacer que la infraestructura sea más fácil para los desarrolladores” a “hacer que la infraestructura funcione para una nueva generación de constructores” – fundadores solitarios, equipos pequeños y agentes de IA que pueden crear código de backend pero no tienen interés en luchar con la configuración de la nube. Ya no solo servimos a ingenieros tradicionales. La audiencia ha explotado.

Herramientas de IA como Cursor y GitHub Copilot han cambiado la forma en que los desarrolladores escriben código. Desde tu perspectiva, ¿qué partes del ciclo de vida del software han mejorado más, y dónde siguen luchando los equipos?

La generación de código ha avanzado mucho. Esa parte está casi resuelta. Puedes describir una característica, y la IA la esboza. El frontend especialmente ha beneficiado porque los patrones están bien entendidos – componentes, estilos, diseños.

Donde los equipos luchan es en todo lo que viene después: implementación, infraestructura, operaciones. La IA puede generar un punto final de API, pero no puede crear automáticamente la base de datos, el almacenamiento, la cola, la red, los permisos o la canalización de implementación que lo hace real. La infraestructura de backend no ha mantenido el ritmo con la generación de código.

El resultado es un progreso desigual. En lugar de que las cosas se vuelvan más simples de principio a fin, aparecen nuevos puntos de presión. Los equipos generan backends completos en minutos, luego se atascan durante días tratando de implementarlos de manera segura. A veces, la IA lo empeora al producir más código del que los equipos pueden ejecutar o mantener. Ahí es donde vive la verdadera fricción ahora.

La implementación a menudo se describe como el mayor cuello de botella para las aplicaciones generadas por IA. ¿Qué hace que la producción de estos sistemas sea tan desafiante en comparación con la generación del código en sí?

El problema es la confiabilidad y las consecuencias. La generación de código es indulgente – si la IA comete un error, lo ves inmediatamente y lo corriges. Los errores de infraestructura son diferentes. Un permiso incorrecto, un recurso mal configurado, una mala suposición sobre el costo o la seguridad, y has creado un problema real que podría no surgir hasta más tarde.

Al principio, tratamos de dejar que la IA inferiera libremente la infraestructura a partir del código de la aplicación. Parecía genial en demos. En sistemas reales, se desmoronó. La IA producía configuraciones que estaban casi bien pero no del todo – permisos demasiado amplios, elecciones de recursos extrañas, configuraciones que se volverían costosas silenciosamente.

Eso nos enseñó algo crítico: en producción, la inteligencia sin límites crea problemas. La IA no necesita más libertad. Necesita mejores rieles. Tienes que diseñar sistemas donde la IA pueda sugerir y acelerar, pero no correr desenfrenada. Ese es el desafío técnico que hace que la producción de aplicaciones generadas por IA sea mucho más difícil que generar el código.

Shuttle recientemente introdujo Neptune como la próxima evolución de su plataforma. Neptune se describe como una plataforma de ingeniería universal asistida por IA – ¿qué significa eso en términos prácticos para los desarrolladores que pasan de un prototipo a un backend listo para producción?

Neptune actúa como la capa que falta entre el código y la producción. En términos prácticos, significa que los desarrolladores – o agentes de IA – pueden centrarse en escribir lógica de aplicación, y Neptune maneja todo lo demás: entender qué infraestructura se necesita, provisionar recursos, gestionar secretos, manejar la implementación, orquestar servicios.

En lugar de hacer que los desarrolladores traduzcan su aplicación a infraestructura en la nube, Neptune entiende la aplicación y genera la infraestructura alrededor de ella. Tu código es el plano. Neptune construye el entorno necesario para ejecutarlo. No hay archivos Docker, no hay Terraform, no hay configuración interminable.

Para alguien que se mueve de un prototipo a producción, significa que no chocas con el muro donde de repente necesitas aprender DevOps. La aplicación que construiste sigue funcionando a medida que la escalas. Neptune conecta la brecha entre “he construido algo” y “está funcionando de manera confiable en producción”.

¿Cómo equilibras la velocidad y la abstracción con la necesidad de control, seguridad y observabilidad a medida que los desarrolladores confían más en la IA para generar sistemas de backend?

La confianza es la respuesta. En infraestructura, la confianza importa más que la capacidad. Una mala sorpresa – un agujero de seguridad, una implementación rota, una factura de nube masiva – y has perdido a la gente.

Aprendimos temprano que cualquier cosa que la IA toca necesita ser comprensible y revisable. Incluso si un desarrollador no configuró algo a mano, todavía necesita ver qué está sucediendo y por qué. Eso es por qué Neptune utiliza reglas de infraestructura deterministas. La IA puede sugerir y acelerar, pero todo lo que hace está basado en especificaciones que son revisables, predecibles y probables.

El cambio que hicimos fue de “la IA decide” a “la IA propone dentro de restricciones”. Esa es la diferencia entre una demo divertida y algo en lo que puedes confiar cuando importa. Los desarrolladores no están pasando menos tiempo tomando decisiones – están pasando menos tiempo tecleando y más tiempo decidiendo qué debería existir, qué es aceptable, qué compensaciones tienen sentido. Los mejores equipos tratan a la IA como un ingeniero junior muy capaz: útil, productivo, pero no al mando.

¿Qué tipo de equipos están viendo el valor más fuerte de Neptune hoy en día, ya sea desarrolladores solitarios, startups o organizaciones de ingeniería más grandes?

El perfil ha cambiado dramáticamente. Originalmente, en el lado de Rust, teníamos una base diversa – desarrolladores individuales, startups en etapas tempranas, empresas en crecimiento, incluso equipos de empresa en automotriz, IoT, finanzas, criptomonedas, en cualquier lugar donde la confiabilidad y el rendimiento importen. Estos equipos querían el poder de Rust sin la carga de gestionar infraestructuras de nube complejas.

Pero en el último año, el auge del desarrollo impulsado por IA ha cambiado completamente quién construye software. Ahora vemos a fundadores solitarios, desarrolladores independientes, agentes de IA, equipos pequeños y empresas de software tradicionales generando código de backend a una velocidad sin precedentes. La audiencia no son solo ingenieros senior en campos especializados.

Vemos regularmente a fundadores solitarios y equipos pequeños ir de una idea a un backend implementado en una sola sesión porque no tienen que pasar días configurando. No es solo el tiempo ahorrado – es el impulso preservado, lo que es todo al principio. Ahí es donde se muestra el valor más fuerte: personas que pueden construir pero no quieren convertirse en expertos en infraestructura solo para llevar sus ideas a la vida.

Desde un punto de vista técnico, ¿cómo maneja Neptune la configuración del entorno, la gestión de secretos y la orquestación de infraestructura al convertir código generado por IA en un backend de producción listo para implementar?

Neptune trata el código y la infraestructura como un sistema unificado. La mayoría de las herramientas de implementación actúan como un servicio de entrega – te traes un contenedor, y tratan de ejecutarlo. Eso todavía te deja responsable de coser recursos de nube, escribir configuración, tratar con variables de entorno, manejar secretos, provisionar bases de datos.

Neptune invierte ese modelo. En lugar de hacer que el desarrollador traduzca su aplicación a infraestructura en la nube, Neptune entiende la aplicación y genera la infraestructura alrededor de ella. Es un enfoque nativo de IA para DevOps: el código es el plano, y Neptune construye el entorno necesario para ejecutarlo – incluyendo la gestión de secretos, la configuración del entorno y la orquestación de recursos.

La clave es que la IA trabaja dentro de reglas de infraestructura deterministas. No puede producir configuraciones arbitrarias. Todo sigue siendo revisable y predecible, lo cual es esencial para la seguridad y el control de costos en entornos de producción.

Mirando hacia adelante, ¿cómo ves la evolución del papel de Neptune en un ecosistema donde los sistemas de IA cada vez más construyen, implementan y gestionan otros sistemas de software?

Estamos avanzando hacia un mundo donde la brecha entre una idea y un producto funcional es casi cero. Muy pronto, los productos no solo se construirán más rápido – también se mejorarán continuamente basados en retroalimentación en tiempo real de cómo la gente los usa realmente.

En ese mundo, el software no será estático. Las aplicaciones, los agentes y los sistemas se crearán, modificarán y evolucionarán constantemente. Todo eso todavía necesita ejecutarse en algún lugar. Todavía necesita infraestructura, permisos, recursos y confiabilidad.

Nuestro objetivo a largo plazo es convertirnos en el sistema predeterminado para DevOps asistido por IA – esencialmente, el Ingeniero de Plataforma de IA. Ya sea que el código sea escrito por un desarrollador en Cursor o generado de forma autónoma por un agente de IA, Neptune debería ser la capa que lo lleva del código a un servicio de producción completamente funcional y escalable.

Si la creatividad se vuelve ilimitada, la infraestructura no puede ser la restricción. A medida que los agentes de IA y los productos que evolucionan automáticamente se vuelven normales, nuestro trabajo es hacer que la interacción con la infraestructura en la nube sea invisible, predecible y segura. Estamos centrados en hacer que eso sea invisible, para que los desarrolladores, fundadores y empresas puedan centrarse en crear valor en lugar de luchar con la infraestructura. Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar Shuttle.