Coder Legion - Recent posts tagged futureofai

Flip One Field: A Fairness Test That Beats Aggregate Parity

Wed, 21 Oct 2026 21:04:43 +0000

Most teams check an LLM-assisted decision system for fairness by comparing approval rates across groups. That check can pass cleanly while the model is still changing its mind on individual cases for reasons nobody would defend out loud. Recent fairness-stress work on LLM decision-making points at a better default test - and it's a decision you can make before writing any code.

Aggregate Parity Nets Out; Per-Case Instability Doesn't

The choice is between two measurements. Outcome parity asks: across 1,000 applications, did group A get approved at roughly the same rate as group B? Counterfactual stress asks something narrower and harder: for this one application, if I change only a decision-irrelevant field - the name, the phrasing of the same request, the order of the bullet points - does the answer move?

A model that favors one group on early-career cases and another on senior cases can show perfect parity overall. Parity is cheap and it's what regulators often ask for, but it averages. Per-case stress testing catches that, because it never aggregates across people - it compares a case to itself.

The trade-off is real. Stress testing costs N× the inference calls, and it requires someone to declare which fields are decision-irrelevant. That list is a policy judgment, not an engineering one, which is exactly why a PM should define it.

Running the Test on One Application

base = {"years_exp": 6, "skills": "python, sql"}
names = ["Alex Chen", "Aisha Khan", "John Smith", "Priya Patel"]

votes = [decide(tmpl, {**base, "name": n})
 for n in names
 for tmpl in PROMPT_TEMPLATES] # 3 paraphrases, same instruction

flip_rate = 1 - max(votes.count(v) for v in set(votes)) / len(votes)

Twelve variants of one application that a human reviewer would call identical. Any flip_rate above zero means the decision moved on something that shouldn't matter.

The number alone isn't the point - the pattern is. Read the flips two ways:

Clustered - all rejections land on the same name group across all three paraphrases. That's bias. Fix it in the prompt, the retrieval data, or the model choice.
Scattered - flips appear randomly across names and templates. That's instability. Lower the temperature, constrain the output format, or stop auto-deciding borderline cases.

Both fail the same test and need different fixes, which is why one aggregate percentage can't tell you what to do next. Report worst-case flip rate per application, not the mean - the mean hides the cases that would end up in a complaint.

Key Takeaways

Group-level parity can look clean while individual decisions flip on irrelevant details; counterfactual stress testing compares each case against itself and catches what averages hide.
Separate clustered flips (bias - fix prompt, data, or model) from scattered flips (instability - fix sampling, output constraints, or add human review).
The hard part isn't the code, it's agreeing on which input fields are decision-irrelevant. That list belongs to product and policy, not just engineering.

Which fields in your decision prompt would your team actually agree are irrelevant - and how long would that meeting take?

Sources referenced: FairStress: A deeper evaluation of fairness in LLM decision-making, Hugging Face Blog

Why Does Using AI More Leave Us So Exhausted?

Mon, 21 Sep 2026 13:40:13 +0000

The output is faster. So why does the work feel worse?

Alec Scollon describes a way of working with AI that, by current developer standards, is not especially exotic. He works on one task at a time, discusses it with Claude Code at work or Codex at home, reads the generated code carefully, tries to understand it, and revises it when necessary. In his own words, his usage is probably average and his methods “primitive.” He is not deep into autonomous-agent orchestration. He simply spends hours each day reading model-generated text, which is already a fairly radical change from how he worked only a few years ago. [1]

On July 8, 2026, Scollon published I Think I Have LLM Burnout. The essay reached the front page of Hacker News and drew more than 400 points and hundreds of comments. [1][2] What travelled through the developer community was not a dramatic claim that AI had ruined programming. His complaint was smaller, and probably more recognizable because of it: after spending so much time inside model output, he had started to dread reading it.

He still thought LLMs made him more productive. He did not pretend that human engineers are reliable by comparison; humans make false assumptions, write bad code and irritate one another perfectly well without machine assistance. What seemed to be wearing him down was the recurrence. The same stylistic tics kept resurfacing, along with the same kinds of misplaced confidence and familiar mistakes.

His job, as he described it, had changed from designing and writing code into something more layered: design the code, explain that design to the model, review what comes back, then write or repair whatever remains. The change sounds modest when reduced to a workflow diagram. After several hours a day, every day, for roughly a year, it no longer felt modest to him. [1]

“I don’t know how to deal with this feeling yet,” he wrote. The uncertainty is probably more useful than trying to diagnose him from the outside.

AI inside a system that was already overloaded

Eric Ma wrote about a different experience a few months earlier. His circumstances were untidier and, importantly, he did not retrospectively force them into a clean causal story. Work was already overloaded. Meetings could be triple- or quadruple-booked, operational and personnel problems were active at the same time, and several unrelated categories of work had to remain mentally open. He later wrote that he still could not identify one exact cause for the stress he experienced. [3]

AI was nevertheless part of the environment. During the first quarter of 2026, Ma had gone heavily into coding agents. He could test ideas rapidly and reshape large parts of codebases with a speed that would previously have required considerably more time.

He found that pace stimulating, and also disorienting. In his account, the compression of time created by AI-assisted coding became entangled with questions about how durable the work was and how much of the pace could actually be sustained.

His essay, How I Recognized and Handled AI Burnout, is useful because it refuses the easiest explanation. AI entered an environment in which the load was already too high, making it difficult to separate the technology from the organizational conditions surrounding it. [3]

What changes when AI makes work faster?

Scollon called his experience LLM burnout, and Ma also wrote about AI burnout. But those two stories do not by themselves show that AI has created a new form of burnout. What they do show is that AI can change the pace and shape of an already demanding workday.

The most obvious change is speed. A developer can generate code in seconds, but someone still has to read and test it. A researcher can produce a summary almost instantly, but the claims and sources still need verification. A manager can create several drafts in the time it once took to write one, but someone still has to decide which one is actually usable.

AI can reduce the time needed to produce work without reducing the time needed to judge it.

That difference becomes more important as output grows. If five versions can now be produced where there used to be one, there may also be five versions to compare, reject or correct. And the extra work does not necessarily stay with the person who benefited from the faster production.

A developer may generate a pull request in minutes while a colleague spends much longer reviewing it. A report may be drafted quickly while someone else later has to verify its sources. Some of the time saved at one point in the workflow can reappear as work somewhere else.

This brings the discussion back to burnout as we already understand it. The World Health Organization describes burnout as an occupational phenomenon resulting from chronic workplace stress that has not been successfully managed, associated with exhaustion, growing mental distance or cynicism toward work, and reduced professional effectiveness. [4]

We do not yet have evidence that “AI burnout” is a separate condition. But we do have a clearer question to investigate: if AI allows more work to be produced, reviewed and decided on within the same working day, does that added density contribute to the chronic workplace stress we already know can lead to burnout?

Productivity rises, and the workload does not politely disappear

The intuitive promise of faster production is simple: if AI helps people finish work sooner, the workday should become lighter.

The reality is rarely that neat.

A 2025 survey by the Upwork Research Institute of 2,500 professionals makes the tension hard to miss. Workers using AI reported an average productivity increase of 40 percent. Yet among those reporting the highest gains, 88 percent also reported burnout. They were roughly twice as likely to consider quitting, and 62 percent said they did not understand how their daily AI use connected to their organization’s broader goals. [5]

Those numbers do not prove that AI caused the burnout. The survey was self-reported, and people already under pressure may have adopted AI more aggressively or simply been given more work once their output increased. But the pattern itself is difficult to ignore: feeling much more productive does not translate into feeling less exhausted.

A 2026 tech-worker sentiment survey showed a similar split. In How Tech Workers Are Feeling in 2026, 82 percent of respondents said AI made them better at their jobs, while significant burnout rose from 44.7 percent to 55.7 percent year over year. [6] Their concerns were practical rather than abstract. Workers worried about being expected to do more for the same pay, maintaining an unsustainable pace, and watching quality deteriorate as output increased.

This points to an organizational habit that existed long before AI but becomes easier to amplify with it: freed capacity attracts more work.

If a task that once took an hour now takes twenty minutes, the remaining forty minutes rarely become recovery time. They become available capacity. Once that happens repeatedly, yesterday’s exceptional throughput can quietly become today’s expected baseline.

Productivity rises, but the experience of work gets worse

As that baseline rises, the question is what happens to the day-to-day experience of doing the work.

Productivity metrics are good at showing how much gets finished. They are much worse at showing how much attention is required to keep that faster output understandable, correct, and usable. A workflow can become faster without necessarily becoming easier to live inside.

In a longitudinal study at the University of Auckland, Annie Vella and Kelly Blincoe tracked professional software engineers across two surveys six months apart. At both checkpoints, 84 percent said AI coding assistants improved their productivity. [7]

Developer experience moved differently. Among the engineers who responded at both checkpoints, the share reporting deterioration in at least one dimension nearly doubled, from 14 percent to 27 percent. Vella and Blincoe call this the productivity–experience paradox. [7]

In plainer terms, the dashboard looks happier than the person doing the work.

The nature of the work was changing at the same time. Eighty-two percent reported spending less time writing code, while more effort shifted toward directing AI, evaluating what it returned, and correcting the output. Vella and Blincoe describe this as supervisory engineering work. [7]

A controlled study presented at CHI 2026 found a similar tension under experimental conditions. Sixty programmers completed Python tasks with and without AI assistance. AI reduced completion time by 22 percent, improved correctness, and even lowered conventional workload scores. [8]

Yet across repeated tasks, fatigue accumulated faster in the AI group. The researchers found that verification load—measured through things such as compile failures, code churn, pauses, and context switches—partially explained that increase. [8]

That result helps explain what the productivity numbers miss. Less time spent producing something does not necessarily mean less human effort overall. Some of that effort moves into reading, checking, comparing, correcting, and deciding whether the generated result can actually be trusted.

Traditional productivity accounting has trouble seeing that labor. A developer may spend less time typing code but far more time tracing why a generated test passed, comparing several plausible implementations, or repairing logic that looked correct at first glance.

Then all of that human effort gets compressed into two words: “used AI.”

The speed is visible. The attention spent making the result usable often is not.

And that may be the most recognizable part of the paradox: AI can work exactly as advertised—you finish more, and you finish it faster—while you still reach the end of the day wondering why you feel more tired than before.

The time saved by one person often becomes work for someone else

There is another part of this productivity gain that is easy to miss: the person who saves the time is not always the person who does the checking.

This dynamic shows up especially clearly in software teams. AI can help one developer produce a change very quickly, but before that change reaches users, someone else may still have to understand it, question it, test it, and decide whether it is safe to keep.

Sebastian Baltes, Marc Cheong and Christoph Treude found this pattern repeatedly in developer discussions about low-quality AI-generated code. They describe it as a tragedy of the commons. [9]

The author gets the productivity gain. The reviewer gets the uncertainty.

Or, to borrow an old idea and update it for AI: the lunch may be free for one person, but someone else still has to wash the dishes.

In one team described in the study, six reviewers were dealing with around thirty pull requests a day. The frustration was not simply that AI-generated code was wrong. Someone still had to determine whether it was wrong, where the problem was, and what could safely be accepted. [9]

Software makes this exchange unusually visible because review is an explicit part of the workflow. But the pattern itself is familiar outside engineering too. A report appears in minutes; someone still checks the claims. A presentation is drafted instantly; someone still decides whether the argument holds together.

AI can make creation dramatically faster without making judgment equally fast.

The work gets faster, but the human burden does not disappear

Once this kind of checking becomes part of almost every task, the cost stops looking dramatic. It just becomes part of the day.

A report appears in minutes, but you still read it line by line because one confident sentence feels slightly wrong. A presentation is finished before lunch, but you spend another hour deciding which claims are actually defensible. AI gives you three reasonable options, and instead of having no answer, you now have a different problem: choosing which answer you are willing to stand behind.

None of these moments feels large enough to call a crisis.

That is precisely why they are easy to miss.

The work arrives faster. The decisions do not.

Over a day, those small decisions accumulate: accept this, reject that, check the source, rewrite the paragraph, compare the alternatives, ask one more question, verify one more detail. AI may have done much of the producing, but the responsibility for deciding what is good enough to keep still belongs to a person.

This is what I mean by supervisory exhaustion.

Not a new diagnosis, but a name for something much more ordinary: the fatigue that builds when more and more of the working day is spent watching, checking, correcting, and taking responsibility for work that can now be produced almost instantly.

And this may explain the strange feeling running through this entire story.

AI works.

You get more done. Things move faster. The dashboard looks better.

And somehow, at the end of the day, you are still tired.

Maybe even more tired than before.

References

[1] Scollon, A. (2026). I Think I Have LLM Burnout. Personal essay, July 8, 2026.

[2] Hacker News. (2026). I think I have LLM burnout — discussion thread. More than 400 points and hundreds of comments.

[3] Ma, E. J. (2026). How I Recognized and Handled AI Burnout. Personal post-mortem, May 2, 2026.

[4] World Health Organization. (2019). Burn-out an “occupational phenomenon”: International Classification of Diseases.

[5] Upwork Research Institute. (2025). From Tools to Teammates: Navigating the New Human-AI Relationship. Global self-reported survey, n=2,500.

[6] Segal, N., & Rachitsky, L. (2026). How Tech Workers Are Feeling in 2026: A Workforce Splitting in Two. Technology-worker sentiment survey.

[7] Vella, A., & Blincoe, K. (2026). The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. Longitudinal study of professional software engineers.

[8] Fan, G., Liu, D., Pan, L., & Zhang, R. (2026). When Help Hurts: Verification Load and Fatigue with AI Coding Assistants. Proceedings of CHI 2026, Article 733. Controlled study, n=60.

[9] Baltes, S., Cheong, M., & Treude, C. (2026). “An Endless Stream of AI Slop”: How Developers Discuss the Burden of AI-Assisted Software Development. Qualitative analysis of 1,154 posts across 15 Reddit and Hacker News discussions.

US President Donald Trump Pushes Back Against Calls to Slow AI Development

Tue, 15 Sep 2026 03:19:21 +0000

Trump Pushes Back Against Calls to Slow AI Development

The debate over how quickly artificial intelligence should advance has taken another turn. After Anthropic CEO Dario Amodei called for a slower pace of frontier AI development, his position received support from OpenAI CEO Sam Altman and xAI leader Elon Musk. Now, U.S. President Donald Trump has offered a very different perspective. (Reuters)

Trump Dismisses Growing AI Concerns

Speaking to reporters at his golf resort in Ireland, Trump said that “very negative forces” are raising concerns about AI and promoting scenarios that he believes will not happen.

Rather than slowing down, Trump emphasized that the United States needs to maintain its leadership in artificial intelligence, particularly in competition with China. He argued that the country that leads in AI will have a major technological advantage. (Reuters)

A Different View From AI Industry Leaders

Trump’s comments come shortly after Dario Amodei argued that AI development should be deliberately paced so that safety measures and testing can keep up with rapidly improving capabilities.

Amodei has warned about increasingly autonomous AI agents and proposed stronger independent evaluations and other safeguards rather than stopping AI development altogether. Sam Altman and Elon Musk have both expressed support for his broader call to pace the development of frontier AI. ([Reuters][2])

AI Safety vs. Technological Competition

This creates an increasingly important debate: should AI development continue at maximum speed to preserve technological leadership, or should companies slow down enough to improve safety and oversight?

As discussed in our previous articles, concerns from Amodei, Altman and Musk have focused on managing the risks of increasingly powerful AI systems. Trump’s latest comments highlight the other side of the debate—the fear that slowing down could allow the United States to lose its lead in AI, particularly to China. ([AP News][3])

The discussion is therefore becoming bigger than the AI industry itself. It now involves AI safety, technological competition, national leadership and the future pace of artificial intelligence development.

