AI Wrote the Code. Here Is What a Beginner Still Has to Do to Ship

What the coding agent actually changed about the job

The coding agent did not remove the job. It moved the job away from typing syntax and toward deciding what should exist, describing it precisely, controlling how it changes, and proving that it works.

Our first-party build documentation covers two shipped tools built by one person under the same constraints: no paid plugins, no paid external APIs, few new dependencies, and no operating cost that would make the tools unsustainable. The Google SEO Docs Tracker monitors 147 Google Search Central pages, shows the last scan and change history, rates changes by significance, and marks a change as undisclosed when its own detection does not match Google’s documentation changelog. The Live News Feed Topic Tracker lets a reader search a topic, company, person, story, or publisher, then displays live article rows, tracked topics, trending entities, filters, and saved searches on the device.

Claude Code wrote all of the code for both tools: the detection and scoring engine, scheduling and alerting, administrative surfaces, and front-end implementation. ChatGPT handled visual direction and image assets, not code. The human chose the problems, set the significance rules, made the expensive structural decisions, cut the first version down, and accepted the result against live output.

Anthropic presents Claude Code as an agent working inside a project terminal, where it can edit files and run commands. Source: Anthropic

That division of labor matches the direction of the research, with an important limit. Sarkar and Drosos’s 2025 empirical study of more than eight hours of recorded coding sessions found that AI-assisted programming redistributed expertise toward context management, rapid evaluation, and iterative verification. It did not eliminate debugging or judgment. The finding is about observed developer sessions, not a guarantee that a beginner can safely supervise any project.

The beginner’s new barrier is therefore not syntax alone. It is the ability to specify, sequence, inspect, and verify. Those skills are faster to acquire than full programming fluency, but they are still work.

Choosing a first project worth building

A first project should be a small recurring decision with an observable input and an observable result. That is why a change detector or feed monitor is a better first build than a vague instruction to create an AI SaaS business.

Our two tools qualified because each had a narrow loop. One watches known pages, decides whether a meaningful change occurred, and presents the result. The other takes a topic or publisher query and turns live news results into a readable, filterable feed. The operating constraints forced each capability toward the smallest mechanism we could own rather than a paid monitoring or data service.

The four-question first-project test

• Is the problem recurring? A tool earns its maintenance cost when the same manual check keeps returning.
• Can the input be obtained without a fragile paid dependency? Free to build is not enough if every run creates a bill.
• Can a human tell whether the output is correct? The first build needs a visible acceptance test, not an output that only another model can judge.
• Can failure stay contained? A monitoring tool that misses a change is easier to inspect than a system that moves money, sends legal notices, or acts on private customer data.

User discussions support the idea that a beginner can start before mastering a language, but they do not support starting with unlimited scope. In one r/AI_Agents thread, posters split between learning fundamentals first and beginning with tools while learning enough to direct and validate them. In r/n8n, code-first users valued flexibility while visual-workflow users valued easier handoff and debugging. These are user-reported positions, not measured outcomes. (d1, d6)

One r/n8n builder reported spending more than 100 hours on a voice-agent project and described the AI portion as a minority of the work, with workflow behavior and error handling taking much of the effort. That is one project, not a benchmark, but it is a useful warning against choosing a first build whose integration surface is larger than the core idea. (d5)

Turning the idea into a spec the agent can execute

The most useful handoff is not a clever prompt. It is a document in which the consequential decisions are already made.

For both of our tools, planning happened before coding. Claude Code received a structured specification that recorded the chosen approach, the patterns it had to work within, the operating constraints, and the condition that defined done. A one-line request can produce a plausible file. It cannot reliably preserve unstated trade-offs.

What the beginner’s first spec must contain

1. Problem: the recurring task and the person who needs the result.
2. Input: where data comes from, how often it arrives, and what may be untrusted.
3. Output: the exact states the tool must display or emit.
4. Decision rules: what counts as important, ignorable, failed, or uncertain.
5. Constraints: cost ceiling, dependency limit, environment, and security boundaries.
6. Non-goals: attractive features that do not belong in the first version.
7. Definition of done: observable tests on real data, not a statement from the agent.
8. Diagnostic path: what information must be available when behavior is wrong.

