Issue 01: The Bottleneck Moved

May 5 → July 4, 2026
The strongest pattern in this issue is simple: AI is making it easier to produce software, documents, plans, and prototypes. It is not making it easier to know what should exist, what should be trusted, and who should carry the consequences.

Dear reader,

I went through the last two months of LinkCatalog expecting to find many separate stories: coding agents, local models, open source fatigue, AI security, career anxiety, and the usual flood of new tools.

But after reading the compiled wiki as a whole, it did not feel like separate stories.

It felt like one story.

The bottleneck moved.

For a long time, the hard part of software was getting something to work. You had to learn the framework, read the docs, understand the database, wire the API, build the UI, test it, and then keep it alive. That work is still real. But AI is pushing down the cost of getting a first version into existence.

A prototype that once needed a week can appear in an afternoon. A design document that once took days can appear before lunch. A pull request that once came slowly can now arrive with thousands of lines of code and a very confident explanation attached to it.

At first, this feels like a productivity miracle.

Then you notice the second-order effect.

The work did not vanish. It moved from creation to judgment. From typing to reviewing. From knowing the syntax to knowing the system. From asking “can we build this?” to asking “should this exist, does it fit here, and can we own it after it ships?”

That is the picture this issue tries to paint.

1. The harness became the real work

The clearest signal in the catalog is that AI does not remove engineering. It moves engineering into the harness around the model.

OpenAI’s Codex harness-engineering case study is the loudest version of this story: a production-scale system, roughly a million lines of code, built by a small team where the human effort moved toward environments, feedback loops, and AGENTS.md-style operating instructions. Cloudflare’s multi-specialist code review system points in the same direction. The important move is not “use one bigger prompt.” The important move is to give different agents clear responsibilities, boundaries, and review paths.

This is a very different mental model from “AI writes code for me.”

A model by itself is potential energy. A harness turns it into useful work.

The harness is where you decide what context the agent gets, what tools it may use, what tests it must pass, what files it should not touch, when it should stop, and how a human can inspect the result. Without that, the model can still produce impressive output, but the output lands like a stranger in your codebase.

Think about a new developer joining a team. You do not just hand them the production database and say, “be productive.” You explain the architecture. You show them the conventions. You give them small tasks first. You review their work. You tell them which parts of the system are fragile. You help them build taste.

Agents need a version of that onboarding too.

The durable skill is not prompting harder. It is building an environment where good work becomes repeatable and bad work is caught early.

For teams, this means tests, checklists, evals, context files, review gates, and operating instructions are no longer boring process artifacts. They are part of the product surface of AI-assisted engineering.

2. Working code is not the same as fitting code

A recurring mistake in AI discussions is treating correctness as a local property.

Does the code compile? Does the test pass? Does the demo work?

These are necessary questions. They are not enough.

One of the best ways to understand this is authentication. Imagine a developer asks an AI tool to implement OAuth for a new service. The AI produces a secure, well-structured OAuth flow. On paper, the code looks fine. It may even be more polished than what the developer would have written manually.

But the organisation already uses a different flow everywhere else. The monitoring assumes that flow. The onboarding documents assume that flow. The security team has reviewed that flow. The new code is technically reasonable and still wrong for the system.

This is where human context matters.

The same pattern appears across the catalog: RAG systems should authorize before retrieval, not retrieve private documents and then hope the model refuses to leak them. AI-generated retry logic should not duplicate payments because nobody encoded idempotency. A coding agent should not invent a new logging format because it looks cleaner in isolation.

The model can be locally helpful and globally expensive.

This is why structural gates matter so much. Access control should happen before retrieval. Important invariants should live in tests, schemas, type systems, permissions, and policy layers. Calculations should be deterministic. Irreversible actions should require explicit approval.

Prompts are reminders.

Structures are safeguards.

The better AI systems will not be the ones that merely ask the model to behave. They will be the ones where the model is surrounded by systems that make the right thing easier and the dangerous thing harder.

3. Judgment became the scarce resource

AI makes output cheap.

It does not make judgment cheap.

This is the thread connecting Charity Majors on engineering discipline, Vini Brasil on rejecting AI code you cannot explain, Stack Overflow’s decision-fatigue framing, and the growing discomfort around enormous AI-generated pull requests.

If one person sends you one rough proposal, the work is obvious. You read it, improve it, and decide.

If five people each send you ten polished proposals, the work becomes stranger. Everything looks plausible. Everything has a rationale. Everything sounds like it was written by someone who knows what they are doing. Your job is no longer to fix spelling mistakes or missing imports. Your job is to notice which polished thing is subtly misaligned with reality.

That is tiring.

A 2,000-line patch can pass locally and still leave you with questions that only experience can answer:

• Does this match the direction of the codebase?
• Is this abstraction worth carrying for the next three years?
• Will the next engineer understand why this exists?
• Did the AI solve the problem, or did it create a more impressive problem?
• Can I explain this in my own words?

