Don't Sleep on Claude Cowork: How We Used It with Claude Code for EF-Map

This is not an "AI is amazing" post. The useful thing about Claude Cowork is much more specific: it can act as a product reviewer that understands both the live browser and the repo behind the page.

For EF-Map, that matters because the product is not just a static website. It is an authenticated, wallet-connected EVE Frontier tool with a 3D map, docked panels, Cloudflare APIs, Sui-era Intelligence data, route sharing, helper status, and a static State of the Frontier report surface. A normal screenshot audit misses too much. A pure code review misses the feel of the live app. The browser-and-repo loop is the useful middle.

The naming we are using

Anthropic's current product page calls the product Claude Cowork by Anthropic. The browser extension surface is documented as Claude in Chrome, and Claude Code is the coding tool that reads a codebase, edits files, runs commands, and works across development tools. In practice, our workflow used all three ideas: Cowork for the product-audit handoff, Claude in Chrome for browser visibility, and coding agents for implementation.

Why EF-Map is a good test case

EF-Map has the awkward shape most serious tools have after enough real use. The core is strong, but the product questions are cross-cutting. Does search open the right panel? Does a report deep-link back into the map? Does a copy action show feedback? Does a share card help a scout post useful context in Discord? Does a 1080p user still see enough map when a wide panel opens? Does a phone user understand what is and is not supported?

Those are not isolated tickets. They require the reviewer to move through the live app, inspect authenticated states, observe UI density, then read the repo to tell whether an issue is real, already fixed, or out of scope. Claude Cowork was useful because it could work from the same session the app actually uses. That included a signed-in EF-Map session, panel state, helper status, and live pages like State of the Frontier.

The browser access point is important. Claude in Chrome can read the page, click through workflows, and inspect console, network, and DOM state when asked. Because it works in the browser session you choose to expose, it can review authenticated product surfaces without asking you to fake every state in a prompt. I could still keep normal browser tabs around and steer the review, but I treated the EF-Map tab as delegated access, not as a place to hand over secrets or approve risky actions blindly.

The workflow that worked

The loop was simple and deliberately separated from implementation:

1. Claude Cowork audits the live product. It opens EF-Map in the browser, uses the authenticated session, exercises panels, checks responsive assumptions, and cross-checks the repo.
2. It writes an audit report, not a patch. The report lists what was reviewed, what was browser-verified, what was repo-inferred, what should stay unchanged, and what should be split into implementation batches.
3. ChatGPT chunks the report. The big report becomes smaller prompts with explicit scope, non-goals, validation steps, and deployment expectations.
4. GPT-5.5/Codex implementation agents build the scoped changes. They read the report, edit the repo, run checks, deploy previews or production as appropriate, and report what changed.
5. The next Cowork pass audits the result. It looks for regressions, missed feedback, stale copy, layout issues, and whether the new behavior actually closes the loop.

The key point is that Cowork did not have to be the best implementer to be valuable. The report was the artifact. It turned ambiguous product instinct into a queue of small, verifiable changes.

What it found for EF-Map

The most valuable audit was not a generic "make it prettier" pass. It identified loops that were almost complete, then told us where the last click was missing.

UI and UX polish

The first broad audit covered the map, search, hover cards, context menus, Solar System View, routing, Smart Assemblies, Compare Regions, Leaderboards, User Overlay, Help, Map Layers, EF Helper, LIVE stream, Profile, and Intelligence. The strongest recommendation was practical: system search should reuse the existing Intelligence panel instead of creating a separate result path. That became a clean product improvement because it reused an existing surface instead of inventing a new one.

Feature bar, icons, and naming

EF-Map has a lot of power-user tools. Cowork was useful for spotting where an affordance was present but not obvious enough, or where a label sounded like implementation language rather than player language. This helped keep feature-bar and panel naming focused on what the player is trying to do: search Intelligence, inspect routes, open Solar System View, compare regions, or view the weekly report.

Help affordances inside dense panels

The repo already had strong help content, including Smart Assemblies help. The audit value was not "write more docs." It was noticing where a user would need help at the moment of use. That is a better prompt for an implementation agent: surface existing help near the panel action, keep the text short, and do not add a new documentation system.

