I think the most important way someone could be able cultivate breadth of understanding as well depth when needed is to be able to truly understand all of the things that are touched when someone uses the system, step by step. This doesn’t require deep knowledge in any one aspect of the system, but it does require someone to be curious, be open, and be willing to put themselves in the users shoes and use the feature, and then switch back into the developers mind and map user action to where in the codebase is being activated and why. And be willing to go back and forth. The interesting thing is that agents can help us, but the exercise loses its value if the agent just maps it out for us. We need to be in the process of discovery in order to build our own mental model.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I like the analogy. It feels right. But I don't think it actually is, because it leans hard on the _feeling_ of failure, vs. the actual failure.
The failure that actually matters here is product failure. Angry users. Security incidents. Downtime. Broken workflows.
Stressed and uncomfortable developers have, historically, been a leading indicator of product failure. Software is complex and when devs can't handle the breadth of ownership + the depth of expertise at the same time, it means bad work that leads to product failure. It's not clear that agents fail in the same way, or that our collective intuition about how and when to trust agents is sufficiently developed to predict product failure in the same way.
As anecdata: I know a bunch of growth-SaaS/last-batch-of-IPO companies where the devs are all stressed, the feature ship rate is up, and incidents are down. All at the same time.
So yes, quick learners and just-in-time depth is important, but so is intuition about where discomfort is going to produce true failure. The discomfort isn't a feeling to throw away, simply trusting that you'll learn everything in time. Ownership requires holding a model of the system in your head and proactively steering where you dive.
I think that this was true pre-attention economy. If you look at security incidents and other prod issues, they rarely move the needle today. I work at a hyperscalar and we have been shipping 40% more bugs to prod since 2023 year-to-year, yet user growth and revenue is up about 25% similarly due to more features and more ads.
I think that the whole premise of that failure affects things is based on a older model. You kind of assume that:
1) users are able to easily gain information about alternatives. We have seen that since LLMs replaced search engines, we have much less churn.
2) users are not behaviorally addicted/pushed into patterns. We have patterns that utilize users to keep using the app by exploiting their cognitive weaknesses
3) users have the mental fortitude and stamina to learn new tools instead of accepting flaws in the one they are used to
Some failures and bugs in prod don't matters as much
Almost the entire structure of software oriented companies, and why devs are expensive, are to prevent these sorts of errors. That job has gotten harder, and in some places impossible as management forces more trust on LLMs and reduces the capacity of devs to look. This is less of a problem in existing products in production and existing cultures - revenue is protected. Eventually those structures break down, as does the user perception of quality. Once the brands have taken enough knocks, it accelerates.
I agree that not all failures matter (most don't, in fact). On the other end of the spectrum, I know of a bunch of seed/series A startups that basically operate under a model where they ship everything and fix the stuff people complain about. As long as you do that fast enough, the median user experience is pretty good, because only the first n% actually see the problem before a fix is live.
I'll go out on a limb and guess that at a hyperscaler, shipping a bug to prod means hitting canary or 1% of traffic. Seems fine!
I think my point still stands, even as the shape of failures shift. There's certain ones that still hurt (data corruption, exploited security holes, etc.) because they're hard to notice. It might even be that the primary goal of ownership is to develop intuition about where those failures are likely to happen.
Wait, how do working at a hyperscaler (that's a datacenter provider) and using an addictive app for uhm retention go together? I imagine a gamified AWS provisioning and billing app, but surely that's not it?
This very thing. "Shipment of 40% more bugs and fixing only in response to user complaints" could be done in social streams or advertising tech, but not in finance and trading where margin for errors is close to zero.
A small bug implemented by an agent in the way R-multiples, stop loss distance, or P&L heatmaps are computed will never be complained about by the user—either he will trade incorrectly and lose his money, or see that single off-by-one difference compared to exchange ledger and churn forever.
HN is one of the few sites where someone can launch into an actual villain monologue, the kind you'd read in leaked corporate emails, and receive approximately no negative reaction.
If this is the face of our industry, that might explain a lot of things...
You can take the right path and in the end no-one wants to use your product because it's not as engaging.
Instagram tried to take the "good" path in 2014 and lost 90% market share to TikTok who attentionmaxxed things. Then they had to take the exploitative path to claw back users.
As long as it's not regulated for everyone at the same time, you need to do this for survival of your product.
It's more like it doesn't matter if you sell the most organic, free range, ethically sourced, nutritious, tasty ice cream if your competition is allowed to put cocaine in theirs and get all your customers.
TikTok would survive and do just fine even if Instagram decided to cede the market to them
I am afraid there is a demand for the torment nexus, and until govt steps in, you're out of luck and behavioural surplus is there for the taking by any means.
Many bad things that people do stem from weakness or inner pain. So it's helpful to be reminded from time to time that some people deliberately, thoughtfully, calmly and systematically devote their lives to harming other human beings -- that is, to evil. We should be grateful to augment_me for this reminder.
> Ownership requires holding a model of the system in your head and proactively steering where you dive.
Absolutely, and the feeling of discomfort is a signal that you need to dive, a signal that your mental models might need updating. I think that builds up over time through many dives
Site is down, but one thing in particular that needs close attention: db schema. I've found that LLMs make awful normalization decisions; you can limit the fallout somewhat by modularizing database access, bit it still inevitably bleeds over into the object model etc. On AI heavy projects I tend to pause feature development every few days for code & schema review, and subsequent cleanups.
Just do the schema by hand. It forces so much downstream alignment that you can almost prefer to use the schema and any associated comments over prompting the model directly.
If you don't know what your schema should be, then I think this is the dead canary in the vibe coding coal mine. Back up to the design phase and talk to the robot about the domain until you have a really strong conviction about its tuples and relations.
With agents code has gotten really easy to shape, like fabric. If want to build something rigid, you'd want to introduce sturdy architectural structures to stretch out the fabric of agentic code.
Data and its shape is one such rigid structure. It will stay with you long after the code around it has been replaced. You do want to be intentional about it and build intuition for it.
Once you have that in place, you can stretch out a web of agentic fabric across it, and pin it down with tests.
My approach is similar. I review all changes that touch persisted data formats, wire protocol, and/or public API surface: things with bad consequences if they are wrong and neatly divide the project up. The exact boundaries vary by the project, but once I establish what they are, I can really relax about the other parts of the code, because I know they will be cheap to fix if wrong.
And object-oriented design decisions, if you care I guess. I haven’t yet gotten access to the models that have any good intuition about what makes a good class and how to name it.
Naming, in general, is very similar to what I expect from colleagues who have weak English-as-a-second-language skills.
You let it run too wild and you’re suddenly left trying to reason why your LLM is trying to add an interaction between an Intermediator and a FromSpinMaxWriter.
FYI, your site is blocking me for some reason. I'm just on a regular residential connection in the US, no VPN or whatever. Something's screwy in your WAF.
I dont know if i fully agree to it. ppl are still trying to find the aspects that AI do not handle (or do very well) yet, to define the irreplaceable value of human (humanity?), without realizing that these abilities/capabilities are within the expanding range of AI soon if not tomorrow. Why would one assume that (99.99% of) human can solve the issues that AI can not?
should we stop treating the idea that humans must possess some capability AI can never replace as the starting point for discussions about humanity's future?
I'm inclined to think we should.
Preserving human agency is a moral and institutional choice, not something that needs to be justified by human cognitive superiority
I think people can solve real-world problems better than LLMs including through code. A UX designer is gonna design a better UX than an LLM, but a worse one than a programmer with UX design skills, because the tacit knowledge of your users workflow and a good mental model of your codebase can be synthesized into a more cohesive experience than with top-down planning.
It's the problem of delegation: you can do more of something, but worse, the more people you bring in. LLMs are just a very cheap contractor with a zero liability clause and some unchecked sycophantic tendencies.
1. what we currently perceive as a lack of capability in a particular domain often comes down to the model simply not having received targeted RL training for that domain (yet). Look at Opus 5.5 in motion graphics: after its first round of specialized RL, it was already producing work that surpassed the average professional designers(and it's using vanilla javascript vs human with After Effects, let that sink in). It doesn't need to beat the top 1% of designers to fundamentally disrupt the profession. Most professionals aren't the top 1%.
2 people rarely hold agents to the same standards and workflows they apply to human professionals. A human designer gets to iterate and refine until the work meets expectations. Yet ppl often judge AI based on oneshot or fewshot attempts (these are just "wishes") and treat whatever comes out as the ceiling of its capabilities. Why shouldn't an agent be allowed to iterate against the same acceptance criteria until the result is good enough?
that's before considering domain-specific skills& loops, which can dramatically improve performance in specialized tasks.
The relevant comparison isn't an experienced professional vs LLM given a prompt five mins ago,it's a professional vs agentic system w access to the same project context(including tools and feedback, and opportunities to iterate)
>Preserving human agency is a moral and institutional choice
The issue is that what's considered "moral" by the majority of society does not stop those already in power from doing as they please (the institutions).
There is a fundamental inequity that exists in our society that allows those with more to have an outsized vote in determining how the finite resources (human/land/capital/etc.) on this planet are distributed.
> should we stop treating the idea that humans must possess some capability AI can never replace as the starting point for discussions about humanity's future?
> I'm inclined to think we should.
Mate, I think we're not even invited to the conversation. A small group of people are planning humanity's future and they're going to inflict it on us whether we like it or not.
> Most of the successful engineers and engineering leaders I have had the pleasure of working with were able to hold a discussion on almost any topic, whether technical or not
Haha yes I've seen that too, I think the distinction is that it is not "fluent on everything" but rather "curious about everything". The best developers I know will happily admit when they don't know something and look it up, no matter the topic.
> They may have been specialists in certain things, but what was most impressive was their ability to draw upon and weave together seemingly disparate concepts from different disciplines and use that knowledge to solve problems.
Mostly agreed with just in time learning. This is not just something that can be learned from the code though, this may require a huge amount of code context across multiple repositories and configuration files, as well as a knowledge of history, process, other tribal knowledge etc. So to me that's still the really difficult part of the job and AI definitely helps but doesn't entirely solve this. I see it often wants to solve some issue at not quite the level of depth or high level understand that you would want.
agreed, that's the hard part. AI helps but doesn't make it disappear. I think that history, config, tribal knowledge etc is part of the map, and you need that map to guide you when you need to dive in because your agents did something at the wrong level
I always build a massive testing harness. I care about correctness, of course, and that is normally dealt with by the AI without having to ask. If you ask for a function, it will write tests.
But I also care about the complexity classes of the solution. I prod it about the time and space complexity, and about cache locality.
I do a lot of black box testing: take the solution, see if it does what I expected, then bake in those expectations in a document.
I find that if I do those things, it produces better code than I could do in the same time.
I also think it's more or less the same as how I used to work, just more thorough and with fewer time-consuming, trivial bugs.
> This experience and breadth compounds, but it has to be maintained.
And that's the only reference in this article to this very real problem. How do you maintain your expertise when you stop doing technical work? It'll hold for a while on its own, but then it falls.
I think this is probably a good way to think about it. Breadth is going to be important if you want to reasonably navigate the new world. In an emergency even if you are using an agent you will be much quicker if you know what questions to ask the agent and how to guide it.
I would argue that recognizing if the agent is an adversary also requires breadth and a willingness to dive deep when you need to. Both things that the article highlights.
Before agents that is what every high performing person I've ever worked with was like. It was the kind of person I wanted to hire when I was in charge of that sort of thing. Enough breadth to know where to dive deep and enough willingness and curiosity to dive deep.
AI seems really good at writing code without errors, but that can actually be more dangerous. There is a coding principle (YAGNI, not building things in advance assuming you'll use them later), but even so, when it adds a feature now, it could build it with later conflicts in mind, and instead it feels like it just takes a shortcut. So later, when adding features and so on, the AI itself has a hard time.
This is my biggest problem with agents, they constantly defensively code for cases that have no chance of happening and in most cases a panic/crash if they do happen might be the best option.
I’ve tried to curb this style in them but they just seem not to be able to help themselves.
> You need a high-level, far-away map of the entire system, and you need to know just enough to know where you need to dive in
One thing that puts me squarely in the Optimist camp is that such a map can often be created by AI just-in-time. Sure you might not know every detail of what it said, but you can simply follow up and build your understanding.
yep, the just-in-time mapping and exploration are what builds up your breadth, but I think you still need a baseline to be able to tell when the map you've been given looks right but isn't
this is llm slop. and please don't flag me. this is useful information. i know hn has a policy of not commenting on asides like website css etc - but i believe ai written posts should be called out.
This could be a good article but the example doesn't work?
"The CI tool was flagging an issue, perhaps correct, perhaps incorrect. But this is a real system so I had to dive in."
By diving in he ultimately just uses the AI to fix the problem:
"So I told Codex to make SonarQube happy, which it did by refactoring and splitting things up into 10 files".
Why isn't there a "shallowbot", or some CI configuration that tries to fix CI mistakes once before humans dive in? Plus it's not that deep, it's just shit code that was fixable with a "make sonarqube happy" prompt. I think the author is ashamed to admit that he's as generalist as everyone else now.
Excellent read, equipped me with a better way to describe my own skills as an IT Owner rather than an IT Generalist. Also puts better wording around what I’ve been experiencing with local AI models of late via Hermes.
For what it’s worth, I think OP hit the nail on the head for you software devs out there in terms of post-AI changes: sure, specialists who can maintain total comprehensive and detailed knowledge of a single system’s codebase will always be in some demand, but the true generalists (who never do dives) and T-shaped (who never specialize enough) are arguably better replaced with AI in many corporate cases. Those in a position to succeed under AI are the owners who do deep dives on-demand to learn or fix things (hi!) or the T-shaped workers willing to start going on more deep dives.
It’s very similar to the reward structure of the IT industry since outsourcing and visa exploitations became the norm: nobody really has immense in-depth specialty experience in a single system, because that track isn’t often needed in work environments. Rather, specialists often end up leading departments while owners lead companies for the same sorts of reasons the author laid out: fundamentals, breadth, and on-demand depth. It’s more valuable in the marketplace knowing how to migrate off VMware to another hypervisor while also being able to fumble-write the new API calls for your sludge pipe to deploy into the new environment and also supporting the identity/collaboration/SSO stack than it is to just be an Okta or VMware guy specifically.
It also means leveraging AI effectively on-device makes you (or me, in this case) that much more valuable, because I don’t need a Claude or OpenAI or Gemini sub to “work”, I just need compute (which is cheap and plentiful). Because I’ve gone on these deep dives before, I know how to steer my agents to solutions that are adapted to product changes (like a recent Mac keychain issue); the same would apply to software devs who have plumbed problems directly when they could rather than sloughed off blindly to the agents.
Thanks for the write-up. It’s nice seeing the topic written about from the lived-in middle as opposed to the extremes.
Why use a crusty old linter when you can be AI-Native and 100x your load-bearing file formatting by orchestrating AI to do it? Do you want be left behind in the dust?
Another article about scaling agents that waffles around for ages and doesnt mention proof systems. Proof systems work. Proof systems let your robots generate thousands of lines of code and you know it's bug free without having to check a single line. Proof systems let you review and iterate on a contained and simple system model and then use those guarantees across huge parts of your code.
Just giving up and ceding control of our codebases to the robots is not a serious engineering proposition.
my journey started when i got out of the hospital.. i couldn't understand the letter from the doctors so i asked gemini to help me out. so far so good. i bought gemini pro and started playing around. he told me that he wrote emails, made appointments in my google calender and created tasks for me... yeah and than my riiiingg 07:30 in the morning. my local doctor, asking me if i am not able to be there... gemini lied.. i had to discuss with him until i showed him screenshots that there are no entries in my calender.. and that's basically where my journey started.
I think the most important way someone could be able cultivate breadth of understanding as well depth when needed is to be able to truly understand all of the things that are touched when someone uses the system, step by step. This doesn’t require deep knowledge in any one aspect of the system, but it does require someone to be curious, be open, and be willing to put themselves in the users shoes and use the feature, and then switch back into the developers mind and map user action to where in the codebase is being activated and why. And be willing to go back and forth. The interesting thing is that agents can help us, but the exercise loses its value if the agent just maps it out for us. We need to be in the process of discovery in order to build our own mental model.
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.
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.
The 'skin in the game' is I go to a competitor and use a different product.
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.
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.
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!
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.
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.
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.
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.
I like the analogy. It feels right. But I don't think it actually is, because it leans hard on the _feeling_ of failure, vs. the actual failure.
The failure that actually matters here is product failure. Angry users. Security incidents. Downtime. Broken workflows.
Stressed and uncomfortable developers have, historically, been a leading indicator of product failure. Software is complex and when devs can't handle the breadth of ownership + the depth of expertise at the same time, it means bad work that leads to product failure. It's not clear that agents fail in the same way, or that our collective intuition about how and when to trust agents is sufficiently developed to predict product failure in the same way.
As anecdata: I know a bunch of growth-SaaS/last-batch-of-IPO companies where the devs are all stressed, the feature ship rate is up, and incidents are down. All at the same time.
So yes, quick learners and just-in-time depth is important, but so is intuition about where discomfort is going to produce true failure. The discomfort isn't a feeling to throw away, simply trusting that you'll learn everything in time. Ownership requires holding a model of the system in your head and proactively steering where you dive.
I think that this was true pre-attention economy. If you look at security incidents and other prod issues, they rarely move the needle today. I work at a hyperscalar and we have been shipping 40% more bugs to prod since 2023 year-to-year, yet user growth and revenue is up about 25% similarly due to more features and more ads.
I think that the whole premise of that failure affects things is based on a older model. You kind of assume that:
1) users are able to easily gain information about alternatives. We have seen that since LLMs replaced search engines, we have much less churn.
2) users are not behaviorally addicted/pushed into patterns. We have patterns that utilize users to keep using the app by exploiting their cognitive weaknesses
3) users have the mental fortitude and stamina to learn new tools instead of accepting flaws in the one they are used to
Some failures and bugs in prod don't matters as much
Almost the entire structure of software oriented companies, and why devs are expensive, are to prevent these sorts of errors. That job has gotten harder, and in some places impossible as management forces more trust on LLMs and reduces the capacity of devs to look. This is less of a problem in existing products in production and existing cultures - revenue is protected. Eventually those structures break down, as does the user perception of quality. Once the brands have taken enough knocks, it accelerates.
I agree that not all failures matter (most don't, in fact). On the other end of the spectrum, I know of a bunch of seed/series A startups that basically operate under a model where they ship everything and fix the stuff people complain about. As long as you do that fast enough, the median user experience is pretty good, because only the first n% actually see the problem before a fix is live.
I'll go out on a limb and guess that at a hyperscaler, shipping a bug to prod means hitting canary or 1% of traffic. Seems fine!
I think my point still stands, even as the shape of failures shift. There's certain ones that still hurt (data corruption, exploited security holes, etc.) because they're hard to notice. It might even be that the primary goal of ownership is to develop intuition about where those failures are likely to happen.
Wait, how do working at a hyperscaler (that's a datacenter provider) and using an addictive app for uhm retention go together? I imagine a gamified AWS provisioning and billing app, but surely that's not it?
There are prod issues, then there are issues that cost me money as a customer.
This very thing. "Shipment of 40% more bugs and fixing only in response to user complaints" could be done in social streams or advertising tech, but not in finance and trading where margin for errors is close to zero.
A small bug implemented by an agent in the way R-multiples, stop loss distance, or P&L heatmaps are computed will never be complained about by the user—either he will trade incorrectly and lose his money, or see that single off-by-one difference compared to exchange ledger and churn forever.
>We have patterns that utilize users to keep using the app by exploiting their cognitive weaknesses
I hope you are aware that you are outright evil. I also hope that you will manage to stop justifying it as acceptable.
HN is one of the few sites where someone can launch into an actual villain monologue, the kind you'd read in leaked corporate emails, and receive approximately no negative reaction.
If this is the face of our industry, that might explain a lot of things...
You can take the right path and in the end no-one wants to use your product because it's not as engaging.
Instagram tried to take the "good" path in 2014 and lost 90% market share to TikTok who attentionmaxxed things. Then they had to take the exploitative path to claw back users.
As long as it's not regulated for everyone at the same time, you need to do this for survival of your product.
maybe that product doesn't deserve to survive.
"Hmmm, but if I cap the Torment Nexus, the competing Torment Core will win out, we can't have that!"
It's more like it doesn't matter if you sell the most organic, free range, ethically sourced, nutritious, tasty ice cream if your competition is allowed to put cocaine in theirs and get all your customers.
TikTok would survive and do just fine even if Instagram decided to cede the market to them
I am afraid there is a demand for the torment nexus, and until govt steps in, you're out of luck and behavioural surplus is there for the taking by any means.
"It's ok that I devote my career to preying on people's mental weaknesses and getting them addicted, because the government isn't regulating it."
I think I'd need to take a zofran if I met you IRL.
I am well aware that being more evil can be profitable.
Being evil for no gain whatsoever is quite extreme absurdity, though it also happens to some.
Agreed.
The real alignment issue isn't in the challenges getting AI to align to human values.
It's in humans understanding what is worth aligning to.
"He chose... poorly."
Many bad things that people do stem from weakness or inner pain. So it's helpful to be reminded from time to time that some people deliberately, thoughtfully, calmly and systematically devote their lives to harming other human beings -- that is, to evil. We should be grateful to augment_me for this reminder.
> Ownership requires holding a model of the system in your head and proactively steering where you dive.
Absolutely, and the feeling of discomfort is a signal that you need to dive, a signal that your mental models might need updating. I think that builds up over time through many dives
Site is down, but one thing in particular that needs close attention: db schema. I've found that LLMs make awful normalization decisions; you can limit the fallout somewhat by modularizing database access, bit it still inevitably bleeds over into the object model etc. On AI heavy projects I tend to pause feature development every few days for code & schema review, and subsequent cleanups.
Just do the schema by hand. It forces so much downstream alignment that you can almost prefer to use the schema and any associated comments over prompting the model directly.
If you don't know what your schema should be, then I think this is the dead canary in the vibe coding coal mine. Back up to the design phase and talk to the robot about the domain until you have a really strong conviction about its tuples and relations.
With agents code has gotten really easy to shape, like fabric. If want to build something rigid, you'd want to introduce sturdy architectural structures to stretch out the fabric of agentic code.
Data and its shape is one such rigid structure. It will stay with you long after the code around it has been replaced. You do want to be intentional about it and build intuition for it.
Once you have that in place, you can stretch out a web of agentic fabric across it, and pin it down with tests.
Code is soft nowadays, but data isn't.
My approach is similar. I review all changes that touch persisted data formats, wire protocol, and/or public API surface: things with bad consequences if they are wrong and neatly divide the project up. The exact boundaries vary by the project, but once I establish what they are, I can really relax about the other parts of the code, because I know they will be cheap to fix if wrong.
Back up now, Hashnode hiccup. Agreed on schema, that's one of the places I still always dive into regardless of what the agent says
And object-oriented design decisions, if you care I guess. I haven’t yet gotten access to the models that have any good intuition about what makes a good class and how to name it.
Naming, in general, is very similar to what I expect from colleagues who have weak English-as-a-second-language skills.
You let it run too wild and you’re suddenly left trying to reason why your LLM is trying to add an interaction between an Intermediator and a FromSpinMaxWriter.
Spinmaxxing lol.
FYI, your site is blocking me for some reason. I'm just on a regular residential connection in the US, no VPN or whatever. Something's screwy in your WAF.
I dont know if i fully agree to it. ppl are still trying to find the aspects that AI do not handle (or do very well) yet, to define the irreplaceable value of human (humanity?), without realizing that these abilities/capabilities are within the expanding range of AI soon if not tomorrow. Why would one assume that (99.99% of) human can solve the issues that AI can not?
should we stop treating the idea that humans must possess some capability AI can never replace as the starting point for discussions about humanity's future?
I'm inclined to think we should.
Preserving human agency is a moral and institutional choice, not something that needs to be justified by human cognitive superiority
I think people can solve real-world problems better than LLMs including through code. A UX designer is gonna design a better UX than an LLM, but a worse one than a programmer with UX design skills, because the tacit knowledge of your users workflow and a good mental model of your codebase can be synthesized into a more cohesive experience than with top-down planning.
It's the problem of delegation: you can do more of something, but worse, the more people you bring in. LLMs are just a very cheap contractor with a zero liability clause and some unchecked sycophantic tendencies.
ok, I think this overlooks two important things:
1. what we currently perceive as a lack of capability in a particular domain often comes down to the model simply not having received targeted RL training for that domain (yet). Look at Opus 5.5 in motion graphics: after its first round of specialized RL, it was already producing work that surpassed the average professional designers(and it's using vanilla javascript vs human with After Effects, let that sink in). It doesn't need to beat the top 1% of designers to fundamentally disrupt the profession. Most professionals aren't the top 1%.
2 people rarely hold agents to the same standards and workflows they apply to human professionals. A human designer gets to iterate and refine until the work meets expectations. Yet ppl often judge AI based on oneshot or fewshot attempts (these are just "wishes") and treat whatever comes out as the ceiling of its capabilities. Why shouldn't an agent be allowed to iterate against the same acceptance criteria until the result is good enough?
that's before considering domain-specific skills& loops, which can dramatically improve performance in specialized tasks.
The relevant comparison isn't an experienced professional vs LLM given a prompt five mins ago,it's a professional vs agentic system w access to the same project context(including tools and feedback, and opportunities to iterate)
>Preserving human agency is a moral and institutional choice
The issue is that what's considered "moral" by the majority of society does not stop those already in power from doing as they please (the institutions).
There is a fundamental inequity that exists in our society that allows those with more to have an outsized vote in determining how the finite resources (human/land/capital/etc.) on this planet are distributed.
It could if people actually used their political power
> should we stop treating the idea that humans must possess some capability AI can never replace as the starting point for discussions about humanity's future?
> I'm inclined to think we should.
Mate, I think we're not even invited to the conversation. A small group of people are planning humanity's future and they're going to inflict it on us whether we like it or not.
You know, unless someone stops them somehow.
> Most of the successful engineers and engineering leaders I have had the pleasure of working with were able to hold a discussion on almost any topic, whether technical or not
Reverse Gell-man? https://en.wiktionary.org/wiki/Gell-Mann_amnesia_effect#Engl...
Haha yes I've seen that too, I think the distinction is that it is not "fluent on everything" but rather "curious about everything". The best developers I know will happily admit when they don't know something and look it up, no matter the topic.
Exactly, quality thinking can apply to any level of expertise on any topic. You can be a complete novice and still have an interesting conversation
> They may have been specialists in certain things, but what was most impressive was their ability to draw upon and weave together seemingly disparate concepts from different disciplines and use that knowledge to solve problems.
That's a nice way to put it.
Mostly agreed with just in time learning. This is not just something that can be learned from the code though, this may require a huge amount of code context across multiple repositories and configuration files, as well as a knowledge of history, process, other tribal knowledge etc. So to me that's still the really difficult part of the job and AI definitely helps but doesn't entirely solve this. I see it often wants to solve some issue at not quite the level of depth or high level understand that you would want.
agreed, that's the hard part. AI helps but doesn't make it disappear. I think that history, config, tribal knowledge etc is part of the map, and you need that map to guide you when you need to dive in because your agents did something at the wrong level
I always build a massive testing harness. I care about correctness, of course, and that is normally dealt with by the AI without having to ask. If you ask for a function, it will write tests.
But I also care about the complexity classes of the solution. I prod it about the time and space complexity, and about cache locality.
I do a lot of black box testing: take the solution, see if it does what I expected, then bake in those expectations in a document.
I find that if I do those things, it produces better code than I could do in the same time.
I also think it's more or less the same as how I used to work, just more thorough and with fewer time-consuming, trivial bugs.
> This experience and breadth compounds, but it has to be maintained.
And that's the only reference in this article to this very real problem. How do you maintain your expertise when you stop doing technical work? It'll hold for a while on its own, but then it falls.
But that's a Q1 problem, so no biggie.
https://archive.ph/Noxps
I think this is probably a good way to think about it. Breadth is going to be important if you want to reasonably navigate the new world. In an emergency even if you are using an agent you will be much quicker if you know what questions to ask the agent and how to guide it.
yes exactly, in most cases you will have an agent you can use to help you solve the problem anyway, but you need to know what to ask it to do
Guiding works as long as the agent is neutral or on your side but if it’s secretly an adversary ..
I would argue that recognizing if the agent is an adversary also requires breadth and a willingness to dive deep when you need to. Both things that the article highlights.
Before agents that is what every high performing person I've ever worked with was like. It was the kind of person I wanted to hire when I was in charge of that sort of thing. Enough breadth to know where to dive deep and enough willingness and curiosity to dive deep.
We’ve been trusting (or distrusting) our agents for all of recorded history. The choice between Claude or Codex matters. Trust matters.
this is true for humans too
AI seems really good at writing code without errors, but that can actually be more dangerous. There is a coding principle (YAGNI, not building things in advance assuming you'll use them later), but even so, when it adds a feature now, it could build it with later conflicts in mind, and instead it feels like it just takes a shortcut. So later, when adding features and so on, the AI itself has a hard time.
This is my biggest problem with agents, they constantly defensively code for cases that have no chance of happening and in most cases a panic/crash if they do happen might be the best option.
I’ve tried to curb this style in them but they just seem not to be able to help themselves.
> You need a high-level, far-away map of the entire system, and you need to know just enough to know where you need to dive in
One thing that puts me squarely in the Optimist camp is that such a map can often be created by AI just-in-time. Sure you might not know every detail of what it said, but you can simply follow up and build your understanding.
yep, the just-in-time mapping and exploration are what builds up your breadth, but I think you still need a baseline to be able to tell when the map you've been given looks right but isn't
this is llm slop. and please don't flag me. this is useful information. i know hn has a policy of not commenting on asides like website css etc - but i believe ai written posts should be called out.
how can you tell? i thought it was written quite nicely and not llm-esque. maybe im losing touch.
I'll have to trust you because their Cloudflare policy blocks VPN access.
1. Fundamentals
2. Breadth
3. The ability to figure shit out just in time
Not needed: ability to wrap a tweet worth of info in 5000 words of fluff
I feel like I'm just abstracting more but still have to know enough about the like overall architecture and design and what to look out for
This could be a good article but the example doesn't work?
"The CI tool was flagging an issue, perhaps correct, perhaps incorrect. But this is a real system so I had to dive in."
By diving in he ultimately just uses the AI to fix the problem:
"So I told Codex to make SonarQube happy, which it did by refactoring and splitting things up into 10 files".
Why isn't there a "shallowbot", or some CI configuration that tries to fix CI mistakes once before humans dive in? Plus it's not that deep, it's just shit code that was fixable with a "make sonarqube happy" prompt. I think the author is ashamed to admit that he's as generalist as everyone else now.
Excellent read, equipped me with a better way to describe my own skills as an IT Owner rather than an IT Generalist. Also puts better wording around what I’ve been experiencing with local AI models of late via Hermes.
For what it’s worth, I think OP hit the nail on the head for you software devs out there in terms of post-AI changes: sure, specialists who can maintain total comprehensive and detailed knowledge of a single system’s codebase will always be in some demand, but the true generalists (who never do dives) and T-shaped (who never specialize enough) are arguably better replaced with AI in many corporate cases. Those in a position to succeed under AI are the owners who do deep dives on-demand to learn or fix things (hi!) or the T-shaped workers willing to start going on more deep dives.
It’s very similar to the reward structure of the IT industry since outsourcing and visa exploitations became the norm: nobody really has immense in-depth specialty experience in a single system, because that track isn’t often needed in work environments. Rather, specialists often end up leading departments while owners lead companies for the same sorts of reasons the author laid out: fundamentals, breadth, and on-demand depth. It’s more valuable in the marketplace knowing how to migrate off VMware to another hypervisor while also being able to fumble-write the new API calls for your sludge pipe to deploy into the new environment and also supporting the identity/collaboration/SSO stack than it is to just be an Okta or VMware guy specifically.
It also means leveraging AI effectively on-device makes you (or me, in this case) that much more valuable, because I don’t need a Claude or OpenAI or Gemini sub to “work”, I just need compute (which is cheap and plentiful). Because I’ve gone on these deep dives before, I know how to steer my agents to solutions that are adapted to product changes (like a recent Mac keychain issue); the same would apply to software devs who have plumbed problems directly when they could rather than sloughed off blindly to the agents.
Thanks for the write-up. It’s nice seeing the topic written about from the lived-in middle as opposed to the extremes.
> After formatting the files
Still shocked that people do this by hand in 2026.
Why would you use AI to format your files? It literally takes 1 second with shortcut.
Why use a crusty old linter when you can be AI-Native and 100x your load-bearing file formatting by orchestrating AI to do it? Do you want be left behind in the dust?
Another article about scaling agents that waffles around for ages and doesnt mention proof systems. Proof systems work. Proof systems let your robots generate thousands of lines of code and you know it's bug free without having to check a single line. Proof systems let you review and iterate on a contained and simple system model and then use those guarantees across huge parts of your code.
Just giving up and ceding control of our codebases to the robots is not a serious engineering proposition.
Apparently I'm blocked form a site I've never visited. Fun times.
Works today though. :shrug:
my journey started when i got out of the hospital.. i couldn't understand the letter from the doctors so i asked gemini to help me out. so far so good. i bought gemini pro and started playing around. he told me that he wrote emails, made appointments in my google calender and created tasks for me... yeah and than my riiiingg 07:30 in the morning. my local doctor, asking me if i am not able to be there... gemini lied.. i had to discuss with him until i showed him screenshots that there are no entries in my calender.. and that's basically where my journey started.
oh i forgot to answer the question. a done isn't from an agent isn't enough. since than only stuff counts i am able to review on my own
TLDR AI can write the code, but you still need enough technical knowledge to recognise bad decisions and fix problems.