惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

M
MIT News - Artificial intelligence
罗磊的独立博客
Hugging Face - Blog
Hugging Face - Blog
Apple Machine Learning Research
Apple Machine Learning Research
Last Week in AI
Last Week in AI
S
SegmentFault 最新的问题
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
美团技术团队
人人都是产品经理
人人都是产品经理
WordPress大学
WordPress大学
The Cloudflare Blog
IT之家
IT之家
雷峰网
雷峰网
小众软件
小众软件
博客园 - 叶小钗
博客园 - 聂微东
爱范儿
爱范儿
博客园 - 司徒正美
博客园 - 三生石上(FineUI控件)
V
Visual Studio Blog
博客园 - 【当耐特】
V
V2EX
博客园_首页
T
Tailwind CSS Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Input Factories
Janne Lammi · 2026-05-19 · via DEV Community

Everyone is building agent factories.

Cursor, Codex, Claude Code, Devin. Coding agents that plan, write, test, ship. Internal pipelines with five, eight, twelve sub-agents in series. Orchestrators that retry. Eval loops. Tool calls. The pipeline keeps getting better, almost weekly.

This is not the hard part.

A factory amplifies whatever you feed it. If you feed it a thin brief, it builds something thin, faster. If you feed it a contradictory spec, it resolves the contradiction silently — usually wrong. If you feed it nothing, it invents.

Most teams are scaling their ambiguity.

The agent factory is solved. The input factory isn't.


By "input factory" I mean the layer above the build. The thing that decides what the agents read before they generate. It contains:

  • the intent (why this exists, who it's for, what it must do)
  • the product spec (scope, edges, what good looks like)
  • the design rules (tokens, voice, components, don'ts)
  • the brand (how it sounds, what it never says)
  • the playbooks (how this team approaches this kind of work)
  • the reference code (this is how we do it here)

These already exist. They live in Notion, Figma, Slack threads, the repo, somebody's head. They drift. They contradict each other. Nobody owns them. When the build is wrong, no one knows which one to fix.

This is the bottleneck.


Here is the loop most teams are running today:

  1. Agent builds something
  2. Designer or PM reviews the PR
  3. PR is wrong
  4. Fix the PR

Here is the loop they should be running:

  1. Agent builds something
  2. Designer or PM reviews the PR
  3. PR is wrong
  4. Which input was thin, stale, or contradictory?
  5. Fix the input
  6. Run the next thing through the better input

The first loop scales the work. The second loop scales the system.

The first loop is what most teams will look back on as the embarrassing era — when senior people spent their time fixing outputs an agent produced from inputs the senior person never actually wrote.


There is a role shift coming, and it is bigger than it sounds.

The designer stops being the one who fixes the output. They become the one who curates the system that produces the output. When the build comes back wrong, the question is no longer "how do I edit this?" but "what was missing from what the agent read?"

The PM stops chasing tickets. They author the intent — the why — and the evidence behind it. The thing nothing downstream can guess at.

The engineer stops translating. They integrate. They write the reference code, the conventions, the constraints. They make the input layer real in the repo.

In this world the seniority of the work moves upstream. The most leveraged person on the team is whoever owns the inputs.


I think the reason nobody has built this yet is that the inputs feel like just files. Markdown, Figma frames, brand decks, a couple of shared docs. It feels low-status. The factory feels high-status.

But the factory is a commodity. There will be five good ones in eighteen months and they will mostly do the same thing.

The inputs are not a commodity. They are your product's actual intent, captured and made legible to a machine. They are the only thing that makes your factory's output yours instead of generic.


A real input factory does a few things the file-soup version doesn't:

It authors — the inputs are written deliberately, not assembled from drift.

It evidences — every claim points back to the user signal that justifies it.

It governs — somebody owns each input, somebody updates it, the staleness is visible.

It compiles — at build time, the right slice of input is packaged into the agent's context. Not the whole pile. The right slice.

It diffs — when the output is wrong, you can trace which input was insufficient, and improve it.

Karpathy has been writing about a version of this from the other direction: raw notes compiled into a wiki an LLM can read. He is right about the pipeline. The thing he leaves implicit is that for product work, the raw notes aren't notes. They are intent, spec, brand, design rules, playbooks. The wiki isn't a wiki. It is the input factory.


The companies that figure this out first will look, from the outside, like they have better agents.

They won't. They will have better inputs.

If you are building an agent factory right now, the question worth asking is: what does my factory read, who wrote it, and how do I know it's still true?

If you do not have a good answer, the factory is the wrong place to spend the next quarter.

Build the input factory.


I'm building Pathmode, the input layer for product teams building with AI.