Elliot Morris

If you’re in a sane environment, and I am sorry that many of your aren’t, you are not currently being mandated to use AI tooling. You are however, almost certainly being strongly encouraged to explore these new capabilities as a tool to increase velocity, whether that comes directly from company leadership, or just from the culture at large.

You may have reservations about this, especially if you are a developer who reviews a lot of code and can see how this would allow the vast cohorts of less-than-useful developers to make your life, and the systems you maintain, hellish. If you express this, you have probably heard something along the lines of “Don’t worry, everyone will still always be responsible for their own code”.

You laugh, of course. Even prior to the LLM culture, most engineers did not take responsibility for the code they attempted to ship. It’s not always malicious, most engineers have never been taught that this sort of thing is possible or necessary. This is the primary danger of the “everyone will still be responsible” approach. It’s an obvious, well trodden argument that I don’t feel the need to justify. Your engineers, heck, all your employees, must take responsibility for their work if you want to be a high performing technical organization.

Learning how to take responsibility isn’t a trivial thing, it takes time, skill, quite a lot of painful self reflection, and consequences (perish the thought!). It’s the thing that should differentiate a junior engineer from a senior one, but all the juniors have had to lie and say they are seniors now in order to get a job so that’s out the bloody window.

This push to increase velocity is definitionally a push to increase technical debt. Generation of responsibility is not and has never been constrained by fingers or eyeballs, and code without responsibility attached is legacy code, which is technical debt. You simply cannot defer that, responsibility can only exist inside a human.

However, you and I dear reader, we are not reckless engineers, and we do not produce legacy code, so could we increase our output? I contend that no we could not, at least not by very much. The way you hear people talk about velocity increase, you’d be forgiven for thinking that engineers have every symbol of code in our heads from the moment we begin implementation, and that we just can’t vomit it out through our fingers fast enough.

Of course not, at some point during any given implementation, you complete your understanding of the change and how it fits into the surrounding systems. At that point you are ready to be responsible for it, and you are finished. Maybe you still have a couple of hours of typing to do, but that’s a trivial detail. I sure hope all this LLM hype has not been about saving those couple of hours of typing, because I promise you, engineers are losing more time to exploring their own nostrils than they are to this sort of thing, it’s just not worth the squeeze.

If you are being pushed to increase general velocity, that means that the people who are pushing you don’t understand what velocity actually is, and can’t measure whether it is going up or down. I don’t like the word to be honest, momentum might be a better fit, but anything that tries to make a speed analogy isn’t really a good idea.

To tangent from a tangent, why is there such an insistence in framing our work in terms of footraces, and yet such a resistance to defining an actual finish line?

Speaking of tangents, what about tangential tasks? The one-off scripts, boilerplate, that sort of thing? (Why so many are obsessed with boilerplate I will never know, perhaps it is something I am not javascript enough to understand). This is a slightly richer area, as it comes with a less urgent, but still non-zero, need to inject the task with true responsibility. However, even if you could 10x the speed at which these sorts of tasks are accomplished, (you can’t), we’re still only talking about insignificant tangential work.

Don’t be fooled by “Everyone will still be responsible for all their own code.” It’s a nice statement, but meaningless. If not coupled with a implication to increase delivery frequency, then it is just restating what should already be true. If it is coupled with that implication, then it is logically inconsistent and foolish.