Where do you talk to Amp most: terminal, editor, web, phone, Slack?
Mostly in the Mac app, then the phone.
Favorite mode, and when do you switch?
Medium. It’s the best combination of smarts and getting shit done. I only opt into Ultra when I am
not sure what to do or for frontend-heavy changes.
Do you still develop locally? If so, when?
No development. The only local things I do is reading some code from time to time or reading the
prompt files end to end.
What’s a workflow with Orbs that you absolutely love?
I love competitor research. I have a bunch of automations set up that just check out codex, pi,
t3-code and opencode and look at the last day’s changes and then summarize it. Otherwise bug fixes:
I have a bunch of prebuilt prompts, which I just fire off with a bug report in an Orb. And I just
fire off a bunch of them, come back after an hour and review them in bulk.
How do you review changes?
I have a few prompts that I use for it to explain the code changes and explain the critical
changes. I usually read through it and probe the models with questions I have. Then I peek into the
edits that are load-bearing or are in the core paths of Amp (billing, thread coordinator, …), but
that’s mostly spot checks and nothing beyond it. I usually have Amp run through the validations and
show me proof.
Which skills, plugins, or MCPs do you use? Anything you built for yourself?
I have a Google Workspace MCP that I use. I have a Linear MCP that I use with my sister to build her
homepage. I have a bunch of skills around learning and teaching.
How do you use Puck?
Not much for launching threads to be honest, mostly for setting up automations, projects, and
editing the settings. I sometimes have it look into my emails and launch a few threads, but that’s
the extent of it.
What’s a prompt or phrase you keep reusing?
I have loads. Explain:
Explain the changes made. Explain how this works from a user perspective and what then happens in the background (show a diagram for the flow and the main changes to the existing logic and why). Explain how other code paths or flows could be impacted by this change. Explain how agents and/or users are supposed to use it. Less than half a page, limit long paragraphs and sentences so it is skimmable.
Thread debug:
Investigate this thread. Run a root cause analysis of the prompts that could have caused it. Take your time. Read through the thread, look at the thinking summaries, look at the user instructions. Identify first the wrong behavior specifically, then the instruction (or set of instructions) that caused it (user, AGENTS.md, system prompt -- you are in the coding agent repo).
Critical:
What are the critical pieces of code that have the highest impact? Show me them, the files, highlight the code, and explain what they are changing and now doing in context, and how it could impact the surrounding code.
User debug:
The raw user report is pasted above. It may come from an email, Slack, X, support ticket, or similar source. Treat it as evidence of a real problem, not as a complete diagnosis or specification.
Investigate the user problem behind the report: - What is the user actually trying to accomplish? - Where does their workflow break, and what is the consequence? - Is their requested feature the real need or merely a proposed solution? - What mental model does the current behavior violate? - Could a smaller, different, or more general change solve the underlying problem better? - Look for related reports or usage patterns that reveal a broader issue. Then investigate the system: - Separate the underlying need, desired outcome, reported behavior, and confirmed behavior. - Reproduce and trace the relevant flow end to end. - Determine the affected paths, states, and users. - Question Chesterton's fence. Use code history, blame, commits, tests, PRs, and implementation threads to understand why the current behavior exists. - Identify the product and system invariants the design protects. - Evaluate possible solutions against the actual need and those invariants. - Propose the smallest safe solution and the regression tests needed. - Clearly separate evidence, inference, and open questions. Do not implement the user's proposed solution literally until you understand the problem behind it.
What do you still do by hand, and why?
Nothing really. Reading code maybe, when I want to understand something on a low level.
