El Ingeniero de Software Nativo de AI

Entonces, estamos atravesando un cambio bastante grande en la ingeniería de software en este momento. AI y VIBE coding están remodelando fundamentalmente nuestro trabajo, y hay mucho bombo por filtrar. Así que, hoy voy a compartir algunas ideas probadas en batalla desde las trincheras para hacer esa transición con éxito con algunos aprendizajes divertidos en el camino.

Pero antes de comenzar, tengo algo que debo compartir. Todos hemos sido reemplazados por AI. Finalmente podemos retirarnos al bosque antes de que sean talados para más centros de datos. Como puedes adivinar, esto realmente no ha sucedido todavía, pero el futuro podría verse un poco diferente.

He estado codificando con AI durante algunos años, y creo que la dirección en la que vamos es una especie de ingeniero nativo de AI. En lugar de pensar, ya sabes, AI podría reemplazarme, un ingeniero nativo de AI podría preguntar para cada tarea. AI podría ayudarme a hacer esto más rápido, mejor, o de manera diferente de alguna manera. Y creo que el futuro realmente pertenece a los ingenieros que pueden adoptar esa mentalidad colaborativa.

Ahora, si haces un zoom hacia afuera, este gráfico es realmente la hoja de ruta para los próximos años. En un lado, tienes los viajes clásicos de desarrollador donde la mayor parte de nuestro valor provenía de esfuerzo puramente humano. Y luego llegamos a esta fase aumentada por AI donde muchos de nosotros estamos ahora mismo. Y a medida que continuamos cambiando, pasamos de aumentada a AI-first y eventualmente a experiencias de desarrollador AI-native. Ahora, los viajes AI-first hacen una pregunta diferente. Preguntan, ¿cómo se vería este viaje si AI se asumiera desde el principio y no se añadiera al final? Y luego, AI-native DX es donde la unidad de trabajo en sí misma termina cambiando a flujos de trabajo agénticos.

Ahora en el futuro, algunos dicen que cada ingeniero va a evolucionar de un implementador puro a un orquestador de agentes. Tal vez todos seremos gerentes donde el juicio humano y el pensamiento crítico ayudarán a guiar AI hacia la corrección de código hacia los resultados correctos. Algunas personas ya están haciendo mucho de esto, y tal vez vamos a pasar de cómo codifico esto a cómo consigo que se construya el código correcto. Ya hay muchas soluciones disponibles para esto. Está el agente de fondo de cursors, que puede delegar tareas al fondo, puede ser usado por ingenieros, PMs. Puedes monitorear el progreso de múltiples tareas en tiempo real. Puedes ser notificado si el agente necesita entrada. Está cloud code para la web. He estado disfrutando orquestando múltiples tareas usando Jules de Google Labs. También está el agente copilot de GitHub. Uso esto tanto en el escritorio como en el móvil. Como si estuviera de excursión, me encanta poder sacar mi teléfono y simplemente iniciar un montón de tareas en proyectos paralelos. Es bastante genial.

También está Conductor para Map, que soporta múltiples agentes. Pero tengo que aterrizarnos en la realidad. No es sorprendente que las startups o personas con bases de código evergreen ya estén comenzando a jugar con algunas de estas ideas como la orquestación. La empresa es un poco diferente. Lo que escucho cuando hablo con empresas es mucho escepticismo sobre la preparación de estos patrones para bases de código grandes de décadas de antigüedad. Y estoy emocionado de que haya personas investigando estos problemas. Creo que eventualmente las herramientas llegarán a un buen lugar. Pero solo para hablar un poco más sobre estos cambios de patrones, hoy la mayoría de nosotros actuamos como conductores. Efectivamente estamos guiando a un agente a través de una sola tarea. Y mañana podríamos ser esos orquestadores dirigiendo una flota de agentes trabajando en armonía hacia un objetivo compartido. Si piensas en una orquesta, tal vez imagines algo como esto. Tal vez te imagines liderando una orquesta de agentes. Y se ve un poco así. Pero en realidad, quien sea es muy diferente. Las cosas están evolucionando rápidamente, pero las mejores prácticas para equipos y organizaciones aún están en flujo. Así que vamos a hablar un poco sobre eso hoy.

