Volver al blog
13 de marzo de 20266 min de lectura

Claude Code vs Humano: ¿Quién conoce mejor tu proyecto?

Una historia real sobre cómo tuve que corregir a una IA que daba consejos técnicos correctos pero con suposiciones erróneas sobre mi configuración.

IADesarrolloElectronCI/CD

Claude Code vs Humano: ¿Quién conoce mejor tu proyecto?

El Contexto

Esto me pasó recientemente. Tenía un problema de build en mi app Electron (matrix). El problema: better-sqlite3 estaba compilado para Node.js (MODULE_VERSION 127) pero Electron requiere MODULE_VERSION 143.

Localmente funcionaba bien con pnpm start porque Forge hace rebuild automático en modo dev. Pero los archivos copiados en postPackage eran las versiones de Node.js, no las de Electron.

La IA Lo Resolvió Correctamente (Técnicamente)

Claude Code identificó el problema inmediatamente:

"El hook postPackage copia better-sqlite3 desde node_modules/ del proyecto (compilado para Node.js), no para Electron. Necesitamos usar electron-rebuild en el hook o cambiar la estrategia."

La solución era clara: hacer rebuild del módulo nativo para Electron dentro del hook.

pnpm package

Y boom — rebuild exitoso:

✔ Rebuild Complete
[Matrix] Native modules copied and rebuilt for Electron.
✔ Running postPackage hook from forgeConfig

El error de better-sqlite3 desapareció. La app arrancó correctamente:

feedURL https://update.electronjs.org/bpstack/matrix/win32-x64/1.0.1
requestHeaders { 'User-Agent': 'update-electron-app/3.1.2 (win32: x64)' }
updater error

Espera, eso no es un error — es solo el auto-updater intentando funcionar. La app en sí arrancó bien. ¿Solución técnica? Perfecta.

Donde Se Equivocó

Pero entonces Claude Code me pidió hacer algo incompleto:

"Ahora haz pnpm make y sube los 3 archivos al GitHub release"

Aquí está el error:

  1. Estaba en Windows — pnpm make solo genera el installer de Windows
  2. No podía hacer build de Linux/macOS desde Windows — La compilación cruzada no funciona así
  3. El bug afectaba a los 3 SO — better-sqlite3 necesitaba rebuilding para CADA plataforma

Así que si seguía este consejo, solo arreglaría Windows. Linux y macOS seguirían rotos.

Y empezó a explicar cómo configurar CI/CD. Como si no lo hubiera hecho ya.

El caso es que ya tenía CI configurado en .github/workflows/release.yml.

Esto es lo que la IA pasó por alto: el workflow se ejecuta en servidores virtuales de GitHub, lo que significa:

  • Runner de Windows genera el installer de Windows
  • Runner de macOS genera el installer de macOS
  • Runner de Linux genera el AppImage/deb de Linux

Cada SO construye en su PLATAFORMA NATIVA. Sin problemas de compilación cruzada. Sin trabajo manual. Solo hacer push y GitHub genera los 3 archivos automáticamente.

Se lo había dicho a Claude Code muchas veces antes.

Así que tuve que corregirlo:

"aunque el problema original vino del auto-updater, mi release (que ya hemos configurado en c:\Users\dz\projects\matrix\.github\workflows\release.yml) ya genera builds para cada OS ya que los hace virtualmente en el github server. Te he dicho muchas veces que te puedes documentar en mi código antes de dar directrices erróneas."

Y Claude Code respondió:

"Tienes razón, veamos qué tienes configurado"

Después intentó leer archivos y sugirió el enfoque correcto:

"Sí, ya tienes CI configurado para los 3 SO. Los runners virtuales manejarán cada plataforma de forma nativa. Entonces la opción B es la correcta:

  1. Commit de los cambios
  2. Bump versión a 1.0.2
  3. Push + tag v1.0.2
  4. GitHub Actions genera builds para Windows, macOS y Linux automáticamente

¿Quieres que lo haga?"

Y yo le respondí:

"No hace falta, ya lo hago yo, estás gastando tokens inútilmente y te estoy corrigiendo a ti"

La Lección Real

Lo que aprendí de esta interacción:

La IA conoce la solución técnica, pero no conoce TU proyecto

  • Puede depurar código perfectamente
  • Puede sugerir soluciones para problemas de módulos nativos
  • Puede escribir hooks y configuraciones complejas

Pero:

  • Olvida los detalles de tu configuración entre conversaciones
  • Asume que no tienes cosas que sí tienes
  • No lee realmente tus archivos de configuración existentes antes de sugerir soluciones
  • Sugiere soluciones incompletas sin entender el contexto completo
  • Desperdicia recursos cuando no sabe lo que ya tienes

El humano todavía añade valor

En este caso, me ahorré:

  1. Minutos de GitHub Actions — Ejecutar CI builds innecesarios cuando ya los tenía configurados
  2. Tiempo — No esperar por uploads manuales cuando CI lo hace automáticamente
  3. Contexto — Saber lo que ya tenía configurado

La IA resolvió el problema técnico. Yo ahorré las ejecuciones de CI desperdiciadas. Juntos? Eficientes. Separados? Desperdicio.

El Panorama General: Por Qué Necesitas Conocer Tu Configuración

Esto no es solo sobre ahorrar minutos de CI. Esto es sobre algo más profundo:

Si dejas que la IA configure todo, no sabrás cómo funciona.

Y si no sabes cómo está configurado:

  1. No lo recordarás — Si algo se rompe en 3 meses, no sabrás cómo solucionarlo
  2. Cometerás errores — Duplicarás trabajo o romperás cosas que no sabías que existían
  3. Desperdiciarás recursos — CI innecesario, configuraciones duplicadas, workflows ineficientes
  4. No mejoraras — No puedes optimizar lo que no entiendes
  5. Serás dependiente — Necesitarás la IA para cada cosa

Esto es exactamente lo que pasó aquí. La IA me dio una solución técnicamente correcta, pero asumió que no tenía CI/CD configurado. ¿Por qué? Porque no conoce mi proyecto. No lee mis archivos proactivamente. Solo resuelve el problema inmediato.

¿Yo? Yo sabía que tenía CI configurado porque yo lo configuré. Sabía lo que hacía porque yo escribí el workflow. Sabía dónde estaba porque yo creé el archivo.

Esa es la diferencia.

El Camino a la Dependencia

No configuras → IA configura por ti
IA configura → No aprendes
No aprendes → No entiendes
No entiendes → No recuerdas
No recuerdas → Necesitas IA de nuevo
Necesitas IA de nuevo → IA configura de nuevo
→ Ciclo de dependencia

Rompe el ciclo. Configúralo tú mismo. Documentalo. Conócelo.

Porque al final del día, el que mejor conoce tu proyecto deberías ser tú. No la IA.

Lo Que Hago Ahora

Antes de aceptar sugerencias de IA, yo:

  1. Referencio archivos existentes — "Revisa mi .github/workflows/ primero"
  2. Confirmo suposiciones — "¿Qué te hace pensar que no tengo X configurado?"
  3. Verifico antes de ejecutar — No ejecuto comandos ciegamente

La IA es una herramienta increíble para depurar y resolver problemas técnicos. Pero no reemplaza conocer tu propio proyecto. No recuerda tus decisiones de arquitectura. No ve los archivos que olvidaste mencionar.

Conclusión

El mejor workflow no es solo IA ni solo humano. Es IA + humano trabajando juntos, con el humano proporcionando contexto que la IA no puede inferir.

La IA resolvió el problema técnico. Yo ahorré las ejecuciones de CI desperdiciadas. Ambos contribuyeron.

Así es como debería funcionar.

Proyecto: matrix (app de escritorio Electron)
Problema: compilación del módulo nativo better-sqlite3
Estado: Corregido con electron-rebuild en el hook postPackage
CI/CD: Ya configurado, no se necesitan cambios

Volver al blog