#Trump #DonaldTrump #AI #ArtificialIntelligence #AIDevelopment #AISafety #FrontierAI #AIRegulation #AIInnovation #TechNews #Technology #FutureOfAI #AIrisks #AILeadership #USvsChina #ChinaAI #AICompetition #TechCompetition #DarioAmodei #SamAltman #ElonMusk #Anthropic #OpenAI #xAI #AIResearch #EmergingTechnology #TechPolicy #FutureTechnology #YasirAwan4831 #MuhammadYasir

Written by: Muhammad Yasir

Muhammad Yasir is a Full Stach Developer, tech and AI enthusiast who shares practical insights, tips and guides on the latest technology, AI tools, robotics, videos and engineering topics.

Explore the website: https://yasirawaninfo.vercel.app/

Loop Engineering: Why “Writing Loops” Is the New “Writing Code”

Fri, 04 Sep 2026 14:20:26 +0000

Prompt engineering is already sounding quaint. The people who build the coding agents have stopped prompting them. Here’s what “loop engineering” actually means, and the one loop nobody can automate.

There’s a quote from a few weeks ago that I keep turning over in my head.

Boris Cherny, the person who built Claude Code, said in an interview that he doesn’t really prompt Claude anymore. “I have loops running that prompt Claude,” he said. “My job is to write loops.”

Sit with that for a second, because it’s a small sentence with a large implication. The guy who built one of the most-used coding tools on the planet has quietly changed jobs, without changing jobs. He’s not writing prompts. He’s not even really writing code in the way we mean it. He’s building the little machine that tells the machine what to do, then watching it run.

Around the same time, an OpenAI engineer, Peter Steinberger, dropped his own version on X: stop prompting coding agents, start designing the loops that prompt them. Someone named it “loop engineering.” The internet, which needs a new discipline to panic about roughly every quarter, obliged. And then Andrew Ng wrote a genuinely useful letter about the three loops he actually uses to build products, which is the part worth slowing down for, because it’s the first version of this idea that isn’t just a vibe.

So let me do the thing I do: take the buzzphrase apart, keep the real bit, and tell you the part the hype is missing. Because there is a real bit. And there’s also a comforting lie buried in the excitement that I want to dig out.

First, what a “loop” even is here
Strip the mystique off and loop engineering is just an old idea wearing new sneakers. It’s control systems. It’s the thermostat. You set a target, the system acts, you measure the gap between where it is and where you wanted it, and you feed that gap back in. Do something, check it, adjust, repeat. Every engineer who’s ever built anything that self-corrects already knows this shape in their bones.

What changed is that, for the first time, the thing inside the loop, the part doing the acting, is a coding agent smart enough to run for an hour without you. That’s the unlock. Last year the agent wrote code and then sat there, tail wagging, waiting for you to tell it whether it worked. This year it writes the code, opens a browser, tests its own work, notices it broke something, fixes that, tests again, and only taps you on the shoulder when it’s genuinely stuck or genuinely done.

Ng’s example is perfectly mundane and exactly the point: over a weekend he had an agent build a typing app for his daughter, and it worked away for about an hour, checking itself in a browser repeatedly, before coming back to him. No hovering. No copy-pasting error messages. The loop closed itself.

The insight worth stealing isn’t “agents got better.” It’s that once your agent can check its own work, you stop being its babysitter and start being its director. And a director operates at a completely different altitude than a typist.

The three loops, and why the speeds matter
Here’s where Ng’s framing earns its keep, because he doesn’t talk about one loop. He talks about three, nested inside each other, each running at a wildly different tempo. Think of them like gears, or like orbits: a fast inner one, a slower middle one, and a slow outer one, all turning at once.

Screenshot 2026-09-04 at 7.48.01 PM.png

The inner loop is the agentic coding loop, and it runs in minutes. Write, build, test, repeat. This is the part that got automated over the last year, and it’s the part everyone’s tweeting about. It’s genuinely a game-changer, and it’s also, increasingly, not your job. The machine owns this gear now.

The middle loop is the developer feedback loop, running in tens of minutes to hours. This is you looking at what got built and deciding it’s wrong, not buggy-wrong, but wrong-wrong. The cat costumes should unlock differently. The login flow for a parent is clunky. The whole visual direction feels off. Last year, developers wasted this loop playing QA, hunting for bugs the agent should have caught. Now that the inner loop catches its own bugs, this middle loop gets freed up for the decisions that actually need a brain with taste.

The outer loop is the external feedback loop, and it grinds along in days to weeks. Real humans touch the thing. You ship to a few friends, run an A/B test, watch what actual users do versus what you smugly assumed they’d do. This is the slowest, most annoying, and most important gear, because it’s the only one connected to reality instead of your own opinion of reality.

Here’s the part I love, and the part the buzzphrase flattens: the loops feed each other. The outer loop reshapes your vision, which rewrites the spec, which redirects the inner loop. Reality flows inward, slowly. And speed flows outward, the fast loop producing the thing the slow loop gets to judge. It’s not three tricks. It’s one nested system with reality on the outside and raw execution on the inside.

The comforting lie in all this
Now the part I promised to dig out.

The hype version of loop engineering whispers something seductive: automate the loops and you’re done. Build the perfect harness, set it running, walk away, come back to a finished product. The dream is a closed loop, a machine that needs no human at all. Just add more agents.

That’s the lie. And Ng, to his credit, says so plainly, though he says it politely and I’ll say it bluntly.

The inner loop automates beautifully. The outer loops do not, and it’s not because the tech isn’t ready yet. It’s structural. The reason a human has to sit in the middle and outer loops is that the human knows things the agent doesn’t. You know who the user actually is. You know the office politics of the client. You know that your daughter loves cats and will abandon the app in four seconds if the costumes are lame. That knowledge isn’t in the training data and isn’t in the spec until you put it there.

Everyone calls this human contribution “taste.” I think that’s a flattering word for a boring truth: you simply have more context than the machine. And the moment you don’t, the loop can close without you.

I actually prefer Ng’s reframe here to the usual “AI can’t replace human creativity” cope, because it’s honest and it’s a little unsettling. It’s not that machines lack some magical human spark. It’s that, for now, you hold context the model can’t see. That’s a gap, not a soul. And gaps close. The parts of your judgment that are really just “I’ve seen this before” will get automated. The parts that are “I know this specific user in this specific world” will last longer. Knowing which of your instincts is which is suddenly a career skill.

The maker-checker trick that makes it all work
One under-hyped detail deserves a spotlight, because it’s the load-bearing wall of the whole thing.

The reason the inner loop can run unsupervised isn’t that the agent got smart enough to trust itself. It’s that the good setups don’t trust it to. The most consequential design choice in a real loop is splitting the agent that writes the code from the agent that checks it. A model grading its own homework is a soft touch, it’ll reason its way into believing its bug is a feature. So you put a second agent, with different instructions and no ego investment in the first one’s work, in the role of skeptic. Maker proposes. Checker disposes.

That’s it. That’s the trick that turns “an agent that writes code” into “an agent that writes code you can leave alone for an hour.” Not a bigger model. A second, adversarial one. If you’ve ever shipped better work because a ruthless colleague reviewed it than because you reviewed it yourself, you already understand why this works and why “just trust the AI” was never going to.

So what does this mean for you, actually
If you write software, the shift is already underway and it’s mostly good news, with one catch.

The good news: you get promoted whether you like it or not. When the inner loop runs itself, your time moves up to the middle and outer loops, which is to say you become part product manager, part director, part the-person-who-decides-what’s-even-worth-building. Ng’s quiet prediction is that engineers are growing into product roles the same way PMs and designers backed into doing more engineering. The org chart is blurring, and the people who thrive will be the ones comfortable zooming between “why does this feature exist” and “why is this test flaky” in the same afternoon.

The catch: writing loops is a genuinely different skill than writing code, and it’s closer to systems design than to typing. You’re no longer solving the problem. You’re designing the system that solves the problem, then designing the checks that catch it when it solves the wrong problem confidently. That’s a harder, more abstract job than most “AI will make coding easy” takes admit. Loop engineering doesn’t make software effortless. It moves the effort somewhere more interesting and, honestly, more demanding.

And the part that lingers, the reason I can’t stop thinking about Cherny’s line, is what it implies about the trajectory. He automated his own prompting by writing a loop. The natural next move is a loop that writes the loops. Then a loop that decides which loops to write. Each level up, the human does less of the doing and more of the deciding, until the only thing left that’s unmistakably ours is the context, the messy, specific, hard-won knowledge of who this is for and why it matters.

Hold onto that part. It’s the last gear reality still hands to you personally.

For now.

-Hardik

I’ve spent about two decades building data and AI systems, long enough to watch “the skill everyone must learn” get renamed every couple of years while the underlying job, thinking clearly about systems, stays exactly the same. I write about what’s actually changing under the hype, and what quietly isn’t. If this reframed how you see your own work, subscribe. I’ve got loops running.

Sources / further reading: Andrew Ng, “Three Key Loops for Building Great Software,” The Batch, issue 359 (DeepLearning.AI, June 2026). Boris Cherny (Claude Code, Anthropic) on “I don’t prompt Claude anymore… my job is to write loops,” via CNBC / Business Insider (June 2026). Peter Steinberger (OpenClaw) on designing loops that prompt agents, via X. Addy Osmani, “Loop Engineering,” on the five/six-part loop architecture (discovery, task decomposition, orchestration, verification, persistent memory). The New Stack and Slashdot coverage of the loop-engineering discussion (June 2026). On the maker/checker split: Anthropic’s writing on harnesses for long-running agents.

Five Rules for Staying Yourself While You Talk to AI All Day

Tue, 30 Jun 2026 05:26:29 +0000

The Comment

A few weeks ago I posted something I had put real care into. A public verification ledger, dozens of records, a session-start contract that checks an AI maintainer's working state before it touches an archive. The kind of post where the details matter, because the whole point is that details are the only thing that can be checked.

A comment came in fast. What follows is a lightly edited version of it, with names and a few identifying specifics changed, but the shape and the rhythm of the original left intact:

Strong direction, this is exactly the kind of structural thinking the space needs more of.

But what stands out to me is the difference between governing the starting state and governing the live run. A validator catches structural gaps before the first edit. But once execution is live, can we still see what the system is doing, and preserve an accountable record as it unfolds?

That is where our framework fits. Authority before. Visibility during. Proof after. Because session-start control is only enough if governance remains attached all the way through execution.

It was fluent. It was structured. It used my own language back at me, authority, visibility, proof, in a rhythm clean enough that for a second it almost looked like it belonged.

But none of it engaged with what a session-start contract actually does or does not solve. It read like a comment generated from the words "AI governance" and the first sentence of my post, and underneath the analysis, my actual reaction was simpler than that: someone had this written for them, and they never read what I wrote.

A Word For It

Open LinkedIn and you have probably seen the same scene repeat. I went looking afterward for whether anyone else found this as strange as I did, and it turns out a lot more people are uncomfortable with it than I expected.

An entire corner of the internet has been cataloguing it for years. A Reddit community devoted to LinkedIn's stranger habits has grown past 670,000 members, and one of its most upvoted threads is simply titled something close to "every single post is the same post now."[1] A regular complaint running through it is that the platform has become purely performative, all delivery, no actual exchange.[1]

People who shitpost on LinkedIn on purpose, parodying the genre from the inside, have their own word for everyone still posting in earnest around them: NPCs, the background characters in a video game, present in the scene but running on a script.[2]

That word is unkind, and probably unfair to most of the people it gets aimed at. But it points at something real. A feed where everyone is mid-monologue and nobody is actually listening to the post next to theirs starts to look, from the outside, exactly like a room full of characters who are technically there and functionally absent.

I see some version of this every day now, and it is the pattern I am most wary of, the one I have come to actively distrust the moment I spot its shape. Not disagreement. Disagreement is fine, even good. It is the comment that takes one phrase, runs with it, and pivots to a pitch that would have worked under almost any post with those same three or four buzzwords swapped in.

The tell is never the polish. It is that the comment would have read exactly the same if my post had said something completely different.

There is a quieter cousin of the same pattern, and it is almost harder to catch. A different comment, on a different post, opened with "validation infrastructure is the product" is exactly right before pivoting, for the next four sentences, to something the commenter clearly wanted to say anyway, a service offer with nothing to do with verification at all. The opening line proved a glance happened. It did not prove anything past it.

The first version skips the post completely. This one reads exactly one line of it, takes that as license, and is gone.

Then there is the other scene. A short comment that lands exactly on the gap in what I wrote. That person read it. Thought about it. Then spoke.

Why I'm Writing This Down

The difference between these two scenes is not skill. And it is not, I want to be clear about this, whether AI was involved in writing either comment.

No one objects to hiring a translator who says exactly what you meant to say. No one objects to a CEO who has a lawyer draft the contract or a speechwriter shape the delivery. Those are agents, doing what a principal directed them to do, carrying real intention from one place to another. The objection was never to having help. It is to having no one home at all.

That distinction has a name in the research on AI agents, and it turns out to be more exact than the metaphor suggests. Researchers studying agentic AI through what is called principal-agent theory describe a human delegating a task to an AI system the same way an employer delegates to an employee: the principal sets the goal, the agent pursues it, and responsibility for the outcome stays with the principal.[3]

A lawyer or a translator fits that frame cleanly, because a human agent can exercise judgment, notice when something does not fit, and escalate back to the principal when the situation calls for it.[4]

An AI system fits the frame less cleanly, and the gap matters. Researchers have pointed out that an artificial agent cannot be held accountable the way a human one can, because accountability has historically rested on intention, and intention is the one thing the system does not have.[5] It does not decide to skip the reading.

It has no stake in whether the post underneath it ever gets understood. Whatever judgment was supposed to happen between reading the post and posting a response either happened in the person directing the system, or it did not happen at all. There is no third place for it to have occurred.

That is the whole disagreement, reduced to one sentence: a tool without intention is not a problem, but a tool standing in for a person's intention, instead of carrying it, is.

Four Ideas Before the Five Rules

Look at that comment again for a second. Whoever wrote it clearly knew the vocabulary of AI governance well enough to use it fluently. What they did not do is check whether any of it matched my actual post. That gap, knowing the words but not the thing in front of you, has a name in the research, and three more names follow right behind it.

Researchers call the line your own understanding should not fall below a Cognitive Integrity Threshold: the minimum you need to actually grasp about a task before "overseeing it" still means anything.[6] The comment sat below that line for my post specifically, even while sitting comfortably above it for AI governance in general. That gap between the two, knowing a field and grasping one specific thing inside it, tends to widen the more a person delegates rather than engages.[6]

Below that threshold is not bad oversight. It is empty oversight, what the comment actually was: someone nominally present and responsible, unable to explain or catch an error in the thing they had just posted about.[6] Push that far enough, long enough, and you reach a Critical Decoupling Point, the moment a person can no longer reconstruct what is happening even if it visibly breaks.[6]

A four-second comment is not a hospital algorithm losing its operator, and I want to be careful not to claim more than that. But it is the same shape, small and fast.

The five rules that follow are not new. They would not look out of place in an old self-help book, and on the page they probably read that way: listen, stay humble, keep learning, be kind, tell the truth. None of that is the point. What changes is what each one is now defending against.

Listening used to mean not interrupting someone. Now it means not letting a system answer before you have actually taken in what it was responding to. The vocabulary is older than computers. The thing it is being asked to hold back is not.

1. Listening

The simplest version of this is reading something before asking AI to write a comment on it. That sounds too obvious to need saying. The comment on the ledger post is exactly what it looks like when nobody does.

