En mi equipo siempre fuimos bastante obsesivos con el contexto de los tickets. Un buen ticket nunca fue dos líneas sueltas: era el problema bien planteado, el diseño, la referencia a lo que ya existía en el código, lo que no había que romper. Escribir todo eso cuesta, pero es lo que hace que el que agarra la tarea no arranque adivinando. Y eso no cambió.

Lo que cambió es para quién va ese contexto. Hasta hace poco lo escribíamos para que lo entendiera una persona, y era el dev el que después se lo volvía a explicar a su asistente de IA para poder empezar: le pasaba los archivos, le contaba la arquitectura, le aclaraba qué no tocar. El ticket era para el humano, y el humano hacía de traductor hacia su asistente. Hoy ese contexto se escribe directo para la IA. El laburo humano quedó en las puntas: yo (o un senior) decido qué se hace y valido el planteo antes de que exista el ticket; el dev lo vuelve a validar cuando le llega, y audita todo lo que su agente produce.

Matías escribió acá mismo, hace unos meses, que el verdadero problema de la ingeniería siempre fue definir qué construir. Esa frase me quedó picando todo el quarter, porque nos pasó algo muy concreto: construir se aceleró de golpe, y definir quedó corriendo de atrás. Su post planteó el paradigma. Este post cuenta los casi cuatro meses de piloto (varios sprints) que le dedicamos a los tickets.

Exequiel, uno de los seniors del equipo, lo puso en estos términos cuando le pedí su balance:

“Lo veo como un paso más en la misma escalera de siempre: un día dejamos de grabar tarjetas, después dejamos de escribir en lenguaje de máquina y de gestionar los recursos a mano; la IA es la próxima capa de abstracción, más arriba que los lenguajes modernos.”

Compro la escalera. Pero subir un escalón de abstracción nunca fue soltar la responsabilidad de lo que corre abajo, y el mismo Exequiel lo dijo mejor que yo: “abstraer no es delegar la responsabilidad: dejamos de escribir el código, no de ser los responsables de lo que entrega”.

El ticket dejó de escribirse para un humano

Un ticket era una descripción para que otra persona la interpretara. Vos lo leías, entendías la intención, llenabas los huecos con lo que ya sabías del proyecto y traducías todo eso a código. El conocimiento tácito (“ya sabés que acá usamos tal librería”, “seguí el diseño”) vivía en tu cabeza y en la del que lo escribió.

Y esos tickets ya ni siquiera los escribe una persona. Los arma un agente que vive metido en la arquitectura de los proyectos: tiene los repos a mano, conoce las golden rules del equipo, sabe qué convenciones seguimos y qué patrones ya resolvimos antes. Con eso redacta la especificación pensando en que del otro lado la va a ejecutar el asistente del dev, no un humano leyendo entre líneas. Y antes de que exista, alguien lo lee: ningún ticket sale sin ese visto bueno, y más de una vez vuelve para atrás. Lo único que se automatizó de verdad es la redacción.

Nahuel, uno de los seniors, lo resume mejor que yo:

“Hoy el ticket dejó de escribirse para mí y pasó a escribirse para la IA — dejó de ser una descripción para ser un pre-prompt. Ya no leo ‘qué hay que hacer’, leo ‘qué tan bien está especificado para que la máquina no se mande cualquiera’.”

¿Y qué tiene adentro uno de estos tickets? Bastante más que un enunciado. El agente entra al componente que hay que tocar y deja anotado cuántas líneas tiene hoy y qué hace, así se nota si algo cambió antes de arrancar. Si ya existe otra parte del código que resuelve algo parecido, la señala como patrón a seguir en vez de reinventar. Trae el shape exacto que devuelve el endpoint (qué campos, qué tipos, qué puede venir vacío), con la referencia al repositorio del backend donde vive ese contrato, y marca cuál no hay que tocar en esta tarea. Enumera los tokens del design system que van, los estados contra los que hay que validar (cargando, error, vacío, el dato ya resuelto), en claro y en oscuro, y qué queda explícitamente afuera del scope.