Ahora, múltiples encuestas de desarrolladores, incluidas Dora y Stack Overflow, mostraron que la mayoría de nosotros estamos usando AI para codificar en el trabajo. Y lo que estos datos nos dicen es que ya no es una novedad o un caso marginal, sino que rápidamente se ha convertido en una parte estándar del kit de herramientas de desarrollo de software. Lo que me gustaría decir es, ya sabes, hay una cosa que necesitas recordar. AI realmente no se trata de escribir más código más rápido. Se trata de construir mejor software al final del día. Así que a lo largo de esta charla vamos a explorar lo que mejor podría significar potencialmente. Ahora, codificar con AI es un poco de un espectro. Vibe coding es rápido y exploratorio. Prioriza la velocidad y la experimentación sobre la revisión profunda y el rigor de la ingeniería. Y luego tenemos la ingeniería asistida por AI. Está en el extremo opuesto de ese espectro. Y esta es una especie de integración metódica de AI en un ciclo de desarrollo maduro. Así que el ingeniero humano, nosotros, permanecemos muy en control y usamos AI como un colaborador para aumentar un proceso más estructurado. Y el desafío para nosotros como constructores es realmente navegar hábilmente el espectro.

Para estar en la misma página, echemos un vistazo rápido a la experiencia del desarrollador y dónde AI puede ayudar a lo largo de este ciclo de vida. Este es el bucle base sin ninguna intervención de AI. Es útil como referencia para comparar dónde se puede añadir automatización e inteligencia para acelerar la velocidad. Así que típicamente estamos pensando en cosas como diseño, codificación, pruebas, construcción, despliegue. Esto resalta dónde AI es más útil durante las fases tempranas de diseño. Así que piensa en chatbots en tu editor para hacer preguntas, iterar, y herramientas de triage de AI que pueden agilizar la planificación y la investigación.

Luego tenemos el bucle interno de desarrollo donde pasamos mucho de nuestro tiempo. Así que codificación, pruebas, depuración. Y esto puede ayudar con una generación de código más rápida, automatizando tareas, detectando errores, idealmente antes de que lleguen a producción y definitivamente antes de que termines en Hacker News. Aquí está la visión completa de dónde AI puede ayudar con la experiencia del desarrollador. Estos son todos esos bucles, diseño, interno, envío, externo, y resalta cada punto donde AI puede reducir significativamente el trabajo arduo. Las herramientas de codificación de AI también son un espectro.

Mi equipo y yo hemos estado usando algunas de estas. Tienes muchas opciones hoy en día. Ya sea que estés prototipando, no técnico, o estés construyendo para producción. Nosotros, por supuesto, también hemos vibe coded mucho. Y el verdadero genio de vibe coding es que nunca tienes que enfrentar la deuda técnica porque no tienes idea de quién o qué la creó en primer lugar. A medida que tu equipo avanza en este viaje, te encontrarás con escépticos. Realmente quieres convertirlos eventualmente en personas que puedan ser evangelistas técnicos, personas que puedan tener una perspectiva muy fundamentada sobre cuáles son las debilidades de AI, cuáles son sus fortalezas, y si podemos tener una forma muy equilibrada de cómo pensamos sobre ello. Tuvimos algunos grandes aprendizajes en mis equipos, cosas como que las herramientas de AI no necesariamente reemplazan la experiencia, pero la amplifican.

Y cuanto más habilidad puedas aportar a esto como ingeniero, más poderosos serán los resultados que finalmente obtendrás. ¿Qué hay del impacto de AI en la codificación en Google, donde trabajo? Bueno, en general, ya ha estado moviendo la aguja en la productividad real. Estamos viendo ganancias de velocidad bastante medibles y velocidades de codificación más rápidas en múltiples estudios. Ya sea usándolo como un autocompletado para generación de código completo, para documentación, para pruebas, para revisión de código, generalmente hemos encontrado que puede ayudarnos de muchas maneras.

Tenemos muchos equipos usando con éxito cosas como Gemini CLI para construir la próxima generación de aplicaciones, y lo estamos disfrutando. Probablemente recuerdes, hace tres a seis meses, lo cual parece hace mucho tiempo en AI, cuando teníamos ingenieros de prompts. Me encanta este título. Podría haber sido llamado susurrador de código AI. La gente probaba, evaluaba e iteraba en los prompts para mejorar las posibilidades de obtener una salida de alta calidad. Pero un prompt inteligente realmente no te garantiza grandes resultados.

Muchos de nosotros intentamos la ingeniería de prompts, intentamos ajustar palabras sin fin, pero como muestra este iceberg los problemas reales a menudo están debajo de la superficie con un contexto mal gestionado. Una ventana limitada significa que el AI puede olvidar detalles clave, el contenido no estructurado puede llevar a confusión, la información contradictoria puede distraerlo, y sobrecargarlo también puede abrumar al modelo. La mala gestión del contexto es a menudo el gran problema aquí. El contexto es el rey en este momento. Así que si no te has encontrado con cosas como la ingeniería de contexto, efectivamente significa equipar a un agente AI con todo lo que necesita para abordar una tarea de manera efectiva.

