El enfoque de productividad alrededor de los asistentes de código con IA siempre ha sido un poco inexacto. Líneas de código por hora, tiempo de cierre de un ticket, tasa de aceptación de sugerencias de autocompletado: todas son métricas reales, pero describen un efecto superficial. Pasan por alto el cambio más interesante que ocurre cuando un ingeniero con experiencia integra una de estas herramientas en su trabajo diario a lo largo del tiempo. 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.
La señal que esto envía en un contexto de contratación
La forma en que un ingeniero habla sobre su uso de estos asistentes en una entrevista o conversación de contratación es cada vez más una señal relevante, en ambas direcciones. Los ingenieros que tienen una visión matizada y basada en experiencia de dónde estas herramientas agregan valor y dónde no demuestran el mismo tipo de pensamiento crítico que se aplica a cualquier decisión de herramientas. Los ingenieros que se niegan a usarlas por completo, o que describen su flujo de trabajo principalmente en términos de cuánto escribe la herramienta por ellos, están mostrando, de maneras diferentes, algo sobre cómo piensan en su propio trabajo.
Los equipos que vale la pena unirse tienden a haber pensado en esto a nivel de equipo: qué herramientas están en uso, para qué tipos de tareas, con qué expectativas respecto a revisión y verificación. Esa conversación, cuando existe, es evidencia de que la cultura de ingeniería tomó en serio la pregunta en vez de adoptar una política por defecto. Es una señal pequeña, pero tiende a correlacionar con otras cosas que importan: inversión en developer experience, respeto por el criterio de ingeniería, y una visión realista de lo que requiere el buen trabajo.
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.
