Reflexiones sobre el desarrollo con IA tras dos meses en una gran empresa tecnológica

Contexto

Todo empezó con varias reuniones uno a uno con mi líder de equipo. Le interesaba mucho cómo uso las herramientas de IA, cómo armo mis propios Harnesses y cómo estructuro mi flujo de trabajo de AI Coding. Principalmente porque estoy entregando requerimientos rápido y bien, al punto de que ya soy el responsable principal de algunos proyectos. Así que aproveché la oportunidad para organizar mi flujo diario con IA. Hoy en día, en mi equipo me dedico sobre todo al desarrollo de Agentes, mientras mantengo la lógica de negocio del backend existente.

Antes había compartido flujos similares en Xiaohongshu. En ese momento, el contexto era que GPT-5.4 y Opus 4.6 ya podían completar tareas sin problema si les dabas un contexto preciso y restricciones razonables. El auge del Harness Engineering hizo que todos nos diéramos cuenta de algo: puedes controlar mejor a los modelos más potentes agregándoles restricciones.

Por ejemplo, Skills como Superpowers ofrecen una implementación bastante pesada, centrada principalmente en Spec y TDD, que ayuda a organizar y avanzar con las tareas de forma más sencilla.

Pero hacerlo así tiene sus contras. Lo que más se nota es esto: el consumo de Tokens se dispara. Skills como Superpowers incluyen muchos Workflows diseñados para restringir la siguiente acción del modelo. Incluso si, a nivel global, cierto paso ya no hace falta —por ejemplo, si el contexto es suficiente y se puede empezar a implementar directo—, el modelo igual puede seguir ejecutando el proceso predefinido.

Con el lanzamiento de nuevos modelos, he visto a muchos desarrolladores contar que básicamente ya no usan estos Skills tan pesados. Una razón clave es que, al mejorar las capacidades de los modelos, algunas restricciones y procesos que antes creíamos útiles ahora solo son ruido para ellos. Por ejemplo, cuando OpenAI lanzó Astra, publicaron un artículo específico explicando cómo limpiar Skills y system prompts innecesarios para mejorar la experiencia de uso del modelo.

Por eso, en este artículo voy a combinar lo que he practicado estos últimos meses para compartir algunos métodos que hoy me funcionan muy bien, y hablar sobre cómo aprovechar mejor distintos Agentes para ser más eficientes en el día a día.

1. Mis Skills y Prompts más usados

Cómo divido mis herramientas actualmente:

Hoy uso principalmente Codex + GPT-5.6 Sol para implementar código, y Astra para planificar. Antes de que saliera Astra, le delegaba la planificación a GPT-5.6 Sol Max.

Para requerimientos simples, uso pi + DeepSeek V4 Flash para implementar; la revisión adversarial de soluciones y el Code Review los dejo casi siempre en manos de Claude 5 Fable. En proyectos personales, también uso la versión web de GPT-6 Pro para el diseño principal de la solución.

Mis Skills más usados

1. think: el Skill de tw93, lo uso sobre todo para alinear soluciones y hacer brainstorming.
2. grill me / grill with docs: lo uso principalmente para clarificar requerimientos. A base de preguntas constantes, aclara objetivos, restricciones y trade-offs, y luego los deja documentados en un ADR o en CONTEXT.md según lo pida el proceso de desarrollo. Me ayuda a sacar a la luz cosas que no pensé durante la alineación inicial.
3. implement: lo uso junto con grill, es parte del paquete de Skills de Matt Pocock, sirve para implementar planes o Issues que ya están bien definidos.
4. ponytail: lo uso para limpiar el sobre-diseño de la IA y facilitar el Review. Lo uso bastante porque GPT-5.6 Sol tiende a sobre-diseñar seguido.
5. handoff: organiza el contexto actual en archivos para poder retomar la tarea en sesiones nuevas. Por lo general lo uso para pasar el trabajo de Codex a Claude Code o al agente pi.
6. check: lo uso para code review, normalmente al enviar MRs.
7. Skills que fui armando con el trabajo y proyectos personales: sobre todo SOPs de procesos reutilizables, como pruebas end-to-end. Mi consejo es que, en el día a día, si repites un proceso más de tres veces, le pidas a Codex que te lo organice como Skill para reutilizarlo directo después.

Mis Prompts más usados

Hoy casi nunca escribo bloques gigantes de Prompt yo mismo. Cuando lo necesito, suelo pedirle a Codex que me los arme. Por ejemplo, si después de varias rondas de discusión quiero pasarle el contexto actual a GPT Pro para diseñar la solución, primero le pido a Codex que genere un Prompt de handoff completo.

