9. La IA en el ciclo de desarrollo

Dónde ayudan las herramientas de IA y dónde no

⏱ Enseñanza: 8 minutos · Ejercicios: 12 minutos

Preguntas

• ¿Cambia el ciclo de desarrollo de paquetes cuando usamos IA?
• ¿En qué partes del ciclo conviene usar herramientas de IA y en cuáles no?
• ¿Qué formas hay de usar un modelo de IA?
• ¿Qué riesgos tiene dejar que un agente trabaje en mi computadora?

Objetivos

• Distinguir tres formas de usar un modelo: chat, cliente y agente.
• Decidir, para cada paso del ciclo, si conviene delegarlo, pedir un borrador o hacerlo a mano.
• Revisar código y tests generados por IA con los criterios que aprendimos en el taller.
• Nombrar los riesgos principales y cómo protegerse.

¿Por qué vemos este tema al final?

Porque primero había que entender el ciclo. Hoy hicimos todo “a mano” a propósito: create_package(), use_r(), load_all(), roxygen2, use_data(), testthat, check(). Ahora que sabés qué hace cada paso, podés decidir cuáles darle a una herramienta de IA y, sobre todo, entender para poder revisar lo que te devuelve.

En un taller, el proceso es el objetivo. En tu trabajo de todos los días, a veces no.

El ciclo clásico no cambia

De acuerdo a Hadley Wickham y Jenny Bryan el flujo de trabajo es el mismo de siempre:

1. Escribir una función en R/.
2. load_all() y probarla en la consola.
3. Crear el archivo de tests con use_test() y escribir tests.
4. test() hasta que pasen.
5. document() para actualizar la documentación.
6. check() al final.
7. Reiniciar R.

Lo que cambia es quién escribe cada parte, y qué te toca hacer a vos.

Qué cambia con la IA

Parte del ciclo	Qué hace bien la IA	Qué te toca a vos
Código	Lo escribe a partir de tu descripción.	Probarlo en la consola con load_all(), para ver cómo se siente usarlo. Entender cada línea.
Tests	A los agentes les encanta escribir tests.	Que sean los necesarios (menos es más), claros y rápidos. Romper el código a propósito para ver que fallan.
Documentación	Un primer borrador.	La documentación es comunicación entre personas: revisala y escribila con tu voz.
check()	Arreglar los problemas que encuentra.	Correrlo siempre. Sigue siendo igual de importante.
Datos	Leer, limpiar y transformar archivos.	Los datos son tu responsabilidad. Un modelo puede inventar un dicho o un significado con total seguridad.

AdvertenciaLo que pedimos en rOpenSci

En rOpenSci pedimos que todo lo generado con IA sea revisado con cuidado por la persona autora antes de que otra persona lo lea, y que siempre se diga cómo se usó la IA. Lo contamos en el blog: Revisión de Software en la era de la IA (Software Review in the Era of AI) (en inglés).

• Nunca le hagas leer a otra persona algo que vos no revisaste. Un README, la respuesta a un issue o la descripción de un pull request son mensajes para personas.
• La comunicación personal la escribís vos, nunca la IA. Si una persona te escribe, te responde una persona.
• Usarla para traducir está bien, sobre todo cuando tenes que comunicarte en un idioma que no es tu lengua nativa.
• Siempre, siempre, que uses IA, decilo. La transparencia da una buena señal.

Tres formas de usar un modelo

El modelo es el que genera las respuestas (Claude, GPT, Gemini, Kimi…). Lo podemos usar de diferentes manera, aqui te presentamos tres formas, de menos a más autonomía:

Forma	Cómo funciona	Ejemplos	Qué ve y qué hace
Chat	Una página web o una aplicación donde conversás con el modelo.	GitHub Copilot en github.com, claude.ai, ChatGPT	Solo ve lo que le pegás o adjuntás. Vos copiás el resultado a tu código.
Cliente	Un programa que conecta el modelo con tus herramientas: tu editor o tu código de R.	Copilot en Positron, RStudio o VS Code; el paquete ellmer desde R	Ve el archivo que tenés abierto, sugiere código mientras escribís, responde preguntas sobre tu proyecto. Vos decidís qué aceptar.
Agente	Un modelo que hace cosas en tu computadora: lee y escribe archivos, corre código de R, ejecuta comandos.	Posit Assistant, Claude Code, Codex, el modo agente de Copilot	Trabaja solo, en un ciclo, hasta terminar la tarea. Vos revisás lo que hizo.

Un angente es un modelo, dentro de un software que le da herramientas y guardarails y que se ejecuta en un ciclo donde usa esas herramientas y restricciones para lograr un objetivo.

• El modelo decide qué herramienta usar.
• El software que lo contiene ejecuta la herramienta y le devuelve el resultado. Este software también aplica las restricciones que le impusimos (por ejemplo que no pueda borrar archivos)
• Se repite hasta que el modelo dice que terminó.

Las herramientas típicas son: buscar en los archivos, leer, escribir, editar, correr código de R, correr comandos de la terminal, preguntarte algo y leer páginas web. Cuanta más autonomía, más importante es revisar.

