La ingeniería ante la automatización del trabajo intelectual

Durante mucho tiempo, construir una empresa de software significó reunir personas capaces de transformar una necesidad en un sistema que funcionara. Ese trabajo requería conocimiento, coordinación y una cantidad considerable de tiempo, y alrededor de esas condiciones se organizaron las carreras profesionales, los equipos y la relación con los clientes. La inteligencia artificial está alterando esa estructura. A medida que los sistemas pueden asumir una mayor parte del desarrollo, empieza a cambiar el valor relativo de las tareas que realizamos y, con él, la forma en que una empresa justifica su existencia. En 42N creemos que el futuro de nuestro trabajo va a depender cada vez más de cómo ayudemos a las organizaciones a transformar su actividad con estas herramientas. Eso amplía nuestra responsabilidad: tendremos que participar de decisiones sobre procesos y personas, además de resolver su implementación técnica.

Nuestra decisión de construir una empresa propia estuvo atravesada por esa inquietud. La posibilidad de desarrollar ideas con recursos que hasta hacía poco resultaban inaccesibles abría un espacio para emprender, pero también cuestionaba el futuro de una actividad que estábamos eligiendo como profesión. Esa tensión sigue presente. Trabajar con inteligencia artificial permite experimentar una expansión muy concreta de lo que podemos hacer y, al mismo tiempo, advertir que algunas de las capacidades por las que una empresa contrataba a un profesional empiezan a estar disponibles de otra manera. Nos parece necesario reconocer ambas cosas para tomar decisiones que sigan teniendo sentido a medida que la tecnología avance.

La transformación se vuelve especialmente visible cuando se la observa desde la experiencia de haber aprendido a programar durante estos años. Al principio, un asistente ayudaba a entender un error o sugería cómo completar una función; la persona conservaba casi toda la responsabilidad de convertir esas respuestas en una aplicación. Después, las herramientas incorporaron el contexto del proyecto y comenzaron a modificar archivos, ejecutar programas e investigar sus propios fallos. Hoy, una parte creciente de nuestro trabajo de desarrollo consiste en definir objetivos, preparar información y evaluar lo que los agentes producen. Haber recorrido ese cambio hace difícil sostener que estamos ante una mejora de productividad que dejará intacta la organización del trabajo.

Por eso creemos que sería un error construir nuestra estrategia alrededor de lo que los modelos todavía hacen mal. Sus limitaciones actuales importan para decidir qué podemos delegar hoy, pero ofrecen una base inestable para proyectar una carrera o una empresa. Una tarea que exige intervención constante puede volverse delegable con la siguiente generación de herramientas. Necesitamos una organización que pueda incorporar esos avances y seguir entendiendo los problemas que resuelve, incluso cuando cambie por completo la manera de implementarlos. Prepararla exige revisar cómo formamos a las personas, cómo gestionamos los proyectos y por qué nos contratan nuestros clientes, antes de que el cambio aparezca como una urgencia.

La reorganización del trabajo de ingeniería

La experiencia publicada por PostHog permite observar una parte de esta transición. La empresa informó que, en cuatro meses, las solicitudes de cambio de código abiertas por agentes en su repositorio principal pasaron de aproximadamente el 20 % al 70 %. Al describir el trabajo de sus ingenieros, pone el acento en comprender qué sucede con el producto, decidir qué conviene hacer y organizar la implementación y su evaluación. Es un caso particular, con cifras publicadas por la propia compañía, pero muestra un cambio que va más allá de escribir más rápido: al automatizar una parte importante de la ejecución, también se modifica la distribución del trabajo alrededor de ella.

Para un profesional, esa redistribución puede ser estimulante y difícil a la vez. Durante años, aprender un lenguaje o dominar una tecnología ofrecía una manera relativamente clara de progresar. Hoy es posible producir una solución en un entorno que todavía no se comprende del todo, y esa posibilidad vuelve menos evidente la relación entre lo que alguien entrega y lo que sabe. También cambia la experiencia de quien ya tiene conocimientos: una tarea que antes permitía ejercerlos de manera directa puede pasar a consistir en orientar y revisar a un agente. Adaptarse exige aprender a trabajar con esa distancia, conservando la capacidad de intervenir cuando las decisiones del sistema necesitan ser cuestionadas.

Sería apresurado concluir que toda esa responsabilidad puede reducirse a redactar buenas instrucciones. Pensemos en una empresa que quiere automatizar la gestión de pedidos. Antes de desarrollar una solución, hay que entender cómo se reserva el stock, qué ocurre cuando un cliente modifica una compra y quién puede autorizar una excepción. Parte de ese conocimiento puede estar documentado; otra parte suele aparecer recién al conversar con quienes hacen el trabajo. Un agente puede ayudar a investigar, proponer alternativas e implementar decisiones, pero la empresa necesita un proceso que permita resolver desacuerdos y establecer qué resultado considera correcto. La calidad del software depende también de cómo se llega a esas definiciones.

