isnt the 1RM the measure of progress?

If that's what you're training for, sure. If you just want to be strong, you can achieve that and avoid the highest injury risk by sticking with 5 reps or so.

anywhere you want hard isolation and only a subset of OS. especially multiple instances thereof.

so, generally at the edge (gateways, shims, protocol boundaries)

container can be smaller at rest, but larger at runtime

if you're not sure which you want its probably container

one reason i can imagine for this choice is that human review distributes new knowledge among human maintainers. Automated review might discourage that valuable interaction.

The comment is an artefact of an inherently valuable process, not the sole objective. So I'd prefer code is reviewed by a human who maybe initiates a discussion with an agent. I'd hope this minor workflow detail encourages the human to take a more active lead, rather than risk mere ceremonial approval.

I think it's mistaken to think in terms of 'falling behind' or 'catching up'

I've seen that these tools have different uses for different devs. I know on my current team, each of us devs works very differently to one another, and we make significant allowances to accommodate for one another's different styles. Certain tasks always go to certain devs; one dev is like a steel trap, another is the chaos explorer, another's a beginner, another has great big-picture perspective, etc. (not sure why but there's even space for myself ;)

In the same way, different devs use these powerful tools in very different ways. So don't imagine you're falling behind, because the only useful benchmark is yourself. And don't imagine you can wait for consensus: you'll still need to identify your personal relationship to the tools.

Most of all, don't be discouraged. Even if you never embrace these tools, there will remain space for your skills and your style of approaching our shared work.

Give it another 10 years and I'm sure this will all become clearer...

I’ve become comfortable with using LLMs as “trusted advisors.”

I am not [yet] ready to just let an agent write a whole app or server for me, but I am increasingly letting them write a whole function for me.

They are also great “bug finders.” I can just feed some code, describe the symptoms, and ask for an observation. I often get great suggestions, including things like finding typos and copy/pasta problems.

I find that just this limited application has significantly increased my development velocity, and, I believe, the quality of my work.

IMO LLMs make for a great rubber duck https://en.wikipedia.org/wiki/Rubber_duck_debugging

it is MUCH easier for solo devs to get agents to work for them than it is for teams to get agents to work for them.

that's interesting, whats the reason for that?

Hi, the reason I have this expectation is that on a (cognitively) diverse team there will be a range of reactions that all need to be accommodated.

some (many?) devs don't want agents. Either because the agent takes away the 'fun' part of their work, or because they don't trust the agent, or because they truly do not find a use for it in their process.

I remember being on teams which only remained functional because two devs tried very hard to stay out of one another's way. Nothing wrong with either of them, their approach to the work was just not very compatible.

In the same way, I expect diverse teams to struggle with finding a mode of adoption that does not negatively impact on the existing styles of some members.

thanks for the reply, thats interesting

i was thinking it was more like llms when used personally can make huge refactorings and code changes that you review yourself and just check it in, but with a team its harder to make sweeping changes that an llm might make more possible cause now everyone's changes start to conflict... but i guess thats not much of an issue in practice?

oh yeah well that's an extreme example of how one dev's use could overwhelm a team's capacity.

I've shed more tears in the past two weeks than I have in my 40 years of adult life.

forget: there I go again.

kindness beats terror.

I too am an aussie swe (just 3700km up the road) who likes lots of things about working (on a much lower rung) in big (well, mid) tech. I have learned so much more in large orgs than startups, and I'm not done with it.

However:

We DO live in a late-stage-capitalist hellscape.

Large companies ARE run by aspiring robber barons who have no serious convictions beyond desiring power.

I have compromised my principles by giving them (or anyone) my labor.

but I don't lie to myself or anyone else about it. I don't find any need to rehabilitate the structural and personal failings I encounter. When my friends call me out for working at EvilCorp, I don't argue. I know it's like any job: it's all dirty money. Instead, I deal with reality: weigh up pros and cons. I judge each year just how much Corporate I'm willing to swallow to support my dependents.

I enjoy the author's redefinition of cynicism and optimism. These are useful ideas to consider and I've given it some thought, arriving at an attitude of Becoming that I guess some would call idealism.

PS OMFG I just realised its MS. I believe this is what the kids call cringe.

"Fortunately, I’m not that smart." - love that attitude.

multi-agent collaboration on planning is definitely really valuable. I lean in to gemini's long context and have it set up as a long-term observer who I consult about overall direction, project philosophy, patterns in fail and success, and prioritisation. This gives a different perspective from which to assess other agents' plans.

Very true, Claude also tend to struggle around the context window limit and after compact