¿Cómo se ve la excelencia en ingeniería en la era de la IA?

Lee la Transcripción:

Estamos probando la transcripción de nuestros pódcast mediante un programa de software. Por favor, disculpa cualquier error, ya que el bot no es 100% preciso todo el tiempo.

Hannah Clark: Se ha vuelto una broma cómo la era de la IA ha provocado la desaparición de todos los trabajos en tecnología. De hecho, tantos empleos han desaparecido este año, que me sorprende que no me hayan invitado a más funerales. La gestión de productos está muerta, la investigación de usuarios está muerta, y lo más grave de todo, la ingeniería de software está muerta. Seguro que predico al coro aquí, pero cualquiera que realmente crea que la ingeniería de software ha muerto porque tu LLM de barrio puede escribir código, definitivamente no es ingeniero.

Mi invitado de hoy, el fundador de Cortex.io, Anish Dhar, incluso diría que la ingeniería está lejos de estar muerta. Solo está madurando. Anteriormente ingeniero en Uber, Anish fundó Cortex para hacer más fácil a los ingenieros comprender bases de código complejas. Como ingeniero y como alguien cuyos usuarios también son ingenieros, lo que está viendo en este ámbito es, en realidad, una evolución de la excelencia en ingeniería y una desconexión entre las nuevas y viejas formas de medirla. Compartimos ideas de próxima generación sobre la medición y evaluación de la excelencia en ingeniería y una opinión provocadora sobre cómo el fenómeno del “vibe coding” encaja en la conversación. Entremos de lleno.

Por cierto, mantenemos conversaciones como esta cada semana, así que si te parece interesante, ¿por qué no te suscribes? Bien, ahora sí, vamos al tema.

Bienvenidos de nuevo al podcast de The CPO Club. Hoy estoy con Anish Dhar, fundador de Cortex.io.

Anish, gracias por hacer un espacio para hablar conmigo hoy.

Anish Dhar: Muchas gracias por invitarme.

Hannah Clark: Sí, ¿puedes contarnos un poco sobre tus antecedentes y cómo llegaste a tu rol actual?

Anish Dhar: Sí, por supuesto. Soy el cofundador y CEO de Cortex.io. Empezamos la empresa hace unos seis años, pero antes de eso trabajé como ingeniero en Uber. En realidad, empecé mi carrera allí y muchos de los problemas que afrontaba como ingeniero en Uber inspiraron la razón principal para fundar Cortex.

Dos amigos muy cercanos míos. Uber tiene una arquitectura de servicios internos enorme. Como ingeniero allí, me resultaba muy difícil comprender las distintas partes de la base de código, especialmente al principio. Había tantos servicios diferentes en desarrollo, lo que añadió una complejidad impresionante, y hablaba con un amigo muy cercano que era ingeniero en una startup pequeña llamada Lend.

Ellos solo tenían cien ingenieros, mientras que Uber tenía más de mil. Pero ambos enfrentábamos desafíos similares sobre cómo organizar y entender la arquitectura de servicios. Y eso encendió las alarmas: si Uber está por un lado del espectro en escala, y otra empresa que acaba de comenzar su recorrido en microservicios sufre los mismos problemas, está claro que este es un gran problema en la industria.

Así que acabamos fundando la empresa. Pasamos por el batch de Winter 20 de Y Combinator. Y ahora, seis años después, acabamos de cerrar nuestra Serie C y trabajo con cientos de empresas diferentes que usan Cortex para gestionar la simplicidad en sus desarrollos.

Hannah Clark: Genial. Es un recorrido impresionante y siempre es inspirador saber que una empresa nace de un problema que conoces a fondo.

Y hablando de eso, hoy vamos a hablar sobre la excelencia en ingeniería y cómo se ve actualmente en el mundo tecnológico. Así que, por supuesto, es un tema que te ha tocado de cerca a lo largo de tu carrera. Para empezar, ¿cómo defines la excelencia en ingeniería en 2025 y por qué se está convirtiendo en un foco tan crítico para CTOs y vicepresidencias de ingeniería ahora mismo?

