A Study Plan for Outsider Builders

Index:

1. **A Study Plan for Outsider Builders **(downloadable, with templates).
2. **My Bet: I Don’t Need to Learn to Read Code (with precision) **— a bit of history, what I do now, what the field believes, what the evidence says, the test, what a model can find.
3. **Appendix - A Self Assessment - **where I stand on the map.

1 · The Plan

Starting in late March this year, I spent five months and 1,200 hours in a deep hole with Claude Code, learning to build software by making error after error — and thus creating solution after solution — in dialogue with Claude. In the last few weeks, as I finally came up for air, I found myself thinking: I can’t be alone doing this. Others must be building like this. And, moreover, real engineers must have better solutions for the problems I’ve been tackling.

In that context, I stumbled on Andrew Ng and his recently published map of AI engineering skills. He notes that software is built very differently today than in 2022 and proposes a set of skills for people who build and deploy AI applications. (He holds those folk separate from AI engineers building AI systems.)

As an outsider — self-taught, no previous engineering skills — it’s an intimidating map.

Nevertheless, I’ve developed my own workplan and study guide from it.

I’ve made that plan publicly available on Github.

It’s just a starting point. I hope you will help me improve it by offering corrections, additions, and resources.

My hope is to help forge a path for “outsider builders” — those of us who are self-taught and yet loving the creative possibilities and opportunities to contribute.

You can also see the plan and example here.

Please dig into it and comment — and please push back on the argument below.

In the next couple weeks, I’m also going to write on the ethics of building with AI agents. I find myself part of a long-running set of hopes and debates about technology, our responsibilities, and where power sits.

Thank you,

Jonas

2. My bet: I don’t need to learn to read code (with precision)

There’s one piece of Ng’s plan that I refuse: I will not learn to write code, and I will not learn to read it with precision.

I will not be able to review code in bulk. I won’t have line-by-line comprehension in a deep way at an engineer’s speed — or any speed at all — and, contrary to Claude’s initial recommendation, I’m not going to spend a year trying to get it. (As I note below, I did try — and the pace was untenable.)

Instead, I’ll spend that year building machines to do what many argue only an experienced engineer can do. So, mostly, I will read about code. And I will verify by instrument and by argument.

*I’m not saying no knowledge is needed. My workplan commits me to studying the vocabulary and failure modes as well as the ability to do a minimum read — a diff, a stack trace, a schema — with AI help, drawing the vocabulary from taxonomies outside my own repo and using a tutor model that isn’t my builder.

Most of the people I read now treat writing code as optional. OpenAI’s harness team shipped about a million lines with none written by hand. Josh Mohrer, a former Uber GM with no engineering career, built a $7M product by learning to code alongside an LLM. Others shipped without writing at all: Kostiantyn Vlasenko (in Anthropic’s own case study), the anesthesiologist Ahmed Elsonbaty, and Jason Lemkin — who also had an agent delete his production database along the way. And some of the best engineers alive have stopped reading what their agents write. Robert C. Martin, who wrote Clean Code, says his current strategy is not to read any of it, and to measure test coverage, dependency structure, complexity, and mutation scores instead. Peter Steinberger ships code he doesn’t read. Boris Cherny, who built Claude Code, hasn’t written a line by hand in eight months. Amjad Masad said in March 2025 that he no longer thinks you should learn to code.

Nearly everyone still holds, though, that reading with precision is necessary. Simon Willison is very pointed on this (see below) and all the folks above are no doubt experts at reading.

Here’s my contrary take: I believe the fluent human read will soon enough be unnecessary and, perhaps, inferior in most instances. Many of the review and reading skills that engineers today hold to be human work will also be done best by agents.

Andrew Ng, in his most recent writing, comes closest to this position, but he still expects human review of code, even if with increasing infrequency.

My position is not popular among engineers, as I detail below. And, the truth is that the engineers have all seen countless things that I have not. They have a language I lack. They can see problems ahead that I wouldn’t even know to name.

So, I’m not claiming to match an engineer at anything. Rather, my hope – for myself and others – is that the right kind of system of agents can build software that is safe to hand to strangers.

I’m arguing that the future of building won’t require the great majority of us to understand the code itself.

I may prove myself wrong, but I hope not. I’ve got a lot riding on it.

A bit of history

In February 2025, Karpathy coins “vibe coding” — a term he retired a year later for “agentic engineering”: “you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight.” In March, Ng calls advice against learning to code “some of the worst career advice ever given” — his point being that coding had become easier, so more people should do it; read one way, his definition includes me. In October, Willison proposes “vibe engineering.” In February 2026, OpenAI publishes “Harness engineering” — humans steer, agents execute — and Willison starts writing his Agentic Engineering Patterns.

