Imagine a community workshop with two small applications. One lets people book classes. You’re adding tool rentals to the other.

The request sounds simple: choose a tool, pick some dates, confirm the booking. The class-booking app already has a calendar. It supports keyboard navigation, marks unavailable dates and fits the site’s design. There’s a good reason to look at it before building another one.

Then try booking a CNC machine from Friday to Monday. Both dates are free, but someone else has it on Saturday. A calendar that only checks the start and end dates would accept a booking the workshop can’t honor.

Reusing the calendar could save work on accessibility and interaction. It could also carry over an assumption that makes sense for classes and fails for rentals. I’d want to understand that before deciding how much of it to share.

Look beyond the ticket#

Writing in September 2026, I’d expect a capable coding agent to make this feature much easier to build. I don’t have a measured speedup to put on that. Agents can inspect repositories, implement changes and work through verification. Anthropic’s July release, for example, reports stronger debugging and self-checking in its evaluations and early-user accounts.

If the agent’s task and access stop at the rental application, though, I wouldn’t expect it to routinely discover a component in the separate class-booking project. I’d point it there or make the connection available in the project documentation.

With both applications in view, it might find the opportunity itself, or notice a reason to reject it that I missed. I’d ask it to compare them:

Inspect the calendar in the class-booking application before implementing tool rentals. Classes use individual sessions; rentals occupy a continuous period. Assess which behavior can be shared, what would need to change, and whether the maintenance cost justifies sharing it. Check how your recommendation affects both applications.

The longer version also gives a local model such as Qwen3.8-27B a zero-shot starting point: instructions without worked examples. A 4-bit version can run on a high-end consumer GPU in the 24 GB class, such as an RTX 4090; Unsloth’s local-running guide covers the quantized options. Giving the agent both projects is a setup step: make the repositories available and point it to the relevant code.

I use different context profiles for local work in OpenCode. I’ll cover that setup, and when I switch profiles, in a separate post.

With today’s more capable models, such as GPT-6 Astra or Claude Fable 5.1, I’d often start with something shorter:

Check whether the class-booking calendar is a good fit for tool rentals before building a new one.

Given access to both projects, I’d expect the agent to work out much of the comparison. The short prompt directs its attention to an existing component before a fresh implementation gets underway.

Knowing that the second application exists changes the request. So can a conversation with the person managing bookings: they may tell you the tools need an inspection between rentals, which changes what “available” means.

I’d write that rule down where the agent and the next developer can find it. OpenAI’s account of building with Codex describes the work of making project knowledge accessible and providing tools for verification. Giving an agent that environment takes engineering effort too.

What does an available date mean?#

In our workshop example, a class booking reserves a place in one session. A tool rental occupies the same physical item for an interval. A calendar that disables individual dates may have useful presentation and interaction behavior without having the rules the rental application needs.

Does a Friday-to-Monday rental include Monday? Can a tool returned in the morning go out again that afternoon? If it needs an inspection, the calendar has to account for that time.

An agent can surface those questions and propose sensible defaults. Someone responsible for the workshop still has to settle the policy. A plausible default could promise a tool to two people who both need it.

I’d start by investigating whether the calendar’s display and keyboard behavior can be shared while each application keeps its own booking rules. If supporting rentals requires a tangle of exceptions in the class calendar, keeping separate components may cost less over time. Sharing the underlying calendar library might be enough. I’d want the people maintaining both applications involved in that choice.

Try the booking that should fail#

The Saturday conflict gives us one check. I’d also ask the agent what happens when availability changes after the calendar loads. The server needs to check availability and reserve the tool as one operation, so two simultaneous requests can’t both claim it for the same period. A disabled date in the browser can’t provide that guarantee.

Then I’d ask it to exercise the class-booking application too. Sharing code creates a responsibility to the existing consumer. Its keyboard navigation and session selection still need to work after a change made for rentals.

The agent can implement these checks, run them and investigate failures. To review that work, you need enough technical understanding to see what the tests leave unproven. If they confirm two highlighted dates but never attempt a reservation, there’s still work to do.

Bring the useful history#