Anish Dhar: Sí, muy buena pregunta. En Cortex descubrimos que, durante mucho tiempo, la conversación se centró mucho en la experiencia del desarrollador. Y la experiencia del desarrollador sigue siendo una parte crítica de cualquier organización de ingeniería. Son cosas simples como asegurar que, cuando los desarrolladores se unen a una empresa, sea fácil configurar su sistema interno y estar conectados a GitHub y a todas las herramientas que necesitan, o que, cuando despliegan un servicio, la infraestructura esté bien configurada, para que no haya muchos problemas o pasos adicionales.

Pero hemos encontrado, especialmente en los últimos dos años, que la conversación se ha trasladado mucho más allá de la experiencia del desarrollador hacia lo que llamamos excelencia en ingeniería. Y diría que la gran diferencia entre ambas es que la excelencia en ingeniería se centra en diferentes equipos dentro de la organización.

Puedes pensar en equipos SRE, de seguridad, de productividad de desarrollo, incluso de experiencia del desarrollador, pero realmente se alinean con los resultados reales del negocio. Y creo que esa es la diferencia clave: mucha de la excelencia en ingeniería reflexiona sobre cómo mi trabajo realmente impacta el negocio y cómo hace avanzar los objetivos, desde la visión del CEO hasta el SRE específico que trabaja en ello. Un buen ejemplo podría ser: como empresa, nos enfocamos en mejorar la experiencia del cliente y queremos que los clientes que usen nuestro producto lo vean como confiable, y una mejor experiencia trae más ingresos porque usan más el producto.

Desde una iniciativa de excelencia en ingeniería, tu equipo SRE podría implementar un checklist de preparación para producción antes de desplegar servicios y asegurar que todos cumplan los estándares de la empresa. Así, una iniciativa que parte del equipo SRE termina generando un impacto real de negocio.

Creo que es crítico que los equipos piensen sus iniciativas de esta manera porque eso reafirma el valor y alinea las iniciativas técnicas con lo que le importa a la empresa, que es de lo que se trata, en esencia, la excelencia en ingeniería.

Hannah Clark: Interesante. Estoy segura de que, como bien has descrito, es como un recorrido interminable que involucra varias disciplinas trabajando en armonía.

Háblame de este marco que has desarrollado. ¿Cuáles son sus pilares clave? ¿Cómo lo ves en tu propia organización?

Anish Dhar: Es cierto. Realmente es un recorrido interminable. Muchas empresas con las que trabajamos, especialmente las grandes, tienen mucha infraestructura heredada versus una nueva empresa construida con tecnologías modernas o incluso “IA primero”.

Aun así, existen diferentes iniciativas enfocadas en la excelencia en ingeniería, que requieren un enfoque muy reflexivo desde todos los equipos sobre qué trabajo realizan y cómo impacta finalmente los objetivos de excelencia del negocio. Desde la perspectiva del marco, uno de los puntos en los que más hemos trabajado es cómo definir la excelencia en ingeniería para tu organización.

Y creemos que todo inicia con la excelencia de negocio. Hay distintos objetivos a nivel de liderazgo que pueden tener: liberar innovación y reducir el time-to-market, reducir costos y aumentar la eficiencia, y normalmente el tercero, que es cómo mejorar la calidad y la experiencia del cliente.

Bajo eso, están los pilares de la excelencia en ingeniería. Son aquellos equipos y perfiles especializados en impulsar las iniciativas clave hacia esos objetivos. Cosas como velocidad, eficiencia, seguridad, confiabilidad. Incluso dentro de esas subcategorías verás iniciativas como migraciones de seguridad, checklist de preparación, o procesos de gestión de incidentes. O simplemente indicadores como los DORA Metrics para entender cómo está rindiendo el equipo.