**On April 27, 2026, Claude taught me how to install Claude Code locally and I made my first commit, in Replit. (**This followed several weeks of build plan, architecture, and schema development and iteration. My initial plan had me studying every piece of code to achieve solid understanding. I found the pace there untenable. My learning was far too slow, so I started using ‘adversarial’ agents.)

Nine days later — I only saw the timing now — Willison publishes “Vibe coding and agentic engineering are getting closer than I’d like,” and the HN thread runs to 787 points and 885 comments. I was trying to cross this bridge and had zero awareness of the debate.

Within days of that first commit I realized I needed to give my agents more context, and I started decisions.md. Ten weeks later I found Amit Raz recommending the same file. Michael Nygard’s architecture decision records are fifteen years old; I didn’t know that either. I had no idea any of these conversations were happening.

I evolved a number of other practices, as detailed in my agent governance piece. OpenAI was writing in February about repository knowledge as the system of record. I wrote to myself over the summer: “For a fresh session, the record is the world. A decision made anywhere else was not made.”

In dialogue with Claude I also developed other verification practices: graded corpora, pre-work packets, isolated agents with different prompts and context, a QA inventory including a unit suite and DB-backed tests, a CI gate, regression-per-bug, and felt-experience dogfooding. In each instance, I’d asked Claude: “Ok, given this problem, what are my options? How do we solve at root cause level and make the solve durable?”

Kent Beck, June 2025: “In augmented coding you care about the code, its complexity, the tests, & their coverage.” (A year later, in “Trust Factory,” he argues that single-player development with agents eliminates most of the small chances to build trust. I sit in his crosshairs.) I got to the same place there the same way I got everywhere: by failure. When two components each tested green and the wire between them turned out to be missing, Claude suggested breaking every new seam on purpose, once, in a test. When a unit test turned out to have been asserting our own request format back at ourselves for three months, we added a rule: “Anything that carries a contract with an outside system must have been run against that system at least once.”

What I do now

I share what follows just to provide context for the argument I’m making. I’m not claiming any kind of novelty here — I’m sure the field recommends all of it somewhere — though some of it I haven’t yet found elsewhere.

I keep the reviewer away from the code. Anthropic recommends a reviewer in a fresh context that sees only the diff. Mine sees the record — the decisions, the deferrals, the tests — and not the diff’s framing, and it argues with the builder from there. My reviewer can’t be captured by the code. The trade-off is that it can be captured by a stale record. Both have happened. Both are logged.

A deferral index. An agent doesn’t know why something is missing. Deliberate? A mistake? Lacking context, it starts to fix it. So I keep a table of deliberate absences, keyed by what’s missing. (Others built the outlines — the Go FAQ, PEP 1’s rejected ideas — and I’m writing that up now.) I think of this as analogous to a new hire: the agent just plows ahead on its narrow objective where the human version would stop and ask.

I test my instruments. I’ve hardened my mutation tool three times after it lied. Every layer of QA is itself a fallible component. My agents test the tests they build.

Retractions run both directions. Anthropic’s documentation warns that “a reviewer prompted to find gaps will usually report some, even when the work is sound.” I found the opposite failure too: a reviewer folded when the builder cited a three-month-old comment and a verification run. Neither agent provided proof or proposed an experiment to check the truth. (It took two minutes to run; the three-month-old comment was wrong.) So a rule now binds both agents: retract only on evidence, and record the retraction with the query that settled it. I don’t judge the argument. I ask what would settle it and demand the evidence.

Abstention on the user’s side. Everyone gates the build: if the agent can’t verify it, it doesn’t ship. I applied the same rule to the product. When Maximus can’t pin a reminder to a time, it doesn’t guess; it stores the fact undated and asks. That rule has held since June. We shipped a newer guard for a bare “three o’clock” last week and its first live firing was swallowed by another rule — that’s now in the log alongside the fix. The rule that governs my build governs what my users hear.

What the field believes

Willison, March 2025: “I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.”

Willison, May 2026: “If you’re building software for other people, vibe coding is grossly irresponsible because it’s other people’s information.”

Ng, August 2026: “A novice who vibe codes without understanding software fundamentals can create simple applications, but this often leads to the coding agent making bad tradeoffs in latency, availability, consistency, reliability, maintainability, simplicity, and/or cost.” Understanding the fundamentals, he says, is what lets you steer the agents “using the precise language of software engineering.”

Birgitta Böckeler, at Thoughtworks, March 2025: long-term maintainability is “where my 20+ years of programming experience mattered the most.” Cal Newport, August 2026: reviewing code you didn’t write is famously hard, so people skip it. In July, Codeberg’s members voted 358–144 to exclude projects mostly written by agents. And Gary Marcus, August 2025, called the whole arrangement a security nightmare — agents with elevated permissions, steerable by text hidden in the repositories and documentation they read.

