Receta práctica de uso general. Adáptala a tu empresa, revisa lo que produzca la IA antes de usarlo y comprueba el contrato y la configuración de tu herramienta antes de meter datos. Tú decides cómo aplicarla y respondes de su uso.

Resumen. Un asistente de código con cuenta de empresa sugiere código, escribe pruebas y documentación y explica código heredado, y rinde más en perfiles junior y en tareas nuevas y bien definidas. En tres experimentos de campo con 4.867 desarrolladores (Microsoft, Accenture y una empresa de Fortune 100) completaron un 26 % más de tareas (Cui y otros, Management Science, 2025), pero en otro experimento los veteranos que trabajaban en su propio código complejo fueron un 19 % más lentos con IA, aunque creían ir más rápido (METR, 2025).

Ficha rápida


Para quién	Empresas de software y TIC, departamentos de IT de cualquier sector, ingenierías que programan herramientas propias. Equipos de 1 a 50 desarrolladores. Lo lleva el responsable técnico.
Tiempo	5 días de puesta en marcha y 2 semanas de medición.
Esfuerzo	1/5 · Una persona, una semana, sin informática (aquí, sin integraciones nuevas).
Coste orientativo	Depende del plan. Los asistentes generalistas en plan empresa (18-30 € por usuario y mes, comprobado a 7-nov-2026) ya programan; los asistentes integrados en el editor y los agentes de programación tienen precios propios que no hemos comprobado.
Reglamento de IA	Riesgo mínimo. Solo te obliga el art. 4 (formación de quien lo usa).
Datos personales	Bajo, siempre que no pegues datos de producción ni bases de datos con clientes.

Qué necesitas antes de empezar

Control de versiones (repositorio Git) y revisión de código por otra persona. Si no tienes ninguna de las dos, empieza por ahí: sin ellas, el código generado es un riesgo.
Cuenta de empresa del asistente de código (por ejemplo, GitHub Copilot u otros asistentes integrados en el editor) o de un asistente generalista, con garantías de que no entrena con tu código.
Una regla escrita: nada de contraseñas, claves de API, certificados ni datos de clientes en las instrucciones ni en el contexto.
Un proyecto no crítico para el piloto.
Formación mínima: 1 hora sobre revisión de código generado y secretos.

Semáforo de datos para esta receta

Color	¿Lo meto?	Ejemplos
VERDE	Sí	Código abierto, documentación pública de librerías, preguntas generales de programación.
AMARILLO	Sí, con la cuenta de empresa	Código propio no crítico, mensajes de error, esquemas de base de datos sin datos.
NARANJA	No	Datos reales de clientes, registros con correos o teléfonos, volcados de bases de datos de producción. Usa datos ficticios.
ROJO	Nunca	Contraseñas, claves de API, certificados, archivos `.env`, código de seguridad crítico o código cedido por un cliente con cláusula de confidencialidad sin su permiso.

Paso a paso

Día 1 · Prepara el terreno — Quién: responsable técnico · Tiempo: 1,5 h

Elige 1-2 desarrolladores para el piloto (si puedes, uno junior y uno senior) y un proyecto no crítico.
Saca la línea base de las 2 semanas anteriores: tareas cerradas, defectos encontrados en revisión o pruebas, incidencias tras el despliegue.
Comprueba que el repositorio ignora los archivos de secretos y activa un detector de secretos si tu plataforma lo ofrece.
Contrata las licencias de empresa y desactiva, si existe la opción, que se use tu código para entrenar.

Día 2 · Reglas y formación — Quién: responsable técnico + piloto · Tiempo: 1 h

Escribe 6 reglas en el README del proyecto:
1. Todo código generado pasa por revisión humana como cualquier otro.
2. Nada de secretos ni datos reales en el contexto.
3. Si no entiendes lo que ha generado, no lo subas.
4. Pruebas antes de fusionar.
5. Revisa licencias si te propone fragmentos largos que parecen copiados.
6. Anota en la descripción del cambio si ha participado la IA.
Enseña los prompts de esta receta.

Día 3 · Tareas donde más rinde — Quién: piloto · Tiempo: trabajo normal

Usa el asistente en lo que mejor funciona: pruebas unitarias (prompt 2), documentación, funciones nuevas bien definidas, scripts y explicaciones de código heredado (prompt 3).
Evita el primer día lo que menos rinde: cambios grandes en código propio complejo que el desarrollador ya domina.

Día 4 · Revisión de lo generado — Quién: otro desarrollador · Tiempo: 1 h

Revisa los cambios del piloto con el prompt 4 como ayuda (no como sustituto).
Apunta defectos encontrados y si venían de código generado.

Día 5 · Arranca la medición de 2 semanas — Quién: responsable técnico · Tiempo: 30 min

Define cómo se mide: tareas cerradas, defectos en revisión, incidencias tras el despliegue, frente a la línea base.
No midas por la sensación de rapidez. En el experimento de METR, los desarrolladores creían que habían ido un 20-24 % más rápido y fueron un 19 % más lentos.
A las 2 semanas: si mejoran las tareas cerradas sin subir los defectos, extiende al resto del equipo.

Prompts listos para copiar

Prompt 1 · Implementar una función bien definida