Fuera de eso, uso mucho estos tipos de Prompts súper cortos.

A veces logran el efecto de "una frase que vale por mil". Yo los entiendo como "atajos de pensamiento" para el modelo.

No son fórmulas mágicas, sino metodologías altamente estandarizadas dentro del conocimiento humano. Durante su entrenamiento, el modelo vio muchísimos papers, código, documentos de diseño y discusiones relacionadas, así que muchas veces no hace falta escribir cientos de líneas de Workflow a mano: basta con decirle qué método de pensamiento aplicar. Estos son algunos prompts que me dieron muy buenos resultados en la práctica:

• Primeros principios (First Principles): No sigas optimizando sobre la solución actual, vuelve a preguntar cómo debería resolverse realmente este problema. Por ejemplo, si una interfaz es lenta, puedes decir:

No sigas diseñando basándote en la solución establecida de "agregar caché Redis". Analiza desde primeros principios por qué esta interfaz es lenta y cuál es la solución mínima necesaria.

El foco del modelo pasa de "cómo debería diseñarse Redis" a:

¿El cuello de botella está en SQL, en la red, en la serialización, en la contención de locks o en cálculos repetidos? Si agregar un índice en SQL lo resuelve, ¿para qué meter Redis?

Este tipo de Prompt viene perfecto cuando sospechas que "la pregunta en sí podría estar mal".

• Revisión adversarial (Adversarial Review): No busques razones para defender mi solución, intenta demostrar que está mal.

La forma común de pedirlo sería:

Ayúdame a ver si hay algún problema con esta solución técnica.

Se puede cambiar por:

Haz una revisión adversarial de esta solución, priorizando encontrar contraejemplos que puedan derribar las suposiciones principales.

Si tu solución es "introducir locks distribuidos para resolver solicitudes duplicadas", el modelo ya no solo te dirá cómo configurar el timeout del lock, sino que empezará a preguntar:

¿De verdad las solicitudes duplicadas necesitan exclusión mutua? ¿Se puede resolver con idempotencia en la interfaz? ¿Qué pasa si el servicio de locks se cae? ¿Qué pasa si el lock expira pero la lógica de negocio no terminó de ejecutarse? ¿Introdujimos un nuevo punto de falla distribuido para resolver un problema local?

Este tipo de Prompt es ideal para revisiones de soluciones y Code Reviews.

• Experimentos de ablación (Ablation Experiments): Que el sistema mejore no significa que todo lo que agregaste sirva.

Por ejemplo, si hiciste tres optimizaciones de golpe:

Después de agregar índices, caché Redis y consultas por lotes, la latencia de la interfaz bajó de 800ms a 100ms.

En ese momento, puedes preguntar directamente:

Diseña experimentos de ablación para estas tres optimizaciones y determina de dónde vienen realmente las mejoras.

El modelo va a diseñar controles con distintas combinaciones, partiendo del Baseline, comparando solo agregar índices, índices + caché, índices + caché + consultas por lotes, etc.

Al final, podría descubrir que:

Solo agregar índices ya redujo la latencia de 800ms a 120ms; las otras dos soluciones complejas aportaron apenas 20ms.

Así sabes mucho mejor qué código vale la pena conservar y qué complejidad quizás sobra.