Estamos hablando de los archivos correctos, ejemplos, historial, herramientas, restricciones, y la calidad de tu resultado será proporcional a la calidad y relevancia del contexto que proporciones. Muchas de las herramientas que usamos, ya sea que estés usando cursor o client, hacen que sea mucho más fácil hoy en día para nosotros incluir archivos, carpetas, problemas, URLs, más documentos en tus flujos de trabajo para ayudar con ese contexto que nos falta.

Y cada vez más también tienes otras formas, como formas visuales, multimodalidad, siendo capaz de extraer más contexto que puede ser útil. También estamos viendo que nuestras herramientas evolucionan un poco porque, de nuevo, esos tamaños de ventana de contexto pueden ser bastante finitos. Así que algunas herramientas, como Klein, hacen cosas inteligentes como la resumación automática de contexto. Entonces, cuando tu conversación se acerca al tamaño de la ventana de contexto, puede comenzar a resumir sesiones anteriores para liberar espacio y continuar trabajando con las partes importantes, los detalles importantes preservados.

También hay otras ideas como un banco de memoria, que es una especie de sistema de documentación estructurada que te permite mantener el contexto a través de múltiples sesiones. Así que Klein, por ejemplo, puede leer archivos de banco de memoria y reconstruir su comprensión de tu proyecto sin que necesariamente tengas que hacer mucho trabajo manual allí tú mismo. Aquí hay una gran plantilla para la ingeniería de contexto de Anthropic. Tiene ideas como datos de fondo, ejemplos, historial de conversaciones. Este tipo de cosas hace un gran tweet que olvidarás por completo.

Olvido esto todo el tiempo. Decidí convertir este código en una aplicación web rápida que también puedes revisar. También he olvidado por completo usar esto. En general, necesitamos mejores herramientas para manejar esto automáticamente por nosotros, y estoy esperando que nuestras herramientas evolucionen en esta dirección, también.

El desarrollo impulsado por especificaciones se ha vuelto más popular. Esta es la práctica de realmente planificar antes de solicitar, y se trata de proporcionar ese contexto claro que la IA necesita para tener éxito en lugar de esperar que lea tu mente. Hay algunos otros patrones que surgen de esto. Recientemente, he visto a algunas personas usar un archivo markdown de aprendizajes, y esto se trata de crear un ciclo poderoso de auto-mejora donde el rendimiento del agente mejora con cada tarea.

Al final de una tarea, imagina que has estado solicitándole que tal vez escriba un componente o haga algunas adiciones a una aplicación que ya tienes. Puedes pedirle que almacene ideas clave en un archivo de texto simple, y eso actúa como memoria a largo plazo. Se convierte en un cerebro externo que sigue mejorando y ayuda a guiar el rendimiento del agente con el tiempo. Otras cosas que aprendimos. Nunca comprometas código que no puedas explicar a otras personas o incluso a ti mismo. Esta es una regla de oro para la codificación de IA en producción.

Tienes que asumir que tú y tu equipo van a tener que cambiar cosas manualmente en algún momento, y así nuevamente, el humano en el bucle, la revisión humana del código va a seguir siendo importante. Creo que leer el código se va a convertir en una parte aún más grande del trabajo en el futuro. Podemos esperar pasar más tiempo revisando, probando, explicando que necesariamente solo escribiendo, así que vamos a tener que seguir desarrollando este músculo.

Durante la vida útil de un programa, generalmente se escribe una vez, tal vez se edita un número de veces, pero termina siendo depurado, mantenido y mejorado muchas más veces y se lee bastante a lo largo de su vida útil. El vibe coding es un regalo para el prototipado. Creo que los mock-ups estáticos a menudo se ven bien, pero no son realmente interactivos, y eso tiene una retroalimentación limitada que puedes obtener de la verdadera experiencia del usuario. Así que realmente hemos disfrutado usar esto para el prototipado. Puedes rápidamente crear algo que tenga una versión más clara de la visión que estás ofreciendo a las personas, y simplemente eleva la discusión.

Hay algunas empresas que realmente han adoptado esta idea, como Shopify. Así que Shopify tuvo una especie de gestión de cambio a nivel de empresa en torno a su uso de IA en toda la ingeniería, producto UX desde la cima, y lo que ahora tienen son entregas de diseño y desarrollo que son un poco diferentes. Así que los diseñadores ahora pueden simplemente vibe code prototipos, y pueden trabajar directamente con ingeniería para aterrizarlos como artefactos. Ahora, eso significa que hay revisión de código, hay iteración, hay trabajo en calidad, pero estamos empezando a ver una especie de mezcla en algunos casos de los roles, lo cual es muy interesante de ver. La dictado por voz también cambia la forma en que puedes vibe code porque puedes usar tu voz mucho, mucho más rápido de lo que puedes escribir, hasta tres a cinco veces más rápido.

