Cuando necesitás una herramienta, aparece una decisión conocida: ¿conviene comprar algo hecho o construirlo a medida?
Con los agentes, esa pregunta necesita una precisión. Pedirle a uno que arme una aplicación sigue siendo construir: después queda software propio que mantener. La tercera opción aparece cuando le delegamos directamente una tarea y recibimos un resultado, sin crear una aplicación propia para resolverla cada vez.
Las mini-apps caseras son un ejemplo de construcción con IA: herramientas pequeñas para ordenar gastos, convertir datos o automatizar una tarea repetitiva. Pueden ser muy útiles, sobre todo cuando resuelven algo propio que un producto genérico no contempla.
Pero que sea fácil ponerlas en marcha no significa que sean gratis de mantener. La pregunta ya no es solamente «¿lo puedo construir?». También es «¿me quiero hacer cargo?».
Construir se hizo más accesible
El 14 de octubre, Epic Games presentó una versión preliminar de su nuevo launcher con una frase provocadora: programar es difícil, así que habían recurrido al vibe coding para crear uno nuevo.
Conviene leerla en contexto. La propia Epic describe el lanzamiento como una preview, «una lancha y no un yate», y aclara que todavía le faltan funciones. Su equipo contó que empezó desde cero y usó IA para escribir y revisar funcionalidades en otra tecnología. Es una noticia interesante sobre cómo cambia el proceso de desarrollo, pero no demuestra que construir y sostener un producto grande se haya vuelto trivial.
Imaginá ahora una herramienta casera para preparar un boletín. Generar el texto y una vista previa puede resolver una necesidad personal. Convertirla en un servicio de envío para otras personas agrega trabajo: manejar rebotes, bajas, permisos y fallos de entrega, además de cuidar los datos de los destinatarios.
Ese ejemplo plantea una pregunta útil: ¿qué trabajo hace falta para que algo siga funcionando cuando deja de ser un experimento personal?
La IA reduce el costo de empezar. No elimina automáticamente lo que viene después.
Tres preguntas para decidir
Para comparar comprar software, construir una herramienta propia o delegar una tarea a un agente, propondría tres preguntas sencillas.
1. ¿Esto te diferencia?
Si la herramienta contiene una parte importante de lo que hace especial a tu negocio, tenerla bajo tu control puede valer la pena. Quizá puedas adaptarla mejor a tu forma de trabajar y cambiarla cuando el negocio cambie.
Si la tarea es común —facturación, correo, nómina o gestión de contactos— es posible que ya existan productos que resuelvan el problema con más experiencia, integraciones y soporte.
No todo lo que una empresa usa tiene que ser una ventaja propia. A veces es mejor dejar que otra organización se encargue de resolver bien lo que no te distingue.
2. ¿Qué pasa si falla?
Una pequeña herramienta para ordenar tus notas puede dejar de funcionar y ser una molestia. Un sistema que procesa cobros, datos de clientes o registros contables puede causar un daño mucho mayor.
Cuanto más costoso sea el error, más pesan la confiabilidad, la seguridad, la recuperación y el soporte. En un proceso regulado, además, hay que considerar las obligaciones y los controles aplicables.
Comprar un producto no hace desaparecer el riesgo. También hay que evaluar al proveedor, entender dónde quedan los datos y saber cómo se responde ante una interrupción. Pero sí puede significar que parte del mantenimiento y de la operación recaiga en un equipo dedicado a eso.
3. ¿Quién lo mantiene dentro de dos años?
Un agente puede crear una primera versión muy rápido. Después quedan las actualizaciones, las dependencias, los permisos, las copias de seguridad, los cambios en los servicios externos y los errores que aparecen con el uso real.
Para una herramienta interna que usa una persona y resuelve una necesidad pequeña, quizá ese compromiso sea razonable. Para un producto del que dependen clientes o ingresos, hace falta asignar responsables y definir cómo se prueba, protege y corrige.
El costo no está solo en construirlo. También está en conservarlo útil y seguro.
Si delegás una tarea puntual —por ejemplo, convertir una copia de un archivo y revisar el resultado— quizá no necesites mantener una aplicación. Igual hay que considerar el costo de ejecución, qué datos y permisos recibe el agente y cómo comprobás su trabajo. Si terminás usándolo todos los días con integraciones y reglas propias, ya hay una automatización que alguien debe sostener.
Una guía mental, no una fórmula
Podés ordenar la decisión con dos preguntas: cuánto te diferencia la herramienta y cuánto cuesta que falle.
- Te diferencia y una falla tendría poco impacto: construir puede tener sentido, quizá con ayuda de IA.
- No te diferencia y una falla sería costosa: comprar una solución probada puede ahorrarte trabajo, después de evaluar al proveedor.
- Es para uso propio o interno, resuelve algo acotado y puede durar poco: una mini-app de agente puede ser suficiente.
- Es una tarea puntual y su resultado se puede revisar: delegarla a un agente puede evitar construir una herramienta propia.
- Te diferencia, pero una falla sería costosa: construir requiere ingeniería, pruebas, revisión y una persona responsable.
No es una fórmula que decida automáticamente. Sirve para poner sobre la mesa costos que suelen quedar fuera de la primera demo.
Las mini-apps tienen su lugar
No quiero que esto suene como una advertencia contra construir. Poder resolver pequeños problemas con herramientas propias es una posibilidad valiosa. Una aplicación sencilla puede adaptarse exactamente al flujo de una persona, ahorrar pasos y enseñar mucho en el proceso.
El límite aparece cuando confundimos «funciona en mi computadora» con «es un servicio listo para depender de él». Si la herramienta empieza a manejar datos sensibles, dinero o el trabajo de otras personas, cambia la responsabilidad. Hay que pensar en accesos, respaldo, pruebas, privacidad y qué pasa cuando algo se rompe.
También hay una diferencia entre construir algo para aprender y convertirlo en una parte crítica de una operación. El mismo código puede ser un experimento excelente y una mala pieza de infraestructura.
El primer día se abarató; el compromiso sigue
Los agentes están moviendo el punto de partida. Para muchas ideas, ahora es más fácil preparar un prototipo, automatizar un paso o comprobar si una solución podría servir.
Eso no obliga a reemplazar cada suscripción ni a crear una aplicación propia para todo. El tiempo que antes se iba en una primera implementación puede reaparecer como tiempo de revisión, mantenimiento y soporte.
Por eso, ante la próxima decisión de software, preguntaría menos «¿lo podemos hacer?» y un poco más: «¿qué ventaja nos da, cuánto nos costaría una falla y quién va a sostenerlo?».
Construirlo se volvió más barato. Hacerse cargo, no.
Referencias
- Epic Games, presentación del nuevo Launcher en preview, 14 de octubre de 2026.
- Ars Technica, Epic dice que su nuevo Launcher hecho con vibe coding es más rápido que Steam, 14 de octubre de 2026.
Esta reflexión continúa una conversación que ya exploré en De acceso a software a trabajo hecho y en Demasiado código: ¿quién revisa todo eso?. Un abrazo.