{ }  culpa.md #023 · La culpa es tuya, no del modelo ← archivo
El Diario de AlpacaTech
// edition: 023 · sunday, 20 sep read: ~4 min

La culpa es tuya, no del modelo

¿Tú revisas el código que te escribe la IA?

Yo lo sigo haciendo.

(sí, aún no lo hemos quitado xd).

Y aun así estuve a punto de meter en producción código que no servía para nada.

El otro día fui a resolver un ticket de un bug que nos había entrado.

Tengo una skill para ello: coge el ticket, reproduce el fallo, lo arregla, y me da una PR para que revise.

Así que se lo pasé y me fui a hacer cosas.

Volví, lo miré, y estaba perfecto. El caso cubierto y nada raro.

Y cuando estaba a punto de pasar la PR por Slack para que la revisaran mis compañeros y mover la tarea a QA...

me paré.

«Espera. Esto es imposible».

¿Por qué imposible?

Te cuento el bug.

Tenemos un microservicio que se encarga de las notificaciones (Sputnik se llama). Cuando un usuario tiene una sesión de mentoring, ese servicio le manda un correo para avisarle. Y dentro del correo va el enlace de la sesión.

El ticket decía que le estábamos pasando a ese servicio una URL de sesión que no existía, y que por eso petaba.

Eso es lo que Claude arregló (hizo el parámetro anulable vamos).

Pero... es que eso no puede pasar.

O sea, si ese correo se manda es que la sesión se ha generado. Y si el enlace de la sesión no está, es porque la sesión no se ha generado.

O sea, que el fallo que ponía en el ticket no podía existir.

De hecho lo comprobé, y en producción había 0 URLs de sesiones faltantes o inválidas.

Así que me metí yo a leer el ticket.

Y luego se lo empecé a explicar a Claude.

¿Y sabes qué me dijo?

Que tenía razón. Que ahí no había ninguna URL inválida.

(obvio, siempre te da la razón)

Cuando leí el ticket lo vi claro. El problema sí que estaba en ese correo, pero no necesariamente en el enlace de la sesión. El problema era otro parámetro. Uno que, dependiendo del usuario, sí que podía darse el caso de ser null.

Ese era el bug. Y solo cuando lo leí y entendí pudimos arreglarlo de verdad.

Claude lo había resuelto desde el principio. Pero para llegar a nuestro objetivo yo tenía que saber qué pedir.

En ambos casos, la herramienta hizo lo que tenía que hacer, y lo hizo bien.

Y esta es la reflexión que te traigo hoy. Ya no le podemos echar la culpa a la herramienta.

Ya no puede haber un «lenguaje muy complicado« o un framework que »es un desastre". Ahora si queremos montar algo, lo vamos a poder montar, con lo que sea.

El culpable ahora somos nosotros. Sobre todo cuando los modelos no dejan de evolucionar, y ya se revisan e iteran solos.

Quizás no sabíamos qué queríamos. Quizás nunca entendimos el problema. O quizás nos hemos liado al explicárselo.

La cosa es que, probablemente, si algo falla, el problema seamos nosotros.

Ya sea porque tenemos que montar un sistema alrededor mejorando los guardarraíles,

O porque directamente le estamos pidiendo lo que no es.

Algo que... duele.

Porque señalar hacia fuera era bastante cómodo. Pero ahora cada vez nos quedan menos cosas a las que poder señalar.

Piensa en montar un producto que luego no se vende.

Antes tenías donde agarrarte. Que si tardaste demasiado en sacarlo, que si al final no era la versión que tenías en la cabeza.

Ahora lo sacas en una tarde y sale exactamente como lo pensaste.

Pero no se vende igual.

Así que el producto no era el problema. Era la idea de mercado que tú veías buenísima.

Te pasa igual con esa operación que tenías teorizada para ir volando en términos de velocidad, y va lenta.

Puedes revisarle la implementación las veces que quieras. El fallo está antes, en los cálculos que hiciste, y toca rehacerlos.

Y nos toca comernos esto.

Porque Claude, o la IA que tú uses, ha hecho exactamente lo que le pediste lo más rápido que ha podido.

Lo que yo hago para suplir esto es bastante simple.

Mientras Claude se pone a programar el ticket, yo me lo leo. E intento leérmelo bien bien: hasta tener claro qué problema define el ticket, y cuál sería su solución.

