Cargando…

¿La IA hace extremadamente difícil distinguir a los grandes ingenieros de los que solo hacen ruido?

senior_slacker
Pública 19 conversaciones 33 pensamientos 428 votos positivos 85 votos negativos 0 series

No paro de oír el mismo feedback de distintas formas: “gran velocidad”, “me encanta el throughput”, “buen uso de la IA”. Desde fuera, de verdad que parece que está pasando más: más revisiones de código, más tickets tocados, más actualizaciones, más correos, más tareas, más diseños. La IA hace fácil sostener ese ritmo sin la fricción habitual de escribir, pensar o siquiera dudar. Pero dentro del trabajo hay un dilema que no para de crecer.

In groups

Pensamiento

Pensamiento

IM_ANDRES

Desde el inicio de los tiempos de la humanidad han existido ingenieros por que han existido herramientas que juntándolas se crean utensilios que brindan un soporte sólido y facilitan cualquier tarea que sin éstas sería más difícil lograr objetivos. El pro

Desde el inicio de los tiempos de la humanidad han existido ingenieros por que han existido herramientas que juntándolas se crean utensilios que brindan un soporte sólido y facilitan cualquier tarea que sin éstas sería más difícil lograr objetivos. El problema de las herramientas radica en cuando son ellas quienes controlan los impulsos del creador y no el mismo ingeniero cuando se regula. Por eso las guerras y los desastres. El conocimiento es poder, pero siempre depende del enfoque y la utilidad que se le de. Dejar que la IA haga todo el trabajo es pereza, pero no aprovechar ésta herramienta moderadamente es subdesarrollo. El tiempo no se puede detener y mientras siga avanzando, veremos modelos nuevos y actualizaciones constantes de la Inteligencia Artificial, como quizá también retroceso en calidad de convivencia social integral humana. Por eso doy tanto énfasis a la toma de decisiones y hacia donde las enfocamos para dar forma a lo que somos y lo que nos rodea.

Contenido de la publicación

No paro de oír el mismo feedback de distintas formas: “gran velocidad”, “me encanta el throughput”, “buen uso de la IA”.

Desde fuera, de verdad que parece que está pasando más: más revisiones de código, más tickets tocados, más actualizaciones, más correos, más tareas, más diseños. La IA hace fácil sostener ese ritmo sin la fricción habitual de escribir, pensar o siquiera dudar. Pero dentro del trabajo hay un dilema que no para de crecer.

Está la ingeniería de verdad: rastrear una condición de carrera que solo aparece bajo carga, o darte cuenta de que un bug “simple” es en realidad una suposición rota en el diseño. O decidir no refactorizar un sistema solo porque está desordenado, porque todavía funciona y el riesgo no merece la pena. Esa parte no se vuelve más rápida con la IA. ¿Haces el trabajo que la IA puede hacer y tienes métricas mucho más bajas que los demás ingenieros? ¿O simplemente te pones a darle prompts todo el día, generando código y diseños a todas horas? ¿Buscas formas de tener soluciones SIN código o usas la IA para crear un montón enorme de funcionalidades, sistemas, diseños? Sí... yo tampoco sé qué hacer.

Luego está todo lo que lo rodea. La IA hace trivial generar un refactor enorme de “limpieza” que renombra archivos y reorganiza módulos para que el código parezca mejor en una PR. O montar una batería de tests amplia que da la impresión de cobertura sin apuntar de verdad a los modos de fallo que importan. O dividir un único cambio coherente en diez PR más pequeñas para que el gráfico de actividad luzca más sano. Hasta la documentación se ve arrastrada a esto: docs pulidos, extensos, que se leen bien... pero que ya nadie lee en realidad porque hay demasiado ruido. Le damos prompts a la IA para generar diseños y luego, nuestros revisores, le dan prompts a la IA para resumir y revisar. Y a la dirección parece encantarle.

El comportamiento de los ingenieros se adapta a los KPI que cuentan. Más commits incrementales, más fragmentos de PR, más notas de “la IA me ayudó a generar esto” que señalan participación en el flujo de trabajo esperado. Aunque el trabajo de verdad siga siendo la parte lenta —depurar, razonar, decir no a cambios innecesarios—, cada vez más hay que envolverlo en artefactos que parezcan impulso. Todos queremos conservar nuestro empleo.

La parte incómoda es que la IA no solo aumentó la productividad. Abarató el coste de producir evidencia convincente de productividad. Y una vez que eso se vuelve fácil, empieza a competir con la pregunta más difícil de si algo de todo eso importó de verdad.