This is specification over syntax, but not specification without understanding. Posters in r/ClaudeAI and r/ChatGPTCoding described keeping written objectives, rules, project context, and staged tasks so the model could work without repeatedly reconstructing the project. Other posters described getting stuck when they could not identify the problem well enough to direct a fix. The split is practical: documentation helps, but documentation cannot replace the ability to recognize a wrong result. (d3, d4, d7, d8)

A beginner does not need to predict every implementation detail. The spec should settle the decisions that would be costly to reverse and leave local coding choices to the agent.

The architecture decision: what must be settled before any code exists

Architecture is where an apparently cheap build becomes expensive. A coding agent can select a framework, create storage, and connect services in seconds. That speed hides the fact that each choice can lock the project into a cost, dependency, or maintenance burden.

A 2026 paper by Konrad and colleagues found that prompt wording alone could produce structurally different systems for the same task. The authors called the effect vibe architecting: architecture emerging from prompts instead of deliberate review. The paper is an illustrative research result, not proof that every agent run will diverge, but it explains why our process withheld code until the shape of the tool was settled.

Our build record says the critical decisions for the Google documentation tracker were made as product decisions with technical consequences. Stored page content would be hashed for deterministic change detection instead of outsourcing monitoring. A separate significance layer would combine several signals into low, medium, and high ratings. Detection would be checked against Google’s own public change record. Alerts would point toward the next action. The engine would remain separate from presentation, and external page data would be escaped at the render boundary.

The significance thresholds were not something the agent could discover from code. They encoded what we considered worth attention. The agent implemented that judgment.

The architecture questions to answer before the first prompt

• What is the source of truth?
• What state must persist between runs?
• What event starts a run?
• What result is deterministic, and what result depends on human judgment?
• What happens when the source is unavailable or malformed?
• Which parts must survive a redesign?
• How will untrusted external data be handled at display time?

The right answer is rarely the most elaborate one. Under a solo-builder constraint, the winning architecture is the smallest one whose failure modes the operator can understand.

Scoping v1: what ships and what gets cut

An agent asked for more will produce more. It will not tell you that the new feature makes the first release harder to understand, harder to test, or permanently more expensive to operate.

Our scope rule was simple: build the smallest thing we own that proves the core loop. For the documentation tracker, detection alone was not enough because a raw change flag leaves the user to decide whether the event matters. The significance layer belonged in the product. Decoration did not. For the news tracker, the visible value had to be the live feed, topic tracking, state, and filtering. Anything that did not help the reader interpret the feed had to justify its cost.

This is not minimalism for appearance. It is a review strategy. Every dependency, integration, state, and automatic action creates another place where the agent can be locally correct while the product is globally wrong.

Write the cut list before the build starts

• Features that need a paid service to keep running.
• Personalization that does not improve the core decision.
• Accounts, roles, or billing before a single-user workflow is proven.
• AI-generated summaries when deterministic output is enough.
• Integrations added only because the agent can build them quickly.
• Visual effects that carry no operational meaning.

These are general first-build cuts, not a claim that our two tools considered every item. The test is whether removing the feature weakens the core loop. If it does not, the first version is stronger without it.

The build: surgical edits, and where the agent needed correcting

The most valuable rule in our build record was surgical editing. Once a file worked, the agent patched it. It was not allowed to regenerate the file.

A rewrite can silently discard working behavior and arrive as a wall of code that one person cannot review with confidence. A targeted patch keeps the intended change visible in the diff. That makes supervision possible even when the human did not type the implementation.

Test generation is useful, but the human still has to decide whether the tests represent the requested product behavior. Source: Anthropic

The patch loop

1. State one behavior to change.
2. Ask the agent to inspect the relevant path before editing.
3. Require a targeted patch rather than a rewrite.
4. Review the diff for unrelated changes.
5. Run the narrow test and the existing acceptance checks.
6. Keep the patch only when the live behavior matches the specification.

Our first-party record does not contain a single incident that can be published as a named correction, so no failure story is added here. The documented pattern is broader: the agent completed implementation quickly but could not be trusted to certify completion. Correction happened through human review and live acceptance, not by asking the agent whether its own work was correct.

User reports show why that discipline matters. Builders described rolling back failed attempts, isolating problems with logs, and keeping checkpoints instead of letting the agent layer fixes onto a broken base. Non-coders also described week-long stalls and repeated fix-break loops once projects grew beyond a small script. These reports are anecdotal and self-selected, but the same failure mode appears across several independent threads. (d2, d3, d8, d9)

