Cómo ve el desarrollo de software con IA Peter Steinberger, creador de OpenClaw: de OpenClaw a la programación en bucle cerrado

Sun, 17 May 2026 20:02:26 +0800

La trayectoria de Peter Steinberger sirve para observar qué está cambiando en el desarrollo de software con IA.

No es un recién llegado que se hizo visible de repente gracias a la IA. Antes de OpenClaw, ya era fundador de PSPDFKit, una empresa dedicada a renderizado PDF, procesamiento de documentos y herramientas para desarrolladores. Este tipo de producto no gana solo con narrativa: debe resolver rendimiento, compatibilidad, diseño de API, clientes empresariales y mantenimiento a largo plazo.

Por eso, cuando Steinberger construyó OpenClaw con herramientas de IA y empezó a hablar de AI Agent, automatización personal y AI coding, lo importante no fue solo que “una persona escribió mucho código”. Lo más interesante es cómo combinó años de experiencia en ingeniería de software con una nueva generación de AI coding agents para reinterpretar el proceso de desarrollo.

AI coding no es un botón mágico

Muchas discusiones sobre AI coding se reducen a dos extremos.

Uno dice que la IA ya puede escribir código y que los programadores pronto no serán necesarios.

El otro dice que el código generado por IA no es fiable y que la ingeniería real debe seguir escribiéndose a mano.

La experiencia de Steinberger apunta a una tercera idea: la IA cambia la unidad de operación del desarrollo de software, pero no elimina el juicio de ingeniería.

Antes, el trabajo del desarrollador giraba alrededor de editar código. Descomponer requisitos, decidir arquitectura, implementar, probar y corregir bugs se organizaba alrededor de cambios manuales.

Cuando entran AI coding agents, el desarrollador empieza a parecerse más a alguien que gestiona un sistema de ejecución:

Explicar el objetivo.
Proporcionar contexto.
Definir límites.
Dejar que el agent modifique código.
Ejecutar pruebas y comprobaciones.
Iterar según los resultados.

Esto no es simplemente entregar el teclado al modelo. Es pasar de “escribir cada línea a mano” a “definir dirección, diseñar feedback y juzgar resultados”.

Por qué no le convence llamarlo vibe coding

Una expresión frecuente alrededor de Steinberger es vibe coding.

El término nació para describir una nueva forma de desarrollo: el desarrollador describe ideas en lenguaje natural, deja que la IA genere mucho código y luego ajusta con resultados de ejecución y feedback.

Pero Steinberger no está del todo de acuerdo con esa etiqueta. En cobertura pública se ha señalado que ve vibe coding como una expresión que puede volverse despectiva, porque sugiere que el desarrollo asistido por IA es solo “generar por intuición” e ignora la habilidad, el juicio y la experiencia detrás.

La crítica tiene sentido.

El AI coding efectivo no consiste en escribir una frase casual y confiar en la salida del modelo. Requiere:

Convertir requisitos vagos en tareas ejecutables.
Detectar si el modelo entendió mal el objetivo.
Diseñar pruebas y criterios de aceptación.
Juzgar si la estructura del código será mantenible.
Saber cuándo dejar de generar y pasar a revisión humana.

En otras palabras, la IA reduce la fricción de escribir código, pero no reduce la responsabilidad de entender el sistema.

La clave es el bucle

Una idea que se asocia con frecuencia a entrevistas y textos de Steinberger es el bucle.

Dejar que la IA genere código es un proceso de bucle abierto.

Dejar que la IA genere código, lo ejecute, lea errores, corrija problemas y vuelva a ejecutar pruebas se acerca más a un bucle cerrado.

La diferencia es importante.

La generación en bucle abierto crea con facilidad software que parece utilizable. La página abre, las funciones parecen existir y hay bastante código. Pero al entrar en escenarios reales aparecen problemas de estado, permisos, manejo de errores, casos límite y despliegue.

El desarrollo en bucle cerrado exige que la salida esté limitada por feedback. El bucle más simple es:

Escribir claramente el objetivo.
Dejar que la IA modifique el código.
Ejecutar automáticamente pruebas, type checks, lint o build.
Devolver los errores a la IA.
Repetir hasta que pase.
Hacer una revisión humana de la ruta crítica.

Ahí es donde el desarrollo de software con IA puede mejorar de verdad la eficiencia. No porque el modelo acierte a la primera, sino porque puede participar rápidamente en el ciclo de generar, validar y reparar.

Cuanta más experiencia, mejor se usa la IA

Uno de los malentendidos más comunes sobre AI coding es que la experiencia deja de importar.

El caso de Steinberger sugiere lo contrario: la experiencia importa más, aunque su función cambia.

Un ingeniero con experiencia juzga mejor:

Qué tareas conviene pasar a un agent.
Qué módulos necesitan pruebas primero.
Qué cambios son demasiado riesgosos para una refactorización amplia con IA.
Qué código generado solo parece razonable.
Qué problemas deberían resolverse con arquitectura y no con más parches.

La IA puede generar muchas soluciones candidatas, pero cuantas más opciones hay, más juicio se necesita. Alguien sin experiencia puede quedar impresionado porque “funciona”. Un ingeniero con experiencia pregunta: ¿se puede mantener? ¿se puede extender? ¿rompe límites de seguridad? ¿se puede depurar si falla?