La base de toda iniciativa radica en lo que llamamos las 4 Cs: visibilidad completa, mejora continua, experiencia de desarrollador consistente y, por supuesto, propiedad clara. Porque sin propiedad y sin entender las distintas partes del código, difícilmente puedes impulsar estas iniciativas.

Normalmente vemos que los portales internos (IDP) ayudan mucho en esta base, pero cualquier sistema interno de gestión puede servir, siempre y cuando logres saber qué están desarrollando las personas para poder implementar iniciativas de excelencia en ingeniería.

Hannah Clark: Quiero profundizar en algo que mencionaste sobre medir el rendimiento, porque sé que a veces existe cierta tensión respecto a medir la productividad de los desarrolladores con métricas como las líneas de código.

Eso puede resultar un tema controvertido entre ingenieros. ¿Cómo deberían pensar los líderes de ingeniería en torno a la medición de la productividad de un modo más holístico que tenga en cuenta todos estos elementos y las famosas “C” que mencionabas?

Anish Dhar: Sí, totalmente. Creo que gran parte de la productividad de desarrolladores, en los últimos años, se ha centrado en líneas de código o métricas DORA. Existen diversos marcos que intentan simplificar la productividad, y hay cierta verdad detrás de cómo se calculan esos indicadores.

Las líneas de código no son un buen reflejo de si una persona es productiva o no. Pero si no entregas ni una sola línea de código, trimestre tras trimestre, entonces claramente hay un problema con los resultados o si comparas equipos entre sí.

Sin embargo, la conversación ha ido cambiando de tener datos a pensar cómo conseguir que los ingenieros se involucren y busquen mejorarlos. Es un problema completamente distinto. Cualquiera puede ir, conectar su API de GitHub y obtener un panorama. Pero mostrar un set de métricas a un ingeniero y decirle “tenemos que mejorar este indicador” no significa nada para él.

El ingeniero se centra en construir software de acuerdo a las necesidades del negocio y de la forma más eficiente. Pero ahora la plática con los CTOs se enfoca más en: tengo estas métricas, ¿cómo hago que sean significativas para los ingenieros y que se vean reflejadas en su trabajo?

Ahí es donde la excelencia entra en juego. Porque, al final, los ingenieros quieren que el negocio crezca y buscan que su trabajo tenga impacto real en los clientes. La productividad no se limita solo a indicadores sueltos, sino a cómo el negocio los utiliza para contar una historia, y cómo eso se conecta con las tareas que el ingeniero realiza.

Esa es la gran transformación que estamos viendo.

Hannah Clark: ¿Has notado que existen métodos de evaluación o KPIs anticuados de los que se están alejando? ¿Cuál dirías que es la nueva escuela de la evaluación, o tienes algún ejemplo específico?

Anish Dhar: Sí, claro. Pensaría la productividad en términos de métricas de entrada (input) y salida (output). Las métricas de salida son todos los marcos clásicos para medir el rendimiento, como los DORA Metrics, que brindan una visión holística (o supuesta visión holística) sobre cómo rinde tu equipo.

La mayoría de organizaciones quieren ver y capturar estos indicadores, pero lo relevante es cómo influir y verlos avanzar. Lo que más nos piden nuestros clientes últimamente, y por lo que Cortex ha crecido estos años, es justamente ese enfoque en las métricas de entrada que influyen en las de salida.

Por ejemplo, la frecuencia de despliegue: es un excelente indicador, porque te permite predecir la rapidez con la que lanzas productos (que te ayuda a ganarle al mercado y avanzar como negocio). Si decides priorizar la frecuencia de despliegue y lo mides en un dashboard, y lo marcas como un objetivo: “ahora desplegamos dos veces por semana, queremos llegar a cuatro”…

Como ingeniero, ¿cómo asocio eso a mi trabajo y a mis servicios o responsabilidades? Deployar más rápido podría implicar más errores, menos confiabilidad…