That last question is important.

If an agent creates a feature that works but you cannot explain it, you have not really gained ownership. You have borrowed velocity and accepted risk.

This does not mean “use AI less.” It means use AI in a way that keeps human understanding close to the work. Smaller diffs. Clearer design notes. More explicit trade-offs. Better rejection criteria. More time spent reading, not just generating.

The bottleneck is no longer typing.

The bottleneck is owning the consequences.

4. Domain expertise still matters, but it has to be real

A strong idea in the catalog is that domain expertise may be the last durable moat.

AI can collapse the distance between intent and implementation. It can help write the API, suggest the schema, produce the UI, and generate tests. But it does not automatically know whether the thing being built makes sense in the real world.

A logistics dispatcher may know immediately that a proposed route is nonsense because of a local constraint that never appears in the database. A payments engineer may feel uneasy about retry behavior because they have seen duplicate charges create operational pain. A backup engineer may know that a workflow is not just “copy files from A to B,” but a chain of restore guarantees, failure modes, retention rules, and trust boundaries.

That kind of knowledge is not just information.

It is lived context.

But the catalog also makes the opposite warning clear: domain expertise is not magic. If your expertise remains vague, undocumented, or disconnected from the system, AI will steadily learn to approximate parts of it. The moat leaks when experts cannot explain what they know, when teams do not encode their principles, and when hard-won judgment stays trapped in one person’s head.

The goal is not to turn every instinct into a checklist. That would flatten the work.

The goal is to make enough of the judgment visible that humans and agents can work with it: design docs, decision records, examples, runbooks, postmortems, tests, and “this is how we think here” notes.

The future belongs less to people who can code anything, and more to people who know what is worth coding, why it matters, and when it is wrong.

5. The reverse centaur is no longer theoretical

The ideal picture of human-AI work is the centaur: human direction, machine acceleration.

The failure mode is the reverse centaur: machine pace, human cleanup.

The botsitting data in the catalog makes this feel less like a metaphor and more like an operating cost. Workers spend time feeding context to AI, checking output, fixing mistakes, and cleaning up after it. Many feel individually faster. Far fewer see the same improvement at the organisation level.

That gap matters.

It is possible for every individual to feel productive while the system becomes more tired. More documents to review. More code to understand. More side projects to maintain. More meetings with AI-generated proposals. More “quick drafts” that still require careful reading.

This is where the human side of the issue becomes important.

AI removes many natural stopping points. There is always one more prompt, one more refactor, one more variation, one more branch of the idea. The tool makes continuation feel cheap. But attention is not cheap. Recovery is not cheap. Maintenance is not cheap.

A healthy AI workflow needs stopping rituals.

Definition of done. Time boxes. Smaller review units. Explicit “ship or stop” moments. A habit of asking whether AI reduced work or only moved work into supervision.

The question for teams is not only “are people using AI?”

The better question is: who is setting the pace?

6. Open weights moved from preference to resilience

The local-model thread also changed shape in this period.

A few years ago, local models mostly felt like a hobbyist preference or a cost-saving experiment. In this catalog, they look more like resilience infrastructure.

The pattern is clear: local-model UX is improving, skill distillation makes smaller models more useful, Qwen with llama.cpp and OpenCode points toward practical local development workflows, and the Fable/Mythos export-control story makes vendor revocability impossible to ignore.

Hosted models are powerful. They will remain important.

But if your whole workflow depends on one provider, one API policy, one pricing decision, or one silent model change, then your engineering system has a new kind of dependency risk.

The practical answer is not to abandon frontier models. It is to keep an escape hatch.

Use frontier models to discover better methods. Save those methods as model-agnostic artifacts. Let cheaper or local models execute the repeatable parts where they are good enough. Evaluate local models on instruction-following and reliability, not only benchmark scores.

The open-weight argument is no longer only “cheaper.”

It is “cannot be silently taken away.”

7. Open source is entering its spam-filter era

The open-source thread is one of the more painful parts of the issue.

The catalog does not say AI in open source is bad. It says open source is being forced to develop new trust filters because contribution has become cheap.

Armin Ronacher’s issue tracker story shows plausible but wrong AI-generated reports. Archestra saw bot spam bury real contributors. Andrew Tridgell’s rsync essay shows the more nuanced version: AI can be useful under expert supervision, while AI-generated security noise can still harm maintainers.

That distinction matters.

The problem is not whether AI touched the work. The problem is whether a responsible human understood, verified, and owned the work.

Email did not become useless because sending email became cheap. But email did need spam filters, sender reputation, social norms, and better inbox design. Open source is entering a similar moment for issues, pull requests, vulnerability reports, and automated contributions.

Maintainer attention is a scarce community resource.

Protecting it may become one of the central sustainability problems of the AI era.

What I would carry forward

