Seis meses. Ese es, en la práctica, el tiempo que le toma a un ingeniero senior pasar de evaluar cada sugerencia de un asistente de código con IA por separado a integrarlo en su flujo de trabajo sin pensarlo dos veces. En ese proceso pasa algo que las métricas de productividad no capturan bien.
Líneas de código por hora, tiempo de cierre de un ticket, tasa de aceptación de sugerencias: son métricas reales, pero describen un efecto superficial. La velocidad es un subproducto. El cambio más significativo es cognitivo: qué tienes que mantener en tu cabeza, qué puedes delegar y a dónde termina yendo tu atención como resultado.
Esto no es un argumento de que los asistentes de código con IA son transformadores en un sentido que cambia lo que es la ingeniería en su esencia. Es una observación más concreta: los ingenieros que más provecho sacan de estas herramientas no son los que menos teclan. Son los que aprendieron a usar el asistente para comprimir las partes de bajo valor del trabajo, de modo que las partes de alto valor reciban más atención real. Esa es una propuesta de valor diferente a la productividad y requiere un modelo mental diferente para aprovecharse bien.
El enfoque de carga cognitiva es más útil que el enfoque de velocidad
Cuando estás escribiendo software no trivial, una parte significativa de tu memoria de trabajo en cualquier momento está ocupada por cosas que no son el problema central. La sintaxis específica de una API que usas poco. La estructura de boilerplate de un archivo de tests. La firma exacta de una función tres archivos más allá. El formato de mensaje de error que espera el framework de logging de tu equipo. Nada de eso es interesante, pero todo ocupa espacio, y ese espacio tiene un costo: atención que podría estar en la decisión de arquitectura, en el edge case, en la interacción que no está cubierta por el spec.
Un asistente de código con IA bien integrado maneja una parte significativa de esa capa inferior. No perfectamente, y no sin requerir atención propia, pero lo suficientemente bien como para cambiar, con el tiempo, la textura del trabajo. Pasas menos de tu cognición disponible en la recuperación mecánica y más en las partes del problema que realmente requieren tu criterio y contexto específico. Para los ingenieros cuyo trabajo principal es precisamente ese criterio, el cambio se acumula.
Todo esto vale solo si la herramienta es lo suficientemente confiable, en tu contexto específico, como para que monitorear su output no cueste más atención de la que ahorra. Un asistente que genera código plausible pero sutilmente incorrecto en un dominio con el que estás menos familiarizado crea una carga de verificación que puede superar fácilmente el beneficio. El enfoque de carga cognitiva funciona en ambas direcciones.
Cómo evoluciona realmente la relación con la herramienta
Hay una diferencia significativa entre cómo alguien usa un asistente de código con IA en su primer mes y cómo lo usa después de seis meses de trabajo constante en el mismo codebase. La fase inicial se caracteriza por una experimentación tentativa: aceptar sugerencias en completados simples, pedir ocasionalmente que se genere una función a partir de un comentario, sorprenderse cuando funciona y desconfiar cuando no. La herramienta se siente como una entidad separada que hace sugerencias que evalúas a distancia.
La fase posterior, cuando se desarrolla, se ve diferente. El modelo mental de cuándo la herramienta es confiable se construyó a través de la repetición. El flujo de trabajo se adaptó para apoyarse en el asistente en los escenarios donde consistentemente es fuerte y para evitarlo donde consistentemente falla. La interacción deja de ser una evaluación de sugerencias individuales y se parece más a trabajar con un colaborador cuyas fortalezas y puntos ciegos ya conoces, que es más o menos como los ingenieros con experiencia piensan en cualquier miembro del equipo.
Los patrones que tienden a aparecer en ese uso más desarrollado incluyen:
- Recuperación de contexto: volver a una parte del codebase que no has tocado en meses y usar la herramienta para reconstruir el contexto relevante más rápido de lo que lo obtendrías leyendo el código solo.
- Borrador y refinamiento: dejar que el asistente produzca un primer pase en algo estructuralmente predecible y luego aplicar tu criterio a las partes que requieren decisiones de diseño reales.
- Rubber duck con memoria: usar el chat para pensar en voz alta sobre un problema, no para obtener la respuesta, sino para externalizar el razonamiento y detectar brechas que no son visibles cuando todo está solo en tu cabeza.
- Generación dirigida en terreno desconocido: usar el asistente para producir algo en una librería o framework que conoces menos, aceptando que necesitarás verificarlo, pero consiguiendo un punto de partida que comprime el tiempo hasta algo funcional.
Ninguno de estos patrones trata la velocidad como un fin en sí mismo. Todos tienen que ver con dirigir la atención más deliberadamente.
Qué no cambia y no debería cambiar
Las partes de la ingeniería que requieren criterio contextual profundo no se vuelven más fáciles porque tengas un asistente de código con IA. Entender por qué un sistema se comporta de forma inesperada en producción requiere conocer el sistema. Decidir si una arquitectura propuesta va a aguantar cuando los requerimientos cambien requiere experiencia con arquitecturas que no lo hicieron. Reconocer que una solución técnicamente correcta va a crear problemas de mantenimiento para el equipo en seis meses requiere conocer al equipo. El asistente no tiene ninguno de ese contexto, y darle el contexto suficiente para que produzca algo útil en esos problemas suele costar más esfuerzo que pensar el problema por tu cuenta.
También hay un riesgo real cuando los ingenieros dejan de ejercitar las habilidades de recuperación y reconocimiento de patrones de bajo nivel porque la herramienta las maneja. La familiaridad con sintaxis y APIs parece trivial, pero la codificación profunda de esas cosas es parte de lo que permite el pensamiento fluido de alto nivel sobre problemas complejos. Externalizar la mecánica por completo, en vez de selectivamente, es un trade-off que vale la pena hacer conscientemente, especialmente al inicio de la carrera o en un dominio nuevo.
Los ingenieros que usan bien estas herramientas son los que siguen claramente a cargo del trabajo. El asistente genera opciones; el ingeniero toma decisiones. Esa es una postura diferente a dejarse llevar por lo que produce el asistente, y mantenerla requiere más participación activa de lo que el enfoque de productividad sugiere.
Para saber si tu propio uso del asistente ya maduró, o si el de un candidato en una entrevista lo hizo, estas señales dicen más que cualquier respuesta genérica:
- Puede nombrar con precisión qué tareas delega en el asistente y en cuáles no confía en él, con ejemplos concretos.
- Explica por qué distingue esos casos, no solo que los distingue.
- Sigue revisando el output del asistente en los dominios donde ya lo vio equivocarse antes.
- Su equipo tiene, o tuvo, una conversación explícita sobre qué herramientas usa y con qué expectativas de revisión, en lugar de una política por defecto adoptada sin discusión.
En Howdy trabajamos con ingenieros senior de toda LATAM que se unen a equipos de producto en EE. UU. donde ese tipo de cultura de ingeniería intencional es la norma, no la excepción. Si ese es el entorno donde haces tu mejor trabajo, la conversación empieza en howdylatam.com.
Para ir más fondo en ese cambio cognitivo, acá encontrás tácticas concretas sobre cómo usar IA para ser mejor developer, no solo más veloz.
Si todavía estás evaluando qué herramienta suma más a tu workflow, acá analizamos las principales opciones desde la perspectiva de ingenieros que las usan en producción.