That investigation costs tokens and time. Asking an agent to understand another application and reproduce its behavior can cost more than asking it to write a new calendar. I’d want the investigation to lead to actual reuse, or to a decision informed by what we found. Recreating a component after a long explanation of how it works leaves us maintaining two implementations anyway.

If I already know the relevant file, limitation or earlier decision, I’d include it at the start. Suppose the calendar already supports rejecting a range that crosses an unavailable day, but the rental application hasn’t enabled that option. Pointing the agent to that option could turn a proposed rewrite into a small configuration change. It might be one line; the behavior still needs checking.

Useful history includes attempts that failed. If an agent starts circling back to an approach we’ve rejected, I’d bring the failed check and the reason back into view. An earlier message may no longer be in its working context, or its account of that attempt may be wrong. A recorded result gives it something firmer than reconstructing what happened from the current code.

I’d write those notes as the work happens. In the calendar example, a handoff should tell the next agent which component we’re considering, why the booking rules differ, what we’ve tried, which checks pass and what remains unresolved. A new session can read that record before touching the code. Without it, the next agent has to rediscover decisions the previous one already worked through.

I use planning-with-files for this and keep the answers from discussions that challenge a design. Those records explain what led to a decision, including the alternatives we rejected. Update them when the plan changes, and leave a clear next step. When another agent picks up the task, ask it to read the notes and check them against the current code. Stale documentation can send it down the wrong path just as an incomplete prompt can.

I also ask for commits as we go. “Finish the feature” doesn’t specify the checkpoints I want along the way. Depending on its setup, an agent can satisfy that request by leaving working changes in the checkout. I put the checkpoints I want in the repository instructions:

Work on a feature branch in a dedicated worktree. First write a test that reproduces the problem, confirm that it fails for the expected reason, and commit that checkpoint. Implement the change, run the relevant checks, and commit the passing solution. Keep unrelated cleanup in a separate commit. Record what each checkpoint proves.

For the calendar, the first checkpoint would demonstrate that a Friday-to-Monday reservation incorrectly succeeds when Saturday is taken. The next would contain the fix and show the same test passing. If a later change breaks bookings, we have a failure we can reproduce and specific versions to compare or return to. Frequent commits are useful when their boundaries tell us something; saving every small edit wouldn’t give us the same clarity.

That makes recovery less dependent on the agent remembering the conversation or explaining its own changes correctly. Tests record the behavior we expect, commits preserve the code that produced it, and a short decision note explains why we chose that approach.

Know when to step back#

After a failed fix, an agent may add another patch on top of the current code, then another. It’s still trying to finish the task, and it may keep repairing the approach it has without revisiting the decision that led there. I’d watch for that pattern instead of assuming it will stop and compare earlier versions as the current one gets more complicated.

I’d put a trigger for that review in the instructions too:

If a fix fails or needs another workaround, compare the current changes with the last passing checkpoint before adding more code. Explain whether to keep the approach, revise it, or return to an earlier version, using the test results and decision notes.

An agent can make that comparison and recommend going back. Asking for it during development gives us a chance to recover a simpler solution before more work depends on the latest patch.

Make your judgment visible#

If I were trying to stand out as a developer now, I’d make this reasoning visible in the work I submit. A note saying “added date selection” leaves the reviewer to discover the hard parts. In this example, a useful note would explain why we considered the other calendar, which booking rules stayed separate, and how we checked the Saturday conflict. It should also name who maintains the shared behavior and the cost that could make sharing a bad choice.

You can practice this on the next feature you pick up. Before implementation, find a related piece of work or talk to someone who uses the application. Give the agent what you learn. Then choose a case where the feature could look finished while failing that person’s need, and follow it through the system. Include the other applications affected by shared code. Leave enough of the reasoning behind for someone to question your decision.

There is some current evidence for investing in that understanding. Anthropic’s June 2026 analysis of roughly 400,000 Claude Code sessions found that greater domain expertise was associated with better outcomes. It was observational research on one product, and the intermediate-to-expert gap was modest. It supports developing domain knowledge without promising that experience guarantees success.

Back at the workshop, I’d give the agent the two applications and the booking rules, then let it investigate and implement. Before accepting the result, I’d try that Friday-to-Monday reservation. If Saturday is taken, the system needs to say so before someone makes plans around using the CNC machine.