Nobody knows how the whole system works
surfingcomplexity.blog
surfingcomplexity.blog
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?
> 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.
Is this not a job for LLMs, though?
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”
I guess I could be more detailed in the prompt/md files about every time it changes lambda code, check the permissions in the corresponding IAC and check to see if a new VPC endpoint is needed.
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
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
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.
Then you don't have ownership. What you have is responsibility without ownership or authority if this rug pull can be performed.
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.
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.
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?
One bank pissed me off due to an extremely dishonest thing they did. So I overdrafted the account to the max ($500) and left them the bill.
(Not the first time I've done something like that to someone who deserved it. I've done much, much more in some cases. Endless painful papercuts? Nope, I do not accept that.)
They weren't happy about this. I think they hit "my" "credit" with that for years. I never noticed, as I don't borrow money; the machinations of these "credit reporting" agencies are beneath my concern. They have no credit in my eyes. I don't consort with crooks, I just punish them.
> 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.
I haven't had a phone in decades at this point. Don't want one. I refused to be tracked, monitored, or abused by anyone. And no, I sure don't give a single fuck about any of the many people (and there have been MANY) who have tried their best to shame, cajole, insult, ridicule, harass, intimidate, or bully me into getting a phone. Fuck em all.
> Your chain of reasoning is broken? Or is it your model of the world?
Maybe it's you who's broken. Why do you accept slavery? Just to fit in?
Since you're hardly the only one with a similar way of thinking, maybe we could say it's the entire society that's broken.
I simply do not tolerate the things that you tolerate.
I think theft is a poor answer - although most society accepts your rationalisation when dealing with government or big business.
Even worse is that you can't know what it may cost you in the future. My friend couldn't open a business account the other day. After many phone calls he was lucky enough to find someone that told him it was because he left that bank with an account $67 overdrawn when he was younger. That's in New Zealand: I strongly suspect he never would have found out the reason he was denied in many countries[1]. His only recourse was to use a more expensive provider (maybe $600 per year).
Please don't assume I am tolerant of abuse. I vindictively avoid some brands (and even all products from some countries).
I just often judge that my changing to a different service has costs I would rather avoid so I stick with a known evil (I'm good at finding workarounds for many niggles).
I also accept annoying papercuts because I believe all services have imperfection and flaws. Too many people count costs without balance.
What is this perfect bank you have discovered without papercuts?
[1] https://www.bitsaboutmoney.com/archive/debanking-and-debunki...
Theft? HA! Nope, they attempted to rob me, on multiple levels. Categorically refused.
> Even worse is that you can't know what it may cost you in the future. My friend couldn't open a business account the other day. After many phone calls he was lucky enough to find someone that told him it was because he left a bank account $67 overdrawn when he was younger.
Oh no! How will I ever conduct business without the government or bank's permission? I guess the only alternative is slavery to some giant corporation, or death! What should I do?
As an American, I would probably like to consult with Thomas Jefferson, Thomas Paine, Smedley Butler, Lysander Spooner, Mark Twain, etc and get their thoughts on this matter.
While looking something up just now, this old saved quote from years back popped right into view. Couldn't have said it better myself:
"Why work at all? Just live off the system. The aristocrats do it lavishly. The welfare rats do it slovenly. Both know that working for an 'honest dollar' in this empire of lies is for suckers. This is why they set up artificial barriers of entry such as needing a 'college degree' for so many jobs so you have to wade through all that propaganda bullshit they spew these days. It's also why they have to make sure property prices stay high to keep the cheese dangling in front of the mouse. The system is designed to keep you churning the wheel while the others sit back, relax, and enjoy a life of leisure at your expense."
Ah! Found a serious problem. Not the problem, mind you, but a problem. There's a reason the self-described "elites" like to hole up in that place.
(It would be a shame if they never emerged from those holes. What would the world do without their 'leadership'?)
> I strongly suspect he never would have found out the reason in many countries.
Yes, I agree, there are many shithole countries in the world. I live in one, too. One learns to adapt.
> His only recourse was to use a more expensive provider (maybe $600 per year).
Yes, this corrupt country tried to screw me in a similar type of way, years back. I refused to play ball and just did what I wanted instead, very carefully and quietly. Now that problem is permanently resolved, for a fraction of what it would have otherwise cost.
> Please don't assume I am tolerant of abuse. I vindictively avoid some brands (and even all products from some countries).
One time, I went to the local Wal-Mart a couple days before Christmas. I parked at the back of the lot as the place was packed full. No problem, I don't mind walking. But then imagine my displeasure to observe that some complete asshole in a giant lifted pickup truck has double parked near the front of the lot.
That guy was way more important than anyone, in his own mind, clearly. Someone just had to educate him about how so very wrong he was. The job fell to me, as I was the closest warrior at hand.
So I sent a shopping cart sailing at warp 11 into his truck. ("Engage!") It just so happened to impact right on the corner of the cab, behind the door (the worst spot possible--thanks, God), and fucked it all up. Mission Accomplished. I returned home and celebrated.
I know of another funny incident where a similar type of person was similarly unimpressed by some douchebag in a Maserati (this is hillbilly country, home of Chevys and Fords) who likewise felt entitled to take up two parking spots on a busy main street where parking was limited. In this case the guy dumped a tractor bucket load of wet hay into his open convertible top.
The "victim" of that incident was raging on Facebook, offering a reward for whoever turned the guy in, etc, but everyone was just laughing at the SOB.
You'd be surprised what you can get away with, when everyone around you is quietly wishing somebody would do just that thing.
I realize this is a radical concept for your society, which at this moment is thoroughly unjust. Familiarize yourself with this concept now, as it will come up later on the test.
No wonder you keep getting robbed and fucked over all the time. You think it's somehow morally wrong to strike back! It's like you were born and bred to be a victim.
This also explains why so many others get victimized while you stand by and watch idly. Because you think there's nothing wrong with your fellow man getting fucked over!
I could explain more, but it would be useless, as your confusion is at this time far too thick and heavy to be dispelled by just one guy like me. What you're gonna need is somebody like me in your local area to help educate you.
My recommendation is to just double park your big ass honkin truck or Maserati somewhere, then just watch and see what happens. Eventually, you will reach enlightenment.
First off, you make me think of an awakened and fully actualized version of Luke Smith.
So you're like, a hardcore American Libertarian? The no phone thing is incredibly based, and personally I think smashing a shopping cart into some asshole's truck is both hilarious and just. I do similar when I cone illegally parked cars.
So why libertarian and not anarchist? You seem to appreciate direct action. You seem to have opposition to all forms of oppression be they coming from the government or a bank or a corporation, you're willing to make what some would consider huge personal sacrifice to stand for your values. Is it an inherent distaste of leftist thought? If you are libertarian, that word was born in the most far left circles possible. It still is a synonym for "anarchist" in most places in the world.
I'm not trying to get your goat here. I like talking to people with completely different ideologies than me. Keeps me on my toes, prevents fossilization.
Only because they're all painful. If there was a bank that was recognized as perfect, people would switch in short order. Switching to another bank that is also painful is not worth the effort.
> 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.
Only because nobody else sells an iPhone. People would start switching over to other, less buggy iPhone on the market if there was such a thing.
> You are implying efficient market theory, which is bunk.
The efficient market theory says that, in an active market, prices rapidly reflect all publicly available information. How does that apply here, bunk or not?
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.
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.
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!
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.
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)
(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.
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.
I swear, do you people even hear yourselves?
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...
Same as "self-driving cars", the automated farm machinery can't cope with any sort of change in its environment.
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.
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.
If it's at large scale then millions die of starvation.
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.
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.
You can eat some real terrible stuff and like 99.999% of the time only get the shits, which isn't really a concern if you have good access to clean drinking water and can stay hydrated.
The overwhelming majority of people probably would figure it out even if they wind up eating a lot of questionable stuff in the first month and productivity in other areas would dedicate more resources to it.
Maybe if you end up alone and lost in a huge forest or the Outback, but this is a highly unlikely scenario.
If society falls apart cooking isn’t something you need to be that worried about unless you survive the first few weeks. Getting people to work together with different skills is going to be far more beneficial.
I also wasn't putting the focus is on cooking, the ability to hunt/gather/grow enough food and keep yourself warm are far more important.
And you are far more optimistic about people than me if you think people working together is the likely scenario here.
These are very important when you're alone. Like deep in the woods with a tiny group maybe.
The kinds of problems you'll actually see are something going bad and there being a lot of people around trying to survive on ever decreasing resources. A single person out of 100 can teach people how to cook, or hunt, or grow crops.
If things are that bad then there is nearly a zero percent change that any of those, other than maybe clean water, are going to be your biggest issue. People that do form groups and don't care about committing acts of violence are going to take everything you have and leave you for dead if not just outright kill you. You will have to have a big enough group to defend your holdings 24/7 with the ability to take some losses.
Simply put there is not enough room on the planet for hunter gathers and 8 billion people. That number has to fall down to the 1 billion or so range pretty quickly, like we saw around the 1900s.
https://www.scribd.com/document/110974061/Selco-s-Survival
From a real situation, only alluding to the true horrors of the situation.
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.
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.
In fact it says "This isn't a problem in practice though"
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)
The key to survival has always been tribal dynamics. This wouldn't change in the apocalypse.
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.
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.
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?
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.
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.
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.
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.
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.
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...
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.
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
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.
I was thinking more about what I believe you describe as the "hard" engineers, and would say the power AI provides for mapping and translating will greatly benefit those teams as well with the right set-up. People are pushing for the "code for me" angle, but i think there will be a lot of opportunity to have LLMs take on a middle ground of syntax management while the engineers manage the system effects. for example, the engineer may be deciding whether to use a linked list or binary tree and the LLM is implementing it with the available code stack approved by the company.
A company that can successfully implement such an LLM opens up their talent pool from people who know their stack (or want to learn it) to people who know any stack
At this point it's a slightly more sophisticated version of the IDE's "refactor tool". If, in addition to replacing "HashMap" with "LinkedList" in a bunch of places, it might also fix tests, then it's indeed useful but won't be worth paying much more for it.
> A company that can successfully implement such an LLM opens up their talent pool from people who know their stack (or want to learn it) to people who know any stack
Think about it: if the business usefulness of a tool is mostly in reducing onboarding time by even a 75%, it's not really that valuable.
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?
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.
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.
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.
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.
But I hate not knowing how things work, and I have a pretty good memory, so I’m probably an outlier.
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.
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.
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.
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.
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.
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.
I can’t make anyone want to know how things work, and it’s getting tiring being continuously told “no” when I ask.
I just don't get paying to "learn", and then using AI avoid learning.
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?
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.
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.
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.
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.
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"
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.
Intriguing statement. I've worked in a number of disciplines over the years and software, by far, presents the simplest things of all.
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.
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".
That doesn’t make it OK. This is like being stuck in a room whose pillars are starting to deteriorate, then someone comes along with a sledgehammer and starts hitting them and your reaction is to shrug and say “ah, well, the situation is bad and will only get worse, but the roof hasn’t fallen on our heads yet so let’s do nothing”.
If the situation is untenable, the right course of action is to try to correct it, not shrug it off.
One can continue to perfect and exercise their craft the old school way, and that’s totally fine, but don’t count on that to put food on the table. Some genius probably can, but I certainly am not one.
Humans aren’t without flaws; prior to coding assistants, I’ve lost count of the times my PM telling me to rush things at the expense of engineering rigor. We validate or falsify the need for a feature sooner and move on to other things. Sometimes it works sometimes a bug blows up in our faces, but things still chug along.
This point will become increasingly moot as AI gets better at generating good code, and faster, too.
“Nobody knows how the whole system works, but at least everybody should know the part of the system they are contributing to.
Being an engineer I am used to be expert of the very layer of the stack I work on, knowing something of the adjacent layers, mostly ignoring how the rest work.
Now that LLMs write my very code, what is the part that I’m supposed to master? I think the table is still shifting and everybody is failing to grasp where it will stabilize. Analogies with past shifts aren’t helping either.‘
The issue with frameworks is not the magic. We feel like it's magic because the interfaces are not stable. If the interfaces were stable we'd consider them just a real component of building whatever
You don't need to know anything about hardware to properly use a CPU isa.
The difference is the cpu isa is documented, well tested and stable. We can build systems that offer stability and are formally verified as an industry. We just choose not to.
Three minute video by Milton Friedman: https://youtu.be/67tHtpac5ws?si=nFOLok7o87b8UXxY
This particular example can be misinterpreted though. It's true that no single person knows how to make that exact pencil that he is holding. But it's not true that no single individual exists who can make a pencil by themselves. If the criteria is just that it works as a pencil, then many people could make or find something that fills that criteria.
This is an important distinction because there are things like microprocessors, which no single person knows how to make. But also: no single person could alone build something that has anywhere near the same capability. It's conceivable that a civilization could forget how to do something like that because it requires so many people with non-overlapping knowledge to create anything close. We aren't going to forget how to make pencils because it is such a simple problem, that many individuals are capable of figuring out workable solutions alone.
I recently watched this: https://www.youtube.com/watch?v=MiUHjLxm3V0
The levels of advanced _whatever_ that we've reached is absurdly bonkers.
It seems to me that at some point in the last 50 or so years the world went from "given a lot of time I can make a _crude_ but reasonably functional version of whatever XYZ in my garage" to "it requires the structural backbone of a whole civilization to achieve XYZ".
Of course it's sort of a delusion. Maybe it's more about the ramp appearing more exponential than ever.
That depends on your definition of “knows how to make.” I worked at Samsung Austin Semiconductor for a while, and there are some insanely smart and knowledgeable people there (and, I’m sure, at every other semiconductor company). It was actually a really good life experience for me, because it grounded and humbled me in the way that only working around borderline genius can.
I can describe to you all the steps that go into manufacturing a silicon wafer, with more detail in my particular area (wet cleans) than others, but I certainly can’t answer any and all questions about the process. However, I am nearly certain that there existed at least one person at SAS who could describe every step of every process in such excruciating detail that, given enough time and skilled workers (you said “know,” not “do” - I am under no delusion that a single person could ever hope to build a fab), they could bootstrap a fab.
The hard part is finding graphite (somewhere in Wales? looks like lead, but softer and leaves traces on sheep's wool). Then suitable clay to make the lead. Then some kind of glue to glue the two parts of the pencil (boil some bones and cartilages?).
I know a shitload of trivia about both manufacturing and pencils. But I could not possibly recreate all the processes needed to manufacture a pencil.
I learned a lot about pencils from this article. It is also applicable to jet engines.
This new arrangement would be perfectly fine if they aren't responsible when/if it breaks.
AI and humans are labor that can be put to work designing and vetting such systems. The problem with AI isn’t that it builds things we don’t understand. It’s that we do not have much experience with its failure modes, limitations and risks. There are many unknown unknowns.
It’s directly analogous to the problem of hiring, management, outsourcing and contacting. Sure, we know that labor can produce massive, highly reliable systems nobody fully understands. But how do we coordinate labor, AI and human, to successfully produce the systems we actually need? What failure modes and advantages does AI introduce into the mix for specific projects?
That’s where the uncertainty comes from, not the lack of comprehensive knowledge of the systems themselves.
Adam Jacob
It’s not slop. It’s not forgetting first principles. It’s a shift in how the craft work, and it’s already happened.
Bruce Perens
Do not underestimate the degree to which mostly-competent programmers are unaware of what goes on inside the compiler and the hardware.
"I don't need to know about software engineering, I'm writing code."
"I don't need to know how to design tests, ____ vibe-coded it for me."
https://youtu.be/36myc8wQhLo (USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware)
Systems include people, that make their own decisions that affect how they work and we don’t go down to biology and chemistry to understand how they make choices. But that doesn’t mean that people decisions should be fully ignored in our analysis, just that there is a right abstraction level for that.
And sometimes a side or abstracted component deserves to be seen or understood with more detail because some of the sub components or its fine behavior makes a difference for what we are solving. Can we do that?
Does anyone on the planet actually know all of the subtleties and idiosyncrasies of the entire tax code? Perhaps the one inhabitant of Sealand and the Sentinelese but no-one in any western society.
Edit: In a sense "AI" software development is postmodern, it is a move away from reasoned software development in which known axioms and rules are applied, to software being arbitrary and 'given'.
The future 'code ninja' might be a deconstructionist, a spectre of Derrida.
It’s like if you are building a production line. You need to use a certain type of steel because it has certain heat properties. You don’t need to know exactly how they make that type of steel. But you need to know to use that steel. AI slop is basically just using whatever steel.
At every layer of abstraction in complexity, the experts at that layer need to have a deep understanding of their layer of complexity. The whole point is that you can rely on certain contracts made by lower layers to build yours.
So no, just slopping your way through the application layer isn’t just on theme with “we have never known how the whole system works”. It’s ignoring that you still have a responsibility to understand the current layer where you’re at, which is the business logic layer. If you don’t understand that, you can’t build reliable software because you aren’t using the system we have in place to predictably and deterministically specify outputs. Which is code.
"It's not slop. It's not forgetting first principles. It's a shift in how the craft work, and it's already happened."
It actually really is slop. He may wish to ignore it but that does not change anything. AI comes with slop - that is undeniable. You only need to look at the content generated via AI.
He may wish to focus merely on "AI for use in software engineering", but even there he is wrong, since AI makes mistakes too and not everything it creates is great. People often have no clue how that AI reaches any decision, so they also lose being able to reason about the code or code changes. I think people have a hard time trying to sell AI as "only good things, the craft will become better". It seems everyone is on the AI hype train - eventually it'll either crash or slow down massively.
For example, why is the HP-12C still the dominant business calculator? Because using other calculators for certain financial calculations were non-deterministically wrong. The HP-12C may not have even been strictly "correct", but it was deterministic in the ways in wasn't.
Financial people didn't know or care about guard digits or numerical instability. They very much did care that their financial calculations were consistent and predictable.
The question is: Who will build the HP-12C of AI?
Of the top of my head? Most of them. Did you need me to understand some level in particular? I can dedicate time to that if you like. My experience and education will make that a very simple task.
The better question is.. is there any _advantage_ to understanding "all the levels?" If not, then what outcome did you actually expect? A lot of this work is done in exchange for money and not out personal pride or desirous craftsmanship.
You can try to be the "Wizard of Oz" if you want. The problem is anyone can do that job. It's not particularly interesting is it?
But what is not possible is to understand all these levels at the same time. And that has many implications.
Humans we have limits on working memory, and if I need to swap in L1 cache logic, then I can't think of TCP congestion windows, CWDM, multiple inheritance, and QoS at the same time. But I wonder what superpowers AI can bring, not because it's necessarily smarter, but because we can increase the working memory across abstraction layers.
What you need to understand is the API's in-between the sub-systems.
Another way to put it is that the architecture is the API's.
You can in principle throw away and re-implement the sub-system for a specific API without understanding the rest of the system.
I am saying in principle because in practice API's are typically under-specified leaving out important side effects.
The cost is you lose those layers of abstractions you get at the higher software levels, and there's only so much complexity I can handle.
(the funny part is that even HW registers and stuff are just an API that the hardware chooses to expose. As Alan Kay said: "Hardware is really just software crystallized early")
Consider the distinction between I don't know how the automatic transmission in my car works, vs. I never bothered to learn the meanings of the street signs in my jurisdiction.
https://www.cs.ucdavis.edu/~koehl/Teaching/ECS188/PDF_files/...
So nothing new under the sun, often the practices come first, then only can some theory emerge, from which point it can be leverage on to go further than present practice and so on. Sometime practice and theory are more entengled in how they are created on the go, obviously.
That's the beauty of specialization.
The same goes for software.
You have to understand some of the system, and saying that if no one understands the whole system anyway we can give up all understanding is a fallacy.
Even for a programming language that is criticized for a permissive spec like C you can write a formally verified compiler, CompCert. Good luck doing that for your agentic workflow with natural language input.
Citing a few manic posts from influencers does not change that.
sometimes that trust is proven wrong. I have had to understand my compiler output to prove there was a bug in the optimizer (once I understood the bug I was able to find it was already fixed in a release I hadn't updated to yet). Despite that compilers have earned my trust: It is months of debugging before I think maybe the compiler is wrong.
I am not convinced that AI writes code I can trust - too often I have caught it doing things that are wrong (recently I told it to write some code using TDD - and it put the business logic it was testing in the mock - the tests passed, but manual testing showed the production code didn't have that logic and so didn't work). Until AI code proves it is worth trusting I'm not going to trust it and so I will spend the time needed to understand the code it writes - at great cost to my ability to quickly write code.
A few comments on that. First off, the best programmers I've worked with recognized when their abstractions were leaky, and made efforts to understand the thing that was being abstracted. That's a huge part of what made them good! I have worked with programmers that looked at the disassembly, and cared about it. Not everyone needs to do that, but acting like it's a completely pointless exercise does not track with reality.
The other thing I've noticed personally for myself is my biggest growth as a programmer has almost aways come from moving down the stack and understanding things at a lower level, not moving up the stack. Even though I rarely use it, learning assembler was VERY important for my development as a programmer, it helped me understand decisions made in the design of C for instance. I also learned VHDL to program FPGAs and took an embedded systems course that talked about building logic out of NAND gates. I had to write a game for an FPGA in C that had to use a wonky VGA driver that had to treat an 800x600 screen as a series of tiles because there wasn't nearly enough RAM to store that framebuffer. None of this is something I use daily, some of it I may never use again, but it shaped how I think and work with computers. In my experience, the guys that only focus on the highest levels of abstractions because the rest of the stuff "doesn't matter" easily get themselves stuck in corners they can't get out of.
You have to know enough about underlying and higher level systems to do YOUR job well. And AI cannot fully replace human review.
Yes you can make better and more perfect solutions with a deep understanding of every consequence of every design decision. Also you can make some real world situation thousands of times better without a deep understanding of things. These two statements don't disagree at all.
The MIPS image rendering example is perfect here. Notice he didn't say "there was some obscure attempt to load images on MIPS and nobody used it because it was so slow so they used the readily available fast one instead". There was some apparently widely used routine to load images that was popular enough it got the attention of one of the few people who deeply understands how the system worked, and they fixed it up.
PHP is an awful trash language and like half the internet was built on it and lots of people had a lot of fun and got a lot more work done because people wrote a lot of websites in PHP. Sure, PHP is still trash, but it's better to have trash than wait around for someone to 'do it right', and maybe nobody ever gets around to it.
Worse is better. https://en.wikipedia.org/wiki/Worse_is_better
Then you know “what” to build.
The lack of comprehensive, practical, multi-disciplinary knowledge creates a DEEP DEPENDENCY on the few multinational companies and countries that UNDERSTAND things and can BUILD things. If you don't understand it, if you can't build it, they OWN you.
My takeaway is that modern system complexity can only be achieved via advanced specialization and trade. No one human brain can master all of the complexity needed for the wonders of modern tech. So we need to figure out how to cooperate if we want to continue to advance technology.
My views on the topic were influenced by Klings book (it's a light read) https://www.libertarianism.org/books/specialization-trade
The problem is education, and maybe ironically AI can assist in improving that
I've read a lot about programming and it all feels pretty disorganized; the post about programmers being ignorant about how compilers work doesn't sound surprising (go to a bunch of educational programming resources and see if they cover any of that)
It sounds like we need more comprehensive and detailed lists
For example, with objections to "vibe coding", couldn't we just make a list of people's concerns and then work at improving AI's outputs which would reflect the concerns people raise? (Things like security, designs to minimize tech debt, outputting for rradability if someone does need to manually review the code in the future, etc.?)
Incidentally this also reminds me of political or religious stances against technology, like the Amish take for example, as the kind of ignorance of and dependence on processes out of our control discussed seem to be inherent qualities of technological systems as they grow and become more complex.
However, there is a fundamental flaw in this analogy: compilers are deterministic, AI is not. You get high-level code and compile it twice, you get exactly the same output. You get specs and generate high-level code through AI twice, you get two different outputs (hopefully with equivalent behaviour).
If you don't understand that deterministic vs. non-deterministic is a fundamental and potentially dangerous change in the way we produce work, then you definitely fail at first principles.
The whole point of society is that you don’t need to know how the whole thing works. You just use it.
How does the water system maintain pressure so water actually comes out when you turn on the tap? That’s entirely the wrong question. You should be asking why you never needed to think about that until now, because that answer is way more mind-expanding and fascinating. Humans invented entire economic systems just so you don’t need to know everything, so you can wash your hands and go back to your work doing your thing in the giant machine. Maybe your job is to make software that tap-water engineers use everyday. Is it a crisis if they don’t understand everything about what you do? Not bloody likely - their heads are full of water engineering knowledge already.
It is not the end of the world to not know everything - it’s actually a miracle of modern society!
With all hands on deck scrambling HARD, a week later we still didn’t have everything back up, because we didn’t know how. A ton of it had never been down since the 60s.
A mess indeed.
LinkedIn is weeks/months behind topics that originate from X. It suggests you might be living in a bubble if you believe X has fallen.
This is a bad take.
Write servers/clients with rc(1) and the tools at /bin/aux, such as aux/listen. They already are irc clients and some other tools. Then, do 9front's C book from Nemo.
On floats, try them at 'low level', with Forth. Get Muxleq https://github.com/howerj/mux. Compile it:
cc -O2 -ffast-math -o muxleq muxleq.c
1 constant opt.multi ( Add in large "pause" primitive )
1 constant opt.editor ( Add in Text Editor )
1 constant opt.info ( Add info printing function )
0 constant opt.generate-c ( Generate C code )
1 constant opt.better-see ( Replace 'see' with better version )
1 constant opt.control ( Add in more control structures )
0 constant opt.allocate ( Add in "allocate"/"free" )
1 constant opt.float ( Add in floating point code )
0 constant opt.glossary ( Add in "glossary" word )
1 constant opt.optimize ( Enable extra optimization )
1 constant opt.divmod ( Use "opDivMod" primitive )
0 constant opt.self ( self-interpreter [NOT WORKING] )
./muxleq muxleq.dec < muxleq.fth > new.dec
./muxleq new.dec
Also, compare CSP to the concurrent Forth switching tasks. It's great to compare/debug code in a tiny Forth on Subleq/Muxleq because if your code gets relatively fast, it will fly under GForth and due to constraints you will force yourself to be a much better programmer.
CPU's? Cache's? RAM latency? Muxleq/Subleq behaves nearly the same everywhere depending on your simulation speed. In order to learn, it's there. On real world systems, glibc, the Go runtime, etc, will take care of that making a similar outcome everyhere. If not, most of the people out there will be aware of stuff from SSE2 and up to NEON under ARM.
Hint: they already are code transpilers from Intel dedicated instructions to ARM ones and viceversa.
>How garbage collection works inside of the JVM?
No, but I can figure it a little given the Zenlisp one as a slight approximation. Or... you know, Forth, by hand. And Go which seems easiers and it doesn't need a dog slow VM trying to replicate what Inferno did in the 90's which far less resources.