Field Note · 2 September 2026
Lovable, Claude, Codex, Miro or Amplitude? Give Every Tool a Job
A practical way to assign clear jobs across an AI product workflow—without turning the tool stack into the strategy.
- Filed
- 2 September 2026
- Author
- Dima Abramov
- Reading time
- 4 min
- Topics
- Tool Stack · Lovable · Claude · Codex · Miro · Amplitude
- Share

The fastest way to make an AI workflow confusing is to ask every tool to do everything. The second fastest is to choose the stack before defining the problem.
I use a simpler rule: give each tool a primary job, make the hand-offs explicit and keep a human owner for the decision. This is not a permanent league table. The products change quickly. It is an operating map for choosing what happens where.
Miro: frame the shared problem
Miro is strongest at the moment when a team needs to see the same situation together: actors, constraints, evidence, assumptions, workflow and unresolved questions. A board can hold text, cards, links, images and diagrams on a shared visual surface.
That matches Miro’s own description of a board as a workspace for exchanging information through visual items.
Primary job: turn a messy conversation into a visible brief that a team can challenge. Do not let the board become an archive nobody can act on. End with an objective, owners, decisions and the smallest build.
Lovable: make the product surface real
Lovable is useful when the team needs a working web product quickly: interface, flows, database-backed behaviour, authentication and integrations. It is particularly effective when non-engineers and engineers need to react to the same live thing.
The Lovable platform overview describes a full-stack workflow with editable code and GitHub integration.
Primary job: move from an agreed product brief to a testable application. Ask for states, behaviour, constraints and instrumentation—not “make me a beautiful app”.
Claude: reason through ambiguity and complex material
Claude is useful for working through long documents, exploring options, critiquing a brief and, through Claude Code, operating against a repository. It can help investigate a system before a change is made.
Anthropic’s current Claude Code documentation covers its repository-oriented command-line workflow.
Primary job: analyse, structure and implement where substantial context must stay coherent. The team still needs to verify sources, decisions and code.
Codex: execute and verify repository work
Codex fits when the task lives in a codebase and requires inspection, editing, testing and a clear hand-off. It is well suited to bounded engineering work, debugging and implementation that should be checked rather than merely suggested.
Use the current OpenAI developer documentation for capabilities and setup; this area changes too quickly for a static feature checklist.
Primary job: carry a defined code change through to evidence—tests, a diff, a working result and remaining risks.
Amplitude: turn behaviour into evidence
Amplitude belongs in the loop when the team needs to understand what users did, where a flow broke and whether a product change improved a meaningful behaviour.
Amplitude explains that events and their properties form the basis of product analysis.
Primary job: connect the build to observable user behaviour. Define the questions and events before launch; validate the data before trusting the chart.
The hand-off that works
Frame in Miro: situation, evidence, objective, constraints and owner.
Build the product surface in Lovable.
Use Claude or Codex when the work needs deeper reasoning or repository-level implementation.
Instrument meaningful behaviour and inspect it in Amplitude.
Return the finding to the brief and decide what changes next.
Where the tools overlap
There is overlap. Lovable can plan; Claude and Codex can create interfaces; Miro now includes AI capabilities; Amplitude can surface recommendations. Overlap is not a problem until ownership becomes unclear.
Choose the tool that preserves the context and evidence required for the current job. If a hand-off repeatedly loses information, reduce the number of tools or automate that boundary.
The stack is not the transformation
A team has changed when it can select better problems, build and validate faster, work safely and repeat the method without a facilitator. Buying five tools does not create that capability. A disciplined loop might.
Capabilities referenced here were checked against official documentation in September 2026. Recheck access, security and product details before standardising a company workflow.
See how the loop works in practice in Lovable + Amplitude: From Prototype to Evidence.