Un autor de Habr enumera cinco decisiones que el ingeniero debe tomar antes de que la IA escriba código

Uno de los bugs más desagradables de la lógica de pagos tiene un aspecto inofensivo: comprobar que la operación está en estado PENDING, pasarla a SUCCESS y abonar el saldo. Si dos webhooks llegan a la vez, ambos ven PENDING, ambos superan la comprobación y el usuario recibe el dinero dos veces. El autor de un reciente artículo en Habr encontró este error en su propio marketplace. El código lo escribió él mismo, sin IA.

Usa este ejemplo para plantear la pregunta central: si hoy un agente implementa un procesador así en cuestión de minutos, ¿quién fija las restricciones que no aparecen en la descripción funcional? A continuación, el autor analiza cinco situaciones de un marketplace y de una plataforma multimarca, y termina con una lista de 12 preguntas que conviene repasar antes de generar el código.

Dónde calla la especificación

El agente ejecuta bien lo que está descrito. La frase «cuando llegue un webhook exitoso, abonar el saldo» se cumple formalmente tanto en una implementación correcta como en una vulnerable. La diferencia solo aparece bajo carga concurrente y no se ve en pruebas con un único hilo.

Esto no es una propiedad de los modelos de lenguaje, sino de cualquier planteamiento de la tarea en el que se omiten los requisitos no funcionales. Una persona suele cubrir ese hueco con experiencia y con el recuerdo de incidentes pasados. El agente no tiene de dónde sacar ese contexto si no se le proporciona de forma explícita.

El autor identifica cinco áreas en las que estas decisiones se toman de antemano:

• idempotencia de pagos: qué se considera una solicitud repetida y dónde se garantiza;
• migraciones de datos: el orden de los cambios y el comportamiento del sistema en estados intermedios;
• entrega de mensajes entre instancias del servicio: qué ocurre si el destinatario no es el correcto o no está disponible;
• integraciones con proveedores: cómo se comporta el sistema ante reintentos, retrasos y respuestas no estándar;
• arquitectura de marcas: qué es común a todas las marcas de la plataforma y qué se configura por separado.

El autor ofrece la lista completa de 12 preguntas en el artículo original. Conviene hacer una salvedad: el anuncio no incluye detalles de las soluciones, así que lo que sigue describe cómo suelen resolverse estos problemas en la industria, no las conclusiones del autor.

Cómo se suele resolver

Para el caso de los webhooks, el conjunto habitual de medidas es conocido. Una clave única del evento o una clave de idempotencia de la solicitud. Una actualización condicional atómica del tipo «pasar a SUCCESS solo si el estado sigue siendo PENDING», junto con la comprobación del número de filas afectadas. Un bloqueo del registro durante la transacción. Cualquiera de estas medidas convierte el «comprobé y luego escribí» en una única operación indivisible.

Con las migraciones y los mensajes, la lógica es parecida. Cambios de esquema que deben funcionar mientras conviven la versión antigua y la nueva del servicio. Una entrega en la que se ha acordado de antemano si se admiten pérdidas y duplicados. Estas decisiones afectan a la estructura del código, de modo que tomarlas después de la generación ya sale caro: habrá que reescribir, no completar.

Cómo aplicarlo en la práctica

Si encargas una tarea a un agente, conviene adjuntarle un breve bloque de restricciones. ¿Qué debe seguir siendo cierto ante una llamada repetida? ¿Y ante dos llamadas paralelas? ¿Y ante un fallo parcial de un proveedor externo? ¿Y al desplegar una versión nueva junto a la antigua?

También resulta útil pedir al agente que, además de escribir el código, enumere los supuestos que ha asumido sobre la concurrencia y el orden de los eventos. La discrepancia entre sus supuestos y los tuyos es la forma más rápida de detectar un agujero en el planteamiento.

Por último, las pruebas. Para los flujos de pago hace falta al menos una prueba con solicitudes simultáneas; de lo contrario, la verificación de la corrección se queda en el nivel de «parece correcto». Así era precisamente el procesador de la historia del autor: la lógica se leía como correcta y solo fallaba con una condición de carrera.

Las conclusiones del artículo se aplican también al código que escribe una persona. La IA acelera la implementación, pero las decisiones sobre los invariantes del sistema siguen teniendo que tomarse antes, y las toma el ingeniero.