Coder Legion - Recent posts tagged futureofwork

The Death of SaaS - What Happens When People Can Make Software Fit Their Lives?

Tue, 13 Oct 2026 06:35:19 +0000

In February 2026, investors wiped approximately $830 billion from the market value of software and services companies over six trading sessions, frightened by the possibility that AI could erode businesses built around selling access to software. By October, US software stocks had recovered much of that ground, and Wall Street appeared considerably less alarmed. [1][2]

Outside the financial markets, however, customers had begun doing something that stock prices could scarcely capture. They were making their own software.

Some wanted to replace expensive subscriptions. Others were tired of squeezing their work into applications designed around somebody else’s habits.

With AI coding tools and existing open-source components, they could begin assembling applications around what they needed, however peculiar the requirements. An application serving five colleagues might be quite sufficient.

It didn’t need a market.

That is the change beneath the argument about The Death of SaaS: people are gaining the ability to decide how their software should work, rather than accepting those decisions as part of the price of admission.

In October, an ambitious attempt to recreate Adobe’s professional applications brought that change in expectations into public view.

1. Adobe and the Cost of Learning Someone Else’s Software

The developer behind ArtCraft began publishing seven open-source applications in Rust, with substantial AI assistance. Their targets were familiar: Photoshop, Illustrator, Premiere Pro, Lightroom, Acrobat, After Effects, and InDesign. The repositories were public, and other developers could inspect the code and contribute.

Under the Reddit announcement, somebody asked for another program.

“Now do AutoCAD.”

The developer responded with a link to CADCraft, an additional project already underway. [3]

It’s easy to understand the excitement. Adobe’s software has become part of the working environment of designers and photographers, much as Autodesk’s products have shaped established CAD workflows.

People spend years learning these systems. Training courses teach their interfaces, clients request particular file formats, and businesses accumulate work that becomes difficult to move elsewhere.

The subscription is often the most visible expense. The time already invested in learning the software is harder to calculate.

ArtCraft’s early applications, however, were a long way from matching the products they imitated. In an October 10 review, Steve Paris found that PhotoCraft couldn’t open his HEIC photographs and saved edited work only as JPG. FilmCraft struggled with basic trimming and produced unusable audio. [4]

These are understandable limitations for an early experimental project attempting software that large engineering teams have spent decades refining.

A hobbyist can afford to experiment with an unfinished editor; a professional has a client waiting for tomorrow’s revisions. Try explaining that the editable layers are gone, but hey, the toolbar looks just like Photoshop.

The distinction matters in practical work, where an application has to preserve what people create. A designer leaving Adobe may still need to exchange files with clients who haven’t left.

In a July 2025 Reddit discussion, a designer described moving their small company away from Adobe after nearly twenty years of professional use. The responses showed how much previous work and established production habits could complicate a transition, even when people were unhappy with the subscription. [5]

ArtCraft won’t make those dependencies disappear overnight. The developer’s description of the project as a clean-room recreation also remains a claim about the development approach rather than an independently established legal finding.

But there is something peculiar about the assumption that an alternative must reproduce the original product in its entirety.

A photographer may need a reliable RAW-processing workflow without the surrounding application ecosystem. A small business might require a handful of image operations performed consistently. Someone producing illustrations may care deeply about brush behavior while having no use for dozens of other features.

An application developed for a vast customer base necessarily contains decisions made for people whose work bears little resemblance to yours.

A faithful clone would inherit many of those choices, including the ones that were inconvenient in the first place.

We have spent so many years adjusting ourselves to the shape of software that changing the tool itself sounds almost unreasonable, although people who work with physical tools would recognize the impulse immediately.

2. The Hammer and the Way We Work

A carpenter can replace a worn hammer handle or choose a different weight for a particular job. Years of practice still matter, and the tool’s design has a considerable influence on the work. But modifying equipment to suit a particular task has always been part of the craft.

Computer applications trained us into another relationship.

We learned their terminology and remembered where their designers had placed the controls. A business might change its procedures because the software handled one sequence more conveniently than another.

Employees became proficient at navigating features they seldom needed while finding elaborate workarounds for the few that were missing.

Once everybody knew the procedure, the inconvenience became routine. Nobody wanted to disturb a system that had taken so long to learn.

In July 2026, a construction-business operator described this frustration in a Reddit discussion. They had tried Buildertrend, a commercial construction-management platform, and found it bloated and cumbersome for the way their company operated. Rather than return to a costly subscription, they had spent about a month intermittently developing their own management software.

The application was still taking shape. What they wanted from it was unmistakable:

“It works how our business runs instead of us trying to adapt to the way they think we should do things.” [6]

The parent Reddit post was removed, although the relevant comment remains visible.

That is the experience I find more revealing than an ambitious claim about replacing an entire software company. The construction operator already knew how their business ran. Their problem was finding software that respected those practices.

Other contributors in the discussion described similarly narrow approaches to construction administration, including scheduling through SMS so subcontractors could confirm appointments without adopting another application.

Consider what disappears from the usual software-selection process. The business no longer needs to evaluate hundreds of capabilities it never requested. It can start from the tasks employees actually perform and add functions as those tasks require them.

The resulting program could be unsuitable for almost every other construction company. Its owner has little reason to care.

The ambition here is surprisingly modest: to have the right tool for the work already being done.

And a great deal of the technical foundation for such tools has been available for years.

3. We Already Had the Building Materials

Open-source software had been expanding access to advanced technical capabilities long before the present AI boom. People often discuss these projects as inexpensive substitutes for commercial applications, overlooking the substantial engineering they contain and the professional work already produced with them.

The alternatives cover familiar software categories:

Microsoft 365 → LibreOffice / ONLYOFFICE. Document editing, spreadsheets, and presentations.
Autodesk Maya → Blender. 3D modeling, animation, rendering, and visual production.
AutoCAD / Fusion → FreeCAD. Parametric CAD and mechanical design.
Commercial antivirus suites → Windows Security / Bitdefender Free Free baseline malware protection.
TechSmith Snagit → ShareX/ OBS Studio. Screen capture, desktop recording, and workflow automation.
Wondershare UniConverter → HandBrake/ FFmpeg. Video conversion, compression, and media processing.
Adobe Premiere Pro / After Effects → DaVinci Resolve / Kdenlive Video editing and production tools.
Adobe Lightroom → darktable/ RawTherapee. RAW photography and image development.
Adobe Photoshop → GIMP/ Krita/ PhotoCraft Image editing and digital painting; PhotoCraft remains experimental.
Adobe Illustrator → Inkscape/ VectorCraft. Vector illustration and scalable graphics; VectorCraft remains experimental.

Some products in this list are free proprietary software rather than open source, and the applications vary in scope. They are alternatives for particular kinds of work, with different features and degrees of compatibility.

But consider Blender

The animated feature Flow, directed by Gints Zilbalodis, was produced using Blender and EEVEE.

The film won the Academy Award for Best Animated Feature in 2025. Zilbalodis, who had previously worked with Maya, described adopting Blender because its rendering workflow gave him the control and speed he wanted for his production. [7]

This is hardly an example of professionals settling for inadequate software because they couldn’t afford the real thing. The director chose a tool that suited the way he wanted to make a film.