Cuando empecé a escuchar sobre esta idea, pensé que funciona genial si estás trabajando de forma remota en tu propia oficina, y terriblemente si estás en cualquier tipo de oficina abierta. Pero, por supuesto, ahora tienen vibe coding susurrando, que también está disponible. Así que puedes simplemente susurrar tu camino hacia tus MVPs. Realmente funciona bastante bien. La IA es un multiplicador, por lo que lo que ayuda al humano puede ayudar a la IA. Así que invierte en pruebas, CI, documentación clara antes de esperar realmente grandes ganancias. Las pruebas son en última instancia una gran red de seguridad en este momento. Realmente arriesgan tu uso de IA para codificación.

Así que si las cosas empiezan a descarrilarse por cualquier razón, lo sabrás antes. Y si estás, ya sabes, hablé con muchos equipos que dirán que todo esto es genial si ya tienes pruebas de extremo a extremo. ¿Qué pasa si no tenemos esas pruebas? ¿Simplemente usamos IA para escribirlas? Y puedes. Solo que, nuevamente, necesitas asegurarte de que estás manteniendo a los humanos en el bucle para entender como qué pruebas se están generando. ¿Son suficientes? Por cierto, esto parece una madre burlándose de su hijo por alguna razón, pero al menos están seguros.

Así que la promesa con la IA fue una especie de cambio de paso en la productividad y lo que los datos, me encanta leer documentos técnicos, me encanta leer investigaciones, pero los datos muestran una realidad un poco más matizada. Y así que echemos un vistazo a algunos estudios y algunas acciones concretas que tal vez podamos tomar para asegurar ganancias y gestionar riesgos. Así que lo que muestran los últimos datos es que el uso es alto. Continúa aumentando, pero la confianza está disminuyendo. Las opiniones favorables sobre la IA para codificación cayeron del 70 al 60 por ciento en los últimos dos años y el 46 por ciento de las personas desconfían activamente de la precisión de la IA. Este gráfico muestra que alrededor del 30 por ciento de los desarrolladores encuestados aquí tenían poca o ninguna confianza en el código generado por IA. Y este escepticismo no es necesariamente algo malo. Es un signo de que esta área está madurando. Explica parte de la fricción que vamos a ver en algunas de las otras cosas de las que voy a hablar.

Pero los modelos continúan mejorando. Los agentes continúan mejorando. Sin embargo, comenzamos a aprender dónde pueden surgir problemas. Así que cuando las cosas salen mal con VIVE coding, tienes VIVE debugging, donde no tienes idea de cómo funciona el código o realmente cómo solucionarlo. Pensé en dar un reconocimiento. En mi equipo, muy recientemente lanzamos Chrome DevTools MCP. Y esto es para ayudar a tu asistente de codificación de IA a ver e interactuar con un navegador en vivo. Y eso significa que tu agente puede ver lo que se ha renderizado, puede mirar los registros de la consola, puede mirar los registros de la red, automatizar la optimización del rendimiento. Puede encontrar problemas con cualquier diseño roto. Hay mucho poder que esto desbloquea. Si estás codificando con IA, tal vez échale un vistazo. Podría ser útil. Pero volviendo a los datos.

Así que a nivel individual, el impulso de la productividad de la IA es real. Los desarrolladores que la usan pueden ver hasta un 21% más de tareas completadas. Las personas están fusionando en los bordes hasta un 98% más de pull requests. Hablaremos más sobre pull requests en un segundo. Pero un número muy significativo de desarrolladores dirá que la IA tiene un impacto positivo en su productividad personal. Algunos incluso dirán que cuando hablamos de impacto positivo, puede parecer que la IA escribe mejor código que ellos en algunos casos. Ahora, cuando hablamos especialmente de problemas comunes, problemas promedio, ciertamente podría ver que eso es cierto. Y hay personas que dirán que ha aumentado extremadamente su productividad. Esto muestra que tal vez sea alrededor del 10% al 13%. Y habrá personas que dirán que ha aumentado ligeramente su productividad. Así que cerca del 41%. Y ese último grupo más grande realmente sugiere un beneficio incremental de la IA en toda la fuerza laboral.

Ahora llegamos a lo divertido. Aquí está la paradoja. Aceleramos la generación de código, pero la verificación humana no escaló con eso. Los tiempos de pull request han aumentado en algunos casos hasta un 91%. Los tamaños de PR también están explotando.

Si has revisado una pull request completamente generada por IA, tal vez hayas visto que hay casos donde las personas harán todo tipo de cambios que no son necesarios en muchos, muchos más archivos de los requeridos. Así que los tamaños de PR han explotado hasta un 154%. Esto está absorbiendo muchas de esas ganancias individuales de las que acabamos de hablar. El sistema se mueve a la velocidad del paso más lento. Y hoy, ese paso es la revisión y validación.