Aquí las métricas de entrada son claves. Quizá implementas un proceso para ayudar a aumentar la frecuencia de despliegue. Un caso real: uno de nuestros clientes, O’Reilly, perseguía ese objetivo y usaba nuestros dashboards. Descubrieron que para desplegar más rápido debían tener guardarraíles claros sobre cómo se debe desplegar y lineamientos sobre la confiabilidad.

Antes, al intentar acelerar, a menudo aumentaban los errores. Por tanto, crearon un checklist de preparación con ocho o nueve métricas de entrada (input) para evaluar la salud del proceso de deploy: que las guardias los turnos de guardia estén cubiertos, que los builds de los servicios pasen correctamente, que existan tests funcionando, etc. Así, el ingeniero tenía una guía clara de lo que debía cumplir en sus servicios.

Esto logró subir la frecuencia de despliegue gradualmente y evitar incidentes. Por tanto, hoy muchas empresas piensan en ambas métricas (input y output), porque se retroalimentan y cuentan una historia más integral sobre productividad.

Hannah Clark: Sí, tiene mucho sentido. Cambiando de tema pero sin alejarnos mucho, ya que seguimos hablando de desplegar más rápido: no podemos hablar de ingeniería en 2025 sin mencionar el “vibe coding”.

Hablemos de estas herramientas de IA que están transformando los flujos de trabajo del código. Te he oído decir que no puedes “vibe codear” hasta conseguir un millón de usuarios por día. Tal vez sea una opinión controvertida, tal vez no. ¿Cuál es la realidad frente al hype en cuanto al uso de IA en entornos a escala de producción?

Anish Dhar: Sin duda es un tema muy candente. Todas las organizaciones de ingeniería están pensando en IA, o han adoptado algún asistente de codificación con IA, como Cursor, entre otros. Incluso nuestro equipo de ingeniería en Cortex, casi todos usan algún asistente de codificación IA diario.

Pero lo que hemos descubierto, tanto conversando con ingenieros de nuestro equipo como con clientes con iniciativas similares, es que estos asistentes funcionan muy bien cuando tienes una idea inicial y quieres validarla rápido. O para frontend, al prototipar muy rápido algo desde la idea hasta cómo se verá y funcionará.

En esos procesos de desarrollo van perfectos. Quieres algo rápido, algo para mostrar y validar si funciona. Como emprendedor, puedes probar tu idea velozmente, y de ahí el rápido crecimiento de esas herramientas.

Pero la realidad es que jamás confiarías en un código “vibe codeado” para mantener un sistema de producción utilizado por millones de usuarios. Eso lo sabemos por experiencia propia. “Vibe coding” es, como mucho, un ingeniero junior que recién aprendió a programar. No tiene comparación con perfiles senior o “staff” que comprenden el diseño de sistemas y la infraestructura a escala. Y no es que no podamos llegar allí, la IA evoluciona tan rápido que quizá algún día lo logre, pero hoy en día ninguna empresa grande depende del “vibe coding” para ningún sistema crítico. El expertise técnico requerido para desplegar, escalar y diagnosticar esos sistemas es, por ahora, insustituible.

En resumen, la productividad ha subido con asistentes de código, pero no necesariamente en aquellas áreas de las que se suele hablar o que suenan más atractivas en el marketing actual. Pero la realidad es que aún no están listos para sistemas de producción empresariales.

Hannah Clark: Muchos profesionales te entenderán. Hay mucho entusiasmo externo sobre la facilidad de usar estas herramientas en tu profesión, pero eso no significa que estén a punto de reemplazarte.

Pero es importante hablar de esto. Para líderes de ingeniería que quieren equilibrar la inversión en herramientas de IA y su plantilla: ¿qué consideraciones deben tener? ¿Cómo evaluar el impacto real de la IA en la productividad del equipo, e incorporarlo a su presupuesto?