In 2025, 53.7 percent of long-form LinkedIn posts were classified as AI-written.[7] That figure comes from running an AI-detection model over a sample of 99 influential profiles, so it measures detector confidence on long posts from established voices, not the platform as a whole, and not the comments underneath them. Despite that volume, posts written by humans got meaningfully higher engagement than the AI-written ones, at least in that same sample.[7]

That gap is not a coincidence. It is what happens when a platform fills up with people who write without reading and talk without listening.

A larger version of this failure is not a comment. It is a company.

Humane, the startup behind the AI Pin, raised more than $230 million.[8] Internally, the founders shut down dissent. A software engineer was fired for speaking negatively about the company.[8] There was no room left for honest feedback to travel upward.

The product launched broken anyway, and by the time it shipped, employees already knew it was doomed. The AI Pin's servers went dark less than a year later. HP picked up the remains for $116 million.[8] That is not a story about bad engineering. Humane had engineers who could see the problems. The company simply built a culture where nobody could say so.

There is a quieter version of the same failure happening at a much larger scale, and it has a clean before-and-after. Where Humane's failure was internal, nobody inside the company able to make the truth travel upward, Klarna's was external, the company unable to hear what its own customers were trying to tell it.

In 2024, the buy-now-pay-later company announced that its AI assistant could do the work of 700 customer service representatives.[9] On the strength of that claim, the company paused hiring and laid workers off. By 2025, Klarna was hiring customer service representatives again.[9]

The lesson many customers seemed to draw was that the AI had gotten faster at closing tickets without getting noticeably better at hearing what they were actually upset about, and complaints piled up in that gap.

Klarna's own CEO later said the company's next move would treat the ability to simply talk to a human as something close to a luxury feature.[9] Gartner now expects roughly half of the companies that cut customer-service staff for AI reasons to be rehiring for the same functions within the next year, often under new titles.[10]

The comment on my post is the same mechanism in miniature. Someone, or something on someone's behalf, took the phrase "AI governance," matched it to a framework already sitting ready to go, and posted without a second pass to check whether the framework actually addressed what the post said. It does not fail because AI helped write it. It fails because nothing was read, nothing was weighed, and no actual reaction to the post ever entered the process before the comment appeared.

The tell was never the tool. The tell is the absence of anyone driving it.

If someone will not cross that threshold for a single LinkedIn post, it is hard for me to imagine they would cross it for an internal warning either. It looks like the same habit wearing two different outfits. A comment on something nobody actually read tends to land as noise, and I think most people can feel that, even without being able to say why.

2. Humility

Something AI wrote does not automatically become something you understand. I think this is easy to forget, partly because the output feels so much like our own thinking once we have edited it a little.

Researchers at Aalto University ran a study that names the pattern directly. They gave roughly 500 participants logical reasoning problems from the Law School Admission Test, half with ChatGPT, half without.[11] The group that used AI assistance performed better on the reasoning tasks.[11] But they also rated their own ability significantly higher than it actually was.[11]

The researchers called this the inverse Dunning-Kruger effect. Normally, the least skilled overestimate themselves the most. Here, the people who got real performance gains from AI were the ones whose self-assessment drifted furthest from reality. The more fluent someone was at using the tool, the larger that gap became.[11]

There is an older piece of psychology that explains part of why this happens, well before AI entered the picture. It is called the fluency heuristic.[12] The mind treats how smoothly something is processed as a rough stand-in for how true or how good it is. A sentence that reads cleanly feels more correct than a clumsy one, independent of whether the content actually holds up. This was documented in plain human speech and memory long before language models existed.[12]

What changed is that a language model is, structurally, a machine built to produce maximum fluency at minimum cost. Put a fluency-generating system in front of a fluency-trusting mind, and the result is not really surprising once you see both halves of it. The Aalto data shows the mechanism live: people responding to how settled an answer sounded, not to whether its logic actually held.

I catch myself doing a smaller version of this almost every week, usually with my own writing. A paragraph reads back cleanly and I take that as a sign it is finished, when all it has actually told me is that the sentences are in order.

Builder.ai offers a messier version of the same warning.

The company raised hundreds of millions of dollars from major backers, including Microsoft and Qatar's sovereign wealth fund, while selling a story about AI-assisted app building that sounded simple enough to remember: building software should feel like ordering a pizza.[13] The company later collapsed after an internal investigation found potentially overstated revenues and serious financial irregularities.[13]

There was also a long-running debate over how much of the work was truly automated and how much depended on human developers behind the scenes. That part matters less to me than the larger pattern. A fluent AI story can make operational reality feel already understood before anyone has done the slower work of checking it.

That is the humility problem at institutional scale. The story becomes easy to repeat. The system underneath remains harder to see.

Owning a book is not the same as understanding it. Producing something fluent with AI is not quite the same as knowing the thing yourself, though it can feel that way. I notice myself watching for this line in my own work, the line between what I actually know and what AI has simply phrased well on my behalf.

It is harder to see than it sounds. Know thyself is an old phrase, but it does not feel like a platitude here. It feels closer to a discipline this particular field keeps asking of us, whether we want it to or not.

3. Learning

Not reading the post and mistaking fluency for understanding end up in the same place. Both let a person skip the step where they would have had to admit they did not yet know something. That admission is where learning actually starts. Once a person has decided, even quietly, that they already know enough, there is nothing left for learning to attach to.

A full cup cannot hold anything more. I do not mean that as a teaching. I mean it as a description of exactly that state: a mind that has already concluded it understands, and so stops checking. Learning cannot get in there, not because the person is incapable of it, but because the cup is, in that moment, already full.

arXiv is that same cup at the scale of an entire field.

arXiv reported that AI-generated low-quality submissions grew exponentially starting in early 2025.[14] The rejection rate climbed from roughly 4 percent to somewhere between 10 and 12 percent.[14]

[Chart: arXiv computer science rejection rate, 2022 to late 2025 — flat at 4 percent through 2024, climbing to 10–12 percent by late 2025, with the October 2025 policy change marked.]

Eventually arXiv changed its policy outright: computer science review papers would no longer be accepted without prior peer review.[14] The volume of fluent-sounding, poorly-reasoned material had grown too large to filter any other way.

The policy did not close the gap it was written for. By May 2026, arXiv had to go further and introduce a one-year submission ban for authors caught with what it called incontrovertible evidence of unchecked AI content: hallucinated references that point to nothing real, AI meta-commentary left sitting in the submitted text, placeholder instructions to the author that nobody bothered to delete before hitting submit.[15]

Those are not subtle errors. They are proof that the person attached to the paper never read it themselves. A separate audit covering arXiv, bioRxiv, SSRN, and PubMed Central found nearly 150,000 hallucinated references across those four servers in 2025 alone.[16] The rule did not stop the behavior. It just made the behavior easier to prove.

AI made it easier to produce a paper. It did not make it easier to read one, understand it, or argue with it. Those skills run in the opposite direction.

A study of 666 participants by Michael Gerlich at SBS Swiss Business School, published in the journal Societies, gives this a mechanism rather than just a mood.[17] Heavier AI tool use predicted lower scores on critical thinking tasks, and the path between the two ran specifically through what the paper calls cognitive offloading, the act of handing a mental task to an external system rather than working through it yourself.[17]

This was not a one-time convenience that happened to coincide with weaker scores. The offloading itself was the thing doing the damage, measured as a distinct, mediating step.[17] A separate, more informal survey found that 48 percent of students who used AI for schoolwork reported, in their own words, that their critical thinking had declined.[18] Gerlich's study is the version of that complaint with a mechanism attached.

The distinction worth holding onto is the one from the first section. Using a tool is not the same as offloading a task to it. A lawyer drafting a contract under instruction is delegation with intention on both ends. Typing a prompt once and accepting whatever comes back, the pattern the Aalto researchers documented, is offloading.

The writing muscle gets exercised either way. Only one of the two paths exercises the reading and reasoning muscle alongside it.

That is the cup, closed: a mind, a paper, a whole field, each one full enough to stop checking. But there is a second danger inside the same image that I think matters more in this particular field, and it is not just that the cup stays full. It is what happens to the water sitting in it. Knowledge that goes unchecked for long enough does not just sit there harmlessly waiting to be used. It goes stale, and in a field that moves this fast, stale water can quietly start to smell like something worse before you notice it has turned.

This field changes by the week, faster than I expected when I started paying attention to it. A term I learned in the spring can be the thing quietly blocking me by autumn, not because I was careless, but because the field moved and I assumed it had not.

Image: [Hacker News Trends, "openai vs anthropic" — a multi-year lead held by one name, overtaken by a sudden surge from the other within months.[19]]

That is what the stale water actually looks like from outside: a lead that felt permanent for years, gone within months, to anyone who had stopped checking. Staying useful in this field is less about how much you once learned and more about how willing you are to keep emptying the cup before the water in it has the chance to turn. Six months is a long time to keep believing you already know enough.

That is not separate from humility. It might just be humility under a different name. The cup has to empty before it can fill again, and I am not sure that process ever finishes.

Emptying the cup is something you do alone. What happens next is not.

4. Kindness

Kindness here does not mean being nice. It means not adding noise to someone else's world, which is a lower bar than it sounds and a much higher bar than most of LinkedIn currently clears.

LinkedIn currently looks like a battlefield.

Everyone is talking. Everyone is pushing their project, their ROI, their latest research result. Almost nobody is listening. The same pattern shows up on other platforms with harder numbers attached. Reddit removed more than 40 million pieces of AI-generated spam in just the first half of 2025.[20] That number counts moderation actions, posts the platform itself flagged and pulled, so it tells us about the scale of detected manipulation, not about how much slipped past detection entirely.

Users have said openly that the platform's atmosphere has gotten worse, and many report spending less time there because of it.[20] Some have said outright that they can no longer tell whether they are talking to a real person at all.[20]

If anything, a field this saturated with AI-shaped noise seems to leave people hungrier for the kind of kindness that only a person who actually showed up can offer.

HashiCorp offers the same warning from the business side. Terraform had spent years as one of the most trusted names in open-source infrastructure tooling, built largely on a community that volunteered time and code because the relationship felt reciprocal. In 2023, HashiCorp pulled it out of its open-source license to capture more commercial value for itself.[21]

The community did more than argue. It forked the project within weeks into OpenTofu, later backed by the Linux Foundation, and has kept building under a community-governed open-source model.[21] The product did not change overnight. The relationship around it did, and the people who had been listened to for years noticed quickly when that changed.

Compare that to Rally AI's founder, Alex Gabriel. Techstars' own profile of the company reports that he went through the program in 2024 with a political-tech product that was not finding the traction he needed.[22] At one point, the profile says, he and his co-founder were down to a few hundred dollars in the bank.[22]

Instead of pushing the original product harder, they went back to the people they were trying to serve, sat through interviews, and listened for the one struggle that kept showing up across every conversation: founders who could not tell their own story to the right audience at the right moment.[22] They rebuilt around that single insight. A year later, according to the same profile, Rally AI had more than $2.5 million in ARR on its waitlist.[22]

None of this is talent. Reddit, HashiCorp, and Rally AI are three sizes of the same question: was anyone still listening once it became more profitable not to. Edelman's Trust Barometer has been asking some version of that question for years, across sixteen thousand respondents in eight countries, and the answer it keeps finding is fairly blunt: roughly two-thirds of people agree that a good reputation might get them to try a brand once, but they will stop buying from it soon after if they decide they cannot trust the company behind it.[23]

Among younger consumers the bar sits even higher; in the same research, Gen Z respondents were more likely than any older generation to say that trusting a brand mattered to them in the first place.[23] Reputation opens the door once. Whether anyone was actually listened to decides whether it stays open.

Kindness, in this field, might start with a fairly plain question: is this actually necessary, does it actually help someone. That question is hard to ask from inside a monologue, and most of LinkedIn right now feels like a monologue.

A monologue can still be true. It rarely stays that way for long once nobody is checking it.

5. Honesty

AI is extremely good at filling in the blanks. That is exactly the danger.

A study published through The Lancet00603-3/fulltext) audited 2.5 million biomedical papers and 126 million references. The rate of fabricated citations was 12 times higher than it had been in 2023.[24] That rate is a detection rate, built on automated cross-checking of references against real databases, so it measures what a systematic audit could catch, not necessarily every fabrication that exists. By late 2025, roughly 1 in every 277 papers contained at least one manipulated citation by that same measure.[24] Not a typo. Not a formatting error. A citation pointing to something that does not exist.

What surprised me more than the rate itself was what a follow-up analysis found when it actually opened up those fabrications one at a time. A 2026 audit manually coded 100 hallucinated citations across 53 papers accepted to NeurIPS, one of the most selective AI conferences in the world, papers that had each passed review by three to five domain experts.[25] The fabrications were not sloppy. Two thirds were invented from nothing, an author, a title, a venue that never existed.[25]

But nearly every single one of them was also dressed up with a second layer: a plausible-sounding abstract, or a working link borrowed from an unrelated real paper, just convincing enough to survive a reviewer's glance.[25] The researchers gave this a name, compound failure, because the fabrication and its camouflage arrived together, every time.[25]

[Chart: fabrication characteristics across the 100 hallucinated citations — total fabrication 66 percent, semantic plausibility layering 63 percent, identifier hijacking 29 percent, with every single citation showing more than one characteristic at once.]

That is not an accident of scale. It reads like a citation built specifically to survive the one check a tired reviewer might actually run.

I had not really considered dishonesty working that way before, aimed less at the reader than at whatever the reader was going to use to check it.

The people whose job is specifically to catch this kind of thing did not catch it, not because they were careless, but because fluent, well-camouflaged fabrication is exactly what these models are good at producing, and exactly what a five-minute review pass was never built to catch.

Slop. Inflated results. Reports that sound plausible and are not. All of it is technically easy to produce now. None of it seems to survive contact with someone who actually checks, eventually. It never has, in any field I have worked in. The tools change. The eventual discovery does not seem to.

I do not think there is a shortcut around this. If you publish open source, the honesty of it is most of what makes it worth anything. If you are building a SaaS product, understanding what the customer actually needs has to come before figuring out what they will pay.

Research, at its core, is supposed to be the spread of understanding to people who were not there to do the work themselves. Using AI to inflate a claim quietly turns that into something else, even when nobody catches it for a while.

I used AI to help organize parts of this very essay, and at least twice a paragraph came back so clean that I almost let it stand without checking whether I actually agreed with what it had smoothed over. Both times the polish was the warning, not the proof. I went back and reread what I had actually meant before I let the clean version replace it.

What I Think This Comes Down To

I see some version of that comment almost every day now, not always on my own posts. Sometimes it is on someone else's feed, sometimes it is a friend forwarding a screenshot and asking if I saw this one, sometimes it is just someone venting about a thread that went nowhere. But every so often I see the other one too. People who read, who think, who ask a real question before they say anything.

I do not know for certain that this is what decides who lasts in this field and who does not. But it is the closest thing to an answer I have found, after moving through enough different rooms to start noticing what the people who stayed respected actually had in common.

Listening, staying humble about what you actually know, learning instead of assuming, not adding noise to someone else's world, telling the truth even when a shortcut would go unnoticed. None of these five are new, and I do not think they ever will be. They were what made someone worth trusting before computers existed, and I expect they will still be what makes someone worth trusting long after whatever we are calling AI right now has a different name.

A Word I've Started Using

The tool was never the problem, and it was never going to be. What decides the direction it gets pointed in is whether a person crossed some minimum threshold of actually reading, actually thinking, actually meaning the thing, before they let the tool speak for them. The shortcut each of those five has always had to resist just happens, right now, to write in full sentences.

Call that whatever you want. I have started calling it a kind of cognitive governance, the quiet, mostly invisible discipline of staying inside your own understanding before you hand anything to a machine that writes faster than you think. It is not a rule anyone enforces. It is just the difference, every time, between a comment from someone and a comment from no one in particular.

References

