DEV Community

Jonathan Berg
Jonathan Berg

Posted on

Your coding agent should start from your library

Every new project used to start the same way for me. I would open Cursor or Claude Code, explain what I wanted, and then spend the next hour describing things I had already built somewhere else.

The authentication flow was sitting in one repo. The pricing section I liked was in another. A good way to structure the dashboard had disappeared into an old conversation. None of it was really gone, but none of it was available either.

That is a strange way to build software. The more work I shipped, the more useful material I left behind. My experience was growing while the agent still started every project from zero.

This week I tried to reduce the whole problem to four words: create, connect, save, reuse.

Create something worth keeping. Connect the tools you already code with. Save the finished work to a library. Reuse it from any project and any agent.

It sounds obvious when the loop is drawn out. In practice, most coding agents stop after create. They help produce the component, fix or pattern, then leave it inside the conversation where it happened. The next conversation has no idea it exists.

A conversation is a bad place to keep finished work

Conversations are useful while something is uncertain. You can explore an approach, reject a few versions and explain what feels wrong. The problem is that the finished result stays mixed together with all of that process.

Six weeks later, finding it means remembering which agent you used, which project was open and roughly what you said. Even if you find the thread, the agent still has to work out which part was the final version and why it mattered.

This is where people reach for longer prompts. They write another paragraph explaining the old component, paste a few snippets and hope the new agent reconstructs the same idea. Sometimes it does. Sometimes it gives you something close enough that you only notice the differences after you have started building on top of them.

I do not want a better guess. I want the thing I already approved.

Libraries change how the next project starts

A saved asset is more than a code snippet. It is a decision you do not have to make again.

The useful part may be a React component, a database pattern, a working integration or a short note about why one approach failed. What matters is that it has crossed the line from conversation into something named and reusable.

Once that happens, the next project can start with the library you have built through actual work. You can ask Cursor to save a component today and pull it into Claude Code next month. The value is not tied to the chat, repo or agent that happened to produce it.

This also changes the economics of getting better at AI-assisted coding. Normally the agent gets another chance to generate every time. A library lets your own work compound. Ten finished projects should make the eleventh easier because the good parts are already there.

Memory should include things, not only facts

A lot of agent memory is described as information about the user: preferences, instructions, summaries and facts. That is useful, but builders also need memory of the work itself.

Knowing that I prefer a certain kind of pricing page is weaker than having the exact section I chose. Remembering that we solved an OAuth edge case is weaker than keeping the fix and the reason the obvious approach failed. A summary can guide another generation. An asset can become part of the next product.

This is the difference I care about. The goal is not to make an agent sound more familiar with me. The goal is to stop leaving useful work behind.

When the library grows, coding becomes less conversational and more compositional. You still use agents to explore and create. You just stop asking them to recreate every good idea from a description.

The agent should start from what you have already built, not from what it can guess you meant.

Top comments (0)