
poteto@poteto
el volumen sí importa miren, lo entiendo. si eras ingeniero antes de que llegaran los agentes, tienes toda la razón en desconfiar de que se usen las líneas de código y el número de PRs como métrica de cualquier tipo de productividad. ¡y estoy de acuerdo! o al menos, lo estaba. para explicarlo más fácil, voy a hablar desde la perspectiva de alguien que es ingeniero en un equipo grande de al menos 50 personas. antes el volumen no importaba porque nos enfocábamos en el impacto. podías tener mucho impacto incluso con pocos PRs: por ejemplo, podías hacer un cambio de configuración de una línea y ahorrarle millones de dólares a la empresa. pero antes de los agentes, las veces que vi que el volumen entraba en la conversación eran para los casos atípicos. en el extremo negativo podías tener a alguien con problemas para rendir, en el otro a alguien del arquetipo "máquina de programar". una máquina de programar era alguien que podía encerrarse en un cuarto y salir con una pila de PRs que resolvían un montón de problemas. así que el volumen sí importaba, pero solo en los extremos de la distribución, y combinado con el impacto. si alguna vez trabajaste en una big tech, vas a entender a qué me refiero. lo que pasa con los agentes es que los problemas de las big tech ahora también son problemas de empresas pequeñas y medianas. ¿cómo cambian los agentes este cálculo? bueno, ahora todos tienen la capacidad de volverse una máquina de programar. tienes modelos de frontera increíblemente capaces que escriben código mejor que cualquiera de nosotros, y mucho más rápido. en este mundo, si sigues sacando la misma cantidad de PRs que antes, ¿por qué no te detendrías a preguntarte por qué no estás siendo más productivo? la inteligencia alienígena ya llegó, ¿y aun así no puedes sacar más que una máquina de programar humana? esto me lleva de vuelta a por qué sigo hablando de confianza. si no le has dedicado trabajo a poder confiar en lo que produce tu agente, es muy difícil escalar tu productividad. y sí, este enfoque requiere más tokens, pero yo lo pienso en términos de costo por inteligencia. antes de los agentes, ese costo era muy alto: necesitabas contratar a muchos ingenieros de software con salarios altos de 6 cifras para hacer el trabajo. los tokens todavía son caros hoy, pero es probable que se abaraten con el tiempo si tomas en cuenta el costo de la inteligencia. lo que hoy parece exorbitante probablemente será accesible en 6 meses a un año. un solo ingeniero con agentes puede hacer el trabajo de decenas, si no cientos, de ingenieros, por una fracción del costo. la realidad que creo que todavía no cae es que el trabajo del ingeniero de software realmente cambió. nuestro trabajo ya no es solo producir software (bueno, siendo honesta nunca fue solo el código, pero aguántenme por el bien de la explicación), sino la máquina que escribe el software. esta idea de una fábrica de software, o una cocina Michelin como me gusta llamarla, todavía es un tema de investigación. y es el tipo de cosas que me gusta compartir, no para presumir, sino para mostrarles lo que es posible cuando le pones mucho rigor a usar agentes a escala
volume does matter
look, i get it. if you were an engineer before agents came along, you're rightfully skeptical about lines of code and number of PRs being used as a metric for any kind of productivity. and i agree! or at least, i used to. for ease of explanation i will talk about this from the perspective as being an engineer on a large team of at least 50.
volume didn't matter before because we focused on impact. you could have high impact even with a few PRs: for example you could make a one line config change and save the company millions of dollars.
but before agents, the times where i saw volume come into the conversation were for the outliers. on the negative end you might have someone who is struggling to perform, on the other end you might have someone who was a "coding machine" archetype. a coding machine was someone who could just lock themselves in a room and emerge with a stack of PRs that solve a huge number of problems. so volume did matter, but only at the tail ends of the distribution, and combined with impact.
if you've ever worked at a large tech company before, you'll get what i mean. the thing about agents is that big tech co problems are now small-medium co problems as well.
how do agents change this calculus? well, everyone now has the ability to become a coding machine. you have incredibly capable frontier models that can write code better than any of us, at a rate much faster than we can. in this world, if you're still producing the same number of PRs as before, why wouldn't you pause to wonder why you're not being more productive? alien intelligence is here, and yet you can't outship a human coding machine?
this brings me back to why i keep talking about trust (https://x.com/poteto/status/2102050467505430555). if you haven't put in the work to trust your agent's output, it is very difficult to scale up your productivity.
and yes, this approach does require more tokens, but i think about this in terms of cost per intelligence. before agents, this cost was very high - you needed to hire many software engineers with high 6 figure salaries to do the work. tokens are still expensive today, but are likely to get cheaper over time (https://x.com/theo/status/2107924138094703084) factoring in the cost of intelligence. what looks exorbitant today will likely be affordable in 6 moths to a year. a single engineer with agents can do the work of tens if not hundreds of engineers, at a fraction of the cost.
the reality that i don't think has hit yet is that job of the software engineer has truly changed. our job is not merely to produce software any longer (well tbh it was never only about the code, but bear with me for the sake of the explanation), but the machine that writes the software. this idea of a software factory, or a Michelin kitchen as i like to call it, is still a topic of research. and it's the type of stuff i like to share, not to flex, but to show you what's possible when you put a lot of rigor into using agents at scale