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

Contexto

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

Anteriormente compartí flujos de trabajo relacionados en Xiaohongshu. El contexto entonces era que GPT-5.4 y Opus 4.6 ya podían completar tareas correctamente si se les daba 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 potentes añadiendo restricciones.

Por ejemplo, Skills como Superpowers ofrecen una implementación relativamente pesada, centrada principalmente en Spec y TDD, que ayuda a organizar y avanzar en las tareas con mayor facilidad.

Pero hacerlo así tiene sus inconvenientes. La sensación más evidente es que el consumo de Tokens se dispara. Skills como Superpowers contienen muchos Workflows diseñados para restringir la siguiente acción del modelo. Incluso si, desde una perspectiva global, cierto paso ya no es necesario —por ejemplo, cuando el contexto es suficiente y se puede empezar a implementar directamente—, el modelo puede seguir ejecutando el proceso predefinido.

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

Así que, en este artículo, combinaré mi práctica de los últimos meses para compartir algunos métodos que actualmente me funcionan, y hablaré sobre cómo aprovechar mejor distintos Agentes para mejorar la eficiencia en el desarrollo diario.

1. Mis Skills y Prompts más utilizados

Mi distribución actual de herramientas:

Ahora mismo uso principalmente Codex + GPT-5.6 Sol para la implementación de código, y Astra para la planificación. Antes de que saliera Astra, el trabajo de planificación se lo dejaba sobre todo a GPT-5.6 Sol Max.

Para requerimientos sencillos, uso pi + DeepSeek V4 Flash para la implementación; la revisión adversarial de soluciones y el Code Review los lleva principalmente Claude 5 Fable. En proyectos personales, también uso la versión web de GPT-6 Pro para el diseño de la solución principal.

Mis Skills más utilizados

1. think: 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 continuas, aclara objetivos, restricciones y trade-offs, y luego los plasma en un ADR o en CONTEXT.md según lo que pida el proceso de desarrollo. Me ayuda a sacar a la luz problemas que no tuve en cuenta durante la alineación inicial.
3. implement: Se usa junto con grill, forma parte de la suite de Skills de Matt Pocock y sirve para implementar planes o Issues claramente definidos.
4. ponytail: Sirve para limpiar el sobre-diseño de la IA y reducir la dificultad del Review. Lo uso mucho porque GPT-5.6 Sol tiende a sobre-diseñar constantemente.
5. handoff: Organiza el contexto actual en archivos para facilitar continuar la tarea en nuevas sesiones. Normalmente lo uso para pasar el relevo de Codex a Claude Code o al agente pi.
6. check: Para code review, lo suelo usar al enviar MRs.
7. Skills extraídos de mi trabajo y desarrollo personal: Principalmente 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, te plantees pedirle a Codex que te lo organice en un Skill para reutilizarlo directamente después.

Mis Prompts más utilizados

Hoy en día rara vez escribo bloques enormes de Prompts yo mismo. Cuando hace falta, suelo dejar que Codex me ayude a organizarlos. Por ejemplo, tras varias rondas de discusión, si 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.

Aparte de eso, uso muy a menudo los siguientes tipos de Prompts cortísimos.

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

No son fórmulas mágicas, sino metodologías altamente estandarizadas dentro del conocimiento humano. Durante su entrenamiento, el modelo ha visto muchísimos papers, código, documentos de diseño y debates relacionados, así que muchas veces no hace falta escribir a mano cientos de líneas de Workflow; basta con decirle qué método de pensamiento adoptar. Aquí van algunos prompts que, en la práctica, me han resultado muy efectivos:

• 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 va lenta, puedes decir:

No sigas diseñando basándote en la solución establecida de "añadir 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:

¿Está el cuello de botella en el SQL, la red, la serialización, la contención de locks o en cálculos repetidos? Si añadir un índice al SQL lo resuelve, ¿para qué meter Redis?

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

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

La forma normal 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 tumbar las suposiciones principales.

Supongamos que tu solución es "introducir locks distribuidos para resolver peticiones duplicadas". El modelo ya no se limitará a decirte cómo configurar el timeout del lock, sino que empezará a preguntar:

¿De verdad las peticiones duplicadas necesitan exclusión mutua? ¿Se puede resolver con idempotencia en la interfaz? ¿Qué pasa si el servicio de locks se cae? ¿Y si el lock expira pero la lógica de negocio aún no ha terminado? ¿Hemos introducido un nuevo punto de fallo distribuido para resolver un problema local?