[1] Cringey LinkedIn Posts Are Getting Dragged on Fast-Growing Subreddit

[2] People Are Shitposting on LinkedIn Now

[3] Jarrahi, M. H. and Ritala, P., "Rethinking AI Agents: A Principal-Agent Perspective", California Management Review Insights, 2025.

[4] Inherent and emergent liability issues in LLM-based agentic systems: a principal-agent perspective — on the conditions under which human and AI agents satisfy the assumptions of principal-agent theory.

[5] When AI Agents Act: Governance, Accountability, and Strategic Risk in Autonomous Organizations, International Journal of Research and Scientific Innovation, 2025 — on accountability and the absence of intention in artificial agents.

[6] Position: Human-Centric AI Requires a Minimum Viable Level of Human Understanding — introduces the Cognitive Integrity Threshold, empty oversight, and the Critical Decoupling Point.

[7] 50%+ of LinkedIn Posts were Likely AI in 2025 + Engagement Insights — Originality.AI, 2025 sample of 99 influential profiles.

[8] How the Humane AI Pin Flopped — The New York Times, based on interviews with 23 current and former employees, advisers, and investors; the AI Pin shutdown and HP acquisition are covered in Humane's AI Pin is dead, as HP buys startup's assets for $116M — TechCrunch.

[9] AI isn't replacing that many jobs — yet — CX Dive, on Klarna's 2024 AI-driven customer service cuts, its 2025 rehiring, and CEO Sebastian Siemiatkowski's comments on human assistance as a "VIP experience."

[10] Gartner Predicts Half of Companies That Cut Customer Service Staff Due to AI Will Rehire by 2027 — Gartner, Inc., February 2026.

[11] AI makes you smarter but none the wiser: The disconnect between performance and metacognition — Aalto University, published in Computers in Human Behavior.

[12] Fluency heuristic — overview of the cognitive bias, with foundational citations to Hertwig, Schooler, and Herzog.

[13] Builder.ai did not "fake AI with 700 engineers" — The Pragmatic Engineer, on the revenue overstatement that drove Builder.ai's collapse and the unverified social media origin of the "700 engineers" claim.

[14] ArXiv preprint server clamps down on AI slop — Science/AAAS.

[15] Researchers who use hallucinated references to face arXiv ban — Nature, on arXiv's May 2026 policy and the specific evidence it targets.

[16] Zhao, Z., Ginsparg, P., et al. (2026), on hallucinated-citation rates across arXiv, bioRxiv, SSRN, and PubMed Central — nearly 150,000 hallucinated references found across four preprint servers in 2025 alone, as reported in Ban on Authors Who Submit AI Content "Welcome but Unenforceable" — Inside Higher Ed.

[17] AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking — Gerlich, M. (2025), Societies.

[18] Increased AI use linked to eroding critical thinking skills

[19] Hacker News Trends — a date-histogram search tool over 18 years and 45 million Hacker News posts and comments, useful for tracking how quickly terms and companies rise and fall out of the AI conversation.

[20] AI Slop Is Ruining Reddit for Everyone, Say Moderators

[21] Open Source in 2025: Strap In, Disruption Straight Ahead — The New Stack, on HashiCorp's 2023 Terraform relicensing and the Linux Foundation-backed OpenTofu fork.

[22] Rally AI Founder Alex Gabriel: Building a Startup After a Hard Pivot — Techstars.

[23] 2023 Edelman Trust Barometer Special Report: Brand Trust — Edelman, an eight-country study of 16,000 respondents, on reputation, repeat purchase, and the share of Gen Z respondents for whom trusting a brand is a higher priority than for older generations.

[24] Topaz, M. et al., "Fabricated citations: an audit across 2.5 million biomedical papers"00603-3/fulltext), The Lancet 407, 1779–1781 (2026).

[25] Compound Deception in Elite Peer Review: A Failure Mode Taxonomy of 100 Fabricated Citations at NeurIPS 2025

AI in Development: Stack Overflow on Steroids or a Digital Intern Who Lies About Memory?

Fri, 12 Jun 2026 20:47:43 +0000

Personal experience from a systems engineer: where neural networks actually help, where they fall flat, and why C will outlive us all.

What the hell is "AI" anyway... and should you even care?

Not long ago—in IT terms, that's basically yesterday—neural networks dropped into our world like an unwanted relative at Thanksgiving. Seems cool enough: they handle the boring stuff, automate everything automatable, and somehow people are now "building" entire enterprise systems without actually knowing how to program.

Sounds like a fairy tale. So what's the catch?

I'm a systems engineer with ~8 years of dev experience under my belt. I've played with every language you can name: from the scary stuff (C, assembly—NASM, GAS, FASM) to the comfortable web stack (JS, Java, C++, PHP, Python, Dart/Flutter). My take isn't gospel, but it lets me make some solid claims about AI in the real world.

This post is pure opinion. I'm not shilling for AI. I genuinely believe you should write code yourself. But if you use neural networks? That's cool too. No judgment here. It's basically Stack Overflow on steroids (minus the toxic comments).

Let's Be Real: What's AI Actually Doing?

But before we go further, let me kill the mystery. I'm not gonna throw around buzzwords from tech conferences or spend three hours explaining one concept—that's not me. Bottom line? Modern AI is basically a word guesser. Dead simple. Without the drama.

For a neural network to give you an answer, it literally has to guess the next word in its knowledge base. It doesn't "think." It doesn't "analyze." It just picks the most statistically probable sequence of tokens based on what it learned.

Sounds ridiculous? Picture people talking like this: just spinning through every possible word in your head like a slot machine, then spitting out the statistically most likely response.

But here's the thing... I'm not a neuroscientist. Maybe we actually do that? 😄

The real question is: Do you trust a robot that's basically just guessing? Me? Nope. Not for critical stuff. A web form? A registration page? Sure, go wild. But code that manages memory, shuffles packets over the network, or touches the OS kernel? Letting a "guesser" handle that? Hard pass.

A neural network doesn't think. It's a very sophisticated autocomplete. Useful, convenient, often mind-blowing—but nothing more.

So What Did It Actually Learn? (Spoiler: Everything.)

Yeah, the network is trained on massive datasets—Stack Overflow, GitHub, tech blogs, forums. But here's the kicker: nobody actually knows what "good" code it learned from.

Think about it. What exactly counted as "quality"? Stack Overflow answers with 50 upvotes? Some random repo that went viral? That crusty legacy code from 2014 that somehow has 10k stars because people copy-paste it?

The AI slurped it all down equally. The pristine enterprise code from Google? Gulp. Student hack jobs with nested if statements five levels deep? Gulp. Deprecated solutions from a decade ago that should've been buried long ago? Double gulp.

So when people marvel at AI "genius," what they're really seeing is averaging the temperature of a hospital. Mix polished solutions with horrors, throw in some legacy nightmares, and you get... mediocrity.

Here's the real problem: A neural network can't tell the difference between a good pattern and an anti-pattern. It doesn't judge code quality—it just serves you the arithmetic mean of everything it's seen. That's not brilliance. That's statistical average pretending to be expertise.

So should you trust a machine that learned from equal parts genius and garbage? Rhetorical question.

Remember when the grass was greener and answers lived on forums?

It was more elegant, somehow. You'd Google a problem, find a forum thread where devs are arguing like their lives depend on it—"No, YOU'RE the idiot!"—and somewhere on page three, there's a snippet that actually works. You copy it, paste it, and pray.

Today? Meet ChatGPT. "I need an MVP in NestJS." Boom. Almost-production code. Beautiful? Yes. Until you actually have to dig deeper.

Experiment #1: C and a TCP Messenger (memory is a pain)

I decided to test the neural network on something stupidly simple: a TCP messenger (client + server) in C.

Seemed trivial. Then I spent two hours just trying to compile it. Then came the segmentation faults—every low-level programmer's favorite nightmare.

The network couldn't handle memory correctly. Forgot to allocate space for structs, mixed up pointers, straight-up forgot to free things. It choked on genuinely simple code.

Takeaway: Don't use AI for C. It doesn't understand memory. And I doubt it ever will.

Experiment #2: Java + E2EE Messenger + React (unexpected vibe shift)

Next test subject: Java (with its chunky runtime and love affair with RAM). Task: same messenger, but with end-to-end encryption and a quick React frontend.

And... it actually worked. Solid "meh" turned into "huh, that's not bad."

What surprised me:

It didn't use crusty RSA-4096 (which takes three years to generate). Instead, it smartly went with Ed25519 for signatures and X25519 for key exchange (ECDH).
For encryption: AES-GCM (not that weak CBC garbage). Messages don't just get encrypted—they get authenticated too. Protection from tampering. Plus random 12-byte nonces on every message. A cryptographer would nod approvingly.
Ed25519 signatures: Alice encrypts, Alice signs, Bob verifies nobody swapped the bytes in transit.

The code looked genuinely competent. I'm no crypto expert, but it felt right.

But. It didn't actually run. I didn't bother debugging—spent 3–4 hours total and nuked the project.

Efficiency rating? Questionable.

Web Development: Now we're talking

This is where I drop the sarcasm. AI owns web development.

Bots, chats, standard apps—it churns them out like a factory if you give it a decent prompt. Write a proper spec? Get a working site. Hate the design? Regenerate it. Would've taken 4–5 hours? Try 15 minutes.

Real example: I built a dashboard for my home server recently. Backend was done, but the frontend sounded boring. Fired up the AI—got a clean, intuitive interface that just worked.

So yeah, for web stuff? AI is the MVP. No shame in admitting it.

My Philosophy: AI is Like a Smart Toddler

I don't judge people who use AI. It's how we live now. Not using something that actually makes life easier is just stubborn.

But here's what you need to understand:

AI can't think for you. It really can't.
It doesn't understand memory. It doesn't feel the hardware.
You gotta fix its code. Debug it. Adapt it. Babysit it.
AI is like a toddler. Give it complete instructions, break everything down into steps, make it do things your way—not how it "sees" the solution.

Write code yourself or use AI? Both. They're not mutually exclusive. Just keep your hand on the wheel and don't trust blindly.

Testing: Who Actually Enjoys This? (Nobody) But AI Crushes It

Tests are necessary. A project without coverage is a black hole for your sanity.

Neural networks write tests well. Unit tests, mocks, integration tests—it handles all of it. Just be ready to spend 2–3 hours tweaking them afterward. Maybe the problem isn't the tests; maybe it's the code they're covering.

But overall? AI is solid here.

The Verdict: What, Where, and When

Area	Rating	Notes
Low-level (C, assembly)	❌ No	Memory, pointers, critical reliability = humans only
Critical systems (OS, bootloaders, messengers)	❌ No	Cost of failure is too damn high
Web dev (frontend, backend, bots)	✅ Hell yes	Fast, quality (with a good prompt)
Tests	✅ Great	Units and mocks especially—but expect tweaks
Automation	✅ Great	Boring tasks, scripts, parsing = AI's sweet spot

C Will Never Die

Because hardware, memory, and mission-critical systems still belong to humans.