Riesgos y cómo cuidarte

El peligro principal son las acciones que no se pueden deshacer:

• editar archivos sin Git;
• borrar archivos o tablas sin copia de seguridad;
• mandar un correo o publicar algo;
• revelar un secreto (una contraseña, una clave de API, datos sensibles).

Cómo cuidarte:

• Usá Git siempre. Si el agente rompe algo, volvés atrás. Es la mejor razón para aprender Git.
• Hacé copias de seguridad de lo que no está en Git.
• Mirá lo que hace. Leé los cambios antes de aceptarlos.
• No le pegues secretos ni datos privados a un chat: contraseñas, claves de API, datos personales.

TipConversaciones cortas

Cada mensaje nuevo le manda al modelo toda la conversación anterior. Las conversaciones largas cuestan más (en dinero y en energía) y arrastran confusiones. Empezá conversaciones nuevas seguido: es tan importante como reiniciar tu sesión de R.

Cómo pedir ayuda: corto y preciso

Algunos consejos del taller de Posit para hacer buenas preguntas:

• Ser un poco más específica mejora mucho el resultado. Usá las palabras del tema: load_all(), @export, snapshot test.
• Achicá el alcance: preguntá sobre este paquete, esta función, este error.
• Pedí pruebas: “mostrame en qué parte de la documentación dice eso”.
• Preguntas cortas, respuestas cortas, y de a una. Así vas construyendo tu propia comprensión.

Y no todo es chat: la búsqueda de código de GitHub sigue siendo buenísima. Por ejemplo, user:cran path:data-raw te muestra cómo otros paquetes de CRAN preparan sus datos.

Cuánto delegar: más riesgo, más controles tuyos

Hadley y Jenny proponen ajustar el proceso según cuánto cuesta un error: si se puede deshacer, cuántas personas lo notarían y cuánto te lleva revisarlo. Cuanto más caro sería equivocarse, más puntos de control ponés vos antes y después de que trabaje la IA.

Si un error…	Cómo trabajar	Ejemplo en dichosos
se arregla en un minuto	Pedilo y revisá el resultado.	Arreglar el WARNING de tildes.
lleva un rato arreglar	Pedí un plan primero, corregilo, y después que lo haga.	Agregar dichos_por_tema().
afecta a otras personas	Revisá el plan y el resultado: leé cada cambio, probá con load_all(), corré los tests y check().	Cambiar cómo funciona dicho_al_azar(), que ya usan otras personas.
es difícil de deshacer	Las decisiones de diseño las tomás vos; la IA ayuda a implementar.	Preparar el paquete para CRAN o para la revisión de rOpenSci.

Cuando le pidas un plan, pedí que lo escriba en un archivo Markdown que puedas leer y editar.

Contarle al agente cómo es tu paquete

Si le repetís lo mismo a un agente tres veces (“usá cli para los errores”, “nada de tildes en el código”), conviene escribirlo en un archivo AGENTS.md en la raíz del proyecto. Los agentes lo leen al empezar cada conversación. Existe la función usethis::use_tidy_agents(), que crea uno con las convenciones del tidyverse.

Mantenelo corto: se manda en cada pedido, y lo estás pagando.

Nota¿Y si quiero probar? Con tu cuenta de GitHub, gratis

Si tenés una cuenta personal de GitHub, ya tenés GitHub Copilot Free, sin pagar nada:

• Como chat, en el navegador: entrá a https://github.com/copilot. Le podés preguntar sobre tu código, y si tu paquete está en GitHub, sobre tu repositorio.
• Como cliente, en tu editor: Copilot funciona en Positron, RStudio y VS Code.
• Tiene un límite mensual de uso. Estudiantes, docentes y personas que mantienen proyectos de código abierto pueden pedir acceso gratuito a planes más completos.

Otras opciones, que en general necesitan una suscripción o una clave de API: Posit Assistant en Positron y RStudio, Claude Code, Codex, Mistral.

Para aprender, ninguna es imprescindible: todo lo que vimos hoy funciona sin IA.

Desafío 9.1: ¿Dónde sí y dónde no? 5 minutos, en parejas

Para cada tarea de dichosos, decidí: ¿le darías el trabajo a una herramienta de IA, la usarías solo para un borrador que después revisás, o la harías vos?

1. Elegir el nombre del paquete.
2. Escribir el código de buscar_dicho().
3. Escribir los significados de los dichos de tu país.
4. Escribir los tests de dicho_del_dia().
5. Arreglar el WARNING de caracteres no ASCII.
6. Escribir el README.
7. Responder un issue de otra persona que encontró un error en tu paquete.

Anotá tus respuestas en el documento colaborativo. No hay una sola respuesta correcta: lo interesante es el por qué.

TipUna respuesta posible

