$cat developers-becoming-builders.md

Developers Are Becoming Builders: What AI Actually Changes

July 3, 202615 min readby MDflowview as .md

An emerald wireframe architect-builder figure at a console orchestrating small AI agent nodes that assemble glowing modular blocks into a structure, on a dark terminal-grid background

"Thanks to AI, smart software developers are becoming builders. The rest will need to find a different job." It is a good line — the kind that gets quoted in a keynote and reshared with a knowing nod. It is also half right and half wrong, and the difference matters if you write software for a living.

The first half is well supported: the developer's job really is shifting, from typing code line by line toward architecting, specifying, reviewing, and orchestrating AI agents. The second half — that everyone who doesn't make the jump needs a new career — collides with the actual data on jobs and productivity. This post separates the signal from the slogan, with sources and dates, and then gets practical about how to be on the right side of the shift.

TL;DR — Developers becoming builders is real: near-universal AI adoption (90% of technology professionals use AI at work, per the 2025 DORA report) is moving engineers from writing every line toward architecture, spec-writing, review, and agent orchestration. But "the rest will need a different job" overstates it — the U.S. BLS projects software-developer employment to grow 15% through 2034 and cites AI as a demand driver, a 2025 METR trial found experienced devs 19% slower with early-2025 tools, and displacement is concentrated at the entry level, not across the profession. What separates builders from the rest isn't raw coding speed — it's architecture, review discipline, and context engineering. That last one needs somewhere durable to live: a markdown memory both you and your agents can read and write. That's MDflow.

What "developers becoming builders" actually means

"Developer as builder" describes a shift in where an engineer spends their attention: away from implementing every line by hand, and toward the higher-order work of deciding what to build, specifying it clearly, reviewing what an agent produces, and orchestrating multiple agents to get there. It is the same job — shipping working software — reorganized around a new default: the agent writes the first draft; the human directs and owns it.

This is now the mainstream framing, not a fringe prediction. OpenAI's own Codex guidance describes engineers who "shift their attention to higher-order work" — "clarifying product behavior," "designing patterns, guardrails, and conventions" — while routine tasks are "delegated to Codex entirely." Its model for the AI-native engineer is three words: Delegate, Review, Own — with the crucial caveat that "true ownership of code — especially for new or ambiguous problems — still rests with engineers."

The vocabulary is still settling, but the practitioners converge on the same idea:

Term	Coined by	What it names
Vibe coding	Andrej Karpathy (2025)	Writing code with AI without reading the output — fast, unaccountable, fine for throwaways
Vibe engineering	Simon Willison (Oct 2025)	The disciplined opposite: seasoned pros accelerate with LLMs while staying fully accountable
Agentic engineering	Karpathy / Addy Osmani (2026)	Orchestrating AI agents and providing oversight as the new default, rather than writing code directly

The through-line: the valuable skill is no longer keystrokes. As Addy Osmani (a Google engineering leader) puts it, the developer becomes "architect, reviewer, and decision-maker." That is the "builder" the slogan is reaching for.

The evidence: the role shift is real

The adoption numbers alone make the shift hard to argue with. In the Stack Overflow 2025 Developer Survey (roughly 49,000 respondents), 84% of developers were using or planning to use AI tools — up from 76% in 2024 — and 51% of professional developers use them daily. The 2025 DORA report (published September 23, 2025) found that 90% of technology professionals use AI at work, with more than 80% saying it increased their productivity.

DORA added a second, subtler signal. In 2024 it had found AI adoption correlated with a slight decrease in delivery throughput and stability. In 2025 that reversed: "Unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance." Teams are learning to build with agents, not just poke at them — which is exactly what you'd expect as the craft matures from autocomplete into orchestration.

So the first half of the claim stands: the work is being reorganized, universally and quickly, around directing AI rather than out-typing it.

The part the claim gets wrong: "the rest will need a different job"

Here the slogan outruns the evidence in three directions.

