Nodar Daneliya, CEO y cofundador de Shuttle – Serie de entrevistas

Nodar Daneliya, CEO y cofundador de Shuttle – Serie de entrevistas: Nodar Daneliya ha sido cofundador y CEO de Shuttle desde su fundación en 2019, liderando su crecimiento desde una startup temprana de YC Summer 2020 hasta una empresa de ingeniería de plataforma para desarrolladores; antes de Shuttle, ocupó puestos como Director de Riesgos de Provenance Technologies Ltd, donde trabajó en estrategias de fondos de cobertura cuantitativos, y anteriormente en puestos 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 una implementación rápida, una provisión de recursos fuera de la caja y un 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 cofundar 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 la parte 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 fue creado 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 los 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 en la 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 llega a 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, pequeños equipos 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 se ha beneficiado especialmente 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 quedan atascados 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 perdonable – 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 puede 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. Debes diseñar sistemas donde la IA pueda sugerir y acelerar, pero no correr desbocada. 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 esto 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 Dockerfiles, no Terraform, no configuración interminable.

Para alguien que pasa 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 cubre 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 cada vez 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 todo lo 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é. Es por eso que 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 un demo divertido y algo 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é compromisos 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 tempranas, scaleups, incluso equipos de empresa en automotriz, IoT, finanzas, criptomonedas, cualquier lugar donde la confiabilidad y el rendimiento importen. Estos equipos querían el poder de Rust sin la sobrecarga de gestionar infraestructuras de nube complejas.

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

Vemos rutinariamente a fundadores solitarios y pequeños equipos pasar 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 producción.

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 – les traes un contenedor, y tratan de ejecutarlo. Eso todavía te deja responsable de coser recursos de nube, escribir configuración, lidiar 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 permanece revisable y predecible, lo cual es esencial para el control de seguridad y costo en entornos de producción.

¿Cómo ves evolucionar el 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 funcionando 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 realmente los usa.

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 completamente ejecutable, escalable y de grado de producción.

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 de forma autónoma 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 compañías puedan centrarse en crear valor en lugar de luchar con la infraestructura.

Gracias por la gran entrevista, los lectores que desean aprender más deben visitar Shuttle.