1. Vos. La IA no sabe si un nombre es una mala palabra en tu país (pkg_name_check() tampoco), y el nombre es una decisión de diseño.
2. IA, y después vos. Pedile algo específico, probalo en la consola con load_all() y leé cada línea. Si no entendés el código, no lo agregues.
3. Vos. Los datos son tu responsabilidad. Un modelo de lenguaje puede inventar un dicho o un significado con total seguridad, y en @source dice de dónde salieron.
4. IA, con supervisión. A los agentes les encanta escribir tests: tu trabajo es que sean pocos, claros y que de verdad fallen cuando algo se rompe.
5. IA. Es un problema mecánico, con un mensaje de check() claro. Las herramientas de IA son muy buenas arreglando lo que encuentra check().
6. Borrador. La IA puede armar la estructura, pero el README es comunicación entre personas: revisalo, escribilo con tu voz y contá que usaste IA.
7. Vos. Podés usar IA para entender el error o probar un arreglo, pero la respuesta es comunicación personal: la escribís vos. Si la usaste para traducir, está bien, y lo decís. Son pautas que pedimos en rOpenSci.

Desafío 9.2: Revisá lo que escribió la IA 7 minutos

Le pedimos a un asistente de IA: “Agregá a dichosos una función que devuelva los dichos de un tema”. Esto es lo que escribió. Con lo que aprendiste hoy, encontrá al menos cinco problemas.

library(dplyr)

# Esta función recibe un tema y devuelve los dichos de ese tema.
# Primero filtra los datos por tema y después devuelve el resultado.
dichos_por_tema <- function(tema) {
  if (!tema %in% dichos$tema) {
    stop("No hay dichos de ese tema. Probá con otro.")
  }
  dichos %>% filter(tema == tema)
}

Y en tests/testthat/test-dichos_por_tema.R:

test_that("dichos_por_tema() funciona", {
  expect_true(TRUE)
  resultado <- dichos_por_tema("dinero")
  expect_s3_class(resultado, "data.frame")
  expect_equal(nrow(resultado), 6)
  expect_equal(ncol(resultado), 4)
  expect_equal(names(resultado), c("dicho", "significado", "pais", "tema"))
  expect_true(all(resultado$tema == "dinero"))
  expect_error(dichos_por_tema("dinosaurios"))
})

TipSolución

En la función:

1. library(dplyr) en el código del paquete. Nunca. Hay que declarar la dependencia con usethis::use_package("dplyr") y usar dplyr::filter(). O mejor: ¿hace falta dplyr? Con R base alcanza (dichos[dichos$tema == tema, ]) y el paquete tiene una dependencia menos.
2. filter(tema == tema) no filtra nada. Adentro de filter(), los dos tema son la columna, así que la condición siempre es verdadera y devuelve todos los dichos. Es el tipo de error que solo aparece si probás la función en la consola.
3. No tiene documentación de roxygen2 ni @export.
4. “Probá” tiene tilde en el código: check() da un WARNING. Va Prob\u00e1.
5. El error no ayuda: no dice qué tema se pidió ni cuáles existen. Mejor cli::cli_abort() con la lista de temas, como hicimos en dicho_al_azar().
6. Los comentarios explican el qué, no el por qué. Si el código se entiende, sobran.

En el test:

7. expect_true(TRUE) no comprueba nada.
8. expect_equal(nrow(resultado), 6) se rompe cada vez que alguien suma un dicho de dinero. Es un test frágil.
9. Es un solo test gigante. Mejor varios test_that() cortos, cada uno con una descripción de lo que comprueba.
10. Lo bueno: all(resultado$tema == "dinero") sí detecta el error del punto 2… pero solo si alguien corre los tests. Revisar lo que escribe la IA incluye correr los tests y probar en la consola.

Desafío 9.3 (opcional, con GitHub Copilot Free u otro asistente): Pedilo bien para casa

Escribí un pedido corto y preciso para que un asistente agregue dichos_por_tema() a tu paquete. Con tu cuenta de GitHub podés usar el chat de Copilot en https://github.com/copilot. Por ejemplo:

Agregá a dichosos la función dichos_por_tema(tema) en R/dichos_por_tema.R. Usá R base, sin dependencias nuevas. Si el tema no existe, dá un error con cli::cli_abort() que liste los temas disponibles, como en dicho_al_azar(). Documentala con roxygen2 y exportala. Escribí tests cortos en tests/testthat/test-dichos_por_tema.R. Antes de escribir código, mostrame un plan.

Después: leé el plan, pedile el código, copialo a tu paquete, revisá los cambios con Git, probá la función con load_all() y corré devtools::check(). ¿Qué hizo distinto a lo que habrías hecho vos?

Puntos clave

• El ciclo de desarrollo es el mismo con o sin IA: load_all(), test(), document(), check().
• Saber hacerlo “a mano” es lo que te permite revisar lo que hace la IA.
• Delegá lo mecánico (arreglar lo que encuentra check()), revisá el código y los tests, y quedate con las decisiones, los datos y la comunicación con personas.
• Usá Git siempre: es tu botón de deshacer.
• Pedidos cortos y precisos, y conversaciones cortas.
• Como pedimos en rOpenSci: revisá todo antes de que lo lea otra persona, escribí vos tu comunicación personal y siempre decí cuando usaste IA.