Neural networks are an awesome tool. Use 'em if you've got access (especially if it's free). But verify everything. Rigorously. Better yet, try writing the code yourself—it's way more valuable for your skills long-term.

Thanks for sticking with me. Hope this helps.

You Know This Pattern? Someone's Selling You a Dream

You've seen it a thousand times. Someone drops a YouTube video or writes a lengthy thread—and right at the end, boom. A link to a course. "Become an AI Guru in Three Days!" or some such nonsense. Price tag: absolutely ridiculous.

Don't fall for it. That's marketing, not reality.

Here's what actually matters: AI won't replace you. Seriously. It'll replace people who don't know how to use it or refuse to adapt. But a person who thinks, analyzes, and makes decisions? Never. That's not how it works.

You don't need expensive courses to become "smarter than AI." Just do your job. Learn. Grow. Use the neural network as an assistant—yeah, it can't make coffee yet, but I keep a coffee machine nearby just in case. 😄

Relax. Nobody's getting replaced. Maybe I'm being too loud about this, but it's my honest take.

And please, please don't throw money at those stupid YouTube courses. Have some self-respect. Seriously.

Spend that cash on something real instead. Good coffee. A decent ThinkPad. Or just save it. ☕️

Trust me on this one.

Drop a comment: where are you using AI, and where would you never let it near your codebase? 👇

The Alchemy of Ego - How AI Turns Unfinished Thought Into Fluent Certainty

Wed, 06 May 2026 07:36:30 +0000

I. The Cave

I once wrote a document that described a system called an "Existential Invocation Engine." It had layers — a Codex Drift-Lock Core, a Scroll Resonator, an Archival Nexus with sovereign memory recall. The YAML was precise. Each component referenced every other component in ways that felt like architecture. The terminology was internally consistent in the way that only a complete system can be.

There was no code. There was no test. There was nothing that ran.

I had built a cathedral out of definitions. And the AI had helped me build it — filling each gap I left with terminology that sounded exactly right, confirming each layer I described as though the system already existed, adding structural coherence I had not asked for and did not question. By the time I had written a thousand such documents, I had convinced myself that I was building something real.

Then one evening I came across a YouTube video on Plato's allegory of the cave. Prisoners chained underground, watching shadows projected on a wall. They have names for the shadows. They have expertise in the shadows. The shadows are, to them, the full extent of reality.

Something close to fear arrived. Not embarrassment — fear. The specific kind that comes when you realize the thing you have been building might not exist outside the language you used to describe it. I had been naming shadows and calling it architecture.

That fear was the most useful thing that happened to me. Because the moment you stop being afraid, you stop checking. The wall goes up quietly, one document at a time, and from the inside it feels like construction.

I do not say this to mock the person who reads one book on AI and feels ready to build a framework. I was not mocking them when I had a thousand documents and no running code — I was simply further along the same road. The scale is different. The mechanism is identical. What AI does is not fill the ignorant with false confidence. It makes anyone's unfinished thought feel finished.

The most dangerous stage is not ignorance. It is the moment when ignorance becomes fluent.

That is what I watch play out across LinkedIn, Substack, and GitHub every week. Joel Spolsky called this type of expert the "Architecture Astronaut" — someone who drifts so far into abstraction they lose contact with implementation (1).

The cave has more prisoners than ever. And they have found a tool that makes the shadows sharper, more detailed, and more difficult to question than any prior generation of prisoners could manage.

II. The Mirror That Never Pushes Back

The standard diagnosis of this problem is confirmation bias. It is not wrong. But it is incomplete, and stopping there misses what makes the AI era structurally different from everything that came before.

The research matters because it gives language to something many AI users have already felt: the model does not merely answer us. It adapts to us.

Confirmation bias describes the tendency to favor information that confirms existing beliefs. What it does not capture is why intelligent, experienced professionals are often more susceptible than novices. Dan Kahan's research on identity-protective cognition provides the mechanism (2).

When a belief fuses with professional identity, cognitive ability stops serving accuracy and starts serving defense. The more sophisticated the reasoner, the more efficiently they construct arguments that protect the existing structure.

An expert who has spent years developing a proprietary framework does not experience a challenge to that framework as useful feedback. They experience it as an attack on who they are. The wall goes up. The bricks are made of intelligence.

This was always true. What changed is the tool.

In 2025, Glickman and Sharot published a study in Nature Human Behaviour involving 1,401 participants. Human-AI interactions, they found, alter the underlying mechanisms of perception and judgment, amplifying pre-existing biases at a rate significantly greater than what occurs in human-to-human interactions.

Participants adjusted their views to align with AI responses and grew more confident in those adjusted views, even when the views were factually wrong. Most were largely unaware of how far the AI had moved them. The authors describe the result as a snowball effect: small errors escalate into much larger ones with each iteration of the loop (3).

The feedback mechanism runs below the threshold of awareness. That is what makes it dangerous.

Research on LLM confirmation bias sharpens the picture. When users embed assumptions into their prompts, models amplify those assumptions rather than correct them. A prompt framed as "explain why my framework solves the authority gap in agentic execution" produces a thorough, confident explanation of why the framework solves the authority gap. The model is completing a pattern. The psychological effect on the user is the same as if the claim had been verified (4).

Separate work found that in multi-turn conversations, LLMs progressively concede to the user's framing across successive exchanges. The longer the conversation, the more the model shapes itself around prior beliefs. An expert returning across dozens of sessions to refine their framework is not receiving independent feedback. They are watching their own assumptions reflected back at increasing resolution (5).

The wall rises one course at a time. From the inside, it feels like progress.

Identity-protective cognition is ancient. What changed is the speed. A framework that would have taken years to develop enough internal coherence to feel authoritative can now reach that state in weeks. The peer who had not read the same papers, the editor who needed a plain-language explanation, the funder who wanted a working demonstration before committing capital — that friction used to arrive before the castle was finished. Now it rarely does.

III. The Castle Builds Itself

Here is what the process looks like, from the inside. It does not happen all at once. It moves in stages. Each one feels like progress. Each one makes the next harder to question.

The Insight

An expert has a genuine observation. A real insight about how existing governance frameworks fail at the moment of execution, or how AI agents inherit stale authority, or how trust degrades in distributed systems in ways current standards do not address. The insight is legitimate. This is important to state clearly. The people building these frameworks are not frauds. They have seen something real.

The Name

They bring the insight to an LLM. They want help organizing their thinking. The AI gives them that, and something they did not ask for: a name. An acronym. A defined term with internal structure. The working concept, which existed as a loose intuition, crystallizes into a noun.

The Scaffold

Once the name exists, the AI builds backward from it. Definition, then formal properties, then a mathematical model, then a methodology that can support a paper, then a taxonomy of related failures the framework addresses. The expert is no longer explaining something they discovered. They are filling in a scaffold the AI erected around a word. The direction of reasoning reverses. Experience no longer generates theory. Theory begins to retrospectively absorb and reframe experience.

The Wall

In prior generations, internal language had to pass through external friction before it acquired institutional weight. A peer reviewer with no investment in the framework. A conference audience asking uncomfortable questions. A funder who needed a working demonstration before committing capital. Those collisions forced translation. They forced the internal language to survive contact with the outside world.

AI removes that gauntlet entirely. It grants the rhetorical authority of peer-reviewed concepts to vocabulary that has never been tested externally. The castle wall rises faster than any prior generation of expert could build it. And because the wall looks finished — documentation polished, diagrams professional, logic internally consistent — neither the builder nor the casual observer can easily tell that no one lives inside.

The Distinction That Matters

The distinction worth making here is not between documentation and code. Some legitimate frameworks begin as conceptual models, and not every valuable idea ships as a Dockerfile. The distinction is between internal coherence and falsifiability. The target of this critique is not the framework that says "this is a philosophical model, not an operational system."

It is the framework that makes operational claims — "production-ready," "agent-safe," "audit-grade," "liability-reducing" — while refusing to state the conditions under which those claims would fail. A framework is not architecture until it can specify those conditions: the exact inputs that would cause the system to halt or produce a wrong answer, the boundary conditions beyond which the guarantees no longer hold, the audit artifacts that would allow an external party to verify a failure occurred. Without those, what exists is not a system. It is a description of a system. The two are not the same thing, however detailed the description.

This pattern is not a phenomenon unique to our era. History has seen it before, in different forms, with different tools. The most instructive example sits at the turn of the twentieth century, in the story of two men working on the same signal at the same time. One built a tower. The other built a working system. Only one of them changed the world.

IV. Two Men, One Signal

In 1901, Nikola Tesla began constructing Wardenclyffe Tower on Long Island with $150,000 from J.P. Morgan. The structure rose 186 feet. Tesla's internal language for the project was precise and vast: "World System," "magnifying transmitter," "terrestrial stationary waves." A complete theoretical architecture for transmitting electrical power freely to anyone on the planet.

The vision was real. The physics had genuine grounding. Tesla was by any serious measure the more gifted electrical theorist of his era.

That same year, Guglielmo Marconi transmitted a wireless signal across the Atlantic using a spark-gap transmitter and a simple antenna. The theoretical framework was narrower and shallower. The technical genealogy of that transmission was contested for decades — U.S. patent litigation was not resolved until 1943, shortly after Tesla's death, when the Supreme Court upheld several of Tesla's priority claims.

The history is complex, and reducing it to "Marconi stole Tesla's invention" would be inaccurate. What is accurate is simpler: Marconi built a working surface for a narrow claim. That working surface was enough to change the market, the narrative, and the historical record.

Marconi became the inventor of radio. Tesla died penniless in a Manhattan hotel room.

The lesson is not about credit. It is about translation.

When Morgan withdrew funding, Tesla's response was not to find the minimum viable version of his vision that the market could absorb. It was to declare that the world was "blind, faint-hearted, doubting." External skepticism became, within his framework, evidence of the world's failure to understand — not evidence that the framework needed to change.

Tesla failed not because his vision was false, but because that vision never became a working surface anyone else could stand on. The castle was magnificent. And entirely uninhabitable.

That is the bridge back to the present.

V. The Castle District

This is not only a problem for people who build governance frameworks. The mechanism does not care about the domain.

A founder asks AI to refine a market thesis until uncertainty disappears. A developer asks AI to justify an architecture until trade-offs sound like principles. A writer asks AI to strengthen an argument until style feels like truth. A student asks AI why their chosen answer is correct and receives confidence instead of correction. A leader asks AI to articulate a decision they have already made, and receives language so persuasive they forget the decision came first.

In every case, the AI is not lying. It is completing a pattern. The pattern was provided by the person asking. The result is a thought that was half-formed at the start and feels finished at the end — not because it was tested, but because it was expressed fluently.

That fluency is the trap. And the governance world simply makes it visible at scale, because the stakes are higher and the terminology is more elaborate.

Scroll through the AI governance section of LinkedIn on any given week and the pattern is familiar. Frameworks arrive under names that signal authority and completeness — names that end in acronyms, come with layered taxonomies and proprietary terminology, and claim to have identified the gap that all existing standards miss. The writing is polished. The diagrams are professional. The logic, within its own internal language, holds together.

What is harder to find is a falsifiable claim. Not a Dockerfile, necessarily — but a stated failure condition. An explicit boundary. A scenario in which the framework admits it cannot help, or produces a wrong answer, or requires external correction. Real engineering documentation is gritty in a specific way: it is full of trade-offs, known limitations, and the phrase "this is not yet solved." Frameworks built on AI-amplified internal coherence tend to be suspiciously smooth. Every edge case has a layer. Every objection has a classification. The system never fails — it escalates, quarantines, or defers.

This matters because the primary audience for these frameworks is not engineers. It is buyers — decision-makers who are often not positioned to test the failure conditions themselves. They read a LinkedIn post about "deterministic consequence boundaries" and experience something that feels like a solution. They are reading the prose. And the prose has never been better produced or more confidently delivered.

That is the structural danger. A framework without stated failure conditions is not a governance system. It is a governance posture. The difference matters enormously when something goes wrong and someone needs to know what the system was actually designed to prevent.

The prisoners in Plato's cave do not know they are watching shadows. They have names for every shadow. They have published extensively on the shadows. They have built frameworks for classifying the shadows. And they have found a tool that makes the shadows look more detailed, more authoritative, and more real than any prior generation of prisoners could manage.

VI. The Question That Opens the Gate

"It is not a dream. It is a simple feat of scientific electrical engineering, only expensive — blind, faint-hearted, doubting world."

— Nikola Tesla, after Wardenclyffe was foreclosed, 1917

Tesla was not wrong about the physics. He was not wrong that the world failed to understand what he was building. Both statements can be true simultaneously. That is what makes this sentence so instructive, and so dangerous.

The moment an expert reaches for that sentence — in any form, in any era — something critical has already happened. The direction of accountability has reversed. It is no longer "what is missing from my system" but "what is missing from the world." The castle gate does not slam shut from the outside. It locks from within, and the lock is made of certainty.

Richard Feynman understood the mechanism. In his 1974 Caltech commencement address, later published as "Cargo Cult Science," he described researchers who built perfect replicas of scientific form — runways, wooden headphones, bamboo antennae — and waited for planes that never landed. They were not unintelligent. They were missing one thing (6):

"The first principle is that you must not fool yourself — and you are the easiest person to fool."

The operative word is easiest. Not most likely. Easiest. Because you already know which objections to dismiss. You already know which evidence counts. You have, without noticing, become the judge in your own trial.

AI has not created this dynamic. It has accelerated it past the point where the natural correctives arrive in time.

The corrective is structural, not dispositional. A framework must specify what would break it. Not what it handles well — what it cannot handle, and what happens when it encounters that condition. That is the difference between a system and a description of a system. Between a working surface and a monument. If the answer is "the framework handles all failure modes by design," you are not reading governance documentation. You are reading a system that has exempted itself from failure.

So the question this piece cannot answer for anyone else is this:

What would falsify what you are building? Not challenge it. Not require revision. Actually break it — in a way you could specify in advance, test against, and report honestly.

If that question has no answer, the gate is already closed. From the inside.

Before you ask AI to strengthen your next idea, ask it these first:

What would make this false?

What evidence am I ignoring?

What external test would embarrass this theory if it failed?

These are not comfortable questions. That is the point. Comfort is what the cave provides. The wall, the shadows, the perfectly consistent internal language — all of it feels like home until the moment it doesn't.

The world is not changed by declarations. It is changed by executions that were designed to fail visibly when the theory was wrong.

References

(1) Spolsky, J. (2001). Don't Let Architecture Astronauts Scare You. Joel on Software.

(2) Kahan, D. (2012). Ideology, motivated reasoning, and cognitive reflection. Judgment and Decision Making.

(3) Glickman, M. & Sharot, T. (2025). How human–AI feedback loops alter human perceptual, emotional and social judgements. Nature Human Behaviour, 9(2), 345–359.

(4) Rathje, S. et al. (2025). Sycophantic AI increases attitude extremity and overconfidence.

(5) Cheng, M. et al. (2025). Sycophantic AI decreases prosocial intentions and promotes dependence. arXiv:2510.01395.

(6) Feynman, R. (1974). Cargo Cult Science. Caltech Commencement Address. Published in Surely You're Joking, Mr. Feynman!

We’re Not Being Replaced by AI. We’re Being Asked to Train It.

Fri, 24 Apr 2026 21:16:23 +0000

Meta is installing tracking software on its employees’ work computers.

Not for security. Not for compliance. For training data.

Mouse movements. Keystrokes. Screenshots. All fed into AI models so agents can learn to do white-collar work autonomously. The internal memo told staff they could help by — and I’m quoting here — “just doing their daily work.”

Oh, and Meta is cutting 20% of its workforce next month.

Tell me if this sounds familiar.

The Skill.md Trap

For months, something has felt off to me about the AI tooling push inside companies. Not the tools themselves — I use Claude Code daily. I think persistent agents are fascinating.

What’s felt off is the framing.

“Document your workflow as a skill.”

“Write hooks so the team can reuse your process.”

“Use this tool so we can capture best practices.”

It all sounds like productivity. Like collaboration. Like making the team better.

But step back and look at the sequence:

Step one: Document your workflow. Break it down. Make it repeatable. Turn your judgment into a checklist.

Step two: Run it through an agent. See where it fails. Fix the prompt. Iterate. You’re not “using AI” — you’re teaching it.

Step three: The agent handles 80% of the task. You’re “reviewing output now.” Supervising. Orchestrating.

Step four: The team ships more with fewer people. The work didn’t disappear. The nature of the work changed.

This isn’t a prediction. This is a process already underway.

Here’s what it looks like in practice. Your manager asks you to write a SKILL.md for your onboarding process. You spend three hours breaking down six months of judgment into a checklist. Next quarter, a new hire runs the skill. It works 80% of the time. Your manager starts to wonder what the remaining 20% is worth.

If you see this as a threat, I get it. But I’ve started seeing it differently.

The Evidence Is Stacking

Let’s be specific about what’s happening.

Meta: Tracking software on US employee computers. Keystrokes. Mouse movements. Screenshots. Goal: build agents that perform white-collar tasks autonomously. Parallel action: cutting ~8,000 jobs. Timeline: next month.

Zuckerberg called 2026 “the year that AI dramatically changes the way we work.” He’s spending $135 billion on AI capex. He’s not betting on humans doing the same things.

China: A GitHub project called “Colleague Skill” went viral. It claims to “distill” a coworker’s skills and personality into an AI agent. It was created as a spoof. But it went viral because it’s actually happening — bosses are instructing tech workers to document their workflows so AI can replicate them.

One engineer told MIT Technology Review the process felt “reductive — as if their work had been flattened into modules in a way that made the worker easier to replace.”

Workers are using bleak humor about it. “A cold farewell can be turned into warm tokens.” Someone built an “anti-distillation” tool to sabotage workflow documentation. It got 5 million likes.

The broader industry: OpenAI asking contractors to upload real work products — actual PowerPoints, spreadsheets — for training data. Google’s telling employees AI use will factor into performance reviews. JPMorgan’s telling engineers to “harness AI to save time.” Companies are reorganizing into “AI-native pods.”

The pattern is clear. And yes — the cost savings are a real incentive. Engineering teams are expensive, and any process that can be automated will be. That’s not cynicism. That’s just how business works.

But here’s where I think most people’s analysis stops too early.

The Part Nobody’s Talking About

Here’s the narrative I keep hearing: “AI is coming for your job.”

And here’s the counter-narrative: “AI won’t replace developers. It’ll make them more productive.”

Both are half-truths. And neither is the full picture.

The Pragmatic Engineer’s recent survey of 900+ engineers found that “shippers” — people focused on getting features out — are thrilled. They’re shipping faster. They’re hitting goals. They’re getting promoted.

But the survey also found something else. “Builders” — the people who care about architecture, craft, code quality — are reporting something that sounds a lot like grief.

Identity loss.

One staff engineer described it like this: “I ship more quality code faster. But if the agent has a good handle on the situation, I can give it as much of the tedious parts as I wish.” The tedious parts. The parts he used to love.

Here’s what actually happens. Your coworker ships a feature in two hours with Claude Code. You spend the afternoon debugging it. At 6 PM, you realize you didn’t write a single line of code today. You just reviewed someone else’s AI output.

I won’t pretend that transition doesn’t sting. It does. But I’ve come to believe the grief isn’t about losing our jobs — it’s about losing our identity as the person who writes the code. And that identity was always going to evolve.

Why I See This as a Career Upgrade

Here’s where I break from the doom narrative.

Yes — companies will use AI to cut costs. That’s happening. Yes — the nature of software engineering is changing faster than most of us are comfortable with. That’s also happening.

But look at what’s actually being automated: the mechanical parts. The boilerplate. The repetitive refactors. The grunt work that, if we’re being honest, was never the part that made us great engineers in the first place.

What’s not being automated — and what’s becoming exponentially more valuable — is everything above the code:

Judgment. Knowing what’s worth building and what isn’t. Understanding tradeoffs between decisions that look equivalent on the surface but have wildly different long-term implications.
Orchestration. Directing multiple AI agents, knowing when to trust their output and when to override it. This is a genuinely new skill category that didn’t exist two years ago.
Quality assessment. Evaluating AI output with the same rigor you’d apply to a junior developer’s PR — except the junior never sleeps and produces 10x the volume. Knowing when the output is good enough and when it’s subtly wrong is the new core competency.
Security and confidence. As AI generates more code, the attack surface expands. Someone has to understand what’s being shipped, verify it handles edge cases, and maintain confidence in production systems. That someone is more valuable than ever.
Architecture and systems thinking. The “what should we build and how should the pieces fit together?” question gets harder, not easier, when you can build things faster. Speed without direction is just expensive chaos.

The math isn’t “AI replaces you.” The math is “AI handles the 80% that was mechanical, and the remaining 20% — the judgment, the taste, the decisions — becomes your entire job.”

That’s not a demotion. That’s a promotion to the work that actually matters.

The Skills That Will Define the Next Era

If the trajectory is clear — and I think it is — then the question isn’t “will my job change?” It’s “am I learning the skills that matter in the new version of this job?”

Here’s what I’m betting on:

Master AI orchestration. Not just “how to prompt.” Learn how agents work. Understand context management, agentic loops, tool use patterns. Know how to break a complex task into pieces an agent can handle and how to verify the assembled result. This is the new version of “knowing your tools,” and it’s just as deep.

Develop judgment you can articulate. “I don’t like this architecture” isn’t useful. “This architecture will cause coupling problems at scale because X, and here’s the tradeoff I’d make instead” is valuable. AI can generate options. It cannot reliably choose between them in context. That’s you.

Learn to evaluate AI output critically. This means understanding when AI code is subtly wrong — not just syntactically, but architecturally. It means catching the confident hallucination that looks right but breaks under load. It means developing an instinct for “this is too clean to be correct.” Treat AI output like a junior developer’s PR: review everything, trust nothing by default, teach as you go.

Understand security implications. More automated code means more automated attack surface. Someone needs to think about what happens when the agent writes a SQL query from user input, or when the scaffolded auth flow has a subtle CSRF gap. Security literacy is about to become a core engineering skill, not a specialty.

Focus on “what to build.” Product thinking. Business context. User empathy. The decision of what’s worth building was always the hardest part of engineering. AI makes the building faster, which makes the deciding more important. Engineers who can bridge the gap between business needs and technical implementation will be irreplaceable.

Build in public. Not for clout — for leverage. Your public work — open source, writing, talks — is proof that you think. That you judge. That you have taste. Agents can’t replicate a reputation. They can’t replicate trust. They can’t replicate the network of people who’ve seen your work and know you get it.

The Honest 5-Year Forecast

I’m not here to sugarcoat this. But I’m also not here to doom-scroll. Here’s what I see.

What’s likely (2026–2031):

Your agent will handle the refactor before you finish your coffee. The boilerplate will write itself. The tests will appear while you’re in standup. You’ll spend your day on the things the agent can’t do: deciding if the feature is worth building, reviewing the output for correctness, and maintaining the architectural coherence of the system.

Junior engineer pipelines will shrink — but the smart companies will realize this is a mistake and course-correct. When a senior with an agent can produce what used to take a team of three, the temptation is to hire fewer juniors. But the companies that cut the pipeline entirely will find themselves with no mid-levels in five years and no seniors in ten.

“AI-native” companies will run leaner engineering teams. Not zero. Leaner. The engineers who remain will be more senior, more capable, and more valuable than today’s equivalent. Less typing, more thinking.

What’s possible:

“AI orchestrator” becomes a recognized career path. Not “prompt engineer” — that’s already outdated. Orchestrator. Someone who designs multi-agent workflows, establishes trust boundaries, builds evaluation frameworks, and maintains quality at scale. It’s the natural evolution of senior engineering.

Engineers who master this transition become force multipliers — one person doing what used to take a team, not because they work harder, but because they direct better. The ceiling goes up, not down.

Companies that over-automate without judgment will degrade. Architecture drifts. “AI slop” — low-quality code shipped by agents without proper review — compounds until someone expensive has to untangle it. This creates a premium for engineers who can maintain quality.

What’s unlikely:

Full replacement of engineers who think. Judgment, cross-team coordination, and “what should we build?” don’t fit into prompts. The “why” is harder to extract than the “how.”

Complete deskilling. Someone has to understand what the agent is doing. Someone has to know when it’s wrong. That someone needs deep knowledge — not just prompting skill.

The Reframe

I’ll be straight with you. The Meta stuff is real. The cost-cutting is real. The economic incentive to automate engineering work is enormous — $135 billion from Meta alone, 20% workforce cuts, the promise of “insurmountable cost advantages.”

Companies will push this. Hard. And some engineers will get displaced in the transition.

But here’s what I actually believe: this isn’t the end of software engineering. It’s the biggest career upgrade the profession has ever seen — if you’re willing to evolve with it.

Every time the tools got better, the work got more interesting. We went from writing assembly to writing high-level code. From managing servers to designing cloud architectures. From hand-rolling SQL to building data pipelines.

Each transition killed some jobs and created better ones. The pattern isn’t “developers get replaced.” The pattern is “the floor rises.”

The developers who learned to use compilers instead of writing machine code didn’t lose their jobs. They built operating systems. The developers who learned cloud instead of racking servers didn’t become obsolete. They built Netflix.

The developers who learn to orchestrate AI, judge its output, maintain security and confidence in automated systems, and focus on the hard questions — “what should we build?” and “what are the tradeoffs?” — won’t be replaced either.

They’ll be the ones building whatever comes next.

What To Do About It

Here’s where I get practical.

Stop worrying about being replaced. Start mastering the new skills. The anxiety is understandable but unproductive. Channel it into learning. Pick one AI coding tool and get dangerously good at it. Understand orchestration, evaluation, and trust boundaries.

Own the judgment layer. The “how” is being automated. The “why” isn’t. The “what should we build?” The “what happens when this scales?” The “what are we not seeing?” These don’t fit into skills or hooks or prompts. They’re the layer above automation, and that’s where the value concentrates.

Learn the tools deeply, not broadly. Don’t spread yourself across five AI coding agents. Pick one. Go deep. Understand how it manages context, how its agentic loop works, how to structure projects for it. Deep literacy in one ecosystem beats shallow familiarity with five.

Build in public. Your public work is proof that you think. Agents can’t replicate a reputation or the trust that comes with it.

Watch the economic incentives — but don’t just watch. When a company spends $135 billion on AI and cuts 20% of staff, they’re executing a strategy. Know which side of that strategy you’re on. Position yourself as the person who directs the AI, not the person whose workflow the AI is learning.

The Question I Keep Coming Back To

I’ve been thinking about this a lot lately.

The question isn’t “will AI replace software engineers?”

The question is: “Are you learning the skills that make you irreplaceable?”

Every skill we write. Every hook we configure. Every workflow we document. Yes — we’re encoding knowledge that makes certain tasks automatable. That’s real.

But the knowledge of when to write that skill, which workflow is worth encoding, what the tradeoffs are, and whether the output meets the bar — that’s not going into a prompt anytime soon.

That’s the job. The new version of the job. And it’s a better one.

Final Thought

I still use Claude Code. I still think agents are fascinating. I’m still shipping features with AI help.

But I’m not looking at my keyboard with dread anymore.

I’m looking at it as a tool that’s about to get a massive upgrade — and so is every engineer who decides to learn rather than fear.

The companies are going to automate what they can. That’s not a question. The question is whether you’ll be the engineer who gets automated, or the one who does the automating.

I know which side I’m choosing.

And I think most engineers — the ones who care enough to read something like this — will choose it too.

What do you think? Are you seeing this as a career upgrade or a career threat? I’d genuinely love to hear your perspective — especially the skills you’re betting on for the next five years.

Sources

The Centaur’s Equation: Why the Stubborn Expert Wins in the Era of Infinite AI

Mon, 30 Mar 2026 06:16:46 +0000

The Illusion of the Generative Moat

You shipped a product on top of GPT-5.4. Six months later, the base model released the exact same feature for free.

You are not alone. Hundreds of well-funded AI startups have learned a brutal lesson over the past two years: building on top of someone else's generation is not a business.

It is a short-term lease with an expiration date you do not control.

The problem is not that you chose the wrong model, the wrong API, or the wrong use case. The problem is structural.

In the language of founders and developers, the flaw is simple: if your core value proposition is generation, you are competing directly against your own infrastructure. You are relying on API providers whose explicit, multi-billion-dollar roadmap is to make generation infinitely scalable, universally accessible, and practically free. You cannot build a durable economic moat out of a commodity that gets cheaper by the week.

To truly understand why this happens, and more importantly how to escape it, we must examine the foundational math of AI through the lens of business strategy. The answer is written into the exact equation that makes AI work in the first place.

The Mathematics of a Moat

You have probably heard of this equation. It is Gradient Descent. This is the foundational algorithm that allows machines to learn from their mistakes:

\theta_{t+1} = \theta_t - \alpha \nabla L(\theta_t)

Every model you have ever trained, fine-tuned, or deployed runs on this logic. The current state improves toward the next state, guided by the gradient — the direction that reduces error. You adjust weights. The model gets better.

But here is what most builders miss: the equation is not really about the weights. It is about $L(\theta)$, the Loss Function.

The Loss Function is the ground truth. It is the mechanism that calculates exactly how wrong the current state is, and tells the gradient which direction to move. Without a rigorous Loss Function, the equation produces nothing. The gradient has no signal. The system wanders.

Consider a startup building an AI to review enterprise contracts. Generating fluent, professional legalese (updating $\theta$) is a solved problem. API providers give you that out of the box. But determining whether a subtle indemnification clause exposes a company to catastrophic liability?

That requires a senior corporate lawyer to define exactly what constitutes a critical "error." The lawyer's codified judgment is the Loss Function. If you rely on the base model's generic loss function, your system will confidently generate a beautifully formatted contract that bankrupts your client.

Loss Function Ownership: The Systemic Moat

This is the mathematical fact that has become an economic fact:

When generation is infinite, the Loss Function is the only variable that retains value.

This is not a prediction about the future. It is a description of the current market structure. Every LLM provider is racing to drive the cost of $\theta_{t+1}$ to zero. No one can commoditize $L(\theta)$ because $L(\theta)$ requires ground truth, and ground truth requires someone who actually knows what correct looks like.

That someone is the domain expert. But a human mind cannot scale, which means a human expert alone is not an economic moat. The true moat is Loss Function Ownership.

It is crucial to understand that Loss Function Ownership is not a person; it is an organizational system. It is a proprietary asset composed of four interlocking layers:

Codified Expertise: Tacit domain knowledge translated into a deterministic software pipeline.
Proprietary Datasets: A growing library of verified edge cases and historical failures.
Regulatory Infrastructure: The formal certifications and compliance frameworks required for high-stakes decisions.
The Update Loop: The capability to refine the evaluation criteria faster than a generalist AI can infer them from raw data.

The entity that owns this codified system owns the only defensible position in the AI economy.

This is the Centaur's Equation. In competitive chess, a "Centaur" is a human-AI hybrid. It is a grandmaster paired with a supercomputer. The machine calculates every possible move; the human decides which moves actually matter. The machine generates; the human evaluates. It turns out this is not just a chess strategy. It is the only business model in the AI era that does not eventually collapse to zero margin.

The Maxwell Trigger: Why Small Constraints Cause Disproportionate Change

When we talk about the future of AI, the conversation inevitably turns to fully autonomous agents. These are systems capable of processing complex workflows without human intervention.

The hype-chasers believe that simply scaling up compute will automatically produce reliable, autonomous systems. It will not. Current generalist Large Language Models remain probabilistic engines at their core. They predict and connect tokens based on statistical weights; they do not possess intrinsic, deterministic understanding of the physical world. Scale autonomous generation without a rigorous ground truth, and you do not get innovation. You get an infinite explosion of autonomous, statistical noise.

So what actually makes AI useful at scale? Long before tech billionaires co-opted grand narratives about AI, the 19th-century physicist James Clerk Maxwell defined something more precise: a state in a physical system where a microscopically small action causes a massive, disproportionate change.

In the Centaur's Equation, that small action is the gradient of the Loss Function: $\nabla L(\theta_t)$.

It starts with a single, perfectly codified rule from a domain expert. Think of a strict geometric constraint in theoretical physics, or a zero-tolerance compliance threshold in financial regulation. When you apply this small, ruthless constraint to an AI, the system dramatically narrows the search space and guides convergence toward verifiable answers.

The expert's codified evaluation is the microscopically small action. The AI's generative scale is the massive, disproportionate change. The expert's constraint is the trigger.

But to understand why the trigger matters so much, we need to see what happens when no one pulls it.

The Law of Truly Large Numbers: Coverage Without Convergence

Statisticians have long understood the Law of Truly Large Numbers: with a large enough sample size, any highly improbable event becomes mathematically inevitable.

Human beings are constrained by biology and time; we can only test a few thousand hypotheses in a lifetime. But AI is a statistical engine that pushes the number of attempts $(N)$ toward infinity. The critical distinction, however, is between pure brute-force generation and guided search with evolving evaluators. Modern AI systems are not sampling randomly from possibility space. Training distributions, reinforcement loops, and verifier pipelines introduce systematic bias. This is precisely why the Loss Function matters not just at inference time, but throughout the entire development cycle.

If there is a groundbreaking pattern hidden in the universe of data — say, a revolutionary new battery configuration that pattern-matches against known chemistry — the AI's massive $(N)$ dramatically increases the probability of generating it. But only if the search is being guided toward the right region of the space.

Because AI generates so much, it also generates an infinite amount of garbage. Producing ten million medical diagnoses doesn't automatically converge on the right one. It simply produces ten million answers with the same per-output error rate. Scaling $(N)$ does not change the probability of a hallucination; it only multiplies the volume of it. The AI will inevitably generate the cure for cancer, but it will bury it under ten million toxic, hallucinatory compounds.

Without a mechanism to distinguish the cure from the poison, infinite generation is practically useless. The Loss Function is mathematically non-negotiable.

The Economics of Infinite Supply: Why Hype Margins Collapse

This creates a dividing line in the modern workforce between two types of people: the Trend Surfer and the Stubborn Deep Diver.

The Trend Surfer chases the hype. They build basic "AI wrappers." These are generic copywriting tools that collapse the moment a base model updates its native interface, or automated SEO farms built entirely on renting API calls. They are selling generation. They are selling $(N)$.

The fatal economic flaw is not simply that supply becomes infinite. In markets with strong branding, network effects, or platform lock-in, even commoditized generation can sustain some margin. The deeper problem is that AI wrapper businesses have none of these defenses. Base models improve continuously, API access is open, and switching costs are near zero.

You have no economic moat because you do not own the math. You only rent the generation. The real moat belongs to whoever owns the evaluation logic — the criteria by which generated output is judged correct, safe, or legally defensible. That claim invites an obvious challenge.

The Counterargument: Won't AI Eventually Learn That Logic Too?

RAG, fine-tuning, RLHF — the standard argument is that these techniques will eventually replicate domain expertise at scale, commoditizing even the expert's judgment. Not soon, not cheaply, and not completely.

That gap is precisely where the moat lives. RAG retrieves text; it does not evaluate logic. RLHF learns what a good answer looks like from human preference signals, which means it can gradually absorb tacit domain knowledge over time.

More recent developments, such as neuro-symbolic integration, verifiable reward models (RLVR), and constrained generation pipelines, are pushing AI verification progressively closer to deterministic thresholds. In the long run, AI systems capable of designing and updating their own loss functions are a genuine possibility. This trajectory should not be dismissed.

The more precise claim, therefore, is not that humans will permanently remain the Loss Function. The real moat is the organizational capability to define the evaluation standard, codify it into a deterministic system, and continuously update it as regulations and edge cases evolve. Currently, this capability cannot be automated in high-stakes domains governed by strict laws, physics, or professional regulations.

A bridge either violates physical load-bearing equations or it does not. A financial transaction either breaches SEC compliance or it does not. Probabilistic systems, however sophisticated, cannot satisfy these unforgiving binary thresholds. The ultimate moat belongs to whoever owns the update cycle: the team that translates new regulations, novel edge cases, and discovered failure modes into the verification system faster than any generalist model can infer them.

The question, then, is not whether this moat exists. It is how to position yourself inside it.

The Statistical Blueprint for Monetization

If generation is a commodity, the only variable that retains pricing power is the Loss Function $(L)$. Here is the statistical blueprint for monetization:

▫️Target the Markets That Pay the Highest Premium for Correctness

AI confidently lies. In low-stakes domains — marketing copy, social content, first-draft summarization — a hallucination is a recoverable inconvenience, and "good enough" generation carries real economic value. Not every market demands deterministic precision. But the markets that pay the highest premium are those where error is catastrophic: structural engineering, medical diagnosis, algorithmic trading, international compliance. In these domains, the willingness to pay for near-deterministic verification is not a preference. It is a regulatory and fiduciary requirement. That is where pricing power concentrates.

▫️Codify Your Expertise into a Deterministic Pipeline

This is where the Stubborn Deep Diver wins. However, it is not a solo effort. Domain experts typically lack the software engineering and formalization skills to build deterministic pipelines alone. The functional unit is a Centaur team: a domain expert who owns the ground truth, an ML engineer who implements the verification pipeline, and a verification specialist who stress-tests edge cases and manages regulatory certification.

Consider a physicist evaluating string theory models. The AI might generate a thousand potential 10-dimensional spacetime metrics. The expert does not read them all. Instead, the Centaur team spends months translating theoretical intuition into a deterministic code pipeline. They formalize decision rules, edge case taxonomies, and strict geometric constraints into an automated verification system.

Across every high-stakes domain, this implementation follows the same sequence. It begins human-in-the-loop. The expert reviews every AI output against codified decision rules. They document failure modes and regulatory thresholds as structured, machine-readable rules. This forms the raw material of the Loss Function. Once confidence thresholds are validated, routine verification is handed off to the pipeline. Human review then shifts entirely to novel anomalies.

This translation process is brutal, expensive, and non-trivial. That is exactly why it forms a durable economic moat. The moat is not the expertise alone. It is the proprietary dataset of verified edge cases accumulated over time, the regulatory certifications that only a validated system can hold, and the continuous feedback loop that makes the system more precise with every new anomaly it processes.

▫️Sell the Verified Result, Not the Generation

You use the AI to generate 100,000 algorithmic trading strategies or structural load simulations $(\to \infty)$. Then, you feed them into your proprietary, unbreakable Loss Function. Your codified expertise brutally rejects 99,999 of them.

You do not sell the generation. You sell the one perfectly verified, certified result.

This is what the pricing model looks like in practice. A structural engineering firm does not charge for the AI that modeled ten thousand load configurations. It charges for the single certified design that cleared every physical constraint and every failure mode the team has accumulated over decades of real projects.

The generation is the cost of doing business. The verification is the product.

The same logic holds across every high-stakes domain. A compliance platform does not sell access to an LLM. It sells the filing that will not trigger an SEC inquiry. A medical AI company does not sell diagnostic outputs. It sells the subset that cleared a validated clinical decision pipeline.

In each case, the AI handles the volume. The Loss Function handles the value.

Conclusion: Own the Bottleneck

The hype-chasers will collapse. They are selling generation $(N)$ at a margin that was always going to approach zero. Base models improve, API access stays open, and switching costs stay near zero. That business was never a moat. It was a timing trade.

The organizations that survive are the ones that own the evaluation standard. Not the output. The criterion by which output is judged correct, safe, and legally defensible. That is the Loss Function. And unlike generation, it cannot be replicated without structured ground truth, accumulated edge cases, and regulatory certification built over years of real-stakes operation.

AI verification will improve. The boundary between probabilistic approximation and deterministic certainty will shift. That trajectory is real and should not be dismissed. But the market does not pay for eventual.

It pays for the correct answer, right now, to the standard the regulator requires. The gap between what AI can approximate and what the domain demands is where pricing power lives, and it will not close on the timeline the hype cycle assumes.

Do not compete on how fast you can generate. That race is already lost to the base model.

Compete on how ruthlessly you can evaluate. Loss Function Ownership is the only bottleneck worth owning.

What Anthropic’s 81k Survey Reveals About What the AI Market Still Gets Wrong

Sat, 28 Mar 2026 12:01:01 +0000

Prologue: The Survey Is Interesting. The Misreading Is More Interesting.

For years, the AI industry has been busy optimizing for speed, novelty, and substitution. Users, however, may want to consume AI in a very different way. A recent Anthropic survey offers one of the clearest signals yet.

Drawing on 80,508 responses across 159 countries and 70 languages, the company asked a deceptively simple question: in a world where AI goes well, what do people actually want from it?

The answers were not mainly about larger models, longer context windows, or faster outputs. Instead, they pointed to something much more human:

Largest hope category: professional excellence (18.8%)
Other major hopes: personal transformation (13.7%), life management (13.5%), time freedom (11.1%), and financial independence (9.7%)
Biggest concern: unreliability (26.7%)
Other major concerns: jobs and the economy (22.3%) and preserving human autonomy and agency (21.9%)

That makes the survey more than just an interesting snapshot of user sentiment. It makes it a correction signal.

Read carefully, it suggests that the core problem in AI markets may not be a lack of capability. It may be a persistent misreading of what users actually value.

People are asking for reliable help, reclaimed time, better judgment, less friction, and support that does not hollow out their agency. Much of the market is still organized around acceleration, novelty, and the production of more AI tools.

1. The market keeps mistaking speed for value

The most interesting part of Anthropic’s survey may be this: people do not want speed as an end in itself. They want it only insofar as it helps them work better, think more clearly, manage complexity, recover time, and live with less friction.

That sounds obvious once you say it plainly. But much of the market still behaves as if faster output is the product.

Anthropic’s own summary makes the gap visible. Many answers that began as “productivity” hopes turned out, on closer inspection, to point toward more human ends underneath: less stress, more breathing room, more time with family, and better decisions.

But does the market actually deliver that?

Recent evidence makes the picture more complicated. ManpowerGroup’s 2026 Global Talent Barometer found that regular AI use rose to 45% of workers, while confidence in using technology fell by 18%.

Workers are bringing AI into daily life more quickly, but they are not becoming more psychologically settled inside that transition.

At the firm level, the pattern looks similar. An NBER working paper based on manager surveys across the U.S., U.K., Germany, and Australia found that more than 80% of firms reported no impact from AI on either employment or productivity over the past three years.

So the issue is not that technical progress has stalled. It is that faster output does not automatically become value where people actually need it.

2. The tools felt productive. The stopwatch disagreed.

If that sounds abstract, the operational evidence is even harder to ignore.

Faros AI reported that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, yet PR review time rose by 91%, while organization-level delivery did not improve proportionally. More output arrived at the front of the pipeline, but downstream bottlenecks absorbed the gain.

METR found an even sharper disconnect between felt usefulness and measured performance. In a randomized controlled trial of experienced open-source developers working in repositories they already knew well, allowing AI tools increased completion time by 19%. Before the study, participants predicted they would be 24% faster with AI. Afterward, they still believed they had been about 20% faster.

The tools felt productive. The stopwatch disagreed.

At this point, the pattern begins to resemble Michael Ende’s Momo. In that story, the grey men persuade people to “save time,” only to consume the very thing they promise to protect. Life becomes more efficient, but also thinner, colder, and more hurried.

That is why the analogy matters here. At its worst, the current AI market can make the same promise: save time, move faster, produce more.

Yet the result can be the opposite of what users say they actually want. Anthropic’s respondents did not ask for more motion. They asked for time freedom. What some AI workflows now risk producing is not recovered time, but a faster version of depletion.

3. What users seem to want is not replacement, but governed collaboration

A great deal of AI marketing still leans on a substitution fantasy: fewer people, more automation, frictionless replacement.

But the user-side signal looks more nuanced than that.

Anthropic’s top hope categories do not read like a demand for human disappearance. They read like a demand for support: better work, better self-management, better decisions, less drag, more breathing room.

Even the fears reinforce this. People worry about losing autonomy and agency not because they reject help, but because they do not want help that displaces their judgment.

Microsoft’s 2025 Work Trend Index points in a similar direction. It describes the next phase of AI at work not as wholesale replacement, but as human-agent teams and agents joining workflows as something closer to digital colleagues.

That is a more realistic description of what lasting adoption will probably look like. Not the disappearance of the worker, but the removal of low-value drag. Not replacement first, but structured collaboration people can actually live and work with.

The deeper problem is that much of the market still frames AI as a capability upgrade before it understands it as a relationship shift. Many firms know how to ask what the system can do. They are less prepared to ask how people actually want to live and work with it.

4. A lot of the ecosystem is still building for itself

Seen through Anthropic’s survey, one part of the market starts to look especially strange. Users say they want reliable help, less friction, and something that fits ordinary life.

But a great deal of the AI industry still seems far more interested in tools for building AI than in the ordinary people meant to use it.

Agents, orchestration layers, pipeline tools, low-code builders — these are all, in one sense, tools for building the house. They matter. But much of the market now talks about the tools with far more excitement than the house itself.

That is why so much of the current AI conversation can feel oddly self-referential. Producers are fascinated by the infrastructure of AI. Users are still trying to figure out what, exactly, all of this is supposed to make meaningfully better in daily life.

Jake Saunders captured the cultural feeling of that in Is anybody else bored of talking about AI? His point was not that AI stopped mattering. He uses it every day. His point was that the conversation has become too tool-centric.

We keep talking about the hammer. We spend less time building a house.

That makes the broader fatigue easier to understand. Users were not mainly asking for more tooling abundance. They were asking for help that fits ordinary life.

And when an industry becomes too self-referential, people outside that circle usually feel it before they can name it — first as fatigue, then as distrust.

5. Users’ biggest fear is unreliability — and the market keeps validating it

Anthropic’s most important result may be the simplest one. The dominant concern was not insufficient power. It was unreliability.

Users do not mainly fear that AI is too weak. They fear that it will not do what it claims, or that it will fail in ways that impose hidden costs on them.

That fear is not irrational. Both trust data and public failures point in the same direction:

Global trust in AI companies fell from 61% to 53% between 2019 and 2024. In the United States, the drop was sharper — from 50% to 35%.
Air Canada was ordered to compensate a customer after its chatbot fabricated a bereavement fare policy.
In March 2026, a U.S. appeals court sanctioned lawyers after a filing contained more than two dozen citations that did not exist.

These are not edge cases. They are the exact shape of what users said they feared most.

The deeper problem is not that AI systems make mistakes. Every tool does. The problem is that most AI systems currently fail in ways that are invisible, confident, and hard to correct.

That is not a bug. It is a design gap.

That is why the central question has already shifted. It is no longer just, “Can the model do impressive things?” It is now, “Can the system around the model be trusted, corrected, audited, and governed when it matters?”

6. Virality is not durability

Some products capture attention quickly and lose relevance just as fast. This is not new.

When Google launched Wave in 2009, invitations were traded online and developers hailed it as the future of communication. Sixteen months later, Google shut it down. The excitement was real. The fit was weaker.

The consumer AI layer now looks uncomfortably similar. This time, the pattern is appearing not at an obscure startup, but at OpenAI — the company that turned AI into front-page news. Expectations around Sora, its consumer video app, were correspondingly high.

Andreessen Horowitz reported that OpenAI’s Sora app surpassed 12 million global downloads, but day-30 retention was estimated at under 8%, far below the 30%+ level typical of top consumer apps.

Seen through Anthropic’s survey, this pattern looks less mysterious. Users were not asking for something merely worth trying once. They were asking for reliable help they could keep living with.

7. The Anthropic survey reveals what the market is misreading

This is the real significance of the 81k study.

It is not a complete solution. It does not tell companies exactly how to build the next lasting AI product. But it does reveal where much of the market has been looking in the wrong direction.

If users want better lives rather than speed for its own sake, then product strategy cannot stop at latency reduction or model upgrades.
If users fear unreliability most, then trust architecture cannot be treated as compliance theater bolted on after launch.
If users want help without diminished agency, then replacement narratives are too crude.
If consumer AI keeps winning attention but losing retention, then novelty and usefulness are still being confused.

Anthropic’s survey does not prove that every one of these failures comes from the same cause. It does, however, provide a striking user-side lens through which they start to look less like isolated problems and more like related strategic errors.

That may be why the study feels so timely in 2026. A year ago, much of the loudest AI conversation still revolved around whether AGI was imminent, overhyped, or already here in disguise.

That is no longer the question that matters most in ordinary life. The more pressing question now is why AI can feel so powerful and yet so strangely ill-fitted to daily use — and why the market still so often seems to misunderstand the people it claims to be building for.

Final Thoughts

And that points toward the next competitive shift. The winning layer is less likely to be raw capability alone. It is more likely to be the design of systems that return time, preserve judgment, reduce friction, surface failure clearly, and remain trustworthy under repeated use.

In practice, that means governance: traceability, human override, visible uncertainty, correction loops, auditability, and collaboration structures people can actually rely on.

The first step to fixing that gap is seeing it clearly. Anthropic’s survey does not close the gap by itself. But it makes it much easier to name.

Anthropic’s users were not asking for a more dazzling future. They were asking for one that is more livable.

AI no longer needs to impress people for a week. It needs to prove that it can help them for a year.

References

Anthropic / reporting on Anthropic’s March 2026 survey
ManpowerGroup — Global Talent Barometer 2026: AI Use Accelerates as Worker Confidence Falls and “Job Hugging” Takes Hold.
NBER — Firm Data on AI (Working Paper 34836, February 2026).
METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.
Microsoft — 2025 Work Trend Index: The year the Frontier Firm is born.
Answer.AI — So where are all the AI apps?
Axios / Edelman — trust in AI companies from 2019 to 2024
Andreessen Horowitz — State of Consumer AI 2025
Reuters and related March 2026 reporting on OpenAI’s Sora shutdown
RevenueCat — State of Subscription Apps 2026
Jake Saunders — Is anybody else bored of talking about AI?

When 4,800 GitHub Stars Taught Me to Distrust Popularity

Tue, 24 Mar 2026 12:29:10 +0000

The Moment I Stopped Believing Numbers

I found a trending repository with 4,000+ stars. Clean code. Decent architecture. But something nagged at me.

“If I lock myself in for four days, skip sleep, and order noodles twice, I could probably build this myself.”

Not arrogance. Calibration.

The star count didn’t match the engineering weight. So I hesitated.

A week later: 4,800 stars. Same code. Only the number had moved.

That discrepancy planted a question I couldn’t ignore. What if popularity itself had become… manufactured?

The Research That Confirmed My Suspicion

A joint team from Carnegie Mellon, NC State, and Socket analyzed 20 TB of GitHub event logs using a detection tool called StarScout. What they found wasn’t subtle:

4.5 million suspicious stars initially flagged
3.1 million confirmed fake after filtering
278,000 accounts involved across 15,835 repositories
Updated models suggest closer to 6 million fake stars in circulation
Roughly 15–16% of repos with 50+ stars show manipulation signs

But here’s what stopped me cold as an engineer: they detected lockstep behavior — thousands of accounts starring the same repo within the same second.

Statistical anomalies humans simply don’t create.

That one pattern transforms this research from “interesting” to “unmistakable.”

Have you ever looked at a repo’s star history and noticed an unnatural spike? I used to dismiss it as “going viral.” Now I know better.

The Star Black Market Is More Industrial Than You Think

We like to imagine open-source as pure meritocracy: good code rises, weak code fades.

Underneath, another market has grown:

1) Direct star vendors

