Research and Prototyping¶

AI agents are at their best before a single line of production code is written. The cost of trying an idea has dropped so far that you can now test whether an idea is even worth pursuing in an afternoon — building a throwaway prototype, comparing design options head to head, or having the agent dig through documentation and known issues while you plan.

This page is about using AI for the fast, cheap, disposable front half of engineering: research and experimentation. The goal is to learn something, not to ship the thing you build.

Where this meets the limits. AI's knowledge is frozen at its training cutoff (limitation #3), so for anything that moved recently — a library's current API, a freshly reported bug — the agent's built-in memory is stale or wrong. The fix is to pull current information into the session at research time. The tools for that come below.

Cheap prototypes, live docs, and why you throw the first version away — 1 min 41 s.

Cheap MVPs to test an idea¶

Before committing a sprint to a feature, build the smallest thing that answers "is this even a good idea?" An agent can stand up a rough end-to-end slice — a script, a stub UI, a fake-data pipeline — in minutes. You run it, you learn, you decide.

The mindset shift: the prototype is an experiment, not a deliverable. Its job is to produce a yes/no answer, not clean code. Judging a prototype by its code quality misses the point — judge it by what it taught you.

Throw it away and rebuild cleanly¶

This is the discipline that makes prototyping safe. A fast prototype is full of shortcuts, hard-coded values, and skipped error handling — exactly the things that make it fast. Do not promote that code to production. Once the prototype has answered its question, throw it away and rebuild the real thing cleanly, now that you actually understand the problem.

The first version taught you the shape of the solution. The second version is the one you maintain. Trying to "clean up" a prototype into production code usually keeps the hidden bad assumptions and loses the speed advantage you bought.

Compare design options¶

When two or three approaches are plausible and you cannot tell which is better on paper, build a small version of each and compare. This pairs naturally with parallel sessions and worktrees: one isolated workspace per option, evaluated side by side, then keep the winner and discard the rest. Concrete comparison beats argument — you see the real ergonomics, performance, and complexity instead of guessing.

Search docs, known issues, and examples during planning¶

Some of the most valuable research is not building at all — it is having the agent gather current information before you design. Ask it to:

pull the up-to-date API for a library you plan to use,
find known issues or breaking changes in the version you are on,
surface real-world usage examples and common pitfalls.

This is precisely where the training-cutoff limit bites, so lean on tools that fetch live information rather than trusting the model's memory:

Built-in WebSearch and WebFetch are the simplest first line: Claude Code can search the web and pull a specific page into the session on its own, so a quick "what's the current way to do X?" gets answered against today's internet, not the training data. Reach for these before anything heavier.
context7 injects current, version-specific library documentation and examples straight into the agent's context — so it codes against the API that exists today, not the one that existed at its training cutoff. See context7 and the Skills and plugins guide.
The deep-research skill runs a multi-source, fact-checked research pass — fanning out web searches, fetching sources, verifying claims, and synthesizing a cited report — when you need a thorough, current answer rather than a quick guess. Also covered in Skills and plugins.

For everyone: when an agent confidently describes a library's API, ask yourself "how would it know the current version?" If the answer is "from its training data," it may be out of date. Pulling in live docs via context7 or a research pass turns a confident guess into a checked fact.

Explore safely with branches and forks¶

Research means trying things that might be wrong — that is the point. Keep that risk off your main line of work. Use a throwaway git branch or a dedicated worktree for each experiment so a dead end is deleted with a single git worktree remove or branch delete, leaving your real work untouched. Nothing speculative should ever ride directly on your main branch.

The caveat: the developer still owns the hard parts¶

Cheap experiments can make it feel like the AI is doing the engineering. It is not. The agent can generate options and prototypes quickly, but the judgment that makes research useful stays with you:

Domain understanding — what the problem actually is, in your field, with your data.
The product goal — what "good" means for users and the business; the agent does not know your roadmap.
System constraints — the real performance budgets, the database you must use, the regulations you must meet, the legacy you cannot break.
The real-world test procedure — deciding what counts as evidence that the idea works. A prototype that runs is not a prototype that succeeds; you define the bar and you check against it.

Bottom line: AI makes the trying cheap. It does not make the deciding automatic. The faster you can prototype, the more your value concentrates in choosing the right questions and judging the answers — which is exactly the work the AI cannot do for you (limitation #2: no genuine understanding of your goals carried across time).