Link Search Menu Expand Document
DWES DOCS

1.3. Uso eficiente y ético de la IA en desarrollo backend

DESCARGAR PRESENTACIÓN

1.3.1. Por qué este documento existe

Vamos a hablar claro: en este curso, puedes y DEBES usar IA.

La IA es una herramienta que vas a tener disponible el resto de tu carrera profesional, te guste o no. Cualquier empresa de desarrollo de software actual da por hecho que sabes usar estas herramientas. Lo raro para un programador, a estas alturas, sería no usarlas.

Pero (y este pero es importante) hay una diferencia abismal entre usar la IA para programar mejor y usar la IA para no tener que aprender a programar.

Eso sería un suicidio profesional para ti, incluso aunque lograses aprobar el curso.

Este documento existe para dejar clarísima esa diferencia, explicarte por qué la segunda opción es una trampa que solo te hace daño a ti mismo, y contarte exactamente cómo vamos a comprobar, a lo largo del curso, que lo que entregas es tuyo de verdad.

Léetelo entero. No es un trámite burocrático, es literalmente la diferencia entre que este curso (y este título) te sirva para algo o no.

1.3.2. La trampa de «que lo haga la IA»

Vamos a hacer un ejercicio de sinceridad. Le pides a una IA que te genere un CRUD completo en Laravel, lo copias y lo pegas, lo entregas, y sacas un notable. ¿Qué has conseguido?

Una nota. Nada más. Una mentira que te estás contando a ti mismo. Cuando llegues a una empresa, a nadie le importará un pimiento tu notable. Lo único que les importará es qué sabes hacer TÚ.

Aquí van las razones, sin rodeos, de por qué esto es una pésima idea, incluso (sobre todo) si tu único objetivo fuera “aprobar como sea”:

  • La nota no es el producto, es la señal. La nota existe para decirte a ti (no a una futura empresa) si sabes hacer algo. Si falsificas la señal, no has ganado nada: sigues sin saber hacerlo, solo que ahora tienes un papel que dice lo contrario. Y ese papel se va a poner a prueba en la primera entrevista técnica o en tu primer día de prácticas en una empresa real.
  • Este módulo se construye por capas. Lo que no entiendes hoy de Eloquent te va a explotar en la cara dentro de tres semanas, cuando lo demos por sabido para explicar otra cosa. Copiar y pegar sin entender no es “ganar tiempo”, es pedir un préstamo con intereses que vas a tener que pagar más adelante (normalmente en el peor momento posible).
  • Vas a tener que defenderlo. Como verás en el apartado 1.3.5, en este curso el código que entregas no es el final de la historia: vas a tener que explicarlo, defenderlo y, en algunos casos, modificarlo en vivo. Y ahí no hay IA que te salve.
  • Le estás mintiendo a la única persona a la que no le conviene mentir: a ti. Recuerda siempre que dentro de unos meses vas a hacer las prácticas en empresa o vas a buscar tu primer trabajo.

No se trata de que “la IA sea trampa”. Se trata de que usarla para evitar aprender es la única forma de usarla mal. El resto de usos (y son muchos, y son potentísimos) son bienvenidos. Sigue leyendo.

1.3.3. Lo que te va a pedir el mercado laboral

Desde un punto de vista práctico, esto es, a grandes rasgos, lo que hoy en día una empresa espera de un programador/a junior, tanto en habilidades técnicas tradicionales como en habilidades relacionadas con IA:

Como programador/a:

  • Que entiendas el código que escribes y el que te entregan tus compañeros, no que “funcione y ya está”.
  • Que sepas depurar un error tú solo/a cuando la IA (o una búsqueda en Google) no te da la respuesta correcta a la primera, cosa que pasa constantemente.
  • Que entiendas lo suficiente de arquitectura (en nuestro caso, MVC, ORM, API REST…) como para saber dónde debe ir cada cosa, aunque no te acuerdes de memoria de la sintaxis exacta.
  • Que puedas justificar tus decisiones técnicas delante de tu equipo, tu responsable técnico o un cliente. “Porque la IA me dijo que era así” no es una respuesta aceptable en una code review real.
  • Que sepas leer y entender código que no has escrito tú, porque, en tu primer trabajo, el 90% de tu tiempo lo vas a pasar dentro de un proyecto que ya existía antes de que llegaras y modificando código que puede llevar 20 años escrito y funcionando.

