Lo armaste con IA. ¿Y ahora?

Hasta hace poco, quien tenía una idea para una aplicación y no sabía programar tenía un solo camino: buscar a alguien que la construyera. Hoy hay otro. Con IA, una persona sin conocimientos técnicos puede armar una primera versión por su cuenta, probarla, cambiarla y volver a probarla, sin pagarle a nadie por cada iteración.

Puede ser un buen camino. Las primeras versiones de cualquier idea cambian mucho, y hacer esas iteraciones por cuenta propia es más barato y en general más rápido que explicárselas a un tercero. Muchas ideas se validan o se descartan así.

El problema no está en empezar solo. Está en seguir solo cuando lo que se armó empieza a ser otra cosa.

En el último tiempo escuché a dueños de empresas decir, medio en broma, que si el proveedor tarda mucho, lo hacen ellos con IA. Y algo de razón tienen: la primera versión la pueden armar. Lo que desde afuera no se ve es la distancia entre esa versión y una que puedan usar sus clientes: quién entra a qué, qué pasa si se cae, quién la sigue cuando haya que cambiarla. Esa parte sigue llevando tiempo, con IA o sin ella.

Algunos ya lo hicieron, y empiezan a aparecer pedidos de empresas que armaron su aplicación con IA y ahora buscan presupuesto para “lo que falta”. Muchas veces hay botones en la pantalla sin nada detrás, o funciones que nadie pidió. Y la pregunta que traen es si conviene seguir con lo que hay o hacerlo de nuevo. Lo que falta no se puede presupuestar sin saber antes qué hay.

Aunque funcione, no siempre está bien

Una aplicación armada con IA puede verse bien en la pantalla y tener problemas que desde ahí no se ven. En los últimos años, la IA mejoró mucho en escribir código que anda. Lo que no siempre hace es escribirlo seguro. En su informe de 2026, Veracode probó código generado por más de cien modelos, y en el 44% de las pruebas el código introdujo fallas de seguridad conocidas, casi lo mismo que un año antes.

Estas fallas también pueden aparecer en aplicaciones hechas por alguien con conocimientos técnicos, con IA o sin ella. La diferencia es que esa persona conoce estos riesgos y el contexto: qué datos maneja la aplicación, quién la va a usar, qué pasa si falla. Con eso puede trabajar para evitarlos o achicar su impacto. A veces no lo logra, pero las fallas son menos probables. Cuando una aplicación la arma con IA alguien que no es técnico, muchas decisiones técnicas las toma la herramienta sin ese contexto, porque quien la armó no sabía que tenía que dárselo. Y después no sabe cuáles fueron ni tiene cómo verlas. Por ejemplo:

• Quién puede ver los datos. Si otra persona, cambiando algo en la dirección de la página, puede ver la información de otro cliente.
• Las claves. Si las contraseñas de los servicios que usa la aplicación quedaron escritas en el código, a la vista de cualquiera que acceda a él.
• Las piezas de terceros. Casi toda aplicación usa componentes que no escribió nadie del proyecto. Algunos pueden tener fallas conocidas, o no tener a nadie que los mantenga.
• Las copias de seguridad. Si existen, dónde están, y si alguna vez se probó recuperarlas.
• Si alguien más puede seguirla. Si mañana hace falta que otra persona la continúe, si va a entender qué se hizo y por qué.

Nada de esto se nota mientras la aplicación corre en la computadora de quien la armó. Se nota cuando está en internet, aunque la siga usando una sola persona.

Casos así ya empezaron a salir en las noticias. En octubre se viralizó el de una cadena de cafeterías cuyo director venía contando en público que programaba con IA: un panel interno que parecía protegido con usuario y contraseña dejaba ver datos de franquiciados y cifras de la empresa a cualquiera que tuviera la dirección. Fallas como esta suelen ir más allá de lo técnico, porque terminan afectando al negocio: reclamos, incluso legales, cuando hay datos personales, daño a la reputación y clientes que se van.

Pueden quedar ahí, sin que nadie las note, hasta que alguien las encuentra. Y la misma IA que sirve para armar una aplicación también sirve para armar una herramienta que le busque fallas. Hasta hace poco, eso era cosa de especialistas. Hoy lo puede intentar mucha más gente, y no toda con buenas intenciones.

Cuándo conviene que alguien la mire

No hace falta revisar cada prueba. Pero hay momentos en que seguir sin que nadie la mire deja de ser una decisión razonable:

• Cuando se publica en internet, aunque la use solo quien la armó.
• Cuando la empiezan a usar personas reales, sobre todo clientes.
• Cuando guarda datos sensibles: datos personales, financieros o de salud.
• Cuando cobra, o maneja dinero de alguna forma.
• Cuando se va a sumar alguien a trabajar en ella.
• Cuando da miedo tocarla, porque cada cambio rompe otra cosa.

Cualquiera de esos momentos cambia lo que está en juego. Mientras es una prueba, una falla cuesta un rato de trabajo. Después, puede costar datos, plata o la confianza de los clientes.

Qué se decide después de revisarla

Una revisión que termina en una lista larga de problemas técnicos no le sirve a quien no es técnico. Tiene que terminar en una decisión y un plan:

• Qué se puede seguir usando como está, qué hay que arreglar antes de crecer, y qué conviene rehacer.
• Cuánto vale la pena invertir. Depende de lo que el negocio espera de la aplicación. Si todavía se está probando la idea, tal vez no haga falta arreglar todo lo que se encontró. Si la empresa ya trabaja con ella todos los días, hasta una aplicación simple puede necesitar arreglos urgentes.
• En qué orden. Lo que expone datos o dinero va primero. Lo que es incómodo pero no riesgoso, después.
• Qué puede esperar. No todo lo que se encuentra hay que resolverlo ya, y saberlo también ahorra plata.

Rehacer todo no tiene que ser la respuesta automática. Muchas veces lo armado tiene partes que funcionan bien, y lo que hace falta es arreglar pocas cosas en el orden correcto. Es la misma pregunta que planteo en “Hay que hacerlo todo de nuevo”: antes de tirar algo, entender qué tiene.

Y conviene que el plan diga también cómo seguir construyendo, para que lo que se arregle no se vuelva a romper con la próxima vuelta de la IA: qué reglas sigue el código, qué se prueba antes de cada cambio. Es lo que desarrollo en Vibe coding: rápido para empezar, caro para sostener.

Empezar solo, crecer acompañado

La IA le dio a mucha gente la posibilidad de probar una idea sin depender de nadie. Es una buena noticia, y no hay motivo para dejar de hacerlo.

Lo que no conviene es que la primera persona que mire la aplicación con criterio técnico llegue después del primer problema serio. Revisarla antes de crecer cuesta mucho menos que arreglarla con clientes adentro.

Después, lo que deja la revisión hay que hacerlo, y alguien lo tiene que hacer. En una empresa sin área de sistemas, esas horas suelen salir de quien armó la aplicación, que ya tiene otro trabajo: el de su negocio. Si arreglarla y sostenerla le empieza a sacar tiempo para eso, aparece la misma pregunta que con cualquier tarea que no es el centro del negocio: seguir haciéndola por cuenta propia o encargársela a alguien que se dedique a eso. Con una diferencia: ahora hay una primera versión que ya se revisó y se sabe qué le falta, así que el presupuesto se puede pedir sobre una lista concreta.