No sé programar y construí una app de salud completa

Hay una app en producción, con usuarios reales, que hace esto: le sacas una foto a tu plato y estima qué estás comiendo y cuánto aporta. Registra tu entrenamiento con progresión de carga. Lleva tus hábitos con rachas. Y cruza todo eso buscando patrones —usando la prueba exacta de Fisher con corrección de Benjamini-Hochberg, para no inventar correlaciones que no existen—.

Se instala en el teléfono y lee tus pasos y tu pulso directamente de los sensores.

Yo no escribí una línea de ese código a mano. Y no es una app de juguete.

Lo que la gente cree que es difícil

Cuando alguien dice “no sé programar”, casi siempre está pensando en la sintaxis: los punto y coma, las llaves, acordarse de cómo se recorre una lista.

Esa parte, hoy, la hace la máquina. Y la hace bien.

Lo que la máquina no hace por ti es lo otro: decidir qué se necesita, qué NO se necesita, en qué orden, con qué reglas de negocio, y —sobre todo— darse cuenta cuando lo que te entregó está mal.

Un ejemplo concreto de por qué esto importa

En la app hay una sección que busca patrones: te dice cosas como “duermes peor los días que entrenas de noche”.

La versión ingenua de eso es fácil de pedir: “busca correlaciones entre mis datos”. Y una IA te la construye en minutos.

El problema es que esa versión está mal, y está mal de una manera que no se nota. Si le das a un computador suficientes variables y lo dejas cruzarlas libremente, va a encontrar patrones. Siempre. Muchos de ellos no existen: son ruido que casualmente se alineó.

Con 20 cruces al azar y el umbral estadístico habitual, esperas un hallazgo falso solo por azar. Con 100 cruces, cinco. Y esos hallazgos falsos se ven exactamente igual que los verdaderos: un gráfico, un porcentaje, una frase que suena convincente.

La solución tiene nombre y es vieja: se define una lista blanca de hipótesis antes de mirar los datos, y se corrige el umbral por la cantidad de comparaciones. En esta app se usa Benjamini-Hochberg.

Nada de eso lo propuso la IA sola. Lo tuve que pedir, porque sabía que el problema existía.

Esa es la habilidad. No la sintaxis.

Qué sí hay que saber

Después de construir bastantes cosas así, lo que de verdad se necesita se reduce a cuatro cosas:

1. Saber describir un proceso completo

Si no puedes explicar cómo funciona algo de principio a fin —quién hace qué, en qué orden, qué pasa cuando falla—, no lo vas a poder pedir. La mayoría de los proyectos que fracasan no fracasan por código malo: fracasan porque nadie tenía claro el proceso.

Esto no es una habilidad técnica. Es la misma que hace falta para escribirle instrucciones a alguien que recién entró a trabajar contigo.

2. Saber qué preguntar cuando algo no calza

Cuando un resultado te sorprende, hay dos reacciones posibles. Una es aceptarlo porque el computador lo dijo. La otra es preguntar por qué.

La segunda es la que salva proyectos. Un número que no calza con tu intuición del negocio casi siempre significa una de dos cosas: o tu intuición estaba mal, o el cálculo estaba mal. Las dos vale la pena averiguarlas.

3. Saber verificar sin depender de quien construyó

Esto es lo que más se salta la gente.

Si te entregan algo y la única prueba de que funciona es que quien lo hizo te dice que funciona, no tienes ninguna prueba.

Verificar significa: abrir la URL y ver el código de respuesta. Correr el caso real, no el de ejemplo. Comparar el archivo publicado con el archivo local. Mirar la captura en el tamaño de pantalla donde va a estar tu cliente, no en la tuya.

4. Conocer tu propio negocio mejor que nadie

Acá es donde la gente que no programa tiene ventaja sobre la que sí.

Yo sé que en mi rubro un cliente abre el sitio desde el celular, en la calle, con señal irregular, y le da tres segundos. Eso no lo aprendí en un curso: lo aprendí perdiendo ventas.

Un desarrollador excelente que no conozca tu negocio va a construir exactamente lo que le pediste. El problema es cuando lo que pediste estaba mal.

Lo que esto cambia para un negocio chico

Hasta hace poco, un negocio chico tenía dos opciones frente a un problema de software: aguantarlo, o juntar varios millones y contratar un desarrollo.

Ahora hay una tercera: describir bien el problema, construirlo, y verificar que funcione. Con un costo que cabe en el presupuesto de un negocio real.

Eso no significa que cualquiera pueda hacer cualquier cosa. Significa que el cuello de botella se movió: antes era el acceso a alguien que supiera escribir código, ahora es el criterio para saber qué pedir y para darse cuenta cuando la respuesta es plausible pero incorrecta.

Y el criterio, a diferencia de la sintaxis, sí se puede traer de tu propia experiencia operando un negocio.

Una advertencia honesta

Nada de esto significa que la IA no se equivoque. Se equivoca todo el rato, y se equivoca de la peor manera posible: con seguridad y con una explicación que suena bien.

Un ejemplo real: si le pides “revisa que esto funcione”, muchas veces te va a decir que funciona. Si le pides “corre este comando específico y pégame la salida”, te vas a enterar de la verdad.

La diferencia entre las dos frases es toda la diferencia entre un proyecto que funciona y uno que parece que funciona.