Una aplicación puede empezar con una necesidad muy pequeña: dejar de repetir el mismo cálculo. En este caso, el proyecto terminó abarcando algo más ambicioso: conectar herramientas de ingeniería eléctrica, aprovechar la IA para desarrollar software y mantener las decisiones técnicas bajo responsabilidad humana. Entre el primer boceto y el envío de la versión 1.0.0 a revisión en Google Play registré 216 horas de trabajo activo. La cifra describe aquella etapa del proyecto; no representa el tiempo que tardaría cualquier persona en desarrollar una aplicación equivalente, ni significa que ese mismo día ya estuviera disponible para el público.

La historia de WattsWise empieza bastante antes de la programación, frente a una situación conocida por quienes trabajan con cálculos técnicos: una hoja de Excel abierta para resolver, otra vez, una operación realizada la semana anterior. Las plantillas existían; lo complicado era recordar cuál correspondía, encontrar su última versión y comprobar que las condiciones iniciales seguían siendo válidas. La familiaridad con la herramienta había terminado ocultando la fricción del procedimiento.

Una calculadora en línea parecía la salida más sencilla, aunque también tenía límites. Cuando una herramienta impone valores de tensión, determinadas convenciones o un recorrido que no coincide con el trabajo real, el problema deja de ser la fórmula: aparece en la distancia entre el cálculo y su contexto. De esa incomodidad nació una pregunta más interesante que «¿cómo automatizar esta operación?». ¿Y si los cálculos habituales compartieran parámetros, conservaran el contexto y evitaran volver a introducir los mismos datos?

El verdadero problema no estaba en Excel

Excel sigue siendo una herramienta extraordinariamente útil para un ingeniero; WattsWise no surgió para sustituir todas las hojas de cálculo, sino para resolver una situación más específica. En una jornada de trabajo, ajustar la potencia de una carga puede obligar a recalcular la corriente y revisar posteriormente la caída de tensión o la corrección del factor de potencia. Si cada herramienta funciona como una isla, una modificación pequeña termina multiplicándose en tareas manuales, copias de valores y oportunidades de error.

El objetivo fue diseñar un conjunto de calculadoras interconectadas: datos compartidos cuando resulte conveniente, posibilidad de modificar parámetros y flexibilidad para trabajar con distintas configuraciones eléctricas. En la ficha pública de WattsWise en Google Play se describen funciones como el cálculo de potencia, la caída de tensión, estimaciones de cortocircuito y otras utilidades eléctricas. Esa ficha sirve para comprobar qué ofrece la aplicación actualmente; no debe interpretarse como un inventario de las funciones que ya estaban completas en su primera versión.

Conviene señalar otro límite: una calculadora que permita introducir tensiones, frecuencias o unidades distintas no certifica automáticamente el cumplimiento de una norma. El cálculo físico es una parte del trabajo; seleccionar los criterios de diseño, verificar las hipótesis y comprobar las exigencias reglamentarias aplicables sigue siendo responsabilidad de quien utiliza los resultados.

La IA ayudó a escribir el software; no podía decidir qué debía ser correcto

El salto desde las hojas de cálculo hacia una aplicación implicó una dificultad diferente. Conocía el dominio eléctrico y podía definir las relaciones matemáticas, las reglas de negocio y los casos en que una respuesta dejaría de ser útil. Lo que faltaba era convertir ese conocimiento en una interfaz y en una arquitectura de software sin organizar, desde el primer día, un equipo tradicional de desarrollo.

Ahí entró el desarrollo asistido por IA. El proyecto utilizó Flutter y un flujo de trabajo con dos funciones complementarias: un ejecutor, que implementaba dentro de los límites establecidos, y un auditor, que revisaba los resultados. Las discrepancias detectadas regresaban al ciclo de corrección; la decisión de aceptación seguía siendo humana. No eran sustitutos de la ingeniería ni una garantía automática de calidad; eran una manera de distribuir el trabajo mientras conservaba el control sobre los requisitos y las decisiones finales.

La distinción parece menor hasta que aparece un resultado perfectamente compilado que responde a una pregunta equivocada. Una operación puede estar bien escrita y, aun así, utilizar una hipótesis eléctrica incorrecta; una pantalla puede funcionar, pero perder un dato que debía compartirse con el siguiente módulo. Por eso, la pregunta decisiva no era si el agente había terminado de programar, sino qué evidencia permitía aceptar el comportamiento obtenido. Es una diferencia que también desarrollo en «La IA no elimina la ingeniería; la obliga a volverse más explícita».

En un proyecto Flutter, las pruebas unitarias, de componentes y de integración ofrecen niveles de verificación distintos. Su documentación oficial ayuda a entender qué puede comprobar cada tipo de prueba; no demuestra, por sí sola, qué cobertura alcanzó WattsWise durante aquel desarrollo. La lección práctica fue establecer una separación entre generar una solución, revisarla y decidir si satisfacía los criterios técnicos del producto.

Una arquitectura necesita memoria, no solo conversaciones