Como usuario/a de IA:

  • Que sepas usarla como un acelerador, no como un sustituto: pedirle que te genere un test, que te sugiera una refactorización, que te explique un error inexplicable, que te proponga varias formas de resolver algo para que tú elijas, etc.
  • Que sepas revisar y cuestionar lo que te devuelve, en lugar de aceptarlo a ciegas. La IA se equivoca, alucina funciones que no existen, y a veces te sugiere soluciones que funcionan pero que son una barbaridad desde el punto de vista de la seguridad o el rendimiento. Si no sabes lo suficiente como para detectarlo, el problema no es la IA, eres tú.
  • Que entiendas sus límites: una IA no conoce el contexto completo de tu proyecto, ni tus decisiones de arquitectura previas, ni las restricciones concretas del cliente. Tú sí (o deberías conocerlas).
  • Cada vez más empresas hacen entrevistas técnicas que incluyen el uso de IA para ver cómo la usas: qué le preguntas, cómo verificas la respuesta, si detectas cuando se equivoca. Saber usarla bien es, en sí mismo, una habilidad que se valora mucho.

Nadie te va a echar de una empresa por usar IA. Te van a echar (o, peor, ni siquiera te van a contratar) si demuestras que sin ella no sabes hacer nada.

1.3.4. Cómo SÍ vamos a usar la IA en este curso

Nos vamos a centrar, sobre todo, en tres usos concretos:

  1. Asistencia para refactorización. Ya tienes un código que funciona. Lo has escrito tú, aunque sea con ayuda, y lo entiendes. Es razonable pedirle a la IA sugerencias para mejorarlo: nombres más claros, eliminar duplicación, aplicar un patrón mejor, simplificar una condición enrevesada. Tú decides qué sugerencias aceptas y por qué.
  2. Generador de tests. Le describes qué hace una función o un endpoint y le pides que te proponga casos de prueba (incluyendo casos límite en los que quizá no habrías pensado). Es una de las tareas donde la IA rinde muchísimo y donde el riesgo de “hacer trampa” es prácticamente nulo, porque los tests no sustituyen tu código, lo ponen a prueba.
  3. Resolución de dudas puntuales. “¿Por qué me da este error?”, “¿qué significa este mensaje de Laravel?”, “¿cuál es la diferencia entre estos dos métodos?”. Es un profesor particular disponible 24 horas. Úsalo así.

¿Y generar código directamente? Aquí está el matiz importante: es razonable, y no vamos a perseguirlo, que la IA te genere esqueletos o scaffolding de una parte del proyecto (la estructura de un controlador, las rutas básicas de un recurso, un modelo con sus relaciones ya esbozadas). Es exactamente el tipo de código repetitivo y mecánico que a cualquier programador/a profesional también le interesa generar rápido para no perder el tiempo escribiéndolo a mano.

La condición, la única de verdad importante, es esta: antes de entregarlo, tienes que entender cada línea que hay en tu entrega, la haya escrito tu mano o la IA. Si no puedes explicar por qué una línea está ahí y qué pasaría si la borraras, esa línea no debería estar en tu entrega. Punto.

Lo que no vamos a considerar un uso razonable es pedirle a la IA “hazme la práctica entera” y entregarla sin haber entendido ni tocado nada. No porque esté “prohibido” en un sentido policial, sino porque, como hemos visto, solo estaríamos perdiendo el tiempo. El tuyo y el mío.

1.3.5. Protocolo de entregas: cómo comprobaremos la autoría

Vamos a usar tres mecanismos complementarios para asegurarnos razonablemente de que lo que entregas lo entiendes de verdad.

Digo “razonablemente” porque ningún método es infalible al cien por cien. El objetivo no es “cazarte”, es que te resulte costoso fingir que aprendes. Pero, si finges lo suficientemente bien, seguro que consigues engañarme. Es decir, engañarte a ti mismo/a.

Los tres mecanismos de comprobación que usaremos son:

  1. Explicación de decisiones técnicas, sobre tu propia entrega, de forma oral y sin IA.
  2. Exámenes con cambios en vivo, unos días después de la entrega, también sin IA.
  3. Code reviews entre compañeros, con tiempo limitado, sobre código ajeno.

Vamos uno por uno.

Enfoque 1: Explicación de decisiones técnicas

Cómo funciona:

  • Fase A (con IA permitida): desarrollas tu tarea, proyecto o examen con toda la ayuda de la IA que consideres oportuna.
  • Fase B (sin IA, en vivo): después de entregado tu código, te haré unas preguntas de control sobre tu propio código, que no conoces de antemano, y que tendrás que responder ahí mismo, sin consultar ninguna IA.

