I don't think a reusable component has a useful fixed size. A button can be worth keeping. So can an entire sign-in flow. The question I care about is whether an agent can take the work into another project without making me explain the missing half.
This matters when you start saving work from coding-agent conversations. In the conversation, everything has context. The agent knows which files it just changed, which package you installed and why you rejected the previous version. Pull the final code out of that conversation and some of those assumptions disappear. You can save the right code and still lose what made it work.
That is a different problem from finding the code again. Retrieval can be perfect and the saved work can still be awkward to use.
The useful boundary follows the work
Suppose I save a button that depends on a theme provider. The component looks self-contained until I move it to a project without that provider. Now the agent has to discover the dependency, work out whether to bring it across and decide how to connect it to the new project's styles.
Saving the entire application would avoid some missing context, but it would create another problem. I wanted a button, not the routing, data model and deployment choices of the project it came from.
The boundary I want sits between those extremes. Keep the work I chose, along with enough information to understand what it expects around it. A dependency does not always need to be copied into the asset. Sometimes naming it and explaining why it is there is enough. What matters is that the next agent does not have to discover it by breaking things.
An auth flow has a larger boundary because the useful behaviour crosses files. Breaking it into isolated snippets can make it less reusable. The callback handling and the session checks belong to the same piece of work even if they are nowhere near each other in the repo.
I would rather save a complete idea than force everything into the same shape.
Leave room for the next project
There is also a difference between the part I want to preserve and the part I expect to change. The behaviour might be worth keeping exactly while the styling needs to fit a new site. An integration pattern might be reusable while its environment configuration belongs entirely to the next project.
If I don't make that distinction clear, the next agent has to choose for me. It might preserve something that should change, or rewrite the thing I saved it to avoid rewriting.
This is where I think AI is useful as glue. It can connect a known piece of work to a new setting. I still want it to reason about the differences. I just don't want every difference to become an excuse to generate the whole thing again.
Reuse is the check
A component that worked in its original project has passed a useful test, but it has not yet shown me that I chose a good reusable boundary. Moving it somewhere else exposes the assumptions I forgot to save.
That is how I want to think about the library I am building with Sirro. Saving is a starting point. Each reuse should help me understand whether the saved work includes too much, too little or the right amount of context.
The goal is not a library full of equally sized pieces. It is a library where the next agent can tell what a piece does, what it needs and what can change. Then the work I finished in one conversation can actually become a building block in the next.
Top comments (0)