Parts 2 to 4 were about the chip. This post is about how the work got done. Much of the hands-on work in this project was done by Claude Code, Anthropic's AI coding agent, working inside G2 and alongside one engineer. Here is how that worked, including where it went wrong.
Two roles
The split was simple:
| Claude Code | The engineer |
|---|---|
| ran the flows through G2's own commands | set the goals and the limits |
| read logs and reports | made the decisions: option A or B, which floorplan, “finish anyway” |
| diagnosed failures | asked the questions that changed direction |
| wrote scripts, fixes and write-ups | approved anything public |
Put simply: the agent supplied the hands and the engineer supplied the judgement.
One rule mattered from the start: every flow step goes through G2's API, the same sd -e commands that the WebUI's buttons call. The agent didn't run tools from ad-hoc shell scripts. When a step it needed had no API, that was a gap to report and build, not to work around. This kept every run in G2's records, where the engineer could see it.
2:11Watch on YouTube ↗Watch on Bilibili ↗
The unattended night
On 13 October at 21:40 the engineer handed over about ten hours with one instruction: go as far as possible, and stop only for real decisions. By 07:00 the next morning:
- otbn v5 was routed. Four route failures were diagnosed and fixed, one after another (the story is in part 2).
- Seven blocks went through post-route and finish, and their IP views (abstract LEF, timing models, black-box stubs) were generated.
- i2c went first: the new finish scripts were tested on the cheapest block before the expensive ones.
- Chip v2's scripts were staged: power grid and floorplan.
- Sixteen decisions were logged, each with a reason.
The decision trace
Every non-obvious choice got an entry with four parts: the time, what was decided, why, and tags. Two examples from that night: fold the re-timing into a G2 stage instead of a side script, and test the new scripts on the cheapest block first. Each entry is short, and the "why" line is what makes it useful.
Over seven days (13 to 19 October) the trace collected 101 entries. The engineer could review the whole night the next morning in minutes, instead of reconstructing it from logs.
Mistakes became rules
The agent made mistakes. Each one cost something, and each one became a written rule:
| What happened | The rule |
|---|---|
| A four-hour timeout that the agent set itself killed a placement run with no output. | No timeouts on long EDA runs. |
| It re-ran a block over an existing version and overwrote the first result. | A new version for every run. |
| It put probes in a scratch folder, outside the project. | Checks are G2 stages, in a test version, with a README. |
| It blamed the clock-tree tool for the SPEF bug. | Compare with what the same code gets right. |
| It proposed running chip timing inside OpenROAD. | Signoff stays in a separate tool. |
| It waited on conditions that could never come true. The engineer asked “why waiting?” three times. | Check that a wait can end, and make timeouts report. |
The SPEF case is the clearest example of the collaboration. The agent's first theory was plausible and came with one buffer traced as evidence. The engineer didn't argue with the evidence. Instead they asked a better question: the same file writes this module's synthesized nets correctly, so what is different here? That moved the search from the clock-tree tool to the SPEF writer, where the bug was (part 4).
The rules, written down for AI engines
The rules live in a plain-text guide that the next agent reads before it touches a G2 project. It has ten golden rules:
- Use the G2 API for every step.
- A new version per run.
- Checks are G2 stages.
- Ask before creating a test case.
- Ask before anything public.
- One EDA job at a time, at most 10 threads.
- No timeouts on long runs.
- Signoff timing in standalone OpenSTA.
- Timing analysis from G2's timing-path data.
- A demo run is not closure: note the leftovers and move on.
Some of these are engineering practice that any chip team would recognise. Others, such as "ask before anything public" and "check that a wait can end", are specific to working with an agent. Rule 5 covered the upstream bug reports: the agent prepared the issues and pull requests, and nothing was posted until the engineer said yes.
Why it works in G2
An agent that runs for ten hours unattended has to leave work that a person can review quickly and trust. G2's structure does most of that:
- Every run is a version. Nothing the agent does overwrites a result, so a bad run costs time but not data.
- Every step is a stage with its log, QoR summary and README. The agent writes the README at the end of a run: purpose, result, next step.
- Decisions are written down in the trace: time, what and why.
- One set of pages. The engineer reviews the same WebUI pages the agent writes to. There is no separate report to trust or distrust.
What we'd tell another team
- Give the agent a structure in which mistakes are cheap: versions, stages and a place to write down why.
- Turn each mistake into a written rule the next session reads. Corrections given only in conversation don't last.
- Keep the decisions with consequences, and anything public, with a person.
- Read the decision trace. It is the fastest way to review work you weren't watching.
Next, the last part: what a million-cell chip costs in memory and runtime on one laptop, and when more machines would help.