Cómo colaborar con una IA al programar: contexto, tareas y revisión

La IA puede ayudar a escribir y revisar código, pero cada resultado debe verificarse en el contexto del proyecto.

Un asistente de IA puede proponer código, explicar errores y sugerir pruebas. Su respuesta no es correcta por el solo hecho de parecer convincente o ejecutarse en un ejemplo. Para aprovecharla, aporta contexto verificable, define qué resultado necesitas y revisa la propuesta antes de incorporarla.

Revisado el: 5 de octubre de 2026. Las herramientas y sus interfaces cambian; las prácticas de verificación de este artículo no dependen de un modelo concreto.

1. Da contexto útil y comprobable

Una petición mejora cuando describe el problema concreto, no solo el nombre de una tecnología. Incluye, según corresponda:

Entorno: lenguaje y versión, framework, sistema operativo y comandos relevantes. Por ejemplo: «Python 3.11, FastAPI 0.x, PostgreSQL; el endpoint recibe este JSON y falla con este mensaje».
Resultado esperado: qué debe hacer la función o cambio, con ejemplos de entrada y salida y casos límite.
Contexto del proyecto: archivos y contratos relacionados, convenciones existentes y dependencias permitidas. Comparte solo el fragmento necesario y evita incluir credenciales o datos privados.
Restricciones: compatibilidad, rendimiento, seguridad, arquitectura o interfaces que deban respetarse. Indica qué decisiones ya están tomadas.
Formato de respuesta: pide un parche pequeño, explicación de supuestos, pruebas propuestas y cualquier incertidumbre que deba verificarse en la documentación.

Un ejemplo de petición concreta: «En Python 3.11 y FastAPI, modifica crear_pedido para rechazar cantidades menores que 1. Mantén el contrato actual, no agregues dependencias y añade pruebas para cero, un valor positivo y un tipo incorrecto. Antes de cambiar archivos, enumera los supuestos sobre el esquema».

Para cambios amplios, dividir el trabajo en pasos puede facilitar la revisión. Primero acuerda el enfoque; luego implementa una parte delimitada y valida sus pruebas. No hace falta fragmentar una tarea sencilla si eso añade más coordinación que valor.

2. Lo que conviene verificar según la tecnología

No hay una lista fiable de fortalezas y debilidades universales de la IA por lenguaje. Los errores dependen de la tarea, las versiones, las bibliotecas, el contexto y las pruebas disponibles. Estos son puntos de revisión prácticos, no una clasificación de rendimiento:

Área	Qué pedir o comprobar	Riesgo que no debe darse por resuelto
Python y frameworks web	Fija versiones, validación de datos, manejo de errores y contratos de API. Comprueba la estructura de imports y ejecuta las pruebas del proyecto.	Los imports circulares son un problema posible de organización de módulos, no una debilidad exclusiva de la IA ni inevitable en proyectos grandes. Python documenta las condiciones en que pueden causar problemas.
JavaScript y React	Indica la versión de React y el tipo de proyecto; revisa el uso de estado, efectos y APIs actuales en la documentación correspondiente.	React aún soporta componentes de clase, aunque recomienda funciones para código nuevo. No basta decir que la IA «usa métodos viejos»: hay que señalar la API, versión y alternativa concreta.
Apps móviles en Python	Elige el framework y el proceso de publicación antes de pedir una solución. Para Android verifica compatibilidad de dependencias nativas, SDK, firma, permisos y dispositivos objetivo.	KivyMD es una biblioteca de widgets sobre Kivy; Flet tiene su propio flujo de compilación para Android. Buildozer pertenece al flujo de empaquetado de Kivy y no es un requisito genérico para Flet.
HTML, CSS y accesibilidad	Comprueba HTML semántico, navegación por teclado, etiquetas, texto alternativo y contraste; evalúa las páginas con los criterios WCAG pertinentes.	HTML estructura contenido y CSS controla su presentación: ninguno garantiza por sí solo accesibilidad ni posicionamiento SEO. Son objetivos relacionados, pero se comprueban por separado.
SQL y bases de datos	Prueba la consulta con datos representativos y revisa el plan de ejecución, índices existentes, restricciones, transacciones y migraciones.	Un índice sugerido no es automáticamente una optimización. El costo depende del motor, la distribución de datos y la carga real; medir con herramientas del motor, como `EXPLAIN`, antes de aplicarlo.

3. Revisa el cambio antes de integrarlo

La revisión no termina al copiar una respuesta ni cuando una prueba aislada pasa. Revisa el cambio completo en el proyecto:

Comportamiento: contrasta el código con los requisitos, ejemplos, casos límite y errores esperables.
Pruebas: ejecuta las pruebas existentes y añade casos para el comportamiento nuevo. Una prueba aprobada solo respalda lo que esa prueba comprueba.
Seguridad y datos: inspecciona validación de entradas, autorización, consultas, gestión de errores, secretos y datos personales. No pegues secretos en el asistente.
Integración: revisa dependencias, compatibilidad, migraciones, interfaces públicas y cambios fuera del alcance.
Operación: entiende los comandos, scripts y efectos antes de ejecutarlos, especialmente si modifican datos o infraestructura.
Mantenimiento: confirma que el cambio sigue las convenciones del repositorio y que otra persona podrá entenderlo y modificarlo.

Una respuesta que pasa pruebas aporta evidencia sobre esos casos. No demuestra por sí sola que el cambio sea seguro, completo o adecuado para producción.

4. Usa la IA como apoyo, no como autoridad final

Pídele que explique decisiones, cite documentación oficial cuando la versión importe y proponga pruebas que puedan ejecutarse. Contrasta las recomendaciones con la documentación del proyecto y del proveedor. Si no puede inspeccionar el repositorio o ejecutar el código, trata sus conclusiones como hipótesis pendientes de validar.

El grado de revisión debe corresponder al impacto del cambio. Una función local de bajo riesgo puede requerir pruebas automatizadas y revisión habitual; autenticación, pagos, permisos, migraciones o infraestructura merecen revisión especializada y controles adicionales. El lenguaje no determina por sí solo el nivel de riesgo.

Buscar este blog

Corazón Sabio