Anish Dhar: Es una gran pregunta. Hay muchos factores involucrados. Desde un punto de vista macro, los líderes de ingeniería que impiden a sus equipos explorar o acceder a herramientas como Cursor o GitHub Copilot, por ejemplo, están perjudicando la salud y calidad de sus equipos a largo plazo. La realidad es que en los próximos diez años, mucho del código inicial será asistido por IA, porque, como dije antes, si estás creando una empresa o tienes una idea y quieres probarla rápidamente, es diez veces más rápido con algo como Cursor, sin preocuparte todavía por la escala.

Los equipos que ya adoptan esas herramientas y aprenden a usarlas en fases diversas del ciclo de vida del código tendrán ventaja, incluso en grandes empresas. También resulta útil para perfiles no técnicos: product managers, TPMs o científicos de datos, que comprenden conceptos técnicos y pueden pasar ideas más completas a ingeniería gracias a que pueden generar fácilmente prototipos. Desde esa perspectiva, sería absurdo no presupuestar el acceso a las herramientas IA.

Ahora, la “pregunta del millón” es cuánto impacto real tienen en la productividad. Honestamente, todas las empresas están tratando de responder eso hoy. Muchos clientes compran Cortex junto a GitHub Copilot y nos lo preguntan: “Tenemos esta herramienta que debería multiplicar por 3 o 4 nuestra productividad, ¿realmente sucede?”. Creo que vuelve a lo de antes: no basta con ver la frecuencia de despliegue y decir si Copilot hace efecto allí, porque puede ayudar a ir más rápido, pero generando código malo y problemas de confiabilidad.

Tienes que analizarlo desde varios ángulos y revisar diferentes métricas, en línea con la excelencia en ingeniería. Como negocio, olvida el “vibe coding” y la moda, piensa: ¿qué nos impide crecer ahora? ¿La introducción de la IA está cambiando realmente esa realidad?

La realidad es que, al principio, quizá no veas impacto claro, porque se necesita tiempo para encontrar los espacios en los que estas herramientas modifican la productividad. El error de muchas empresas es dejarse llevar por la moda, comprar miles de licencias, y a los seis meses preguntarse si han visto resultados, generando reacciones negativas.

Debes tener una estrategia clara para introducir estas herramientas y saber tus intenciones desde el inicio. Así puedes luego medir si están cumpliendo.

Hannah Clark: Coincido contigo. Ahora mismo hay presión por dominar estas herramientas e integrarlas en el flujo de trabajo, pero la diferencia entre cantidad de producción y calidad de resultados es enorme. Hay que ser muy intencionales, no solo en ingeniería, sino en toda la empresa, para aplicarlas bien, facilitando lo mejor del equipo, y no solo como excusa para reducir plantilla por IA en el futuro.

Por eso es interesante ver cómo todos están aprendiendo sobre la marcha, y es una época desorientadora para estar en tecnología. Hablando de herramientas de IA y su integración en los flujos de desarrollo, y también de calidad: ¿cómo podemos lograr un equilibrio entre mantener la calidad, estándares de seguridad y confiabilidad, y aprovechar estas herramientas para ser organizaciones de vanguardia?

En tu empresa, ¿cómo lo gestionáis?

Anish Dhar: Es muy buena pregunta. De entrada, la idea de que la IA va a reemplazar a los ingenieros es absurda. Lo que es cierto es que, al empezar, puedes quizás contratar menos ingenieros, porque puedes iterar y probar ideas rápido con herramientas como Cursor. Eso sí, la velocidad de iteración es brutal. Pero cuando se trata de sistemas de producción, en mi opinión, las empresas que creen que podrán reducir su plantilla de ingeniería por la IA buscan titulares llamativos; en realidad eso no sucede ni sucederá.

Hannah Clark: Sin dar nombres…