• La navaja de Ockham (Occam's Razor): Cuando los efectos son similares, prioriza soluciones con menos suposiciones y menor complejidad.

Por ejemplo, si el Agente diseña una solución así:

Kafka + Redis + Lock Distribuido + Máquina de Estados + Compensación programada.

Puedes agregar una línea:

Vuelve a revisar este diseño usando la navaja de Ockham, eliminando todos los mecanismos que no sean esenciales, siempre que se cumplan los requerimientos.

Muchas veces termina descubriendo que:

El escenario actual solo implica escrituras en una sola base de datos; con una transacción y un índice único alcanza.

Esta frase le viene genial a los Coding Agents actuales, porque los modelos tienden a sobre-diseñar por querer ser "completos".

• Alta cohesión, bajo acoplamiento: Vuelve a revisar las responsabilidades y límites del código.

Por ejemplo, si ves que OrderService ya tiene 2000 líneas, puedes pedir:

Revisa los límites de responsabilidad de OrderService según los principios de alta cohesión y bajo acoplamiento; no lo dividas solo por dividir.

El modelo suele empezar a verificar:

¿Por qué el servicio de pedidos maneja a la vez inventario, cupones, SMS, pagos y reportes? ¿Qué lógica pertenece realmente al dominio de pedidos y cuál debería delegarse a otros módulos mediante interfaces estables?

Esto no activa un simple "dividir archivos", sino todo un conjunto de criterios sobre modularización, ocultamiento de información, dirección de dependencias y división de responsabilidades.

Por eso, casi nunca escribo cosas como:

Paso 1 analizar requerimientos, Paso 2 verificar suposiciones, Paso 3 buscar alternativas, Paso 4...

El modelo ya aprendió muchísimas metodologías maduras. Prefiero decirle directamente:

Vuelve a analizar desde primeros principios, haz una revisión adversarial de la solución actual; los mecanismos clave deben validarse con experimentos de ablación; la solución debe seguir la navaja de Ockham y el código mantener alta cohesión y bajo acoplamiento.

Detrás de esas pocas palabras, en realidad estás definiendo cinco acciones cognitivas distintas:

Redefinir el problema → Atacar las suposiciones → Verificar los aportes → Eliminar complejidad → Organizar los límites del sistema.

Y así entiendo yo el cambio en el Prompt Engineering en esta nueva era de modelos: en lugar de escribirle al modelo un proceso de pensamiento fijo y completo, es mejor usar metodologías precisas para decirle "de qué manera pensar", y después sumar solo las restricciones que de verdad hagan falta para la tarea actual.

2. Mi flujo de desarrollo diario

Cuando recibo un requerimiento, primero suelo pasarle el contexto relevante al Agente, como el PRD, minutas de reuniones, chats y feedback de usuarios, y luego uso grill para alinear los requerimientos con él.

Estos materiales casi nunca forman un requerimiento completo y consistente. Puede que el PRD esté desactualizado, que en las reuniones se hayan sumado restricciones o que en los chats se hayan ajustado prioridades. Incluso mi propia interpretación del requerimiento puede tener suposiciones implícitas.

Dejo que el Agente entienda todo esto apoyándose en la Wiki del equipo y el código existente, y luego aclaro objetivos, límites y trade-offs que afectan la implementación a través de preguntas constantes. Algunas las puedo responder ahí mismo, otras me obligan a volver a confirmarlas con producto o con otros compañeros.

Acá manejo una regla clara: cuando las dudas que quedan ya no van a cambiar significativamente el rumbo de la implementación ni los criterios de aceptación, podemos empezar a desarrollar.

No le exijo que planifique cada detalle de implementación por adelantado, porque si no, la misma alineación de requerimientos se vuelve un proceso pesadísimo.

Las conclusiones de esa alineación las dejo plasmadas en un Spec o en CONTEXT.md, donde anoto principalmente el problema a resolver esta vez, el alcance, las decisiones clave y los criterios de aceptación. Esto también facilita que los Agentes que después se encarguen de implementar y revisar compartan el mismo contexto, sin tener que releer todas las conversaciones anteriores.

Una vez definida la solución, dejo que el Agente principal decida cómo ejecutarla según la complejidad de la tarea. Los requerimientos simples se implementan directo; los complejos se dividen en Issues con límites claros que se puedan aceptar de forma independiente. Solo las partes que pueden avanzar solas se delegan a subagentes para desarrollarlas en paralelo en distintos worktrees, y al final el Agente principal las integra.

El agente de código completa las pruebas primero. Cuando considera que está listo para entregar, meto otros Agentes para una revisión cruzada adversarial, dependiendo de la complejidad de la tarea. Los problemas que aparecen se le reportan todos juntos al agente de código principal, o sea, Codex, que los corrige y vuelve a verificar.

Antes de hacer mi propio Review, también corro pruebas end-to-end.

Hoy no leo línea por línea todo el código generado; me enfoco sobre todo en los resultados de las pruebas y en la lógica de negocio central. Acá hay una condición clave: cada MR tiene un alcance lo suficientemente chico, y los flujos de negocio completos se van validando de a poco a medida que avanza el desarrollo.

Los MRs chicos mantienen los cambios que exigen comprensión y criterio dentro de rangos manejables cada vez; las pruebas end-to-end ayudan a chequear si esos cambios aguantan cuando se integran a los procesos reales. Durante el Review manual, me concentro en confirmar la lógica de negocio y en ver si los resultados de las pruebas existentes alcanzan para respaldar esta entrega.

3. Cómo armar pruebas end-to-end amigables para Agentes

La IA ya es buenísima escribiendo casos de prueba; muchas veces genera cientos de líneas de tests para un simple Bugfix (sobre todo 5.6 sol). Escribir más tests no suele ser un problema en sí, pero después del deploy y el lanzamiento seguimos encontrando errores inesperados.

En mi experiencia, un problema central es este: no darle al Agente un entorno de pruebas end-to-end, ni la chance de detectar estos problemas durante la etapa de codificación y auto-prueba.

Si logramos armar un entorno así, donde el Agente pueda ejecutar cómodamente tareas desde el punto de entrada real del ambiente de pruebas y validar todo hasta llegar a los resultados que necesita el usuario, vamos a poder confiar en que el código escrito por IA corra en sistemas reales.

En el desarrollo real, armé un set de entornos de prueba end-to-end para nuestro negocio. El Agente puede consultar tablas de bases de datos, logs y conectarse a máquinas para investigar problemas sin complicaciones.

Todo el proceso de armado consiste, básicamente, en dejar que el Agente extraiga mis rutinas diarias de auto-prueba e integre herramientas y capacidades que estaban dispersas: lo que se puede convertir en herramienta pasa a MCP o CLI; los procesos reutilizables se escriben como Skills.

Sí, exige esfuerzo al principio, pero no le tengas miedo a la fricción. Una vez que lo armas, acelera muchísimo el desarrollo, reduce el retrabajo y la posibilidad de incidentes en producción, y dejas de preocuparte todo el día por si el código que escribió la IA va a causar un desastre.

Alrededor de las pruebas end-to-end amigables para Agentes, hice principalmente cuatro cosas:

1. Dejar que el Agente conozca el entorno: Por ejemplo, soportar el levantamiento del ambiente de pruebas con un clic, crear datos de prueba, aclarar versiones actuales, cuentas de prueba y permisos, y ofrecer capacidades de limpieza y reseteo.
2. Dejar que el Agente opere los sistemas de negocio: Ejecutar procesos reales vía navegadores, APIs o CLIs.
3. Dejar que el Agente consulte fácilmente tablas de bases de datos y logs: Confirmar resultados de almacenamiento mediante un MCP de base de datos de solo lectura, y localizar problemas con Skills del sistema de logs y consultas de Trace.
4. Reutilizar procesos tediosos pero estables: Pasar las operaciones estables a scripts, y organizar los puntos de entrada y métodos de troubleshooting en Skills, reduciendo la intervención manual y las conversaciones repetitivas.

Basado en este trabajo, estos son algunos métodos que hoy me resultan efectivos:

1. Automatización de navegador: Cuando los sistemas de negocio requieren operar desde el navegador, recomiendo el navegador open-source ego lite. Es fácil de usar y rápido. Combinado con pi agent + DeepSeek V4 Flash, las pruebas se completan bastante rápido, ahorrando tiempo.
2. Unificar operaciones en una CLI: Integrar los Skills reutilizables, los MCPs configurados y los scripts escritos en una CLI de pruebas unificada, que ofrezca capacidades para chequear el entorno, preparar datos, ejecutar escenarios, consultar resultados y limpiar. Esto también puede convertirse en una herramienta interna de productividad. Actualmente armé este set como CLI, y me resulta comodísimo para investigar cuando surge algún problema.
3. Que las herramientas sirvan directamente para la aceptación: Las consultas a la DB sirven para confirmar estados, los logs y Traces para explicar fallas, pero los resultados esperados tienen que salir de los contratos de negocio. No dejes que el Agente asuma que algo está bien solo porque ve lo que devolvió el sistema. Con lógicas de negocio complejas, el sistema puede devolver perfectamente un resultado que parece razonable pero incumple las reglas. Las herramientas nos ayudan a conseguir evidencia, no a definir las respuestas correctas por nosotros.
4. Si el producto en sí es un Agente, revisa también la calidad de las respuestas: Si lo que estás probando es un Agente, además de verificar que los procesos de negocio funcionen, hay que evaluar la calidad de las respuestas. Esto es lo que solemos llamar Agent Eval, que no vamos a profundizar acá.

4. Cómo revisar código escrito por IA

En las secciones anteriores compartí cómo lograr que la IA escriba código de calidad, pero al final del día, el desarrollador sigue siendo el principal responsable de los requerimientos de negocio.

Sin Review, los sistemas grandes empiezan a fallar rápido.

Y tampoco querrás que te levanten para un On-call a la madrugada, solo para descubrir que el problema lo causó código escrito por IA.

Respecto al Review, estas son mis prácticas principales hoy:

1. Primero los criterios de aceptación, después los resultados de las pruebas: Primero reviso los criterios de aceptación que dio el Agente, y luego los comparo con los resultados de las pruebas end-to-end previas para confirmar si se cumplió lo esperado y si falta algo. No te fijes solo en cuántos tests pasaron, sino en si esos tests validaron lo que realmente importa para este requerimiento.
2. Sigue los flujos de negocio para ver la implementación, concentrando energía en las partes de alto riesgo: Reviso sobre todo permisos, cambios de estado, concurrencia, reintentos, consistencia de datos y partes críticas como migraciones y rollbacks. Al CRUD con patrones estables le dedico menos tiempo; de hecho, hay partes que ya ni miro.
3. Presta atención especial a las abstracciones y mecanismos nuevos: Para lo recién agregado, aplico ideas como la navaja de Ockham y le pido a la IA que lo revise otra vez: ¿De verdad es necesario? ¿Hay una implementación más simple? ¿Metimos demasiada complejidad para un problema local?
4. Considera armar Bots de Review dedicados cuando haya muchos MRs: Si en el equipo hay muchos MRs, se puede diseñar un Review Bot específico para encargarse de la revisión cruzada. A diferencia de llamar directamente a pi agent / Claude Code para una revisión adversarial como mencioné antes, acá el foco está en combinar la información de cambios de Git con procesos de revisión prediseñados, creando una capacidad de revisión repetible pensada exclusivamente para MRs.

5. Algunos balances y reflexiones

Mi mayor cuello de botella hoy en el desarrollo es la velocidad de Review.

Los Agentes pueden empujar varias tareas a la vez, pero mi velocidad para entender el negocio, evaluar soluciones y confirmar entregas no escala en la misma proporción. Si solo lo dejas escribir más, lo único que haces es acumular más código esperando revisión.

Por eso, lo que quiero mejorar ahora es que los problemas repetitivos se detecten y corrijan antes de llegar a mis manos.

Los temas que se pueden detectar con chequeo de tipos, tests y aserciones de negocio deberían manejarlos el propio Agente durante el desarrollo en la medida de lo posible; los que requieren mi criterio se concentran en si entendimos bien los requerimientos, si la lógica de negocio clave se sostiene y qué riesgos sin validar quedan en este cambio.

Los Bots de Review dedicados pueden ayudar con esto, pero su valor depende de si reducen los olvidos de problemas reales y la carga manual, no de cuántos comentarios generen.

Esto también hace que mi idea de lo que es un Harness se vuelva más concreta: además de darles a los Agentes el contexto correcto, necesitan entornos capaces de ejecutar tareas y bases para juzgar los resultados.

Organicé las operaciones que repetía constantemente en mis auto-pruebas diarias en CLIs, scripts y Skills, dejando que el Agente corra los sistemas, valide resultados y encuentre evidencia de fallas por su cuenta. En tareas futuras similares, estas capacidades se pueden seguir usando y, de a poco, pasarlas a otros compañeros para que las reutilicen.

Al mismo tiempo, este flujo de trabajo necesita restarle cosas regularmente.

Algunos pasos existen para compensar las limitaciones de cierta generación de modelos. Cuando los modelos cambian, hay que volver a evaluar si esos pasos siguen sumando. Las tareas simples se hacen directo; las complejas suman planificación, división y revisión cruzada. Por ejemplo, después de las actualizaciones de Astra, borré algunas restricciones demasiado estrictas de AGENTS.md. Los modelos iteran, y nuestros flujos de trabajo tienen que iterar con ellos.

Obvio, las pruebas y el Review reducen la incertidumbre, pero alguien tiene que dar los criterios de aceptación correctos. Aunque el código y los tests coincidan entre sí, puede que ambos estén entendiendo mal los requerimientos. Las pruebas end-to-end solo cubren comportamientos en los entornos y escenarios elegidos; el tráfico, la concurrencia y la distribución de datos en producción pueden traer problemas nuevos.

Como desarrollador que recién empieza a trabajar, sigo queriendo aprender más conocimiento profesional del rubro a través del trabajo. Sin embargo, la IA de verdad redujo algunas oportunidades de caer en trampas por cuenta propia. Esa experiencia valiosa que antes ganabas al toparte con problemas e investigar sus causas, hoy puede resumirse a que la IA te diga:

"Me equivoqué, lo corrijo ahora."

Por eso,

ahora reservo parte de mi jornada de desarrollo para aprender y reflexionar, mientras me pregunto: qué habilidades necesitan realmente los equipos de R&D en la era de la IA.

Este artículo registra un conjunto de métodos que fui descubriendo de a poco en mi negocio durante mis primeros meses. Su alcance y sus carencias son algo que todavía estoy explorando.

Cualquiera puede arrancar eligiendo un flujo de auto-prueba que haga seguido, intentar que el Agente lo corra solo, guardar la evidencia y luego consolidar los pasos que funcionaron.

Por políticas de confidencialidad de la empresa, no puedo incluir muchos detalles en el artículo. Espero que este texto sirva para abrir el debate, ¡me encantaría conocer las buenas prácticas que aplican ustedes en su día a día!