I could go on. The experienced engineers developing AI engineering practice almost all hold that the ability to do precise code review is necessary.

And yet.

On September 4, Ng wrote: “When AI review isn’t sufficient, you judiciously insert human reviews of the code behavior (and, infrequently, of code as well) while exploring how to automate this review further.” And: “Now, we focus much less on code and instead focus on deciding what to build, designing the architecture, writing the spec, and verifying outputs.” (link)

In short, I take Ng as arguing that a builder must know the fundamentals well enough to know tradeoffs, review behavior, and read code rarely – while continuing to automate the review. That’s not the Willison standard. It’s closer to my bet than to the standard view.

Of course, for Ng, “Understanding software engineering fundamentals lets you make good tradeoffs by steering coding agents using the precise language of software engineering.” (My emphasis.) Precision is the output of understanding fundamentals, not a substitute for it, and “infrequently” presupposes someone who can read when they choose to. He’s not arguing on my behalf.

Two days earlier, Rachel Laycock, Thoughtworks’ CTO, published “Maybe We Shouldn’t Be Reviewing All This Code.” “We need engineers to understand systems, not diffs.” She argues to “shift the judgment left” – move the feedback closer to the decision by pairing, mobbing, and team design sessions alongside “trunk-based development, automated testing, static analysis, fitness functions and security scanning…agents can participate in those loops too.”

She also rejects having AI agents replace human reviewers as “automating the ceremony rather than questioning why the ceremony exists” while underscoring the real worry — “cognitive and intent debt” – as raised by Brian Houck citing Margaret-Anne Storey: software that grows while the humans responsible for it understand less.

I am indeed guilty of that. It’s a daily struggle. My answer, for now, is not that agents read diffs but that the intent lives in the record: every decision, every deferral, every retraction with its receipt. The machines check the code against the record instead of a human checking the code against memory.

The plan I’ve developed against Ng’s framework is my attempt to tackle the cognitive debt.

What the evidence says

Every number cited for slow rot in AI-assisted code comes from codebases maintained by people who can read code.

GitClear (a code-analytics vendor), January 2026: across 623 million analyzed changes, block duplication up 81% since 2023, refactoring moves down 70% since 2022, error-masking constructs up 47%.

DORA 2025 (Google Cloud): “AI doesn’t fix a team; it amplifies what’s already there.” AI adoption “does continue to have a negative relationship with software delivery stability.”

Cloud Security Alliance, April 2026, on a security vendor’s scanner data: AI-assisted developers “introduce security findings at 10x the rate” — about three times per commit, once you account for how much faster they commit, and counted by scanners, not by readers.

*None of these studies measured whether the code was read. So they show that reading, as practiced, is not sufficient. Whether it is necessary is untested. I’m trying to turn my own builds into the test case.

Everyone, it seems, is struggling with this problem. Rachel Laycock again: “And we know now it’s not viable to continue down this path, hence why code review keeps coming up as an issue or a blocker. If an agent can produce ten times the code but every line eventually queues up waiting for a senior engineer to inspect it, we haven’t created a ten-times engineering organisation, we’ve created a big backlog and a new bottleneck.”

Willison himself now ships some code he hasn’t line-reviewed — uneasily, “leaning on my 25 years.”

I don’t have the 25 years, which is why I can’t do what he does.

The test

Perhaps this is another way of stating the question:

Can the model’s patterns, plus a record that supplies calibration and consequence, beat a human’s patterns plus memory?

Consider: Willison doesn’t win against the AI review by way of pattern recognition. A model has seen far more code than any human alive. His experience is two other things: (i) calibration – knowing which pattern applies here and knowing, and admitting, when he doesn’t know, and (ii) consequence – he’s been in the room over-and-over again when mistakes cost something.

The model has neither, so my system has to supply them. That’s what I’m hoping the record can do. Patterns propose; the record calibrates; instruments dispose.

The models are solving open math problems and proposing new molecules in much the same way: a pattern engine plus an external verifier, a proof checker, or a wet lab.

**There’s one major weakness as far as I can tell: **the training corpus for the models is biased toward success. Public code over-represents tutorials and working examples and under-represents production failure, because failures get fixed quietly and post-mortems are rare. Or so I’m told. The failure states are in there, but, according to Claude, they’re thinnest exactly for the slow rot nobody writes up: duplication, coupling, the invariant nobody named.

Can I catch those without help from the model’s priors?

What a model can find

Ng describes seven tradeoffs: latency, availability, consistency, reliability, maintainability, simplicity, cost.

The field also describes four kinds of rot: duplication, coupling, eroded invariants, security debt.

Five are measurable today, three partly, three not.

