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.

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

[0] - https://www-cdn.anthropic.com/3edfc1a7f947aa81841cf88305cb51... (specifically section 5.5.2.4)

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.

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.

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

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.

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.

[0] https://en.wikipedia.org/wiki/Duverger%27s_law

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.

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.

BUT. And I say this with all respect, since I broadly find a lot of value in your comments: I strongly disagree to your assertion that remote "is less efficient."

My theory to what is happening is that there are existing methodologies people are used to working in, including 'hacks' to build consensus that were developed in an in-person environment. (Namely, pulling a bunch of people into a room and arguing it out.) My perspective is that remote work makes a bunch of things that are just as critical in-person (shared documentation, good communication channels, trust and rapport, etc etc) non-optional, and your previous hacks far less effective. But I don't see this as a bad thing. If anything, it's like a strongly typed language: It forces you into a more effective pathway. (For instance, imagine how remote folks or even folks-just-not-around-at-the-moment felt in not being able to participate evenly in the "in-person-bash-it-out" sessions or hallway chats without a strong culture of proliferating knowledge and documentation?)

While you may reasonably say "Ok, that's fine, people built up methodologies, why flip it on its head and disrupt a status quo that works" to which I'd emphasize the "we were relying on suboptimal ways to build consensus, and it was a local maxima." I would also propose that I believe a good manager _HAS_ to change their methodologies in some ways more disruptively than just the local/remote shift when dealing with certain styles of employee, (their own) manager, and org+busines structure/process/incentives, and as such, this should just be part and parcel with the constant process of adapting to refine your own methods and style.