If I had to compress the last two months into one sentence, it would be this:

AI lowers the cost of producing work, but raises the value of knowing what work deserves to survive.

That sentence changes how we should build.

We should write better specs because implementation is cheaper.

We should keep humans close to the domain because correctness lives in context.

We should make agent work inspectable because ownership cannot be outsourced to a transcript.

We should move rules into systems because prompts are too soft for critical boundaries.

We should keep local and open-weight paths alive because resilience matters when models become infrastructure.

We should protect attention because output is infinite and human recovery is not.

And most of all, we should build tools that help competent people become more capable, not tools that pretend competence is unnecessary.

That is the hopeful version of this shift.

Not AI replacing judgment.

AI making judgment more valuable.

Signals worth watching

• Harnesses becoming product assets. Tests, evals, context files, policy gates, and agent instructions will matter as much as model choice.
• Smaller diffs becoming a team norm. AI-generated work will need to arrive in reviewable units, not impressive avalanches.
• Artifact memory beating transcript memory. Agents will become more useful when they inherit accepted docs, commits, and decisions instead of raw chat history.
• Security moving before the model. The strongest systems will enforce permissions before retrieval, tool calls, and irreversible actions.
• Open-weight escape hatches. Teams will keep at least one local or portable path for workflows they cannot afford to lose.
• OSS trust filters. Maintainers will need norms and tooling that separate expert-assisted work from plausible noise.
• Recovery as part of productivity. Teams that use AI well will design stopping points, not just acceleration loops.

Articles behind this issue

These are the pieces I would keep open beside the essay if you want to trace the argument back to its sources.

Harnesses, agents, and review

• Harness engineering: leveraging Codex in an agent-first world — the production-scale case that makes “harness as the work” concrete.
• Orchestrating AI Code Review at scale — Cloudflare’s multi-specialist reviewer architecture.
• Build Your Own Eval Harness from Scratch with Bun and claude -p — a small, practical example of treating evals like tests for non-deterministic software.
• Agentics: Memorizing Session Transcripts Isn’t Useful — why reviewed artifacts often beat raw transcript memory.
• Building Reliable Agentic AI Systems — a grounded agentic RAG case study from Bayer PRINCE.

Judgment, context, and career pressure

• AI demands more engineering discipline. Not less — the case for higher standards as AI output grows.
• When I reject AI code even if it works — a useful checklist for refusing work you cannot own.
• Coding agents are giving everyone decision fatigue — the SDLC bottleneck moving into judgment.
• Domain Expertise Has Always Been the Real Moat — the clearest statement of domain knowledge as the human oracle.
• LLMs are eroding my software engineering career and I don’t know what to do — the more uncomfortable counterpoint: even domain knowledge is under pressure.
• Give Smart People The Tools To Do Smart Things — the better framing for AI tools: amplify competent people.

Boundaries, security, and structural gates

• Making RAG Safe by Construction — authorization belongs before retrieval, not after generation.
• Structural Backpressure Beats Smarter Agents — why invariants should live in compilers, tests, and gates.
• Intro to TLA+ for the LLM Era — LLMs lower the syntax barrier; humans still define correctness.
• A Circuit Prompt Programming Language — a hardware-design example of compiler-mediated LLM work.
• Idempotency Is Easy Until the Second Request Is Different — a reminder that retry logic without domain guarantees can be dangerous.

Human-AI collaboration and fatigue

• The rise of the ‘botsitters’ — the hidden labor data behind the reverse-centaur concern.
• AI coding is addictive. Engineers are paying the price — the “AI Vampire” loop and the need for stopping rituals.
• Reverse centaurs and the failure of AI — Cory Doctorow’s framing of machines setting human pace.
• Centaur Chess Shows Power of Teaming Human and Machine — the more hopeful collaboration model: human in command, machine as amplifier.
• Pet Projects Are Getting Too Big to Pet — the personal version of AI expanding scope and obligation.

Open weights and open-source trust

• Qwen 3.6 27B is the sweet spot for local development — a practical local coding workflow with Qwen, llama.cpp, and OpenCode.
• Skill Distillation — frontier models write procedures; smaller/local models execute them.
• GLM-5.2 vs Claude Opus — a cost/quality comparison that also makes the resilience argument for open weights.
• If Claude Fable stops helping you, you’ll never know — silent degradation as a vendor-trust problem.
• Building Pi With Pi — AI-generated issue reports as a new maintainer burden.
• Let’s talk about AI slop — bot spam burying real open-source contributors.
• rsync and outrage — separating expert-supervised AI use from AI-generated noise.

Closing note

The most useful posture for the next phase is neither panic nor worship.

It is craftsmanship.

Use the models. Build the harnesses. Protect the human. Keep the domain close. Put the rules into the system. Prefer tools that make judgment stronger, not tools that pretend judgment is optional.

That is the lesson I would carry forward from this first issue.