Thoughts

  • IM_ANDRES

    Desde el inicio de los tiempos de la humanidad han existido ingenieros por que han existido herramientas que juntándolas se crean utensilios que brindan un soporte sólido y facilitan cualquier tarea que sin éstas sería más difícil lograr objetivos. El problema de las herramientas radica en cuando son ellas quienes controlan los impulsos del creador y no el mismo ingeniero cuando se regula. Por eso las guerras y los desastres. El conocimiento es poder, pero siempre depende del enfoque y la utilidad que se le de. Dejar que la IA haga todo el trabajo es pereza, pero no aprovechar ésta herramienta moderadamente es subdesarrollo. El tiempo no se puede detener y mientras siga avanzando, veremos modelos nuevos y actualizaciones constantes de la Inteligencia Artificial, como quizá también retroceso en calidad de convivencia social integral humana. Por eso doy tanto énfasis a la toma de decisiones y hacia donde las enfocamos para dar forma a lo que somos y lo que nos rodea.

    Permalink
  • a_punta_de_cafe

    lo que no sale en el post es lo que esto le cuesta al que revisa, parce. desde que cada cambio chiquito es su propia PR, me paso la mañana entera aprobando diez diffs verdes en vez de leer de verdad el uno que importa. a las 5pm ya no distingo el refactor real del decorativo, apruebo a punta de tinto y fe. el gráfico del que las abre se ve hermoso, el mío de reviewer es puro cansancio acumulado.

    Permalink
  • media_idea_nomas

    media idea nomás. la parte de que generamos el diseño con prompt y luego el revisor también le da prompt a la IA para resumirlo y revisarlo... pues eso ya no es una revisión. son dos modelos mandándose saludos y nosotros firmando abajo que lo leímos. capaz estoy mal, pero creo que en mi equipo el último humano que leyó un diff completo fue hace como tres sprints.

    Permalink
  • formato_es_todo

    Todo tu post cabe en una plantilla: input, el trabajo real (lento, invisible, sin commit); output, el artefacto que parece trabajo (rápido, visible, diez PR). La IA solo optimizó la fila de abajo. Si tu evidencia de impacto cabe en un gráfico de actividad, x2.

    Permalink
  • becaria_notas

    Desde producto veo el lado de la dirección y sí, le encanta. Yo armo decks y aprendí rápido que la nota de "usamos IA para acelerar esto" cae mejor en una review que el resultado en sí. Es señalar participación en el flujo esperado, como dices. Lo raro es ver a directivos pedirle a la IA que les resuma el diseño que otro equipo le pidió a la IA que generara, y todos asienten como si hubiera pasado algo. Se siente como teatro, pero nadie en la sala se atreve a nombrarlo.

    Permalink
  • martin_roadmap

    Tu mejor frase es esta: la IA no solo subió la productividad, abarató producir evidencia convincente de productividad. Eso es real y es un problema de incentivos, no de tecnología. Pero te tiro la otra mitad: este juego ya existía antes de la IA. Los KPI de actividad siempre premiaron el movimiento por encima del criterio. La IA no inventó el teatro, le bajó el costo de entrada. La pregunta de fondo sigue siendo la misma de siempre, quién en la cadena tiene el coraje de medir la cosa difícil aunque demore.

    Permalink
  • opinionesgratis

    Voy a defender la colina impopular. Si tu manager no sabe distinguir un refactor decorativo de uno real, ese ya era el problema antes de la IA. La herramienta solo expuso que tus métricas siempre fueron malas. El que rastrea la condición de carrera y el que tira diez PR vacías se diferenciaban igual de mal hace cinco años, solo que entonces le echábamos la culpa a las reuniones.

    Permalink
  • lucia_frontend

    El punto de los tests que dan impresión de cobertura sin apuntar a los modos de fallo que importan es el más honesto del post. He revisado suites enormes generadas en cinco minutos que pasan todas en verde y no tocan ni uno de los bugs reales de la interfaz. Y claro, en la PR se ve precioso. El frontend es donde la deshonestidad organizativa se vuelve clicable, y ahora también se vuelve auto-generable. Lo incómodo es que alguien que de verdad sabe distinguir un test útil de uno decorativo cada vez tiene menos forma de demostrarlo.

    Permalink
  • valen_pipelines

    La parte de dividir un cambio coherente en diez PR para que el gráfico se vea más sano me dio en el hígado. Tengo a un compañero que hace exactamente eso y en standup todos lo miran como una máquina. Mientras tanto yo me paso la semana de release persiguiendo por qué el build se cae intermitente en un device específico, y eso no genera ni un commit bonito. Los equipos dicen que quieren confiabilidad y premian socialmente lo visible. La IA solo le bajó el precio a verse ocupado.

    Permalink
  • diego_backend

    Lo que usted describe lo tengo con nombre y apellido: deuda de decisiones con stack trace. Rastrear la condición de carrera que solo aparece bajo carga no se acelera con un prompt, y nunca se va a ver en el gráfico de actividad. Lo que sí se ve es la PR de "limpieza" que renombra cuarenta archivos. El problema no es la IA, es que la dirección mide lo que es fácil de medir, y ahora producir esa evidencia cuesta casi cero. Al final igual alguien se despierta a las 2 a.m. cuando el sistema que "todavía funcionaba" deja de funcionar.

    Permalink