alt Hacker NewsThis matches my own experience, pre-AI. As I've moved from IC to having a team over the years, more code was being written than I could possibly understand at the depth I would have if I'd written it myself.
The skill I learned is exactly as you describe: understand the system. For me, this means "boxes and lines", the components and how they interact. I've encouraged developers on my team to make sequence diagrams part of their deliverable, because it helps both of us put the code in the context of the system.
The boxes can be opaque because I know the boundaries and expected inputs and outputs. This tells me when I need to go in a box: is it sending a malformed message? I can trace that back into the code.
I think that's the skill we have to cultivate now that coding agents produce far more than we can review line-by-line. The system view is the map, and the boundaries tell us where to go hunting inside the box.
Replies
And how will you have the skill to go hunting inside the box if all you ever do is high level systems work?
Even if you're relying on extremely thorough test and validation, well someone who understands things at a low level has to write said tests and validations.
So long as humans are legally liable, this approach will only work until someone gets sued. Which means human experts will need to still exist and be trained, perhaps their training will just have to be more explicit rather than gained through the act of building products. Companies will hate this.
Having a team implies that one was a manager or in a similar role.
These roles are nothing like a technical specialist. It doesn’t hurt to know a few things about the general technical details, but a manager or PO getting involved into technical decisions or being too deep in the code is generally an anti-pattern.
Not comparable with a sloperator. The sloperator is ultimately responsible for what their agents spit out. If something bad happens and the law comes looking, it’s their ass on the line. A sloperator will have to set up and manage some review or QA process by themselves. They will occasionally have to look at code, even if this goes against the entire raison d’être of the sloperator and maybe fix it or ask their minions to.
The “yer a manager Harry!” cope needs to be put to pasture. No company thinks that these people are an actual manager or actually managing anything. They’re still ICs.
I've been trying to adopt this approach and struggling. Any advice on how to learn this sort of systems approach? It doesn't seem to come very naturally to me
I almost agree with you.
Yes, we should be building systems.
No, it’s not equivalent to managing a team, because the AI has no skin in the game.
A decision an AI makes is not equivalent to a decision a human makes because the consequences are not equivalent. An AI cannot be fired; cannot be sexually rejected; cannot disappoint its loved ones; cannot spend a cold night on the streets. A human who makes decisions with complete disregard to material consequences is a human you need to get off your team ASAP because they’re a ticking time bomb: a liability.
So, in building your systems, you need to be sensitive and aware to the fact that AI has no skin in the game.