existencebox

I expect there's a probabilistic factor to it, among other things.

I use the almost the same addendum as you ("do not make, commit, or push any changes without my approval") and it broadly seems to work in my day-to-day dev. However, I also set up some agents that trigger on incoming requests from my dev teams to automate things that used to be rote/manual tasks. _That_ is where I see the issues, I suspect simply because it has so many more opportunities to go off script.

The most common failure mode is that it will, despite all directives to not make changes without approval, start writing unit tests. (I do find this equal parts head-shaking and amusing; At least it chooses something relatively 'benevolent' vs. the aforementioned skynet.)

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.

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.

Chiming in with a slightly different perspective: I often bookmark things I see in passing that might not be useful now but may in the future based on things I know I want to do.

Case studies in certain engineering/programming tasks, something I read that I found useful and want to have handy to share with others in the future, project ideas or notes for long-running efforts I pursue and sometimes want a "bucket to pull from" for instance.

While it's certainly true that I probably _use_ 10-20% of what I bookmark, I don't think it would be possible to realize the same positive outcomes without the 80% that I don't. (Just last week I was able to braindump a large piles of 'examples/essays I found helpful learning about neural network optimization' to one of my engineers because I'd kept them handy after they helped me.)

I should say though, I sense this is a slightly different use case than the "I want to read this article just to read it" bookmarks where I know I never will, which is certainly something I've experienced but is a minority case in my life nowadays, so I wanted to vouch for productive scenarios too.

I take a very mechanical view on this, but take this with a grain of salt as my success has been "banal" at best. You have people paying you for your product. This is more fit than most people achieve.

Some good advice I heard is to find and focus on a KPI that aligns with the sort of use that'd indicate healthy consumption of your product+costs, with a guiding principle of "if people are paying us and using it with a trendline moving the right direction, we're succeeding."

Have you thought about what you'd need to do to get more users/get more eyes? (Presuming you've proven enough traction+lack of churn from existing users that it wouldn't be premature) Similarly, are you talking to users who find value in your product and identifying ways you could provide more value?

I personally see tons of potential avenues for growth given what you've said; but obviously saying this ignorant of much of the reality on the ground so take it with a major grain of salt.

This is a bit orthogonal to the broader conversation, but you've hooked me with your predicament: Can you allow for preorders or "Expressed interest" at a new price point? (or at a hand-wavy price point to assess interest re: overhead/bulk/etc.) If tariffs come down, you can refund/credit, but for customers who wanted this, something-at-some-price may be better than nothing-at-any-price.

I'm going to disagree with this as a long-term ARPG fan and a long-since-washed-up game dev.

Up through the last few years, I was playing Path of Exile rather regularly. The grind in that game puts what we used to do in D2 to shame, to me at least.

(Comparing the amount of time I used to spend baal/cow/key/pindle running to gear a character sufficiently for e.g. ubers vs. what I'd consider equiv endgame bosses in POE from tree-boosted maven/Sirus/ubers/etc, outside of explicitly low-gear bossers like trapping)

I also regularly wish I could go _Back_ to playing it, specifically 1.13-1.15 (harvest) as it was, in my opinion, the peak of ARPG gameplay, as it turned progression from pure RNG where a wrong roll would brick an item or where you had to rely on the market to find your gear into something slightly less punishing where we could experiment with a far wider variety of builds. But the powers that be in POE saw it differently, that it watered down the endgame and made progression too easy, and proceeded to remove the vast bulk of the mechanic, while doubling down on other mechanics that were, frankly, not respectful of anyone's time. (e.g. scourge.)

This to say, I think game incentives have changed over the last few decades. Something subtle, motivated by microtransactions, subscriptions and streamers, has changed the nature of grind from primarily something that needs to be kept fun to make the game meaty enough to play, to something that must sufficiently extend gameplay to keep the microtransaction faucet going and keep certain goals effectively out of reach.