Anish Dhar: Exactamente. Todas esas empresas seguirán contratando ingenieros; la demanda no va a desaparecer. Respecto a tu pregunta sobre cómo impacta la IA en los pilares clave de confiabilidad y seguridad, esa es la gran incógnita ahora mismo. Y es probablemente lo que más asusta a los equipos de SRE, seguridad y operaciones, porque la introducción de estas herramientas multiplica la superficie de ataque: se escribe más código, pero no siempre comprendemos cómo funciona.

Lo que significa que cuando hay un incidente (algo que es inevitable, porque siempre puede surgir una caída inesperada, una parte del código que no entendiste bien…), cuanto más IA participa en el sistema, más difícil es para el ingeniero recorrer el código y comprenderlo cuando ocurre un problema.

Eso es lo más preocupante. Por eso ahora es más crítico que nunca esa base de excelencia en ingeniería de la que hablaba: visibilidad total y propiedad clara. Cuantos más sistemas son generados (o asistidos) por IA, menos cobertura real hay sobre esas áreas. Quién es responsable, quién entiende cómo funciona… son cosas que inquietan a equipos de seguridad y confiabilidad, y ya lo vemos con nuestros clientes y nosotros mismos.

Cuando publicamos código generado por IA, los ingenieros aclaran cuál parte fue creada 100% por Cursor o la herramienta IA, y revisamos esas áreas con mayor atención. También está creciendo mucho la tendencia del “testing asistido por IA”. Hay empresas creando “ingenieros IA” para revisar tests y código. A veces parece arriesgado porque aunque la IA aporta mucho más bien que mal hoy en los equipos de ingeniería, da miedo imaginar un sistema donde el 80% esté autogenerado y no lo entiendas. Eso aumentaría el tiempo de resolución de incidentes, fallaría la confiabilidad, y los incidentes de seguridad crecerían porque hay menos control y visibilidad. Eso es lo que hay que vigilar.

Hannah Clark: Estoy de acuerdo. Es un problema logístico del que se habla poco, que muchos equipos deben afrontar: más output exige más supervisión.

La semana pasada hablamos con el SVP de gestión de productos en Mastercard Gateway y nos comentó cómo las herramientas de IA aceleran la cumplimentación de formularios para entrar a nuevos mercados. La IA permite completar rápidamente todo el papeleo, pero también es necesario supervisar y tener propiedad sobre esos envíos. Así que es el clásico “puedes producir más rápido, pero debes ser responsable a la misma velocidad”.

Creo que es un enorme cuello de botella logístico para equipos de ingeniería y otros roles que aprovechan estas herramientas. Hay que subrayar esto: sí, podemos sacar features muy rápido, pero también debemos rendir cuentas igual de rápido.

Realmente es fascinante ver cómo líderes de muchos departamentos afrontan preocupaciones tan similares incluso estando en disciplinas distintas.

Realmente agradezco todas tus ideas. Esto concluye nuestro episodio. ¿Dónde pueden encontrarte, Anish?

Anish Dhar: Me pueden seguir en LinkedIn o Twitter, solo busquen mi nombre y me encontrarán. También pueden encontrar Cortex en LinkedIn.

Siempre publicamos, y de hecho estamos organizando “Engineering Excellence Summits” en el mundo. Si hay uno cerca de tu ciudad, pásate por allí, nos encanta construir comunidad sobre estos temas. Todas las empresas se enfrentan a estos desafíos, y es genial ver una comunidad tan grande alrededor de ello.

También organizamos nuestra conferencia llamada IDPCON, centrada en la excelencia en ingeniería, reuniendo líderes empresariales y desarrolladores interesados en conectar relacionados con la excelencia en ingeniería.

Habrá muchas charlas geniales. Será en octubre en Nueva York, así que esperamos veros allí.

Hannah Clark: Suena fantástico. Lo mencionaremos en la descripción. Muchas gracias por acompañarnos.

Anish Dhar: Gracias a ti por invitarme. Ha sido genial.

Hannah Clark: Gracias por escucharnos. Si quieres más ideas, guías prácticas y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a The CPO Club donde prefieras escuchar tus pódcast.