FFmpeg provides a different illustration. Its media-processing capabilities can sit underneath a small application that handles a production team’s particular conversion requirements. The person constructing that application doesn’t need to develop a video codec. Much of the difficult engineering already exists.

AI coding assistants can help people create the surrounding application: a small interface, a sequence of processing steps, perhaps an integration with another tool used in the same workflow.

Open-source projects such as Screenshot-to-Code push the starting point even closer to the user by generating interface code from visual examples. A screenshot is only part of an application, but it can give someone an initial structure to modify. [8]

There is a long history behind this kind of customization. People built intricate applications in Excel, and platforms such as Airtable enabled teams to organize databases around their own activities well before AI coding assistants arrived.

What is expanding now is the range of changes people can attempt through natural-language interaction with code. They can start with components created by skilled developers and shape their own application around those foundations.

The benefit becomes especially clear when the intended audience is very small.

4. Software for One

In June 2026, a Reddit user asked which paid applications people had replaced by building their own with AI.

The replies brought that possibility down to the scale of everyday work. People had grown tired of accommodating software that never quite fitted their needs, and some had begun changing the tools themselves.

One reply described taking a screenshot of a Monday.com board and asking Bolt to build something similar. Within hours, the user reported having a working application they named Tuesday.

They subsequently tailored it to their team’s habits, including synchronization with a shared Google Calendar, and claimed savings of approximately $800 per month in Monday.com licenses. Those figures come from the user’s account rather than an independent audit. [9]

The name Tuesday has a kind of accidental charm. The user wasn’t trying to launch a rival to Monday.com. Their team needed a particular way to manage work, and the person building the application could decide which functions deserved attention.

Elsewhere in the same discussion, a user described making a budgeting application that relied on manually entered transactions. Another participant explained why manual entry could be desirable: recording expenses deliberately was part of how they kept track of their spending. An automatic bank import, usually treated as an obvious improvement, would remove part of the experience they valued. [9]

This is the sort of disagreement commercial software designers must routinely reconcile. A feature can make the application better for one customer while making it less suitable for another.

Software developed for a single person can accept peculiar requirements without taking a vote.

A further Reddit contributor described creating their own document-management system after a product they had used for fifteen years was discontinued following an acquisition. The purchaser was attempting to move customers onto a more expensive subscription service.

The user reported building an alternative that could work with a collection approaching 100,000 documents, despite having little recent programming experience. This remains a self-reported account, but the motive is hard to miss: they wanted to retain control over work that another company’s acquisition had disrupted. [9]

Similar cases have appeared outside developer communities. In January, TechCrunch reported on people making micro-apps for themselves and small groups.

Rebecca Yu created Where2Eat to help her friends choose restaurants. Other applications were built for household tasks and temporary needs that would never have justified a conventional commercial product. [10]

A conventional software company must consider market size. The owner of a personal application can ask whether the software serves the people who will actually use it.

That difference changes what counts as a successful product.

If a useful tool lasts six months and is then replaced because its owner’s requirements have changed, it may have fulfilled its purpose. If it contains only four features, those four can receive attention that a large general-purpose application would have distributed across far more capabilities.

More importantly, the user can participate in deciding how those features work.

Research into generative and malleable interfaces has begun exploring this relationship more formally. Yining Cao, Peiling Jiang, and Haijun Xia examined interfaces organized around task-driven data models, allowing users to modify generated applications through natural language and direct interaction. Their CHI 2025 work explores how applications can evolve alongside the requirements of the people using them. [11]

An application can therefore become something less fixed than the product delivered at the moment of purchase. Its structure can reflect the work as the work changes.

This experience can seem unfamiliar because professional software has been distributed through standardized applications for so long.

Historically, however, the movement of technical knowledge toward a wider population is hardly unprecedented.

5. Gutenberg, the Encyclopédie, and the Open Web

Around the middle of the fifteenth century, Johannes Gutenberg helped transform book production in Europe.

Printing with movable metal type was already known in Korea, as demonstrated by the surviving Jikji of 1377, but Gutenberg’s European printing system made the repeated production of books more efficient within its own historical environment.

The Gutenberg Bible, printed around 1454–1455, remains one of the defining artifacts of that change. [12][13]

Books still required literacy, and access was far from universal. Yet the economics of making and circulating written material had changed. Knowledge that depended heavily on laborious manuscript copying could now travel through a growing printing industry.

Three centuries later, Denis Diderot and Jean le Rond d’Alembert undertook another revealing project.

Published between 1751 and 1772, the Encyclopédie attempted to gather knowledge across the sciences and the mechanical arts. Its enormous collection of illustrations documented machinery and working processes in remarkable detail.

The University of Chicago’s ARTFL project records seventeen volumes of text and eleven volumes of plates in the original publication. [14]

The decision to document practical trades was particularly significant.

At the time, much technical knowledge belonged to the working traditions of individual craftspeople and workshops. Some manufacturing practices were guarded closely. Diderot wanted to put these processes into words and pictures so that people outside the original workshops could study them.

John R. Pannabecker’s historical research describes how the Encyclopédie helped shift the mechanical arts from knowledge embedded largely in working communities toward knowledge represented systematically in published materials. [15]

An engraving couldn’t make its reader a master craftsperson. There are forms of judgment that cannot be transferred completely through a diagram. But someone who had never entered a particular workshop could begin to understand machinery and production methods previously difficult to examine.

That is a striking antecedent to the open-source idea: useful technical knowledge becomes available for study beyond the people and institutions that originally developed it.

Then came the World Wide Web.

Tim Berners-Lee developed the Web at CERN beginning in 1989 to help researchers exchange information. On April 30, 1993, CERN released core Web software into the public domain. That decision made the basic technology available for others to use and improve without paying CERN for permission. [16]

The Web grew on the foundation of an internet that already existed, and its expansion depended on browsers and technical contributions from many organizations. CERN’s own history emphasizes how openly available software and accessible browsers helped the Web spread beyond its original scientific setting.

One detail is particularly relevant today: Berners-Lee’s original WorldWideWeb browser was also an editor. The early vision included the ability to create and change pages, even though most people eventually came to know the Web primarily as something they browsed. [16]

For ordinary users, the arrival of accessible publishing tools changed who could put information online. A person no longer needed to own a newspaper or a broadcasting network to publish something others could read.

There is a thread running through these episodes, though each belongs to a different technological world.

Printing altered the reproduction of written material. The Encyclopédie tried to bring practical technical knowledge beyond the workshops where it had accumulated. The open Web expanded opportunities to publish and exchange information across institutional boundaries.

The consequences extended well beyond the industries that created the original technologies.

AI-assisted software development is opening another part of that history. A person who understands a particular job can increasingly participate in making the software used to perform it.

The technical foundations are often already available through open-source projects. AI helps bridge some of the distance between understanding a problem and constructing a working tool.

The possibilities remain uneven. Some applications are easy to modify, while others embody extraordinary engineering complexity. A sophisticated CAD system cannot be conjured into professional reliability merely by reproducing its interface.

Yet people are gaining practical ways to influence software’s design without first becoming specialists in every underlying technology.

That changes the relationship between a person and the tools they depend on.

Final Thoughts — The Choice We Didn’t Have

The traditional software business was built around producing applications that large numbers of people could use. Standardization brought real benefits, but it also required customers to accept decisions made for a much wider population.

