Been beekeeping for a couple decades now, and during that short time period I've watched first hand what we're up against to save polinators and insects in general in the coming decades. Overuse of pesticides, a massive decline in foragable land, the unchecked introduction of various predators and associated pathogens from global trade and a warming planet are just a few that come to mind.
I tend to agree that the news cycles put too great a focus on honeybees in particular when discussing the decline of pollinators worldwide. However, I understand why the focus is there; they're an easy to point to example that the average person is familiar with, doubly so since most folks use honeybee byproducts regularly.
That said, insect populations are declining at a staggering 1-2% year over year rate. 40% of all insect species are endangered. Rates are declining significantly higher in both North America and Europe, concentrated near agricultual centers. There is some truth in honeybees outcompeting native species for increasingly scarce resources, but putting our blame on the honeybee is missing the forest for the trees.
Another effect observed with LED street lights, especially in my area, is that many have shifted from white light to purple as a widespread manufacturing flaw causes their phosphor coating to fail.
The purple lights evoke a vaporwave/synthwave aesthetic like I'm in a bad 80s scifi movie. Unintentionally appropriate given the general state of things.
LLM systems at their core being probabilistic text generators makes them easily produce massive works at scale.
In software engineering our job is to build reliable systems that scale to meet the needs of our customers.
With the advent of LLMs for generating software, we're simply ignoring many existing tenets of software engineering by assuming greater and greater risk for the hope of some reward of "moving faster" without setting up the proper guard rails we've always had. If a human sends me a PR that has many changes scattered across several concerns, that's an instant rejection to close that PR and tell them to separate those into multiple PRs so it doesn't burn us out reviewing something beyond human comprehension limits. We should be rejecting these risky changes out of hand, with the possible exception when "starting from scratch", but even then I'd suggest a disciplined approach with multiple validation steps and phases.
The hype is snake oil: saying we can and should one-shot everything into existence without human validation, is pure fantasy. This careless use of GenAI is simply a recipe for disasters at scales we've not seen before.
100% this. With these new tools it's tempting to one-shot massive changesets crossing multiple concerns in preexisting, stable codebases.
The key is to keep any changes to code small enough to fit in your own "context window." Exceed that at your own risk. Constantly exceeding your capacity for understanding the changes being made leads to either burnout or indifference to the fires you're inevitably starting.
Be proactive with these tools w.r.t. risk mitigation, not reactive. Don't yolo out unverified shit at scales beyond basic human comprehension limits. Sure, you can now randomly generate entirely (unverified) new software into being, but 95% of the time that's a really, really bad idea. It is just gambling and likely some part of our lizard brains finds it enticing, but in order to prevent the slopification of everything, we need to apply some basic fucking discipline.
As you point out, it's our responsibility as human engineers to manage the risk reward tradeoffs with the output of these new tools. Anecdotally, I can tell you, we're doing a fucking bad job of it rn.
The article touches on this but I think the key takeaway is that humans need to properly manage the _scope of work_ for their agentic teams in order to have any chance of a successful outcome.
Current gen agents need to be provided with small, actionable units of work that can _easily_ be reviewed by a human. A code deliverable is made easy to review if the scope of change is small and aligned with a specific feature or task, not sprawled across multiple concerns. The changes must be ONLY related to the task at hand. If a PR is generated that does two very different things like fix linting errors in preexisting code AND implement feature X, you're doing it wrong. Or rather, you're simply gambling. I'd rather not leave things up to chance that I may miss something in that new 10000LOC PR. It's better that a 10000LOC never existed at all.
YOLOing out massive, sweeping changes with agents exceed our own (human) "context windows" and as this article points out, we're then left with an inevitable "mess." The untangling of which will take an inordinate amount of time to fix.
At which point you've gained very little efficiency in most large organizations given that by the time you're actually doing development work at the ticket level 90% of the project timeline (identifying issues, prioritizing, creating requirements, architecture, ticket breakdowns, coordination, etc) has already passed.
If AI can enable engineers to move through the organization more effectively, say by allowing them to work through the service mesh as a whole, that could reduce time. But in order to evaluate code contributions to any space well, as far as I can tell, you still have to put in leg work even if you are an experienced engineer and write some features which exposes you to the libraries, quirks, logging/monitoring, language, etc that make up that specific codebase. (And also to build trust with the people who own that codebase and will be gatekeeping your changes, unless you prefer the Amazon method of having junior engineers YOLO changes onto production codebases without review apparently... holy moly, how did they get to that point in the first place...)
So the gains seem marginal at best in large organizations. I've seen some small organizations move quicker with it, they have less overhead, less complexity, and smaller tasks. Although I've yet to see much besides very small projects/POCs/MVPs from anyone non-technical.
Maybe it'll get to the point where it can handle more complexity, I kind of think we're leveling off on this particular phase of AI, and some headlines seem to confirm that...
- MS starting to make CoPilot a bit less prominent in its products and marketing
- Sora shutting down
- Lots of murky, weird, circular deals to fund a money pit with no profits
- Observations at work
It's really kind of crazy how much our entire society can be hijacked by these hype machines. My company did slow roll AI deployment a bit, but it very much feels like the Wild West, and the amount of money spent! I'm sure it's astronomical. Pretty sure we could have hired contractors to create the Chrome plugin and Kafka topic dashboard we've deployed for far cheaper
The productivity gains are somewhat real in a sense, but are not really about "moving faster", as the hype would have us believe. GenAI agentic systems instead boost individual developer "efficiency" by allowing a single, reasonably qualified developer, to approximate an entire software team. As those developers, however, we're still required to manage the workload of those teams and ourselves to ensure quality output, just as ever before.
The problem is that it's VERY easy to overload oneself with the output of these new tools. Human comprehension is the bottleneck, as much as it always has been. Anyone that tells you otherwise is shilling for these companies.
And just to underscore my point about the disconnect between the advertising/hype vs the reality: the real point of this tech and the reason leadership seems so motivated to push it is that they ultimately see this tooling as our replacement, not our enhancement, at least in the long term (although those "many hats" roles will have to persist).
It's just harder to sell trades folk the tools of their demise, so it's couched in terms of a miracle product that'll make us all 10x devs; when the reality is, it'll just be 1/10 of us still around doing the risk mitigation work left within the system that relaced us.
No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.
I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.
ctrl-z pauses the process, it doesn't terminate. I think of z as in zombie as you can then run fg to bring it back from paused state or as you suggested kill in it for good
With the models I've been working with lately, providing them with small, actionable units of work that can easily fit within their context window (before compaction) seems to work well. If you can hit that sweet spot, you can get excellent output.
I don't tell the agents to "just go do it", as that tends to go off the rails for complex tasks. Emulating real world software development processes in meat space with your AI "team" seems to approximate similar outcomes.
I usually start by having the agents construct a plan document which I iterate on and build up well before writing code. This is a living document, not a final design (yet.) If I run into context window issues I just shut them down and rebuild from the document. I farm out research and data gathering tasks to build it up. Once all the findings are in I have the architect take a stab at the technical system design before the break down and delegation work begins. By then the units of work are small and manageable.
From my vantage point AI consumption is being lead by tech leadership moreso than actual in-the-weeds programmers themselves. HN just happens to include more folk at the intersection of leadership and individual code contributor.
The top down push for AI is in line with the age old traditions of replacing highly skilled and highly compensated trade workers with automation. The writing is on the wall if folks care to look; many just don't want to. This has happened 1000 times before and it'll keep happening in the name of "progress" in capitalist systems for as long as there are "inefficiencies" to "resolve." AI is meant as our replacement, not as an extension of our skill as it happens to align with today.
Its increasingly obvious that the next phase in the evolution of the average programmer role will be as technical requirements writers and machine generated output validators, leaving the actual implementation outsourced to the machine. Even in that new role, there is no secret sauce protecting this "programmer" from further automation. Technical product managers eventually fall to automation given enough time and money poured into the automation of translating fuzzy, under specified ideas into concrete bulleted requirements where they can simply review the listed output, make minor tweaks and hit "send" to generate the list of jira-like units of work to farm out to a fleet of agents wearing various hats (architect, programming, validator, etc.)
The above is very much in progress already, and today I'm already spending the majority of my time reviewing the output of said AI "teams", and let me tell you: it gets closer and closer to "good enough" week by week. Last year's models are horse shit in comparison to what I'm using today with agentic teams of the latest frontier models (Opus 4.6 [1m] currently, with some Sonnet.)
Maybe we're at a plateau and the limitations inherent in GenAI tech will be insurmountable before we get to 100% replacement. But it literally won't matter in the end as "good enough" always prevails over the perfect, and human devs are far from perfect already.
I have been producing software (at fang scale) for several decades now, and I've been closely monitoring GenAI systems for coding specifically. Even just a few months ago I'd get a verbose, meandering sprawl of methods and logic scattered with the actual deliverables outlined in the prompt from these systems. Sometimes even with clear disregard of the requirements laid out, or "cheating" on validation via disabling tests or writing ones that don't actually do anything useful. Today I'm getting none of that. I don't know what changed, but I somehow get automated code with good separation of concerns, following best practices and proven architectural patterns. Sure, with a bunch of juniors let loose with AI you get garbage still, but that's simply a function of poor delegation of work units. Giving the individual developer and the AI too much leeway in the scope of changes is the bug there. Division of work into small enough units is the key and always has been for the de-skilling portion of automating away skilled human labor for machines. We're just watching Marxist theory on capitalist systems play out in real time in a field generally thought to be "safe." It certainly won't be the last.
Pretty bare bones setup: Claude Agent Teams with some wrappers to leverage our bedrock hosted models. Opus 4.6 [1m] as orchestrator, architect and reviewer, Sonnet 4.6 [1m] for investigation, data gathering and coding depending on task scope.
Recently one of my friends got email hijacked and whatever entity it was seemingly used her past sent emails as a training corpus to construct some very convincing pleas for donations involving a dog rescue she's been operating for several years.
It also included personal details only her closest friends and family would know. I assume this is being done at scale now. These are NOT Nigerian prince scams of yesteryear; this is something entirely different.
I tend to agree that the news cycles put too great a focus on honeybees in particular when discussing the decline of pollinators worldwide. However, I understand why the focus is there; they're an easy to point to example that the average person is familiar with, doubly so since most folks use honeybee byproducts regularly.
That said, insect populations are declining at a staggering 1-2% year over year rate. 40% of all insect species are endangered. Rates are declining significantly higher in both North America and Europe, concentrated near agricultual centers. There is some truth in honeybees outcompeting native species for increasingly scarce resources, but putting our blame on the honeybee is missing the forest for the trees.
reply