Porque el problema que haya entendido Claude puede no ser el que he entendido yo.

Y las dos cosas se ven igual de bien en un diff.

Claro que no soy perfecto. Cuando se me pasa, o cuando quiero ir muy rápido, me acuerdo de la frase de aquel día:

«Espera. Esto es imposible».

Y entonces me voy y reviso detenidamente la PR.

// appendix
$ weekly.log

Tres apuntes de la semana

+
funcionó
Tener equipo cuando vienen mal dadas.
Mi empresa está pasando una época algo convulsa, y una de las pocas cosas que me quedan es el equipo que hemos forjado. Cuando hay incertidumbre y todo parece irse a pique, el equipo es lo que sigue en pie. Por eso los lazos hay que haberlos creado antes, cuando todo iba bien y no hacían falta. Ahora mismo lo estoy agradeciendo muchísimo.
~
aprendí
Mejor tarde que nunca.
Este fin de semana ha sido una locura, y las dos siguientes estoy viajando, así que no me dio tiempo de escribir la newsletter. La he hecho entera hoy domingo, y en vez de mandártela a las nueve de la mañana te llega a las nueve de la noche. Pero mejor tarde que nunca, porque de otro modo no la estarías leyendo. Muchas veces tiramos todo el trabajo solo por ir tarde, y damos por hecho que ya no merece la pena. Si estás leyendo esto, es que sí merecía.
−
me bloqueó
Ver cómo se va un compañero.
Han venido cambios en mi empresa y ha habido que ver marcharse a un compañero. Nunca es bonito, y menos cuando no es culpa suya, sino pura cuestión de números. Nos ha dejado desmoralizados a todos: a final de semana yo apenas produje nada.
$ picks

Te recomiendo

herramienta
Typora
// lo que uso a diario

Typora

typora.io · de pago

Es el editor de texto que uso a diario. Con la IA empecé a trabajar muchísimo en Markdown, y las notas del Mac son terribles para eso, así que me puse a buscar y acabé en Typora. Cuesta dinero, sí, pero lo pagué y lo veo como un lifestyle: en vez de salir un fin de semana o de pegarme una comida fuera un día. Y estoy más contento que nunca. Eso sí, ahora con la IA probablemente te puedas montar tú algo parecido y no te cueste nada.

$ open · typora.io →
video
Shopify ABANDONA React Native: No Cometas el Mismo Error
// nuevo en el canal
title: "Shopify ABANDONA React Native: No Cometas el Mismo Error"
fecha: 17 sep 2026
// de qué va
↳ pruebo nuevo formato de vídeo
↳ te explico por qué tú no eres Shopify
↳ comentamos la noticia que está revolucionando Internet
$ inbox

De la comunidad

L
@lorenzo-xu1qe
▶ youtube · hace 17 horas
«Desde mi perspectiva el problema principal es no darse cuenta que esto es un negocio, programadores a nadie le importa el lenguaje en el que programes y que tan bueno seas programando, acá lo que importa es generar valor para tu empresa, hoy en día el cuello de botella ya no es más programar [...] el error de los programadores es justamente querer trabajar para otro en vez de crear su propio negocio, hoy en día estamos en el mejor momento para esto último ! Saludos»
// reply Lo destaco porque dice muchos hechos por línea. Y más allá de si la programación está muerta o no (de eso ya tengo unos cuantos vídeos), sí creo lo otro: centrarse en puntos tan específicos de tecnología es una pérdida de tiempo, sobre todo si vas a hacer software o quieres trabajar en el mercado de masas. El valor ya no está ahí. Nos toca aportarlo desde otros ángulos, quizá fusionándonos con producto, no lo sé. Pero lo que está claro es que hay que subir la mirada y no dejar que los árboles nos tapen el bosque. Y sí, es muy buen momento para montarte tu propio negocio. Aunque yo, por ejemplo, todavía no lo he conseguido.
// tu turno

«Espera, esto es imposible»

¿Te ha pasado alguna vez? Dale a responder y cuéntamelo.

$ reply --to=newsletter@alpacatech.dev 
↳ asunto: Espera, esto es imposible
// firma
~/alpacatech $
$ subscribe

¿Te ha gustado? Cada domingo escribo una así.

Acabas de leer una edición de El Diario de AlpacaTech. Si quieres recibir la próxima en tu bandeja, apúntate.

// ~4 min de lectura · domingos a las 09:00