Así que los desarrolladores están describiendo este patrón común. Las sugerencias de IA son a menudo plausibles, pero no siempre son correctas. Y el 66% de las personas llaman a esto su mayor pérdida de tiempo. El 45% dice que depurar la salida de IA es más trabajo del que vale. Y esto se conecta directamente con esas revisiones más largas de las que acabo de hablar. La conclusión es bastante simple.

Las puertas de calidad y la validación son ahora el camino crítico. Así que como industria, vamos a necesitar comenzar a evolucionar cómo pensamos sobre la revisión de código para evitar simplemente poner toda esta carga extra en los ingenieros senior. Así que lo que hemos encontrado en general es que la IA brilla en situaciones de bajo contexto. Si estás comenzando desde cero, si estás manejando patrones predecibles, escribiendo funciones genéricas, si estás tratando a la IA como un ingeniero junior, donde las tareas están tal vez bien definidas y el contexto es bajo, puede hacerlo bastante bien, especialmente con código nuevo, especialmente con boilerplate, generando pruebas unitarias, generando documentación, nuevamente, prototipos, MVPs.

Creo que esto puede liberar a los expertos para que puedan concentrar su tiempo en más trabajo de diseño, integración, casos límite complicados, simplemente construyendo experiencias más pulidas. Donde tiene dificultades en este momento es en problemas novedosos de alto contexto. Y aquí es donde realmente se requiere un contexto profundo. Y si eres un equipo que construye algo no trivial, esto va a requerir una supervisión fuerte. Así que no puede necesariamente contener una década de decisiones arquitectónicas o lógica empresarial informal en su cabeza sin estudiar tus bases de código, sin estudiar tus documentos y cómo tu equipo ha estado trabajando a lo largo del tiempo.

En áreas sensibles a la seguridad, el riesgo de errores sutiles sigue aumentando con esto. Y cada vez que tus requisitos son ambiguos o la lógica abarca múltiples sistemas, nuevamente, los humanos deben liderar y la IA debe estar asistiendo. Ahora, algunos pueden decir que no importa cómo sea tu vibe coding, no importa cuán frágil pueda ser, siempre puedes arreglarlo más tarde. Pero para aquellos de nosotros que no estamos cómodos YOLOing it, hay algunas cosas que puedes hacer. Nuestra primera prioridad es realmente mitigar la erosión de habilidades.

Tenemos que usar la IA para acelerar el aprendizaje en nuestros equipos, pero no necesariamente reemplazarlo. Y esto requiere repensar nuestros procesos básicos de enseñanza y tutoría para asegurar que los ingenieros de todos los niveles estén desarrollando y manteniendo capacidades fundamentales de resolución de problemas. Esto lleva a algo que llamo el problema del 70%. La IA puede llevarte aproximadamente al 70% del camino hacia la solución de un problema, ya sea generando una aplicación completa, generando un MVP. Pero ese último 30%, esa milla final, es la parte más difícil. Tu asistente puede ayudarte a estructurar una característica, pero la preparación para producción significa que esos casos límite, esos problemas de arquitectura, esas pruebas, esas limpiezas, todo eso requiere trabajo de nuestra parte. Para los juniors, si eres alguien nuevo en tecnología, si eres un junior, ese 70% sigue siendo muy mágico. Puede parecer muy mágico.

Pero para los seniors, ese último 30% a menudo es más lento que escribir el código desde cero. Así que la IA puede ayudarnos a cerrar la brecha de demostración rápidamente, pero creo que el envío a producción todavía pertenece a los humanos. A veces, ese último 30% es algo que los seniors ven y los juniors no, simplemente porque no saben necesariamente qué buscar. En otras palabras, los juniors pueden enviar ese 70% como una pull request, como si estuvieran listos. Y luego significa que la parte realmente difícil puede terminar cayendo en la revisión de código, en gran medida siendo realizada por seniors, limpiando errores que ningún humano necesariamente habría cometido. O tal vez los humanos los cometerían. Pero significa que, nuevamente, tenemos que repensar cómo estamos abordando las revisiones de código.

No nos gusta hablar sobre el impacto de la IA en el mercado laboral, pero creo que nos va a impactar de alguna manera. El 54% de los líderes esperan que la IA reduzca la contratación de juniors de alguna manera en los próximos años. Está comoditizando las partes fáciles, obligándonos a pensar en cómo la cadena de valor está evolucionando hacia un trabajo más significativo. Esto podría significar, potencialmente, menos roles de nivel de entrada, o que los roles de juniors evolucionen para centrarse en cosas que la IA no podría hacer tan bien. Si eres un líder técnico, un gerente, un líder, creo que vamos a tener que seguir pensando en cómo desarrollamos talento para asegurarnos de que no agotemos inadvertidamente nuestra fuente de talento, porque vamos a necesitar que esos juniors se conviertan en seniors en algún momento. Todavía creo que vamos a necesitar muchos ingenieros seniors.