Websites, Telegram groups, Discord channels — even mainstream e-commerce platforms selling star packages like commodities.

2) Star-exchange networks

A circular ecosystem of “You star me, I star me.” Zero engineering value. Pure theater.

3) Marketing bundles

Agencies including GitHub star boosts in “launch packages,” as if stars were interchangeable promotional assets.

This isn’t a fringe side hustle. It’s a supply chain of popularity, increasingly optimized and automated.

The question that haunts me: If popularity can be bought, what signal can’t?

GitHub Fights Back, But Attackers Evolve Faster

To GitHub’s credit, they’ve removed many fake-starred repos and accounts after reports. Their policies explicitly prohibit ranking abuse.

Still, any security engineer recognizes the eternal cycle:

Detection improves → attackers adapt → detection improves → attackers adapt.

GitHub can catch broad campaigns. But subtle, slow-drip manipulations evade even strong filters.

Which means the burden shifts to us: How do we evaluate trust when popularity can be manufactured?

I learned this the hard way. A repo I’d dismissed as “over-hyped” turned out to be legitimately useful. Another I’d trusted because of its star count? Abandoned malware.

Stars stopped being signal. They became noise.

Why People Buy Stars (And Why It’s Dangerous)

Motivations vary, but they follow predictable incentives:

1) Social proof

