[−]bluefirebrand · 2026-10-10 Sat 18:23 UTC ·
link
> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together
Which is frankly exhausting to do when you have to keep up with the rate of LLM changes
[−]__MatrixMan__ · 2026-10-10 Sat 18:40 UTC ·
link
I can sling code at about 20x speed with an LLM, but I can only understand it well enough to support it at 5x speed and I can only make decisions that won't piss off the rest of the company at about 3x speed. My job as a software engineer is to therefore slow down to working merely 3x faster than before despite the extra headroom that the LLM gives me. Anybody can give into the seduction of new features poorly understood, to be a specialist means to bother spending the extra time.
Or at least that's the current model I'm playing with.
This is my dilemma as well currently, because there's no obvious place to draw that line. The boundaries are all subjectively defined.
I could change a whole UI completely in 30 minutes to something fundamentally better but then 30 people would all wake up and be upset they weren't consulted and need training for it. That training and consultation will take hours and hours. And probably generate feedback - some of it correct, some of it misguided - that needs to be human negotiated, taking more hours. The effective maximum rate of change is limited so dramatically more by other factors than the technical implementation that we have to completely redesign process now to cater to those factors.
We are in a weird space now because most of the process is still built around a presumption that technical implementation is a lot of work. The main reason to be upset that you weren't consulted about a change is because there's a presumption that you will be stuck with it - ie: it's a lot of work to change it back. But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
[−]__MatrixMan__ · 2026-10-10 Sat 21:41 UTC ·
link
I've been handling it as a sort of voluntary A/B test.
A is what you're used to, B is what I recommend. If I can convince people to start using B instead, I can look at the metrics for A and conclude that it's effectively dead, and then I can remove it.
It's working out for me, but maybe not a fair comparison because I only have something like 15 users.
Yeah it's an interesting one - I have had the same thought process. If code is free, and I trust the tests and the review process, why not deploy a different branch to production for every user that wants one? it's only at the point where shared resources such as database schemas conflict that it becomes an issue, but a large slice of user requests don't even touch those. If something gets deployed broken in one branch, someone can flip branches and use the one that works. As long as the system maintains strongly enforced safety boundaries, a thousand roses can bloom outside of those boundaries.
It does beg the question where it all leads however ...
> But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
... but it isn't free. You're introducing a certain amount of entropy and drift every time you let the coding agent loose on it. There's a hidden cost of loss of cohesion that comes with changing anything and then changing it back, and while that cost exists with human developers, too, the pace at which they work and think limits the damage and the risks. LLMs just compound them, but the consequences are long-term, while the incentives are to do the thing now.
Which is frankly exhausting to do when you have to keep up with the rate of LLM changes
Or at least that's the current model I'm playing with.
I could change a whole UI completely in 30 minutes to something fundamentally better but then 30 people would all wake up and be upset they weren't consulted and need training for it. That training and consultation will take hours and hours. And probably generate feedback - some of it correct, some of it misguided - that needs to be human negotiated, taking more hours. The effective maximum rate of change is limited so dramatically more by other factors than the technical implementation that we have to completely redesign process now to cater to those factors.
We are in a weird space now because most of the process is still built around a presumption that technical implementation is a lot of work. The main reason to be upset that you weren't consulted about a change is because there's a presumption that you will be stuck with it - ie: it's a lot of work to change it back. But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
A is what you're used to, B is what I recommend. If I can convince people to start using B instead, I can look at the metrics for A and conclude that it's effectively dead, and then I can remove it.
It's working out for me, but maybe not a fair comparison because I only have something like 15 users.
It does beg the question where it all leads however ...
... but it isn't free. You're introducing a certain amount of entropy and drift every time you let the coding agent loose on it. There's a hidden cost of loss of cohesion that comes with changing anything and then changing it back, and while that cost exists with human developers, too, the pace at which they work and think limits the damage and the risks. LLMs just compound them, but the consequences are long-term, while the incentives are to do the thing now.