La ilusión de la velocidad en desarrollo

Se cierra un nuevo sprint de trabajo, se cierra una semana, y llega el momento de enfrentarte al backlog, de ver cuántas tareas cerraste, cuántos puntos de historia quemaste, cuántos hicieron los demás.

Repasás mentalmente las horas invertidas frente a la pantalla y te aparece otra vez esa sensación de que no fuiste lo suficientemente productivo porque te demoraste «un poco más de tiempo» en resolver un cambio que, en los papeles, parecía trivial.

Es una trampa psicológica compartida. Cuando sos Junior, la sobreexigencia te hace creer que un desarrollador de verdad resuelve problemas de manera lineal, limpia y, sobre todo, veloz.

A medida que sumás años de experiencia, aprendés a convivir con esa fricción. Entendés que los sistemas reales son caóticos, que tenemos reuniones, que surgen imprevistos, que hay bugs, que también tenemos una vida aparte de nuestro trabajo. Pero, seamos honestos: en el fondo, la duda siempre vuelve y tenemos que lidiar con ella más veces de las que nos gustaría admitir.

Y más hoy. En el contexto actual, rodeados de asistentes de inteligencia artificial capaces de largar doscientas líneas de código en diez segundos, la presión por la velocidad se volvió asfixiante (a veces es una presión impuesta por nosotros mismos, eh. La autoexigencia puede ser difícil). Sentís que, teniendo estas herramientas a mano, deberías volar. Y si te demorás analizando un error, aparece todavía más culpa: ¿Por qué no avanzo incluso si tengo una IA al lado? ¿Cómo hacen los demás?

La paradoja del tiempo invisible y la falsa solución

Consideremos un escenario común en nuestro trabajo. Te asignan modificar un flujo de facturación en un módulo heredado que lleva acoplada lógica de negocio de tres años atrás. Tenés dos caminos.

El primer camino es el que elegimos cuando la ansiedad por la velocidad nos gana. Abrís el asistente de IA, pegás el método gigante de 300 líneas y le pedís que te agregue la nueva regla tributaria.

La IA lo hace en segundos. Genera código nuevo, duplica un par de condiciones para no «romper lo viejo» y te lo entrega empaquetado. Lo pegás, tirás un par de pruebas locales básicas, el flujo pasa y metés el Pull Request en veinte minutos.

El tablero Jira se mueve, «te sacaste un peso de encima».

Pero cuando cerrás la computadora al final del día, te queda un vacío horrible en el pecho. Sabés perfectamente que no tenés idea de lo que hiciste. Copiaste, pegaste, funcionó por descarte, pero si mañana se cae ese entorno o necesitás explicarlo, no sabrías por dónde empezar a buscar. Entregaste velocidad a cambio de tu propia confianza técnica.

El segundo camino es el de la ingeniería real. Decidís frenar la pelota. Te das cuenta de que si metés ese parche rápido de la IA, podés romper la consistencia de las transacciones con la base de datos o vas a generar un efecto secundario en el cálculo de impuestos diferidos. Pasás cuatro horas rastreando la ejecución de un bean de Spring mal configurado, depurando un hilo de ejecución que nadie documentó y entendiendo el ciclo de vida de la entidad de Hibernate para no reventar la memoria.

Al final del día, tu producción neta visible es mínima: cambiaste una sola línea de configuración en un archivo .properties o borraste cincuenta líneas de lógica duplicada. Si evaluás tu jornada bajo el sesgo del volumen, cerrás el IDE frustrado, sintiendo que te estancaste y comparándote con tu compañero de equipo que hoy dejó 3 PRs abiertos.

Pero analicemos el mediano plazo: el código de veinte minutos va a fallar en producción dentro de tres meses cuando el volumen de peticiones duplique su escala, obligando al equipo a apagar incendios un domingo a la madrugada. Tu línea de configuración de cuatro horas evitó ese escenario. El código escrito no es el trabajo del ingeniero; es simplemente el subproducto físico de tu pensamiento.

El desacople entre “escribir código” e ingeniería

Medir tu rendimiento por la velocidad de entrega asume que el desarrollo de software es un problema de tipeo. Si así fuera, nuestra carrera ya estaría perdida contra cualquier modelo de lenguaje moderno, ¿te pusiste a pensar en eso?