Una de las primeras cosas que podemos hacer es intentar evolucionar las revisiones de código hacia más momentos de aprendizaje. He oído hablar de ingenieros seniors que devuelven pull requests donde está claro que se usó IA pero la persona realmente no entendía lo que estaba haciendo. Cuando un junior envía un PR generado por IA, la revisión se convierte en uno de tus principales lugares para la tutoría. Puedes hacerles preguntas socráticas que los obliguen a explicar la salida de la IA. Puedes ayudar a asegurar un nivel de comprensión y no solo de funcionalidad. Esas revisiones se vuelven más sobre comprensión que solo corrección. He sugerido que tal vez evolucionemos la programación en pareja a programación en trío. Mantiene al experto senior en el circuito, pero asegura y asume que el junior va a estar usando IA de alguna manera para aprovechar la velocidad.

Todos están aprendiendo, la calidad idealmente se mantiene alta, y evitamos problemas de aislamiento que el trabajo asistido por IA pura puede crear. Sigue siendo un trabajo en equipo colaborativo humano-IA. He estado sugiriendo en mis equipos que probemos desafíos regulares sin IA. Esto es otra cosa que puedes hacer para asegurar que las habilidades de pensamiento crítico no se evaporen. Puedes ayudar a mantener las habilidades de tu equipo afiladas designando un día de la semana o incluso un cierto tipo de tarea en tu backlog donde simplemente digas, tal vez no usemos IA para eso. Solo refuerza que es un asistente. Es una herramienta, pero no es un reemplazo para el pensamiento. Esto es esencial para construir resiliencia cuando la IA falla o no está necesariamente disponible.

La IA a menudo produce código que pasa pruebas básicas, pero puede carecer de robustez. Su línea base suele ser, bueno, funciona, supongo. Más o menos se renderiza en el navegador, supongo. Pero nuevamente, esas revisiones de código son importantes para verificar casos extremos, rendimiento, seguridad, corrección, si todavía está cumpliendo con las mejores prácticas y patrones de tu equipo. Y nuestro papel humano realmente se trata de asegurar la preparación para la producción y los estándares. Hablando de estándares, así es como se veían los estándares de seguridad en los años 80. No tener cinturones estaba bien. Solo teníamos vibraciones, lo cual no es completamente diferente a lo que tenemos hoy.

Así que cubrí mucho hoy. Si así es como te sientes, tienes toda la razón. Lo importante de todo esto es simplemente mantenerse proactivo en ayudar a ti mismo y a tus equipos en este viaje. Nuestro trabajo es encontrar el equilibrio adecuado al final del día. Es aprovechar la velocidad y las capacidades de la IA para entregar valor más rápido, pero mantener el elemento humano a cargo. Creo que nuestra creatividad, nuestro juicio y nuestra comprensión de las necesidades del usuario realmente guiarán cómo se usa la IA. Así que espero que hayas encontrado algo útil en esta charla. Gracias. Gracias.

Bien. Así que parece que la primera pregunta es, ¿cuál ha sido el canal principal para tu equipo en el último desafío del 30%? Voy a reformular eso como ¿cuál ha sido el principal desafío para tu equipo en el último desafío del 30%? Creo que honestamente, ha sido definir qué queremos decir con calidad. Creo que si haces un zoom hacia afuera, muchas personas, si les preguntas, ¿qué significa calidad? Dirán que hay un aspecto de corrección, seguridad, rendimiento, tal vez accesibilidad, tal vez buenos diseños estéticos ahí. Pero, ¿cuál es la herramienta que usas para averiguarlo? En mi equipo, hemos construido una serie de herramientas a lo largo de los años. Hicimos Lighthouse, hemos hecho Chrome DevTools, hemos hecho CoreEd Vitals, pero cada equipo va a tener una perspectiva ligeramente diferente en términos de lo que ese último tramo realmente significa para ellos. Así que creo que definir y alinear cuál es ese estándar para ti va a seguir siendo muy importante.

Bien. Sí, eso tiene sentido. Nuestra siguiente pregunta es, ¿creemos que estamos perdiendo nuestra intuición dependiendo mucho de los asistentes de IA? Oh, absolutamente. Definitivamente creo que ese es el caso. Ya estoy encontrando lugares donde me apoyo en la IA para generar un bloque de función o algo. Y estaba... Me encanta... Tuvimos este cuestionario justo al principio y estaba pensando, hombre, lo habría hecho mejor en este cuestionario hace dos años que ahora. Y es porque estamos empezando a depender de ello. Al menos con Stack Overflow, tenías que buscar la respuesta. Ahora simplemente se genera para ti. Y esperamos que lo estés leyendo de alguna manera, pero ¿la gente realmente está leyendo el código que se está generando?

