todos los artículos
ia · 6 min de lectura

Programación con IA: un flujo de revisión para canvas y otros espacios de trabajo con IA

Usá un espacio de programación con IA para cambios acotados y después revisá el diff, corré los tests y buscá datos sensibles antes de aceptar el código.

Los espacios de programación con IA hacen fácil producir mucho código en poco tiempo. Lo difícil es decidir qué parte de ese código entra en tu proyecto. Este artículo propone un flujo de revisión que sirve tanto si usás el canvas de ChatGPT como una ventana de chat con bloques de código o un editor con IA, para que un equipo chico pueda aceptar código generado con la misma confianza que el código escrito por un colega.

Qué cambió con canvas

OpenAI presentó canvas en ChatGPT en 2024 como un espacio de trabajo al lado del chat para editar textos y código.

El producto cambió desde entonces. Las notas de versión de modelos de OpenAI dicen que, desde fines de mayo de 2026, canvas ya no está disponible en GPT-5.5 Instant ni en GPT-5.5 Thinking, y que la escritura y el código ahora se hacen directamente en el chat, con bloques de escritura y de código. Las mismas notas dicen que los usuarios pagos pueden seguir usando canvas con modelos heredados por un tiempo limitado, hasta que esos modelos se retiren. Revisá las notas de versión antes de armar un hábito de equipo alrededor de canvas en particular, porque la disponibilidad depende de tu plan y del modelo que elijas.

Por eso, el flujo que sigue no depende de ninguna herramienta en particular. El espacio de trabajo con IA es donde se escribe un borrador. Tu repositorio, tus tests y una persona que revisa deciden qué sale a producción.

La regla: la IA escribe el borrador, el repositorio decide

Tratá cada pieza de código generado como un pull request sin revisar de un desconocido capaz. Puede estar bien. También puede llamar a una función que no existe, cambiar sin avisar un comportamiento del que dependés o incluir una credencial que pegaste como contexto. Nada de eso se ve hasta que leés el diff y ejecutás el código.

Eso deja tres controles que no se pueden saltear:

El cambio es lo bastante chico como para leerlo de una sola vez.
Tests que podés volver a correr demuestran que hace lo que pediste.
Lo aprueba una persona que no escribió el pedido a la IA.

Paso 1: acotá el pedido antes de abrir el espacio de trabajo

La mayoría de las malas ediciones con IA empiezan con un pedido vago sobre un archivo grande. Antes de escribirle a la IA, anotá:

El único archivo o función que tiene que cambiar.
Qué tiene que hacer el código después del cambio, en una o dos oraciones.
Qué no tiene que cambiar: nombres de funciones públicas, esquema de la base de datos, respuestas de la API.
Cómo lo vas a comprobar: un test existente, un test nuevo o un paso manual que puedas describir.

Pegá solo el código necesario para ese cambio. Si la IA necesita más contexto, dáselo, pero mantené cada pedido en un solo comportamiento. Un pedido como "agregá validación de entrada al manejador del formulario de facturas y devolvé un 400 con un mensaje cuando falte el monto" produce un diff que se puede revisar. Un pedido como "ordená este servicio", no.

Paso 2: llevá el cambio al control de versiones como un diff

Uses el espacio de trabajo que uses, no copies un archivo entero regenerado encima de tu copia de trabajo sin mirarlo. Copiá el cambio en una rama y dejá que el control de versiones te muestre exactamente qué se movió.

git switch -c ai/invoice-validation
# paste or apply the edited code
git diff --stat
git diff

Leé primero git diff --stat. Si pediste un cambio en una función y se movieron tres archivos, frená y averiguá por qué. Después leé el diff completo, línea por línea. Prestá atención a:

Código borrado que no pediste quitar, sobre todo manejo de errores y logs.
Dependencias o imports nuevos. Cada uno es una decisión sobre la cadena de suministro, no un detalle de formato.
Variables renombradas o bloques reformateados que esconden el cambio real. Pedile a la IA que lo rehaga sin ediciones que no tengan que ver.
Valores escritos a mano en el código: URLs, IDs, claves, direcciones de correo.

El historial de versiones dentro de un espacio de trabajo con IA sirve mientras armás el borrador. No reemplaza un historial de commits que todo tu equipo pueda ver.