La descripción de Anthropic para el puesto de Forward Deployed Engineer ofrece un ejemplo concreto de esa necesidad. Combina programación y experiencia con modelos con la capacidad de trabajar directamente con clientes, comprender sus procesos y llevar aplicaciones a producción. El interés de ese perfil está en reunir conocimientos que a menudo se distribuían entre varias funciones. Para 42N, esa combinación orienta el tipo de capacidades que queremos desarrollar: profundidad técnica, comprensión del negocio y suficiente cercanía con la operación para saber si una implementación está resolviendo el problema que la motivó.

Eso no significa que la especialización pierda valor ni que cada integrante de un equipo deba saber hacer todo. Un sistema sigue necesitando conocimientos sobre datos, infraestructura, seguridad o diseño, y automatizar su construcción puede aumentar la importancia de algunas de esas decisiones. Lo que esperamos es una relación más estrecha entre las especialidades y los resultados del producto. Un ingeniero de datos necesita entender qué decisiones dependen de la información que prepara; quien diseña una integración debe conocer sus consecuencias sobre el trabajo de otras áreas. Los agentes amplían la capacidad de ejecución de esos perfiles, pero aprovecharla requiere que el equipo pueda coordinar conocimientos y resolver prioridades con claridad.

La formación merece una atención particular dentro de esta reorganización. Muchas tareas que se vuelven más fáciles de delegar fueron también la manera en que un profesional adquiría experiencia. Un estudio de Anthropic sobre aprendizaje con IA, realizado con 52 desarrolladores que debían utilizar una biblioteca de Python desconocida para ellos, encontró una menor comprensión posterior en el grupo asistido. El experimento es acotado, pero plantea una dificultad que las empresas necesitan considerar: obtener un resultado no garantiza haber desarrollado el conocimiento necesario para evaluarlo. Si esperamos contar con profesionales capaces de orientar sistemas cada vez más autónomos, tendremos que cuidar deliberadamente cómo adquieren esa capacidad mientras trabajan.

Las consecuencias para la empresa

El efecto sobre el empleo depende de algo que la capacidad técnica, por sí sola, no permite resolver: cuánto trabajo adicional aparece cuando producir software se vuelve más accesible. Una organización puede aprovechar la automatización para hacer lo mismo con menos personas, ampliar los proyectos que desarrolla o combinar ambas decisiones. Incluso si la demanda total de software crece, las oportunidades que se abran pueden requerir conocimientos distintos de los que dejan de ser necesarios. Por eso nos parece insuficiente tanto asegurar que habrá lugar para todos como anunciar la desaparición de una profesión entera. La transición puede crear actividad y desplazar trabajadores al mismo tiempo, y su costo dependerá en parte de cómo se preparen las organizaciones.

Los escenarios económicos que publicó Anthropic ayudan a entender esa diferencia entre capacidad tecnológica y resultado social. Su análisis de Estados Unidos hacia 2030 contempla distintas velocidades de avance y adopción, con consecuencias muy diferentes para el crecimiento y el empleo del conocimiento. No ofrece una trayectoria inevitable, y sus resultados no pueden trasladarse directamente a una empresa argentina. Para nosotros, su utilidad está en mostrar por qué conviene preparar decisiones que puedan sostenerse bajo más de un futuro posible. Formar al equipo, ordenar la información y revisar los procesos puede ser valioso tanto si la automatización avanza de manera gradual como si lo hace mucho más rápido de lo previsto.

También hay una consecuencia comercial que quienes desarrollamos software debemos asumir. Si el esfuerzo de implementación disminuye en determinados proyectos, es razonable esperar presión sobre los precios y los plazos, además de nuevas alternativas para los clientes. Una empresa que explica su valor principalmente por las horas necesarias para escribir una aplicación tendrá que revisar ese argumento. Esto vuelve más importante poder identificar un problema relevante, justificar la solución propuesta y acompañar su funcionamiento. Para 42N, implica construir una relación con el cliente en la que el desarrollo forme parte de una responsabilidad más amplia sobre el resultado, con alcances y compromisos que podamos explicar y cumplir.

