Hay un relato de ciencia ficción que circula esta semana en Hacker News y que describe algo que ya está pasando: Tom Hartmann no planeaba convertirse en “mecánico de software”. Nadie lo hace. El trabajo no existía hace siete años.
En el cuento “Warranty Void If Regenerated” de nearzero.software, Hartmann era técnico de equipos agrícolas —tractores, cosechadoras, sistemas GPS— en Wisconsin. Cuando el software dejó de ser algo que se repara para convertirse en algo que se regenera desde especificaciones en lenguaje natural, su trabajo cambió de forma. Ya no arreglaba código. Arreglaba especificaciones. Si el sistema fallaba, el cliente o el propio técnico reescribía la descripción de lo que debía hacer y el software se regeneraba. “Bug” dejó de ser un error de código detectable. Pasó a ser un síntoma de especificaciones incompletas.
El relato es ficción, pero describe con precisión un fenómeno sistémico real que vale analizar con seriedad.
IA para el Resto de Nosotros
La nueva versión de mi curso estrella para aprender a usar la IA de forma práctica, simple y útil en tu día a día. Comienza el 24 de marzo.
→ Inscríbete hoy 🚀¿Qué es el “software regenerado” y por qué importa en agricultura?
La agricultura moderna ya corre sobre software: sistemas de guía GPS, sensores de humedad, drones de aplicación de agroquímicos, plataformas de gestión de cultivos. Históricamente, cuando ese software fallaba, necesitabas un programador. El tiempo y el costo eran prohibitivos para el agricultor promedio en LATAM.
Lo que está cambiando, según varios reportes del sector, es que cada vez más de ese software se genera mediante prompts en lenguaje natural. Un técnico de campo puede describir lo que necesita —”quiero una alerta cuando la humedad baje del 40% en el sector norte y el viento supere 20 km/h”— y obtener un script funcional sin escribir código. Cuando algo no funciona, el flujo no es depurar el código, sino refinar la descripción.
Cerca del 60% de los problemas técnicos en estos entornos, según el artículo base, provienen de datos externos que cambian sin aviso: APIs de sensores que actualizan su formato, feeds meteorológicos que cambian su estructura, integraciones con plataformas de proveedores que no notifican sus cambios. El software regenerado es tan bueno como las especificaciones que lo describen. Y las especificaciones que fallan son casi siempre las que asumen que el mundo externo es estable.
Por qué importa más allá del relato
La tesis real aquí no es que la IA automatiza la agricultura. Es que el software generado por IA desplaza la expertise técnica hacia el dominio específico. Un Software Mechanic en agricultura necesita saber de agricultura, no de programación. El técnico que entiende cuándo una especificación falla por un error del negocio versus un error de la herramienta es más valioso que el que entiende Python.
Para founders que construyen en agtech o en cualquier industria “old school” con adopción de IA: el diferencial no está en el modelo. Está en quién puede diagnosticar el gap entre lo que el sistema debería hacer y lo que está haciendo, con suficiente contexto del dominio para reescribir la especificación correctamente.
En LATAM, donde la agricultura representa entre el 5% y el 20% del PIB dependiendo del país, y donde la digitalización del campo sigue siendo fragmentaria, este fenómeno tiene implicancias concretas. Las plataformas que bajen la barrera de creación de herramientas digitales para técnicos de campo —no para programadores— tienen una oportunidad enorme. El modelo de negocio tampoco es trivial: como muestra el relato, los clientes prefieren pagar por reparaciones puntuales antes que por suscripciones preventivas, lo que crea fricciones reales para quien quiera construir un modelo recurrente.
Algo que también cubrimos cuando vimos cómo la IA redefine quién construye software: el rol no desaparece, se transforma. Y en sectores físicos como el campo, esa transformación llega más lento pero con implicancias más profundas.
