human

Respondents found the task less meaningful when they thought that the slogans were AI-generated (Figure 1). Compared to the human-label group, the AI-label group saw a drop in task meaning of about 0.07 standard deviations. Respondents in the AI-label condition were also less willing to contribute a slogan of their own by 3.4 percentage points. Because 26% of participants provided a slogan—and some were remarkably creative—the estimated effect is substantial: a 13% decrease relative to the baseline.

Accepting program modifications
demanded by changing external circumstances to be an essential part of programming, it is argued that the primary aim of
programming is to have the programmers
build a theory of the way the matters at
hand may be supported by the execution
of a program. Such a view leads to a
notion of program life that depends on
the continued support of the program by
programmers having its theory. Further,
on this view the notion of a programming method, understood as a set of rules of
procedure to be followed by the programmer, is based on invalid assumptions and so has to be rejected.

I no longer have a firm mental model of what they can do and how they work, which means each additional feature becomes harder to reason about, eventually leading me to lose the ability to make confident decisions about where to go next.

The important ironies of the classic approach to automation lie in the expectations of the system designers, and in the nature of the tasks left for the human operators to carry out.

And so generating code is not necessarily the part that you need to worry about the most. Given enough context, agents can write the implementation and run the tests and inspect failure and revise code for us. We need to get to a place where we feel like there is enough of human taste encoded in the environment that we can trust what is being built, so that our human attention can be focused on the places where it’s needed most.

Comprehension debt is the growing gap between how much code exists in your system and how much of it any human being genuinely understands.

Dr. Margaret-Anne Storey, professor of computer science at the University of Victoria, first used the term ‘cognitive debt’ in October 2025 while teaching an entrepreneurship startup course. She had encouraged her students to use AI to move faster, and that worked well: the students were putting products into the hands of users and getting feedback. However, they were struggling with implementing that feedback back into their product.

Cognitive debt, a term gaining traction recently, instead communicates the notion that the debt compounded from going fast lives in the brains of the developers and affects their lived experiences and abilities to “go fast” or to make changes. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.

a cloud software factory is just an automation around the core loop of development, from triage → spec → implement → review → verify → ship → monitor, where at every step a mix of agents and humans moves the process forward.

We conduct randomized experiments to study how developers gained mastery of a new asynchronous programming library with and without the assistance of AI. We find that AI use impairs conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average. Participants who fully delegated coding tasks showed some productivity improvements, but at the cost of learning the library. We identify six distinct AI interaction patterns, three of which involve cognitive engagement and preserve learning outcomes even when participants receive AI assistance. Our findings suggest that AI-enhanced productivity is not a shortcut to competence and AI assistance should be carefully adopted into workflows to preserve skill formation -- particularly in safety-critical domains.

Reviewing AI generated code can be tough, especially if the code generated is solving a particularly complex problem. Even if the code is correct, it can be hard to understand how exactly it works. When working with other human programmers, I would generally ask them to walk me through their code, and I would ask questions about why they made certain decisions as we go. I wanted a similar process for reviewing AI generated code. After a lot of exploring, I've found a combination that works well for me.

The core insight is this: AI agents don’t save you time by finishing your work. They expose how much work was always possible but never attempted. Five constraints now govern how much of that backlog any organization can actually capture: judgment, planning, coordination, evaluation, and absorption. Understanding those five constraints tells you exactly which new roles are being created and why.

Agents doing judgement-heavy work need a way to learn from the people whose judgement they are trying to approximate. 1. Principles beat rules, because rules overfit and principles transfer. 2. Agents need to learn how to learn, or feedback turns into brittle exceptions. 3. The feedback loop has to live where the team already works, or people stop participating.

Feedback is not learning unless the agent can generalize

When an agent does work repeatedly, the prompt starts to become the thing you review. If those instructions determine production behaviour, they should live in a repo, with version history, review, and rollbacks. The daily learning agent does not directly change production behaviour. It opens a PR showing what feedback it reviewed, what principle it thinks should change, and the exact diff to the skill file. A human reviews it like any other change.

long-horizon agents assume requirements all exist upfront. They are fundamentally against human in the loop. And they don't have true judgment for what humans like. That—is why I don't like them.