If a function was missing, users searched for another product or waited. If a workflow didn’t fit, they learned a workaround. Years of practice made those compromises familiar, while subscriptions kept access to the software tied to decisions made elsewhere.

Now people are beginning to make different choices. A construction operator is developing software around the way his company already works. A small team has built Tuesday because Monday.com carried more than it needed. Someone with years of documents has attempted to replace a system whose owner wanted to move them onto another subscription.

Meanwhile, open-source projects continue to make advanced technology available for reuse, and AI coding tools give more people a way to assemble that technology around their own requirements.

Services that genuinely help people will continue to find customers. A user can choose to pay for infrastructure or collaboration without surrendering every decision about the application that sits above them.

The part of SaaS losing its hold is the assumption that useful software must arrive as a standardized package whose structure the customer has little power to change.

That brings me back to the ArtCraft announcement.

“Now do AutoCAD.”

The request was for another familiar professional application. After reading the accounts of people making software for their own work, though, I wonder what that person actually needed AutoCAD to do.

Perhaps the answer wouldn’t require another enormous application. Perhaps it would require something smaller, built around the particular design problem sitting on their desk.

For a long time, that distinction hardly mattered. Most users had to choose among the applications somebody else was willing to build.

They are beginning to have a say in the tools themselves.

References

[1] Reuters, “Selloff wipes out nearly $1 trillion from software and services stocks as investors debate AI’s existential threat,” Reuters, February 4, 2026.

[2] Reuters, “US software stocks scale fresh 2026 highs as AI disruption worries fade,” Reuters, October 6, 2026.

[3] ArtCraft developer, “I’ve created Open Source 100% Rust clean-room replacements for 7 of Adobe’s apps,” Reddit, r/SaaS, October 2026.

[4] Steve Paris, “One dev is recreating 7 Adobe apps in Rust for free — so I tested it out,” TechRadar, October 10, 2026.

[5] r/graphic_design contributor, “Why I’m (we’re) leaving Adobe,” Reddit, r/graphic_design, July 2025.

[6] r/ClaudeAI commenter, “Construction-management discussion, including Buildertrend replacement,” Reddit, r/ClaudeAI, July 12, 2026. Parent post removed; relevant comment remains accessible.

[7] Francesco Siddi, “Making Flow — Interview with director Gints Zilbalodis,” Blender, January 22, 2025; updated to reflect subsequent awards.

[8] Abi Raja and contributors, “screenshot-to-code,” GitHub repository, accessed October 2026.

[9] r/ClaudeAI contributors, “What paid apps have you ditched by vibe coding a replacement?,” Reddit, r/ClaudeAI, June 2026 and subsequent comments.

[10] Dominic-Madori Davis, “The rise of ‘micro’ apps: non-developers are writing apps instead of buying them,” TechCrunch, January 16, 2026.

[11] Yining Cao, Peiling Jiang, and Haijun Xia, “Generative and Malleable User Interfaces with Generative and Evolving Task-Driven Data Model,” Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, Article 686, 2025.

[12] UNESCO, “Baegun hwasang chorok buljo jikji simche yojeol (vol. II),” Memory of the World Register, 2001.

[13] Library of Congress, “The Gutenberg Bible at the Library of Congress: Introduction,” Library of Congress Research Guide, undated.

[14] University of Chicago, “The ARTFL Encyclopédie,” ARTFL Encyclopédie Project, institutional digital edition.

[15] John R. Pannabecker, “Diderot, the Mechanical Arts, and the Encyclopédie: In Search of the Heritage of Technology Education,” Journal of Technology Education, 6(1), Fall 1994.

[16] CERN, “A Short History of the Web,” CERN institutional history, undated.

The AI Skills Race Is Missing the Real Problem: How Do We Prepare for Technologies That Keep Changing?

Sun, 04 Oct 2026 23:50:28 +0000

The conversation around AI skills is moving faster than most education and training systems can keep up with.

A new model appears.

A new interface changes how people work.

A new agent can complete tasks that previously required several separate tools.

A new workflow becomes normal.

Then another generation of technology arrives.

This creates an uncomfortable question:

What happens when the skills we are teaching people have a shorter lifespan than the programmes designed to teach them?

The problem is not that AI literacy is unimportant.

It is that AI literacy, by itself, may not be enough.

If the technology keeps changing, then the deeper capability is learning how to adapt when the tools, workflows and even professional roles keep changing with it.

The AI Skills Race

Organizations everywhere are trying to become “AI-ready.”

Employees are learning prompting.

Teams are experimenting with copilots.

Universities are introducing AI courses.

Professionals are learning automation, data analysis and generative AI workflows.

All of this makes sense.

But much of this training still assumes that the important question is:

Which AI tools should people learn?

That question has value, but it has a short shelf life.

The stronger question is:

What capabilities will continue to matter when the tools themselves change?

Tool Knowledge Is Not the Same as Adaptability

There is a difference between knowing how to use a tool and knowing how to respond when the environment around that tool changes.

A professional might become highly skilled in one AI platform.

But what happens when another platform replaces it?

What happens when AI agents begin completing entire workflows rather than individual tasks?

What happens when organizations redesign jobs around automation?

What happens when a role changes so much that the original job description no longer makes sense?

Tool proficiency helps people operate within a system.

Adaptability helps people navigate when the system itself changes.

The Half-Life of AI Skills Is Shrinking

In fast-changing technological environments, some skills become outdated quickly.

This does not mean they are useless.

It means they should not be treated as permanent.

The faster AI evolves, the more organizations need to distinguish between:

skills that help people use today’s technology
capabilities that help people adapt to tomorrow’s technology

The first category is still necessary.

The second may become more valuable.

From AI Literacy to Future Readiness

AI literacy usually focuses on understanding and using artificial intelligence effectively.

That includes knowing how to interact with AI systems, evaluate outputs, recognize limitations and use AI responsibly.

But future readiness requires another layer.

People also need to ask:

What happens if this technology becomes cheaper?
What happens if it becomes more autonomous?
What happens if regulation slows adoption?
What happens if trust becomes a bigger issue than capability?
What happens if AI changes entry-level jobs faster than universities redesign degrees?
What happens if entire workflows are automated?

These are not questions about tools.

They are questions about possible futures.

Why Futures Literacy Matters

Futures Literacy is not about predicting the future correctly.

It is about becoming more aware of the assumptions we make about the future and exploring alternative possibilities.

UNESCO’s work on Futures Literacy advances the idea that imagined futures influence the decisions we make in the present.

This matters because people make decisions based on assumptions about tomorrow all the time.

Students choose degrees because they imagine certain careers will remain valuable.

Companies invest because they expect particular markets to grow.

Universities design curricula based on expectations about future skills.

Governments build policies around assumptions about future economies and societies.

The problem begins when these assumptions become invisible.

We start treating one imagined future as inevitable.

Futures Literacy helps us question that.

Strategic Foresight Turns Uncertainty Into Action

Strategic Foresight takes this further.

It helps individuals and organizations explore multiple plausible futures and use them to make better decisions today.

Instead of asking:

What will happen?

Strategic Foresight asks:

What could happen?
What would cause different futures to emerge?
What signals should we watch?
What assumptions might fail?
Which capabilities would remain valuable across several scenarios?

That changes the role of AI strategy.

Instead of simply adopting tools, organizations begin preparing for different technological environments.

