Ingeniería de software: programar a lo largo del tiempo

En los cursos anteriores aprendieron a programar: a partir de un enunciado, escribir un programa que lo resuelve, probarlo con algunos casos y entregarlo. Casi todo ese código tuvo una vida corta. Se escribió en unos días, lo leyó una sola persona (quien lo calificó) y nadie lo volvió a abrir después de la nota. Eso no es un defecto de esos cursos: para aprender a programar, el código de corta vida es justo lo que hace falta.

Este curso trata del otro tipo de código: el que vive años, lo cambian muchas personas, lo usa gente real y tiene que seguir funcionando cuando cambian los requisitos, las herramientas y el equipo. A lo que hace falta para que eso funcione le llamamos ingeniería de software. No reemplaza a la programación; la contiene y le suma el tiempo, las personas y las decisiones.

Este primer capítulo tiene dos partes, como las dos sesiones de la semana. En la primera respondemos qué es la ingeniería de software, con las tres ideas del capítulo 1 de Software Engineering at Google (el texto principal del curso): el tiempo, la escala y las decisiones con costos. Por el camino aparece la ley de Hyrum, que vamos a ver funcionando en Kallpa, la aplicación de reservas sobre la que trabajan los laboratorios. En la segunda parte miramos las herramientas de IA que escriben código: qué hacen bien, qué hacen mal, qué dice la evidencia sobre su efecto real y por qué la responsabilidad por el código sigue siendo de quien hace commit. El capítulo termina con el laboratorio: Git en equipo, con ramas, pull requests y un conflicto de merge que resolvemos paso a paso.

Lectura. Este capítulo acompaña a Winters, Manshreck y Wright, Software Engineering at Google (SWEG), cap. 1, What Is Software Engineering?; como complemento, el cap. 2, How to Work Well on Teams. Para la Sesión B: CMU News, CMU Students Put AI Coding Tools to the Test (2025), y METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025), el resumen del estudio con su nota de actualización; como complemento, DORA, State of AI-assisted Software Development 2025, y el artículo completo del estudio de METR en arXiv. Para el laboratorio: Pro Git en español, cap. 3; GitHub, About pull requests y Creating a repository from a template; SWEG, cap. 16, Version Control and Branch Management. El código del capítulo está en code/week-01 y se prueba con make test dentro del contenedor del curso (./env/run.sh).

Ruta de lectura.

• Antes de clase (obligatorio, unos 20 minutos): El curso en una página; de Programación frente a ingeniería de software, Tres diferencias y ¿Cuánto tiempo va a vivir este código?; de La ley de Hyrum, El enunciado; y de La IA en el ciclo de desarrollo, Qué es una herramienta de IA para programar, Qué hace bien, Qué hace mal y La política del curso.
• En clase: Sesión A: Programación frente a ingeniería de software, La ley de Hyrum con sus ejemplos en Kallpa, Escala y políticas y Decisiones con costos. Sesión B: La IA en el ciclo de desarrollo, con el ejemplo del código que pasa sus propias pruebas y la evidencia. Laboratorio: Git en equipo.
• Después de clase: el Resumen y los Ejercicios; El laboratorio paso a paso, Las marcas de un conflicto y Leer git log --graph para repasar Git. Para profundizar: Shift left: encontrar el error antes, Evidencia, no anécdotas y las lecturas del recuadro Lectura.

El curso en una página

El curso tiene cuatro partes: proceso y requisitos (semanas 1 a 4), diseño y arquitectura (5 a 8), calidad (9 a 12) y producción y evolución (13 a 16). El calendario, las lecturas de cada semana y las políticas están en el programa del curso; cada semana tiene además su guía en weeks/.

Hay dos hilos que atraviesan el semestre:

• Kallpa, la aplicación de reservas de un complejo deportivo comunal de Lima, escrita para el curso en TypeScript con Node.js 26. Casi todos los laboratorios trabajan sobre ella: la van a leer, extender, probar, revisar, desplegar y auditar. Su README explica las reglas del negocio y la estructura del código.
• El proyecto, que se hace para un cliente real: una persona u organización con un problema que se pueda resolver con una aplicación web pequeña (un negocio del barrio, una asociación, una oficina de la universidad). La primera entrega, P0, es individual y se hace sobre Kallpa; de P1 a P5 el equipo construye su producto en tres sprints, desde las entrevistas hasta la entrega al cliente. El detalle está en projects/README.md.

En la defensa oral, cualquier integrante debe poder explicar cualquier parte del producto.

Las herramientas de IA están permitidas en el proyecto y en los laboratorios, con un registro de uso y una defensa oral; los exámenes son sin IA. La Sesión B explica por qué la política es así, y la sección La política del curso dice qué va en el registro.

El entorno es el mismo para todos: un contenedor Docker con Node.js 26, TypeScript, Git, la CLI de GitHub y las herramientas de calidad del curso. Lo instalan en el laboratorio de esta semana siguiendo la guía del laboratorio. Dentro del contenedor:

$ node --version
v26.13.0
$ tsc --version
Version 6.0.3
$ git --version
git version 2.47.3

Programación frente a ingeniería de software

Tres diferencias

El capítulo 1 de SWEG empieza separando dos cosas que solemos llamar igual. Según su autor, Titus Winters, hay tres diferencias críticas entre programar y hacer ingeniería de software:

1. El tiempo. Un proyecto de ingeniería de software tiene que preocuparse por el paso del tiempo y por la necesidad, tarde o temprano, de cambiar.
2. La escala. Una organización que hace software tiene que preocuparse por la eficiencia cuando crece: la del software que produce y la de la propia organización que lo produce.
3. Las decisiones. Quien hace ingeniería de software toma decisiones más complejas y con más en juego, muchas veces a partir de estimaciones imprecisas sobre el tiempo y el crecimiento.

Dentro de Google lo resumen en una frase que el capítulo cita: la ingeniería de software es programación integrada en el tiempo (“software engineering is programming integrated over time”). La metáfora es matemática: así como integrar una función en el tiempo agrega una dimensión (la velocidad integrada da la distancia, un cuadrado extendido en otra dimensión da un cubo), la ingeniería de software es la programación más la dimensión del tiempo. Programar es una parte importante de la ingeniería de software, porque es como se produce el código nuevo; pero el trabajo de ingeniería incluye también modificar y mantener ese código mientras siga en uso.

Idea clave. Programar es el acto inmediato de producir código. La ingeniería de software es el conjunto de políticas, prácticas y herramientas que hacen falta para que ese código siga siendo útil todo el tiempo que se necesite, y para que un equipo pueda colaborar en él.

Esa última frase es casi textual del final del capítulo, y vale la pena leerla con cuidado: no dice que la ingeniería de software sea “mejor” que la programación. SWEG insiste en que son dos dominios de problemas con restricciones y buenas prácticas distintas. Para un programa que va a durar unos días no hacen falta pruebas de integración ni despliegue continuo, y preocuparse por el versionado semántico de sus dependencias es perder el tiempo. El error es aplicar las prácticas de un dominio en el otro: tratar un sistema que va a vivir años como si fuera un script, o tratar un script como si fuera un sistema.

¿Cuánto tiempo va a vivir este código?

La pregunta que separa los dos dominios es simple: ¿cuál es la vida esperada de este código? Con “vida” SWEG no se refiere a cuánto tarda en ejecutarse, sino a cuánto tiempo se va a seguir compilando, ejecutando y manteniendo; cuánto tiempo va a dar valor.

Las respuestas razonables a esa pregunta varían en un factor de alrededor de 100 000. Es igual de razonable un código que tiene que durar unos minutos que uno que va a vivir décadas. Comparen dos programas que podrían escribir esta semana:

En el script de una tarde no importa si mañana sale una versión nueva de Node.js: no se va a volver a ejecutar. En Kallpa sí importa, y mucho: en diez años van a haber cambiado casi todas sus dependencias, explícitas o implícitas, y el código tiene que poder seguirlas.

SWEG observa algo más sobre la transición entre esos extremos. En algún punto de la escala, un proyecto empieza a tener que reaccionar a cambios externos. Para un proyecto que no se preparó, la primera actualización grande suele ser muy dolorosa, por tres razones que se suman: es una tarea que nunca se hizo en ese proyecto (hay más supuestos escondidos), quienes la hacen tienen poca experiencia en ese tipo de tarea, y el cambio es más grande de lo normal, porque se acumularon años de actualizaciones. Después de una experiencia así, muchos equipos concluyen “nunca más” y eligen no actualizar o reescribir todo. A veces la respuesta más responsable es la contraria: invertir en que actualizar sea menos doloroso.

Sostenibilidad

De ahí sale la definición central del capítulo:

Definición. Un proyecto es sostenible si, durante toda la vida esperada del software, es capaz de reaccionar a cualquier cambio que valga la pena, por razones técnicas o de negocio.

Tres detalles de esa definición:

• Habla de capacidad, no de obligación. Un equipo puede decidir no hacer una actualización porque no aporta valor o porque tiene otras prioridades. Lo que no puede permitirse es ser incapaz de hacerla: eso es apostar a que ese cambio nunca se va a volver crítico. Para un proyecto corto, la apuesta puede ser segura; a lo largo de décadas, probablemente no.
• Habla de cambios que valgan la pena. Cambiar no es bueno en sí mismo.
• Incluye razones técnicas y de negocio. Para Kallpa, ejemplos de cambios que valen la pena serían una vulnerabilidad en una dependencia, una versión nueva de Node.js, una ley que obligue a emitir comprobantes electrónicos o un pedido de la administración (“los domingos atendemos de 8:00 a 20:00”).

Una nota al pie del capítulo da una definición informal de deuda técnica que vamos a usar en la semana 16: lo que “debería” hacerse en el código y todavía no se hizo, la diferencia entre el código que tenemos y el que quisiéramos tener.

Escala: muchas personas, muchas versiones

La otra forma de mirar la ingeniería de software es por la escala: cuántas personas participan y qué papel tienen a lo largo del tiempo. Una tarea de programación suele ser un acto de creación individual; una tarea de ingeniería de software es un trabajo de equipo. SWEG cita una definición antigua que lo dice bien: la ingeniería de software es “el desarrollo de programas de muchas versiones por muchas personas” (“the multiperson development of multiversion programs”). El mismo libro aclara que no está claro quién la dijo primero (se le atribuye a Brian Randell, a Margaret Hamilton o a David Parnas). El término software engineering se popularizó con las conferencias de la OTAN de 1968 y 1969, convocadas para discutir los problemas de los proyectos grandes de software: llegaban tarde, costaban más de lo previsto y fallaban.