Fijate que en todo eso no hay una sola instrucción de implementación. Hay contexto, límites y una definición de listo que se puede chequear: o pasa o no pasa. El ticket define el qué. El cómo (los nombres, la estructura, el enfoque) lo deciden el dev y su asistente.

El ticket define el qué; el dev y su asistente deciden el cómo El ticket define el qué debe ser verdad cuando la tarea esté lista; el dev y su asistente deciden el cómo.

Hay una decisión de diseño escondida ahí que hace todo esto sostenible: el ticket tampoco nombra la herramienta. No dice “abrí tal editor y pedile que refactorice”. Problema y criterios de listo; el resto lo resuelve el que lo agarra, con el agente que use o a mano. Las convenciones, el stack y los límites duros viven en archivos del propio repo, que cada herramienta lee por su cuenta. El contexto viaja adentro del ticket, y si mañana cambiamos de agente, los tickets sobreviven.

Setup vs. tarea: el setup vive en el repo; la tarea flota por encima, portable entre herramientas El setup vive en el repo y es estable; la tarea flota por encima, portable entre herramientas.

De escribir a auditar

“Escribo bastante menos y reviso muchísimo más —el laburo se corrió de ‘producir código’ a ‘auditar y decidir’.”

Exequiel otra vez.

De escribir a auditar: el trabajo se corre de producir código a revisarlo y decidir El trabajo se corrió de escribir código a auditar y decidir sobre lo que produce el agente.

Esta forma de trabajar te ahorra dos cosas distintas, y la gente suele nombrar una sola. Te ahorra picar teclas, obvio. Y te ahorra la arqueología de arrancar, esa hora de reconstruir contexto antes de poder escribir nada. Lucero, que vivió las dos épocas en el equipo:

“Antes tenía que cargarme yo de contexto antes de arrancar un ticket. Ahora el ticket ya viene con el contexto necesario, lo que evita mucho ida y vuelta con Lauti y otras áreas. No reemplaza la comunicación humana, pero acorta muchísimo el tramo de definición.”

Lo que no te ahorra nadie es leer, comprender y auditar. La comprensión se mudó de lugar: la hora de leer código en serio ahora viene después del diff del agente, ya no antes de escribir la primera línea.

Y auditar bien sale más caro que escribir. Contraintuitivo, pero es la experiencia del equipo y hay teoría vieja que lo explica: Peter Naur escribió en 1985 que programar es construir una teoría del sistema en la cabeza de alguien, y que esa teoría —no el código— es lo más caro que produce un equipo. Rafael Costa lo actualizó este año para la era de agentes: cuando la IA genera el código y vos lo revisás, el riesgo es que nadie sostenga el modelo mental. La IA nunca lo tuvo. Matías contó una versión de esto en su post: revisar una feature sobre código que conocía le resultaba fácil; armar el mapa mental de un microservicio que un agente hizo desde cero le costó mucho más.

Y hay algo de este escalón que lo separa de los anteriores. Cada capa de abstracción vieja era determinista: el mismo código de alto nivel compila siempre al mismo binario, así que confiar en lo que corría abajo salía gratis. Esta no. La misma intención puede volver resuelta de dos maneras distintas, y ninguna con garantías. Ahí es donde auditar deja de ser opcional.

En el día a día, ese costo de auditoría tiene una cara buena que no me esperaba. Lucero de nuevo:

“Antes, por tiempo, se dejaban pasar mejoras y edge cases (’esto funciona, dale’). Ahora la velocidad de la IA libera tiempo para pensar en esos edge cases de antemano —datos que no llegan del backend, listas sobrecargadas— en vez de encontrarlos recién en QA.”

Y una cara incómoda, que me parece la mejor observación de todo este piloto:

“Nos acostumbramos tanto a lo rápido que la revisión se siente ’lenta’ cuando en realidad es el tiempo que la IA nos regaló. La IA no es excusa para bajar el estándar: al contrario, ya no hay excusa para no sacar el mejor código posible.”

La revisión se siente lenta porque todo lo demás se volvió instantáneo. Ojo con las métricas que te empujan a recortar justo ahí.

Resulta que medio mundo llegó a lo mismo

Nosotros llegamos acá por necesidad, cansados de las idas y vueltas. Cuando después salimos a leer, resultó que esto ya tenía nombre y promulgadores: spec-driven development. Sean Grove, de OpenAI, en su charla The New Code: “quien escribe la especificación es ahora el programador”. Hay tooling de AWS y GitHub, y una fundación bajo la Linux Foundation empujando los estándares (links en Referencias). El principio de fondo es el mismo que encontramos con los tickets: la spec dice qué tiene que ser verdad al final, y el camino lo elige el que ejecuta.

Haberlo encontrado por las nuestras me da confianza en el camino. También me ubica: no somos pioneros de nada, somos parte de una ola.

Lo que todavía nos hace ruido

Tres cosas, y la primera es la que más me pesa.

¿Dónde va a aprender arquitectura el que arranca hoy? Nahuel:

“A veces siento que estoy programando al programador, y me quedo pensando dónde va a aprender arquitectura el pibe que arranca hoy si nunca pasa por esa ambigüedad que a mí me formó.”

Un experimento controlado de Anthropic con 52 desarrolladores, la mayoría junior, encontró que el grupo que usó IA quedó 17 puntos abajo en comprensión del sistema (50% contra 67% del grupo control), con la brecha más grande en debugging. El esfuerzo de quedarte trabado, parece, es parte de cómo se construye el criterio. Matías dejó abierta esta misma pregunta en su post y nosotros tampoco la cerramos. Lo que hacemos mientras tanto: los seniors escriben los tickets complejos, y los semi-seniors los leen y auditan durante un tiempo antes de escribir los suyos. Un ticket denso y bien investigado resultó ser buen material de estudio de arquitectura. No reemplaza pasar por la ambigüedad que te forma, pero por ahora es lo mejor que tenemos.

Percepción y cronómetro no coinciden. Un estudio de METR de 2025 midió a devs experimentados trabajando con IA sobre repos que conocían bien: fueron un 19% más lentos, y se creyeron un 20% más rápidos. Casi cuarenta puntos de diferencia entre lo que sentían y lo que marcaba el reloj. Por eso desconfío de cualquiera que prometa “10x”. También hay reportes de más defectos por PR en código generado (el más citado viene de un vendor que vende review con IA, así que tomalo con pinzas, aunque coincide con lo que vimos). Todo esto es la razón por la que la revisión humana consciente, como insiste Lucero, no se negocia.

Percepción vs. realidad: se sienten más rápidos con IA, pero tardan más Devs experimentados sobre código que conocían: se sintieron 20% más rápidos con IA; en realidad tardaron 19% más (METR, 2025).

La tercera es más incómoda de admitir: nuestro propio balance es cualitativo. No medimos todavía time-to-first-PR ni cuántas preguntas de arranque desaparecieron; está en el roadmap. Estos casi cuatro meses fueron muy buenos, y cuando digo eso hablo de la vivencia del equipo.

La escalera

Escribir intención con precisión resultó ser tan difícil, y tan de ingeniería, como escribir código lo fue siempre. Nahuel dice que redactar tickets para una máquina lo hizo pensar mejor el problema antes de tocar una línea, y a mí me pasa igual. El trabajo cambió de lugar: menos manos en el teclado, más cabeza en el qué. Y la firma sigue siendo nuestra.

La última línea se la dejo a Nahuel:

“Saber qué pedir y por qué lo que te devuelve puede estar mal: eso no me lo enseñó la facultad, pero es lo único que hoy me hace difícil de reemplazar.”

Gracias a Exequiel, Eric, Nahuel y Lucero por bancarse que los cite textual.

Referencias