Este tipo de Prompt es especialmente útil para revisiones de soluciones y Code Reviews.

• Experimentos de ablación (Ablation Experiments): Que el sistema mejore no significa que todo lo que añadiste sea útil.

Por ejemplo, si hiciste tres optimizaciones de golpe:

Tras añadir í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 diseñará controles alrededor de distintas combinaciones, partiendo del Baseline, comparando solo añadir índices, índices + caché, índices + caché + consultas por lotes, etc.

Al final, podría descubrir que:

Solo con añadir índices la latencia ya bajó de 800ms a 120ms; las otras dos soluciones complejas aportaron apenas 20ms.

Así tienes mucho más claro qué código merece la pena conservar y qué complejidad podría ser innecesaria.

• 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 añadir una frase:

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

Muchas veces acabará descubriendo que:

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

Esta frase es especialmente útil con los Coding Agents actuales, porque los modelos tienden fácilmente a sobre-diseñar en aras de la "completitud".

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

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

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 normalmente empezará a comprobar:

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

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

Por eso, rara vez escribo cosas como:

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

El modelo ya ha aprendido muchas 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 verificarse mediante 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 estas pocas decenas de palabras, en realidad se están especificando cinco acciones cognitivas distintas:

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

Y esto es, tal y como yo lo entiendo, un cambio en el Prompt Engineering en la era de los nuevos modelos: en lugar de escribirle al modelo un proceso de pensamiento fijo y completo, es mejor usar metodologías precisas para indicarle "de qué manera pensar" y luego añadir solo las restricciones realmente necesarias para la tarea actual.

2. Mi flujo de trabajo de desarrollo diario

Cuando recibo un requerimiento, normalmente primero le paso el contexto relevante al Agente, como el PRD, actas de reuniones, registros de chat y feedback de usuarios, y luego uso grill para alinear los requerimientos con él.

Estos materiales casi nunca forman un requerimiento completo y coherente. Puede que el PRD no esté actualizado, que en las reuniones se hayan añadido restricciones o que en los chats se hayan ajustado prioridades. Mi propia comprensión del requerimiento también puede incluir suposiciones implícitas.

Dejo que el Agente entienda estos materiales apoyándose en la Wiki del equipo y el código existente, y luego aclaro objetivos, límites y trade-offs que afectan a la implementación mediante preguntas continuas. Algunas preguntas puedo responderlas al instante; otras requieren volver a confirmarlo con producto o con los compañeros correspondientes.

Aquí manejo una regla: cuando las preguntas pendientes ya no vayan a cambiar significativamente la dirección de la implementación ni los resultados de aceptación, se puede empezar a desarrollar.

No le exijo que planifique todos los detalles de implementación por adelantado, porque si no, la propia alineación de requerimientos se convierte en un proceso pesadísimo.

Las conclusiones tras la alineación se plasman en un Spec o en CONTEXT.md, registrando 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 posteriores encargados de la implementación y la revisión compartan el mismo contexto, sin tener que releer todas las conversaciones previas.

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 directamente; los complejos se dividen en Issues con límites claros que puedan aceptarse de forma independiente. Solo las partes que pueden avanzar por separado se delegan a subagentes para desarrollo en paralelo en distintos worktrees, integrándose finalmente por el Agente principal.

El Agente de código completa primero las pruebas. Cuando cree que está listo para entregar, introduzco otros Agentes para una revisión cruzada adversarial según la complejidad de la tarea. Los problemas detectados se devuelven de forma unificada al Agente de código principal, es decir, a Codex, que los corrige y vuelve a verificar.

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

Actualmente no leo línea por línea todo el código generado; me centro sobre todo en los resultados de las pruebas y en la lógica de negocio principal. Aquí hay un requisito previo importante: el alcance de cada MR debe ser lo bastante pequeño, y las rutas de negocio completas deben ir verificándose gradualmente a medida que avanza el desarrollo.

Los MRs pequeños mantienen los cambios que exigen comprensión y criterio dentro de rangos controlables cada vez; las pruebas end-to-end ayudan a comprobar si esos cambios aguantan al integrarlos en procesos de negocio reales. Durante el Review manual, me concentro en confirmar la lógica de negocio y en si los resultados de las pruebas existentes bastan para respaldar esta entrega.

3. Cómo construir pruebas end-to-end compatibles con Agentes

