Generar código no es avanzar

Generar código no es avanzar. Un programador, o una IA, puede escribir miles de líneas en una tarde y dejar tu problema exactamente donde estaba. Un proyecto de software avanza cuando alguien de tu empresa hace hoy, con la aplicación, algo que ayer hacía a mano. Todo lo demás es movimiento. Y el movimiento, visto desde fuera, se parece mucho al avance.

Te lo digo desde dentro, porque yo he caído.

¿Qué es esa "falsa sensación de productividad" con la IA?

Es la sensación de estar haciendo muchísimo cuando en realidad estás haciendo poco que importe. Y trabajar con IA la dispara.

Te cuento mi caso. Hubo una temporada en la que tenía siete terminales abiertas a la vez, cada una con un agente de IA haciendo una tarea distinta. Uno arreglaba un fallo, otro montaba una pantalla, otro revisaba un informe. Antes de terminar de repartirle trabajo al séptimo, el primero ya me estaba avisando: acabé, mándame más.

Se lo conté a un compañero, medio orgulloso. Y resulta que no era el único.

Me levantaba de la silla y pensaba: si hace diez minutos que tenía que ir al baño, por qué no he ido. Tenía que hacer la comida y decía "espera, que acabo una cosa". La dopamina que a otros les da el móvil a mí me la daba lanzar tareas.

Pues al final de muchos de esos días, si me preguntabas qué había cambiado para el cliente, la respuesta honesta era poco.

¿Por qué hacer treinta tareas no es avanzar treinta pasos?

Porque las tareas no valen por sí mismas. Valen si te acercan a un objetivo que alguien ha definido antes de empezar.

Una IA te puede generar cosas infinitas. Es un saco sin fondo. Le pides una pantalla y te hace una pantalla. Le pides otra y te hace otra. Nunca te va a decir "oye, esto no hace falta".

La pregunta que importa no es cuánto se ha hecho, sino si se ha cumplido el hito. Si al terminar las treinta tareas la recepcionista ya puede dar una cita sin abrir la libreta, has avanzado. Si no, da igual cuántas tareas fueran. No estás ni cerca.

Esto vale para mí y vale para cualquiera que te haga un programa. Con IA o sin ella.

¿Cómo lo notas tú si le has encargado un programa a alguien?

Lo notas en qué te enseñan cada semana. Si te enseñan cosas que puedes usar, avanza. Si te enseñan cosas que solo puedes mirar, cuidado.

Hay proveedores que te mandan informes larguísimos. Tantas horas, tantas funciones, tantos cambios. Suena a mucho trabajo, y seguramente lo es. Pero tú no compras trabajo. Compras que tu empresa funcione mejor.

Estas son las señales que yo miraría si fuera tú:

• Cada semana puedes tocar algo. No una presentación. Algo que abres, pulsas y hace lo que tiene que hacer.
• Te hablan en tu idioma. "Ya puedes registrar un albarán y sale firmado", no "hemos terminado el módulo de entidades".
• Hay una fecha para usarlo de verdad. Con tu equipo, con datos reales, aunque sea una sola parte.
• Te preguntan cosas. Quien no te pregunta nada en tres semanas está construyendo lo que él cree, no lo que tú necesitas.
• Te dicen que no a algo. Si todo lo que pides entra, nadie está pensando en qué importa.

Si un mes después de empezar no hay nada que tu equipo pueda usar, algo va mal. Da igual lo ocupado que se vea tu proveedor.

¿Entonces es mejor no usar IA para programar?

No. El que no usa la IA y el que la usa sin freno acaban en el mismo sitio, que es no avanzar.

El que no la usa va lento. El que la sobreusa va rapidísimo en todas direcciones a la vez, que para el caso es lo mismo. Hacer mucho sin valor es prácticamente no hacer nada.

Yo la uso todos los días y no pienso dejar de hacerlo. Lo que cambié fue la forma. Ahora trabajo por roles. Un agente hace de jefe de proyecto y reparte. Otro programa. Otro revisa que lo hecho funciona. Cuando los tres dan el visto bueno, lo reviso yo. Y solo entonces se enseña.

Lo que no funciona es lo contrario. Sentarse y decir "venga, vamos a hacer una aplicación con pacientes, contabilidad, administración y un chatbot". Ahí es cuando se te va la olla. Sale mucho código y ninguna herramienta.

La IA es un multiplicador. Multiplica lo que ya sabes hacer. Si sabes qué hay que construir y en qué orden, te multiplica eso. Si no lo sabes, te multiplica el desorden.

¿Qué es un buen hito en un proyecto de software?

Un buen hito es algo que una persona concreta de tu empresa puede hacer con la aplicación, un día concreto, sin ayuda. Así de simple.

Ejemplos de hitos que sí sirven:

1. El repartidor firma el albarán en el móvil y en la oficina aparece al momento.
2. La recepcionista ve en una pantalla los huecos libres de las tres sedes.
3. El recordatorio de la cita sale solo el día antes y el paciente puede confirmar con un botón.
4. El dueño abre el panel por la mañana y ve lo facturado ayer sin preguntar a nadie.

Y ejemplos de hitos que no sirven, aunque suenen técnicos:

• "Base de datos terminada."
• "Diseño aprobado al 80 %."
• "Integración iniciada."

Ninguno de esos cambia tu mañana. Pueden ser pasos necesarios, claro. Pero no son avance hasta que se convierten en algo de la primera lista.

Por eso en mis proyectos defino los hitos la primera semana, antes de escribir una línea. Y los defino con quien va a usar la aplicación, no solo con el dueño. Si quieres ver cómo se traduce esto en un caso real, mira el ejemplo de una distribuidora de alimentación: cada pieza se mide por lo que deja de hacerse a mano, como los tres días de cada mes pasando albaranes a facturas.

¿Y si el que está siempre ocupado eres tú?

Pues te aplica lo mismo. Y esto es lo que más me costó ver.

El que siempre está ocupado, el que no tiene ni cinco minutos para una llamada, casi siempre se organiza mal. No hay más. Me incluyo, que llevo mucho tiempo trabajando doce o catorce horas al día y me da hasta vergüenza decirlo.

En una pyme pasa igual. El dueño que contesta WhatsApp a las once de la noche, que hace él las facturas porque nadie más sabe, que está en todo. Parece que avanza porque no para. Pero lleva tres años con los mismos problemas.

Si te reconoces, antes de comprar ningún programa haz esto. Para. Apunta qué procesos se repiten cada semana. Mira cuál te come más horas. Y empieza por ese, uno solo. Te lo explico con más calma en qué automatizar primero en tu empresa.

¿Por qué un proyecto pequeño y enfocado gana a uno grande?

Porque un proyecto pequeño tiene que elegir. Y elegir es lo que hace avanzar.

Mi propio SaaS me llevó tres meses con el foco puesto. Algo parecido, hace unos años, habría necesitado un equipo de cinco personas durante dos años. La diferencia no fue solo la IA. Fue saber qué no hacer. Lo cuento entero en tres meses contra dos años y cinco programadores.

Cuando alguien te enseñe cuánto ha hecho, pregúntale qué puedes usar ya. Esa respuesta vale más que cualquier informe. Y si quieres que miremos juntos por dónde empezaría tu proyecto, reserva una llamada de 30 minutos y lo vemos con tus procesos delante.