Por eso los AI coding agents no convierten la ingeniería de software en puro chat. Más bien externalizan una parte del trabajo de ejecución y amplifican la importancia de planificar, revisar, validar y decidir trade-offs.

OpenClaw importa más allá del proyecto

OpenClaw llamó la atención no solo porque es un AI agent open source, ni solo porque creció rápido.

También funciona como señal: los desarrolladores empiezan a querer que la IA no solo responda preguntas, sino que se conecte a herramientas reales y ejecute acciones reales.

Los chatbots tradicionales se quedan dentro de la caja de conversación. Pueden explicar código, escribir borradores y dar consejos, pero muchas veces una persona todavía debe copiar, pegar, abrir software y ejecutar comandos.

La dirección de los agents es conectar modelos con herramientas:

Sistema de archivos.
Navegador.
Terminal.
Email.
Calendario.
Servicios de terceros.
Repositorios de proyecto.

Cuando los modelos pueden usar esas herramientas, cambian los límites del desarrollo de software. La IA deja de ser solo autocompletado de código y participa en lectura de proyectos, descomposición de tareas, edición de archivos, ejecución de pruebas, preparación de PR y automatización de workflows.

Por eso también llamó la atención la incorporación de Steinberger a OpenAI. No representa solo una historia individual de desarrollador, sino una dirección de producto: los agents personales pasarán de demos a la capa de trabajo diaria.

Qué significa para desarrolladores comunes

Para desarrolladores comunes, la experiencia de Steinberger no se puede copiar directamente en todos los casos.

No todo el mundo puede gestionar varios agents a la vez. No todos los proyectos toleran generación intensa con IA. No todos los equipos aceptan el ritmo de “generar primero e iterar rápido”.

Pero hay varias lecciones útiles.

Primero, escribir tareas con claridad.

La IA es sensible a objetivos vagos. Si dices “optimiza esto”, puede cambiar estilo, estructura, funciones y lógica. Si dices “cambia el mensaje de error al fallar el login de inglés a chino sin alterar el flujo de autenticación”, el resultado suele ser más controlable.

Segundo, fijar comandos de validación.

Si un proyecto no tiene pruebas, build ni lint, la IA tiene dificultades para formar un bucle. Incluso comandos básicos como npm test, go test ./..., pytest o hugo son mejores que revisar solo a ojo.

Tercero, controlar el alcance del cambio.

Pedir a la IA que trabaje en un módulo, un bug o una página cada vez suele ser más fiable que pedirle “refactoriza todo el proyecto”.

Cuarto, mantener revisión humana.

En autenticación, pagos, permisos, eliminación de datos, scripts de despliegue, migraciones de base de datos y configuración de seguridad, no bajes el estándar de revisión solo porque el código lo generó IA.

Quinto, revisar prompts y patrones de fallo.

Si la IA malinterpreta a menudo cierto tipo de tarea, escribe esas restricciones en reglas del proyecto, agent instructions o archivos de skill. La capacidad de AI coding no viene solo del modelo, sino también del entorno de trabajo que construyes alrededor.

Hacia dónde va el desarrollo de software con IA

La historia de Steinberger muestra que el desarrollo de software con IA se mueve desde “ayudar a escribir código” hacia “organizar flujos de producción de software”.

Las primeras herramientas de AI coding servían sobre todo para completar funciones, explicar errores y generar plantillas. El cambio actual es que los agents pueden trabajar entre archivos, llamar herramientas, ejecutar comprobaciones y seguir corrigiendo con feedback.

Esto apunta a varias tendencias.

Primero, subirá el techo productivo de los desarrolladores individuales.

Una persona puede avanzar más prototipos, scripts, herramientas internas y productos pequeños. Pero producir más no significa producir mejor automáticamente. Cuanto más rápido se genera, más importante es validar.

Segundo, la estructura del proyecto será más importante.

Cuanto más claro sea el código, más explícitas las pruebas y más completa la documentación, más fácil será que la IA haga cambios correctos. Los proyectos caóticos son difíciles para humanos y para IA.

Tercero, los ingenieros de software se parecerán más a diseñadores de workflows.

En el futuro no importará solo conocer un lenguaje, sino saber organizar requisitos, contexto, herramientas, pruebas, despliegue y permisos en un bucle controlable.

Cuarto, los límites de seguridad serán más sensibles.

Si un agent puede hacer cosas, también puede hacer cosas equivocadas. Si puede leer archivos, ejecutar comandos y acceder a servicios, permisos, auditoría y rollback se vuelven infraestructura básica del entorno de desarrollo con IA.

Resumen

Lo más valioso de la visión de Peter Steinberger sobre desarrollo de software con IA no es “cuánto código generó la IA”, sino la nueva postura de desarrollo que muestra.

Las personas ya no solo escriben línea por línea dentro del editor. Diseñan objetivos, gestionan agents, construyen bucles de feedback, revisan resultados y ajustan el sistema. El código sigue siendo importante, pero ya no es el único centro del trabajo.

Si el desarrollo tradicional enfatizaba “escribir bien el código”, el desarrollo con IA enfatizará cada vez más “hacer que el sistema produzca resultados correctos y verificables de forma continua”.

No se trata solo de bajar la barrera de la ingeniería. Cambia la forma de la capacidad técnica: de implementación manual hacia descomposición de tareas, gestión de contexto, orquestación de herramientas, validación automática y juicio final.

Peter Steinberger on KnightLi Blog