A medida que aparecían módulos nuevos, resultaba evidente que cada corrección debía tener consecuencias más allá de la pantalla donde se descubría. Las fórmulas, las unidades y las reglas para compartir datos no podían depender de que un agente recordara una explicación anterior; tenían que convertirse en decisiones explícitas que sobrevivieran al siguiente cambio.

El esquema ejecutor–auditor ayudaba a identificar errores, pero también tenía un coste: revisar una y otra vez la misma ambigüedad no aporta valor. Por eso, el aprendizaje más duradero no consistió en multiplicar agentes, sino en conservar mejor el conocimiento que necesitaban para trabajar: requisitos, convenciones, restricciones, criterios de aceptación y resultados de las revisiones. La experiencia conecta con otra cuestión abordada en «¿Más agentes o mejores especificaciones?»: la coordinación funciona mejor cuando lo importante no se pierde en cada transferencia de contexto.

Existe un paralelo interesante, aunque el contexto y la escala sean diferentes: el informe DORA de 2025 sobre desarrollo de software asistido por IA describe la IA como un amplificador de las fortalezas y debilidades preexistentes de una organización. No se trata de utilizar ese estudio para validar el rendimiento de un proyecto individual, sino de reconocer un principio útil: acelerar la ejecución no corrige por sí solo una definición incompleta del problema.

¿Qué significan realmente las 216 horas?

El registro comenzó con el primer boceto conceptual y terminó cuando se envió WattsWise 1.0.0 a Google Play Console para su primera revisión. Incluyó trabajo activo de definición, arquitectura, lógica principal, interfaz y marca; quedaron fuera los periodos pasivos de espera. De ese registro nació el nombre de Studios216 y una forma de recordar el origen del proyecto.

El artículo original proponía una comparación ilustrativa: frente a las 216 horas registradas para alcanzar aquel primer hito, contemplaba un escenario de desarrollo tradicional de unas 800 horas y un presupuesto de USD 50.000. Las dos últimas cifras procedían de una estimación de planificación, no de una comparación controlada entre productos equivalentes con el mismo alcance, calidad, tarifas y personal. Sirven para dimensionar la inversión que podría exigir otra forma de ejecutar el proyecto, pero no para calcular un porcentaje de ahorro universal. Las 216 horas son un registro del proyecto; las 800 horas y los USD 50.000 son supuestos ilustrativos, no promedios medidos del sector.

Importa distinguir tres cosas que a menudo aparecen mezcladas en las historias de emprendimiento tecnológico: horas de trabajo registradas, dinero externo invertido y coste económico total. WattsWise se desarrolló sin capital externo durante aquella etapa; eso no convierte en gratuitos el tiempo propio, los equipos, los servicios o el aprendizaje. Tampoco permite afirmar, sin un proyecto comparable y una metodología común, que se ahorró un porcentaje universal frente a una agencia tradicional.

El hito de las 216 horas fue, además, el envío a revisión, no una publicación instantánea. Google explica que el proceso de revisión y la disponibilidad pública son estados diferentes. Actualmente WattsWise cuenta con una ficha pública en Google Play, pero esa disponibilidad posterior no modifica el alcance del registro inicial.

¿Fue rápido para el tipo de trabajo realizado? Esa es una lectura razonable de la experiencia personal; convertirla en un récord, una comparación de mercado o una promesa reproducible para terceros requeriría evidencia distinta. El dato vale más cuando se explica su perímetro que cuando se transforma en un eslogan imposible de comprobar.

El resultado visible y la lección menos evidente

WattsWise acabó siendo una aplicación de cálculo eléctrico con herramientas que comparten información y permiten abordar tareas relacionadas sin reconstruir todo el recorrido desde cero. Su evolución posterior amplió el alcance inicial; quien quiera conocer las funciones disponibles hoy puede consultar la descripción actual de la aplicación. No todas las decisiones de diseño fueron definitivas desde la primera versión, ni toda característica mencionada en la ficha actual formaba parte necesariamente de aquel primer envío.

Sin embargo, el aprendizaje que dio origen a Studios216 fue más allá de una aplicación. La IA puede reducir considerablemente la distancia entre una idea técnica y una primera implementación; esa aceleración resulta especialmente interesante cuando existe conocimiento profundo del problema. Lo que no desaparece es la necesidad de decidir qué construir, qué comprobar, qué corregir y cuándo aceptar el resultado. Ese mismo tránsito —de una idea a algo que debe mantenerse— aparece, desde otra perspectiva, en «De una idea a un producto funcional».

Al principio parecía que la historia consistiría en abandonar varias hojas de Excel y obtener una aplicación. En realidad, el cambio fue de método: transformar conocimiento técnico repetido en un sistema reutilizable, apoyarse en la IA para acelerar la ejecución y conservar la responsabilidad de ingeniería allí donde siempre debió estar. Las 216 horas explican cuánto duró una etapa; las decisiones tomadas durante ese tiempo explican por qué merecía la pena contarla.