← Driving RustL1 · The Bargain
Score 0
1/6 Find the flaw

Which arrow gets refused?

Your agent drew the config path for a service. The server owns the config. A logger keeps a reference to read from. A hot reloader overwrites it in place, possibly while the logger is mid-read.

On your microcontroller this design shipped. In Rust one arrow is refused before it runs. Tap it.

the designL1·1
server(owns cfg)Configurl = db-aloggerhot reloaderownsreads (&)overwrites (&mut)r

Tap the part that will not survive contact with reality — or press 14.

2/6 Two designs — pick one

Hand it over, or copy it?

A 2 MB parsed document goes from parse() into store(). Nothing in the caller touches it afterwards.

The agent asks: move it, or clone it so the caller keeps its own copy? Pick one and say why.

the designL1·2
A · move itparse()store()2MBmemory in use2 MBB · clone it, caller keeps a copyparse()store()⧉ clone2MB2MBmemory in use2 MB
3/6 Judge the agent

The clone that made it compile

Your agent hit a borrow error in the request handler and reports a fix. Read it, then make your move.

the designL1·3
requesthandlersessionlogged_in = trueaudit()⧉ .clone()session′ (copy)logged_in = truelogout()
The agent says

The borrow checker complained that session was still borrowed when I passed it to audit(). I added a .clone() on the session before the call and it compiles now. It is a small struct, so the cost is negligible.

4/6 Judge the agent

When the borrow checker is right

Your agent is building a workflow graph, like your LangGraph nodes: nodes point to their neighbours in both directions. The compiler refused two ownership designs already. Here is the third proposal.

the designL1·4
intakeRc<RefCell<Node>>classifyRc<RefCell<Node>>replyRc<RefCell<Node>>escalateRc<RefCell<Node>>update(classify)
The agent says

Each node holds its neighbours as Rc<RefCell<Node>>. Rc lets several nodes share ownership; RefCell lets us mutate through a shared handle. It compiles, the graph API stays simple, and this is a standard idiom for graphs in Rust.

5/6 Put it in order

Answering a refusal

The borrow checker refused a design. Put your agent’s moves in the order you want them made, first to last. Then run it and watch the refusal travel the pipeline.

the pipelineL1·5
E0512345
    Level 1 cleared

    What survives this level

    designcompilerun · 3 a.m. C++ on the MCU ✕ torn readhard fault, no witness Rust ✕ E0506refused, with a witness ✓ runs same discipline, moved left clone · Rc<RefCell> · unsafe move it back right
    You can now say to a coding agent“If the borrow checker rejects it, tell me whose data it is before you reach for clone or Rc<RefCell>.”
    Added to your ledger
    Move semanticsHand data over by default; a move is free and forces you to say who owns it next.
    Borrowing as a design critic, not a ruleA borrow-checker rejection is a review comment on ownership; answer it with a design change, not a workaround.
    Clone / Copy and the cost of cheap duplicationA clone that exists to silence the compiler is a second owner nobody designed; ask what it is for.

    Back to the map Next: L2 When Rust, When Not →

    What clearing this level buys you
    “If the borrow checker rejects it, tell me whose data it is before you reach for clone or Rc<RefCell>.”