(As an aside, I was tempted to make this comment on your upstream comment[0] talking about "maybe I'm not actually succeeding, it feels like winning at a fucked up system" since I definitely feel you there. I got into management in large part out of a "I'm frustrated by how management is often done and how it ends up percolating down to ICs, and I want to put my money where my mouth is that there's a better approach", and while I definitely feel like I've succeeded in some respects, and continue to get "rewarded" as you say, I'm intimately aware that I'm likely still screwing things up/finding the optimal way to balance pathological incentives, and still have a ton to learn. In short, I'd not be surprised if both of us are "doing fine but still have blind spots," so please take my above just as one person's opinions/"attempt to draw the elephant" :) )

[0] https://news.ycombinator.com/item?id=38984369

When I started reading I was getting very ready to disagree vehemently ("remote work is overhyped and only works for a tiny sliver of the workforce")

But your last paragraph seems to describe far more what I've seen in reality; that it's often risk-aversion/not-wanting-to-commit-to-change/leaning-on-what-they-know/wanting-to-look-like-they're-doing-something that I've seen driving RTO in various locations. This hypothesis is supported by, as you point out, the increasing, albeit incrementally, list of companies and teams that have implemented remote successfully (my own included, obviously only speaking for myself/not for my employer).

So, to be clear, I don't think you're wrong that there's intentional focus on communication and collaboration that is _absolutely_ needed to make remote work, and that's harder for someone who doesn't know what that looks like (or for someone junior without experience working in that modality).

HOWEVER I would object to is the assertion that it's "overhyped and only works for a tiny sliver of the workforce."

Since starting to lead remote teams ~5 years back (after having been a dev on one for a few years prior) the delta between remote vs. in-person has been a _negligible_ friction point vs. much more "typical" aspects of management: Individual work habits, motivations, life externalities, team and org dynamic, "standard" disagreement or conflict, etc.

I'd be lying if I said the remote aspect was zero cost, but not only was much of it recouped in building better processes as you may have suggested above, but this enabled both hiring some amazing folks who likely wouldn't have been options if we only looked local, and supporting all of our lives with significantly increased flexibility, both in terms of personal life and in things like time-zone based coverage for outages and on-call. All-in-all, a massive benefit.

First, let me say that I don't disagree, pragmatically, with the truth of what you're saying, in terms of increasing your odds on the whole as a candidate.

But that said, as another hiring manager, let me respectfully disagree with this as a strong hiring signal. I say this, to boot, as an engineer with an, in my experience, above average OSS contribution, research, and patent portfolio, although these things are a bit power-law-esque so obviously I'm nothing next to many.

When I interview, I want to know you have a track record of high quality delivery, and are good for the skills you attest to. I can understand some folks looking at the public displays as a proxy to that, but I'd argue, at that point, indexing on the "public" part is orthogonal to what we're looking for it to display, and carries both false positives and negatives.

To some degree we may be agreeing loudly here, where you'd say "well that's what them putting it in public is" but I'd worry that by caring about the public component vs. a more generalized examination of professionalism and accomplishment, we preclude folks who have no time or interest in curating that sort of profile.

If I put myself into the absolute edge case of two candidates all things being equal but one seems to have also made a more visible portfolio of work, MAYBE, MAYBE that would move the needle in terms of establishing a degree of external validation, but I think I'd be looking _hard_ for other aspects to differentiate that would seem to have more direct applicability to our day-to-day needs, and am hard pressed to think of a time in the last few hundred interviews I've had to make such a choice without a stronger differentiator for any candidate above a very junior level.

Build this doc repo as well as the TODO component within it for absolutely minimal mental overhead. In fact, optimize for minimal mental overhead in all things, and ability to reenter/pick up where you left off effectively "on autopilot." This (low mental overhead, reentrency) applies to things like email triage as well.

I realize this is both very terse and very open ended, but it's really the crux of my ability to deal with exponential levels of randomization, complexity, and parallel tasks. If there's any "Secret sauce" this doesn't contain, it's the need to adjust your systems/organization/methods to whatever is "natural" for you (this perhaps goes hand in hand with low mental overhead and reentrency, even the process must be low-overhead and easily 'reentrent', for instance, preparing for forgetting where I put something, I should know my own tendencies for where I'd look such that I buid my organization upfront that I'd readily find it again.)

I'll cap this with one more meta item before I turn this into an essay: Retrospect. regularly ask yourself "how are things? how is what I'm doing? can it be improved? has anything gone wrong/should I be paying attention to anything I'm not? are there any questions I'm not asking?"

> Imagine being an IC software developer and being stuck on dial up. That’s what it’s like to be a manager in a remote environment.

This is hyperbolic. I would also suggest it takes some autonomy and responsibility away from managers to adapt and learn new ways for building an understanding of your engineers. If adapting to remote is problematic, adapting to employees with dramatically different methods of thinking and communication (of which there are many) will also be problematic.

Are there challenges? Sure. From my perspective, the largest among them likely being the loss of organic opportunities to casually interact and build rapport, such as over lunch. The second worth mentioning is the friction added to nonverbal communication. (Onboarding is one of the most critical places these hit, but they're ongoing headwinds as well.) But neither of these are in any way insurmountable, or even high on the list of "things that keep me up at night" managing a team. At the risk of a simple answer, I've found they're usually well addressed by intentionally making opportunities to just... interact, and of course finding what works for an individual dev, with a team-wide emphasis on async methods of alignment, knowledge sharing, and consistency/coordination.

None of the things you mentioned, what a dev is doing, what they want and need, should have in-person as a requirement. The statement of "more intrusive" is especially ironic, as I find knocking on an office door and interrupting flow, or bugging someone in the hallway or over lunch "what's the status of X" far more intrusive than having a good process and cadence and ongoing awareness for work being done, and trusting/cultivating engineers to reach out if something comes up. (These are systems which, to emphasize my point, come very naturally when one is supporting a remote or hybrid team, but have broad benefit.) I'd add as well that "is someone smiling" is an... extremely lossy and unreliable heuristic for knowing your engineer, to put it more gently than I probably should.

The funny part with all this said: Your core point, that managers are contributing to the RTO push, potentially has some truth to it. (although I'm inclined to disagree that it's THE major component just knowing the discussions and tax implications between legislators/business owners/bigcos in my own city, it's totally a guess on my part) I've just been reading a bunch of posts lately that seem to defend what is, in my eyes, a cop-out for a manager who should be adapting to far more than remote on a day-by-day basis, resulting in concrete costs both for employees in location/commute and for managers in being unable to hire high quality remote engineers, and this being said so overtly pushed me to write this wall-of-text.

Even within a single site, there were often errors at the fringes, especially if things like layout/styling changed, and my concern about giving bad data to users (or needing to constantly be checking data quality and adjusting custom parameters for each target site) held me back from ever feeling confident enough to convert it into a paid product.

I don't mean for you to give up your secret sauce here, but wondering if you ran into this same issue, and what your approach was from a business/customer expectations perspective?