I’ve already built tools for latency, availability, and cost. Duplication is doable. Structural coupling falls out of import graphs. Two files that must change together with no import between them needs git history. (Claude just pointed me to Adam Tornhill’s work and change coupling.) Complexity has metrics that are a weak proxy for simplicity. Static analysis finds the security classes the scanners counted above, not authorization logic. Consistency and reliability are guarded exactly where an invariant has been named as a test or a constraint and not otherwise (and this may be the strongest argument for a rented reader of my code).

Rot also has a tell: it shows up in the agents’ own performance — time to green, retries, reverts — if you hold the task constant. Unnormalized, those numbers fall when the agent copy-pastes, which is exactly how rot happens. I’ve seen this already. Claude has proposed a fixed set of canary tasks replayed monthly on a pinned model — and when that model is retired, re-baselined with the discontinuity marked. A rising curve on that is the maintainability signal that, as Dex Horthy of HumanLayer put it in his “Why Software Factories Fail” series, no benchmark penalizes: “if the tests pass, we win, but there is no penalty for eroding codebase maintainability.” Horthy’s own conclusion is that humans must hold the architecture; I’m testing whether the record can hold it alongside me.

Two gaps

The unnamed invariant. The instruments guard what we’ve named. The failure that matters is the assumption nobody wrote down. I can ask an agent, “What does this code assume that nothing checks?” However, an agent told to find gaps will find some so the answer doesn’t necessarily help all that much. It still needs calibration. The best I can do then, I think, is run checks against replayed production data and old incidents. If it catches something real, it stays.

*Beyond that – the assumption no one has thought of – is what I’ll have to hire a reader for.

Adjudication. When two agents disagree, I can’t read my way to the answer. What I can do is run experiments that might settle the disagreement, and that takes vocabulary — transaction, race, idempotent, coupling — not fluency. I’m committed to learning vocabulary. When no experiment can settle it, which is what architecture disputes usually are, I ask each side what would have to be true for it to be right and what it costs to reverse, and I ask a third agent in a fresh context to lay out the tradeoff without a stake in it. Then I decide — because the disputed facts are about my users and my constraints, not about patterns. I then record the decision, the option I rejected, the reasoning, and cause for revisit (a coupling number, a canary run, or a date. My build plan already has many dated decision revisits.)

The plan

So, I’ll try to build machines over reading. I’ll study the vocabulary. I’ll spend real time on external taxonomies and I’ll hire a human tutor in due course. I’m going to branch out from Claude, too, for tutors from other models.

And, later, I’ll hire a real reviewer – an outside engineer – to read the architecture and the security boundaries. I’m still working this out and the costs aren’t fully clear to me yet, but my intent is to use that review as a way to score the agents. I’ll publish these results.

Someone will no doubt point out that all the stuff I’m learning to do – mutation testing, unique indexes, CI gates, regression-per-bug, don’t-trust-the-harness, and so on — that’s ordinary software engineering and I’m simply learning it through a translator (the model). Yes, I think that’s right. My hope is that the translator plus the instruments is enough to build real software.

3 · Appendix: where I stand on the map

As I look at the map, here’s my self-assessment, which the outside reviewer will correct: I’m strongest on using agents and shaping the build; solid, for a self-taught outsider, on building AI apps except for evaluation method; weakest on security; and slow on architectural signals.

Against Ng’s expanded lists, there’s a bunch I’ll tackle when the build demands it (numbers are from my internal training list):

• Fine-tuning and self-hosting (1.1)
• Knowledge graphs, semantic layers over structured data, and document-to-LLM pipelines — PDFs, HTML — which Maximus doesn’t do and Dispositive will (1.2)
• Computer-use agents, generative UI, MCP and sandboxed tool access inside the product (1.3)
• Distillation and model-choice optimization for cost at volume (1.5)
• Storage types beyond relational (2.2)
• Monolith vs. microservices and stack selection by experiment (2.3) — done once, under duress, when Replit dropped all my tables
• Load balancing, sharding, replication, infrastructure-as-a-service (2.5) — untested past six accounts
• Team coordination of agent context (3.4) — I’m a team of one

And, here are the real existing gaps. The fix here is late, and my plan is mapped against them:

• Judge validation and held-out sets (1.4)
• Drift detection and prompt-injection defense (1.5) — no evidence in my record either way, and a voice product that ingests what users say is an injection surface
• Shift-left security: vulnerability scanning, dependency supply-chain checks, cloud-config attack surface (2.4)
• Parallel agents with a stop condition (3.2)
• User-flow tests with evidence, and the AI security and architecture audits (3.3)
• The MCP/skills/plugins ecosystem (3.4)
• Accessibility (2.1) — which for an 81-year-old starts with the voice itself, and extends to the account page the moment it exists

Perhaps out of reach for now: supervised and reinforcement learning, deep learning at “some depth,” training and evaluating my own models (1.6). Ng says every good LLM builder he knows has this. I do want to study it, out of interest.