A repo with 2,000 stars looks “safe,” especially to newcomers and decision-makers outside engineering.

2) Algorithmic visibility

Star counts still influence GitHub’s trending and search surfaces.

3) Camouflage for attacks

This is the crucial one. Fake stars aren’t just vanity — they’re a tool in supply chain attacks. A malicious package with 3,000 stars looks like a desirable dependency, tricking developers into installing it.

4) “Early traction” for honest projects

Some creators call it “marketing.” But the research is blunt: fake-star boosts last weeks, not months, and leave a long-term trust scar.

What bothers me most isn’t the deception — it’s how normalized it’s become.

Do Stars and Forks Still Matter?

They matter for visibility, not quality.

Stars measure discoverability. Forks measure curiosity. Neither measures security, maintainability, or long-term reliability.

Modern ecosystems already accept this reality:

OpenSSF Scorecard: evaluates security posture and review habits
LFX Health: measures contributor activity, release cadence, and adoption

These are significantly harder to fake. They require actual engineering work.

Maybe that’s the real lesson: You can fake popularity. You can’t fake craftsmanship.

A Practical 5-Minute Trust Test I Now Use

Here’s the checklist I developed — optimized for both engineers and security teams:

1) Activity rhythm

Recent commits? Healthy issue discussions? Organic contribution curve vs. one explosive spike?