Lenguaje y versión: [p. ej., Python 3.12]. Framework y versión: [X]. Estilo del proyecto: [enlace o resumen de convenciones].
Necesito una función que [DESCRIPCIÓN EXACTA].
Entradas: [TIPOS Y EJEMPLOS]. Salida: [TIPO Y EJEMPLO]. Casos límite: [LISTA].
Restricciones: sin dependencias nuevas salvo [X]; no uses APIs obsoletas en esa versión.
Entrega:
1. El código, con comentarios breves.
2. Pruebas unitarias que cubran los casos límite.
3. Una lista de supuestos que has hecho y que debo confirmar.
Si una función o librería no estás seguro de que exista en esa versión, dilo en vez de inventarla.

Prompt 2 · Escribir pruebas para código existente

Este es el código (sin secretos ni datos reales):
"""
[PEGA LA FUNCIÓN O CLASE]
"""
Escribe pruebas unitarias con [FRAMEWORK DE PRUEBAS] que cubran: caso normal, entradas vacías o nulas, valores límite y errores esperados.
No cambies el código original. Si ves un posible error en el código, descríbelo aparte en "POSIBLES DEFECTOS" sin corregirlo.

Prompt 3 · Entender código heredado

Explícame este código heredado como si fuera mi primer día en el proyecto:
"""
[PEGA EL CÓDIGO]
"""
1. Qué hace, en 5 frases.
2. Flujo paso a paso.
3. Dependencias externas y efectos secundarios (ficheros, base de datos, red).
4. Partes frágiles o difíciles de mantener.
No supongas el comportamiento de funciones que no aparecen: márcalas como "DEFINIDA FUERA, REVISAR".

Prompt 4 · Segunda opinión en una revisión

Revisa este cambio como revisor exigente. Contexto del proyecto: [1-2 FRASES].
"""
[PEGA EL DIFF]
"""
Busca: errores de lógica, casos no tratados, problemas de seguridad (inyección, validación de entradas, secretos), rendimiento y legibilidad.
Tabla: Línea | Problema | Gravedad (alta/media/baja) | Sugerencia.
Si no encuentras problemas graves, dilo. No inventes problemas para rellenar.

Cómo medir el beneficio

Métrica principal: tareas cerradas por desarrollador y semana.
Métricas de control: defectos encontrados en revisión, incidencias en producción y tiempo de revisión.
Antes / después: 2 semanas antes frente a 2 semanas con asistente, en el mismo proyecto.
Hoja simple:

Semana	Desarrollador	Junior/senior	Tareas cerradas	Defectos en revisión	Incidencias tras desplegar	¿Usó IA?	Nota

Riesgos y cómo evitarlos

Riesgo	Cómo evitarlo
Código que parece correcto y no lo es (funciones que no existen, versiones equivocadas, fallos de seguridad).	Revisión humana obligatoria y pruebas. Prompt con versión exacta. “Si no lo entiendes, no lo subas”.
Fuga de secretos o código confidencial.	Cuenta de empresa sin entrenamiento, detector de secretos, regla escrita.
Más lento en expertos con código complejo (E09).	Medir con datos, no con sensaciones. Dejar que cada persona decida cuándo lo usa.
Juniors que no aprenden. El empleo de entrada cae donde la IA automatiza (Stanford, 2025).	Pedir a los juniors que expliquen el código generado en la revisión. Usar el prompt 3 para aprender, no solo para copiar.
Reglamento de IA.	Riesgo mínimo: art. 4. Si con el asistente desarrollas un sistema de IA y lo pones en servicio con tu nombre, tu empresa pasa a ser proveedor de ese sistema; sus obligaciones dependerán de su uso (`../legal/clasificacion.md` §5).

Errores típicos

Pegar un archivo .env o una cadena de conexión “para que entienda el error”.
Medir el éxito por lo contento que está el equipo.
Aceptar sugerencias largas sin leerlas.
No decir la versión del lenguaje o del programa: la IA mezcla versiones.
Usarlo primero en el módulo más crítico.

Siguiente nivel

En IT y desarrollo, esta receta te lleva al nivel 3: asistente de código corporativo, política que prohíbe pegar credenciales y revisión del código generado.

Nivel 4: IA en el ciclo de desarrollo (revisión de código, pruebas, documentación) y en el soporte interno (ver R18).
Nivel 5: mides tiempo de ciclo, defectos e incidencias y lo comparas con el periodo anterior.

Fuentes

E05 · Cui, Demirer, Jaffe, Musolff, Peng y Salz (2025). Management Science, DOI 10.1287/mnsc.2025.00535. Tres RCT de campo, 4.867 desarrolladores: +26,08 % de tareas completadas. VERIFICADO.
E04 · Peng y otros (2023). arXiv:2302.06590. RCT de laboratorio: 55,8 % más rápido en una tarea nueva y bien definida. VERIFICADO.
E09 · Becker y otros (2025). METR, arXiv:2507.09089. RCT, 16 desarrolladores veteranos: 19 % más lentos. VERIFICADO.
E19 · Brynjolfsson, Chandar y Chen (2025). Stanford Digital Economy Lab. VERIFICADO (resumen).
Reglamento (UE) 2024/1689, arts. 3.3 y 4: https://eur-lex.europa.eu/eli/reg/2024/1689/oj

Siguiente paso: haz el diagnóstico gratuito de InteligenciaArtificial.eu (5 minutos la versión rápida): tu grado de implantación frente a tu sector y, según tus respuestas, qué te pide el Reglamento europeo de IA → Empezar gratis

Información general, no asesoramiento jurídico ni profesional. Los resultados dependen de tu empresa: mide antes y después.

Más contexto: cómo implantar la IA en la empresa, por dónde empezar y todas las guías.

Cómo implantar un asistente de programación con IA en tu equipo de desarrollo