Se ha añadido un conjunto de principios de ingeniería compartidos para todos los Agentes de OpenClaw, 5 reglas: 1. Módulos profundos: si se puede reducir un parámetro de interfaz, se debe hacer, y las funcionalidades deben desarrollarse en profundidad. 2. Ocultación: todos los ID, rutas y claves deben gestionarse a través de la configuración; el código duro en los scripts es una fuga de información. 3. Manejo de errores: si un archivo no existe, devolver un valor vacío en lugar de provocar un fallo; si hay un desbordamiento de parámetros, recortarlo automáticamente sin generar un error. 4. Programación estratégica: cada vez que se realice un cambio, dedicar entre el 10% y el 20% del tiempo a mantener el diseño; cualquier script debe ir acompañado de documentación. 5. Escribir comentarios antes de escribir código: primero definir qué se va a hacer y luego cómo se va a hacer; los comentarios son el prompt para la IA. Se ha redactado como ENGINEERING.md y se ha colocado en agents/shared/; todos los SOUL.md de los Agentes lo referencian. El mayor problema de la IA al escribir código es que solo se preocupa por la funcionalidad y no por la arquitectura. Estas 5 reglas, en esencia, están restringiendo el comportamiento de la IA: debes indicarle qué son las buenas prácticas de ingeniería, de lo contrario, generará el código más difícil de mantener de la manera más rápida.

En la era de la IA, hay varios cambios en la programación: El valor de los comentarios no solo no disminuye, sino que aumenta. La premisa para que la IA te ayude a escribir código es que puedas expresar claramente lo que quieres: los comentarios son el prompt para la IA. Si no sabes escribir buenos comentarios, la IA no podrá salvarte. "Diseñar dos veces" se ha vuelto especialmente fácil. Antes, implementar manualmente dos soluciones y compararlas era demasiado costoso y nadie quería hacerlo. Ahora, hacer que la IA genere rápidamente dos o tres soluciones para compararlas es cuestión de minutos. Pero la IA también está creando nuevos problemas: le gusta generar un montón de pequeñas clases, getters/setters y sobrecarga de encapsulamiento, todo son módulos superficiales. La crítica de Ousterhout sobre la "classitis" se está produciendo en masa por parte de la IA. Así que al final, volvemos a lo mismo: la gestión de la complejidad es un trabajo humano. La IA puede escribir código, pero no toma decisiones arquitectónicas. ¿Dónde están los límites de los módulos? ¿Cómo se debe ocultar la información? ¿Qué tan profundos deben ser los interfaces? Estas cosas la IA no puede entender. En resumen, los requisitos para los programadores en la era de la IA han cambiado: La capacidad de escribir código está devaluándose, mientras que la capacidad de diseñar sistemas está en aumento. Antes, dependías de tu velocidad y memoria, ahora la IA puede hacer todo eso. Pero, ¿puedes descomponer un sistema complejo en varios módulos profundos, asegurando que cada interfaz sea lo suficientemente limpia para que la IA la entienda? Esa es una habilidad que la IA no puede reemplazar.

Siempre ha sido Claude quien me ayuda a elaborar el plan de Openclaw. Ahora incluso le he dejado algunas tareas simples directamente a Claude. El problema es, ¿quién sabe cuándo de repente te pueden cerrar la cuenta? Ni siquiera hay un mecanismo de respaldo. Con Openclaw se puede cambiar de modelo en cualquier momento, y las habilidades de memoria se pueden empaquetar y llevarse.