No sé si siempre lo hacen. Y así creo que nosotros mismos vamos a tener que asegurarnos de seguir estos patrones de revisión humana de todo lo que se genera. Si estoy usando cursor, cliente VS code, cualquiera de estas cosas, volveré... Tan pronto como la IA haya generado el código, volveré y echaré un vistazo a cuáles fueron sus pasos de pensamiento. ¿En qué estaba pensando realmente cuando decidió construir esto?

Solo para intentar asegurarme de que cuando la IA comience a tener problemas para resolver cuestiones, sepa cómo solucionarlo, porque de lo contrario estaré en problemas. Exactamente. Sí.

Veamos. La siguiente pregunta es... ¿Te preocupa que la codificación con IA fomente una mentalidad de productividad sobre una mentalidad de curiosidad? Absolutamente. Me preocupa absolutamente esto. Creo que muy a menudo nos dejamos llevar por la emoción de, oh Dios mío, me generó todo en solo unos minutos. Soy increíble.

Pero no necesariamente... Siento que hemos pasado por alto, oh espera, la IA puede ser realmente útil como herramienta de aprendizaje y como guía de aprendizaje. Y especialmente si trabajas en cualquier base de código de tamaño significativo, es realmente, realmente buena para eso. Simplemente selecciona una parte de la base de código, pídele una comprensión de cómo funcionan las cosas. Trabajo en Chrome. Tenemos una de las bases de código más grandes de Google, creo que en el mundo.

Y no puedes simplemente hacer que la IA meta toda la base de código en la ventana de contexto. Así que si queremos intentar aprender sobre una parte de la base de código, simplemente diremos, está bien, bueno, me dijeron que la lógica está aproximadamente aquí. Puedo ir a preguntar a alguien, pero primero voy a usar IA para enseñarme sobre esta parte de la base de código. Y luego, si todavía tengo preguntas persistentes, puedo preguntar a los ingenieros senior o a la persona con más experiencia sobre esas lagunas. Y de esa manera, lo estás usando para construir tu memoria muscular y tu comprensión de cómo funciona el espacio del problema antes de usarlo para simplemente hacer todo el trabajo por ti.

Así que creo que, de nuevo, se reduce a cuáles son los patrones y prácticas y hábitos que tú mismo estás imponiendo. Sí. Es casi como un mejor pato de goma en este punto. Sí.

Absolutamente. La siguiente pregunta es, ¿cómo ves la evolución del proceso de entrevista en la era de la IA? Oh, esa es una pregunta picante. Sí. Sigo todas esas conversaciones divertidas sobre, ya sabes, Clulee y todas estas cosas que están sucediendo. Mi opinión personal es que cada vez más las empresas van a tener que asumir que una persona está usando IA como herramienta. Hace unos años, estaríamos diciendo, bueno, oye, ¿tienes acceso a la web? ¿Puedes usar Stack Overflow? ¿Puedes usar cualquier otra fuente de información? Y siento que la parte importante, lo que más me importa es, ¿realmente puedes resolver problemas? ¿Cuál es tu proceso de resolución de problemas? ¿Cómo estás usando la IA en ese proceso de resolución de problemas? Porque no puede ser el proceso completo de resolución de problemas en sí mismo. Exactamente. Exactamente. Así que creo que el proceso de entrevista va a tener que asumir que probablemente estás usando IA de alguna manera, pero si es algo en persona, o es una llamada donde estás monitoreando de alguna manera, que la persona no lo está delegando completamente a la IA, simplemente les preguntaría como, genial, generaste algo con IA. ¿Puedes explicarme cómo funciona esto? Si tuviéramos que resolver este otro caso límite sin usar IA, ¿podrías tal vez hablar sobre tu proceso? Y está bien si están usando IA para luego estructurar la solución, pero quiero que entiendas cómo resuelves problemas a través de diferentes sistemas, a través de diferentes componentes, a través de diferentes piezas de tu aplicación. Y así, en última instancia, creo que sí, el proceso de entrevista va a tener que evolucionar mucho. Sí, creo que cuando se creó IntelliSense por primera vez, la gente se resistía a ello. No necesitas memorizar todo, y eso es lo que la IA puede ayudarte a hacer. Sí, absolutamente. Entonces, ¿crees que la IA está impactando más los trabajos de front-end que los de back-end? Tengo una respuesta extremadamente larga para esto. Así que sí. La razón es que actualmente, muchos equipos de modelos de frontera, así que probablemente estén usando modelos de varias empresas diferentes. Muchos de esos equipos, provienen de un trasfondo de ciencia de datos.

