Lo que aprendí al lanzar la beta de Hefty con un compañero de programación con IA

Hefty está en fase de beta abierta. Hefty es un agente de IA local-first que controla su computadora, automatiza flujos de trabajo y gestiona archivos. Este texto no pretende ser un consejo. Es un informe directo desde el desarrollo: lo que aprendí al construir Hefty desde cero con la IA como mi principal compañero de programación. Parte de esto coincide con lo que escribí en The New Rules. Otra parte me sorprendió por completo.

De dónde surge esta experiencia

Llevo 27 años entregando código a producción. Tengo un doctorado en ingeniería, he publicado en IEEE y Springer sobre sistemas distribuidos y modelos neuronales, y fui arquitecto principal de la red social más grande de España, una plataforma con más de 10 millones de usuarios. Recientemente ayudé a construir Anyone, la mayor red distribuida de privacidad del mundo.

Esta trayectoria importa para lo que viene a continuación. No soy un recién llegado deslumbrado por el autocompletado de código con IA. He construido infraestructura de producción a gran escala, y puedo asegurar que la línea de desarrollo asistida por IA es real. Simplemente no funciona de la forma en que la mayoría de la gente cree.

El plan y el estado actual

El plan para Hefty contemplaba tres pasos:

• crear algo que la gente quiera ver;
• crear algo que la gente quiera usar;
• crear algo por lo que la gente quiera pagar.

Me encuentro en el paso 2. La beta está activa, el grupo de prueba está trabajando y el ciclo de retroalimentación está en marcha.

Lo que me enseñaron dos años de experimentación

Tras dos años experimentando con diferentes enfoques, he llegado a una conclusión clara: los fundamentos no han cambiado tanto como muchos creen.

Usted sigue necesitando una línea de producción de software sólida. Es indudable que ha surgido una nueva categoría de herramientas de desarrollo. Sin embargo, el producto final sigue siendo una forma de expresión que depende del criterio humano. En qué medida y de qué forma continúa siendo una decisión del operador humano.

He desarrollado desde plataformas de video bajo demanda hasta analítica para IoT y motores de mundos virtuales. El proceso de producción importa mucho más que las herramientas. Lo que cambió es que las herramientas se volvieron más rápidas.

Escribí sobre este punto en The New Rules: cuando la velocidad de implementación se acerca a cero, la velocidad del pensamiento lo es todo. Esto resultó ser literalmente cierto en mi propio proceso de desarrollo. Las décadas acumuladas de criterio arquitectónico no perdieron valor con la IA. Al contrario, se convirtieron en el cuello de botella - en el mejor sentido posible.

Fase A: desarrollo del núcleo guiado por especificaciones

La fase A requirió dos semanas de ciclos continuos: especificación, refinamiento, código, ajuste y nueva especificación.

La primera semana estuvo dedicada a diseñar el núcleo: las decisiones arquitectónicas fundamentales, el lenguaje de dominio, el mapa de componentes y las pautas cualitativas para el ciclo de vida del programa. Es aquí donde la experiencia genera un interés compuesto. Saber qué abstracciones resistirán el uso real en producción no es algo que se pueda resolver mediante prompts.

La segunda semana se centró en construir las funcionalidades principales: la interfaz gráfica de usuario (GUI), la integración con MCP, la capa de API, el flujo de cognición (enriquecimiento y gestión de contexto) y la transmisión de actividad en tiempo real. El resultado fue un agente operativo con interfaz de chat, un entorno gráfico funcional y una base de software sólida. El ritmo fue de aproximadamente dos iteraciones completas por semana: desde cero hasta un agente en ejecución.

El factor determinante fue que la especificación y la programación se ejecutaron de forma intercalada, no secuencial. Cada iteración de código alimentó la siguiente revisión de la especificación. Cada ajuste en la especificación transformó el código. El desarrollo con IA hizo que este ciclo fuera lo bastante ágil como para ser viable. Lo que habitualmente habría requerido un mes de idas y vueltas se completó en cuestión de días.

Fase B: refinamiento guiado por el usuario

En cuanto hubo un entregable visible, transformé el flujo de trabajo. Se incorporó un grupo de prueba y el ciclo pasó a ser: observar (uso real), definir (necesidad de cambio), aplicar (modificar el programa) y observar nuevamente. Durante cuatro semanas mantuve el mismo ritmo de dos iteraciones por semana, impulsado por las observaciones de usuarios reales.

Lo que no anticipé fue el enorme volumen de oportunidades de mejora que se hicieron evidentes en cuanto personas reales interactuaron con el producto. Junto con la iteración regular de funciones, estuve incorporando continuamente tareas de limpieza técnica: revisiones de consistencia, consolidación de componentes y simplificación del código fuente.

Esto se alinea con lo que vengo exponiendo en The New Rules: cuando la IA puede generar cualquier función, la curaduría supera a la creación. El trabajo difícil no fue construir características nuevas. El verdadero desafío consistió en determinar cuáles mejoras tenían un valor real y mantener la coherencia de la base de código mientras se avanzaba con rapidez. Esa es una labor de criterio profesional. Proviene de años de mantener sistemas a escala, no de un prompt bien elaborado.

Por qué todavía no hay pruebas automatizadas

Omití las pruebas automatizadas durante las primeras fases. Lo hice de manera deliberada.

Sé cómo suena esto viniendo de alguien con un doctorado y publicaciones académicas sobre control de calidad. Dos motivos justificaron esta decisión:

• velocidad de cambio - el código fuente se transformaba con tanta rapidez que el mantenimiento de las pruebas habría generado una carga constante con un beneficio mínimo;
• necesidad limitada de precisión matemática - en esta etapa de desarrollo del producto, la orientación estratégica adecuada importa más que la exactitud formal.

Durante estas fases iniciales descarté cerca de cuatro prototipos tempranos para definir la estructura básica del diseño. La organización de los componentes, los flujos de transmisión y ejecución, el alcance de la cognición y las integraciones secundarias para tareas de mantenimiento: todo pasó por reescrituras profundas.

Mi tesis es la siguiente: resulta más sencillo desenredar el código con un revisor experimentado y un socio de IA que gestionar una suite integral de pruebas a lo largo de múltiples transiciones arquitectónicas. Esto contradice el consenso habitual. Sin embargo, ese consenso fue concebido para un entorno donde reescribir código resultaba muy costoso. Cuando su generador de IA puede reestructurar un módulo completo en minutos, el cálculo cambia radicalmente.

Las pruebas llegarán. La arquitectura se está estabilizando y los cambios estructurales son cada vez menos frecuentes. Forzar la cobertura de pruebas de forma prematura habría frenado el avance sin aportar una seguridad real.

Cuáles son los siguientes pasos

El proceso iterativo se mantiene: observar, definir y aplicar. Sin embargo, cada etapa incorpora mayor automatización y requiere menor supervisión manual. El programa es lo bastante maduro como para que la propia línea de producción necesite una actualización: mayores salvaguardas, más automatización y superior certeza en el proceso de cambio.

He identificado este mismo patrón en toda la industria. A medida que el tiempo de implementación con IA se aproxima a cero, el cuello de botella se desplaza hacia niveles superiores. Primero fue la velocidad para escribir código. Luego, la agilidad en la toma de decisiones. Ahora es el diseño de los procesos.

Compartiré más detalles en un nuevo informe dentro de un par de semanas.

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 está desarrollando software con herramientas de IA en este momento, me gustaría conocer cómo se compara su proceso. La línea de producción es el producto - todo lo demás es simplemente el resultado.