Cómo una tarea llega a producción
Cómo trabajo realmente en 2026: cada tarea pasa primero por dos filtros —si puede evitar el trabajo manual y si se puede acelerar la escritura— y solo después llega al código. Abajo, toda la cadena paso a paso.
Condición previa — dueño o ejecutorEl filtro solo funciona cuando soy dueño de mi área
Promova reconfiguró mi forma de pensar: no solo ser desarrollador, sino validar cada tarea que me llega. No «cómo construyo esto» sino «qué aporta al negocio». Ese filtro, eso sí, solo funciona bajo una condición.
La tarea pasa por el filtro de inmediato. Respondo por el resultado, así que tengo autoridad para decir «esto no debería construirse en absoluto» o «esto no debería construirlo yo».
Sin filtro. Hay una tarea, un plazo y una entrega. Nada malo en ello — es simplemente otro contrato.
La diferencia no es la habilidad, es el mandato. Una unidad independiente que es plenamente dueña de su área le cuesta a la empresa menos que un ejecutor — porque no construye lo innecesario.
Antes del código
Llega una tarea
No empiezo por «cómo construyo esto». La primera pregunta es qué aporta al negocio; la segunda, si de verdad hay que construirlo a mano, y si me toca a mí.
Filtro uno — ¿se puede evitar por completo el trabajo manual?
Tres salidas, y las tres responden a una pregunta: quién lo hace a partir de ahora. Si la tarea toma cualquiera de ellas, deja de ser mía y mi capacidad queda libre para el trabajo que de verdad necesita un desarrollador.
salidas del pipeline- Lo hace un agente
Se configura una vez y no vuelve a nadie. A partir de ahí un agente la ejecuta y la completa por su cuenta, sin ninguna intervención.
Revisión de código automática · la analítica cae directa en un canal de Slack dedicado, en vez de sacar logs a mano
- Lo hace quien lo pide
La tarea no llega hasta mí. Quien la necesita la hace por su cuenta junto con la IA — lo mío es construir el camino una vez.
Mailing de outreach · plataforma de influencers
- Lo hace el equipo
Una funcionalidad o plugin cosido al sistema, a través del cual el equipo hace los cambios por su cuenta — sin ticket, sin desarrollador.
Plugin de redirecciones en el CMS a cargo del equipo de SEO
Filtro dos — acelerar la escritura misma
La tarea superó el filtro uno, así que es mía. Siguiente pregunta: ¿es rutina en términos de código? Si el patrón se repite —estilos de botón, una estructura recurrente— primero le escribo un skill y solo después el código. Una vez más largo, cada vez después más rápido.
Decisión
Plan mode — análisis antes de una sola línea
Tengo que vivir este código, no recibirlo. El plan decide quién lo escribe.
- No conozco este código
- Lo escribo yo.
- Conozco este código
- Lo escribe el agente.
- No lo conocía, pero el plan lo dejó claro
- Lo escribe el agente.
Entrega
Implementación
Empieza a escribir quien haya elegido el plan — yo o el agente.
Comprobaciones en dev — el agente
Comprueba el agente, no yo: recorre el flujo con Playwright o lee los errores directamente del dev server de Next.js por MCP. Aquí no gasto nada de mi capacidad.
Comprobaciones en modo build — el agente
Dev miente. Otros chunks, otras optimizaciones, otro comportamiento. Algo que funciona en dev y muere en build es un clásico, así que build tiene su propia pasada — de nuevo la conduce el agente.
Tests unitarios + Playwright
Solo cuando de verdad funciona. Tests unitarios para la lógica, Playwright para el flujo — también los escribe el agente.
Staging — aquí entro yo
El primer punto que reviso a mano yo mismo. En local solo cuando la tarea es sensible. Luego va a QA — en ese orden, no al revés.
Pull request
Lo revisan agentes con los skills que gobiernan esa zona del proyecto: un cambio de rendimiento se contrasta con las reglas de rendimiento; uno de pagos, con las reglas de pagos.
Producción
Release.
Comprobación final
QA en producción. Si aguanta — listo.
- OOP
- SOLID
- DRY
- KISS
- YAGNI
- CI/CD
Conociendo las prácticas de arquitectura y manteniendo el orden de los pasos, se puede escribir código rápido y bien a la vez. La velocidad viene de la secuencia, no de teclear más rápido.
La experiencia en una tecnología concreta siempre produce mejor código — eso no se discute. Pero no se transfiere: cambias de stack y empiezas de cero. La comprensión del flujo de desarrollo, de la arquitectura y de los principios se transfiere por completo. Es lo que permite trabajar en un código que aún no conoces: plan mode (paso 04) muestra cómo está montado este proyecto en concreto, y juzgar si una solución es la correcta es algo que ya sabes hacer.