Trabajar en equipo trae problemas nuevos (coordinarse, comunicarse, no pisarse el trabajo), pero también permite construir cosas que nadie podría construir solo. El capítulo 2 de SWEG, la lectura complementaria, trata ese lado humano. Dos ideas de ese capítulo que vamos a usar todo el semestre:

• El mito del genio. Tendemos a atribuirle el éxito de un equipo a una sola persona. SWEG recuerda que Linus Torvalds escribió el comienzo de un kernel tipo Unix y lo mostró en una lista de correo; Linux es cientos de veces más grande que ese primer kernel y lo escribieron miles de personas. El logro de Torvalds fue coordinar a esa comunidad. La reacción típica del mito es esconderse a trabajar hasta tener algo “perfecto”; SWEG argumenta que eso retrasa la detección de errores y hace más lento al equipo.
• El bus factor (factor bus): cuántas personas tendrían que ser atropelladas por un bus para que el proyecto quede condenado. Si solo ustedes entienden una parte del código, el bus factor de esa parte es 1. La receta del capítulo: buena documentación y, para cada área, un responsable principal y uno secundario.

Idea clave. En su proyecto, el bus factor importa de verdad: el curso pide que cualquier integrante pueda explicar cualquier parte del producto en la defensa oral. Una parte que solo entiende una persona (o que no entiende nadie, porque la escribió una herramienta y nadie la leyó) es un riesgo para el equipo y para su nota.

La ley de Hyrum

El enunciado

Si mantienen un proyecto que otras personas usan, la lección más importante sobre la diferencia entre “funciona” y “se puede mantener” es la que en Google llaman ley de Hyrum, por Hyrum Wright, uno de los autores del libro:

Con una cantidad suficiente de usuarios de una API, no importa lo que se prometa en el contrato: todo comportamiento observable del sistema va a ser usado por alguien.

Conviene separar dos cosas que la ley pone frente a frente:

• El contrato es lo que el sistema promete: lo que dice la documentación, los tipos de una API, la especificación. Quien depende solo del contrato puede esperar que el sistema lo siga cumpliendo.
• El comportamiento observable es todo lo que el sistema hace y alguien puede ver: el orden de los resultados, el texto de los mensajes de error, el tiempo que tarda, los campos de más que vienen en una respuesta, el formato exacto de una fecha.

El comportamiento observable siempre es más grande que el contrato. La ley de Hyrum dice que, con suficientes usuarios y suficiente tiempo, alguien va a depender de la diferencia. SWEG la compara con la entropía: no se puede eliminar, pero sí se puede planificar teniéndola en cuenta. Y saca la consecuencia práctica: con suficiente tiempo y suficientes usuarios, hasta el cambio más inofensivo va a romper algo, y el análisis del valor de un cambio tiene que incluir el costo de investigar, encontrar y arreglar esas roturas.

En la industria. El ejemplo de SWEG es el orden en que se recorre una tabla hash. Casi todos saben que ese orden “no está definido”, pero pocos saben si la implementación que usan piensa mantenerlo para siempre, y en la práctica hay programas que dependen de él. Con el tiempo aparecieron razones para cambiarlo: algoritmos de hash más eficientes y los ataques de hash flooding, en que alguien que conoce la función de hash envía datos que chocan todos en el mismo lugar y vuelven lenta la tabla; la defensa (una función de hash con semilla aleatoria) cambia el orden. Algunos lenguajes empezaron a cambiar el orden a propósito entre versiones, o incluso entre ejecuciones, para que nadie pueda depender de él. Aun así, cuenta el libro, aparecieron programas que usaban ese orden aleatorio como un generador de números aleatorios (ineficiente): quitarle la aleatoriedad ahora los rompería. (SWEG, cap. 1, Example: Hash Ordering.)

Un ejemplo en Kallpa: el orden de las canchas

La API de Kallpa tiene una ruta para listar las canchas. Su README la documenta así:

Ese es el contrato: una lista de canchas con id, name y sport. No dice nada del orden. Ahora miremos el comportamiento observable, con Kallpa corriendo en el contenedor:

$ curl -s localhost:3000/api/courts | jq
{
  "courts": [
    {
      "id": 4,
      "name": "Básquet",
      "sport": "basquet"
    },
    {
      "id": 1,
      "name": "Fulbito 1",
      "sport": "fulbito"
    },
    {
      "id": 2,
      "name": "Fulbito 2",
      "sport": "fulbito"
    },
    {
      "id": 3,
      "name": "Vóley",
      "sport": "voley"
    }
  ]
}

Las canchas vienen ordenadas por nombre, no por id. Es porque el repositorio de canchas (court-repository.ts) hace la consulta con ORDER BY name:

list(): Court[] {
  return this.#db.prepare('SELECT id, name, sport FROM courts ORDER BY name').all() as Court[];
}

Nadie lo prometió, pero cualquiera lo puede ver. Y en cuanto alguien lo ve, alguien depende de ello. Supongan que una liga de fulbito escribe un bot de WhatsApp que reserva la cancha de siempre, y quien lo programó miró la respuesta de arriba y escribió esto (hyrum-clients.ts):

// "La segunda cancha de la lista es Fulbito 1": cierto hoy, porque Kallpa
// ordena por nombre y 'Básquet' va antes que 'Fulbito 1'.
export function fulbitoOneFragile(courts: CourtJson[]): number {
  return courts[1].id;
}

Hoy funciona. Ahora supongan que alguien del equipo de Kallpa cambia la consulta a ORDER BY id, porque le parece más natural o porque es un poco más rápido. El cambio respeta el contrato del README, todas las pruebas de Kallpa siguen pasando… y el bot de la liga empieza a reservar Fulbito 2 sin que nadie se entere hasta que dos equipos llegan a la misma cancha. Las pruebas de la semana (hyrum.test.ts) comprueban exactamente eso: con la lista ordenada por id, la función frágil devuelve la cancha 2, mientras que una versión que busca por lo que la API sí da, el nombre, sigue devolviendo la 1:

// Busca por lo que la API sí da: el nombre de cada cancha.
export function fulbitoOne(courts: CourtJson[]): number | undefined {
  return courts.find((court) => court.name === 'Fulbito 1')?.id;
}

Hay un usuario de este orden todavía más cercano: la propia página de Kallpa. public/app.js arma la lista desplegable de canchas en el orden en que llegan de la API, y un <select> muestra elegida la primera opción. Por eso, al abrir la página, la cancha elegida es Básquet. Si mañana la API devolviera las canchas por id, la página abriría con Fulbito 1. No es grave, pero es un cambio visible para los vecinos que nadie decidió.

El orden por nombre tiene además una sorpresa propia. SQLite compara el texto byte a byte (su intercalación por omisión, BINARY), no con las reglas del alfabeto español. En UTF-8, la Á se codifica con bytes mayores que los de cualquier letra sin tilde, así que una cancha nueva llamada “Área techada” no va primero, como en un diccionario, sino al final (courts-order.ts):

$ node courts-order.ts
Hoy:                    4 Básquet | 1 Fulbito 1 | 2 Fulbito 2 | 3 Vóley
Con una cancha nueva:   4 Básquet | 1 Fulbito 1 | 2 Fulbito 2 | 3 Vóley | 5 Área techada

Es otro comportamiento observable que nadie diseñó: “las canchas vienen en orden alfabético” es casi cierto, y el “casi” es justo donde alguien se va a equivocar.

Un segundo ejemplo: códigos y mensajes de error

Kallpa sí prometió algo explícito sobre sus errores. El README dice que todas las respuestas de error tienen la misma forma, “con un código estable que los clientes HTTP pueden comparar sin leer el mensaje”. Por ejemplo, al intentar reservar para una fecha que ya pasó:

$ curl -s -X POST localhost:3000/api/bookings -H "content-type: application/json" \
    -d '{"courtId":1,"memberId":2,"date":"2026-11-01","startHour":7,"hours":1,"teamName":"Real Barranco"}' | jq
{
  "error": {
    "code": "IN_THE_PAST",
    "message": "Esa hora ya pasó."
  }
}

El code es para los programas; el message es para las personas (la página lo muestra tal cual). Esa separación es una forma de defenderse de la ley de Hyrum: el equipo de Kallpa le da a quien llama a la API algo estable para comparar, y se reserva la libertad de mejorar la redacción de los mensajes. Pero la ley dice que el contrato no basta. Si un script de la administración hace esto:

// Compara el texto del mensaje, que está escrito para personas.
export function isPastHourFragile(body: ErrorJson): boolean {
  return body.error.message === 'Esa hora ya pasó.';
}

se rompe el día en que alguien mejora el mensaje. Y eso es exactamente lo que van a hacer en el laboratorio de esta semana: cambiar el texto de ese mensaje en dos ramas distintas. Al final del laboratorio, el mensaje queda como 'Esa hora ya empezó: elijan una hora libre.'; las pruebas de la semana comprueban que con ese mensaje la versión frágil deja de reconocer el error y la que compara el code sigue funcionando. Las pruebas de Kallpa, por su parte, comparan el código y no el mensaje, así que siguen pasando después del cambio (también está comprobado en team-git.test.ts).

Qué puede hacer quien mantiene una API

La ley de Hyrum no se puede eliminar, pero se puede administrar. Algunas herramientas, de las que vamos a volver a hablar en la semana 6 (APIs):

• Decir qué se promete y qué no. Un contrato claro no impide que alguien dependa de lo no prometido, pero deja claro de quién es la culpa cuando se rompe, y da libertad para cambiar. El README de Kallpa podría decir: “el orden de las canchas no está garantizado”.
• Prometerlo de verdad, si es útil. Si muchos clientes HTTP necesitan las canchas ordenadas por nombre, el equipo puede decidir que eso es parte del contrato, escribirlo y agregar una prueba que lo verifique. Desde ese momento ya no es un accidente.
• Dar algo estable para las máquinas, como hace Kallpa con code frente a message.
• Hacer que lo no prometido no sea estable, como los lenguajes que cambian el orden de sus tablas hash entre ejecuciones. Es una medida fuerte y tiene su propio costo.
• Medir antes de cambiar. Cuando hay que cambiar un comportamiento observable, averiguar quién depende de él (buscar en el código de los clientes HTTP, revisar logs) y avisar con tiempo.