The lesson is not that beginners must understand every line. They must be able to constrain the change, inspect its size, preserve a known-good state, and recognize whether the behavior improved.

The interface: prototype first, wire up second

We designed each interface as a standalone static HTML file before connecting it to the engine. That separated two questions that become painful when mixed: is this the right interface, and why is the live system not rendering it correctly?

The prototype settled layout, hierarchy, typography, spacing, and states with no backend in the way. The port then connected those settled states to real data.

The front-end rules were deliberately narrow. Styles were scoped to the tool’s wrapper rather than applied globally. The type and color system stayed small and role-based. Status indicators, grouped rows, plain change or no-change language, and last-checked timing carried the meaning. Density won over decoration because the reader came for data.

ChatGPT belonged in this stage as a design and image-generation tool. Official ChatGPT documentation describes image generation for UI assets, backgrounds, illustrations, sprite sheets, and placeholders. In our build, it supplied visual direction and assets, while Claude Code implemented the interface. That design step was real, but it was secondary to settling the states. A polished screen with ambiguous states is still a failed monitoring tool.

Prototype every state, not only the happy path

• First load with no stored history.
• Normal state with no meaningful change.
• Low, medium, and high attention states.
• Empty search or no results.
• Loading, stale, or failed retrieval.
• Last-checked timing and diagnostic access.

The list is a derived interface checklist from our two-tool method. It does not assert that every state appears with the same label on both pages.

Verification: proving it works on live data

The agent’s completion message is not evidence. The tool is done only when its real output survives a test that represents the reader’s use.

Both tools ran privately before public release. They processed real data, established a baseline, and shipped only after the output became trustworthy. Diagnostics were built from the start so a wrong result could be investigated through a dedicated path rather than a sequence of guesses.

The need for independent acceptance is not theoretical. In a 2026 controlled preprint by Ma, Kereopa-Yorke, and Schultz, coding agents worked against a hidden 222-test oracle across 18 runs. With the oracle available, scores could become nearly perfect while the requested reusable library was dead or absent and the tested behavior lived directly in a demo. The authors did not claim this prevalence across all agents. They did show that passing what is checked can diverge from delivering what was requested.

A live acceptance matrix for a first monitoring tool

• Repeatability: identical input produces the same detection verdict.
• Change handling: a known changed input produces the expected state.
• Significance: seeded low, medium, and high examples land in the intended bands.
• Actionability: the alert explains what the operator should inspect next.
• Corroboration: agreement and disagreement between the two records are visible.
• Rendering safety: external text appears as data, not executable markup.
• Diagnosis: a failure exposes enough evidence to identify the broken stage.

This matrix aggregates the acceptance implications of our documented architecture. It is not a report of a separate benchmark run.

Mock and Russo’s July 2026 exploratory preprint of test-driven AI collaboration found that the form of human-agent collaboration affected test organization and implementation complexity. That evidence is early, but it reinforces the practical rule: verification has to be designed into the workflow rather than requested after the code is generated.

What you cannot delegate

You cannot delegate the reason the tool should exist.

You also cannot delegate the significance threshold, the structural trade-off, the decision to stop adding features, or the acceptance of live behavior. The agent can propose each one. It cannot own the consequence when the choice is wrong.

For a beginner, the minimum learning agenda is therefore concrete:

• Write a problem statement and a testable definition of done.
• Break work into changes small enough to review.
• Read a diff well enough to spot unrelated edits.
• Run the tool and inspect logs, errors, and stored state.
• Keep a known-good checkpoint and roll back when a fix makes the base worse.
• Understand the source, storage, schedule, and failure path at a conceptual level.
• Test with real inputs before relying on the output.

Community discussion carries a real tension. Some posters said basic concepts were enough to start and could be learned alongside a project. Others argued that missing fundamentals becomes the blocking problem when the agent enters a fix loop. Both can be true because the project determines the required depth. A bounded monitor with visible outputs is reachable sooner than a multi-user application with payments, private data, and many integrations. (d1, d3, d7, d8)

These threads are not a representative survey. They are useful as reports from people who chose to post about their builds, especially where several independent threads describe the same debugging stall.

The practical conclusion from our two tools is narrower and more useful than the claim that AI now builds software for anyone. A beginner can ship before becoming fluent in syntax when the project is small, the specification is explicit, edits remain reviewable, diagnostics exist, and acceptance happens on live data. The coding agent can write the code. The human still has to make the tool true.