The Rise of Agentic AI Makes This More Important

The shift from conversational AI toward increasingly agentic systems makes this issue more urgent.

The difference is significant.

A chatbot helps with a task.

An agent may coordinate multiple tasks.

A more autonomous system may plan, execute, monitor and revise work with limited human intervention.

This means the future of AI is not only about better interfaces.

It may also involve the redesign of workflows, decision rights, management structures and professional responsibilities.

A person who knows how to prompt a chatbot may still be unprepared for an organization in which AI agents participate in complex work processes.

That is why future readiness must go beyond interface-level skills.

The Real Question for the Future of Work

The future-of-work debate often becomes too narrow.

People ask:

Which jobs will disappear?

Which jobs will survive?

Which professions are safe?

But work rarely changes in such a simple way.

Jobs are bundles of tasks.

AI may automate some tasks, augment others and create entirely new ones.

The deeper question is:

How will work be reorganized?

That requires us to look at technology together with:

organizational design
regulation
education
labour markets
culture
infrastructure
trust
demographics
human behaviour

Technology does not operate in isolation.

Different societies may therefore experience very different AI futures.

There Will Not Be One Future of Work

The future experienced by a software engineer in San Francisco may not be the same as the future experienced by a teacher in Karachi.

The future of a healthcare worker in Nairobi may differ from the future of an accountant in London.

The future of a small business owner in Lahore may differ from that of a multinational executive in Singapore.

This is why global AI narratives need local interpretation.

Every region needs to ask:

What does AI mean in our own institutional, economic, educational and social context?

A More Durable Capability Stack

Instead of treating AI literacy as the final goal, I believe we need a broader capability stack.

1. AI Literacy

Understand what AI systems can do and how to use them effectively.

2. Critical AI Literacy

Question outputs, assumptions, biases, limitations and claims.

3. Responsible AI Literacy

Understand ethics, accountability, governance, privacy and social consequences.

4. Human Capabilities

Develop creativity, empathy, judgement, communication and collaboration.

5. Learning Agility

Build the ability to learn, unlearn and relearn repeatedly.

6. Futures Literacy

Recognize assumptions about the future and explore alternatives.

7. Strategic Foresight

Translate uncertainty into scenarios, choices, experiments and action.

The objective is not to make everyone a professional futurist.

The objective is to make future-conscious thinking a normal part of professional life.

What This Means for Universities

Universities face a structural challenge.

Curricula move slowly.

Technology moves quickly.

If universities respond to every technological change by adding a course on the latest tool, they may always remain one step behind.

A better approach is to combine AI education with future-oriented learning.

Students can learn how to use AI tools.

But they can also learn how to scan for emerging signals.

They can explore alternative scenarios for their professions.

They can question assumptions about careers.

They can examine how technology interacts with ethics, institutions and society.

They can learn how to make decisions under uncertainty.

This prepares them not only for today’s tools, but for tomorrow’s changes.

What This Means for Organizations

Organizations face the same problem.

Many are currently asking:

How do we adopt AI?

A stronger question is:

What different operating environments could AI create for us?

Imagine three futures.

In the first, AI mainly augments employees.

In the second, autonomous systems perform large parts of knowledge work.

In the third, regulation, trust concerns or institutional resistance significantly slow adoption.

Would your organization succeed in all three?

Which capabilities would remain useful?

Which investments are robust?

Which assumptions are most fragile?

What experiments should you run now?

This is where foresight becomes practical rather than theoretical.

AI-Ready Is Not the Same as Future-Ready

An AI-ready organization can use today’s technology.

A future-ready organization can adapt when today’s technology becomes outdated.

That distinction matters.

Because the competitive advantage may not come from adopting every new tool first.

It may come from building an organization capable of learning faster than its environment changes.

The Skill We Are Not Teaching Enough

Much of AI education focuses on capability.

How do I use this system?

How do I automate this task?

How do I write a better prompt?

Those are useful questions.

But another question deserves equal attention:

What happens when this changes?

That question opens the door to foresight.

It turns technical training into strategic learning.

The Future Will Keep Moving

AI will keep evolving.

The current models will not be the final models.

The current interfaces will not be the final interfaces.

The current workflows will not be permanent.

And many current job descriptions may not remain intact.

This does not make AI literacy less important.

It makes it incomplete.

The people and institutions best prepared for the AI age will not simply be those who master the latest tools.

They will be those who can keep learning, question assumptions, explore alternative futures and make intelligent decisions under uncertainty.

In a world where the tools keep changing, the most durable skill may be the ability to navigate what comes next.

About the Author

Dr Salman Ahmed Khatani is an Associate Professor, futurist and researcher working at the intersection of Strategic Foresight, Futures Literacy, Responsible AI, the Future of Work and future-ready education.

He is the Founder of Fiker Futures Academy and author of Designing Tomorrow.

Further reading

Pakistan 2035: Why We Need Futures Literacy Before the Future Arrives

Beyond AI Literacy: Why Strategic Foresight Is the Missing Capability for the AI Age

Originally published on Futures, AI & Strategic Foresight.

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.

Everyone Can Build Software Now. Who’s Making Sure It Works?

Wed, 02 Sep 2026 11:08:14 +0000

Something interesting is happening in software right now. Building things is getting easier, faster, and more accessible than ever. With AI and a growing number of tools, you can have an idea in the morning and a working prototype by the afternoon.

And there’s a tool for almost everything now. Design, writing, research, coding, automation you name it.

Honestly, we love it.

The best tools don’t make you feel like you’re doing less. They take the repetitive work off your plate so you can focus on what actually needs you.

Which got us thinking: if everyone is getting better tools to build software, why shouldn’t testers get better tools too?

Building software is getting easier. Testing it isn’t.

AI can help you create an application incredibly quickly. But creating something and knowing that it actually works are two very different things.

Real users don’t follow the happy path. They refresh, double-click, leave halfway through, enter unexpected data, open another tab and somehow find the one thing nobody thought to test.

That’s why QA still matters.

But testing isn’t just about running test cases. There’s test data, environments, execution, reruns, failures, history, debugging and all the little things teams have to keep track of between one release and the next.

And then comes that familiar moment before a release:

“Are we good to ship?”

You might have spent five hours testing, but answering that question can still mean checking multiple places, digging through previous runs or asking someone what happened last time.

The testing happened. The problem is everything around it.

Automation helps. But it doesn’t solve everything.

Automation can take care of repetitive execution, run tests consistently and give teams faster feedback. That’s a huge win.

But no automation is perfect. Some scenarios need human judgment. Some failures need investigation. Some tests simply aren’t worth automating.

And that’s okay.

The goal shouldn’t be to automate everything. It should be to make the entire testing process easier.

That’s where QAlity comes in.

We started thinking about the QA problems that technology could simply take off a tester’s plate.

Why should testers have to remember what happened during previous executions? Why should understanding a test’s history require digging through different places? Why should so much time go into managing testing instead of actually testing?

So we built QAlity around a simple idea:

Let automation do the repetitive work. Let testers focus on the work that needs them.

Not to replace testers. Not to claim that every test should be automated.

Just to give QA the kind of leverage that almost every other part of software development is starting to get.

Because everyone is becoming a developer. Maybe it’s time to become a tester too.

