# El volumen de código se multiplicó Cada semana sale más código y más funcionalidades, y las horas para revisarlo son las mismas. El loop que uso hoy, con qué valido, y qué se delega y qué no. 26 jul 2026 · https://e1i0.com/es/el-volumen-de-codigo-se-multiplico.html --- *Cuando digo IA en este post, me refiero a la ola actual: LLMs, agentes, asistentes de código.* Cada semana sale más código y más funcionalidades a producción. Las horas que tengo para revisar todo eso son las mismas de siempre. Antes se me iba el tiempo escribiendo. Ahora se me va revisando. ## ¿Qué puede salir mal? En lo crítico hay que tener cuidado: - **Inventa.** Se saca de la manga algo que no existe. - **Agrega cosas que nadie pidió.** Capas y dependencias que después alguien tiene que mantener. - **Falla en medio de una funcionalidad importante**, y te deja el trabajo a medias. - **Te resuelve el problema como si fueras otra empresa.** Una arquitectura pensada para una escala que no tienes. - **Se equivoca más cuando lo dejas solo.** Sin contexto de cómo se trabaja en el proyecto, decide por su cuenta y acierta menos. - **Hay días en que rinde menos.** El mismo modelo, la misma tarea, y el resultado no es el mismo. No siempre hay explicación. - **Se cae el servicio.** Y te agarra en la mitad de algo. ## Mi loop 1. Definir bien las tareas. 2. Asegurarme de sacarlas lo mejor posible, apoyado en las herramientas que el proyecto ya tiene puestas y en skills que dicen qué hacer y cómo. Soltarle todo y dejarlo libre es tentador, y a veces te trae problemas. > Tablas nuevas. Flujos enteros que nadie usa. Después toca borrarlos. 3. Deployar rápido. 4. Validar **periódicamente** que todo siga funcionando. Parte automático, parte a mano. > Sentarme, abrirlo y ver si aquello hace sentido. No si pasa las pruebas solamente, si **hace sentido**. El trabajo acá es compartido, y toca iterar para encontrar qué se delega y qué se hace a mano. El cuarto punto es el que sostiene todo lo demás. Y hay una regla: **el loop tiene que darte valor, no bloqueo**. Por eso la validación es periódica y no una puerta que te frena antes de cada cosa. ## Con qué valido Esto es lo que uso hoy. - **Pruebas end to end, una por flujo completo, corriendo periódicamente en producción.** Para mí son las más importantes hoy. No te dicen si un pedazo funciona, te dicen si el camino completo sigue funcionando, que es lo que usa la gente. - **Pruebas unitarias y de integración**, que hoy tienen que estar mejor que nunca. Con tanto código generado, son las que te avisan cuando algo nuevo rompió algo viejo. - **Un modelo revisando cada PR en loop**, contra skills que ya tengo definidas. Lo simple lo aprueba solo. En lo crítico se pone más estricto y valida a fondo. No lo quiero opinando bonito, lo quiero comprobando cosas puntuales. - **Un modelo revisando calidad por su cuenta, cada cierto tiempo**, que en vez de dejar comentarios sueltos **genera tickets** de lo crítico. Así el hallazgo entra al trabajo real y no se pierde. - **Integraciones por [MCP](https://modelcontextprotocol.io) para que todo pase por un solo lado.** El modelo llega al repo, a la base de datos, al navegador y a los tickets sin que yo ande saltando de herramienta en herramienta. Es lo que hace que el loop sea uno solo y no cinco pedazos sueltos. > Ojo con los permisos y con lo que le dejas hacer. Darle acceso a todo es darle también con qué borrar cosas en producción. Eso da para un post aparte. - **En frontend, que el propio modelo navegue la interfaz.** Con [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp), el oficial del equipo de Chrome, el modelo abre la página, hace clic, mira la consola y te dice si aquello quedó bien. Leer el código y mirar el resultado son dos cosas distintas. - **Skills para organizar el trabajo.** Los [agent-skills de Addy Osmani](https://github.com/addyosmani/agent-skills) traen el ciclo ya armado (planear, construir, probar, revisar, simplificar) con perfiles de revisión distintos (código, seguridad, rendimiento). Y [superpowers](https://github.com/obra/superpowers) para planear y poder retomar donde ibas. - **Los skills de revisión y seguridad que ya vienen**, `/code-review` y `/security-review`. Y los propios, que valen la pena porque son los que saben cómo se trabaja en tu proyecto. - **[CodeRabbit](https://coderabbit.ai)** como capa extra sobre el PR. Otro ojo encima, que no encuentra lo mismo que los demás. Ayuda bastante. ## La misma configuración toda la semana Yo trato de **mantener la misma versión, el mismo esfuerzo y el mismo modo durante toda una sesión, o toda una semana**. Así evito que el modelo vea las cosas distinto cada rato y me cambie el criterio a medio camino. Va en contra de lo que suele recomendarse, que es elegir el mejor modelo para cada tarea y mover el esfuerzo según lo que estés haciendo. Yo no soy muy de seguir reglas, así que probé al revés. Y me ha ido mejor. Antes de jugar con las configuraciones prefiero optimizar otra cosa: **gestionar bien los tokens**. Documentos con el plan escrito, para no volver a pensar lo mismo cada vez. Y herramientas tipo [graphify](https://graphify.net/) para que no tenga que releer todo el proyecto en cada consulta. Si toca variar, más o menos así: - **Modo de razonamiento para planear.** Es donde más se nota. - **Esfuerzo alto o muy alto para bugs.** Un bug difícil se paga solo. - **Modelos menos avanzados para documentación.** No hace falta artillería para eso. Primero el plan escrito y el ahorro de tokens. Después las configuraciones. ## Afilar la sierra Un leñador lleva horas cortando un árbol con la sierra sin filo. Le preguntan por qué no para a afilarla: > No tengo tiempo, estoy muy ocupado cortando.

Del séptimo hábito de Los 7 hábitos de la gente altamente efectiva, de Stephen Covey.

Vale la pena dedicarle un tiempito a que cada proyecto quede pulido con sus herramientas y su forma de trabajo, para que el modelo ya sepa cómo funciona todo ahí y no tenga que improvisar. Que cada proyecto tenga su manera, escrita, y que sea siempre la misma. Cuesta un rato al principio. Después todo sale más rápido, y sobre todo sale más parecido a lo que querías. ## Al final El modelo genera. Qué revisar, y hasta dónde, lo decides tú. Igual me queda la duda de si esta es la mejor forma. Siento que falta algo, que todavía no está en su punto. Puede que no llegue nunca, y lo que toca es seguir iterando. Y quedan preguntas para el próximo: > Si el mismo modelo rinde distinto de un día a otro, y cada versión nueva ve cosas que la anterior dejaba pasar: > > - ¿Qué haces con todo el código y la documentación que ya salieron? > - ¿Los mandas a revisar otra vez con el modelo nuevo? > - ¿Y si esa revisión te devuelve hallazgos que no hacen sentido? > - ¿Los reescribes? > - **¿Cómo sabes si de verdad quedaron mejor?**