Here be monsters: What do you still need to know when agents do the work?

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

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.

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.

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

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

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

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.

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.

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.

  > Sorry, you have been blocked
  > You are unable to access hashnode.dev

Well this is a first for something posted to HN. I'm not blocked anywhere else, so I don't know what you're doing different on your website.

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

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.

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.

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.

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.

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[dead]

TLDR AI can write the code, but you still need enough technical knowledge to recognise bad decisions and fix problems.