Esa responsabilidad exige medir la mejora en el proceso completo. Una reducción del tiempo de programación puede perderse después en revisiones, correcciones o dificultades de implementación. En un análisis publicado por DORA en marzo de 2026, ingenieros de Google describieron cómo parte del tiempo ahorrado al generar código se trasladaba a su verificación. La observación importa para cualquier empresa que evalúe incorporar estas herramientas: necesita saber qué ocurre con la demora que experimenta el usuario, la carga que queda sobre el equipo y el costo de sostener la solución. Contar cuántas tareas ejecuta un agente deja buena parte de esa evaluación sin responder.

La autonomía también obliga a revisar cómo se distribuye la autoridad. Un sistema que recomienda una acción tiene consecuencias distintas de uno que puede modificar información, comunicarse con un cliente o ejecutar una operación. A medida que ampliamos sus permisos, necesitamos definir qué puede decidir, qué evidencia debe conservar y en qué situaciones corresponde que intervenga una persona. Compartimos, en ese sentido, el criterio de Simon Willison sobre la entrega de software: quien propone un cambio debe acompañarlo con evidencia de su funcionamiento. Llevar ese criterio a una organización requiere construir procedimientos que permitan verificar resultados y asignar responsabilidades incluso cuando buena parte de la ejecución está automatizada.

A una escala distinta, Dario Amodei examina en «We Must Pace the Frontier» la dificultad de mantener la seguridad al ritmo del desarrollo de los modelos más potentes. Propone moderar ese avance para dar tiempo a la evaluación y a la prevención de riesgos, con participación externa y coordinación entre empresas y gobiernos. Se refiere al desarrollo de la tecnología de frontera, y su propuesta no implica una pausa acordada que las demás empresas puedan dar por hecha. Nuestra lectura para el ámbito de la adopción es más acotada: la velocidad con la que podemos automatizar una tarea debe evaluarse junto con nuestra capacidad de comprender y controlar sus efectos. Una herramienta puede estar disponible mucho antes de que una organización esté preparada para darle autoridad sobre una operación importante.

La posición que asumimos en 42N

En 42N queremos acompañar esa preparación mediante un trabajo que reúna consultoría, desarrollo, automatización y formación. El punto de partida es conocer cómo funciona la empresa: puede haber una oportunidad importante en una tarea repetitiva, pero también puede ocurrir que la demora provenga de información incompleta, responsabilidades confusas o sistemas que no se comunican. Automatizar sin comprender esas condiciones puede conservar el problema y volverlo más difícil de detectar. Nuestro aporte debe consistir en estudiar esas relaciones con el cliente, definir una intervención, construirla y acompañar su adopción hasta poder comparar lo que ocurre antes y después. Con esa evidencia se puede decidir si conviene ampliar la solución, modificarla o dedicar el esfuerzo a otra necesidad.

Nos importa, además, que ese proceso deje conocimiento dentro de la empresa. Una implementación pierde parte de su valor si quienes trabajan con ella no entienden sus límites o dependen de un tercero para interpretar cada resultado. Acompañar la adopción incluye explicar las decisiones, formar a las personas involucradas y dejar mecanismos para reconocer cuándo hace falta intervenir. También exige conversar sobre cómo cambia el trabajo de cada rol. La incorporación de IA puede alterar tareas, expectativas y oportunidades de aprendizaje; tratarlas como consecuencias secundarias aumenta la probabilidad de que una buena solución técnica encuentre dificultades que podrían haberse abordado desde el comienzo.

Pensar en 2027 tiene, para nosotros, el sentido de asumir un horizonte cercano de preparación. Las herramientas que utilizamos van a cambiar, y algunas decisiones de hoy necesitarán ser revisadas. Aun así, hay trabajo que una empresa puede comenzar ahora: conocer sus dependencias, identificar dónde pierde capacidad y desarrollar personas que puedan comprender tanto su operación como las posibilidades de la tecnología. Esperar a que el futuro sea más previsible posterga ese aprendizaje; incorporar cada novedad sin una dirección clara tampoco lo garantiza. Preferimos avanzar sobre problemas concretos y usar los resultados para orientar las decisiones siguientes.

La posibilidad que vemos en este momento es considerable. Un equipo chico puede intentar proyectos que antes excedían sus recursos, y empresas que convivieron durante años con limitaciones operativas pueden encontrar nuevas formas de resolverlas. Queremos que 42N contribuya a hacer posible ese trabajo, con la disposición de aprender que exige una tecnología cambiante y con la responsabilidad que merece cualquier decisión sobre el funcionamiento de una organización. Por eso abrimos esta conversación con quienes ya se están preguntando qué va a cambiar en su empresa: cómo preparar a sus equipos, qué conviene empezar a transformar y qué condiciones necesitan construir para hacerlo bien. Es en ese trabajo compartido donde queremos que esté el valor de nuestra ingeniería.

42N — Consultoría, desarrollo y automatización