Los exámenes podrán basarse en prácticas que tú has entregado, así que cada alumno/a puede tener preguntas distintas (aunque parecidas en dificultad y que evalúen las mismas competencias). Así que debes conocer bien el código que has entregado en las prácticas para afrontar con éxito el examen.

Ejemplo de preguntas (sobre un modelo Eloquent de Laravel; lo entenderás mejor cuando vamos Laravel):

  • ¿Por qué usas hasMany en lugar de belongsToMany en este modelo? ¿Qué cambiarías si la relación fuera muchos-a-muchos?
  • Identifica dos líneas de tu código que podrían causar un problema de rendimiento o de seguridad (por ejemplo, una consulta N+1 o una inyección SQL) y explica cómo las corregirías.

No hace falta que la respuesta sea perfecta. Lo que buscamos es que se note que sabes por qué tu código es como es, no que lo hayas memorizado.

Enfoque 2: Exámenes con cambios en vivo

Cómo funciona:

  • En el examen individual inicial, sí se permite el uso de IA, con las mismas reglas del apartado 1.3.4.
  • Unos días después, habrá un segundo examen, esta vez sin IA (en papel), en el que tendrás que modificar tu propio código entregado o responder preguntas sobre él.

Igual que en el enfoque anterior, este segundo examen se generará a partir de las respuestas que cada alumno/a entregó en el primero, así que será ligeramente distinto (aunque comparable en dificultad) para cada persona.

Ejemplo:

Imagina que en tu examen inicial entregaste un pequeño CRUD de tareas (Task) con Eloquent, incluyendo un método para listar solo las tareas pendientes. Unos días después, en el segundo examen (sin IA), te puedo pasar tu controlador TaskController y tu modelo Task impreso y pedirte algo así:

Tu controlador TaskController tiene un método index() que devuelve todas las tareas. Añade al modelo Task un método llamado completadas() que permita obtener solo las tareas marcadas como completadas, y modifica el método index() para que acepte un parámetro por query string (?estado=completadas) que use ese método cuando esté presente.

No es un ejercicio inventado desde cero: es una situación típica del mundo real y que parte de tu propio código, sobre el que deberías tener soltura si lo entendiste, lo escribiste y lo revisaste la primera vez.

Enfoque 3: Code reviews entre pares

Cómo funciona:

En sesiones concretas del curso, revisaréis el código de un compañero o compañera (nunca el vuestro), o bien código que os presentará el profesor, con un tiempo limitado y sin IA para hacerlo.

Ese límite de tiempo no es capricho: es precisamente lo que hace que este método funcione. Con diez o quince minutos y el reloj corriendo, hay que ir directo al grano, lo que demuestra si de verdad conocéis la arquitectura de Laravel (o de lo que estemos trabajando en ese momento) o si solo la habéis visto pasar por delante.

Ejemplo:

Se os entrega este fragmento de un controlador de Laravel y tenéis cinco minutos para hacer una code review con sugerencias constructivas:

public function store(Request $request)
{
    $user = User::find($request->user_id);

    $post = new Post();
    $post->title = $request->title;
    $post->body = $request->body;
    $post->user_id = $request->user_id;
    $post->save();

    return Post::all();
}

En cinco minutos, alguien que domine mínimamente Laravel debería poder señalar, entre otras cosas:

  • No hay validación de los datos de entrada ($request->title y $request->body podrían venir vacíos, o directamente no existir).
  • No se comprueba si $user existe antes de usarlo (y, de hecho, ni siquiera se usa la variable $user para nada).
  • Sería más idiomático usar asignación masiva (Post::create($request->validated())) en lugar de asignar campo a campo.
  • Devolver Post::all() al final es un problema de rendimiento serio: con cada store(), se está trayendo toda la tabla de posts en lugar de devolver, por ejemplo, el post recién creado.

Ese tipo de hallazgos, hechos con el reloj corriendo y sin preguntar a nadie (ni a una IA), son un termómetro bastante fiable de cuánto has interiorizado de verdad.

layout: page title: Ejercicio 1.3 — Genera, entiende, defiende permalink: /uso-de-ia-ejercicio/ nav_order: 4 has_children: false parent: 1 Herramientas de desarrollo y flujo de trabajo profesional grand_parent: Desarrollo Web en Entorno Servidor —