The profession is growing, not shrinking. The U.S. Bureau of Labor Statistics projects employment of software developers to grow 15% from 2024 to 2034 — "much faster than the average for all occupations" — about 287,900 additional jobs. And BLS names AI as a driver of that demand, not a threat: growth is "projected to be strong due to the continued expansion of software development for artificial intelligence (AI), Internet of Things (IoT), robotics, and other automation applications." Developers who feel this in their gut agree: 64% told Stack Overflow in 2025 that they do not see AI as a threat to their jobs (though that's down from 68% in 2024).

The productivity premise is shakier than the hype. The thesis quietly assumes AI makes good developers dramatically faster. Sometimes it does: a 2023 GitHub Copilot randomized controlled trial (Peng et al., n=95) found the AI group finished a well-bounded HTTP-server task 55.8% faster. But a 2025 METR randomized trial (July 10, 2025; 16 experienced open-source developers, 246 real issues on their own mature repositories) found the opposite — developers were 19% slower with early-2025 AI tools. More striking than the slowdown was the self-deception around it: those developers predicted a 24% speedup and, even after being measurably slowed, still believed AI had sped them up by 20%. (METR notes the finding is scoped to early-2025 tools and that today's models "likely" help more — but the perception gap is the durable lesson, and it should make you distrust every self-reported productivity number, including DORA's 80%.)

Quality and maintenance costs are real. The same 2025 DORA report that found a throughput gain also found AI adoption still has a negative relationship with delivery stability without "strong automated testing, mature version control practices, and fast feedback loops." A difference-in-differences study of 2,755 open-source repositories (arXiv 2510.10165) found "code written after the adoption of AI requires more rework to satisfy repository standards, indicating a potential increase in technical debt." And developer trust is falling even as usage rises: in Stack Overflow 2025, more developers actively distrust AI accuracy (46%) than trust it (33%) — the survey's headline was literally "Trust in AI at an All-Time Low." Two-thirds are frustrated by "AI solutions that are almost right, but not quite."

Where the slogan has a real point: the entry level. The strongest evidence for the darker half of the claim is Stanford's "Canaries in the Coal Mine?" (Brynjolfsson, Chandar, Chen; November 2025 revision), built on ADP payroll data for millions of workers. It found early-career workers (ages 22-25) in the most AI-exposed occupations down about 16% relatively, and software developers aged 22-25 down nearly 20% from their late-2022 peak — while experienced workers in the same occupations stayed stable or grew. The displacement is concentrated where AI "automates rather than augments," and it lands on juniors first. (Caveat: it's a working paper reporting relative declines, and the authors concede the post-2022 hiring correction and interest-rate hikes also weigh on young-worker employment — critics dispute the cause, not the age gradient.)

Put together: the profession isn't going away. But the on-ramp is narrowing, and the reward is moving to whoever can direct AI well. That's a real, uncomfortable truth — just not the one the slogan states.

What separates the builders from the rest

If it isn't raw talent or typing speed, what is it? The consistent finding across practitioners is that AI amplifies whatever fundamentals you already have — and amplifies confusion where you don't. The developers who thrive share a recognizable toolkit:

Architecture and systems thinking. Deciding how the pieces fit is exactly the work agents are worst at and humans still own. AI accelerates the first ~70% of a feature; the last 30% — the part that requires understanding how the system actually works — is still yours.
Writing clear specifications. An agent is only as good as the spec it codes against. The builder's leverage is turning a fuzzy intent into an unambiguous, testable description before a line is written.
Review discipline. "Delegate, Review, Own" only works if the review is real. Reading and interrogating agent output — not rubber-stamping it — is the skill that keeps the 46%-distrust problem from becoming your production incident.
Testing and guardrails. DORA is blunt: AI-driven change volume causes instability without strong automated testing and fast feedback loops. The builders are the ones who build the rails the agents run on.
Context engineering. Agents don't fail for lack of intelligence; they fail for lack of the right information at the right moment. Curating specs, decisions, conventions, and prior work into context an agent can pull on demand is fast becoming the defining craft of AI-native development. (We wrote a whole piece on why curation beats a bigger prompt.)

Notice what these have in common: they're all about durable, written artifacts — specs, decisions, tests, conventions, notes-to-self — that an agent reads before it acts and writes back after. Which is where storage stops being plumbing and becomes strategy.

Which workflows benefit most from a markdown memory

The builder's workflow runs on written context that outlives any single chat session. A few patterns benefit most from a shared markdown store that both people and agents can read and write:

Spec-driven development. The spec, the plan, and the running progress file are what the agentic coding loop reads and writes between turns. Keep them durable and an agent runs longer and drifts less.
A knowledge base your AI maintains. The Karpathy-style wiki — a plain-Markdown knowledge base an LLM writes and keeps current — compounds where hand-kept wikis rot, because agents don't get bored updating cross-references.
Multi-agent coordination. When several agents work in parallel, they need one place to see the shared plan, claim work, and leave results — a common memory, not a private scratchpad each.
Onboarding and handoff. The context a senior builds up — why the system is shaped this way, what was tried and rejected — becomes a written artifact new teammates and new agent sessions can load, instead of tribal knowledge that leaves when the person does.
Curated context over raw retrieval. Instead of embedding everything and hoping, the builder curates what matters into described, navigable folders an agent pulls from deliberately.

Anywhere the work depends on written context an agent consumes and updates, portable Markdown beats a proprietary block store or a pile of embeddings — because it's readable by humans, versionable, and speaks every agent's native language.

How MDflow fits