La inteligencia artificial es imbatible en volumen y podemos apalancarnos en eso para ser realmente más productivos. O más rápidos y cansarnos menos, sería la expresión correcta.

Pero tiene un gran problema, y es que carece de contexto. No entiende las sutilezas grises de las reglas de negocio de tu empresa y, fundamentalmente, no asume la responsabilidad del mantenimiento a largo plazo.

Cuando aceleramos para acallar la inseguridad o para demostrar que «somos rápidos», lo que estamos haciendo es usar la IA como un escudo “analgésico”. Le delegamos nuestro criterio para sacarnos la papa caliente de encima.

El senior no es el que programa más rápido porque sus dedos se mueven mejor en el teclado. Es el que aprendió a sostener la tensión de la demora. Es el que sabe plantarse en una reunión de planificación y decir: «No voy a tocar esa clase hasta que no entienda cómo afecta al resto del ecosistema».

La confianza técnica no se construye entregando código a ciegas para parecer eficiente, sino sabiendo defender el tiempo que requiere un análisis serio.

Hacia un criterio propio de productividad (y una salida a la ansiedad)

Para romper este ciclo de comparación constante y ansiedad por la velocidad, cosa que es muy normal en nuestro ambiente, el crecimiento profesional exige cambiar las preguntas que nos hacemos al terminar el día.

Si pasaste la tarde leyendo código o entendiendo por qué la IA te proponía una solución absurda, no perdiste el tiempo. Hiciste ingeniería (andá a saber, quizás hasta aprendiste algo nuevo en el proceso).

El apoyo que necesitás para sumar confianza no viene de ganarle en velocidad a una máquina o a un compañero, sino de validar tu propio proceso de pensamiento.

Mañana, cuando la prisa te tiente a copiar y pegar sin entender, respirá y mové el foco de la cantidad a la calidad de tu intervención:

• Dejá de preguntarte: ¿Cuántos tickets cerré esta semana?
• Empezá a preguntarte: ¿Cuántos problemas futuros evité al comprender el contexto antes de escribir código? ¿Entiendo realmente el flujo de lo que acabo de subir? ¿Hice lo mejor que pude?

Aprender a pensar antes de programar

La solución a este problema, en parte, viene con la experiencia, aunque como te dije antes, es algo con lo que vamos a tener que convivir siempre.

Compararse con un compañero nunca tiene sentido. Cada uno es como es y tiene su valor en distintos aspectos. Si entendés que trabajamos en equipo, no deberías pensar en que uno tiene que ser mejor que otro, sino en que todos colaboran en lo que pueden y a su manera por el bien común.

Y por otro lado, podemos cambiar el foco sobre la IA para que nos ayude. Ya está acá y no se va a ir. Está en nosotros usarla para lo correcto.

El secreto está en aprender a apalancarte bien en ella, haciendo un uso inteligente que potencie tu criterio en lugar de anularlo. Tenés que perderle el miedo a la herramienta, dejar de usarla como un generador de parches de emergencia para tapar la prisa y empezar a usarla como un mentor que desafíe tus propias soluciones, que te enseñe, que te mejore y te haga ser más productivo por los motivos correctos.

Aprender a gestionar esa ansiedad y a construir ese balance es un proceso largo que, lamentablemente, no nos enseñan en ningún bootcamp.

Y ya en tema, aprovecho para contarte que tengo un libro en donde hablo más sobre nuestra relación con la IA en el trabajo: “El desarrollador inteligente”.

No lo escribí como un manual de sintaxis aburrido ni como una guía de hacks rápidos de Spring Boot, sino que, en base a mi experiencia, decidí plantearlo como un mapa conceptual para desarrolladores backend Java que quieren aprender a liderar su propio desarrollo en esta nueva era; personas que quieren sacarle el máximo provecho a la IA para ser más estratégicos, pero sin regalarle jamás nuestro activo más valioso: el pensamiento de ingeniería y el criterio técnico.

Si sentís que la velocidad te está ganando la carrera mental, que entregás tareas pero no confianza, te invito a leerlo; seguro puede ayudarte a incorporar conceptos que, a corto plazo, te sirvan para sentirte más seguro en el día a día.

Si te interesa, los links de mis libros y recursos están disponibles en mi perfil.