1.3.6. Práctica final

¿Qué vamos a hacer?

Si te has leído cuidadosamente este apartado, ya sabes que en este curso vamos a comprobar que lo que entregas lo entiendes de verdad, sea tuyo al 100% o generado con ayuda de una IA, y que uno de los mecanismos que usaremos es explicar tus decisiones técnicas, en vivo y sin IA.

Este ejercicio es un calentamiento de ese mecanismo. Todavía no hemos visto Laravel ni nada del temario propiamente dicho, así que vamos a ponerlo en práctica sin presión de nota, solo para que te familiarices con la dinámica antes de que cuente para algo.

El ejercicio tiene tres fases y dura unos 15-20 minutos en total. Las vamos a hacer todas en clase, en orden, y cada una tiene sus propias reglas sobre si se puede usar IA o no. Léetelas bien antes de empezar cada fase, porque cambian.

Fase 1: Generar código con IA (5 minutos)

Pídele a una IA (la que quieras) que te escriba un método sencillo, pero no trivial, escrito en Java o el lenguaje de programación que usaste en primer curso. Un par de ideas, aunque puedes elegir otras parecidas:

  • Un método que reciba una lista de números y devuelva solo los que son primos.
  • Un método que valide si una cadena de texto tiene formato de email válido.

Puede ser cualquier cosa siempre que cumpla 2 condiciones:

  • Ser un método completo y autocontenido, es decir, que se pueda leer de arriba abajo sin depender de más código.
  • No ser trivial, es decir, que haya que pensar un poco para entenderlo, pero tampoco debe ser terriblemente complejo.

Guarda el código en un archivo. Lo vas a necesitar en las dos fases siguientes.

Fase 2: Entender el código generado (5 minutos)

Cierra la IA. En esta fase vas a trabajar solo/a, con tus propias palabras. En un documento aparte (no lo mezcles con el código), anota:

  1. Qué hace cada línea o cada bloque relevante del código, explicado como si se lo estuvieras contando a alguien que no lo ha visto y que no sabe programar. ¡Imagina que se lo estás explicando a mi abuela!.

    Y, si hay una o varias líneas que no sabes explicar, no dejes de investigar qué demonios significan cuando termines este ejercicio. Puedes usar una IA para ello.

  2. Casos de entrada para los que sospeches que la función podría fallar o comportarse raro. Por ejemplo: una lista vacía, un número negativo, una cadena vacía, un valor inesperado. No hace falta que ejecutes nada, solo que lo razones.

    Este segundo punto no es un capricho, sino el tipo de pensamiento que necesitarás más adelante para generar buenos tests y para usar la IA de forma crítica.

Puedes sentir la tentación de usar IA para hacer esta parte. Es lógico. ¡Es tan cómodo no tener que pensar! ¿Verdad? Pero estás aquí para aprender a pensar como un programador.

Ten en cuenta que, en futuras ocasiones, tendrás que hacer este ejercicio CON EL ORDENADOR APAGADO. Solo tú, tu cerebro, papel y bolígrafo.

Fase 3: Hacer el code review del código de otra persona (5-10 minutos)

Intercambia tu código (no tus notas) con un compañero o compañera.

Cada uno/a le va a hacer al otro 2 o 3 preguntas, de tipo técnico, sobre su código. Algunas ideas de preguntas que podéis usar (o inventar otras parecidas):

  • ¿Por qué usaste este bucle/estructura y no una función de librería que ya existe para esto?
  • ¿Qué pasaría si le pasas [pon aquí un caso límite que sospechas que podría fallar]?
  • ¿Por qué esta condición va antes que esa otra? ¿Cambiaría algo si las intercambiases de orden?
  • Señala una línea que podrías borrar sin que la función deje de funcionar en el caso normal. ¿Por qué está ahí entonces?

Reglas de esta fase:

  • Nada de IA ni de consultar tus propias notas de la Fase 2 para responder preguntas. Si te preguntan algo y no lo sabes, reconócelo. Eso información útil para ti, no un error.
  • El que pregunta tiene que escuchar de verdad la respuesta. Si la respuesta no le convence, que siga preguntando.
  • Sé constructivo/a. El objetivo no es dejar en ridículo a nadie, es que los dos salgáis de la fase entendiendo mejor un código que hace diez minutos ni siquiera habíais escrito vosotros mismos.
  • Después de unos 5 minutos preguntando el uno al otro, intercambiad los papeles.