Acto IAntes del código
Qué construir y dónde aterrizarlo
Un ticket sin problema detrás es deuda futura, da igual lo bien implementado que esté.
- 01 · Criterio de producto
- 02 · Diagnóstico técnico
Guía para Product EngineersProducto,
Producto,
no código.
El oficio del Product Engineer cuando la IA escribe el código por defecto.
El código es un medio, no el fin.
Gratis. Email para el PDF + newsletter semanal.
37 páginas
3 actos · 6 dimensiones
4 imprimibles
Apertura
Generar código se ha vuelto barato. Hacer producto, no.
Probablemente ya lo notas. La IA escribe el código por ti. Algunas tardes te das cuenta de que llevas tres horas aceptando sugerencias, otras tres iterando un plan, y al cerrar el portátil no sabrías reconstruir lo que has hecho. La velocidad aparente ha subido, pero algo cruje por debajo.
Si tu valor dependía de cuánto código escribías, la IA lleva ventaja sobre ti. A la diferencia es a lo que llamo oficio: seis prácticas concretas, casi siempre invisibles en tu jira, que separan al ingeniero que entrega producto del que entrega tickets.
Una nota antes de seguir. Este no es un documento sobre IA. Es un documento sobre lo que sigue siendo tuyo cuando la IA está dentro del editor.
Qué hay dentro
Tu ciclo real de trabajo, en tres actos.
Cada acto desarrolla dos dimensiones del oficio. Cada dimensión sigue el mismo patrón: síntoma de atrofia, cambio mental, tres prácticas para el lunes y la tabla con lo que cuesta no hacerlo.
Acto IIEn el código
Resistir la complejidad, dirigir la IA
El oficio en el código no es producir, es resistir. La IA empuja en la dirección contraria, no por error, sino por entrenamiento.
- 03 · Código sostenible
- 04 · Colaboración con IA
Acto IIIDespués del código
Del merge a la métrica, y a la narrativa
El merge no es la entrega. La entrega es la métrica moviéndose, y alguien que sabe contarlo.
- 05 · Ownership del outcome
- 06 · Reposicionamiento
Las seis dimensiones del oficio
Lo que no se ve en el repositorio.
Cuando el código se vuelve barato, lo que separa al ingeniero al que la herramienta sustituye del ingeniero al que la herramienta amplifica son estas seis prácticas. El resto lo hace la herramienta.
01Criterio de producto
Tu unidad de trabajo no es el ticket, es el problema que el ticket representa. Los tres porqués, el briefing en cinco líneas y la conversación de alternativas antes de implementar.
02Diagnóstico técnico
Antes de tocar un módulo, entiéndelo. Mapeo de impacto en quince minutos, la regla del archivo de al lado y el git blame curioso, para que tu PR no rompa lo que nadie había anticipado.
03Código sostenible
El código aguanta por simplicidad, no por inteligencia. Presupuesto de complejidad, doble lectura del PR y la regla del archivo más pequeño contra el reflejo de la IA de añadir capas.
04Colaboración con IA
Diriges, aunque no teclees. La IA escribe, prueba y opera cada vez más, pero no asume la consecuencia de elegir mal: esa es tuya. Pídele alternativas en lugar de soluciones, úsala para interrogar el sistema en vez de solo modificarlo, y firma siempre tú.
05Ownership del outcome
Tu trabajo no acaba con el merge. Cierra el bucle hasta la métrica, aparece tú cuando lo tuyo arde, y deja handoffs explícitos para el siguiente que entre, incluido tu yo de tres sprints.
06Reposicionamiento
Si tu manager no ve el oficio, el oficio no existe para tu carrera. Journal de decisiones, 1:1 estructurado alrededor de outcomes y tres frases honestas para cuando aparece la oportunidad.
La tesis
“El código nunca fue el producto,
era el medio.”
Lo que pagas como Product Engineer (decidir qué construir, escribir lo que aguanta y entregar más allá del merge) sigue siendo trabajo humano. La IA acelera el medio, no el fin. Este documento va de no confundirlos.
El anexo · 4 imprimibles
Hojas para usar, no para archivar.
Cuatro plantillas con cadencia explícita (lunes, durante la semana, viernes, cada 1-2 semanas) para que el oficio entre en tu rutina sin reescribir tu calendario.
Canvas typist ↔ owner
Cada 1-2 semanasUna escala por dimensión para ver, en una hoja, dónde estás operando como typist y dónde como owner. Evidencia concreta + cierre reflexivo.
Plantilla 1:1 con tu manager
Lunes (o antes del 1:1)Cuatro secciones para dejar de reportar y empezar a narrar: lo que decidí, lo que aprendí, lo que estoy mirando, dónde necesito cobertura.
Checklist semanal del oficio
ViernesSeis preguntas (una por dimensión) para mirar la semana antes de cerrarla. Casillas circulables, sin scoring, sin gamificación.
Journal de decisiones
Durante la semanaDos entradas por hoja con Decisión / Contexto / Alternativas / Outcome. Veinte entradas en un trimestre cuentan una historia que ninguna lista de PRs cuenta.
Sobre el autor
Quién escribe esto.
Emilio Carrión
Staff Engineer · 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.
Llévatelo y empieza el lunes.
Es gratis. Te lo mando por email y te dejo en mi newsletter, donde escribo cada semana sobre lo mismo.