Un mes con la beta de Hefty - informe de campo desde la fase de pulido

Hace un mes escribí sobre lo que aprendí al lanzar la beta de Hefty con un compañero de programación con IA. Aquel artículo abarcó seis semanas desde cero hasta la beta: desarrollo guiado por especificaciones, ciclos de retroalimentación de usuarios y un ritmo de despliegue que jamás había experimentado con un flujo de trabajo tradicional. Hefty es un agente de IA local-first que controla su computadora, automatiza flujos de trabajo y gestiona archivos, y continúa en fase de beta abierta.

El último mes fue distinto. No fue más lento; en varios aspectos resultó incluso más rápido. Sin embargo, fue más exigente de una forma que no había previsto, y no porque los retos técnicos fueran más complejos. Lo que cambió fue la naturaleza misma del desafío. Cuando usted pasa de crear algo nuevo a pulir una herramienta que la gente utiliza a diario, llega el momento de pagar la factura por cada atajo tomado. La pregunta deja de ser «¿podemos construir esto?» y se convierte en «¿podemos sostener esto?».

Este texto es un informe de campo de esa etapa.

La paradoja de las pruebas

En mi artículo anterior defendí la decisión de prescindir de las pruebas automatizadas. El código se transformaba tan rápido que una suite de pruebas habría significado un desgaste continuo con un aporte mínimo de estabilidad. Esa apuesta dio resultado durante la fase inicial de desarrollo puro.

Un mes después, las pruebas unitarias están operativas. Las pruebas de extremo a extremo (end-to-end) están en funcionamiento. Los entornos de ejecución están configurados. Y, aun así, no tengo la certeza de cuánto valor aportan realmente en este momento.

La razón es la siguiente. Me encuentro inmerso en una profunda revisión de calidad operativa: refactorizando interfaces, simplificando flujos y consolidando abstracciones que tenían sentido en la primera semana, pero que hoy han quedado obsoletas. Son precisamente estos cambios los que rompen las pruebas. No porque las pruebas estén mal planteadas, sino porque el producto sigue evolucionando a una velocidad superior a la capacidad de las pruebas para seguirle el paso. La incógnita consiste en si las metodologías clásicas de testing conservan su vigencia en esta etapa de un flujo asistido por IA, donde el ritmo de modificación supera por amplio margen a los métodos convencionales.

No sostengo que las pruebas hayan muerto. Semejante afirmación es insostenible cuando se mantiene un producto real. Lo que señalo es que la ecuación de retorno de inversión y el momento oportuno de implementación cambian por completo cuando su socio de IA puede reestructurar un módulo entero en el mismo lapso que toma actualizar los datos de prueba correspondientes. La regla que estoy adoptando es clara: las pruebas adecuadas en el momento preciso, no pruebas por el simple hecho de acumularlas. Profundizaré en esto cuando la arquitectura alcance mayor estabilidad y la suite empiece a justificar su existencia.

El dilema de las pruebas fue la primera señal. La segunda fue que Hefty comenzó a superar su estructura original.

De agente a plataforma

Hefty ha dejado de ser un agente individual. Está evolucionando hacia una plataforma: un conjunto de servicios que respaldan las operaciones basadas en agentes de quienes lo ejecutan, configuran y utilizan en su actividad diaria.

Desarrollar esa plataforma sacó a la superficie los verdaderos desafíos del desarrollo de software asistido por IA. Son los aspectos que nadie comenta en las conferencias:

• el cambio de contexto es el enemigo silencioso - me encuentro alternando entre el núcleo del agente, los servicios de la plataforma, las herramientas del operador y las capas de configuración; cada ámbito cuenta con su propio contexto, estado y modelo conceptual. Las herramientas de IA son potentes dentro de un contexto aislado, pero no facilitan la transición fluida entre cinco de ellos a la vez. Dudo que exista algo capaz de lograrlo.
• el entorno de desarrollo y la producción siguen siendo dos planetas distintos - lo que se ejecuta sin problemas en mi equipo y lo que funciona de manera confiable para otra persona continúan siendo realidades diferentes. Esa brecha no desapareció con la IA; simplemente cambió de lugar. Despliegue, discrepancias de configuración y supuestos de tiempo de ejecución: es indispensable seguir considerando cada uno de estos factores.
• la seguridad pasa de ser abstracta a convertirse en un pilar arquitectónico - en el momento en que se construye una solución que interactúa con sistemas locales y claves de API de los usuarios, la seguridad deja de ser un requisito administrativo y pasa a definir cada decisión de diseño. ¿A qué recursos tiene acceso el agente? ¿Qué eventos se registran en los registros del sistema? ¿Qué información se almacena en caché? ¿Qué sucede cuando se renuevan las credenciales?
• la estabilidad de las APIs es una decisión estratégica - me he vuelto sumamente riguroso al seleccionar los servicios externos que decido integrar. La lección fue directa y costosa: elija APIs consolidadas y maduras, o prepárese para asumir el costo de reescribir integraciones cada vez que un proveedor externo decida sumarse a la tendencia de turno.

