Retrospective: Un mes de Vibe Coding a tope con Claude para almacenamiento local en el juego

Este último mes en el curro me metí de lleno a hacer "vibe coding" con Claude (normalmente tiro de Gemini para mis cosas). La empresa nos soltó una cuota de API brutal, y me encasquetaron desarrollar una función nueva de almacenamiento local para la galería de fotos del juego. Así que le di la vuelta a mi forma de currar: yo haría de arquitecto para el diseño general, y dejaría que Claude Opus 4.6 fuera el picacódigos (code monkey).

Después de un mes dándole duro, hablando en plata: cuando sabes exactamente lo que quieres, la IA es una bestia. Pero en el segundo en que empiezas a cambiar cosas o a cazar bugs, la experiencia humana no se puede reemplazar ni de coña.

Cuando sabes lo que quieres, lo revienta

Durante la fase inicial de montaje, siempre que le marcara unos límites estrictos, Claude escupía exactamente lo que le pedía.

Por ejemplo, para que los archivos de la galería no se corrompieran, le pedí una medida de seguridad. Claude lo pilló al vuelo y se sacó de la manga un patrón WAL (Write-Ahead Logging) impecable directo de SQLite. Clavó la lógica para los archivos temporales, reemplazos atómicos y recuperación. En este punto, si le dejas las cosas claras, la IA se come el trabajo sucio y te ahorra horas de picar boilerplate (código repetitivo).

Baño de realidad: La visión de túnel de la IA con los bugs

Pero la luna de miel se acabó en cuanto empezamos a retocar cosas y arreglar fallos. Ahí es donde se le ven las costuras a Claude.

El mayor problema de la IA es que tiene cero visión global. Cuando la lógica choca, su primera reacción es hacer una chapuza (ponerle una tirita). Le flipa meter flags booleanos a lo loco o abrir nuevos if-else en lugar de dar un paso atrás y encajar el parche en el sistema completo. Si le haces caso a ciegas, tu código se volverá inmanejable en cero coma.

Una cagada de manual: Reference Counting en Texture2D

Me comí un ejemplo de manual de esto mientras montaba un sistema de reference counting para el caché de Texture2D en C#.

La idea era gestionar la memoria de las páginas de la galería. Dividí el caché en dos zonas: activa e inactiva. Si una textura tiene referencias, se queda activa; si llega a cero, va al pozo de las inactivas, lista para ser eliminada.

La cosa se fue al traste al mezclar callbacks asíncronos con las referencias. Claude escribió una lógica de timing rotísima: mandaba la página a la zona inactiva antes de marcar la referencia. Esto provocaba una race condition brutal. Si el caché ya estaba a tope, mandarla a inactiva disparaba la limpieza al instante, cargándose la página antes de que el asíncrono pudiera siquiera marcar la referencia.

¿La genialidad de Claude para arreglar esto? Meter un flag súper cutre llamado is_early_marked para saltarse todo el problema del ciclo de vida.

Lo corté de raíz. Como me conozco el ciclo de vida del componente, le di una regla innegociable: retrasa toda la limpieza de la página inactiva hasta después de que la operación asíncrona marque la referencia. Tocando el timing a nivel de arquitectura, el bug quedó aplastado por completo, sin meter flags guarros.

En resumen

Todo este rollo demuestra que, aunque la IA te hace programar a toda pastilla, es súper fácil que te esconda deuda técnica.

Si un dev junior se cruza con ese bug asíncrono, lo más seguro es que hubiera mergeado el fix cutre de Claude. Avanza unas semanas y tienes un montón de flags y ramas que no sirven para nada, y un módulo que no hay por dónde cogerlo. Con el vibe coding, no tienes que picar cada línea de código tú mismo, pero no perder de vista el panorama general y evitar que se convierta en código espagueti es un curro exclusivo de humanos.