AI has made building software accessible to people who may never have considered themselves developers.

And as more people build software, more software will need to be tested.

You don’t need everyone to become a QA engineer. But you do need people to start thinking beyond

“Does it work?”

Ask what happens when it doesn’t.

That’s where good testing begins.

The future isn’t manual versus automation. It’s people and technology doing what each does best.

We’re building QAlity for that future so testers can spend less time managing the process and more time doing what actually matters.

Because building software is getting easier every day.

Making sure it works should be getting easier too.

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

Stop Waiting for Permission to Use AI

Mon, 29 Jun 2026 18:22:17 +0000

A recent survey from ResumeNow found that 41% of workers say their employer gives them zero guidance on using AI. Only 19% say they got real training, with dedicated time and resources behind it. Nearly a third say they got no training at all.

Meanwhile, the same companies are telling employees to "use AI more." That's like handing someone a new car with no keys and asking why they're not driving it.

Here's the thing. You don't need your employer's permission to start learning. You don't need a training program, a budget line, or a kickoff meeting. You need a few minutes of curiosity and a willingness to play around.

I started using AI for personal projects back in November 2021. Not because anyone at work told me to. I was just curious. Four and a half years later, AI touches almost everything I do, at home and at work. And the path that got me there didn't start with a business problem. It started with fun.

The $100 Vegas Challenge

A few years ago, I gave myself a simple goal: make $100 last as long as possible at video poker in Las Vegas. Instead of guessing at strategy, I used Claude to run real-time statistical analysis on the hands I was playing. Four or five hours later, I'd learned more about probability, pattern recognition, and decision-making under uncertainty than I'd expected from a casino floor -- and I still had some of my $100.

That's not a business case study. It's just a guy having fun with a new tool. But the skill underneath it, using AI to make sense of data in real time, is exactly what shows up later in enterprise work.

The 45-Page Manual

Another time, my wife had just bought a food steamer with a manual that ran 45 pages. She wanted me to help her cook a roast. Instead of reading the whole thing, I had AI break it down into the steps that actually mattered for what she was making. My wife was pleased with the outcome. More importantly, I walked away with a clear example of something AI does well: take something dense and confusing and turn it into something usable.

That's the same skill that matters when you're trying to explain a technical process to a non-technical audience, or when you're untangling a vendor's documentation for your team.

Why Personal Use Comes First

Personal experiments work because the stakes are low. If you ask AI for help with a recipe and it gets something wrong, nobody's job is on the line. That low-risk environment is exactly where you build the instincts you'll need later: how to phrase a request, how to spot a wrong answer, how much context the AI actually needs before it can help you.

I call this giving AI context, not just typing a question and hoping for the best. The more clearly you describe what you're trying to do and who it's for, the better the result. That's true whether you're asking for poker strategy or asking for a content plan for a Fortune 500 client.

Once you've built that instinct on your own time, it transfers. I've used the same approach to help simplify a six-petabyte intranet migration, redesign chatbot conversation flows for a healthcare client, and support a retail bank's effort to cut a 20-minute manual review down to about a minute with an AI agent. None of that started with a strategy deck. It started with a willingness to experiment somewhere low-stakes first.

A Realistic Way to Start

You don't need a six-week roadmap. You need a sequence that looks something like this:

Week 1: Try AI on something personal. A hobby, a household project, a question you'd normally Google.

Weeks 2-3: Bring one small work task to it. Something low-risk, where a wrong answer doesn't cost much.

Weeks 4-6: Apply what's working to a bigger project, once you trust your own judgment about when AI helps and when it doesn't.

Week 7 and beyond: Share what you've learned with your team. This is where individual habits start becoming team capability.

That progression matters more than any formal training program, because it builds judgment, not just familiarity with a tool. A training session can show you what buttons to click. It can't teach you when to trust the output and when to push back on it. Only practice does that.

The Real Gap

Companies asking employees to "use AI more" without giving them time or guidance to learn are setting people up to improvise. Improvising isn't a strategy. But individuals don't have to wait for their employer to fix that gap. You can close it yourself, starting with something as low-stakes as a video poker session or a recipe you're trying to get right.

So here's the actual question worth asking: what's your first AI adventure going to be? It doesn't need to be impressive. It just needs to be yours.

Your Next Direct Report Might Be an Agent

Mon, 15 Jun 2026 13:00:00 +0000

Not metaphorically. Not eventually. Right now, in some organizations, managers are already responsible for agents the way they're responsible for people — assigning work, reviewing output, correcting errors, and deciding when to escalate.

That shift is happening faster than most job descriptions have caught up to. And it raises questions worth thinking through before you find yourself managing an agent without a framework for doing it.

What It Actually Means to Manage an Agent

Managing a human direct report involves a predictable set of responsibilities. You set expectations. You review work. You give feedback. You decide what they should handle independently and what needs your input. You hold them accountable for outcomes.

Managing an agent involves the same responsibilities — with a few important differences.

Feedback doesn't work the same way. You can't have a conversation with an agent about why its output missed the mark. You adjust its instructions, its scope, or its inputs. The correction mechanism is configuration, not coaching.

Accountability is also different. When an agent makes a mistake, the accountability doesn't sit with the agent. It sits with whoever deployed it, scoped it, and let it run. That's you.

And unlike a human employee who can recognize when a situation is outside their experience and ask for help, an agent will keep going until its scope runs out or someone catches it. The boundaries you set are the only guardrails it has.

The Skills That Transfer — and the Ones That Don't

Most of what makes someone a good manager of people transfers directly to managing agents. Clear communication. Defined expectations. Regular review of output. Knowing when to intervene.

What doesn't transfer cleanly is intuition. A manager with ten years of experience has developed instincts for when something feels off — a team member who seems disengaged, a project that's quietly going sideways. That instinct comes from reading signals that agents don't send.

With agents, you replace intuition with instrumentation. You build in monitoring. You set thresholds. You review logs rather than reading the room. The information is there — it just looks different than what you're used to.

The managers adapting fastest are the ones who recognize this shift early. They stop waiting to feel like something is wrong and start building systems to tell them.

The Organizational Question Nobody Is Asking Yet

Here's the question most organizations haven't gotten to: when an agent is doing the work of a human role, who manages it, and where does that responsibility live on an org chart?

Right now, the answer is usually whoever built the agent, or whoever owns the system it runs in. That's a fine answer for a pilot. It doesn't hold up at scale.

As agents take on more responsibility — handling customer interactions, processing approvals, managing workflows — the question of ownership becomes a governance question. Who reviews agent performance? Who authorizes changes to scope? Who gets called when something goes wrong at 2 a.m.?

These aren't technology decisions. They're organizational design decisions. And the organizations that make them deliberately, before they're forced to, will be in a better position than the ones that figure it out reactively.

What This Means for Developers and Engineers

If you're building the agents, you're already closer to this reality than most. You've seen what agents can and can't do. You know where the edges are.

That puts you in a useful position — not just as the person who builds the system, but as someone who can help the business think clearly about what managing it actually requires. The organizations getting this right tend to have engineers who stay engaged after deployment, not just during build.

The feedback loop between "how it was built" and "how it's being managed" is where most production problems get caught early. That loop only works if the people who built it are still in the conversation.

The Bigger Picture