Ninguna de estas tareas resulta glamorosa. Sin embargo, es el trabajo que separa a una demostración de un producto real.

Todo este impulso generó su propio obstáculo.

El choque contra la barrera de velocidad

La forma en que venía trabajando para construir la versión beta - guiando manualmente a la IA en cada tarea, revisando cada resultado, corrigiendo el rumbo e iterando - se topó con un límite. No fue una barrera conceptual; fue una barrera de velocidad operativa.

Incluso frente a tareas de complejidad moderada, el ciclo manual resultaba excesivamente lento. Dedicaba más tiempo a dirigir el modelo que a construir la solución. Eso representa exactamente lo contrario de lo que se espera del desarrollo asistido por IA.

Por lo tanto, introduje un cambio estructural. Pasé del diseño directo de prompts a un esquema automatizado: orquestación en lugar de supervisión manual, flujos continuos en vez de instrucciones aisladas y descomposición sistemática de tareas en lugar de ensayar para ver qué funciona.

Se produjeron dos consecuencias inmediatas:

• el consumo de tokens aumentó de forma considerable - una mayor automatización implicó mayor procesamiento por parte de la IA en cada ciclo: más generación, más análisis y mayor gestión de contexto. Si su proveedor factura por token, aquí es donde el costo se hace evidente. Sin embargo, también es donde surge el verdadero apalancamiento: el costo se elevó, pero la productividad obtenida por cada unidad de mi tiempo creció en una proporción mucho mayor. Ese es precisamente el intercambio que buscaba.
• evité el riesgo de quedar atrapado por un proveedor - casi en el mismo período, un proveedor líder de IA comenzó a tomar medidas que recuerdan por qué depender de una sola cadena de herramientas ajena es un riesgo: ajustes en precios, límites de uso y la estrategia habitual del mercado. El enfoque multi-proveedor orientado a la automatización que acababa de adoptar me permitió absorber el impacto sin alterar el ritmo de trabajo.

La lección general es clara: cuanto antes incorpore flexibilidad operativa en un flujo asistido por IA, menor será el impacto cuando un proveedor decida que sus requerimientos ya no forman parte de sus prioridades.

Una vez que los sistemas internos estuvieron operativos, la dinámica cambió. El cuello de botella ya no residía en el código.

Mirar hacia el panorama general

En todo proyecto desarrollado en solitario llega un momento en que el código avanza con tal rapidez que el propio creador se convierte en la principal limitación. En mi caso, esa transición ocurrió alrededor de la sexta semana.

Comencé entonces a operar de manera diferente. Dedico menos tiempo a escribir código y más a trabajar en torno al producto.

Incorporé un agente especializado en marketing. No se trata de un asistente genérico, sino de un sistema concebido específicamente para gestionar la estrategia de contenidos, la segmentación de audiencias y la planificación de campañas para Hefty. La mejora en la calidad de los resultados fue inmediata.

Asimismo, volví mucho más estrictos los criterios para seleccionar aliados comerciales. He participado en suficientes conversaciones con personas interesadas en «explorar sinergias». Lo que requiero en esta etapa son contrapartes dispuestas a avanzar: aliados que identifiquen la oportunidad, dominen este entorno y prefieran construir en lugar de teorizar. El filtro no solo es más riguroso, sino innegociable.

Esta transición resulta exigente. Implica confiar en los sistemas que uno mismo diseñó para resolver tareas que antes ejecutaba de forma manual. Supone aceptar que mi tiempo genera mayor valor en la estrategia y las alianzas que en la confirmación del siguiente commit. Significa aprender a delegar.

Sin embargo, al levantar la vista del código, es inevitable enfrentar la realidad del mercado. Y el mercado actual está saturado de ruido.

Señal y ruido

