Balance

Balance y postura (2022 -> mediados de nov. 2025)

Este diario cuenta tres años en los que puse la IA en el centro de mi trabajo, a veces de forma muy intensa. Con perspectiva, lo que queda sobre todo son convicciones y una postura: lo que guardo, lo que abandono, y la forma en que quiero trabajar con estas herramientas.

Calidad de los modelos y de los datos

Una convicción simple: la calidad de las salidas está limitada por la calidad de los datos de entrenamiento. Cuando el código público es promedio, el promedio del modelo también lo es. Un modelo “potente” no basta. Para obtener algo limpio, hacen falta reglas explícitas, contexto bien acotado y pruebas serias.

Sigo desconfiando de las modas superficiales (emojis, tono “demasiado humano”, storytelling gratuito). Lo que me interesa es lo que podemos repetir mañana en otro proyecto, no solo la demo del día.

Mi postura de director de orquesta

Al principio, mi placer era “devorar código”. Hoy, me veo sobre todo como un director de orquesta: alguien que diseña los sistemas en los que trabajarán las IAs.

En concreto, dedico más tiempo a:

• definir reglas y contratos que el código debe respetar;
• escribir pruebas y checks que actúan como barandillas;
• diseñar arquitecturas de flujo (contexto, agentes, CI);
• automatizar la recolección y la síntesis del contexto en lugar de copiarlo a mano.

El desarrollador sigue siendo crítico y quien toma decisiones. Para mí, la IA es un amplificador de pensamiento: acelera cuando el marco está claro y se desvía cuando no lo está. El prompt engineering moderno es menos una frase mágica y más un entorno bien preparado.

También es una herramienta de exploración temporal: pruebo más ideas más rápido, fracaso antes y aprendo más rápido.

Fracasos asumidos y lo que abandono

Lo que guardo de mis fracasos no es vergüenza, sino una lista de lo que no quiero repetir. No hablo de todo aquí, pero estos son los abandonos principales:

• Escaneo local exhaustivo: demasiado lento, coste exponencial. Prefiero indexación selectiva y acceso bajo demanda.
• Archivos de contexto mantenidos a mano: callejón sin salida (delegado a IAs, pero igual demasiado pesado). El contexto debe generarse y limpiarse automáticamente cuando cambia el árbol.
• Sobreingeniería de orquestación: demasiados subcomandos, scripts y ceremonias terminan costando más de lo que aportan. KISS y YAGNI no son eslóganes; son barandillas.
• Prompts mágicos sin arquitectura: “más prompts” no compensa la falta de estructura. Ahora apunto a “más arquitectura, menos prompts”.
• Reglas no comprobables: una intuición que no se convierte en una regla verificable (lint, check, test) suele desaparecer. Si puedo automatizarlo, lo automatizo.

Estos abandonos no son renuncias; son elecciones de diseño para los próximos ciclos.

Trabajar conmigo en estos temas

Si llegaste hasta aquí, es probable que estos temas también te interesen. Aquí van ejemplos de colaboraciones que me atraen (aunque sigo abierto a otros enfoques, siempre que hablemos de sistema y calidad):

• Poner rieles de IA en un proyecto existente: aclarar contexto, conectar CI y diseñar un flujo de orquestación simple pero robusto.
• Auditar / consolidar un setup de IA: revisar lo que existe (prompts, scripts, agentes, CI), detectar sobreingeniería, simplificar y documentar una nueva versión más clara.
• Co-construir herramientas o workflows open source alrededor del contexto, los MCP (potentes pero pesados en contexto), la orquestación y la calidad.
• Formar o acompañar a un equipo en uso serio de LLM para desarrollo: cómo delegar sin soltar el volante y cómo convertir intuiciones en reglas y pruebas.

Si quieres hablarlo, lo más simple es partir de un problema concreto (un proyecto, un workflow, un equipo) y ver cómo estas ideas pueden ayudarte. Sin pitch comercial, solo terreno.

Conclusión

El núcleo de mi experiencia: la IA amplifica el pensamiento que la conduce. El reto no es dejar que la IA escriba en nuestro lugar, sino pensar con ella: diseñar reglas, flujos y barandillas para hacerla útil, repetible y segura.

Comparto esto porque es concreto, y porque el cambio es nítido: del desarrollador que teclea código al director de orquesta que diseña sistemas. La continuación probablemente será otro ciclo: menos experimentación, más estabilización y más transmisión.