La IA ya es muy buena escribiendo casos de prueba; a menudo escribe cientos de líneas de tests para un Bugfix (especialmente 5.6 sol). Muchas veces, escribir más tests no es un problema en sí, pero tras el despliegue y la puesta en producción seguimos encontrando errores inesperados.

En mi experiencia, un problema central es no proporcionarle al Agente un entorno de pruebas end-to-end que le dé la oportunidad de descubrir estos problemas durante las fases de codificación y auto-prueba.

Si logramos construir un entorno así, que permita al Agente ejecutar cómodamente tareas desde el punto de entrada real del entorno de pruebas, comprobando todo hasta llegar a los resultados que necesita el usuario, podremos dejar con confianza que el código escrito por IA corra en sistemas reales.

En el desarrollo real, he montado un conjunto de entornos de pruebas de desarrollo end-to-end para nuestro negocio. El Agente puede consultar cómodamente tablas de bases de datos, logs y conectarse a máquinas para investigar problemas.

Todo el proceso de construcción consiste básicamente en dejar que el Agente extraiga mis procesos diarios de auto-prueba, integrando herramientas y capacidades dispersas: lo que se puede convertir en herramienta pasa a ser MCP o CLI; los procesos reutilizables se escriben como Skills.

Es cierto que esto exige esfuerzo al principio, pero no le tengas miedo a las complicaciones. Una vez montado, acelera enormemente el desarrollo, reduce el retrabajo y la posibilidad de incidencias en producción, y te quitas de encima esa preocupación constante de si el código escrito por la IA va a provocar algún desastre.

Alrededor de las pruebas end-to-end compatibles con Agentes, hice principalmente cuatro cosas:

1. Dejar que el Agente se familiarice con el entorno: Por ejemplo, soportar el arranque con un clic de los entornos de prueba, crear datos de test, aclarar versiones actuales, cuentas de prueba y permisos, y ofrecer capacidades de limpieza y reinicio.
2. Dejar que el Agente opere los sistemas de negocio: Ejecutar procesos de negocio reales mediante navegadores, APIs o CLIs.
3. Dejar que el Agente consulte cómodamente tablas de bases de datos y logs: Confirmar resultados de almacenamiento mediante MCP de base de datos de solo lectura, y localizar problemas a través de 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 resolución de problemas en Skills, reduciendo la intervención manual repetitiva y el diálogo innecesario.

Basándome en este trabajo, aquí van algunos métodos que actualmente me resultan efectivos:

1. Automatización de navegador: Cuando los sistemas de negocio requieren operar en el navegador, recomiendo el navegador open-source ego lite. Es cómodo de usar y rápido. Combinado con pi agent + DeepSeek V4 Flash, las pruebas se completan bastante rápido, reduciendo el tiempo de testing.
2. Unificar operaciones en una CLI: Integrar los Skills reutilizables, los MCPs configurados y los scripts escritos en una CLI de pruebas unificada, ofreciendo capacidades para comprobación de entorno, preparación de datos, ejecución de escenarios, consulta de resultados y limpieza. Esto también puede convertirse en una herramienta interna de productividad. Actualmente he empaquetado todo esto en una CLI, y resulta comodísima para investigar problemas cuando surgen.
3. Dejar que las herramientas sirvan directamente a la aceptación: Las consultas a la BD sirven para confirmar estados, los logs y Traces para explicar fallos, pero los resultados esperados deben seguir viniendo de los contratos de negocio. No dejes que el Agente asuma qué es correcto solo porque ve lo que devolvió el sistema. Bajo lógicas de negocio complejas, el sistema podría devolver perfectamente un resultado aparentemente razonable pero que incumple la norma. Las herramientas nos ayudan a obtener pruebas, no a definir respuestas correctas por nosotros.
4. Si el producto en sí es un Agente, comprueba también la calidad de las respuestas: Si el producto que estás probando es en sí mismo un Agente, además de verificar que los procesos de negocio se ejecutan de principio a fin, hay que tener en cuenta la calidad de las respuestas. Esto es lo que solemos llamar Agent Eval, que no vamos a detallar aquí.

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

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

Sin Review, los sistemas grandes dan problemas con mucha facilidad.

Y tampoco querrás que te llamen para un On-call en plena madrugada solo para descubrir que el culpable fue un código escrito por IA.

Respecto al Review, actualmente sigo estas prácticas principales:

1. Primero los criterios de aceptación, luego los resultados de las pruebas: Compruebo primero los criterios de aceptación dados por el Agente y luego los contrasto con los resultados de las pruebas end-to-end anteriores para confirmar si se cumplen las expectativas y si falta algo. No te fijes solo en cuántos tests pasaron, sino también en si esos tests verificaron lo que realmente importa para este requerimiento.
2. Sigue las rutas de negocio para ver la implementación, concentrando la 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, ahora hay partes de esto que ni miro.
3. Revisa específicamente las abstracciones y mecanismos recién añadidos: Para las nuevas abstracciones y mecanismos, aplico enfoques como la navaja de Ockham para que la IA vuelva a revisarlos: ¿Son realmente necesarios? ¿Hay una implementación más sencilla? ¿Han introducido demasiada complejidad para resolver un problema local?
4. Considera construir Bots de Review dedicados cuando haya muchos MRs: Si hay muchos MRs en el equipo, se puede diseñar un Bot de Review 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, aquí el enfoque está en combinar la información de cambios de Git con procesos de revisión prediseñados, creando una capacidad de revisión repetible orientada exclusivamente a los MRs.

5. Algunos resúmenes y reflexiones

Mi cuello de botella más evidente ahora mismo en el desarrollo es la velocidad de Review.

Los Agentes pueden sacar adelante varias tareas simultáneamente, pero mi velocidad para entender el negocio, evaluar soluciones y confirmar entregas no aumenta en la misma proporción. Si solo dejas que escriba más, probablemente solo estarás acumulando más código esperando revisión.

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

Los problemas que se pueden detectar mediante comprobación de tipos, tests y aserciones de negocio deberían gestionarlos el propio Agente durante el desarrollo en la medida de lo posible; los que requieren mi criterio se concentran en si los requerimientos se entendieron bien, si la lógica de negocio clave se sostiene y qué riesgos sin verificar 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 solo de cuántos comentarios generen.

Esto también hace que mi concepto de Harness se vuelva poco a poco más concreto: además de darles a los Agentes el contexto correcto, también 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 ejecute sistemas, compruebe resultados y encuentre pruebas de fallos por sí mismo. En tareas futuras similares, estas capacidades se pueden seguir usando y, gradualmente, cederse a otros compañeros para que las reutilicen.

Al mismo tiempo, este flujo de trabajo también necesita restar cosas regularmente.

Algunos pasos compensan carencias de una generación concreta de modelos. Cuando los modelos cambian, hay que reevaluar si esos pasos siguen aportando valor. Las tareas simples se hacen directamente; las complejas añaden planificación, división y revisión cruzada. Por ejemplo, tras las actualizaciones de Astra, eliminé algunas restricciones demasiado estrictas de AGENTS.md. Los modelos iteran, y nuestros flujos de trabajo tienen que iterar con ellos.

Por supuesto, las pruebas y el Review reducen la incertidumbre, pero los humanos seguimos teniendo que dar los criterios de aceptación correctos. Aunque el código y los tests cuadren entre sí, podrían estar malinterpretando juntos los requerimientos. Las pruebas end-to-end solo cubren comportamientos en entornos y escenarios seleccionados; el tráfico, la concurrencia y la distribución de datos en producción pueden seguir trayendo problemas nuevos.

Como desarrollador que acaba de empezar a trabajar, sigo queriendo aprender más conocimientos profesionales del sector a través de mi trabajo. Sin embargo, la IA sí ha reducido algunas oportunidades de meter la pata personalmente. Experiencias valiosas que antes se ganaban sufriendo problemas e investigando causas, ahora pueden resumirse en una IA diciendo:

"Me equivoqué, lo modifico ahora mismo."

Por eso,

ahora reservo parte de mi jornada de desarrollo para aprender y reflexionar, mientras me pregunto: qué habilidades necesitan realmente los compañeros de I+D en la era de la IA.

Este artículo recoge un conjunto de métodos que fui explorando poco a poco en mi proyecto durante mis primeros meses. Su ámbito de aplicación y sus carencias son algo que sigo descubriendo.

Todos podéis empezar eligiendo una ruta de auto-prueba que hagáis habitualmente, probar a dejar que el Agente la ejecute de forma autónoma, guardar las pruebas y luego consolidar los pasos que funcionen.

Por requisitos de confidencialidad de la empresa, muchos detalles no pueden incluirse en el artículo. Espero que este texto sirva para abrir el debate y me encantaría conocer las buenas prácticas de todos en el desarrollo real~