En una experiencia anterior de desarrollo, le pedí a Claude que reconsiderara cómo acceder a la base de datos de una aplicación. Ya había código escrito, pero no quería que eso decidiera el estándar por inercia. La pregunta era concreta: comparar GORM, sqlc y SQL nativo, y dejar anotado qué convenía descartar o mejorar en las librerías y en el manejo del contexto.
El punto de partida también importaba. Había elegido un ORM para ahorrar consultas escritas a mano cuando todavía no contaba con un agente de IA. Al retomar el análisis con esa ayuda, pedí revisar aquel criterio. Eso no demostraba que la elección anterior fuera incorrecta: cambiaba una de las condiciones con las que quería evaluar las alternativas.
Una propuesta con consecuencias
Claude anunció que iba a inventariar las librerías y el manejo de contexto antes de comparar opciones. Después propuso sqlc junto con pgx como estándar y planteó descartar GORM. En su explicación, el centro de la comparación pasó del ahorro de escritura a la posibilidad de revisar las consultas y contrastarlas con el esquema.
La propuesta no se limitaba a elegir una dependencia. Claude presentó el SQL explícito como una forma de conservar visible lo que se ejecutaría y de facilitar su revisión. También reconoció un costo: las consultas con muchos filtros opcionales resultarían incómodas. Para esos casos propuso usar pgx directamente, dentro del mismo adaptador de acceso a datos.
Ese detalle condicionaba el paso siguiente. El estándar recomendado incluía una excepción acotada; no pretendía que todas las consultas siguieran exactamente el mismo camino. La decisión de arquitectura necesitaba explicar tanto la vía habitual como los casos que se apartaban de ella.
El documento también tenía que cambiar
Mientras desarrollaba el análisis, Claude reportó usos directos de una conexión global y ausencia de cierre ordenado. La muestra conservada no permite verificar esos hallazgos contra el código, así que los trato como observaciones del agente. Sí muestra que el análisis incorporó el manejo de contexto y las librerías, además de la comparación inicial.
Luego Claude indicó que había añadido una sección sobre acceso a datos y actualizado las recomendaciones anteriores para que coincidieran con el nuevo estándar. Revisó menciones en la lista de cambios, la sección de base de datos, el kit y el plan de trabajo. Ahí estaba la consecuencia más concreta de su decisión: proponer otra herramienta obligaba a corregir también el documento que orientaría los pasos posteriores.
Qué quedó resuelto
El resultado documentado fue una revisión del análisis. Claude dijo haber comprobado su estructura, enlaces internos y recomendaciones residuales. No tengo en esta muestra resultados de pruebas de la migración ni una confirmación humana de adopción del estándar propuesto. Tampoco corresponde convertir esa revisión en una mejora de rendimiento demostrada.
Mi intervención verificable fue pedir una nueva evaluación sin atarla al código existente. La aportación de Claude fue formular una alternativa, reconocer una excepción y trasladar sus consecuencias al resto del plan. Esta experiencia deja una distinción útil: una recomendación de arquitectura puede ordenar el trabajo pendiente, pero su valor en ejecución todavía necesita comprobaciones propias.