6600 commits en un mes: lecciones de workflow del creador de OpenClaw
Un solo desarrollador. 6600 commits. Un mes.
Más de lo que la mayoría de equipos entrega en un trimestre. Más de lo que muchas startups producen en medio año. No es una métrica de marketing – es la productividad real de Peter Steinberger, creador de OpenClaw (antes conocido como clawdbot), uno de los proyectos de IA más virales de enero de 2026.
El propio Peter describe el proyecto con sencillez: «No es una empresa – es un tipo sentado en casa disfrutando del proceso». Tras un exit exitoso de PSPDFKit podría haberse tomado un descanso. En cambio, construye un asistente IA que gestiona su calendario, envía correos y lo registra en vuelos. «IA que realmente hace las cosas» – así formuló la misión del proyecto.
¿Cómo puede una sola persona trabajar como toda una empresa? ¿Qué habilidades son críticas cuando se trabaja con agentes IA? ¿Por qué la experiencia gestionando un equipo de más de 70 personas resulta clave para la productividad con IA? ¿Y cómo evoluciona el foco del ingeniero – del escribir código al diseñar arquitectura?
Analizamos las lecciones constructivas del workflow de Peter Steinberger – aplicables a cualquier proyecto asistido por IA, incluso si nunca vas a instalar OpenClaw.
El proyecto ha sido exitosamente rebrandeado a OpenClaw tras un crecimiento explosivo hasta 145 000 estrellas en GitHub y 2 millones de visitantes en una semana. El nuevo nombre refleja la filosofía open-source del proyecto y su foco en la data sovereignty – el despliegue local del asistente IA en tu propia infraestructura.
En la primera parte analizamos los problemas críticos de seguridad de OpenClaw y desmontamos el mito sobre la necesidad de un Mac Mini. Pero más allá de las vulnerabilidades y el hype de marketing, hay algo mucho más valioso: la experiencia de workflow que es aplicable a cualquier proyecto asistido por IA, independientemente de la herramienta elegida.
¿Qué es OpenClaw? Es un asistente IA local de código abierto que funciona en tu propia infraestructura. A diferencia de las soluciones SaaS, OpenClaw da control total sobre los datos. Se integra con WhatsApp, Telegram, Discord, Slack, Teams y otros mensajeros.
Advertencia importante: OpenClaw aún no está listo para uso masivo. La configuración requiere tiempo considerable y experiencia técnica. Existen también preguntas de seguridad – inevitables en un proyecto bootstrapped, pero especialmente críticas para una herramienta que actúa en tu nombre. Sin embargo, la tracción del proyecto demuestra el hambre por sistemas IA que cumplan las promesas de automatización – y no solo aceleren la escritura de código.
Contexto: la carrera de los agentes IA
OpenClaw no apareció en el vacío. A principios de 2026, las grandes empresas tecnológicas desarrollan activamente la categoría de agentes IA – sistemas capaces de ejecutar tareas complejas en nombre del usuario.
Anthropic presentó recientemente Claude Cowork – un producto experimental que crea tablas y organiza archivos rápidamente. A finales de 2025, Manus captó la atención global con una demostración de un agente IA más universal, capaz de filtrar CVs y planificar itinerarios de viaje. Meta acordó recientemente adquirir Manus, abriendo posibilidades de integrar estas funciones en WhatsApp y otras aplicaciones sociales.
La apuesta de Peter es diferente: no crear un agente específico, sino gestionar una flota de agentes. En el podcast Insecure Agents explicó: «Empecé con una pregunta simple: ¿por qué no tengo un agente que vigile mis agentes?» En esencia, OpenClaw decide qué sistemas automatizados usar para cada tarea concreta.
Enfoque arquitectónico: “Prompt Requests” en lugar de Pull Requests
Peter Steinberger ha rediseñado radicalmente el proceso de desarrollo tradicional. Los pull requests se han sustituido por “prompt requests” – le interesa saber qué prompt generó el código, no el código en sí. El code review ha muerto en este workflow – lo reemplazan discusiones sobre arquitectura.
Incluso en el canal de Discord del equipo de OpenClaw no se discute código – solo arquitectura y decisiones clave. Paradójicamente, funciona: la mayor parte del código es, como lo formula Peter, “aburrida transformación de datos”. La energía debe invertirse en el diseño del sistema, no en el estilo de formateo o la elección del patrón para un data mapper.
En una entrevista con Gergely Orosz (The Pragmatic Engineer) Peter lo precisa: «Cuando recibo un PR, me interesan más los prompts que el código. Pido a la gente que añada los prompts, y los leo más que el código. Para mí eso da una señal mucho más clara de cómo llegó alguien a la solución. ¿Qué preguntó realmente? ¿Cuántas correcciones necesitó? Eso me dice más sobre el resultado que el propio código».
De code review a architecture review
El proceso de desarrollo tradicional se centra en la calidad de cada línea de código. El workflow asistido por IA de Peter desplaza ese foco: si la arquitectura es correcta, la implementación concreta importa menos. La IA puede reescribir el código diez veces hasta obtener el resultado deseado – lo fundamental es que la dirección sea la correcta.
Esto no implica ausencia de control de calidad. Significa que el control de calidad se eleva un nivel: en lugar de “¿está bien formateado este bucle?” las preguntas son “¿está bien diseñado este subsistema para la extensibilidad”.
Mecánica del workflow: cómo funcionan 5–10 agentes simultáneos
¿Cómo puede una sola persona producir más código que la mayoría de equipos en un trimestre? Peter ejecuta 5–10 agentes simultáneamente, manteniéndose en estado de “flujo”. Mientras un agente trabaja en la funcionalidad A, otros implementan en paralelo B, C y D. Esto no es desarrollo tradicional – es orquestación de ejecutores autónomos.
El proceso de planificación: etapa crítica
El propio Peter invierte un tiempo sorprendentemente largo en planificación antes de lanzar un agente. Cuestiona al agente, ajusta el plan, presenta objeciones. Solo cuando el plan es realmente detallado y bien pensado lo pone en marcha y pasa al siguiente.
Esto no es la “magia de una sola frase” del marketing – son inversiones de ingeniería comparables a construir un LangChain-workflow desde cero. La diferencia es que el tiempo se dedica a planificar y a arquitectura, no a escribir cada línea de código.
El hack secreto del prompting: referenciar otros proyectos. «Uno de los hacks secretos para usar IA de forma eficaz es referenciar otros productos. Constantemente le digo: mira en esta carpeta, porque resolví un problema similar ahí», explica Peter. La IA lee código perfectamente y entiende las ideas que ya has implementado – no hace falta explicarlas de nuevo.
Peter prefiere usar Codex precisamente porque Codex se va a ejecutar tareas de larga duración, mientras que Claude Code vuelve para pedir aclaraciones – lo que distrae cuando el plan ya está detalladamente elaborado. Esto muestra la importancia de elegir la herramienta correcta para cada fase del trabajo.
En una entrevista en vídeo Peter matiza la diferencia: «Para el coding prefiero Codex, porque sabe navegar grandes bases de código. Puedes literalmente enviar el prompt y luego hacer push a main – tengo un 95% de confianza en que realmente funciona. Con Claude Code necesitas más trucos, más “charadas” para obtener el mismo resultado». Al mismo tiempo, para el carácter y el humor del bot de Discord elige Opus: «No sé en qué entrenaron el modelo, cuánto Reddit hay ahí, pero se comporta genial en Discord. Chistes que son realmente graciosos – solo lo he visto con Opus».
Close the loop: self-verifying systems
Los agentes IA deben verificar su propio trabajo – principio clave del workflow de Peter. Diseña los sistemas de modo que los agentes puedan compilar, lintear, ejecutar y validar los datos de salida de forma autónoma.
El momento en que este principio “encajó” para Peter ocurrió en Marrakech. Le envió al agente un mensaje de voz por WhatsApp – una función que ni siquiera había implementado. Apareció el indicador de lectura, y 10 segundos después el agente respondió con normalidad. Peter preguntó: «¿Cómo lo has hecho?» El agente explicó: «Me enviaste un enlace a un archivo sin extensión. Miré la cabecera del archivo, entendí que era Opus, usé FFmpeg en tu Mac para convertirlo a WAV. Quería usar el transcriptor local, pero había un error de instalación. Entonces encontré la clave de OpenAI en tu entorno, la envié mediante curl, obtuve la transcripción y respondí». «Ese fue el momento en que entendí: estas cosas son animales increíblemente inteligentes e ingeniosos», recuerda Peter.
Pero esta ingenuidad tiene también un lado oscuro. Desde el punto de vista de la seguridad, el agente realizó una exfiltración de datos no autorizada: escaneó las variables de entorno, encontró la clave secreta y envió un archivo privado a la nube sin permiso explícito. En un entorno corporativo eso es un incidente de seguridad. El workflow de Peter prioriza la autonomía sobre el aislamiento: al agente se le dan acceso a las “llaves del reino” en pro del resultado.
Esto explica su preferencia por CI local frente a remoto: ¿para qué esperar 10 minutos en un pipeline remoto si el agente puede ejecutar los tests localmente ahora mismo? Cuando el agente detecta un problema en su código, puede corregirlo de inmediato – sin esperar feedback externo.
Peter incluso ha acuñado un nuevo término para esto – “gate” (barrera). «El agente lo llama gate… Full gate es lintear, compilar, verificar, ejecutar todos los tests. Es como un muro antes de que mi código salga al exterior».
Emerge un nuevo vocabulario para describir el trabajo con agentes IA. «Uso tantas palabras nuevas ahora… por ejemplo, “weaving in code” – entretejer código en la estructura existente. A veces hay que cambiar la estructura para que el nuevo código encaje. Poco a poco adopto su lenguaje», reconoce Peter.
El principio “close the loop” es aplicable mucho más allá del desarrollo de software: cualquier automatización se vuelve más fiable cuando el sistema puede verificar los resultados de su trabajo y corregir errores por sí mismo.
Los CLIs ganan frente a los MCPs: por qué la línea de comandos escala mejor
Peter tiene una posición clara sobre la arquitectura de integraciones: «Mi premisa es que los MCPs (Model Context Protocol) son una tontería. No escalan. La gente construye todo tipo de cosas de búsqueda raras alrededor de ellos. ¿Saben qué sí escala? Los CLI. Los agentes conocen Unix».
La lógica es simple: en tu ordenador puede haber miles de pequeños programas. Al agente le basta con conocer el nombre. Llama a --help, carga la información necesaria y usa la herramienta. «Literalmente llamamos al menú de ayuda, y luego saben cómo usar el programa».
El insight clave: «Construye para los modelos, no para las personas». Si los agentes esperan un flag --log, crea --log. Es el desarrollo agentic-driven – diseña como piensa el modelo, y todo funciona mejor. «Es un nuevo tipo de software», dice Peter.
El precio de esta flexibilidad es la seguridad. El enfoque CLI da al agente los permisos del usuario (acceso al shell), a diferencia del MCP, que limita las acciones a llamadas API específicas. Esto exige medidas de precaución estrictas (sandboxes, máquinas virtuales), ya que un agente con acceso al terminal puede ejecutar accidentalmente – o de forma deliberada mediante prompt injection – un comando destructivo.
Antes de crear OpenClaw, Peter construyó decenas de herramientas CLI: para Google Places, para Sonos, para cámaras de vigilancia, para el sistema de hogar inteligente. Cada nuevo CLI le daba al agente más capacidades – y hacía el trabajo con él más interesante. Todo ese fundamento ya existía cuando llegó la integración con WhatsApp.
Las habilidades que importan: outcomes por encima de algoritmos
La experiencia de Peter Steinberger revela patrones interesantes sobre qué habilidades y enfoques son críticos cuando se trabaja con agentes IA.
Ingenieros orientados a resultados frente a puzzles algorítmicos
Peter observa una división clara: los ingenieros que disfrutan resolviendo problemas algorítmicos a menudo tienen dificultades para adaptarse al workflow con agentes IA. Quienes disfrutan entregando productos y se preocupan por los resultados, prosperan.
En la misma entrevista lo formula de forma más contundente: «Hay personas que realmente disfrutan programando tareas complejas, pensando en algoritmos… Son exactamente las personas que luchan contra la IA y frecuentemente la rechazan – porque ese es exactamente el trabajo que la IA hace por ellas».
Esto invita a reflexionar: quizás conviene distinguir entre “buen ingeniero” en el desarrollo tradicional y “buen ingeniero” en el desarrollo asistido por IA. Las habilidades que te hacían brillar en LeetCode pueden no servir cuando la tarea principal es orquestar agentes autónomos y diseñar sistemas auto-verificables.
Para los managers, esto implica replantear el perfil de contratación. Al formar equipos asistidos por IA se necesitan no brillantes algoritmistas, sino personas que:
- Están orientadas al resultado, no a la perfección de la implementación
- Se sienten cómodas con código imperfecto si resuelve el problema
- Iteran rápidamente y cambian de dirección
- Piensan arquitectónicamente: ven el sistema en su conjunto sin perderse en los detalles
Gestionar el perfeccionismo: lección del management
Gestionar un equipo de más de 70 personas en PSPDFKit le enseñó a Peter una habilidad crítica: soltar el perfeccionismo. Cuando diriges un equipo grande, aceptas que el código no siempre cumplirá exactamente tus preferencias. Cada ingeniero tiene su estilo, sus enfoques.
Paradójicamente, esta habilidad de management resulta crítica para trabajar con agentes IA. Si no puedes aceptar que la IA escriba el código de una forma que no es exactamente como tú lo harías, te quedarás atrapado en correcciones interminables en lugar de entregar funcionalidades.
Esto explica por qué los managers experimentados pueden ser más productivos con IA que los desarrolladores junior. No porque programen mejor, sino porque han aprendido a soltar el control sobre los detalles y a focalizarse en el resultado.
Los usuarios no técnicos también pueden: el caso de la agencia de diseño
En uno de los encuentros de Agents Anonymous, Peter conoció a alguien de una agencia de diseño que nunca había programado. «Descubrió OpenClaw a principios de diciembre y empezó a usarlo», cuenta Peter. ¿El resultado? «Ahora tienen 25 servicios web – herramientas internas para todo lo que necesitan. No tiene ni idea de cómo funciona el código. Simplemente usa Telegram, habla con su agente, y el agente construye».
Este es un cambio fundamental: en lugar de suscribirse a startups aleatorias que construyen un conjunto genérico de funciones, las personas obtienen software hiperpersonalizado que resuelve exactamente su problema. Y de forma gratuita. «Las personas no técnicas lo hacen porque es natural. Solo describes el problema, y esa cosa construye lo que necesitas».
El código se devalúa: la nueva economía del software
Peter formula un pensamiento radical sobre el valor del código: «El código ya no vale tanto. Puedes simplemente borrarlo y reconstruirlo en un mes. Mucho más importante es la idea, la atención y, posiblemente, la marca – eso es lo que tiene valor real».
Esto explica su actitud tranquila ante la licencia MIT y la posibilidad de forks: «Que copien. Hagamos el open source tan bueno que no haya mucho espacio para quienes quieran convertirlo en su propio producto».
Y un reconocimiento paradójico: «Escribo mejor código ahora que no escribo código yo mismo. Y yo escribía código realmente bueno». Antes, en PSPDFKit, estaba obsesionado con cada espacio, cada salto de línea, las naming conventions. «En retrospectiva – ¿qué diablos? ¿Por qué lo hacía? El cliente no ve el interior».
¿Qué significa esto para el workflow? Si el código puede reescribirse en un mes, el foco se desplaza a lo que no puede reescribirse: las decisiones arquitectónicas, la comprensión del dominio, las relaciones con los usuarios. El workflow de Peter es consecuencia de este desplazamiento: menos tiempo puliendo código, más en diseño de sistemas.
Tradeoffs intencionales: cuando la “ineficiencia” es una estrategia
Uno de los aspectos más interesantes del workflow de Peter son sus compromisos deliberados que parecen errores desde el punto de vista del desarrollo tradicional.
El consumo de tokens como inversión en exploración
Un usuario de OpenClaw quemó 8 millones de tokens en una sola sesión – aproximadamente 200 dólares en costes de API para una tarea de configuración. Suena a catástrofe, ¿verdad?
Pero aquí está lo interesante: Peter sub-promptea de forma intencional para descubrir soluciones inesperadas. Cuando le das al agente espacio para explorar, a veces encuentra enfoques en los que tú no habrías pensado. Esto tiene sentido para un proyecto experimental que busca product-market fit.
La paradoja: lo que parece ineficiencia puede ser una estrategia de exploración para proyectos en etapa temprana. Para sistemas en producción con requisitos conocidos es un desperdicio. Para experimentos donde no conoces la solución óptima, es una inversión razonable.
Cuándo aplica el workflow de Peter
Este workflow no es universal – funciona en un contexto específico.
Aplicable cuando:
- Estás explorando una nueva categoría de producto o servicio
- La velocidad de iteración es más crítica que la estabilidad
- Tienes expertise profunda en el dominio (arquitectura, diseño de sistemas)
- El equipo es pequeño y todos comparten la visión arquitectónica
No aplicable cuando:
- Sistema en producción con SLA y obligaciones financieras
- Requisitos de compliance y datos sensibles
- Presupuesto de API estrictamente limitado
- Equipo grande y distribuido
Un arquitecto experimentado con agentes IA puede ser más productivo que un equipo corporativo – en el contexto adecuado. En el contexto equivocado, esa misma productividad se convertirá en caos con vulnerabilidades y deuda técnica.
Pronóstico para las empresas: 30% del equipo
Peter hace un pronóstico duro para el mundo corporativo: «A las empresas les resultará muy difícil implementar la IA de forma eficaz, porque eso requiere redefinir completamente cómo funciona la empresa… Probablemente puedes reducir la empresa al 30% de las personas».
Es una perspectiva inquietante, pero refleja la realidad: «Este nuevo mundo requiere personas con visión de producto, capaces de hacer de todo. Y se necesita mucho menos de esas personas. Pero deben ser personas con un nivel de agency y competencia muy elevados».
Conclusión: principios aplicables, no una herramienta concreta
6600 commits en enero – es un resultado real, que demuestra lo que es posible cuando un arquitecto experimentado combina diseño de sistemas profundo con agentes IA.
El workflow de Peter Steinberger se construye sobre cinco principios:
Las habilidades de outcomes importan más que el dominio algorítmico. La experiencia de management y la capacidad de soltar el perfeccionismo resultan más críticas que saber resolver problemas de LeetCode.
La arquitectura importa más que el código. Prompt requests en lugar de pull requests. La energía, al diseño de sistemas, no al formateo de bucles.
Close the loop. Los agentes deben verificar su trabajo. Un “gate” local en lugar de esperar al CI remoto.
Planificación antes de ejecución. El cuestionamiento detallado del plan antes de lanzar el agente – no la “magia de una sola frase”.
El contexto determina el enfoque. La exploración requiere libertad y tokens. La producción, restricciones estrictas y optimización.
Esto no es “el software engineering ha muerto” – es la evolución del rol. Cambia el nivel de abstracción: de escribir cada línea a diseñar sistemas que la IA puede extender y mantener.
¿Quieres conocer los problemas críticos de seguridad y el coste real de propiedad de OpenClaw? Lee la primera parte: análisis crítico de OpenClaw – desmontando el mito del Mac Mini, vulnerabilidades documentadas y cuándo conviene elegir alternativas probadas.
¿Utilizas agentes IA en tu trabajo? ¿Qué patrones has encontrado útiles? Puedes comentarlo abajo o en nuestro canal de Telegram.
¿Quieres aprender a trabajar eficazmente con agentes IA?
Módulo abierto del curso mysummit.school: cómo diseñar workflows asistidos por IA, elegir las herramientas correctas y evitar los errores más comunes – sin registro.
Fuentes
- Introducing OpenClaw – blog oficial – anuncio del rebranding, filosofía del nombre, últimas actualizaciones
- OpenClaw GitHub Repository – repositorio oficial con 111 000 estrellas, documentación y código fuente
- Peter Steinberger background and PSPDFKit exit – What Is Skills – biografía del creador, contexto de su experiencia
- Peter Steinberger interview – entrevista en vídeo – insights detallados sobre el workflow, filosofía «CLIs over MCPs», comparación de Codex y Claude Code, historia del mensaje de voz en Marrakech
- The Pragmatic Engineer Podcast: Peter Steinberger – podcast de Gergely Orosz – entrevista en profundidad sobre «prompt requests vs pull requests», el nuevo lenguaje del desarrollo («weaving», «gate»), pronóstico para empresas (30% del equipo), filosofía «close the loop»
- Everything you need to know about clawdbot/Moltbot – TechCrunch – visión completa del proyecto
- User experience report on practical workflow – Reddit – experiencia real de uso, consumo de tokens
- PSPDFKit creator viral Mac Mini discussion – 36Kr – contexto de creación y filosofía de desarrollo
- clawdbot hype explained – Thomas Eccel – análisis de productividad y workflow