Quien vende herramientas corre contra el modelo. Quien vende el trabajo corre con él.
Todo el que construye algo con IA hoy hace la misma cuenta mental: ¿qué le pasa a mi producto cuando la próxima versión del modelo haga esto sola? La pregunta es honesta y el miedo es justo. Si lo que vendes es la herramienta, cada modelo nuevo acorta la distancia entre tú y cualquiera. Pero si lo que vendes es el trabajo terminado, la misma actualización que amenazaría al producto llega como un aumento de margen: más rápido, más barato, más difícil de alcanzar.
Inteligencia y criterio
Vale la pena separar dos cosas que suelen venir en el mismo paquete.
Escribir código es, casi todo, inteligencia. Las reglas son complicadas, pero son reglas: traducir una especificación, probar, encontrar dónde se rompió. Decidir qué construir después es criterio. Depende de experiencia, de gusto y de haberse equivocado antes. Qué deuda técnica aceptar, cuándo entregar antes de que esté listo, qué recortar cuando el plazo se achica.
La IA cruzó el umbral de la inteligencia primero en la ingeniería de software, por un motivo simple: es la profesión en la que la máquina puede verificar sola si acertó. Compila o no compila, la prueba pasa o no pasa.
Dónde se están usando los agentes (% de las llamadas a herramientas)
Ingeniería de software |================================== 49,7%
Automatización de back-office |====== 9,1%
Otros |===== 7,1%
Marketing y copywriting |=== 4,4%
Ventas y CRM |=== 4,3%
Finanzas y contabilidad |=== 4,0%
Análisis de datos y BI |== 3,5%
Investigación académica |== 2,8%
Seguridad |= 2,4%
Atención al cliente |= 2,2%
Fuente: Sequoia, "Services: The New Software" (2026)
La mitad, contra un solo dígito en todo lo demás. No es que las otras profesiones sean más difíciles. Es que nadie ha armado todavía el ciclo de verificación que la ingeniería obtuvo gratis.
El cliente nunca quiso la herramienta
Aquí va la parte que el mercado brasileño siempre supo y que el mercado de producto insiste en olvidar.
Ningún cliente se levanta con ganas de comprar software. Quiere el problema resuelto. La empresa que paga un sistema de contabilidad y después le paga al contador para cerrar el mes no está comprando dos cosas: está comprando una, y paga la licencia como un peaje. Lo que quería era el mes cerrado.
Vender herramientas obliga al cliente a convertirse en operador. Compra la licencia, aprende la interfaz, descubre que falta una pieza, contrata a alguien para unir los extremos. Vender el trabajo se salta toda esa fila.
Dónde deja esto a Nimbuu
El servicio es la puerta y el software es la casa. Un sitio, un sistema o una app sale de Nimbuu ya instalado dentro del ecosistema: cobra con Pay, se edita en Build y sigue en pie sin depender de una llamada hacia acá.
Ninguno de estos productos empezó como idea de startup. Cada uno empezó como un problema que apareció en medio de una entrega:
- Había que cobrar por lo que se hizo, y el checkout que existía era difícil de integrar. Se volvió Pay.
- El cliente necesitaba cambiar un texto sin abrir un ticket. Se volvió Build.
- Varios proyectos al mismo tiempo necesitaban agentes de código sin que uno pisara al otro. Se volvió Stratuu.
Es el orden inverso al que se enseña. Primero el trabajo, que es lo que alguien paga hoy. Después la herramienta, que es lo que queda del trabajo bien hecho y repetido suficientes veces como para que valga la pena automatizarlo.
La prueba
Si la próxima versión del modelo deja tu producto obsoleto, estabas vendiendo la herramienta. Si deja tu entrega más rápida, estabas vendiendo el trabajo.
Vale la pena hacerse la pregunta antes de que el mercado la haga por ti.