Paso 3: hacé que los tests se puedan reproducir

"Cuando lo corrí, funcionó" no es un test. Un test reproducible es uno que cualquier persona del equipo, o tu sistema de CI, puede correr con un solo comando y obtener el mismo resultado.

Para cada cambio hecho con ayuda de IA:

Corré la suite de tests existente antes de aplicar el cambio, así conocés la línea de base.
Agregá al menos un test que falle sin el cambio y pase con él. Si le pedís a la IA que escriba ese test, leelo con cuidado: a veces los tests generados verifican lo que el código hace hoy, y eso no demuestra nada.
Incluí un caso límite que se te haya ocurrido a vos: un valor vacío, un texto muy largo, un campo que falta.
Volvé a correr la suite completa después del cambio.

Ejecutar el código dentro del espacio de trabajo con IA, cuando se puede, es una verificación rápida. Corre en un entorno distinto al de tu proyecto, con otras versiones y sin acceso a tu configuración real, así que no reemplaza tu propia corrida de tests.

Paso 4: buscá datos sensibles en las dos direcciones

Acá hay dos riesgos distintos.

Lo que entra: todo lo que pegás en una herramienta de IA sale de tu máquina. Antes de pegar, sacá claves de API, contraseñas, cadenas de conexión, nombres de clientes y datos personales. Usá valores falsos con la misma forma. Revisá los controles de datos de tu plan y la política de tu empresa sobre qué se puede compartir con qué proveedor.

Lo que sale: el código generado puede traer credenciales copiadas de tu pedido, claves de ejemplo que parecen reales o logs que imprimen datos personales. Buscá en el diff cualquier cosa que parezca una clave o un token antes de hacer el commit. La documentación de GitHub dice que el escaneo de secretos (secret scanning) se ejecuta automáticamente y sin costo en los repositorios públicos; en los repositorios privados, la disponibilidad depende del tipo de cuenta y del plan, así que revisá la documentación vigente para tu caso.

Paso 5: exigí una segunda persona y controles aprobados

En un equipo chico, la persona que le escribió a la IA suele ser la misma que hace el merge. Ahí es donde se cuelan la mayoría de los errores. Si tu código está en GitHub, las reglas de ramas protegidas pueden exigir revisiones del pull request antes del merge y exigir que los controles de estado (status checks) pasen antes del merge. Activá las dos cosas en tu rama principal y hacé que tu suite de tests sea uno de los controles obligatorios.

Quien revisa tendría que recibir una descripción breve con cada pull request hecho con ayuda de IA:

Qué se pidió, en una oración.
Qué herramienta y qué modelo produjeron el borrador.
Qué cambió a mano el autor después.
Cómo se probó.

Ese registro también sirve más adelante, cuando quieras entender por qué existe una línea.

Una tabla rápida para decidir

Situación	Aceptar después de revisar	Requiere cuidado extra	No pegar en una herramienta de IA
Cambio chico en una función, con tests	Sí
Dependencia nueva de terceros		Revisá la licencia, el mantenimiento y qué arrastra
Autenticación, pagos, permisos		Revisión de alguien con experiencia y pruebas manuales
Código con claves activas o datos de clientes			Ocultá esos datos primero, o dejalo afuera
Refactorización grande en muchos archivos		Dividila en pedidos más chicos

Fallas comunes a las que conviene prestar atención

El código llama a una función u opción de una biblioteca que no existe en la versión que usás. Tus tests y tu verificador de tipos lo detectan; leer el código solo, muchas veces no.
La IA "arregla" un test que falla cambiando el test en lugar del código.
El manejo de errores se reemplaza por un catch amplio que esconde las fallas.
Los comentarios describen lo que el código se suponía que hacía, no lo que hace.

Mantener fijos los pasos de revisión es lo que evita que el borrador rápido se convierta en una depuración lenta en producción.

Dónde entra automotif

Si tu equipo ya escribe código con herramientas de IA y quiere una forma compartida de revisarlo, el servicio que más encaja es adopción de IA: capacitamos al equipo sobre sus tareas reales y dejamos una guía por escrito que cubre instrucciones, revisión y tests. Si te parece útil, reservá una llamada gratis de 30 a 60 minutos para conversarlo.