The idea of a direct report who doesn't sleep, doesn't have bad days, and can handle hundreds of transactions simultaneously sounds appealing in the abstract. In practice, it comes with real management overhead — just different overhead than you're used to.

The managers who thrive in this environment won't be the ones who treat agents like software. They'll be the ones who bring the same discipline to managing agents that they bring to managing people: clear expectations, consistent review, and genuine accountability for outcomes.

That's not a new skill. It's an existing skill applied to a new kind of team member.

Future Jobs Won’t Ask “What Do You Know?” They’ll Ask “What Can You Build?”

Sat, 23 May 2026 09:28:29 +0000

Future Jobs Won’t Ask “What Do You Know?”

They’ll Ask “What Can You Build?”

For a long time, the system was very simple.

Study hard.
Get good marks.
Complete your degree.
Apply for jobs.
Get hired.

For years, this was the standard formula people followed.

And honestly...

It worked.

Because knowledge was limited.

If you knew something others didn’t know, you had an advantage.

But today, the world looks completely different.

Now information is everywhere.

Need to learn coding?

YouTube is there.

Need help with a problem?

AI can explain it.

Need a course?

Thousands are available online.

Today, almost everyone has access to information.

And that changes everything.

Because companies are slowly realizing something important:

Knowing information is no longer enough.

Because information is available to everyone.

The bigger question is now:

Can you use what you know?

Can you create something useful?

Can you solve real-world problems?

Can you take an idea and turn it into reality?

Let's think about a simple example.

Two people join the same course.

Both complete the course.

Both receive certificates.

But after six months...

Person A says:

"I completed the course."

Uploads the certificate.

Updates LinkedIn.

And moves on.

Person B says:

"I built a project using what I learned."

Maybe a website.

Maybe an app.

Maybe an AI tool.

Maybe a solution for a real problem.

Now tell me honestly...

Who stands out more?

The answer is obvious.

Because future opportunities may not come to people who only collect knowledge.

They may come to people who show proof of work.

People who create.

People who build.

People who execute.

That’s why projects, portfolios, problem-solving, and practical skills are becoming more valuable every year.

Learning is still important.

Very important.

But learning alone is not enough anymore.

The future belongs to people who don't just consume information...

They use it.

They experiment with it.

And most importantly...

They build with it.

Learn.

Build.

Share.

Because the future may not ask:

"What do you know?"

It may ask:

"What can you actually build?"

What skill would you build for your future?

FutureOfWork #CareerGrowth #AI #Tech #Learning #Skills #Innovation #FutureSkills #LinkedInCommunity

The Meeting Nobody Could Follow -The format of AI output is a design decision.

Tue, 19 May 2026 06:58:44 +0000

Our team runs fast. Everyone uses AI — for code review, architecture decisions, issue triage, sprint planning. The individual work is solid. The outputs are good.

The problem shows up in the meeting.

Someone opens a PR and shares the AI-generated action plan in the standup. It is a .md file, 200+ lines, logically structured, accurate. The engineer who ran it knows exactly what is in it.

The two people looking at it for the first time are scrolling, skimming, trying to locate what matters while the conversation moves on.

Our lead eventually just asked:

“Can you highlight what’s actually blocking us right now?”

That was not a knowledge gap. Everyone in the room was technical. It was not a preparation gap either — the work had been done well.

The gap was between the person who had been living in that context and everyone else trying to enter it in 90 seconds from a flat text file.

That is a format problem.

And it compounds every time AI-generated work crosses from one person’s context into a shared one.

The Post That Reframed It

On May 8, 2026, Thariq Shihipar, an engineer on the Claude Code team at Anthropic, posted nine words on X:

“HTML is the new markdown. I’ve stopped writing markdown files for almost everything and switched to using Claude Code to generate HTML for me. This is why.”

The post linked to a companion site: 20 self-contained .html files, each one an agent-generated artifact covering a different category of engineering work.

No build step.
No framework.
Just a file you open in a browser.

The line that stopped us was from Thariq’s framing of the Code Review category:

“Diffs and call-graphs are spatial information; markdown flattens them.”

That was the exact problem we’d been circling for weeks without naming it. Our action plans weren’t hard to read because they were long.

They were hard to read because the information inside them was spatial — priority relationships, status changes, size deltas, dependency chains — and we were delivering it as a flat sequence of text.

Simon Willison, whose writing on developer tooling is widely followed, read the piece the same day and wrote that it caused him to reconsider his three-year default of asking for everything in Markdown.(3)

His note: Markdown won because of constraints — the 8,192-token GPT-4 era, where every character counted. Those constraints are largely gone. The reasoning that locked in the default hasn’t been re-examined.

That evening, we ran our own action plan through Claude with one change:

“Output this as a standalone HTML file with priority-coded sections, status badges, and a visual summary header.”

Thirty minutes of iteration.

The document we’d been failing to share effectively for weeks was suddenly something a new set of eyes could navigate in under a minute.

Why This Works: Source for Machines, Interface for People

Before going further, the actual rule is worth stating clearly, because the headline “HTML is the new markdown” gets misread.

This isn’t about replacing Markdown everywhere.

README files, commit notes, audit logs, agent-to-agent context passing — Markdown stays. It’s compact, diffable, searchable, and parseable without a browser. Those are real advantages that don’t disappear.

The shift is narrower: when AI-generated work reaches a human who needs to review, navigate, and act on it, Markdown hands the translation cost to the reader. HTML absorbs it into the document.

Karpathy replied to Thariq’s post with a practical note:

“This works really well btw — at the end of your query ask your LLM to ‘structure your response as HTML’, then view the generated file in your browser.”

He added the underlying reason: roughly a third of the human brain is dedicated to visual processing — the 10-lane superhighway of information into the brain. Audio is the preferred input to AI. Vision is the preferred output from it.

That is why the format question matters beyond aesthetics. If AI output is increasingly something people have to review, navigate, and act on quickly, then the container is no longer a neutral wrapper.

A February 2026 Harvard Business Review study tracked 200 employees at a U.S. tech company over eight months and found that AI adoption intensified work rather than reducing it — 83% reported it increased their workload. (5)

The study doesn’t prove a format problem by itself. What it describes is the broader environment in which format problems become expensive: workers moving faster, taking on broader scope, with less time per handoff.

In that environment, a document format that requires translation before action isn’t a minor inconvenience. It’s a recurring tax.

The 20 Examples: A Map Worth Keeping

So what does a better container look like in practice?

Thariq’s companion site at thariqs.github.io/html-effectiveness is worth opening in a separate tab.

It’s not a gallery — it’s a structured argument across 9 categories, each one showing where Markdown flattens information that HTML can spatialize.

Here’s the full map for reference. Skim it — it’s a map, not a reading list. The three categories that actually changed our workflow are below the table.