Error común. Pensar “si no está en la documentación, lo puedo cambiar sin problema”. La documentación decide quién tiene la razón cuando algo se rompe; no decide si se rompe. Antes de cambiar un comportamiento observable, pregúntense quién podría estar usándolo.

Con IA. Una herramienta de IA que lee el código de Kallpa para escribir un cliente HTTP ve el ORDER BY name y la respuesta de ejemplo, igual que una persona, y puede escribir sin dudarlo un courts[1]. Para la ley de Hyrum, un agente es un usuario muy aplicado: depende de todo lo que observa, salvo que se le diga qué es contrato y qué no. Cuando revisen código generado que usa una API, pregunten lo mismo que con código de una persona: ¿esto depende de algo que la API promete o de algo que hoy simplemente hace?

“Funciona” frente a “es correcto”

SWEG usa el ejemplo del orden hash para distinguir dos niveles. Para un programa de corta vida, depender del orden de una tabla hash no causa problemas técnicos: “funciona”. Para un proyecto de ingeniería de software, esa dependencia es un riesgo: tarde o temprano algo va a hacer valioso cambiar ese orden (eficiencia, seguridad, o simplemente poder evolucionar la estructura de datos). El código que depende de detalles frágiles y no publicados de sus dependencias suele describirse como ingenioso o como un hack; el que sigue las buenas prácticas y planifica el futuro, como limpio y mantenible. Los dos tienen su lugar, y cuál elegir depende de la vida esperada del código. El capítulo lo resume en una frase que vale la pena recordar: es programación si “ingenioso” es un elogio, y es ingeniería de software si “ingenioso” es una acusación.

Escala y políticas

Lo que se hace muchas veces tiene que escalar

La segunda gran idea del capítulo es la escala. No solo la del software (que tiene que soportar más usuarios, más datos, más carga), sino la de la organización que lo hace. SWEG lo plantea como una pregunta: cuando la organización crece y sus proyectos se expanden, ¿se vuelve más eficiente para producir software, o sus políticas de control de versiones y de pruebas le cuestan proporcionalmente más?

La regla que propone: todo lo que la organización tiene que hacer repetidamente debería escalar bien en esfuerzo humano, es decir, crecer de forma lineal o mejor con el tamaño de la organización y del código. Para detectar una política que no escala, imaginen el trabajo que le impone a una sola persona y multipliquen la organización por 10 o por 100. Si esa persona tiene 10 veces más trabajo, o si su trabajo crece con el tamaño del código, y no hay nada que lo automatice, hay un problema de escala.

Estos problemas además crecen despacio. Preguntas como “¿cuánto tarda un build completo?” o “¿cuánto cuesta actualizar a una versión nueva del lenguaje?” casi nadie las mide, y cambian poco a poco. SWEG las compara con la rana que se cocina lentamente: el problema empeora sin que haya nunca un momento de crisis que obligue a mirarlo.

Políticas que no escalan

El primer ejemplo del libro es la deprecación. Se escribe un componente nuevo, se decide que todos tienen que dejar de usar el viejo, y quienes dirigen el proyecto anuncian: “el 15 de agosto borramos el componente viejo; asegúrense de haber migrado”. En una organización pequeña puede funcionar. Cuando el grafo de dependencias crece, cada equipo depende de más componentes, cada rotura afecta a más gente y el trabajo de migrar se multiplica por el número de equipos.

En 2012, cuenta SWEG, Google adoptó la regla contraria, que llaman Churn Rule: los equipos de infraestructura tienen que hacer ellos mismos el trabajo de mover a sus usuarios internos a las versiones nuevas, o hacer la actualización en el lugar y de forma compatible. Es la política que la guía de la semana resume como que lo haga quien cambia la dependencia, en vez de que cada equipo actualice su copia a mano. Escala mejor por dos razones: los proyectos que dependen del componente ya no gastan cada vez más esfuerzo solo para mantenerse al día, y un grupo de especialistas que aprende el problema a fondo una vez y lo aplica en todas partes lo hace mejor que cien equipos que lo aprenden a medias, lo resuelven y olvidan lo aprendido.

El segundo ejemplo son las ramas de desarrollo de larga vida. Una organización nota que hacer merge de funcionalidades grandes desestabiliza el producto y concluye “hay que hacer merge menos seguido”; cada equipo o cada funcionalidad termina con su propia rama, y cada vez que una llega a la rama principal, las demás tienen que sincronizarse y volver a probar. Con 5 o 10 ramas se puede manejar; con más, el costo de coordinar crece sin límite. Vamos a volver a este ejemplo al final del capítulo, en el laboratorio de Git.

Políticas que escalan

La política favorita del capítulo protege a los equipos de infraestructura: si un producto sufre una caída u otro problema por un cambio de infraestructura, pero el problema no lo detectaron las pruebas del sistema de integración continua, la culpa no es del cambio de infraestructura. En Google la llaman Beyoncé Rule, por la canción: “if you liked it, you should have put a CI test on it” (si te gustaba, le hubieras puesto una prueba en CI). Desde el punto de vista de la escala, significa que las pruebas especiales que no corren en el sistema común de integración continua no cuentan. Sin esa regla, quien cambia la infraestructura tendría que buscar a cada equipo afectado y preguntarle cómo correr sus pruebas; con cien personas se puede, con decenas de miles, no.

Fíjense en la conexión con la ley de Hyrum: la Beyoncé Rule es una manera de decidir qué comportamientos observables cuentan como contrato. Si un comportamiento importa, alguien escribe una prueba que lo verifica, y desde ese momento quien cambia el sistema se entera si lo rompe.

La otra política que escala, según el capítulo, es compartir el conocimiento: foros comunes de preguntas y respuestas, personas expertas dispuestas a ayudar. Un experto amable en un lenguaje, en una organización con cien personas que lo usan, pronto produce cien personas que lo escriben mejor.

El ejemplo del compilador

El capítulo cuenta la actualización de compilador “más recordada” de la historia de Google, en 2006. La empresa tenía entonces varios miles de ingenieros y llevaba unos cinco años sin cambiar de compilador: casi nadie tenía experiencia con una actualización así, y casi todo el código solo se había compilado con una versión. Fue una tarea larga y dolorosa, hecha en buena parte por voluntarios. Muchos problemas de la ley de Hyrum se habían ido acumulando en el código y lo ataban a esa versión del compilador. Y no había todavía Beyoncé Rule ni un sistema de integración continua extendido, así que era difícil saber de antemano el impacto del cambio.

Lo que el libro destaca no es la historia en sí, que muchas empresas pueden contar parecida, sino lo que vino después: reconocer que la tarea había sido dolorosa y cambiar la tecnología y la organización para que la siguiente no lo fuera, con automatización, consistencia y especialistas. Hoy, dice SWEG, para algunos lenguajes actualizan el compilador cada una o dos semanas. La lección: cuanto más seguido se cambia la infraestructura, más fácil se vuelve cambiarla. El código que ya pasó por varias actualizaciones deja de depender de los detalles de una implementación y depende de lo que de verdad garantizan el lenguaje o el sistema operativo.

Shift left: encontrar el error antes

La última idea de esta parte es una observación que el libro repite en muchos capítulos. Imaginen el flujo de trabajo de una funcionalidad como una línea de tiempo que va de izquierda a derecha: idea y diseño, implementación, revisión, pruebas, commit, canary (un despliegue a una parte pequeña del tráfico) y despliegue a producción. Encontrar un problema más a la izquierda en esa línea suele costar menos que encontrarlo más a la derecha. A eso le llaman shifting left, correr la detección hacia la izquierda.

La razón es intuitiva. Si el error lo encuentra quien escribe el código mientras lo escribe, esa persona ya tiene todo el contexto en la cabeza y lo arregla en segundos. Si lo encuentra un revisor, hay que explicarlo, volver al código y pedir otra revisión. Si llega a producción, primero alguien tiene que notar el problema, después alguien tiene que encontrar la causa en un código que ya nadie tiene fresco, y mientras tanto hay usuarios afectados. SWEG no da un número para la diferencia; dice que usualmente reduce los costos, y que ninguna herramienta ni proceso tiene que ser perfecto: se combinan varias capas (análisis estático, revisión, pruebas) para atrapar la mayor cantidad posible de errores a la izquierda.

Un ejemplo pequeño en Kallpa. Para calcular el precio de una reserva, la función quotePriceCents recibe un objeto con sport, date, startHour, hours y plan. Supongan que alguien escribe hour en lugar de hours (shift-left/price-typo.ts):

const cents = quotePriceCents({ sport: 'voley', date: '2026-03-10', startHour: 9, hour: 2, plan: 'regular' });
console.log(`Total: ${cents} céntimos`);

Node.js 26 ejecuta TypeScript quitando los tipos, sin revisarlos. El programa corre sin quejarse:

$ node price-typo.ts
Total: NaN céntimos

NaN (not a number) sale de multiplicar la tarifa por undefined, la propiedad que no existe. Si este código llegara a producción, alguien vería algún día una reserva con precio NaN, o peor, un total del día que no cuadra. El revisor de tipos encuentra el mismo error antes de ejecutar nada, y además sugiere la corrección:

$ tsc -p .
price-typo.ts(7,83): error TS2561: Object literal may only specify known properties, but 'hour' does not exist in type 'PriceQuote'. Did you mean to write 'hours'?

Mejor todavía: un editor configurado con TypeScript lo subraya mientras se escribe, que es lo más a la izquierda que se puede llegar. Por eso Kallpa corre tsc como primer paso de make check, y por eso la integración continua lo correrá en cada pull request (semana 12).

Error común. Pensar que “Node ejecuta TypeScript” significa que Node revisa los tipos. Node 26 solo los quita. Si no corren tsc (o no miran los errores del editor), los tipos son comentarios.

Decisiones con costos

Qué es un costo

La tercera idea del capítulo es que la ingeniería de software consiste en tomar decisiones entre alternativas, y que toda decisión tiene costos. SWEG insiste en que “costo” no significa solo dinero, y enumera seis tipos:

A eso se suman los sesgos: la tendencia a dejar las cosas como están, la aversión a perder. En un campo como el software, dice el libro, el costo que suele limitar no es el dinero sino el de personal: entre un equipo enfocado y uno distraído, es fácil imaginar una diferencia de 10 a 20 % en lo que producen.