En los últimos dos o tres años, han tenido que estar un poco más conscientes de las mejores prácticas de front-end, mejores prácticas de full stack. Pero todavía hay mucho énfasis en el diseño de front-end. Espera, front-end es un tema muy amplio. Podrías estar, ya sabes, alguien podría estar usando Next.js y tratando de construir una aplicación, o podrían estar usando otros tipos de cosas. Y así, hay mucho énfasis en este momento en front-end, solo porque es un poco más fácil para nosotros poder construir puntos de referencia alrededor de él para que los equipos de modelos optimicen. Eso no quiere decir que los modelos no sean buenos en back-end, pero todavía hay mucho trabajo por hacer en aplicaciones de full stack, andamiaje y desarrollo. Creo que esto es un problema de tipo cuestión de tiempo. Así que ahora mismo, diría que sí, probablemente está impactando más los trabajos de front-end, pero también va a impactar a esos de back-end probablemente dentro del próximo año o dos. Correcto, tiene sentido.

¿Alguna opinión sobre etiquetar el nivel de uso de IA para PRs? Sí. Mucha gente me hace variaciones de esta pregunta. La gente me pregunta, ¿deberíamos estar anotando nuestros archivos fuente individuales con las líneas que generó la IA? ¿Debería estar anotando componentes, módulos, cualquiera de estas cosas? Creo que ahora tenemos que asumir que la gente va a estar usando IA y tal vez el 70, 80%, 90% está siendo generado por IA. Esto se convierte en un problema filosófico especialmente para proyectos de código abierto, porque ahora es muy fácil para la gente simplemente lanzar algo de código por encima de la cerca y sentirse bien si su contribución es aceptada. Siento que necesitas idear algún tipo de política que intente desalentar a la gente de ser perezosa y los anime a al menos haber hecho una primera revisión ellos mismos para entender cómo funciona. Así que si alguien me envía un PR y es obvio que han usado IA no solo para generar el código, sino también para generar el resumen de qué trata esto, voy a llamar bullshit. Y creo que está bien que llamemos bullshit. Siento que solo necesitamos comenzar a asegurarnos de que hay prácticas acordadas, ya sea un proyecto de código abierto o un equipo, prácticas acordadas y asegurarnos de que si estamos pidiendo a la gente revisiones, hay alguna evidencia de que realmente han pensado en el problema. Tal vez eso signifique que introducimos prácticas como, bueno, podría hacer una revisión rápida de primera pasada. Si parece que no lo entiendes, o simplemente resolviste esto de la manera incorrecta, lo siento, solo voy a decir, vas a tener que rehacer esto de alguna manera. Pero creo que para las pull requests, estoy mucho más abierto a que la gente etiquete que se usó IA. Para archivos individuales, creo que eso es una batalla perdida, porque especialmente si estás en un proyecto de equipo, se vuelve obsoleto tan rápido.

Si reducimos la contratación de ingenieros junior, ¿cómo se ve el pipeline para formar ingenieros senior calificados? Absolutamente. Creo que este es un problema fundamental con el que estamos lidiando. No vamos a poder apoyarnos en el mismo cociente exacto de desarrolladores senior para siempre. Si asumes que los modelos y la calidad de los agentes van a mejorar mucho, mucho, mucho en los próximos años, tal vez eso ayude a resolver parte del problema. No creo que vaya a resolver todo el problema en absoluto. Mi perspectiva personal es que las empresas que ya están reduciendo agresivamente la contratación de juniors no están tomando una visión a largo plazo sobre esto. Como industria, necesitamos ser mucho más conscientes sobre la reducción de esos roles junior. Necesitamos mantenerlos en su lugar. De acuerdo.

Gran pregunta. Diré que si piensas en esto desde la perspectiva de la mayoría de las plataformas de vibe-coding, hay un montón de plataformas de vibe-coding, muchas de ellas, cuando comenzaron a desarrollarse, estaban muy enfocadas en, ¿podemos hacer que la maldita cosa siquiera funcione? Escribes un prompt. Es realmente un poco mágico que funcione a la primera muchas veces. Pero estaban muy centrados en la corrección y en si funciona. En el último año, comenzaron a enfocarse un poco más en el diseño, en el rendimiento. No creo que se hayan enfocado tanto en la accesibilidad. Diría que los modelos base a menudo no asumen nada sobre accesibilidad. Vas a tener suerte si eso es algo para lo que van a optimizar. Me encantaría ver más herramientas, más plataformas, realmente enfocarse en sus prompts del sistema diciendo, hey, sí, asegurémonos de que esto también sea accesible.

Genial. Bueno, eso resume el tiempo que tenemos para preguntas y respuestas, pero Addy estará en una de las sesiones de oradores donde puedes hacerle preguntas personalmente y siéntete libre de contactarlo. Gracias. Sí, gracias.