Tu equipo no tiene una deuda técnica.
Tiene una deuda de criterio.
El cuello de botella ya no es el código. Es decidir bien cuando la IA lo escribe por defecto.
Un documento de 33 páginas con un marco de 4 dimensiones, un autodiagnóstico de 10 minutos y un canvas de decisión que puedes llevar a tu próximo 1:1.
Gratis. Email para el PDF + newsletter semanal.
Generar código es barato. Decidir bien sigue siendo caro.
El proxy dominante de productividad en software ha sido durante décadas la velocidad de salida: líneas, commits, story points, PRs cerrados. La IA acelera exactamente eso más que cualquier herramienta anterior.
Pero un equipo de ingeniería no escala por cuánto código produce. Escala por su capacidad de cambiar de dirección sin romper el sistema, sin perder contexto y sin concentrar todo el criterio en dos o tres personas.
El problema no es que la IA escriba código malo. El problema es aceptar cambios que nadie entiende del todo. La velocidad local puede empeorar el coste global cuando review, decisión, contexto y ownership no evolucionan al mismo ritmo que la generación.
Cuatro dimensiones donde se acumula la deuda de criterio.
No aparece en Jira como una tarea ni en métricas de DORA como una caída. Aparece en la calidad de la conversación: cómo se revisa, cómo se decide, qué se asume y quién se queda con el cambio cuando algo falla.
Review
Si lo que revisamos son decisiones o solo código. Si la review es un mecanismo de gestión de riesgo o un filtro de estilo.
Decisión
Si las decisiones técnicas relevantes se conversan antes de que el código ya esté escrito. Si hay criterios explícitos sobre reversibilidad.
Contexto
Si el código deja suficiente información para que otro equipo lo cambie sin perder seis semanas reconstruyendo el motivo.
Ownership
Si cada cambio relevante tiene una persona o equipo claro responsable de mantenerlo cuando falle, cambie o crezca.
Cuando generar código se abarata, aparece una pregunta nueva: ¿con qué criterio aceptamos lo que estamos cambiando, por las razones correctas y con ownership claro?
A esa tensión la llamo deuda de criterio.
Tres herramientas que puedes aplicar esta semana.
- 1
Marco de 4 dimensiones que puedes llevar a tu próximo 1:1
Lenguaje común para nombrar dónde se concentra la fricción real de tu equipo.
- 2
Autodiagnóstico para tu equipo (10 min)
16 preguntas, 4 dimensiones. Sirve mejor con dos o cuatro personas en paralelo: las divergencias son la parte útil.
- 3
Canvas de decisión técnica que puedes imprimir esta semana
Una página A4 para elevar la conversación antes de escribir, no después del PR.
Descarga el documento completo.
Es gratis. Te lo mando por email y te dejo en mi newsletter, donde escribo cada semana sobre lo mismo.
¿Quieres trabajar esto con tu equipo?
Después de la guía, hay un formato más profundo: un workshop a medida para llevarlo de la lectura individual al acuerdo de equipo.
Deuda de criterio: del marco al acuerdo de equipo.
Una sesión práctica para que tu equipo salga con dos o tres acuerdos de review y decisión escritos, aplicables desde el lunes siguiente, con responsables y fecha de revisión a 30 días.
No es una charla inspiracional sobre IA. Es trabajo de equipo sobre PRs reales, decisiones recientes y zonas del sistema donde el ownership se ha vuelto difuso.
- Formato
- 1 día completo o 2 medias jornadas
- Participantes
- 8 a 20 personas
- Modo
- Presencial o remoto
- Idioma
- Castellano o inglés
Para quién
CTOs, Heads of Engineering, EMs y Staff+ Engineers cuyos equipos ya tienen IA en producción y quieren acordar cómo revisar, decidir y repartir ownership sin acumular deuda invisible.
Entregables
- Checklist para PRs asistidos por IA adaptado a vuestros cambios de mayor riesgo.
- Technical Decision Canvas aplicado a una decisión real del equipo.
- Una regla concreta de review o decisión, escrita por el equipo, con owner y fecha de revisión a 30 días.
Emilio Carrión
Staff Engineer en Mercadona Tech · Doctorando UPV · Métodos de producción de software
Soy Staff Engineer en Mercadona Tech: construyo sistemas a escala real en retail físico. Compagino con un doctorado en la UPV sobre métodos de producción de software. Fuera del trabajo escribo para miles de ingenieros senior, doy charlas, y colaboro selectivamente con líderes técnicos y Product Engineers que están redefiniendo su oficio cuando la IA escribe el código.
El workshop lo facilito fuera de mi trabajo en Mercadona Tech, con agenda limitada para mantener la calidad.
He hablado en
Preguntas habituales.
▸¿Es teoría sobre IA o trabajo aplicable?
Trabajo aplicable. Salimos con acuerdos de review y decisión escritos, con owner y fecha de revisión a 30 días. Si quieres una charla inspiracional sobre IA, este no es el formato.
▸¿Qué tamaño de equipo encaja?
Entre 8 y 20 participantes. Por encima de 20 la conversación se diluye; por debajo de 8 no hay suficientes voces para que aparezcan los desacuerdos útiles.
▸¿Para qué seniority está pensado?
CTOs, Heads of Engineering, EMs y Staff+ Engineers que ya tienen IA en producción. Mezclar perfiles es deseable: las divergencias de criterio entre roles son la parte útil.
▸¿Remoto o presencial?
Ambos. Presencial funciona mejor para salir el mismo día con un acuerdo cerrado por escrito; remoto requiere romper el bloque en dos medias jornadas con trabajo asíncrono entre sesiones.
▸¿En qué idioma?
Castellano por defecto. Inglés disponible si el equipo es internacional.
▸¿Cómo encaja con tu trabajo en Mercadona Tech?
Es trabajo selectivo fuera de mi rol en Mercadona Tech. Mantengo agenda limitada de engagements para no comprometer la calidad ni el horario.
▸¿Qué pasa después del workshop?
Os quedáis con los acuerdos por escrito, los responsables y la fecha de revisión a 30 días. Si queréis, paso ese día a hacer una revisión ligera: ver qué acuerdos han aguantado el contacto con la realidad y cuáles hay que reescribir.
¿Lo quieres traer a tu equipo?
Escríbeme con tres datos: tamaño del equipo y tu rol, dónde aparece la fricción con un ejemplo concreto, y qué habéis intentado ya. Respondo en 48h laborables, honestamente, te diga lo que te diga.
Escríbeme: hola@emiliocarrion.com →