This 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.

▲

datsci_est_2015 4 hours ago | parent | next [-]

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.

▲

mrothroc 4 hours ago | parent | next [-]

I agree there are differences in the teams, but it sure feels like there is a lot of overlap in the skill I need to deliver software, regardless of who is creating the code.

You raise another point though: agents are not human. The things that drive agentic loops are not at all the things that motivate humans to do good work.

That's probably where the human-management skill ends in this new world. The techniques that get high quality from humans do not apply to agents.

▲

jimbobimbo an hour ago | parent | prev | next [-]

I think of my AI use as me contracting an offshore team (no skin in the game) but I can be as micromanaging as I want to.

▲

viklove an hour ago | parent [-]

Offshore team absolutely has skin in the game, for the exact same reasons OP said -- they want to keep their roof over their head.

AI will never have this. AI is a product, and it has no motivations or self-preservation. The only goal for the AI is to increase your lifetime token spend to maximize profit for corporation.

	▲	geraldwhen an hour ago \| parent [-]
		That’s not been my experience nor the posters, I imagine.

▲

BatFastard 2 hours ago | parent | prev | next [-]

AI may have no skin in the game.

But it will work all night and on weekends. It never gets sick. It never forgets to do something. And as far as I can tell, it does it best work all the time.

That's enough skin for me.

▲

datsci_est_2015 an hour ago | parent | next [-]

You can’t really just redefine “skin in the game” to be “constant iterative code generation”.

Engineers (builders) who recognize that there is a difference in assigning a task to a human and a task to an agent will have a competitive advantage over those who don’t. That’s not to say that agents can’t be used at all, only that how they’re used is critical.

▲

viklove an hour ago | parent | prev [-]

What do we need you for then?

	▲	BatFastard 44 minutes ago \| parent [-]
		I love my AI tools, but if left alone they would cover the front lawn in rabbit holes. For now they need people to make judgement calls. Will this be the case in 5 years, probably. They will certainly be different rabbit holes.

▲

derektank 3 hours ago | parent | prev [-]

This is an odd take. By this logic, you should never hire someone that is financially independent and can walk away from a job.

	▲	scottLobster 3 hours ago \| parent \| next [-]
		You just stated the reason why engineers have a hard time getting hired as baristas when they're laid off. The hiring restaurant knows you can and will walk as soon as you land another engineering gig.
	▲	datsci_est_2015 2 hours ago \| parent \| prev [-]
		Well, partially. Trust fund kids are notoriously poor employees, yes. Unless what they’re doing is somehow motivated by status or passion. Which now we’re back to those human motivations like sexual rejection and disappointing people you don’t want to disappoint. But completely unmotivated financially independent people are probably the worst people to have on a team, yes.

▲

scottLobster 3 hours ago | parent | prev | next [-]

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.

▲

mrothroc 3 hours ago | parent | next [-]

How do I personally have the skill? I built it the old fashioned way: decades of doing this, starting with vi and hand coding assembly, through IDEs and high level languages, and now with distributed tracing on ephemeral serverless deployments.

How do juniors develop it? Yeah, that's the tough part. Those years spent slogging through very tedious work got me here. You have to exercise to build muscle. Maybe we need to find some way to let people exercise the skills without the hands-on slog? I'm honestly not sure, how are you seeing it handled where you are?

▲

scottLobster 2 hours ago | parent | next [-]

Yeah that's my point. Sooner or later a human is going to have to go hunting "inside the box", and those humans will have to be capable of doing so competently.

I'm not seeing post-AI training of juniors handled at all, anywhere. The closest thing is what my employer does where for liability reasons every command executed by an AI agent, even as simple as an ls, has to be manually approved by the developer. This has the side effect of walking you through the AI's analysis, which can be quite educational.

Given the general culture of corporate cost-cutting (the whole appeal of AI is it doesn't need a benefits package), it's possible we're heading into a future where people trained pre-AI turn into a dedicated guild of professional troubleshooters, demanding fat paychecks to parachute in and put out fires when a company's giant blob of agents fails and their in-house staff lacks the deep knowledge to figure it out.

	▲	mrothroc an hour ago \| parent \| next [-]
		That approval thing is interesting, for sure. It reminds me of how experts are very deliberate in narrating their thinking for juniors while they work, so juniors can learn the why behind the how. There are definitely companies that are being short-sighted on this. I've seen this come back and bite them (usually, not always). I'd argue that if the company doesn't provide this, then people should rely on their community. I'm lucky enough to live in a place that has lots of meetups and we talk about this. Absent that, there are plenty of active discussions online, as this very thread shows. The bonus of working via the community is that's where you can find a new opportunity if the company doesn't take care of their people.
	▲	adrq 2 hours ago \| parent \| prev [-]
		[flagged]

▲

dist-epoch 2 hours ago | parent | prev [-]

When compilers appeared, junior developers didn't have to develop the skill to understand assembly. Worrying about them not learning that skill because using compilers is so convenient would have been a bad move.

Now the juniors are cooked anyway, but not because they didn't learn the skill of software development.

	▲	mrothroc an hour ago \| parent [-]
		"junior developers didn't have to develop the skill to understand assembly" well that's certainly fair. At the same time, what I saw during that time was that organizations that actively sought to help juniors transition their skills to match the tools did better than those who just left everyone to wander around in the dark.

▲

dist-epoch 2 hours ago | parent | prev [-]

Less than 0.1% of programmers are legally liable for the software they write.

▲

bluefirebrand 5 hours ago | parent | prev [-]

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

	▲	mrothroc 4 hours ago \| parent [-]
		Sure! Make sequence diagrams, or get the agents to do it as part of what they deliver. That's always been very helpful for me to develop a "boxes and lines" view. The boxes are right there across the top and the lines go between them!