Get the top HN stories in your inbox every day.
rorylaitila
scottLobster
The irony is "ownership" is a common management talking point, but when you actually try to take ownership you inevitably run into walls of access, a lack of information, and generally a "why are you here?" mentality.
Granted one person can't know/do everything, but large companies in particular seem allergic to granting you any visibility whatsoever. It's particularly annoying when you're given a deadline, bust your ass working overtime to make it, only to discover that said deadline got extended at a meeting you weren't invited to and nobody thought to tell you about it. Or worse, they were doing some dark management technique of "well he's really hauling ass right now, if he makes the original deadline we'll be ahead of schedule, and if he doesn't we have the spare capacity".
If the expectation is I'm a tool for management to use, then I'll perform my duties to the letter and no further. If the expectation is ownership, then I need to at least sit at the cool kids' table and maybe even occasionally speak when I have something relevant to contribute.
lazystar
> Granted one person can't know/do everything,
watch me try, at least.
> but large companies in particular seem allergic to granting you any visibility whatsoever. It's particularly annoying
If the blind spot is directly causing customer pain, find metrics that demonstrate the impact. If it ends up driving away your customers, then your company is securing itself to death.
robocat
> customer pain > driving away your customers > company death
You are implying efficient market theory, which is bunk.
Example: Our banks have endless painful papercuts yet most of us don't change banks just because of one pain.
We each respond to our own complex of costs and benefits (or risks versus rewards).
Second example: I use an iPhone because I judge it to be more secure yet I'm constantly fighting the same bugs and misfeatures that seem to never get fixed/improved.
Your chain of reasoning is broken? Or is it your model of the world?
BobbyTables2
It’s a lot like the “how shit happens tale”.
The product may take 20 minute to boot - a testament to its complexity and greatness (/s). But pointing that out might end badly when it’s the SVP’s pet. They will not entertain alternatives or efforts that distract from their mental plan.
And if a developer finds themselves getting feedback or communication from customers, things are probably on fire - absolutely literally.
order-matters
>Or worse, they were doing some dark management technique of "well he's really hauling ass right now, if he makes the original deadline we'll be ahead of schedule, and if he doesn't we have the spare capacity"
As a business analyst who has worked a lot with executive teams at multiple companies, this is almost always the case (ime). Deadlines are only shortened down the chain, never extended. The assumption is that if it cannot be done then they will simply not administer any consequences and classify it as "not realizing the upside".
The only reason it is almost always and not always, is because sometimes a different thing pops up that needs to get prioritized first, so it is communicated that the first thing isnt actually as important as it was yesterday and this other thing is now the most important.
Now obviously I cant speak for everyone at all teams, but as far as boring corporate default behavior goes this is the safe path for executives. If your boss is doing otherwise, they are going out of their way to do it.
The takeaway as a worker is that you should not treat any business goal or deadline ask of you with the same level of care as you would a personal favor. When something really needs that level of care, your boss should pull you aside and break character and make it a personal favor to them, not the business.
As far as "Ownership" goes, it is just a pissing contest as far as I can tell. if you own a task but cant do the task, you just send an email to someone who can do the task so that the task gets done and you can report the task is done and get your ownership credit. the person who did the task was used as a tool in this regard. So high performing managers just try to get ownership of as much as they possibly can, as there's no meaningful difference between who sends that email.
BobbyTables2
Taking ownership is hard but fending it off is even harder.
I’ve been dragged into modifying my team’s product to fix deficiencies in others’ designs.
They didn’t want take ownership and freely pushed it onto us!
toyg
Ownership doesn't imply FULL ownership. You get handed ownership of a slice, and expected to be responsible for that bit of land; but you'll never own the farm, and will likely never be consulted on whether that land should become a car park from Tuesday. That's just how capitalism work.
Jtsummers
> and will likely never be consulted on whether that land should become a car park from Tuesday.
Then you don't have ownership. What you have is responsibility without ownership or authority if this rug pull can be performed.
scottLobster
That's called renting. And even renters have rights per whatever lease they signed and local laws.
It's a simple formula. If you want me to be personally invested in my work and go above and beyond, then I need the motivation to do that. So either you grant me a reasonable level of professional input such that my opinion is valued and I'm helping the mission succeed, or pay me for said extra effort (can be opportunities for promotion, direct overtime pay, career advancement, etc). If you want me super-motivated you can even do both!
If we're playing hardball "you're some lowly IC nerd without an MBA or connections and we're here to make money so fuck you" capitalism, well the only serious leverage I have to is to take my talents where they're most appreciated. So you'll get exactly what you pay for until I find something better, and aside from some professional courtesy I'll be looking. Maybe you're fine with that, but if you start preaching "ownership" of the product just be aware that the entire dev team is going to pay you lip service and then laugh as soon as you're out of the room, and we clock out at 5:00, even if we don't on paper. Except for poor Bob who due to life/family commitments has no option to leave and needs to rationalize his situation even though he agrees with us. Sometimes we'll tone it down just so he doesn't feel too bad about being trapped. Regardless, in that environment we take ownership of our careers, not our work.
I've worked both types of jobs. I'd say the former worked the best for all involved, but the latter has its place and is fine so long as everyone acknowledges what game we're playing and expectations are set appropriately.
cortesoft
Strangely, I feel that using Claude helps me stay MORE focused on what I am actually trying to accomplish.
In the prior 30 years of my programming life, so much time was spent "yak shaving"... setting up all the boilerplate, adding basic functionality you always have to do, setting up support systems, etc. With Claude, all of those things are so quick to complete that I can stay focused on what I am actually trying to do, and can therefore keep more of the core functionality I am caring about in my head. I don't have to push the core, novel, parts of my work aside to do the parts that are the same across other projects.
Insanity
But apart from side projects these true new setups happen rarely. When working at a company you probably work on an already established codebase with known patterns.
So what you say is true about boilerplate reduction, but that’s not a huge ROI for enterprise software.
(Some exceptions apply, there’s always some setup work for a new microservice etc. But even those don’t happen weekly or even monthly)
konschubert
I don't know. Today I had something break because of a uv update on a very legacy piece of code.
(Not complaining - it was a good update that revealed a bug in our code.)
I really don't care to much any more to learn about the histories of python packaging. Claude fixed it for me and that was it.
ffsm8
I am still missing something like Claude code that's less "hands-off" and optimizes for small edits instead of full feature development
Like you're sitting in your ide, select a few rows, press (for example) caps lock to activate speech and then just say a short line what it should adjust or similar - which is then staged for the next adjustments to be done with the same UX
Like saying "okay, I need a new usecase here, let's start by making a function to do y. [Function appears] great, we need to wire with object into it [point at class] [LLM backtracking code path via language server until it finds it and passes things through]
The main blocking issue to that UX would likely be the speed of the response, as the transcription would be pretty much instant, but the coding prompt after would still take a few moments to be good... And such an interactive approach would feel a lot better with speed.
Too bad nobody seems to target the combined mouse+voice control for LLMs yet. It would even double as a fantastic accessibility tool for people suffering from various typing related issues
nsm
Aider has an ide mode close to this. Check out https://nikhilism.com/post/2026/nudge-skill/ to add similar behavior to certain agents. I too, am waiting for IDEs to do this in a polished way. next tab edit is not quite it
jmalicki
In cursor you highlight and hit Ctrl-L, and use the voice prompting - I can do this today!
devin
The level of exposition required for a lot of edits you might want to make is what stops this from being a primary method of interaction. If I have to express >= AND <= AND NOT == OR ... then I may as well write the thing myself.
8note
the big problem with tools like that is that the agent can read all the existing code and docs when asked, but it cant read your mind.
its always going to do better if you give it a stronger description of the problem, and give it some more freedom on the solution.
if youre sitting more in the solution side, youre going to be dictating those exact functions because theres not enough context for it to just know what the right function you need is
internet2000
You should absolutely try your hardest to learn the layer above you. If your organization won't volunteer the info easily that's unfortunate, but you definitely have to try.
ChrisMarshallNY
Well, to be fair, we've already been there, for many years (dependency hell). In those cases, LLMs are likely to actually improve things.
For myself, I like to know what's going on, to a certain extent, but appreciate abstraction.
I am also aware that people like me, probably don't make commercial sense, but that's already been the case for quite some time.
RGamma
Vaguely reminds me of a phenomenon in farming an acquaintance recently told me. Apparently automation is now so great (if you can afford it), that operators only need to sit in their tractors and let the machine do the rest. You're effectively a weight for the seat contact switch.
ErroneousBosh
That works until something goes wrong.
Same as "self-driving cars", the automated farm machinery can't cope with any sort of change in its environment.
drzaiusx11
You're simply describing the end state of a hyper capitalist system, as outlined by classic Marxist theory.
The core operating principle of which says capitalism requires and promotes systems that enforce the separation of labor from the product they produce. This precludes fellow laborers from meaningfully communicating with each other; knowledge sharing could expose more of how the product "works" after all! Only in final combination, following an undisclosed (to the worker) larger plan, does the product become whole and provide utility.
So not knowing "what happens" in layers "above" and "below" you for your specific work unit is key. This is the "de-skilling" tenet of capitalism and is required for exploitation, conformity, at scale. As labor units become smaller, they require less skill and time to produce, rendering laborers "conditioned to a machine." In other words, workers must acquiesce their skills in the name of "progress" of the system itself. This can easily be sold to the laborers, couched by real world data highlighting the obvious efficiency gains, along with a heavy bonus of having to do less work yourself.
Only by making ever smaller parts of a whole, awhile hiding the utility of those parts produced, can capital rob labor of their value (their skill, their products, their output.)
This very same system lends itself to outcompeting private labor by way of parallelization: as it just so happens that smaller slices of work tend to parallelize better than larger ones. If you can operate at a scale that bespoke creators have no chance of replicating on their own, you "win!" The beautiful moat, the envy of all.
In other words, you're just describing being a worker in a highly efficient capitalist machine! Look! We're almost there! I can just about smell all the "winning" from here...
raw_anon_1111
The average tenure of a developer for the longest was 2.5 years not to mention the developer changing teams, even before AI many developers didn’t know how the code they were brought in to maintain works.
> My English instructions do not leave any residual growth. I learn nothing to send back up the chain, and I know nothing of what's below. Why should I exist?
When you use Claude code, tell it to keep a markdown file updated with the what and the why. Instead of just “Do $y”, “Because of $x I need to do $y”. If it is updated in the markdown file, it will be recorded and sometime the agent will come up with code and mske changes that are correct. But use cases you didn’t think about. You can then even ask it “why did it do $x” that you weren’t expecting but oh yeah, it was right.
> Why should I exist?
That’s the wrong question, the correct question is “why is my employer paying me?”. Your employer is paying you to turn well defined requirements into working code to either make them money or to save them money if (the royal) you are a mid level ticket taker. If someone is working at that level, that’s what they are regardless of title.
No one cares if either you or the LLM decided to use a for loop or a while loop.
At higher levels you are responsible for taking your $n number of years of experience to turn more ambiguous, more impactful, larger scoped projects into working implementations that are done on time, on budget and meets requirements. Before LLMs, that meant a combination of my own coding, putting a team together and delegating and telling my director/CTO that this isn’t something we should be doing in house (ie a Salesforce or Workday integration) at all.
Now add to the mix between all those resources - a coding agent. In either case, I as anything above ticket taker, probably haven’t looked at a line of code first. I test for does it meet the functional and non functional requirements and then mostly look at the hot spots - concurrency issues, security issue, and are there any scalability issues that are obvious before I hammer it with real world like traffic - web request or transactions for an ETL job.
And before the pearl clutching starts, I started programming as a hobby in the 80s in assembly and spent the first decade and a half of my career doing C bit twiddling on multiple mainframes, PCs, and later Windows CE devices.
beej71
>At higher levels you are responsible for taking your $n number of years of experience to turn more ambiguous, more impactful, larger scoped projects into working implementations that are done on time, on budget and meets requirements.
Is this not a job for LLMs, though?
raw_anon_1111
LLMs are good at turning well defined requirements to code.
But even now it’s struggling on a project to understand the correlation between “It is creating Lambda code to do $x meaning it needs to change the corresponding IAM role in CloudFormation to give it permission it needs”
virgilp
That's not how things work in practice.
I think the concern is not that "people don't know how everything works" - people never needed to know how to "make their own food" by understanding all the cellular mechanisms and all the intricacies of the chemistry & physics involved in cooking. BUT, when you stop understanding the basics - when you no longer know how to fry an egg because you just get it already prepared from the shop/ from delivery - that's a whole different level of ignorance, that's much more dangerous.
Yes, it may be fine & completely non-concerning if agricultural corporations produce your wheat and your meat; but if the corporation starts producing standardized cooked food for everyone, is it really the same - is it a good evolution, or not? That's the debate here.
ahnick
Most people have no idea how to hunt, make a fire, or grow food. If all grocery stores and restaurants run out of food for a long enough time people will starve. This isn't a problem in practice though, because there are so many grocery stores and restaurants and supply chains source from multiple areas that the redundant and decentralized nature makes it not a problem. Thus it is the same with making your own food. Eventually if you have enough robots or food replicators around knowing how to make food becomes irrelevant, because you always will be able to find one even if yours is broken. (Note: we are not there yet)
sciencejerk
>If all grocery stores and restaurants run out of food for a long enough time people will starve. This isn't a problem in practice though...
I fail to see how this isn't a problem? Grid failures happen? So do wars and natural disasters which can cause grids and supply chains to fail.
ahnick
That is short hand. The problem exists of course, but it is improbable that it will actually occur in our lifetimes. An asteroid could slam into the earth or a gamma ray burst could sanitize the planet of all life. We could also experience nuclear war. These are problems that exist, yet we all just blissfully go on about our lives, b/c there is basically nothing that can be done to stop these things if they do happen and they likely won't. Basically we should only worry about these problems in so much as we as a species are able to actually do something about them.
pixl97
If they are at small scale then it's fine.
If it's at large scale then millions die of starvation.
xorcist
> Most people have no idea how to hunt, make a fire, or grow food
That's a bizarre claim, confidently stated.
Of course I can make a fire, cook and my own food. You can, too. When it comes to hunting, skinning and the cutting of animals, that takes a bit more practice but anyone can manage something even if the result isn't pretty.
If stores ran out of food we would have devastating problems but because of specialization, just because we live in cities now you simply can't go out hunting even if you wanted to. Plus there is probably much more pressing problems to take care of, such as the lack of water and fuel.
If most people actually couldn't cook their own food, should they need, that would be a huge problem. Which makes the comparison with IT apt.
sceptic123
I don't think they're saying _you_ can't do those things, just that most people can't which I have to agree with.
They're not saying people can't learn those things either, but that's the practice you're talking about here. The real question is, can you learn to do it before you starve or freeze to death? Or perhaps poison yourself because you ate something you shouldn't or cooked it badly.
stetrain
You think that the majority of people actually know how to do those things successfully in the absence of modern logistics or looking up how to do it online?
I have a general idea of how those things work, but successfully hunting an animal isn't something I have ever done or have the tools (and training on those tools) to accomplish.
Which crops can I grow in my climate zone to actually feed my family, and where would I get seeds and supplies to do so? Again I might have some general ideas here but not specifics about how to be successful given short notice.
I might successfully get a squirrel or two, or get a few plants to grow, but the result is still likely starvation for myself and my family if we were to attempt full self-reliance in those areas without preparation.
In the same way that I have a general idea of how CPU registers, cache, and instructions work but couldn't actually produce a working assembly program without reference materials.
idiotsecant
Ok, poof. Now everyone knows how to hunt, farm, and cook.
What problem does this solve? In the event of breakdown of society there is nowhere near enough game or arable land near, for example, New York City to prevent mass starvation if the supply chain breaks down totally.
This is a common prepper trope, but it doesn't make any sense.
The actual valuable skill is trade connections and community. A group of people you know and trust, and the ability to reach out and form mini supply chains.
stetrain
I don't think that comment is advocating for most people to be able to do these things or stating that this is a problem.
In fact it says "This isn't a problem in practice though"
krab
> This is a common prepper trope, but it doesn't make any sense.
In case the supply chain breaks, preppers don't want to be the ones that starve. They don't claim they can prevent mass starvation.
(Very off topic from the article)
stronglikedan
> Most people have no idea how to hunt, make a fire, or grow food. If all grocery stores and restaurants run out of food for a long enough time people will starve.
I doubt people would starve. It's trivial to figure out the hunting and fire part in enough time that that won't happen. That said, I think a lot of people will die, but it will be as a result of competition for resources.
Legend2440
People would absolutely starve, especially in the cities.
It’s just not possible to feed 8 billion people without the industrial system of agriculture and food distribution. There aren’t enough wild animals to hunt.
1718627440
If I could hunt, it wouldn't actually matter, because nearly all the animals I would want are in stables. So all I would need to do is find a large enough rock and throw it at them, until they die. The much larger problem would be to keep all the other humans from doing that before me.
shevy-java
In Star Trek they just 3D printed everything via light.
skeptic_ai
At what point is the threshold between fine and concerning? Seems like the one you put is from your point of view. I’m sure not everyone would agree and is subjective.
lijok
> that's a whole different level of ignorance, that's much more dangerous.
Why? Is it more dangerous to not know how to fry an egg in a teflon pan, or on a stone over a wood fire? Is it acceptable to know the former but not the latter? Do I need to understand materials science so I can understand how to make something nonstick so I’m not dependant on teflon vendors?
virgilp
It's relative, not absolute. It's definitely more dangerous to not know how to make your own food than to know something about it - you _need_ food, so lacking that skill is more dangerous than having it.
That was my point, really - that you probably don't need to know "materials science" to declare yourself competent enough in cooking so that you can make your own food. Even if you only cooked eggs in teflon pans, you will likely be able to improvise if need arises. But once you become so ignorant that you don't even know what food is unless you see it on a plate in a restaurant, already prepared - then you're in a lot poorer position to survive, should your access to restaurants be suddenly restricted. But perhaps more importantly - you lose the ability to evaluate food by anything other than aspect & taste, and have to completely rely on others to understand what food might be good or bad for you(*).
(*) even now, you can't really "do your own research", that's not how the world works. We stand on shoulders of giants - the reason we have so much is because we trust/take for granted a lot of knowledge that ancestors built up for us. But it's one thing to know /prove everything in detail up until the basic axioms/atoms/etc; nobody does that. And it's a completely different different thing to have your "thoughts" and "conclusions" already delivered to you in final form by something (be it Fox News, ChatGPT, New York Times or anything really) and just take them for granted, without having a framework that allows to do some minimal "understanding" and "critical thinking" of your own.
TomasBM
When it comes to food prep, I'd agree with you that the more time of your life passes, the more irresponsible is the risk of not knowing how to fry an egg, for example.
At the same time, you only need to learn how to fry an egg once, and you won't forget it. You can go your entire life without ever having to fry an egg yourself - but if you ever had to, you could.
When it comes to coding, the analogy breaks down, I think. Aside from the obviously different stakes (survival versus control of your device), coding also requires keeping up with a lot of changing domain knowledge. It'd be as if an egg is one week savoury, another week sweet, and another a poisonous mushroom. It's also less of a single skill like writing a for loop, and more of a combination of skills and experiments, like organizing a banquet.
Coding today suffers from having too many types of eggs, many of which exist because some communities prefer them. I also don't like the solution "let the LLM do it", but it's much easier. Still, if we manage to stabilize patterns for the majority of use cases, frying the proverbial egg will no longer be as much of domain knowledge, choice or elitism as it is today.
stoneforger
You do need to be able to understand nonstick coating is unhealthy and not magic. You do need to understand your options for pan frying for not sticking are a film of water or an ice cube if you don't want to add an oil into the mix. Then it really depends what you are cooking on how sticky it will be and what the end product will look like. That's why there are people that can't fry an egg, people that cook, chefs, and Michelin chefs. Because nuance matters, it's just that the domain where each person wants to apply it is different. I dont care about nuance in hockey picks but probably some people do. But some domains should concern everyone.
OkayPhysicist
> You do need to be able to understand nonstick coating is unhealthy and not magic.
Prove it. Please, show me a method by which polytetrafluoroethylene is going to kill me. Because if you're like everyone else moaning about "plastic bad" online, you'll be wrong, and if you have some secret insight that no one else has, I'd love to hear it. But a basic understanding of chemistry reveals that PTFE is functionally inert. It doesn't react with damn near anything, it needs heats well in excess of anything you should be exposed to cooking to melt or burn, and even if you were eating the stuff straight, the whole "inert" thing applies to just about any digestive process your body could apply to it, too.
pixl97
>You do need to be able to understand nonstick coating is unhealthy and not magic
Will it kill you faster than you can birth and raise the next generation?
If it's something that kills you at 50 or 60, then really it doesn't matter that much as evolution expects you to be a grandparent by then.
planb
This article is about people using abstractions without knowing how they work. This is fine. This is how progress is made.
But someone designed the abstraction (e.g. the Wifi driver, the processor, the transistor), and they made sure it works and provides an interface to the layers above.
Now you could say a piece of software completely written by a coding agent is just another abstraction, but the article does not really make that point, so I don't see what message it tries to convey. "I don't understand my wifi driver, so I don't need to understand my code" does not sound like a valid argument.
mamcx
> This article is about people using abstractions without knowing how they work. This is fine. This is how progress is made.
The big problem is that now exist an actual risk most will never be able to MAKE abstractions. Sure, lets be on the shoulders of the giants but before IA most do some extra work and flex their brains.
Everyone make abstractions, and hide the "accidental complexity" for my current task is good, but I should deal with the "necessary complexity" to say I have, actually, done a job.
If is only being a dumb pipe...
1718627440
> Now you could say a piece of software completely written by a coding agent is just another abstraction,
Abstractions come with both syntactic and semantic behaviour specifications. In other words their implementation can have bugs. An LLM never has a bug, it always produces "something", whether this is what you wanted is on you to verify.
ragall
> Now you could say a piece of software completely written by a coding agent is just another abstraction
You're almost there. The current code-generating LLMs will be a dead end because it takes more time to thoroughly review a piece of code than to generate it, especially because LLM code is needlessly verbose.
The solution is to abandon general-purpose languages and start encapsulating the abstraction behind a DSL, which is orders of magnitude more restricted and thus simpler than a general-purpose language, making it much more amenable to be controlled through an LLM. SaaS companies should go from API-first to DSL-first, in many cases more than one DSL: e.g. a blog-hosting company would have one DSL for the page layouts, one for controlling edits and publishing, one for asset manipulation pipelines, one for controlling the CDN, etc... Sort of IaC, you define a desired outcome, and the engine behind takes care of actuating it.
order-matters
I agree. Additionally, a company can own and update a business language of their own design at their own pace and need. Then they can use AI to translate from their controlled business language to the DSL needed (translation being an area it actually does well). In this way the LLM would only ever be going from General -> specific, which should keep it on the rails, and the business can keep its business logic stored
Now that said, there is still the actual engineering problem of leveraging the capabilities of the underlying technology. For example, being able to map your 4 core program to a 16 core system and have it work is one thing, actually utilizing 16 cores is another. Extend to all technological advancements
ragall
> I agree. Additionally, a company can own and update a business language of their own design at their own pace and need.
Yes, although I was more thinking of this being in most cases a SaaS offering because the implementation of the DSL needs solid non-LLM engineering. Larger companies will be able to afford an internal platform team, but most won't.
> Now that said, there is still the actual engineering problem of leveraging the capabilities of the underlying technology. For example, being able to map your 4 core program to a 16 core system and have it work is one thing, actually utilizing 16 cores is another.
I see this more of an extension of existing trends, for example Wordpress themes with limited customizability. Most DSLs won't allow full utilization of the underlying technology, on purpose because that's the only way to keep it simple. I do see this leading to a split into two classes of developers: those who only target simple DSLs using an LLM, and the "hard" engineers who might use LLMs every now and then, but mostly not.
ebhn
I like this direction, but I worry about developers involvement in the design of the DSL becoming the new bottleneck with the same problems. The code which becomes the guardrails cannot just be generated slop, it should be thoroughly designed and understood imo
ragall
Sure, that's why I think that it will mostly be SaaS businesses doing the DSLs, because the business contracts allow for more accountability than having employees do poor reviews, accumulating tech debt, that will only become visible down the road.
Quothling
To be fair to AI, it's not like Clean Code and it's OOP cult weren't already causing L1-3 cache misses by every abstraction and how they spread their functions out over multiple files. I'm not sure AI can really make it worse than that, and it's been a golden standard in a lot of places for 25 years. For the most part it doesn't matter, in most software it'll cost you a little extra on compute but rarely noticible. If you're writing software for something important though, like one of those astractions you talk about, then it's going to travel through everything. Making it even more important to actually know what you're building upon.
Still, I'm not convinced AI is necessarily worse at reading the documentation and using the abstractions correctly than the programmers using the AI. If you don't know what you're doing, then does it matter if you utilise an AI instead of google programming?
matheus-rr
The dependency tree is where this bites hardest in practice. A typical Node.js project pulls in 800+ transitive dependencies, each with their own release cadence and breaking change policies. Nobody on your team understands how most of them work internally, and that's fine - until one of them ships a breaking change, deprecates an API, or hits end-of-life.
The anon291 comment about interface stability is exactly right. The reason you don't need to understand CPU microarchitecture is that x86 instructions from 1990 still work. Your React component library from 2023 might not survive the next major version. The "nobody knows how the whole system works" problem is manageable when the interfaces are stable and well-documented. It becomes genuinely dangerous when the interfaces themselves are churning.
What I've noticed is that teams don't even track which of their dependencies are approaching EOL or have known vulnerabilities at the version they're pinned to. The knowledge gap isn't just "how does this work" - it's "is this thing I depend on still actively maintained, and what changed in the last 3 releases that I skipped?" That's the operational version of this problem that bites people every week.
pixl97
>What I've noticed is that teams don't even track which of their dependencies are approaching EOL or have known vulnerabilities at the version they're pinned to
I mean hopefully they are outsourcing it to some kind of SBOM/SCA type tool that monitors this.
With this said, I've seen a lot of projects before AI started touching anything stuck in this old dependency hell were they couldn't really get new versions integrated without causing hundreds of other problems leading to a cascade of failures.
sgarland
> “What happens when you type a URL into your browser’s address bar and hit enter?” You can talk about what happens at all sorts of different levels (e.g., HTTP, DNS, TCP, IP, …). But does anybody really understand all of the levels? [Paraphrasing]: interrupts, 802.11ax modulation scheme, QAM, memory models, garbage collection, field effect transistors...
To a reasonable degree, yes, I can. I am also probably an outlier, and the product of various careers, with a small dose of autism sprinkled in. My first career was as a Submarine Nuclear Electronics Technician / Reactor Operator in the U.S. Navy. As part of that training curriculum, I was taught electronics theory, troubleshooting, and repair, which begins with "these are electrons" and ends with "you can now troubleshoot a VMEbus [0] Motorola 68000-based system down to the component level." I also later went back to teach at that school, and rewrote the 68000 training curriculum to use the Intel 386 (progress, eh?).
Additionally, all submariners are required to undergo an oral board before being qualified, and analogous questions like that are extremely common, e.g. "I am a drop of seawater. How do I turn the light on in your rack?" To answer that question, you end up drawing (from memory) an enormous amount of systems and connecting them together, replete with the correct valve numbers and electrical buses, as well as explaining how all of them work, and going down various rabbit holes as the board members see fit, like the throttling characteristics of a gate valve (sub-optimal). If it's written down somewhere, or can be derived, it's fair game. And like TFA's discussion about Brendan Gregg's practice of finding someone's knowledge limit, the board members will not stop until they find something you don't know - at which point you are required to find it out, and get back to them.
When I got into tech, I applied this same mindset. If I don't know something, I find out. I read docs, I read man pages, I test assumptions, I tinker, I experiment. This has served me well over the years, with seemingly random knowledge surfacing during an incident, or when troubleshooting. I usually don't remember all of it, but I remember enough to find the source docs again and refresh my memory.
agumonkey
There's various degrees of understanding, for instance as a web dev, you know the browser, the osi network stack.. (in theory, there are a lot of tweaks) then maybe the electronics.. but the radio / wireless part is another world in itself with a totally different mindset (analog waves) which make the rabbithole way too long (and wide.. radio is a big world on its own)
cadr
Amateur radio is pretty approachable and has lots of opportunity to go down those rabbit holes.
joquarky
And it teaches much more practical knowledge.
wrs
Well, pixels on a screen are a totally different mindset from network protocols or program control flow, but nobody’s surprised when one person can work within all of those. Brains are big. So yeah, it’s just a matter of degree. (It’s the T-shaped vs I-shaped career thing.)
agumonkey
at least to me, I could learn most layers in a computer without choking completely. whenever i tried reading radio engineering i was drowning right away
wrs
I had the same reaction — yes, in fact I can at least explain all of those examples at an impromptu whiteboard talk level, and for many of them I can go a lot deeper.
But I hate not knowing how things work, and I have a pretty good memory, so I’m probably an outlier.
bjt
The claimed connections here fall apart for me pretty quickly.
CPU instructions, caches, memory access, etc. are debated, tested, hardened, and documented to a degree that's orders of magnitude greater than the LLM-generated code we're deploying these days. Those fundamental computing abstractions aren't nearly as leaky or nearly as in need of refactoring tomorrow.
mojuba
> AI will make this situation worse.
Being an AI skeptic more than not, I don't think the article's conclusion is true.
What LLM's can potentially do for us is exactly the opposite: because they are trained on pretty much everything there is, if you ask the AI how the telephone works, or what happens when you enter a URL in the browser, they can actually answer and break it down for you nicely (and that would be a dissertation-sized text). Accuracy and hallucinations aside, it's already better than a human who has no clue about how the telephone works or where to even begin if the said human wanted to understand it.
Human brains have a pretty serious gap in the "I don't know what I don't know" area, whereas language models have such a vast scope of knowledge that makes them somewhat superior, albeit at a price of, well, being literally quite expensive and power hungry. But that's technical details.
LLMs are knowledge machines that are good at precisely that: knowing everything about everything on all levels as long as it is described in human language somewhere on the Internet.
LLMs consolidate our knowledge in ways that were impossible before. They are pretty bad at reasoning or e.g. generating code, but where they excel so far is answering arbitrary questions about pretty much anything.
wrs
Very important distinction here you’re missing: they don’t know things, they generate plausible things. The better the training, the more those are similar, but they never converge to identity. It’s like if you asked me to explain the S3 API, and I’m not allowed to say “I don’t know”, I’m going to get pretty close, but you won’t know what I got wrong until you read the docs.
The ability for LLMs to search out the real docs on something and digest them is the fix for this, but don’t start thinking you (and the LLM) don’t need the real docs anymore.
That said, it’s always been a human engineer superpower to know just enough about everything to know what you need to look up, and LLMs are already pretty darn good at that, which I think is your real point.
wduquette
It's certainly the case that I don't always know how the layer below works, i.e., how the compiled code executes in detail. But I have a mental model that's good enough that I can use the compiler, and I trust that the compiler authors know what they are doing and that the result is well-tested. Over forty years and a slew of different languages I've found that to be an excellent bet.
But I understand how my code works. There's a huge difference between not understanding the layer below and not understanding the layer that I am responsible for.
B56b
That's the critical difference. You could always find some person who understood a particular piece of a complex puzzle. It's a very new, worrying thing to have pieces that no one understands.
PandaStyle
Perhaps a dose of pragmatism is needed here?
I am no CS major, nor do I fully understand the inner workings of a computer beyond "we tricked a rock into thinking by shocking it."
I'd love to better understand it, and I hope that through my journey of working with computers, i'll better learn about these underlying concepts registers, bus's, memory, assembly etc
Practically however, I write scripts that solve real world problems, be that from automating the coffee machine, to managing infrastructure at scale.
I'm not waiting to pick up a book on x86 assembly first before I write some python however. (I wish it were that easy.)
To the greybeards that do have a grasp of these concepts though? It's your responsibility to share that wealth of knowledge. It's a bitter ask, I know.
I'll hold up my end of the bargain by doing the same when I get to your position and everywhere in between.
finnthehuman
Graybeards love to yap. Just talk to them or consume the wide amount of material already out there.
It takes curiosity on your part though. Handwaving about practical concerns taking priority is a path to never getting around to it. "Pragmatism" towards skills is how managers wind up with an overspecialized team and then tell themselves it was inevitable. The same can happen to you.
sgarland
Nearly every time I attempt to tell people how much understanding fundamentals matters, it’s dismissed as being unnecessary knowledge.
I can’t make anyone want to know how things work, and it’s getting tiring being continuously told “no” when I ask.
hn_acc1
My daughter who is studying CS (unexpectedly) actually listens most of the time. Which is surprising. But then she tells me her classmates used AI to cheat on assignments so much that the prof had to change the weighting of the assignments to be 0.
I just don't get paying to "learn", and then using AI avoid learning.
OkayPhysicist
Some fraction of "students" are not, in fact, paying to learn. They're paying for a credential that claims they learned. Degrees tied to lucrative jobs tend to have a higher proportion of these people than ones that are less directly applicable.
LEDThereBeLight
Because to a 20 year old who is worried about getting a job, the value of getting all A’s and learning less is higher than getting all B’s and learning more.
supriyo-biswas
There are so many resources, for example, https://cpu.land.
s5300
[dead]
mamp
Strange article. The problem isn’t that everyone doesn’t know how everything works, it’s that AI coding could mean there is no one who knows how a system works.
lynguist
No I think the problem is AI coding removes intentionality. And that introduces artifacts and connections and dependencies that shouldn’t be there if one had designed the system with intent. And that makes it eventually harder to reason about.
There is a difference in qualia in it happens to work and it was made for a purpose.
Business logic will strive more for it happens to work as a good enough.
satisfice
The core problem is irresponsibility. Things that happen to work may stop working, or be revealed to have terrible flaws. Who is responsible? What is their duty of care?
stoneforger
Excellent point. The intention of business is profit, how it arrives there is considered incidental. Any product no matter what, as long as it sells. Compounding effects in computing, the internet and miniaturisation, have enabled large profit margins that further compound these effects. They think of this as a machine that can keep on printing more money and subsuming more and more as software and computers are pervasive.
raw_anon_1111
If the average tenure of a developer is 2.5 years, how likely is it in 5 years that any of the team that started the project is still working on it?
Animats
Including the AI, which generated it once and forgot.
This is going to be a big problem. How do people using Claude-like code generation systems do this? What artifacts other than the generated code are left behind for reuse when modifications are needed? Comments in the code? The entire history of the inputs and outputs to the LLM? Is there any record of the design?
maxbond
I have experimented with telling Claude Code to keep a historical record of the work it is performing. It did work (though I didn't assess the accuracy of the record) but I decided it was a waste of tokens and now direct it to analyze the history in ~/.claude when necessary. The real problem I was solving was making sure it didn't leave work unfinished between autocompacts (eg crucial parts of the work weren't performed and instead there are only TODO comments). But I ended up solving that with better instructions about how to break down the plan into bite-sized units that are more friendly to the todo list tool.
I have prompting in AGENTS.md that instructs the agent to update the relevant parts of the project documentation for a given change. The project has a spec, and as features get added or reworked the spec gets updated. If you commit after each session then the git history of the spec captures how the design evolves. I do read the spec, and the errors I've seen so far are pretty minor.
luckydata
Is this an actual problem? Takes minutes for an AI to explore and document a codebase. Sounds like a non problem.
shevy-java
Is that documentation useful? I haven't seen a well-documented codebase by AI so far.
To be fair - humans also fail at that. Just look at the GTK documentation as an example. When you point that out, ebassi may ignore you because criticism is unwanted; and the documentation will never improve, meaning they don't want new developers.
ahnick
Yes, exactly my point as well. It cuts both ways.
skeptic_ai
I for one I save all conversations in the codebase. Includes both human prompts and outputs. But I’m using a modified codex to do so. Not sure why it’s not default as it’s useful to have this info.
joquarky
It is probably not a default because it will use more tokens.
sceptic123
I read it more as:
We already don't know how everything works, AI is steering us towards a destination where there is more of the everything.
I would also add it's also possible it will reduce the number people that are _capable_ of understanding the parts it is responsible for.
g947o
Who's "we"?
I am sure engineers collectively understand how the entire stack works.
With LLM generated output, nobody understands how anything works, including the very model you just interacted with -- evident in "you are absolutely correct"
sceptic123
Even as a collective whole, engineers will likely only understand the parts of system that are engineering problems and solutions. Even if they could understand it all, there is still no _one_ person who understands how everything works.
dcre
Just because there is someone who could understand a given system, that doesn’t mean there is anyone who actually does. I take the point to be that existing software systems are not understood by anyone most of the time.
1718627440
I do not know about you all, but I need to understand the system before I can change anything, otherwise I would introduce tons of bugs. Heck, without knowing the system I do not even know what I *want* to change.
ahnick
This happens even today. If a knowledgeable person leaves a company and no KT (or more likely, poor KT) takes place, then there will be no one left to understand how certain systems work. This means the company will have to have a new developer go in and study the code and then deduce how it works. In our new LLM world, the developer could even have an LLM construct an overview for him/her to come up to speed more quickly.
stoneforger
Yes but every time the "why" is obscured perhaps not completely because there's no finished overview or because the original reason cannot be derived any longer from the current state of affairs. Its like the movie memento: you're trying to piece together a story from fragments that seem incoherent.
noosphr
It's that no one knows if a system works.
analog31
Granted I'm not a software developer, so the things I work on tend to be simpler. But the people I know who are recognized for "knowing how the whole thing works" are likely to have earned that distinction, not necessarily by actually knowing how it works but:
1. The ability and interest to investigate things and find out how they work, when needed or desired. They are interested in how things work. They are probably competent in things that are "glue" in their disciplines, such as math and physics in my case.
2. The ability to improvise an answer when needed, by interpolating across gaps in knowledge, well enough to get past whatever problem is being solved. And to decide when something doesn't need to be understood.
9rx
> Granted I'm not a software developer, so the things I work on tend to be simpler.
Intriguing statement. I've worked in a number of disciplines over the years and software, by far, presents the simplest things of all.
youarentrightjr
> Nobody knows how the whole system works
True.
But in all systems up to now, for each part of the system, somebody knew how it worked.
That paradigm is slowly eroding. Maybe that's ok, maybe not, hard to say.
redrove
> But in all systems up to now, for each part of the system, somebody knew how it worked.
If the project is legacy or the people just left the company that’s just not true.
youarentrightjr
> If the project is legacy or the people just left the company that’s just not true.
Yeah, that's why I said "knew" instead of "knows".
1718627440
Which is why such code is routinely thrown away and rewritten from scratch or just not really touched at all.
Get the top HN stories in your inbox every day.
There are many layers to this. But there is one style of programming that concerns me. Where you neither understand the layer above you (why the product exists and what the goal of the system is) nor the layer below (how to actually implement the behavior). In the past, many developers barely understood the business case, but at least they understood how to translate into code, and could put backpressure on the business. Now however, it's apparently not even necessary to know how the code works!
The argument seems to be, we should float on a thin lubricant of "that's someone else's concern" (either the AI or the PMs) gliding blissfully from one ticket to another. Neither grasping our goal nor our outcome. If the tests are green and the buttons submit, mission accomplished!
Using Claude I can feel my situational awareness slipping from my grasp. It's increasingly clear that this style of development pushes you to stop looking at any of the code at all. My English instructions do not leave any residual growth. I learn nothing to send back up the chain, and I know nothing of what's below. Why should I exist?