I've reread it and I stand by my statements that it's an isomorphism, simply replace "container" with "machine AAD/auth-system boundaries" in your example.
The "Your credentials stay out of the sandbox" problem, to quote them, is what I see your "require your perms system to enforce it" as implicitly solving for.
(Their "sandbox as cattle" discussion had less bearing on the "which pattern" question to me, since I tend to treat most parts of my agent stack as cattle-like, potentially out of a bias towards that architecture broadly, as I find it's much easier to reason about when as much as possible is disposable/idempotent/eventually consistent.
The durable execution point also assumed aspects of the agent scaffold ala prompts don't have to be turned over in deploy, or conversely, can't finish their tasks and then migrate incrementally, and while I might cynically raise an eyebrow at the focus on 25ms for sandbox calls given the dev loops I currently experience, I'd argue there are other ways to solve that problem in both an in or outside of container sandbox pattern.)
I'd even agree with their final point "Consistency is the part we haven't answered" but in a different angle than they intended, as to why my focus was on "how do you _constrain_ agent behavior" since that has been, in my experience, the biggest bottleneck to letting agents do more.
I'd argue you are still using a sandbox, just at a higher ring (outside the machine/VM) and relaying on app/resource level permissions on each of your external resources to enforce it, which requires _all_ of those external systems to be hardened vs. the agent host itself. The capabilities a full machine has for exploring and exploiting external, ostensibly secured systems, has already been touched on via incidents like the anthropic internal model jailbreak. [0]
Giving the whole machine also doesn't answer the question for how the agent can hook into actions that eventually require more perms, and even if you "airgap" those via things like output queues that humans need to approve, that still feels "harnessey" to me.
I feel a bit guilty of debating semantics here, especially as I can't/don't intend to convey any confidence in a "right answer", but my reason for being pedantic is that I do think there are interesting tradeoffs between "P(jailbreak or unexpected capability use|time)" and "increasing power/available capability set", as well as interesting primitives emerging in terms of the components you'd need regardless of where you drew that line (ala paragraph 2.)
While I typically avoid touching non-technical topics, I have the opportunity to chime in as another PA highschooler from the 90's, we absolutely were taught that, down to details in AP courses such as the impact of individuals like John Brown. While I'm not sure I'd have worded it precisely like the parent, the concept of "the four boxes of liberty" and the progression thereof was certainly understood and conveyed. (There was substantial study of the labor rights movements and conflicts/resistance therein as well)
As a manager, I've tried for years to balance both sides of this coin.
However, what I find in practice is that your success depends almost entirely on the trust your leadership has in you.
Strong support? Doesn't really matter what you work on, legible or not.
Weak support? You can do exactly what they ask and it'll still be an uphill battle, leaving you in a hard situation where you can find ways to do the illegible work, but it will require spending political capital you already don't have (And to preempt the "make that work visible and valued" counterargument, that only goes so far if incentives are misaligned), or gambling that you can change their perceptions by only focusing on the legible work for a time even if it results in worse long-term engineering outcomes and may not bear fruit.
In short, I'd say the most actionable advice I'd give is less about where you spend your time, and more finding a team (or more importantly, a sponsor) where however you spend your time will be valued.
I'm similarly bemused by those who don't understand where the anti-AI sentiment could come from, and "they must be doing it wrong" should usually be a bit of a "code smell". (Not to mention that I don't believe this post addresses any of the concrete concerns the article calls out, and makes it sound like much more of a strawman than it was to my reading.)
To preempt that on my end, and emphasize I'm not saying "it's useless" so much as "I think there's some truth to what the OP says", as I'm typing this I'm finishing up a 90% LLM coded tool to automate a regular process I have to do for work, and it's been a very successful experience.
From my perspective, a tool (LLMs) has more impact than how you yourself directly use it. We talk a lot about pits of success and pits of failure from a code and product architecture standpoint, and right now, as you acknowledge yourself in the last sentence, there's a big footgun waiting for any dev who turns their head off too hard. In my mind, _this is the hard part_ of engineering; keeping a codebase structured, guardrailed, well constrained, even with many contributors over a long period of time. I do think LLMs make this harder, since they make writing code "cheaper" but not necessarily "safer", which flies in the face of mantras such as "the best line of code is the one you don't need to write." (I do feel the article brushes against this where it nods to trust, growth, and ownership) This is not a hypothetical as well, but something I've already seen in practice in a professional context, and I don't think we've figured out silver bullets for yet.
While I could also gesture at some patterns I've seen where there's a level of semantic complexity these models simply can't handle at the moment, and no matter how well architected you make a codebase after N million lines you WILL be above that threshold, even that is less of a concern in my mind than the former pattern. (And again the article touches on this re: vibe coding having a ceiling, but I think if anything they weaken their argument by limiting it to vibe coding.)
To take a bit of a tangent with this comment though: I have come to agree with a post I saw a few months back, that at this point LLMs have become this cycle's tech-religious-war, and it's very hard to have evenhanded debate in that context, and as a sister post calls out, I also suspect this is where some of the distaste comes from as well.
I've appreciated reading your posts broadly/for years prior to this as well, so definitely same statement back your way. If you're ever in the PNW, beers/coffee is on me.
While tone on the internet admittedly makes it hard to tell if your comment was tongue-in-cheek, I'm going to take this in good faith and express my appreciation that you even read through that entire ramble above :)
While "try it and see what happens" may work for low-risk efforts, the costs and chaos associated with this in a system as complex as global employment seems eminently short-sighted. We've already seen how "Try it and see what happens" works for tariffs, have we not?
To your point of cranking it up, I argue that there simply is not a clearing cost that makes US labor viable for many of these positions in the modern world without effectively rendering that service non-viable or dropping US worker purchasing power by a similar multiplier to the salary gap.
In that respect, last I heard, voters and representatives were _viscerally_ opposed to anything that sounded like "Degrowth" which would be the practical outcome of such a policy. (Not making a personal statement here beyond addressing your theory)
In short, my thesis is that if we really want to fix the offshoring issue, there are fundamentally more significant issues that need to be addressed, and absent fixing those, we're only harming ourselves.
Edit: your parent post substantially changed in between my response and now, so I'll address it as currently stands as well:
I'm not sure where "spirit of the law" comes in vs. being a convenient phrase for whatever is being advocated for. I've seen it used innumerably on this very site to defend pushback against worker protections for the last decade in defense of duty to shareholders, certainly.
There is no law that dictates fiscal decisions without regard for practical outcome; that's just bad policy. We appear to not even expect our executive to follow laws at this moment, so the rest of your statement seems to be even more of a non-sequitur. The business-as-a-conceptual-entity will not "suffer" as it's not a human being as much as we'd like the schadenfreude. While it may take a hit in revenue, it has the ability to act globally, it has the ability to shift costs, individuals do not have nearly as much ability to arbitrage, and often have their hands forced.
(Look at how UPS is dramatically raising their fees, and will likely profit substantially despite reduced volume. Who is hurting there, the business or the people?)
I'm also not sure what your statement about zoom is in respect to; these business centers are often self-contained entire LOB or call center vs. working across borders. Just on a basis of population, companies like india can provide services that are not realistic for the US , and we are now taxing ourselves for needing to take advantage of that in a globally competitive environment.
(It feels weird to be arguing this since I'm largely pro-supporting-local-labor-markets, and extremely pro-labor broadly, but frankly this is just counterproductive legislation and not the way to go about it. We need to lean on our comparative advantages, not cut off our hand to spite our face.
To make this even more explicit with an example: I would not have this argument were the legislation targeted at specific tactical sectors where the US currently has a meaningful moat or margin, and were an all-out ban against offshoring within those sectors alongside concrete measures to support onshoring, vs. a tactlessly-broad half-measure.)
I respectfully think you overestimate the impact this will have.
Like with the H1-B cap discussions there were murmurs about some time back (Not actually reducing the cap, but instead priority-weighting it by salary instead of difficulty to fill the position, something that'd actually _hurt_ US workers in the positions they can actually compete and be paid well for) this change feels a lot more like a performative money grab than something that will actually change the economics.
Indian headcount is not 25% cheaper for the roles I've seen it used for. It is integer-N cheaper, where N can sometimes be >3-5. Additionally, there simply is not the functional, social, or business infrastructure to spin up a new 10k person business center overnight in the US, meaning that for many use cases even if individual labor is findable, it's not realistic in the same respect.
If anything my fear (and what I've observed thus far) is that businesses will see overseas staffing as critical enough that the cuts will come out of the highest cost center: US employment.
While I agree with your over/underestimate statement, I unfortunately think you've got it backwards, where we're overestimating the change this pressure is going to lever on how our data is utilized in the short term, and underestimating the reversion to the mean.
Next to companies like Palantir, AT&T(Room641A), Equifax, and hell, even credit card processors, I've always found the ire directed at Facebook to seem... scapegoatey? I'd observe that anger against those companies was quick to fade, and has not seemed to negatively impact employees to work for them, nor created a regulatory environment wherein that work isn't supported. (selfishly us-centric here)
Hell, after the snowden revelations, did those with NSA/govt credentials have trouble getting a job? If that didn't move the needle (and I say this as someone who had been doing gov. funded research at the time, and would have liked to see a stronger response) I'm pessimistic that we'll ever see meaningful long term perceptual shifts in this respect outside of when they're driven by a media-cycle furor.
(To address the root of this comment tree, I think the fad hasn't outlasted the media cycle, I think the media cycle has realized this topic continues to drive clicks for now)
Simply, I worry a lack of privacy, and lack of accountability for corporations/govt, has largely become normalized; or at least that people are increasingly unlikely to act in this direction without heavy media pressure. I hope I'm wrong.
The "Your credentials stay out of the sandbox" problem, to quote them, is what I see your "require your perms system to enforce it" as implicitly solving for.
(Their "sandbox as cattle" discussion had less bearing on the "which pattern" question to me, since I tend to treat most parts of my agent stack as cattle-like, potentially out of a bias towards that architecture broadly, as I find it's much easier to reason about when as much as possible is disposable/idempotent/eventually consistent. The durable execution point also assumed aspects of the agent scaffold ala prompts don't have to be turned over in deploy, or conversely, can't finish their tasks and then migrate incrementally, and while I might cynically raise an eyebrow at the focus on 25ms for sandbox calls given the dev loops I currently experience, I'd argue there are other ways to solve that problem in both an in or outside of container sandbox pattern.)
I'd even agree with their final point "Consistency is the part we haven't answered" but in a different angle than they intended, as to why my focus was on "how do you _constrain_ agent behavior" since that has been, in my experience, the biggest bottleneck to letting agents do more.