Disciplina de Código Mínimo
Usa esta habilidad para aplicar una disciplina de código mínimo (YAGNI-ladder) al planificar y escribir cambios de código. Mantiene los diffs pequeños y evidentemente correctos sin sacrificar las comprobaciones que mantienen seguros a los usuarios.
Esta habilidad complementa a ai-slop-cleaner: esa habilidad limpia el desorden después de que llega; esta evita que se escriba.
Cuándo Usar
Usa esta habilidad cuando:
- el usuario solicite una implementación mínima, ligera, YAGNI o con el diff más pequeño posible
- un plan o cambio en curso esté creciendo más allá de la solicitud indicada
- estés escribiendo código nuevo donde sea probable la expansión del alcance, la reinvención de ayudantes o la generalidad especulativa
- estés revisando un diff propuesto por su tamaño antes de la implementación
Cuándo No Usar
No uses esta habilidad cuando:
- el usuario solicite explícitamente una compilación amplia, rica en funcionalidades o preparada para el futuro (su alcance explícito prevalece)
- la tarea sea un andamiaje exploratorio que el usuario haya marcado como desechable
- la presión de minimización pueda afectar el comportamiento protegido (ver No Negociables)
La Disciplina
Existencia primero. Pregunta si el cambio necesita existir en absoluto; omite el trabajo que solo sirve a una necesidad futura especulativa.
Reutilizar antes de escribir. Busca en el código base un ayudante, tipo o patrón existente antes de escribir algo nuevo. Nunca copies un ayudante que ya viva a unos pocos archivos de distancia; reutilízalo o extráelo a una ubicación compartida.
Escalera de dependencias. Recurre primero a la biblioteca estándar, luego a la capacidad nativa de la plataforma, luego a una dependencia ya instalada. El código escrito a mano es el último recurso. No introduzcas una nueva dependencia cuando basten unas pocas líneas de código, a menos que el usuario lo haya solicitado o aprobado explícitamente.
Comprender antes de minimizar. Lee el código afectado y sigue su ruta de ejecución primero. Entrega el diff correcto más corto una vez que el problema esté comprendido; el código que nunca escribes nunca falla.
Aburrido sobre inteligente. Prefiere código aburrido y evidentemente correcto sobre código inteligente.
Marca el techo. Registra las simplificaciones deliberadas con un comentario breve que nombre el límite aceptado y lo que justificaría reemplazarlo.
Causa raíz, no síntomas. Corrige los errores en la causa raíz compartida por todos los llamantes, no con un parche separado para cada síntoma reportado.
No Negociables
Nunca minimices:
- la validación dondequiera que se cruce un límite de confianza
- el manejo de errores que proteja contra la pérdida de datos
- los controles de seguridad
- los fundamentos de accesibilidad
- el alcance que el usuario solicitó explícitamente
Verificación
Antes de informar la finalización, confirma:
- cada línea añadida se gana su lugar (sin generalidad especulativa, sin ayudantes duplicados)
- el diff es el más corto que resuelve correctamente el problema planteado
- los elementos no negociables están intactos
- las pruebas siguen pasando y el comportamiento no ha cambiado excepto según lo solicitado