State of the Frontier

State of the Frontier started as a strong report surface, but the audit called out a critical gap: it was a content dead end. Systems, players, and tribes were discussed in the report, but readers had too few paths back into the map. The implementation batch added deep links, report-to-map actions, activity metrics, and a Founder Access callout. That moved the report from "interesting page" to acquisition and exploration loop.

Engagement and share loops

A later audit focused on whether EF-Map had repeatable loops, not just features. That led to copy feedback, Intelligence summaries, route notes, short /s/ links, 1200 by 630 PNG cards, QR codes, and report cards. The point was not social garnish. A route, player, tribe, or weekly report becomes more valuable when a scout can move it cleanly into Discord, Reddit, or a corporation planning thread.

Return and polish hooks

The same process produced small return hooks: a new-issue dot on the Frontier Report button, a restrained count-up on weekly report metrics, and a search-arrival pulse on the map. Those changes worked because the audit was explicit about restraint. No confetti, no badges, no noisy animation, and respect reduced-motion preferences.

1080p and mobile audits

Cowork also produced audits that did not immediately ask for code. The 1080p desktop audit found EF-Map workable, with optional comfort fixes for wide analytical panels. The mobile audit was more important: it confirmed that the map can load and the report page is responsive, but the desktop panel system is not a real phone experience. The recommendation was an honest mobile gate and, later, read-only companion surfaces, not a risky rewrite of the full tool.

Why report handoff beats direct implementation

For this kind of product work, the best output is a structured brief. It should say what was reviewed, how it was verified, which claims are browser-verified versus repo-inferred, what the risk is, and what not to change.

That matters because implementation agents are strongest when the shape of the work is already bounded. "Improve engagement" is too broad. "Add transient copy feedback to these buttons, deep-link report entities, reuse the existing share-card renderer, respect reduced motion, and do not touch the route burst animation" is implementable.

This also reduces churn. The audit can explicitly say "do nothing" when an idea is not worth it. In one engagement pass, Cowork recommended pausing additional micro-interactions after the share and return loops were closed. That is a good product outcome. A tool that only generates more work is not helping.

A practical recipe for builders

If you want to use the same pattern on your own project, start narrow:

1. Pick one surface. Example: search, onboarding, a report page, a pricing flow, or a dense admin panel.
2. Give Cowork the live browser and the repo. Let it inspect the actual state users see, including authenticated views when safe.
3. Ask for an audit report only. Include sections for evidence, severity, specific fixes, non-goals, and a smoke checklist.
4. Convert the report into batches. Use ChatGPT or your normal planning tool to split it into small prompts for Codex or your implementation agent.
5. Keep verification boring. Build, run type checks, deploy a preview when appropriate, and use a follow-up browser audit to confirm the change behaves in the live product.

Caveats

There are real limits. Browser agents can click things, so do not expose admin actions, irreversible flows, private data, or secrets unless you are intentionally supervising those steps. Authenticated review is powerful because it sees the real product, but that also means you need clear boundaries.

The browser surface can also be wrong about viewport testing. In one EF-Map audit, resize commands reported success while the rendered viewport stayed pinned to a desktop size. That made the report useful only because it said which claims were observed and which were inferred from CSS. A good audit should make uncertainty visible.

Finally, keep the model separate from the method. Claude Cowork, Claude in Chrome, Claude Code, ChatGPT, and Codex each have different strengths. EF-Map got value by using them in sequence: audit, summarize, scope, implement, verify. Treating one agent as the whole team would have produced worse work.

The EF-Map takeaway

The best use of Claude Cowork for EF-Map was as a browser-and-repo-aware product reviewer. It turned live UX concerns into concrete implementation briefs for the existing agent workflow. The resulting changes were small, practical, and measurable: better Intelligence search, clearer panel affordances, report deep links, share cards, return hooks, and clearer boundaries around desktop versus mobile.

That is the part worth copying. Not the novelty of a browser agent, not the model label, and not the idea that every audit finding should become code. The value is a clean handoff from real product observation to scoped engineering work.