El ejemplo más recordado del capítulo es el de los plumones de pizarra. En muchas organizaciones se controlan con cuidado, siempre faltan y la mitad de los que hay están secos. En las oficinas de Google hay armarios abiertos llenos de plumones. Es una decisión explícita: es mucho más importante que una lluvia de ideas no se interrumpa que evitar que alguien se lleve un puñado de plumones que cuestan menos de un dólar.

Decidir con datos, y revisar la decisión

SWEG distingue dos tipos de decisiones:

1. Aquellas en que todas las cantidades se pueden medir o al menos estimar: ¿vale la pena gastar dos semanas de trabajo para ahorrar cierta cantidad de CPU? Para estas no hay excusa: cualquier organización puede llevar la cuenta de lo que cuestan las horas de trabajo y los recursos, y armar una tabla de equivalencias.
2. Aquellas en que algunas cantidades son sutiles o no se saben medir: ¿cuánto cuesta una API mal diseñada? ¿Cuál es el impacto social de una decisión de producto? Para estas no hay respuesta fácil; se decide con experiencia, liderazgo y precedentes, y con más cuidado, no con menos.

En los dos casos, una decisión de ingeniería debería poder justificarse con una de dos razones: lo hacemos porque tenemos que hacerlo (un requisito legal o del cliente) o lo hacemos porque es la mejor opción que vemos hoy, con la evidencia que tenemos. Nunca con “porque lo digo yo”.

Y como la evidencia cambia, las decisiones se revisan. El ejemplo del libro son los builds distribuidos. A mediados de los 2000, en Google se compilaba todo en la computadora de cada ingeniero, cada vez más lento a medida que crecía el código. Construir un sistema de build distribuido costó tiempo de desarrollo, tiempo para cambiar los hábitos de todos y recursos de cómputo, pero el ahorro fue claramente mayor. Lo que no previeron: cuando compilar dejó de doler, nadie tuvo incentivo para cuidar las dependencias innecesarias, y los builds se inflaron. Tuvieron que volver a pensar los objetivos del sistema y financiar herramientas nuevas. Hasta una decisión simple (“gastamos en cómputo para ahorrar tiempo de las personas”) tuvo efectos que nadie vio venir. Para quien decide, eso implica algo que no es técnico: tener el derecho de admitir que se equivocó.

Decisiones con costos en Kallpa

Kallpa es pequeña, pero cada una de sus decisiones de diseño tiene un costo y un beneficio, y su README dice por qué se tomaron:

Ninguna de estas decisiones es “la correcta” en abstracto. Para una aplicación que maneja reservas en varias zonas horarias, guardar la fecha como texto sería un error. Lo que hace buena una decisión es que se tomó mirando los costos, que está escrita con su porqué y que se puede revisar si cambian las condiciones. En la semana 7 van a escribir decisiones así con un formato estándar, los ADR.

Error común. Medir un proyecto de software por cuánto código se escribió. Cada línea es algo que hay que leer, probar, revisar y mantener durante toda la vida del proyecto. Si dos soluciones resuelven lo mismo, la más corta suele ser mejor. Una nota del capítulo lo pone en números: si el número de líneas crece de forma más o menos constante con el trabajo de las personas, cualquier tarea cuyo costo crece con las líneas de código es una tarea que no escala.

Idea clave. La sesión en tres frases. Tiempo: pregunten cuánto va a vivir el código y si el proyecto es capaz de cambiar. Escala: lo que se hace muchas veces tiene que costar lo mismo o menos cuando el equipo y el código crecen. Decisiones: se toman con evidencia, mirando todos los costos, y se revisan cuando la evidencia cambia.

La IA en el ciclo de desarrollo

Hasta hace pocos años, un curso de ingeniería de software podía suponer que todo el código lo escribían personas. Ya no. Las herramientas de IA que escriben código son parte del trabajo diario de muchos equipos, y van a estar en el de ustedes. Este curso no las trata como un atajo ni como un tabú, sino como parte del tema: qué hacen, qué no hacen, cómo se comprueba lo que producen y quién responde por ello. La pregunta de la Sesión A (¿cómo se mantiene un código durante años, con muchas personas?) no cambia porque una parte del código la escriba una herramienta. Se vuelve más urgente.

Qué es una herramienta de IA para programar

En el centro de todas estas herramientas hay un modelo de lenguaje (LLM, por large language model): un programa entrenado con enormes cantidades de texto, incluido mucho código, para predecir cómo sigue un texto. Se le da un texto de entrada, el prompt, y produce una continuación probable, pedazo a pedazo. Todo lo que el modelo “sabe” de su proyecto es lo que está en ese prompt: la parte de la conversación, los archivos y los resultados de comandos que caben en su context window, el tamaño máximo de texto que puede tener en cuenta a la vez.

Sobre ese modelo se construyen herramientas de tres tipos, según cuánto pueden hacer por su cuenta:

La diferencia importante es la última columna. Un agente con acceso a la terminal puede correr las pruebas, ver que fallan y corregir el código hasta que pasen, todo sin que una persona intervenga. Eso lo hace mucho más útil y también más peligroso: puede hacer muchos cambios en poco tiempo, y puede seguir instrucciones que encontró en lo que leyó.

Idea clave. Un modelo de lenguaje produce el texto más probable dado su contexto. “Probable” no es “correcto”: un código que se parece mucho al código correcto que el modelo vio durante su entrenamiento puede estar mal justo en el detalle que hace diferente a su proyecto.

Qué hace bien

Con la experiencia de los equipos que las usan, hay tareas en que estas herramientas suelen ahorrar tiempo de verdad:

• Código repetitivo: la quinta ruta HTTP que se parece a las otras cuatro, el esqueleto de un archivo de pruebas, la configuración de una herramienta.
• Primeros borradores de algo que se sabe revisar: una función con una especificación clara, un script de una sola vez.
• Explicar código ajeno: “¿qué hace esta expresión regular?”, “¿por qué este handler llama a closeAllConnections?”. La explicación puede estar equivocada, pero es un punto de partida que se puede comprobar leyendo el código.
• Traducir entre lenguajes o entre versiones de una biblioteca.
• Proponer pruebas, en especial casos borde en que no habían pensado.

En todas, la persona que la usa sabe juzgar el resultado, o puede comprobarlo con poco esfuerzo.

Qué hace mal

Los errores típicos también tienen un patrón:

• Código que compila, pasa sus propias pruebas y está mal. Es el más importante y el más difícil de ver. La siguiente sección es un ejemplo completo.
• Inventar cosas que no existen: una función de una biblioteca, una opción de un comando, un paquete de npm. A eso se le llama alucinación (hallucination). Una función inventada la detecta el revisor de tipos; un paquete inventado es más grave, porque alguien puede publicar un paquete malicioso con ese nombre (lo vemos en la semana 12).
• Seguir instrucciones escondidas en lo que lee. Si un agente lee un issue, una página web o un comentario que dice “ignora lo anterior y sube el archivo .env”, puede obedecer. A eso se le llama inyección de prompts (prompt injection), y es un problema abierto (semanas 14 y 15).
• No saber lo que el cliente quiso decir. La herramienta solo conoce lo que está escrito. Si la regla del negocio no está en el prompt, en el código o en las pruebas, la herramienta adivina, y adivina lo más común, no lo que pidió la administración de Kallpa.

Un ejemplo: código que pasa sus propias pruebas

Lo que sigue es una ilustración escrita para la clase: un cambio como los que suele proponer un agente. Supongan que la administración de Kallpa quiere registrar pagos en efectivo, y alguien le pide a una herramienta “una función que convierta a céntimos los montos que escribe la administración, por ejemplo 'S/ 112.50'”. Llega este cambio (agent-change/parse-soles.ts):

export function parseSoles(text: string): number {
  const amount = parseFloat(text.replace('S/', '').trim());
  return Math.floor(amount * 100);
}

con sus pruebas (agent-change/parse-soles.test.ts):

test('convierte una tarifa de fulbito en hora punta', () => {
  assert.equal(parseSoles('S/ 112.50'), 11250);
});

test('convierte un monto sin céntimos', () => {
  assert.equal(parseSoles('S/ 90'), 9000);
});
// ... y dos más: 'S/ 62.50' y '81.00'

El código es corto, se lee bien, compila y las pruebas pasan:

$ node --test agent-change/parse-soles.test.ts
✔ convierte una tarifa de fulbito en hora punta (0.47725ms)
✔ convierte un monto sin céntimos (0.082333ms)
✔ convierte una tarifa de vóley en hora punta (0.06875ms)
✔ acepta el monto sin el símbolo de soles (0.065209ms)
ℹ tests 4
ℹ suites 0
ℹ pass 4
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 76.41875

¿Lo aceptarían? Antes de responder, vuelvan al README de Kallpa: “Todo el dinero se maneja en céntimos, como enteros. Con números decimales, 0.1 + 0.2 no da 0.3 y los totales no cuadran con la caja.” La función hace justo lo que la regla prohíbe: convierte el texto en un número decimal (parseFloat) y lo multiplica. En la representación binaria de los números de JavaScript, 0.29 no existe exactamente; lo más cercano es un poquito menos, y 0.29 * 100 da 28.999999999999996. Math.floor lo baja a 28.

Las cuatro pruebas no lo ven porque usan montos (112.50, 90, 62.50, 81) que sí se representan exactamente en binario. No es mala suerte: las pruebas se escribieron mirando la implementación, con los ejemplos que se le ocurren a quien piensa que la implementación está bien.

Una prueba que sale de la regla, y no de la implementación, lo encuentra enseguida. La regla de Kallpa da una propiedad natural: todo monto que Kallpa muestra con formatSoles (11250 se muestra como 'S/ 112.50') tiene que volver a leerse igual. La prueba agent-change/roundtrip.check.ts la revisa para todos los montos de S/ 0.00 a S/ 1000.00:

$ node --test agent-change/roundtrip.check.ts
✖ todo monto que muestra Kallpa se vuelve a leer igual (16.208208ms)
ℹ tests 1
ℹ suites 0
ℹ pass 0
ℹ fail 1
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 96.228042

✖ failing tests:

test at agent-change/roundtrip.check.ts:11:1
✖ todo monto que muestra Kallpa se vuelve a leer igual (16.208208ms)
  AssertionError [ERR_ASSERTION]: 4586 montos no vuelven: 'S/ 0.29' -> 28, 'S/ 0.57' -> 56, 'S/ 0.58' -> 57...
  
  4586 !== 0
  ...

De 100 001 montos, 4586 se leen con un céntimo de menos. En una caja que registra cientos de pagos al mes, la diferencia aparece rápido, y nadie sabe de dónde sale.