#	Category	What HTML replaces	Examples
01	Exploration & Planning	Sequential walls of text you try to hold in memory	Three code approaches side-by-side · Visual design directions rendered live · Implementation plan with timeline and risk table
02	Code Review	Flat diff output, call-graph prose	Annotated PR with margin notes and severity tags · PR writeup with file-by-file tour · Module map as boxes and arrows
03	Design	Token/component descriptions	Living design system with swatches · Component variants on a single sheet
04	Prototyping	Prose descriptions of motion and interaction	Animation sandbox with easing sliders · Clickable flow across four screens
05	Diagrams	Text-based flowcharts	SVG figure sheet · Annotated flowchart — click any step to see timings and failure paths
06	Decks	PowerPoint export, PDF	Arrow-key slide deck — one HTML file, no build step
07	Research & Learning	Linear explainer dumps	Feature explainer with collapsible steps and tabbed config · Concept explainer with live interactive ring
08	Reports	Weekly status emails, post-mortem docs	Weekly status with a small chart · Incident timeline with minute-by-minute breakdown
09	Custom Editors	Text-box instructions for spatial decisions	Ticket triage board · Feature flag editor with dependency warnings · Prompt tuner with live re-render

Code Review (02).
The annotated PR demo made the problem undeniable. Our action plans were spatial data — P0 vs P1 vs P2, open vs fixed, size deltas — delivered as a flat sequence. Moving to HTML turned priority into visual hierarchy, status into badges, and growth from 163 to 212 lines into an amber callout. The reviewer’s eye went to the right place without being guided there by more text.

Decks (06).
A handful of <section> tags and a little JavaScript becomes a slide deck you can arrow-key through in a meeting. No Keynote. No export. The charts can stay live, the regional breakdown can be filterable, and the presenter stops defending the format and starts defending the idea.

Custom Editors (09).
This is the category most people miss. It isn’t about pretty reports. It’s about asking for a throwaway interface for one specific decision — triaging tickets, toggling feature flags, tuning a prompt template — then exporting the result as structured Markdown for the next agent call. The loop gets tighter.

How We Applied It in Practice

The next step was turning the rule into a workflow.

We didn’t replace Markdown. We added an HTML render layer on top of it.

Every agent run now produces two files. The raw .md stays for version control, diffs, and agent context — passing HTML between agents adds token cost without value. The HTML is what the team opens.

The status bar at the top shows Open / Fixed / Partial counts at a glance. P0 items have a red left border and a pulse. Fixed items are muted. A function that grew from 163 to 212 lines shows the delta in an amber callout — visible without reading the note. The filter bar lets anyone drill to just the P0 items in one click.

Below is the representative example we use. Content has been generalized — no internal identifiers — but the structure, priority system, and status logic are exactly what’s in production.

PR Action Plan Dashboard

Same information. Different container.

One standup dropped from 25 minutes to 12. The questions changed from “wait, which ones are actually blocking?” to “who’s taking P0–1a?”

Beyond the PR: Every Document That Has to Survive a Room

The dev PR use case is where we started. It’s not where this ends.

Think about the last time you sat through a presentation built in PowerPoint. Someone had spent hours on slides, exported a PDF, shared it over email. Half the room opened it on their phones and couldn’t read the charts. The presenter spent the first three minutes explaining the color coding. Someone asked about a specific number and the answer was “I’ll have to check the spreadsheet.”

That’s the same problem. Spatial information delivered as a fixed object, forcing everyone in the room to translate before they can respond.

A quarterly review as a single HTML file looks different. The slides are still there — arrow-key navigation, no build step. But the charts are live. Each person hovers over the number they care about.

The regional breakdown is filterable. A response field at the bottom lets stakeholders flag a concern or submit a priority vote before leaving the page. That input comes back as structured data the next agent call can act on. The meeting doesn’t end with action items in someone’s notebook. It ends with a file.

This is what “sending a document” becomes when the format is HTML. A PDF is a fixed object. An HTML file is an environment. The person receiving it navigates it on their own terms — without matching your reading pace, your zoom level, or your familiarity with the data. And if you’ve built in the export button, what they do inside it comes back to you.

The pattern holds wherever AI-generated work has to cross a context boundary. A business proposal needing sign-off from people who weren’t in the original conversation. A research summary that has to land with someone from a different discipline.

A vendor comparison that three stakeholders need to filter differently. In each case, the question is the same: does the format help the next person enter the work, or does it make them translate it first?

The Tradeoff, Honestly

Every format shift moves cost somewhere. HTML is no exception.

HTML costs more to generate. For a document the size of our action plan, the HTML version runs approximately 4,200 tokens. The equivalent Markdown is around 1,150. That’s a 3.6× multiplier on output tokens.

At Claude Sonnet pricing as of May 2026, the delta is roughly $0.009 per document. At 100 documents per day, that’s about $0.90 extra per day — real, but not significant for most teams.

The more useful frame: one missed P0 finding costs more than a month of that overhead. The token cost is the price of a format that gets reviewed properly instead of skimmed and hoped at.

But token cost is only the first tradeoff.

Three rules keep the format honest.

Rule 1: HTML is for human review, not machine handoff.
HTML is not a good input for agent-to-agent pipelines. Keep Markdown for source, diffs, archives, and machine context. HTML earns its cost only at the human review surface.
Rule 2: visual authority is not factual authority.
A red P0 badge doesn’t mean the agent got the priority right. A well-structured HTML artifact can make a wrong AI output look more credible than a flat Markdown file would. Faster comprehension helps — it doesn’t replace judgment. The render layer should make review faster, not make the model more trusted.
Rule 3: interactivity needs a safety contract.
A useful HTML artifact should be self-contained, with no remote scripts, so it works offline and doesn’t phone home. It should use text labels alongside color and hover states, so it still works for color-blind readers and keyboard-only users. And if it re-enters an agent loop, it should run sandboxed, without external network access.

None of these are hard to ask for in the prompt. They’re worth adding to your template.

The Prompt Change

You do not need new tooling. One line at the end of your existing prompt.

Instead of:

“Generate a PR action plan covering all open issues by priority.”

Try:

“Generate a PR action plan covering all open issues by priority. Output as a standalone HTML file: color-coded priority badges (P0=red, P1=amber, P2=yellow), status indicators (OPEN/FIXED/PARTIAL), delta callouts for size changes, and a summary header with open and fixed counts.”

For code review, Thariq’s own prompt is worth borrowing directly:

“Help me review this PR by creating an HTML artifact that describes it. Render the actual diff with inline margin annotations, color-code findings by severity and whatever else might be needed to convey the concept well.”

The harder shift isn’t the prompt. It’s recognizing that the format of AI output is a design decision. We used Markdown for three years because that’s what the GPT-4 era trained us to expect. The models have moved. The context windows have moved. The use cases have moved.

The next bottleneck isn’t what the agent can generate. It’s whether the next person can enter it fast enough to act.

References

Thariq Shihipar, “The Unreasonable Effectiveness of HTML” — original X post, May 8, 2026
Companion examples site — 20 self-contained HTML artifacts across 9 categories
Simon Willison, link post and notes — May 8, 2026
Andrej Karpathy, reply to Thariq’s post — visual processing argument
Ranganathan & Ye, “AI Doesn’t Reduce Work, It Intensifies It” — Harvard Business Review, February 2026

The Sovereign Cortex: Corporate-Grade AI for Independent Thinkers

Sun, 03 May 2026 21:05:44 +0000

How ANDARTIS puts the power of a server cluster directly onto your laptop.

We are drowning in a sea of rented cognition. A psychologist analyzing decades of patient trauma, or a doctor researching trends across hundreds of clinical diagnoses, cannot simply paste their files into a cloud LLM. To do so is not just a battle against token limits—it is a catastrophic privacy infringement.