MDflow is a markdown workspace built for exactly this moment: a place where the durable context of AI-native development can live for people and agents at the same time. You write and review in a browser editor; your agents read and write the same documents through a first-party MCP server and an HTTP API. It is the "agentic markdown storage" the builder workflow needs.

What already lines up today

Markdown-native storage. Every document is plain-text Markdown — not a proprietary format with an approximate "export to Markdown" button. What you write is what an agent reads, unchanged.
Folders that carry context. Every folder has a description that defines the intended context for the documents inside it, and folders nest to any depth. Those descriptions cascade into a compounded chain of context an agent reads before opening a single file. A folder's description is the primary ranking signal for retrieval — curated context as a first-class feature, not an afterthought.
A context tool agents already call. MDflow's MCP server exposes mdflow_get_context: give it a topic, and it scores folder descriptions first, then names and titles, and returns the most relevant Markdown bodies. That is context engineering, operationalized.
Read and write, over MCP and an API. Authenticated with a Personal Access Token, Claude, ChatGPT, Cursor, and Codex can create, update, move, organize, and share documents through the MCP server and HTTP API — so an agent can write its progress back, not just read the spec.
Raw .md twins with frontmatter. Append .md to any shared link and you get the document as plain Markdown with YAML frontmatter over open CORS — an agent can fetch and cite a document in one request. (This post has one; look for the link at the top.)
Automatic version history. Every write path — editor, API, or agent — captures a version with line diffs and one-click restore. When an agent edits, you have a safety net, which is what makes trusting agents with write access reasonable.
Discovery and governance built in. An llms.txt index, a docs.md agent manual, an A2A agent card, and an OpenAPI spec make the workspace discoverable; public links, private email-based sharing, collections, anchored comments, server-side ownership checks, and optional client-side AES-256 encryption make it governable. The Web Clipper turns any web page into clean Markdown you can drop straight in.

Where we are headed

This is direction, not a dated commitment, but it's the shape of the thinking: a collections API and richer remote MCP so an agent can pull a whole cross-linked knowledge set at once; OAuth so agents connect from ChatGPT and Claude.ai on the web without a manual token; first-class document types and tags for structured, agent-queryable metadata; and agent-assisted enrichment — letting an agent propose folder descriptions and cross-links for knowledge you already have. The bet is simple: as the builder's job becomes managing context, the tools that win are the ones where Markdown was the substrate all along.

The bottom line

The slogan is a good provocation and a bad prediction. Developers are becoming builders — that half is true, universal, and already here. But "the rest will need a different job" isn't what the numbers say: the profession is projected to grow, most developers don't feel threatened, and the clearest trial we have shows AI slowing experienced developers who leaned on it uncritically. The honest version is quieter and more useful: the work is moving to whoever can architect, review, and — above all — engineer the context their agents run on.

That's a skill you can build, and it needs a place to live. Give your specs, plans, and knowledge a durable markdown home that both you and your agents can read and write.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

Are software developers really becoming "builders"?

Yes — the role is shifting from writing code line-by-line toward architecture, writing specs, reviewing agent output, and orchestrating AI agents. OpenAI's Codex guidance frames it as "Delegate, Review, Own," and the 2025 DORA report found 90% of technology professionals now use AI at work. But it is augmentation, not replacement: human engineers still own new and ambiguous problems.

Will AI replace software developers or take their jobs?

Not the profession as a whole. The U.S. Bureau of Labor Statistics projects software-developer employment to grow 15% from 2024 to 2034 (about +287,900 jobs) and names AI as a demand driver, and 64% of developers in the Stack Overflow 2025 survey do not see AI as a job threat. What is real is entry-level compression: Stanford found early-career developers (ages 22-25) down nearly 20% from a late-2022 peak, while experienced developers stayed stable or grew.

Does AI actually make developers more productive?

It depends heavily on the task and the developer. A 2023 GitHub Copilot RCT found a 55.8% speedup on a well-bounded task, but a 2025 METR RCT found experienced developers were 19% slower on their own mature repositories — while believing they were 20% faster. Gains are largest for juniors and greenfield work; complex, existing codebases show real rework and technical-debt costs.

What skills separate developers who thrive with AI from those who don't?

Not raw coding speed. The differentiators are architecture and systems thinking, writing clear specifications, disciplined code review, testing and guardrails, and context engineering — curating the right information for the agent. AI amplifies strong fundamentals and amplifies confusion where they are weak.

What is "agentic markdown storage" and why does it matter for AI-native development?

It is a markdown workspace that both humans and AI agents can read and write through an API and an MCP server — durable memory for specs, plans, and knowledge that outlives a model's context window. It matters because the builder workflow depends on curated, portable context. MDflow provides this with folder descriptions as context, an mdflow_get_context retrieval tool, raw .md twins with frontmatter, automatic version history, and a first-party MCP server plus HTTP API.