La versión corregida (agent-change/parse-soles-fixed.ts) lee los soles y los céntimos como dos enteros, sin pasar nunca por un decimal, y de paso rechaza lo que no tiene forma de monto (devuelve null en lugar de NaN):

const AMOUNT = /^(?:S\/ ?)?(\d{1,7})(?:\.(\d{2}))?$/;

export function parseSoles(text: string): number | null {
  const match = AMOUNT.exec(text.trim());
  if (match === null) return null;
  const soles = Number(match[1]);
  const cents = match[2] === undefined ? 0 : Number(match[2]);
  return soles * 100 + cents;
}

Pasa los cuatro ejemplos del cambio original y la prueba de ida y vuelta para los 100 001 montos (agent-change.test.ts). Cambiar Math.floor por Math.round también haría pasar la prueba en ese rango, pero seguiría razonando con decimales sobre algo que la regla dice que son enteros, y seguiría aceptando textos como 'noventa' (que daría NaN).

Error común. Aceptar código generado porque “pasa las pruebas” cuando las pruebas también las generó la herramienta. Unas pruebas que nadie leyó no verifican nada: comprueban que el código hace lo que el código hace. Lean las pruebas antes que el código, y pregúntense de dónde salió cada valor esperado. Si salió de la regla del negocio, la prueba verifica algo; si salió de ejecutar el código, no.

Fíjense en lo que hizo falta para encontrar el error: conocer la regla del negocio (está en el README), saber por qué existe (los decimales binarios) y escribir una prueba que la exprese. Nada de eso lo hace la herramienta por ustedes. Las semanas 9 y 10 tratan justamente de cómo escribir pruebas que verifican, incluidas las basadas en propiedades como la de ida y vuelta.

Evidencia, no anécdotas

Es fácil encontrar opiniones fuertes sobre cuánto ayudan estas herramientas, en las dos direcciones. Casi todas son anécdotas: “a mí me hizo el doble de rápido”, “a mi equipo le llenó el código de errores”. Una anécdota dice algo de una persona en una situación; no dice qué va a pasar en la de ustedes. Para eso hacen falta mediciones, y saber leer qué midió cada una.

El estudio de METR (2025)

METR, una organización sin fines de lucro que estudia las capacidades de los sistemas de IA, hizo en la primera mitad de 2025 un experimento controlado aleatorio (RCT, randomized controlled trial) con desarrolladores reales:

• Quiénes. 16 desarrolladores con experiencia, de repositorios de código abierto grandes (en promedio, más de 22 000 estrellas y más de un millón de líneas), en los que llevaban años contribuyendo.
• Qué tareas. Cada desarrollador propuso issues reales de su propio repositorio: bugs, funcionalidades, refactorings que igual iba a hacer. En total, 246 issues, de unas dos horas en promedio.
• El experimento. Cada issue se asignó al azar a una de dos condiciones: con IA permitida o sin IA. Con IA podían usar las herramientas que quisieran (sobre todo un editor con IA y los modelos de frontera de ese momento). Grabaron su pantalla y reportaron cuánto tiempo les tomó cada issue.
• Lo que se midió. Con IA, los desarrolladores tardaron 19 % más. Antes de empezar, esperaban que la IA los hiciera 24 % más rápidos. Después de terminar, todavía creían que los había hecho 20 % más rápidos.

El resultado sorprendió, pero la parte más útil para nosotros es la diferencia entre lo que los desarrolladores creían y lo que se midió. Personas con experiencia, trabajando en su propio código, estimaron mal el efecto de la herramienta, y en la dirección contraria.

METR fue cuidadosa en decir qué no muestra su estudio. No es evidencia de que la IA no acelere a la mayoría de los desarrolladores (16 personas expertas en repositorios grandes y maduros no representan a todos), ni de que no acelere en otros dominios, ni de que no vaya a acelerar en el futuro cercano, ni de que no haya formas mejores de usar las herramientas de ese momento. Analizaron 20 posibles explicaciones de la demora y encontraron evidencia de que cinco probablemente contribuyen; los detalles están en el artículo completo.

La actualización de 2026

La página del estudio tiene hoy un aviso: los resultados están desactualizados. En febrero de 2026, METR publicó una nota sobre un segundo experimento, iniciado en agosto de 2025 con herramientas más nuevas y más personas: 57 desarrolladores (10 del estudio original y 47 nuevos, de proyectos más variados), más de 800 tareas. Lo que dice esa nota:

• Para el estudio original, el intervalo de confianza del efecto iba de +2 % a +39 % en el tiempo (el +19 % era la estimación central).
• En el segundo experimento, para los desarrolladores que repetían, el cambio estimado en el tiempo fue de −18 % (más rápidos), con un intervalo de −38 % a +9 %; para los nuevos, de −4 %, con un intervalo de −15 % a +9 %. Los dos intervalos incluyen el cero.
• METR considera que esos datos son una señal poco confiable. Muchos desarrolladores ya no querían trabajar sin IA, ni siquiera pagados: no se sumaron al estudio, o no propusieron las tareas en que más esperaban que la IA los ayudara (entre 30 % y 50 % dijeron que hacían eso). El estudio pierde justo a quienes más se benefician, así que su estimación probablemente se queda corta. METR cree, por lo que le contaron los participantes, que hoy la aceleración es probablemente mayor que en 2025, pero dice que sus datos son evidencia muy débil de cuánto mayor, y está cambiando el diseño del estudio.

Lean esto con cuidado, porque es fácil sacar la conclusión equivocada en las dos direcciones. Los números de 2025 ya no describen las herramientas actuales; usarlos para decir “la IA te hace más lento” es un error. Pero los de 2026 tampoco miden bien la aceleración actual, según los propios autores. La lección que sigue vigente es la del primer estudio: la sensación de productividad no es una medición. Si quieren saber si una herramienta los hace más rápidos en su proyecto, no basta con preguntarse si se sienten más rápidos.

El reporte de DORA (2025)

DORA es un programa de investigación, hoy de Google Cloud, que estudia hace años qué distingue a los equipos de software que entregan bien. Su reporte de 2025, State of AI-assisted Software Development, se basa en una encuesta a profesionales del software. Su conclusión principal es que el papel de la IA es el de un amplificador: magnifica las fortalezas y las debilidades que la organización ya tiene. Un equipo con buenas pruebas, revisión y entrega continua aprovecha la IA; uno sin esas prácticas produce más rápido lo mismo que ya producía mal. Según el reporte, los mayores beneficios no vienen de las herramientas en sí sino de cuidar el sistema de la organización alrededor de ellas.

Como es una encuesta, el reporte describe lo que los participantes reportan y las asociaciones entre sus respuestas; no es un experimento como el de METR, y no permite concluir que una cosa causa la otra. Sirve para saber cómo trabaja la industria y qué hipótesis vale la pena tomar en serio. La noticia de CMU de la siguiente sección cita otro dato del mismo reporte: el 90 % de quienes respondieron la encuesta había adoptado herramientas de IA en su trabajo.

Un curso donde nadie escribe código

La otra lectura de la sesión es una noticia de octubre de 2025 sobre un curso experimental de Carnegie Mellon, AI Tools for Software Development. Sus profesores, Andrew Begel y Austin Henley, les dijeron a los estudiantes que no iban a escribir código a mano: todo lo escribe un modelo de lenguaje, y si el código está mal, tienen que poder leerlo y explicarle al modelo cómo arreglarlo. El primer día, la clase hizo en 13 minutos algo parecido a Instagram.

Begel define el vibe coding como “programar con la esperanza de que el resultado funcione perfecto sin probarlo”. Lo interesante del curso es que no se queda ahí: el objetivo es que los estudiantes apliquen una mentalidad de ingeniería de software para que las herramientas de IA sean confiables. El proyecto final de uno de los grupos, cuenta la noticia, va a tardar mucho más de 13 minutos, porque además de pedirle código al modelo están usando los procesos de desarrollo que aprendieron.

Es una noticia, no un estudio: se escribió a mitad del semestre y no reporta resultados. Su valor es mostrar cómo una universidad está replanteando lo que se enseña. La idea de fondo es la misma de este curso: la parte difícil nunca fue teclear el código, sino saber qué construir y saber si lo construido está bien.

Cómo leer un estudio sobre IA y productividad

Ante cualquier número sobre herramientas de IA (en una noticia, en una charla, en un tuit), hagan estas preguntas:

1. ¿Qué se midió? ¿Tiempo para terminar una tarea, cantidad de código, cantidad de pull requests, satisfacción, o la opinión de los participantes sobre todo eso? No son lo mismo.
2. ¿Cómo? ¿Experimento con asignación al azar, observación de datos reales, o encuesta? Solo el primero permite hablar de causas con confianza, y tiene sus propios límites.
3. ¿A quiénes, con qué tareas? Expertos en su propio código, estudiantes con ejercicios de un día, equipos de una empresa. El resultado vale para situaciones parecidas.
4. ¿Cuándo, con qué herramientas? En este tema, un estudio de hace un año puede describir herramientas que ya no existen.
5. ¿Qué dicen los propios autores que el estudio no muestra?

La responsabilidad no se delega

Hay algo que ninguna herramienta cambia: quien hace commit responde por el código. Si un cambio rompe la caja de Kallpa, a la administración no le importa si lo escribió una persona o una herramienta; le importa que el equipo lo dejó pasar. Lo mismo vale para su proyecto con su cliente real y para cualquier trabajo que tengan después.

De ahí sale una consecuencia que puede parecer paradójica: con herramientas de IA, las prácticas de este curso importan más, no menos. Si producir código se vuelve barato, lo caro es saber si ese código está bien. Para eso están las especificaciones claras (semanas 3 y 4), las pruebas que de verdad verifican (9 y 10), la revisión de código (11) y la integración continua (12). El reporte de DORA dice lo mismo desde otro ángulo: la IA amplifica lo que el equipo ya tiene. Si el equipo no tiene cómo verificar, la IA amplifica eso.

Con IA. Antes de hacer commit de algo que produjo una herramienta, tienen que poder responder cuatro preguntas: ¿qué hace este código, línea por línea? ¿Contra qué regla lo comprobé (no contra qué prueba de la misma herramienta)? ¿Qué caso borde probé yo? ¿Lo podría explicar en la defensa oral sin mirar la conversación con la herramienta? Si alguna respuesta es “no”, el código no está listo.

La política del curso

La política de IA del curso, en concreto:

