Hacker News Reader

Comment by mrothroc | Hacker News Reader

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.

View on HN

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.

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.

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

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.

Covering up work history could work. Though they might suspect something when you reassemble the cappuccino machine to operate autonomously.

Or when you desperately search for the undo button on the mop

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.

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.

What do we need you for then?

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.

2 years ago your AI tools didn't exist, and you're trying to make predictions 5 years out.

I wish I could be as bliss about the whole situation as you are!

Ignorance is BLISS!

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.

> It never forgets to do something. And as far as I can tell, it does it best work all the time.

I wish that were true. Even Opus 5.5 still ignores instructions and finds things it missed on a daily basis.

Its better then 80% of people I have hired.

You are aware that's a very bad flex.

It'd be one thing to highlight bad teams you've been thrown in to; its a very different one to state that about the teams you've hired.

What was it exactly that prevented you from building good teams, with good process supporting them; that limited you to 20% good hires??

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.

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.

That’s not been my experience nor the posters, I imagine.

I think both you and said poster have misunderstood what "skin in the game" actually means.

His point is that the offshore structure is deeply dysfunctional.

The consulting agency tells you they hired the best senior developers, then hand the project over to a junior developer that doesn't know anything about your project and could be reassigned at any time.

> doesn't know anything about your project

I consulted for a client who cut off an offshore consulting firm after they billed 40 hour for a one line CSS border-color fix change. We were suspicious of billing fraud, but the quality of developers we'd observed wouldn't allow us to rule out hanlon's razor.

Of course AI can be fired: by canceling the subscription OR stop using its API.

Every single manager and company wants to fire you over AI

The consequences can be made equivalent. Reinforcement training.

The 'skin in the game' is I go to a competitor and use a different product.

Models have plenty of skin in the game during training, but zero during inference

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.

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?

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.

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.

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.

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

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

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

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!

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.

Reply on news.ycombinator.com