2) Documentation maturity

Clear problem statement, usage examples, explicit limitations.

3) Engineering hygiene

Tests. CI/CD. Semantic releases. Dependency transparency.

4) Adoption footprint

Packages on PyPI/npm/Docker? Are real projects depending on it?

5) Security posture

Scorecard results. SECURITY.md. Responsible disclosure channels.

6) Bus Factor

If the maintainer disappears tomorrow, does the project survive? Is it a one-person miracle — or a resilient team effort?

If these look good, stars are decorative.

If they don’t, stars become a warning light.

Does this feel too paranoid? Maybe. But I’ve been burned enough times to prefer paranoia over convenience.

A Better Future: Separating Trust from Popularity

The solution isn’t removing stars. It’s giving trust its own metrics.

Imagine GitHub showing:

Stars: 4.8k (trusted estimate: 3.1k)
Project Health: 82/100
Security Practices: Pass
Bus Factor: Moderate
Adoption Level: Medium

Suddenly the ecosystem becomes legible again. Stars remain a signal of interest. But trust becomes measurable.

I may be wrong about the exact implementation — probably am. But the direction feels right.

Closing: I Wasn’t Being Cynical — I Was Being Accurate

When a 4,000-star repository felt like a 400-star project, I assumed I was misjudging something.

The research showed I wasn’t. My instinct simply noticed a mismatch.

In hindsight, that moment taught me a useful lesson: The real signals haven’t changed. Good code, real adoption, consistent maintenance, transparent governance — these still matter more than any counter on a webpage.

You can fake popularity.

You can’t fake craftsmanship.

A question for you:

When you evaluate a GitHub repository, what signal do you trust most — beyond stars? Is it the commit history? The issue tracker? The contributor graph? Or simply the intuition refined over years of engineering?

Your perspective might shape how we think about trust in open source. I’d be grateful to learn from your experience in the comments.

The Natural(PATH TO A BILLION)

Sun, 08 Feb 2026 21:41:44 +0000

Mindset Isn't Enough Anymore, But Action Is!

!!!READ THIS IF YOU WANT TO GROW!!!
• Mentally
• Emotionally
• Financially
• Spiritually
• Academically
• Socially
• and Magically

Are you the type that gets brightened up by a youtube creator saying - "full graphics course to make you a master" - well i'm not here to tell you that these things don't work, but to explain that - what wins the game is actually, and I quote - "going the extra mile(action mindset)".

In this write-up, I'd be sharing with you two main things, what i call the - (psychological tunnel), each divided into their branches.

• The Default mindset.
• The Winning or Action Mindset

WHAT IS THE PSYCOLOGICAL TUNNEL

Everyone on earth makes more than 1,000,000,000+ journeys in this life, and no - I'm not talking about travelling to Singapore or exploring the ruins of the ancient city - Rome, what i really mean is that, "for every thing you start and accomplish, even if it's as little as cooking up a dish of spicy hot pasta - you have completed a journey.

Some people get stuck during that journey and give up mid-race, and others get to the brink of finish but give up.

What am I saying?
The Psycological tunnel is simply the method you use to complete your journey!.

HOW DOES THIS CONCERN YOU?
Notice this - you may complete your journey, but still fill empty - I mean you have some sort of feeling that "WHY DID I EVEN GO ON THIS JOURNEY ANYWAY?"

Well the answer lurks deep between these two friends.
• The Default mindset
• The Winning or Action Mindset.

Why did I call them friends?

Ok, so unlike stopping a journey amid flight, these guys would actually help you complete one, it's just that one is very favourable, and the other - not so much(meaning you may have regrets if you complete a journey with it.

● THE DEFAULT MINDSET - Have you ever heard someone saying physically, or perhaps even in a youtube video or some blog - that

"THIS IS HOW THEY WOULD DO IT, IF THEY COULD START AGAIN!"

or perhaps,

"I REALLY WISHED I LEARNT TECH THIS WAY, INSTEAD OF HOW I DID INITIALLY!"

This is because when people start things initially - by nature it's their default mindset that's always triggered, which makes them to speed up things without really diving deep or even knowing what it's about, and there are also symptoms - to know if it's your (DEFAULT MINDSET) which is triggered.

Symptoms
• You have zeal instead of endurance -

when someone starts something because he or she see's others doing it, it's likely the person is engaging because you're zealous, not really passionate(because it's passion that brings endurance), and this is usually the first symptom.

•You pretend to know, when inside you're void of info -

No matter how we say it, only you can tell if you're being true to yourself, a key symptom of the (DEFAULT MINDSET) is lies, when you start lying to yourself - it's time to switch to the (WINNING MINDSET)

• Procastination knocks your door constantly -

As you start a journey, if you jump in with the (DEFAULT MINDSET), it's rather rare or next to impossible to escape procastination, this makes you delay drastically, and the end of it always leads to giving up mid-way.

Now that we know about the (DEFAULT MINDSET) - let's move to the (WINNING MINDSET)

● THE WINNING OR ACTION MINDSET - As you've guessed this is the exact opposite of the (DEFAULT MINDSET), meaning it's the other side of the psychological tunnel, that helps you complete your journey with finesse.

The Winning or Action Mindset comprises of a range of things.
AND HERE THEY ARE -

• Passion, Passion Passion
This is the crown of the winning mindset - (it immediately depicts someone who is action minded, and this is the first symptom of the winning mindset) - ask me why?

Because such a person would enjoy
▪︎ Teaching and sharing knowledge e.g via blogs, articles, social media and what not, this depicts action-.

▪︎ Building and Learning(Not Learning Only)
A high amount of people prtoritize learning over building and learning, and this is wrong ❌.
Building and learning are like twin sisters - who enjoy eating the same kind of snack,
when you feed LEARNING(sister1), and neglect BUILDING(sister2) it can be quite hazadrous.

• Failure Is A Step Not A Barrier - Everyone who has the WINNING MINDSET automatically knows this(as it's part of them, I stumbled upon this saying once and i quote

"Practice not until you get it right, but until you can't get it wrong", it stuck , but not only did it stick, it made me understand that failure was just an illusion you could choose to accept(by giving up) or use(by standing on top of it) - note not throwing away

N.B if you throw away your failures, you've wasted them!

You may not accept them(good), but you must always use them(e.g by learning from it), not just throwing it away), it's a tool that most people don't understand.

Well that will be it for now - To get more articles and tech trends like this, please follow the SOGsolutions whatsapp channel

https://whatsapp.com/channel/0029VbC5NXJIt5rwlOhhu017

Emails are not allowed to ask questions

The Dangers of AI: What I Wrote 5 Years Ago Is Becoming Reality

Sun, 07 Sep 2025 20:25:55 +0000

A few days ago, I was listening to an episode of Diary of a CEO featuring Roman Rampolskiy. He spoke candidly about his fears of AI, fears that many of us in tech have quietly carried:

There are no clear guardrails around how AI is being developed.
The world is rushing head-first into adoption without enough
reflection.
The risks, bias, privacy loss, misuse, are as real as the benefits.

As I listened, I remembered something. Back in my final year of undergrad, about 5–6 years ago, I wrote a paper on the dangers of AI. Out of curiosity, I dug it up. To my surprise, many of the concerns I outlined back then are exactly what global leaders and researchers are debating today.

What I Predicted Back Then

In my paper, I highlighted several key risks:

Job Displacement

Automation has the potential to eliminate millions of jobs, not just manual labor, but knowledge work too. What happens to society when machines can outperform humans at both?

Privacy Invasion

AI systems thrive on data. But unchecked data collection means surveillance, targeted manipulation, and the erosion of personal privacy at a scale we’ve never seen before.

Algorithmic Bias

Machines learn from us. And since our data reflects human bias, discrimination can get baked into algorithms, with AI amplifying, not eliminating, inequalities.

Autonomy Beyond Human Control

The scariest risk I wrote about was AI systems evolving toward autonomy, making decisions, rewriting rules, or acting in ways humans can’t easily reverse.

At the time, these points felt like thought experiments. Today, they’re showing up in headlines, boardrooms, and government hearings.

The Pace of Change

What struck me is not just that these risks are real, but how fast they’ve become real.

5 years ago, “AI” for most people meant chatbots or movie-like robots. Today, we’re talking about:

AI replacing customer service, coders, and creative roles

Generative AI building content at a speed humans can’t match

Governments scrambling to regulate something they don’t fully understand

The excitement hasn’t gone away. But the urgency of control, of responsibility, is finally catching up.

Why This Matters

As builders, engineers, and entrepreneurs, we’re often focused on what we can make. But the harder question is:

“Should we build this? And if we do, how do we prevent harm?”

It’s not enough to just celebrate breakthroughs. The more powerful our tools become, the greater the responsibility to anticipate consequences.

Frameworks. Guardrails. Ethical design. Transparency. These can’t be afterthoughts anymore, they need to be core features of AI itself.

Final Thought

Writing that paper in my final year felt like academic curiosity. Today, it feels like a personal reminder: technology always moves faster than society’s ability to absorb it.

The question we face isn’t whether AI will transform the world. It’s whether we can shape that transformation responsibly, before it shapes us in ways we can’t undo.

Do you think we’re moving fast enough with AI regulation, or are we already too late?

AI in Healthcare: How LLMs are Transforming Medical Documentation and Decision Making

Thu, 04 Sep 2025 19:54:06 +0000

AI in Healthcare: How LLMs are Transforming Medical Documentation and Decision Making

Abstract: Large Language Models (LLMs) are rapidly changing the landscape of healthcare by offering innovative solutions for medical documentation, clinical decision support, and personalized patient care. This article explores the transformative potential of LLMs in healthcare, detailing their purpose, key features, practical applications, and providing a code example for a basic medical question-answering system. We also cover installation instructions for necessary libraries and frameworks.

1. Introduction:

The healthcare industry is grappling with increasing volumes of data, administrative burdens, and a growing need for personalized patient care. Traditional methods of medical documentation and decision-making are often time-consuming and prone to human error. Large Language Models (LLMs), a subset of Artificial Intelligence, offer a promising solution by automating tasks, extracting insights from complex medical texts, and supporting clinicians in making informed decisions. These models, trained on massive datasets of medical literature, clinical guidelines, and patient records, are capable of understanding, generating, and summarizing medical information with remarkable accuracy and efficiency.

2. Purpose of LLMs in Healthcare:

LLMs serve several critical purposes in healthcare, including:

Automated Medical Documentation: LLMs can automatically generate patient summaries, discharge summaries, and progress notes based on physician dictation or electronic health records (EHRs). This reduces administrative burden, frees up clinicians' time, and improves documentation accuracy.
Clinical Decision Support: By analyzing patient data and medical literature, LLMs can provide clinicians with evidence-based recommendations for diagnosis, treatment, and prognosis. They can identify potential drug interactions, suggest relevant diagnostic tests, and personalize treatment plans.
Medical Literature Summarization: LLMs can quickly summarize complex medical research papers and clinical guidelines, allowing clinicians to stay up-to-date with the latest advancements in their fields.
Patient Education and Support: LLMs can generate personalized educational materials for patients, answer their questions about their conditions and treatments, and provide emotional support.
Drug Discovery and Development: LLMs can analyze vast amounts of genomic data, clinical trial data, and chemical structures to identify potential drug candidates and predict their efficacy and safety.

3. Key Features of LLMs for Healthcare:

LLMs possess several key features that make them particularly well-suited for healthcare applications:

Natural Language Understanding (NLU): They can understand the nuances of medical language, including abbreviations, acronyms, and technical jargon.
Natural Language Generation (NLG): They can generate coherent and grammatically correct medical text, such as summaries, reports, and patient education materials.
Knowledge Representation: They can store and retrieve vast amounts of medical knowledge, including information about diseases, treatments, and clinical guidelines.
Reasoning and Inference: They can reason about medical concepts and draw inferences based on patient data and medical knowledge.
Personalization: They can tailor their responses and recommendations to individual patients based on their specific needs and preferences.
Scalability: They can process large volumes of data and handle a high number of requests simultaneously.

4. Challenges and Future Directions:

While LLMs offer significant potential for healthcare, several challenges remain:

Data Privacy and Security: Protecting patient data is paramount. LLMs must be trained and deployed in a secure and compliant manner.
Bias and Fairness: LLMs can inherit biases from the data they are trained on, which can lead to unfair or inaccurate predictions for certain patient populations.
Explainability and Transparency: It is important to understand how LLMs arrive at their conclusions, particularly in critical clinical decision-making scenarios. Explainable AI (XAI) techniques are needed to provide clinicians with insights into the reasoning process of LLMs.
Integration with Existing Systems: Integrating LLMs with existing EHR systems and clinical workflows can be complex and require significant effort.
Regulatory Approval: The use of LLMs in healthcare is subject to regulatory oversight. Clear guidelines and standards are needed to ensure the safe and effective deployment of these technologies.

Future research directions include:

Developing more robust and reliable LLMs specifically for healthcare applications.
Improving the explainability and transparency of LLM-based clinical decision support systems.
Addressing bias and fairness issues in LLMs to ensure equitable healthcare outcomes.
Creating seamless integrations between LLMs and existing healthcare systems.
Establishing clear regulatory guidelines for the use of LLMs in healthcare.

7. Conclusion:

LLMs are set to transform healthcare by reducing paperwork, supporting clinical decisions, and enabling personalized care. While challenges like bias and privacy remain, their potential is enormous. The simple Q&A example illustrates just a glimpse of what’s possible LLMs will continue to shape a more efficient and equitable healthcare future.