Gabriel Neuman
Gabriel Neuman
💡 Aprendizaje15 de mayo de 2026·gabrielneuman.com·Gabriel Neuman

De CSV legacy de 13K filas a directorio operativo en una tarde

De una base de datos muerta a vistas operativas que el equipo consulta. Lo que antes era un proyecto de tres meses hoy cabe en una sesión — y eso pasa todos los días.

💡 Aprendizaje clave

Migrar datos no es importar — es decidir qué preguntas vas a contestar antes de tocar la tabla. Cuando el modelo se diseña desde la pregunta, las vistas se construyen solas.

#data-migration#ia-aplicada#evolucion-trabajo#operaciones

Por qué cuento esto

Esto no es un caso de cliente. Es una sesión normal de un día normal. Lo escribo porque sirve para mostrar algo concreto: lo que antes una persona podía hacer en tres meses, hoy se resuelve en una tarde sentado frente a Claude Code. Y no es un día especial — esto pasa todos los días con lo que vamos trabajando.

Si estás aprendiendo a usar IA para tu trabajo operativo, este tipo de bitácora te sirve más que un tutorial. No hay magia: hay decisiones de modelado, scripts de limpieza, y vistas. Lo que cambió es la velocidad y quién hace cada parte.

Contexto

Una organización con cinco años de operación acumuló un CSV operativo de 13 mil filas. Sesiones, módulos, fechas de impartición, NPS, status. La información existía pero nadie la consultaba antes de tomar decisiones porque abrir un CSV de 13K filas no es práctico.

El objetivo no era "migrar el CSV". Era convertirlo en un directorio que el equipo consultara antes de cada asignación operativa.

Qué hicimos

Seis pasos en cadena, cuatro cerrados el mismo día:

  1. Modelo de datos. Tres tablas — entidades operativas, sesiones, y una tabla puente entre ambas. El CSV venía aplanado; lo normalicé porque las preguntas reales ("cuántas veces dictó X módulo este perfil") requieren joins, no contar duplicados.
  2. Schema en la base. SQL con índices sobre las llaves más consultadas. Permisos de fila desde el día uno.
  3. Script de limpieza. Leer el CSV original y producir tres archivos limpios. Reglas explícitas — normalizar status case-sensitive, descartar filas con valores centinela, deduplicar por combinación de fecha + código + módulo. El detalle del status case-sensitive parecía menor; era el 8% del dataset.
  4. Import + verificación de conteos. Cargar y validar contra el CSV original.
  5. Vista de directorio. Búsqueda por nombre o módulo, tarjeta con NPS promedio + cantidad de sesiones + módulos únicos, historial al hacer click.
  6. Vista de operaciones del día. Agenda con filtros, acciones para cambiar status y registrar reemplazos.

Resultado

Las cuatro tareas técnicas pesadas quedaron cerradas. Las dos vistas se construyeron sobre el modelo limpio sin retoques al schema — eso normalmente significa que el modelo aguantó la primera prueba. Quedó pendiente conectar la vista de operaciones a los handlers reales (cancelar, reasignar).

Aprendizaje clave

Hace cinco años un proyecto así implicaba: un analista que entendiera el CSV (una semana), un DBA que diseñara el schema (otra semana), un dev backend para los scripts (dos semanas), un dev frontend para las vistas (tres semanas), y QA. Tres meses fácil. Hoy es una tarde porque el modelado, los scripts y las vistas se hacen en paralelo conversando con un agente que entiende el contexto del repo entero.

No es que "la IA programe por mí" — es que las tareas mecánicas ya no son cuello de botella. El cuello de botella se movió a las decisiones: qué preguntas voy a contestar, cómo se ve el modelo, qué orden tiene sentido.

La migración fue rápida porque empezamos por la pregunta, no por la tabla. Si hubiéramos hecho lo obvio — un import de un CSV a una tabla — la búsqueda por módulo dictado habría sido imposible sin reescribir todo después. El formato del archivo nunca es la estructura correcta. El uso lo es.