No instalar todavía también es una decisión técnica

Me gusta probar herramientas nuevas. No solo porque puedan resolver un problema, sino porque entender cómo funcionan suele abrir preguntas que ni siquiera me había planteado. Esa curiosidad tiene una ventaja evidente cuando trabajas en tecnología. También tiene un riesgo: confundir que algo sea interesante con que deba quedarse instalado.

Una herramienta puede funcionar perfectamente y, aun así, no tener sentido mantenerla encendida.

Me he encontrado con esa diferencia al experimentar con modelos de IA locales y, después, con un agente persistente. Había decisiones técnicas interesantes: dónde alojarlo, cómo aislarlo, qué permisos conceder, cuánto contexto necesitaba y de qué manera controlar su consumo. Resolverlas fue útil. Pero ninguna de esas respuestas demostraba, por sí sola, que necesitara el sistema disponible las veinticuatro horas.

El experimento y el servicio no son lo mismo

Cuando preparo una prueba técnica puedo aceptar condiciones que serían incómodas en operación normal. Puedo intervenir manualmente, reiniciar una máquina, investigar un fallo o dedicar una tarde a entender por qué una opción se comporta de una manera inesperada. Ese tiempo forma parte del experimento.

Un servicio estable tiene otra exigencia. Debe justificar su mantenimiento incluso cuando nadie está mirando.

Por eso hay una diferencia importante entre estas dos preguntas:

«¿Soy capaz de instalarlo y hacerlo funcionar?»

«¿Qué problema real mejora lo suficiente como para mantenerlo funcionando?»

La primera suele tener una respuesta técnica. La segunda también tiene que contemplar atención, coste, seguridad, consumo y frecuencia de uso.

La complejidad no desaparece al terminar la instalación

Una VM encendida no es solo una VM encendida. Es otro sistema que revisar, actualizar, proteger, respaldar y entender cuando falle. Si ejecuta un agente con herramientas, el alcance es todavía mayor: permisos, tareas programadas, accesos, límites de gasto y comportamiento ante errores.

Ese mantenimiento puede merecer muchísimo la pena. Lo que no tiene sentido es contabilizar únicamente el tiempo de instalación y tratar todo lo demás como si fuera gratis.

Había llegado a una configuración conocida, con un entorno aislado y un agente persistente accesible desde la red local. Había dedicado esfuerzo a entender las fronteras de seguridad y las automatizaciones. También aparecieron costes de consumo asociados a tareas recurrentes que obligaron a replantear qué debía ejecutarse de manera autónoma y qué no.

No fue una demostración de que la herramienta fuera mala. Fue una demostración de que una prueba técnicamente satisfactoria todavía puede necesitar una decisión operativa distinta.

Parar también conserva conocimiento

Durante un tiempo tendemos a tratar un sistema apagado como un proyecto abandonado. Pero hay una forma más útil de verlo: el experimento produjo información y la decisión posterior fue no convertirlo todavía en un servicio permanente.

El valor queda en lo aprendido, no en el consumo eléctrico o en tener un panel de administración disponible.

La decisión que tomé fue mantener apagada la máquina virtual del agente hasta encontrar un objetivo suficientemente concreto que justificara reactivarla. La máquina sigue apagada. No borré la experiencia ni convertí los resultados anteriores en inútiles. Simplemente dejé de pagar el coste continuo de una capacidad sin uso continuo.

Esa es una diferencia que me parece importante. Una pausa deliberada necesita una condición de retorno, no una excusa. En este caso, la condición es clara: una tarea real, repetida y suficientemente valiosa para justificar la infraestructura y la supervisión.

Antes de instalar, definir la salida

Hay una prueba que me está resultando más valiosa que leer listas de características. Consiste en escribir qué espero recibir cuando la herramienta funcione.

No «un agente con memoria y herramientas». Eso describe una arquitectura.

Algo como «un informe que me permita decidir si debo intervenir», «un documento útil preparado cada semana» o «una comprobación que antes hacía a mano y ahora queda verificada». Eso describe un resultado.

A partir de ahí puedo preguntar si necesito un servicio permanente, una tarea puntual, un script convencional o ninguna automatización. Muchas veces la respuesta se vuelve menos espectacular. También más sostenible.

Si el flujo puede ejecutarse cuando lo necesito, quizá no hace falta mantener un proceso activo todo el día. Si el resultado no cambia ninguna decisión, quizá no necesito generarlo a diario. Y si la revisión exige más trabajo que hacerlo manualmente, la automatización todavía no está terminada.

La alternativa a acumular infraestructura

Los desarrolladores sabemos añadir piezas. En ocasiones nos cuesta más decidir cuáles no añadir.

No instalar una dependencia, no activar un servicio o apagar una VM parece una decisión menor porque no deja una funcionalidad nueva que enseñar. Sin embargo, puede reducir superficie de fallo, eliminar mantenimiento innecesario y permitir dedicar atención a lo que realmente está en uso.

No propongo dejar de experimentar. Es casi lo contrario: experimentar sin asumir que cada prueba debe convertirse en una obligación permanente.

La pregunta no es si una tecnología merece una oportunidad. Es cuándo merece quedarse.

De momento, mi criterio es sencillo: primero una necesidad comprobable; después, la mínima arquitectura que la resuelve. Y si esa necesidad no existe todavía, no instalar —o apagar— también es una decisión técnica perfectamente válida.