Comencé a prestar mayor atención a las conversaciones sobre IA en internet. En parte por curiosidad, pero sobre todo por necesidad: requiero comprender cómo posicionar a Hefty en un entorno abrumado por el ruido mediático.

El panorama es el previsible. Cada jornada surge un nuevo lanzamiento. Cada hilo en redes promete una revelación. Cada comentario pretende ser la verdad definitiva. El ámbito de la IA en redes sociales es una economía de la atención funcionando al máximo de su capacidad, y la mayor parte de lo que genera para captar interés es, siendo benevolentes, pura aspiración.

No dispongo de una solución mágica. Si la tuviera, lideraría el área de marketing y no la de ingeniería.

Mi principio de trabajo consiste en mantener la sobriedad, preservar el enfoque y continuar entregando software funcional. El público al que deseo dirigirme - operadores de agentes de IA y especialistas que valoran la privacidad y las soluciones local-first - identifica de inmediato las promesas vacías. Y el ecosistema actual de IA abunda en ellas.

El producto habla por sí mismo. La trayectoria técnica habla por sí misma. Presentarse con actualizaciones comprobables y código funcional comunica mucho más que cualquier publicación viral. Sostengo esa convicción, aun cuando los algoritmos premien dinámicas distintas.

A pesar de todo el ruido, las personas indicadas comenzaron a acercarse.

Primeras conversaciones con un matiz diferente

Esto es algo que no esperaba ver tan pronto.

He comenzado a sostener reuniones con clientes potenciales. No son los intercambios habituales guiados por la fascinación tecnológica donde alguien pide que le describa el producto a grandes rasgos. Son conversaciones prácticas con profesionales que comprenden a fondo dos premisas esenciales. Primero, el valor de un asistente personal de IA que se ejecuta en su propio hardware, bajo su absoluto control y con datos que jamás salen de su máquina. Segundo, los peligros derivados de depender de la IA en la nube para procesos que involucran información confidencial, flujos de trabajo críticos y decisiones estratégicas cotidianas.

Las consultas se plantean de forma directa: «Necesito resolver X. ¿Hefty puede ejecutar X?». Esa pregunta surge de alguien que ha analizado a fondo un requerimiento concreto, no de quien se limita a reaccionar ante una tendencia pasajera.

Todavía no estoy calculando ingresos. Estoy evaluando la calidad de las conversaciones. Y estas comienzan a sentirse sustancialmente distintas: menos exploratorias y mucho más intencionadas.

Pasos pequeños, pero reales

Para un producto consolidado que cuenta con equipo de desarrollo y capital externo, nada de esto resultaría extraordinario. Una estrategia de pruebas, una arquitectura de plataforma, una estructura de marketing y las primeras reuniones comerciales constituyen la rutina habitual de cualquier semana.

Para un proyecto autofinanciado desarrollado por una sola persona con la IA como herramienta principal de ingeniería, dentro de un ámbito que produce mucho más ruido que sustancia, estos avances representan verdaderos hitos. No porque resulten asombrosos de forma aislada, sino porque cada uno refleja una decisión adoptada, un riesgo asumido y la certeza de que el esfuerzo acumulativo supera con creces a los lanzamientos rimbombantes.

Esto sigue siendo el principio. Hefty continúa en fase beta. La etapa de pulido es el momento en que usted descubre lo que su producto es en realidad, en contraste con lo que pretendía que fuera en el diseño inicial. En esa brecha es donde surge el aprendizaje auténtico.

Seguiré documentando lo que vaya descubriendo, no porque tenga todas las respuestas, sino porque este sector necesita testimonios transparentes de quienes están poniendo soluciones en producción y no de quienes comentan desde la barrera. El compromiso es idéntico al anterior: sin adornos innecesarios, sin posturas artificiales y sin listas superficiales. Únicamente lo que estoy construyendo, lo que da resultados, lo que falla y las implicaciones que identifico para cualquiera que persiga un objetivo similar.

Pronto compartiré nuevos avances.

Pruebe la versión beta

Hefty se encuentra en beta abierta. Se ejecuta localmente, prioriza la privacidad y le permite utilizar su propio modelo LLM o clave de API. La versión beta se puede probar de forma gratuita y está disponible para Linux, macOS y Windows.

Si usted tiene un interés genuino en los agentes de IA locales - ya sea como usuario o como aliado estratégico - me complacerá conversar con usted. Y si actualmente mantiene un desarrollo construido con soporte de IA, me gustaría saber cómo se desenvuelve su fase de pulido.