The industry tells us that the only safe way to reason with 10,000 private documents is to buy massive enterprise servers and run corporate RAG (Retrieval-Augmented Generation) clusters behind a firewall. They tell us that hallucinations are the cost of "fluidity," and that true intelligence requires a data center.

They are wrong.

ANDARTIS is the counter-narrative. It puts the power of a corporate AI cluster directly onto the laptops of independent thinkers. It is a local-first, domain-agnostic framework designed not to rent intelligence, but to forge it directly on your machine. It is the crystallization of a new paradigm: the Grounded Agent.

The Illusion of the Generalist

A massive Large Language Model (LLM) is a beautiful generalist. It can write a sonnet or explain quantum physics. But ask it to precisely cross-reference 5,000 patient records or extract the nuanced jurisdictional logic from 10 years of legal filings, and it will hallucinate, truncate, or simply refuse.

The architecture of ANDARTIS rejects the "one model to rule them all" philosophy. Instead, it introduces a symbiotic ecosystem: The Intelligent Senses and The Reasoning Loom.

1. The Intelligent Senses (Micro-Extraction)

At the edge of ANDARTIS sits the Global Extraction Head—a highly specialized, 150M-parameter Causal Decoder. It doesn't "think"; it resonates. Trained via Semantic Echo technology, it acts as a structural scavenger, mapping unstructured chaos into rigid SQLite databases in milliseconds.

For the everyday user, this is magic out of the box. Drop a folder of documents, apply a "Lens" (a simple list of desired metadata keys like Patient Name, Diagnosis, or Verdict), and watch as the noise is instantly distilled into a high-fidelity structural map.

But for the independent thinker—the Private Detective connecting clues across scattered evidence, the Psychologist synthesizing years of encrypted session notes, the rogue researcher—this is just the beginning.

Because ANDARTIS relies on highly efficient micro-architectures that exploit Apple's AMX coprocessors, text is only the first frontier. The same pipeline that maps clinical records today is designed to ingest images, handwritten notes, invoices, and even raw audio recordings tomorrow. It is a multimodal nervous system built for those who operate outside the traditional corporate grid. Rebel tools for rebels.

2. The Architect's Forge

ANDARTIS provides a "Developer Door" allowing the wise to forge their own perception. By feeding diverse datasets (.jsonl, .csv, raw markdown), experts can use the local Mistral SLM as a "Teacher" to distill new semantic patterns into the Extraction Head.

You aren't just adjusting a prompt; you are reshaping the neural pathways of the ingestion engine to understand the specific dialect of your hospital, your law firm, or your laboratory.

3. The Reasoning Loom (Grounded Synthesis)

Once the extraction is complete, the Senior Analyst (a highly quantized Mistral SLM) wakes up. But it does not read documents. It reads the map.

When you ask ANDARTIS a question, it doesn't guess. The Intent Blade parses your query, deploys silent micro-models to fetch raw, structured JSON from the SQLite core, and hands that absolute truth back to the SLM. The SLM then weaves those numbers, lists, and facts into a fluid, Claude-like response.

Zero Hallucination. Total Fluidity.

Scaling the Unscalable: Map-Reduce on Apple Silicon

How do you ask an AI to "List all patients prescribed Aspirin in 2024" across 10,000 files without hitting a token limit?

You don't send the files. You send the SQL.

When ANDARTIS detects a massive-scale request, the Intent Blade generates a dynamic SQLite query utilizing json_extract. The PHP orchestration layer executes this query against the local database in sub-milliseconds, gathering thousands of raw data points. Only the results are sent to the SLM for final, elegant synthesis.

It is the speed of a relational database wrapped in the conversational grace of a modern AI.

The Sovereign Future

ANDARTIS is currently preparing specialized "Global Heads" for the Legal, Medical, and Research sectors. These heads will ship pre-forged with thousands of domain-specific semantic prototypes, ready to organize your life's work instantly, entirely offline, with zero subscription fees.

This is not a launch. This is a manifesto.

Intelligence should not be a utility you pay for by the token, nor should privacy be a luxury reserved for massive corporations with server racks. ANDARTIS operates in full rebel mode because it puts the analytical power of a corporate AI cluster directly onto your laptop. It is a capability you forge, a tool you tune with Lenses for each specific group of documents, and a nervous system you own completely.

The future of AI is not in the cloud. It is on your desk.

Forge the wisdom. Distill the speed. Keep it local.

The AI Talent Shift: Why Shipping Intelligence Matters More Than Building Models in 2026

Fri, 03 Apr 2026 21:52:30 +0000

✍️ Article

If you still think AI/ML engineering is about building models, you’re already behind.

The industry has quietly shifted.

The real demand today is not for people who can train models — it’s for engineers who can ship intelligence into production reliably, repeatedly, and at scale.

What Actually Changed (And Most People Missed)

A year ago, “build a model” was impressive.

Today, that’s the easy part.

What matters now is execution:

Can it handle real-world messy data?
Can it scale to millions of users?
Can it stay reliable under edge cases?
Can it deliver measurable business impact?
AI is no longer a research problem. It’s a production engineering problem.

⚙️ The New AI/ML Engineer = Hybrid Builder

The engineers getting hired globally today are not just ML-focused.

They operate at the intersection of:

ML + Backend Systems
Data Pipelines + Distributed Systems
LLMs + Product Thinking
AI + Cost Optimization
They don’t just ask: “Which model is best?”

They ask: “What’s the most efficient, scalable, and production-ready solution?”

From working with global teams and observing hiring patterns, one thing is clear:
They don’t care about:

10 certificates
Fancy model names
Theoretical knowledge
They care about real impact:

✅ Production Experience

Have you deployed real AI systems? Can you monitor, debug, and improve them?

✅ System Thinking

Can you design end-to-end architecture? APIs, pipelines, latency, caching, scaling?

✅ Business Impact

Did your work increase revenue, reduce cost, or improve user experience?

✅ AI + Practical Engineering

Can you use LLMs, not just build models? Prompting, fine-tuning, evaluation, guardrails?

⚡ The Rise of “Applied AI Engineers”
A new category is emerging:

Applied AI Engineers

These are not researchers.

They:

Integrate APIs like GPT, Claude, and open-source LLMs
Build AI-powered features into real products
Focus on speed, iteration, and ROI
This is where most real-world hiring is happening right now.

The Skill Gap (And Opportunity)

Here’s the truth:

Thousands are learning AI. Very few can deliver production-grade AI systems.

That gap is your opportunity.

If you can combine:

Strong engineering fundamentals
Practical AI/ML usage
System design thinking
You’re not just another candidate — you’re a problem-solver companies will pay a premium for.

What Most Engineers Are Doing Wrong

hasing every new model release
Building toy projects
Ignoring system design
Avoiding real-world constraints
But real AI work is messy:

Bad data
Latency issues
Cost constraints
User unpredictability
That’s exactly where real engineers stand out.

My Perspective as an Engineer

As someone working deeply in frontend and scalable systems, one thing is clear:

The future is not: “Frontend vs AI”

It’s: “AI-powered products built by engineers who understand systems end-to-end.”

The most valuable engineers in the next 3–5 years will be those who can:

Bridge UI + AI
Build intelligent user experiences
Optimize performance across the stack

Final Thought

AI exposed the difference between:

Those who experiment
And those who deliver
And in the global market…

Only the second category gets hired.