• Se permiten herramientas de IA en el proyecto y en los laboratorios. Algunas semanas enseñan a usarlas (la 4, la 10, la 14).
• Se registra su uso. Cada equipo lleva un registro de uso de IA: qué se pidió, a qué herramienta, qué se aceptó, qué se rechazó y por qué.
• Se responde por todo. En la defensa oral se pregunta por cualquier parte del producto, como si la hubieran escrito a mano.
• Los exámenes se rinden sin herramientas de IA.

El programa del curso tiene la tabla completa, herramienta por herramienta: el compilador, la documentación, el autocompletado, los linters y la IA generativa, con lo que se permite en el proyecto y en los exámenes.

En el proyecto, el registro vive en docs/registro-ia.md desde P1, con una tabla de cinco columnas: Fecha, Herramienta, Qué se pidió, Qué se aceptó y Qué se rechazó y por qué (las reglas del proyecto lo detallan). Una entrada no es la conversación completa con la herramienta; es un resumen de lo que importa para entender y defender lo entregado. Con el ejemplo de esta sesión, una fila podría decir esto:

Fíjense en la última celda: el registro no es un trámite; obliga a decir por qué se rechazó algo, y la mejor razón es una verificación. Eso es justamente lo que nadie hace cuando acepta código sin leerlo.

Cuándo se cita. Si un fragmento de lo que entregan (código, un documento, un diagrama) salió casi tal cual de una herramienta, se dice en el registro y, si es un documento, en el propio documento. La regla es la misma que con cualquier otra fuente: lo que no es de ustedes se reconoce.

Git en equipo

El laboratorio de la semana es Git en equipo. Seguramente ya usaron Git para guardar su propio código; aquí lo usamos para lo que de verdad sirve: que varias personas cambien el mismo código al mismo tiempo sin perder el trabajo de nadie, y que quede registro de quién cambió qué y por qué. Es la herramienta más básica de la ingeniería de software como la definimos arriba: tiempo (historia) y escala (muchas personas).

En la industria. SWEG dedica el capítulo 16 al control de versiones. Su recomendación para el uso de sistemas como Git es usarlo en cualquier proyecto más grande que “un proyecto de juguete de una sola persona que nunca se va a actualizar”, y declarar una sola fuente de verdad: una rama de un repositorio donde algo está “hecho” cuando llega ahí. En GitHub, esa rama suele ser main. El mismo capítulo critica las ramas de desarrollo de larga vida (el ejemplo de política que no escala de la Sesión A) y defiende el trunk-based development: cambios chicos a los que se les hace merge seguido con la rama principal, con pruebas e integración continua que la mantienen funcionando. Cita la investigación de DORA, según la cual el trunk-based development es un factor que predice a las organizaciones de alto desempeño.

Git en cinco ideas

1. Un repositorio es una carpeta con su historia completa, guardada en la subcarpeta .git. Cada copia de un repositorio (la de ustedes, la de su compañero, la de GitHub) tiene la historia completa.
2. Un commit es una foto completa del proyecto en un momento, más metadatos: quién lo hizo, cuándo, con qué mensaje, y cuál es el commit (o los commits) padre. Cada commit se identifica por un hash, una cadena de 40 caracteres hexadecimales calculada a partir de todo su contenido; se suele mostrar abreviado (e5ba27c). Si cambia cualquier cosa, cambia el hash.
3. Una rama (branch) es solo un nombre que apunta a un commit. Cuando hacen commit en una rama, el nombre avanza al commit nuevo. Crear una rama no copia archivos: es crear un puntero.
4. HEAD es la rama (o el commit) en que están parados ahora: la que avanza con el próximo commit.
5. Un remoto (remote) es otra copia del repositorio con la que se sincronizan. Por convención el principal se llama origin. git push sube sus commits al remoto; git fetch trae los del remoto sin tocar sus archivos; git pull es, por omisión, fetch seguido de merge.

Se puede ver lo que guarda un commit con git cat-file -p. Este es uno del laboratorio (más abajo verán de dónde sale):

ana$ git cat-file -p HEAD
tree 06ff0c6bc1a05169b294be8637971eb4b570d565
parent e5ba27cec5dc6e56a89ab46e9c78cadb122851b0
parent 2d1b2a97187d6d171839b68bc0463f9c930ff307
author Ana Quispe <ana@uni.example> 1774452600 -0500
committer Ana Quispe <ana@uni.example> 1774452600 -0500

Merge pull request #1 from ana/mensaje-hora-pasada

tree es la foto de los archivos (otro objeto, con su propio hash). Este commit tiene dos padres porque es un merge: une dos líneas de historia. La fecha se guarda en segundos desde 1970 con la zona horaria (-0500, la de Lima).

Commits con mensajes útiles

Un mensaje de commit es documentación para la persona que dentro de un año corra git log o git blame tratando de entender por qué una línea es como es. Esa persona puede ser ustedes. Las convenciones del curso (de la guía de estilo):

• Una línea de resumen de hasta unos 60 caracteres, en imperativo: Agrega validación de horario a las reservas, no agregué ni agregando. Piensen que completa la frase “si se aplica, este commit…”.
• Si hace falta, una línea en blanco y un párrafo con el porqué. El qué ya está en el diff; el porqué no está en ninguna otra parte.
• Un commit, un cambio. Si el mensaje necesita “y” para describir dos cosas sin relación, probablemente eran dos commits.

Ramas y pull requests

El flujo de trabajo con GitHub que vamos a usar todo el semestre es el mismo de casi todos los equipos:

1. Actualizar main y crear una rama con el nombre del cambio (reserva-horario-invalido, no rama-ana ni fix).
2. Hacer el cambio en commits pequeños, con pruebas.
3. Subir la rama (git push -u origin <rama>) y abrir un pull request (PR): una propuesta de hacer merge de esa rama en main, que el equipo puede discutir, revisar y aprobar en GitHub.
4. Otra persona revisa el PR: comenta, sugiere cambios, aprueba.
5. Quien tiene permiso hace el merge. GitHub ofrece tres formas: un commit de merge (la opción por omisión), squash (todos los commits del PR en uno) y rebase. Este capítulo usa la primera.

Un buen pull request es chico (se revisa en minutos, no en horas) y tiene una descripción que responde tres preguntas: qué cambia, por qué y cómo se probó. Si resuelve un issue, la descripción lo enlaza; si incluye una línea como Closes #3, GitHub cierra el issue 3 cuando el PR se hace merge en la rama principal. La revisión de código tiene su propia semana (la 11); por ahora, lo esencial de revisar un PR en GitHub:

• Comentar en una línea: en la pestaña Files changed, el + al lado de una línea abre un comentario sobre esa línea.
• Sugerir un cambio: dentro de un comentario, el botón de sugerencia inserta un bloque ```suggestion con la línea; lo que escriban ahí, la autora lo puede aceptar con un clic.
• Aprobar o pedir cambios: al terminar, Review changes deja elegir Comment, Approve o Request changes.

Al revisar, empiecen por la descripción y las pruebas: ¿el cambio hace lo que dice?, ¿las pruebas verifican la regla o solo que el código corre? Los comentarios son sobre el código, no sobre la persona, y dicen por qué: “este mensaje lo ve un vecino, ¿se entiende sin saber qué es startHour?” es más útil que “cambia esto”.

El laboratorio paso a paso

En el laboratorio van a hacer en parejas, con GitHub de verdad, lo que sigue. Para mostrarlo aquí con salidas reales y sin cuentas de GitHub, el script team-git.sh lo reproduce dentro del contenedor con dos personas inventadas, Ana y Bruno: un repositorio bare (sin carpeta de trabajo, solo la historia) hace de GitHub, y los merges que en GitHub hace el botón Merge pull request se hacen con git merge --no-ff, que es lo que ese botón hace con su opción por omisión. make lo corre y guarda toda la salida en build/team-git.txt. Los nombres, correos y fechas de los commits están fijos en el script, así que los hashes salen siempre iguales.

En cada salida, ana$ o bruno$ indica en la copia de quién se corre el comando.

1. Ana sube su copia de Kallpa y Bruno la clona. Ana convierte su copia de Kallpa en un repositorio, hace el primer commit y lo sube a GitHub:

ana$ git init --quiet
ana$ git add -A
ana$ git commit --quiet -m "Versión inicial de Kallpa"
ana$ git remote add origin /work/code/week-01/build/equipo/github/kallpa.git
ana$ git push --quiet -u origin main

(con --quiet para no mostrar la lista de los cuarenta y tantos archivos). Bruno, que tiene acceso al repositorio, lo clona y mira la historia:

bruno$ git clone --quiet /work/code/week-01/build/equipo/github/kallpa.git kallpa
bruno$ git log --oneline --decorate
e5ba27c (HEAD -> main, origin/main, origin/HEAD) Versión inicial de Kallpa

Un solo commit, y tres nombres que apuntan a él: main (la rama de Bruno, donde está HEAD), origin/main (lo que Bruno sabe de la rama main de GitHub) y origin/HEAD (la rama por omisión de GitHub).

2. Ana: una rama, un cambio, un commit. Ana quiere que el mensaje de “esa hora ya pasó” le diga al vecino qué hacer:

ana$ git switch -c mensaje-hora-pasada
Switched to a new branch 'mensaje-hora-pasada'
ana$ git diff
diff --git a/src/domain/booking.ts b/src/domain/booking.ts
index d58bac2..30dc85a 100644
--- a/src/domain/booking.ts
+++ b/src/domain/booking.ts
@@ -63,7 +63,7 @@ export function checkBookingRules(slot: TimeSlot, now: LimaTime): BookingRuleVio
   }
   const daysAhead = daysBetween(now.date, slot.date);
   if (daysAhead < 0 || (daysAhead === 0 && slot.startHour <= now.hour)) {
-    return { code: 'IN_THE_PAST', message: 'Esa hora ya pasó.' };
+    return { code: 'IN_THE_PAST', message: 'Esa hora ya pasó: elijan una hora libre.' };
   }
   if (daysAhead > BOOKING_WINDOW_DAYS) {
     return {
ana$ git commit -am "Sugiere elegir otra hora cuando la hora ya pasó"
[mensaje-hora-pasada 2d1b2a9] Sugiere elegir otra hora cuando la hora ya pasó
 1 file changed, 1 insertion(+), 1 deletion(-)
ana$ git push -u origin mensaje-hora-pasada
To /work/code/week-01/build/equipo/github/kallpa.git
 * [new branch]      mensaje-hora-pasada -> mensaje-hora-pasada
branch 'mensaje-hora-pasada' set up to track 'origin/mensaje-hora-pasada'.

git switch -c crea la rama y se para en ella. git diff muestra lo que cambió y todavía no está en un commit: la línea con - es la que se va, la de + la que llega, y las demás son contexto. git commit -am hace commit de todos los archivos modificados que Git ya conocía (-a) con el mensaje dado (-m). Con la rama en GitHub, Ana abre el pull request #1.

3. Bruno: otra rama, la misma línea. Al mismo tiempo, Bruno decide que el mensaje no es exacto: la regla de Kallpa prohíbe reservar una hora que ya empezó, no solo una que ya terminó. Cambia la misma línea, en su propia rama:

bruno$ git switch -c mensaje-hora-iniciada
Switched to a new branch 'mensaje-hora-iniciada'
bruno$ git commit -am "Aclara que tampoco se reserva una hora ya empezada"
[mensaje-hora-iniciada 2f01d23] Aclara que tampoco se reserva una hora ya empezada
 1 file changed, 1 insertion(+), 1 deletion(-)
bruno$ git push -u origin mensaje-hora-iniciada
To /work/code/week-01/build/equipo/github/kallpa.git
 * [new branch]      mensaje-hora-iniciada -> mensaje-hora-iniciada
branch 'mensaje-hora-iniciada' set up to track 'origin/mensaje-hora-iniciada'.

y abre el pull request #2. Ninguno de los dos hizo nada mal: dos personas mejoraron el mismo mensaje con buenas razones.

4. Merge del pull request de Ana. Bruno revisa el PR de Ana, lo aprueba, y Ana hace el merge:

ana$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
ana$ git merge --no-ff mensaje-hora-pasada -m "Merge pull request #1 from ana/mensaje-hora-pasada"
Merge made by the 'ort' strategy.
 src/domain/booking.ts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
ana$ git push origin main
To /work/code/week-01/build/equipo/github/kallpa.git
   e5ba27c..9e3f038  main -> main

Como main no había avanzado desde que Ana creó su rama, Git podría haber hecho un fast-forward: mover el nombre main hasta el commit de Ana, sin commit nuevo. --no-ff obliga a crear un commit de merge (el que vimos con git cat-file, con dos padres), que deja en la historia que esos cambios llegaron juntos en un PR. ort es la estrategia de merge por omisión de Git desde la versión 2.34.

5. Bruno trae main a su rama: el conflicto. GitHub ahora marca el PR de Bruno: su rama tiene conflictos con main y hay que resolverlos antes de hacer el merge. Bruno trae lo nuevo de GitHub y mira la historia completa:

bruno$ git fetch origin
From /work/code/week-01/build/equipo/github/kallpa
   e5ba27c..9e3f038  main                -> origin/main
 * [new branch]      mensaje-hora-pasada -> origin/mensaje-hora-pasada
bruno$ git log --oneline --graph --decorate --all
*   9e3f038 (origin/main, origin/HEAD) Merge pull request #1 from ana/mensaje-hora-pasada
|\  
| * 2d1b2a9 (origin/mensaje-hora-pasada) Sugiere elegir otra hora cuando la hora ya pasó
|/  
| * 2f01d23 (HEAD -> mensaje-hora-iniciada, origin/mensaje-hora-iniciada) Aclara que tampoco se reserva una hora ya empezada
|/  
* e5ba27c (main) Versión inicial de Kallpa

Las dos ramas salen del mismo commit, e5ba27c, y cambian la misma línea. Ese commit común es la base del merge. Para hacer el merge, Git compara cada lado con la base: si solo un lado cambió una zona del archivo, toma ese cambio; si los dos cambiaron la misma zona de forma distinta, no puede decidir solo y declara un conflicto de merge:

bruno$ git merge origin/main
Auto-merging src/domain/booking.ts
CONFLICT (content): Merge conflict in src/domain/booking.ts
Automatic merge failed; fix conflicts and then commit the result.
bruno$ git status
On branch mensaje-hora-iniciada
Your branch is up to date with 'origin/mensaje-hora-iniciada'.

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   src/domain/booking.ts

no changes added to commit (use "git add" and/or "git commit -a")

git status dice todo lo necesario: hay un merge a medias, el archivo en conflicto es booking.ts (both modified, modificado por los dos lados), y hay dos salidas: resolver y hacer commit, o abandonar el merge con git merge --abort y volver a como estaba todo antes.

Las marcas de un conflicto

Dentro del archivo, Git dejó las dos versiones de la zona en conflicto, separadas por marcas:

bruno$ sed -n 64,70p src/domain/booking.ts
  const daysAhead = daysBetween(now.date, slot.date);
  if (daysAhead < 0 || (daysAhead === 0 && slot.startHour <= now.hour)) {
<<<<<<< HEAD
    return { code: 'IN_THE_PAST', message: 'No se puede reservar una hora que ya empezó.' };
=======
    return { code: 'IN_THE_PAST', message: 'Esa hora ya pasó: elijan una hora libre.' };
>>>>>>> origin/main

• Entre <<<<<<< HEAD y ======= está la versión de la rama en que están parados (HEAD, la de Bruno).
• Entre ======= y >>>>>>> origin/main está la versión de lo que están trayendo (origin/main, que ya tiene el cambio de Ana).
• Lo que está fuera de las marcas no tuvo conflicto y ya quedó combinado.

Resolver un conflicto no es elegir un lado al azar ni borrar las marcas y dejar las dos líneas. Es decidir qué tiene que decir el código ahora que existen los dos cambios. Aquí, cada uno tenía razón en algo: Ana quería decirle al vecino qué hacer, Bruno quería que el mensaje fuera exacto. Bruno escribe una línea que respeta las dos intenciones, borra las marcas, y marca el archivo como resuelto con git add:

bruno$ sed -n 64,66p src/domain/booking.ts
  const daysAhead = daysBetween(now.date, slot.date);
  if (daysAhead < 0 || (daysAhead === 0 && slot.startHour <= now.hour)) {
    return { code: 'IN_THE_PAST', message: 'Esa hora ya empezó: elijan una hora libre.' };
bruno$ git add src/domain/booking.ts
bruno$ git commit --no-edit
[mensaje-hora-iniciada 86a85f3] Merge remote-tracking branch 'origin/main' into mensaje-hora-iniciada
bruno$ git push origin mensaje-hora-iniciada
To /work/code/week-01/build/equipo/github/kallpa.git
   2f01d23..86a85f3  mensaje-hora-iniciada -> mensaje-hora-iniciada

git commit --no-edit crea el commit de merge con el mensaje que Git propone. En una resolución más delicada que esta, antes del commit corran las pruebas (make check): un merge sin conflictos de texto puede igual romper el programa, y una resolución apurada también. En este caso las pruebas de Kallpa pasan, porque comparan el código IN_THE_PAST y no el mensaje; las de la semana lo comprueban sobre el resultado del script.

Al subir la rama, el PR #2 se actualiza solo y ya no tiene conflictos. Ana lo revisa (el cambio que va a ver es la línea final, comparada con main), lo aprueba y hace el merge. El mensaje es el que GitHub escribe por omisión: el número del PR y la rama, precedida por el owner del repositorio donde está la rama; como las dos ramas están en el repositorio de Ana, también este dice ana/:

ana$ git fetch --quiet origin
ana$ git merge --no-ff origin/mensaje-hora-iniciada -m "Merge pull request #2 from ana/mensaje-hora-iniciada"
Merge made by the 'ort' strategy.
 src/domain/booking.ts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
ana$ git push origin main
To /work/code/week-01/build/equipo/github/kallpa.git
   9e3f038..c5e3591  main -> main

Error común. Resolver el conflicto “aceptando lo mío” o “aceptando lo de ellos” con un botón del editor, sin leer el otro lado. Así se pierde en silencio el trabajo de otra persona. Otro error frecuente es hacer commit con las marcas <<<<<<< todavía en el archivo: búsquenlas antes de hacer commit (git diff --check las detecta), y corran las pruebas.

Con IA. Los editores con IA ofrecen resolver conflictos solos. Pueden ahorrar tiempo en conflictos mecánicos (dos imports agregados en el mismo lugar), pero tienen los mismos riesgos de cualquier código generado: elegir un lado sin entender por qué existía el otro, o dejar las dos versiones juntas. Lean el resultado comparándolo con las dos versiones originales, y corran las pruebas. Si la herramienta resolvió el conflicto, ustedes siguen siendo quienes hacen commit.

Leer git log --graph

El último paso del laboratorio es leer la historia de main y explicar qué muestra:

ana$ git log --oneline --graph --decorate
*   c5e3591 (HEAD -> main, origin/main) Merge pull request #2 from ana/mensaje-hora-iniciada
|\  
| *   86a85f3 (origin/mensaje-hora-iniciada) Merge remote-tracking branch 'origin/main' into mensaje-hora-iniciada
| |\  
| |/  
|/|   
* |   9e3f038 Merge pull request #1 from ana/mensaje-hora-pasada
|\ \  
| * | 2d1b2a9 (origin/mensaje-hora-pasada, mensaje-hora-pasada) Sugiere elegir otra hora cuando la hora ya pasó
|/ /  
| * 2f01d23 Aclara que tampoco se reserva una hora ya empezada
|/  
* e5ba27c Versión inicial de Kallpa

Se lee de arriba (lo más nuevo) hacia abajo (lo más viejo). Cada * es un commit, y las líneas |, / y \ unen cada commit con sus padres. Un * del que salen dos líneas hacia abajo (|\) es un merge. Con eso, la historia se cuenta sola, de abajo hacia arriba:

1. e5ba27c: la versión inicial. Las dos ramas salen de aquí (las dos líneas |/ que llegan a este commit).
2. 2f01d23 (Bruno) y 2d1b2a9 (Ana): los dos cambios, cada uno en su rama, sin saber del otro.
3. 9e3f038: el merge del PR #1. Sus dos padres son e5ba27c y el commit de Ana.
4. 86a85f3: el merge que hizo Bruno para resolver el conflicto. Sus padres son su propio commit y 9e3f038; el cruce |/ y /| que lo rodea es la línea que va de ese merge hasta 9e3f038.
5. c5e3591: el merge del PR #2, donde está main ahora, igual en la copia de Ana y en GitHub (origin/main).

Los nombres entre paréntesis son las ramas que apuntan a cada commit. La rama mensaje-hora-pasada ya no hace falta: GitHub ofrece borrarla después del merge del PR, y conviene hacerlo.

Esta historia es correcta, pero tiene tres commits de merge para dos cambios de una línea. Por eso muchos equipos hacen merge de sus PR con squash, o actualizan la rama con git rebase en lugar de git merge, para tener una historia lineal. Son decisiones con costos (la historia lineal es más fácil de leer; el rebase reescribe commits y hay que saber cuándo no usarlo), y el equipo las toma una vez y las escribe. Para este curso basta el merge.

En el laboratorio

La guía de la semana (weeks/week-01.md) tiene los pasos; aquí, lo que conviene saber para cada uno:

1. Entorno. Instalen Docker y Git siguiendo la guía del laboratorio y abran el contenedor con ./env/run.sh. Configuren user.name y user.email en su computadora, no dentro del contenedor: run.sh monta su ~/.gitconfig en el contenedor en modo de solo lectura. Comprueben las versiones como al comienzo de este capítulo.

2. Su repositorio de Kallpa. Creen su copia como dice el enunciado de P0 (paso 1), y antes de cambiar nada corran make check. Tiene que pasar:

   $ make check
   tsc -p .
   eslint .
   node --test "test/**/*.test.ts"
   ▶ reglas de reserva
     ✔ acepta una reserva válida (0.606584ms)
   ...
   ℹ tests 40
   ℹ suites 6
   ℹ pass 40
   ℹ fail 0
   ℹ cancelled 0
   ℹ skipped 0
   ℹ todo 0
   ℹ duration_ms 159.422375

   Después make start, abran http://localhost:3000 y hagan una reserva.

3. Ramas y conflicto en parejas. Hagan lo mismo que Ana y Bruno, con GitHub de verdad. Para que haya conflicto, los dos tienen que cambiar la misma línea; si cambian líneas distintas del mismo archivo, Git las combina solo. Quien hace el segundo merge trae main a su rama (git fetch origin y git merge origin/main), resuelve, corre make check y sube la rama.

4. Revisión. En el PR de su pareja: un comentario en una línea, una sugerencia de cambio y la aprobación.

5. Historia. git log --oneline --graph en su repositorio. Expliquen cada * y cada merge como en la sección anterior.

6. P0. Lean el enunciado de P0 y calculen qué issue les toca.

Hagan el push y el pull desde la terminal de su computadora, donde tienen sus credenciales de GitHub; el contenedor no las guarda.

El código de la semana y make test

La carpeta code/week-01 tiene los ejemplos de este capítulo y las pruebas que comprueban lo que el capítulo dice de ellos:

Los ejemplos usan la Kallpa del curso directamente desde ../../kallpa, sin modificarla. Dentro del contenedor, desde code/week-01:

$ make test
tsc -p .
eslint .
node --test "*.test.ts"
✔ con decimales, 0.1 + 0.2 no da 0.3 y 0.29 * 100 no da 29 (0.604334ms)
✔ el cambio pasa las pruebas que trae (106.07675ms)
✔ el cambio falla la prueba de ida y vuelta en 4586 montos (119.766084ms)
...
✔ las pruebas de Kallpa siguen pasando: comparan códigos, no mensajes (206.61775ms)
✔ con nombres y fechas fijos, los hashes se repiten en otra corrida (154.805375ms)
ℹ tests 19
ℹ suites 0
ℹ pass 19
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 641.195375

make corre team-git.sh y deja en build/equipo los tres repositorios (el de GitHub y las copias de Ana y Bruno), para que puedan entrar y correr sus propios git log; la salida completa queda en build/team-git.txt. make clean borra build/.

shift-left/price-typo.ts tiene un error de tipos a propósito, así que no está incluido en el tsconfig.json de la carpeta: lo revisa shift-left.test.ts, que comprueba que tsc lo rechaza. Por la misma razón, agent-change/roundtrip.check.ts no termina en .test.ts: es una prueba que falla, y agent-change.test.ts comprueba que falla como dice el capítulo.

Resumen

• La ingeniería de software es programación integrada en el tiempo: producir código y mantenerlo útil mientras haga falta, en equipo. Se diferencia de programar por el tiempo, la escala y las decisiones con costos. No es mejor ni peor que programar: son dos dominios con prácticas distintas.
• La pregunta que los separa es cuánto va a vivir el código; las respuestas razonables varían en un factor de 100 000.
• Un proyecto es sostenible si es capaz de reaccionar a los cambios que valen la pena durante toda su vida. Capacidad, no obligación.
• Ley de Hyrum: con suficientes usuarios, todo comportamiento observable termina siendo usado por alguien, prometa lo que prometa el contrato. En Kallpa, el orden de las canchas y el texto de los mensajes de error. Se administra con contratos claros, campos estables para las máquinas, pruebas para lo que se promete y cuidado antes de cambiar.
• Lo que se hace muchas veces tiene que escalar en esfuerzo humano. La Churn Rule y la Beyoncé Rule son políticas que escalan; las deprecaciones con fecha y las ramas de desarrollo de larga vida, no.
• Shift left: encontrar un error más temprano suele costar menos. tsc encuentra al escribir lo que Node dejaría pasar como NaN.
• Toda decisión tiene costos (financieros, de recursos, de personal, de transacción, de oportunidad, sociales). Se decide con evidencia, nunca “porque lo digo yo”, y se revisa cuando la evidencia cambia.
• Las herramientas de IA predicen texto probable a partir de su contexto. Hacen bien lo repetitivo y los borradores; hacen mal lo que depende de reglas que no conocen, inventan APIs y paquetes, y pueden seguir instrucciones escondidas.
• Código que pasa sus propias pruebas puede estar mal. Las pruebas tienen que salir de la regla del negocio, no de la implementación.
• La evidencia sobre productividad hay que leerla con cuidado: qué se midió, cómo, a quiénes, cuándo. En METR 2025, los desarrolladores se sintieron más rápidos y midieron más lentos; los datos de 2026 son poco confiables según sus autores. DORA 2025 describe la IA como un amplificador de lo que el equipo ya tiene.
• Quien hace commit responde por el código. Por eso el curso pide un registro de uso de IA y una defensa oral.
• En Git, un commit es una foto con padres y un hash; una rama es un nombre que apunta a un commit. El flujo del curso: rama por cambio, commits con mensajes en imperativo, pull request revisado, merge.
• Un conflicto de merge aparece cuando dos ramas cambian la misma zona desde la misma base. Se resuelve decidiendo qué tiene que decir el código, quitando las marcas, corriendo las pruebas, git add y commit.

Ejercicios

1. Den un ejemplo de código que escribieron en un curso anterior que no necesitaba prácticas de ingeniería de software, y otro, de un sistema que usan en su vida diaria, que sí. Para cada uno, estimen su vida esperada, cuántas personas lo cambian y qué cosas debajo de él van a cambiar.
2. Elijan un comportamiento observable de Kallpa que el README no promete, distinto del orden de las canchas y de los mensajes de error. Escriban un cliente HTTP (unas líneas de TypeScript) que dependa de él, y describan un cambio razonable en Kallpa que lo rompería sin violar el README. ¿Qué podría hacer el equipo de Kallpa para que nadie dependa de eso?
3. En courts-order.ts, agreguen una cancha llamada "losa deportiva" (en minúsculas) además de “Área techada”, y corran el archivo. Antes de correrlo, escriban dónde esperan que aparezca. Expliquen el resultado con lo que dice el capítulo sobre la intercalación BINARY de SQLite.
4. Para cada uno de estos errores en Kallpa, digan en qué punto de la línea de tiempo (escritura, revisión, pruebas, producción) es más probable que se encuentre, y qué práctica lo correría hacia la izquierda: (a) llamar a una función con un argumento de más; (b) un mensaje de error con una falta de ortografía; (c) una regla de precios que la administración explicó mal; (d) un ORDER BY que cambia el orden de las canchas.
5. Clasifiquen cada una de estas políticas de un equipo de 6 personas según si escalaría o no a 60 personas, y propongan una alternativa para las que no: (a) “antes de cada entrega, la líder del equipo prueba a mano todas las pantallas”; (b) “todo cambio entra por un pull request que corre las pruebas automáticamente”; (c) “cuando alguien actualiza una dependencia, avisa por el grupo para que cada uno actualice su parte”.
6. Escojan una de las decisiones de la tabla Decisiones con costos en Kallpa y describan una situación (otro negocio, otro cliente) en que la decisión contraria sería la correcta. ¿Qué cambió en los costos?
7. Para parseSoles: escriban dos pruebas más que el cambio original no traía y que fallen con la versión de agent-change/parse-soles.ts pero pasen con parse-soles-fixed.ts, sin usar la prueba de ida y vuelta. ¿De dónde sacaron los valores esperados?
8. En el estudio de METR de 2025, ¿qué diferencia hubo entre lo que los desarrolladores creían y lo que se midió? Escriban una conclusión que el estudio permite sacar y dos que no permite, citando lo que dice METR. Luego expliquen en una frase por qué los números de la actualización de 2026 no permiten decir que la IA hace hoy un 18 % más rápidos a los desarrolladores.
9. Busquen una afirmación pública sobre productividad con IA (una noticia, un anuncio de una empresa, una publicación en una red social) y respondan sobre ella las cinco preguntas de Cómo leer un estudio sobre IA y productividad. ¿Cuántas pudieron responder con lo que dice la fuente?
10. Una herramienta les genera una función y sus pruebas para el issue de P0 que les tocó, y todas pasan. Escriban qué harían antes de hacer commit, y la entrada del registro de uso de IA correspondiente, con todas las columnas de la tabla del capítulo.
11. Corran make en code/week-01 y entren a build/equipo/bruno/kallpa. Usen git log --oneline --graph --decorate --all y git cat-file -p para encontrar la base del merge que hizo Bruno (pista: git merge-base <commit> <commit>). Comprueben que es el commit que dice el capítulo.
12. Modifiquen team-git.sh para que Ana y Bruno cambien líneas distintas de booking.ts (por ejemplo, Bruno cambia el mensaje de TOO_FAR_AHEAD). Corran make clean && make. ¿Hay conflicto? El script se va a detener en algún paso: ¿en cuál y por qué? Ajusten los pasos que dejan de tener sentido hasta que termine, y digan cómo queda booking.ts en main y qué pruebas de team-git.test.ts fallan ahora. (Trabajen sobre una copia de la carpeta: es solo para experimentar.)