Chat Agents, Coding Agents, and Workflows

Open a Workspace and Get the First Preview Running

Bring the request-tracker brief from the MVP guide. A browser-based builder is a reasonable first workspace when it includes a preview, source export, and a clear deployment path. A local coding agent needs a project folder, an editor or app, and the runtime required by that project. Ask it to inspect what is installed before suggesting downloads.

A terminal is a place to run text commands; a runtime runs the application; a dependency is code the project uses. Ask the agent to list the exact startup command, the folder in which to run it, what success looks like, and how to stop it. Follow the project's own instructions instead of assuming every app uses the same command. A local preview address such as localhost is visible on your machine; it is not yet your public website.

Before changing an existing project, save a recoverable snapshot. For a new project, ask for the smallest implementation that meets the brief and runs in the chosen environment. Let the agent explain whether it is creating a static browser app or an app with server-side work, since that changes deployment and data handling.

Use my approved brief. First inspect the workspace and explain the minimum setup. Then make the smallest working request tracker with fictional records, a usable empty state, and no live integrations. Tell me exactly how to open the preview. Do not add a database, paid API, accounts, or deployment unless we have agreed that scope.

Build One Behavior, Inspect It, Then Continue

Describe defects through actions and expected results: I changed request A to Done, but request B changed too. Include a screenshot and relevant error text after removing private information. Ask the agent to investigate one reproducible problem and rerun its checks; repeatedly asking it to fix everything gives you little evidence about what changed.

1. Create the list and add-request form. Try an empty title and a valid title yourself.
2. Add edit and status-change behavior. Check that editing one record leaves another record untouched.
3. Add deletion with confirmation. Test both cancel and confirm.
4. Agree the storage behavior, then add it. Reload the browser and confirm what should survive. Keep an export you can open independently.
5. Check phone width, keyboard navigation, visible focus, labels, loading/error states, and the empty list.
6. Save a named working snapshot before adding another feature. Keep a note of what changed and how you checked it.

Reproduce this problem before changing code. Explain the likely cause in plain language. Make the smallest fix, check the affected workflow and a neighboring one, then show the result and any remaining uncertainty. Preserve unrelated work and the last working version.

Decide When the App Needs a Server and Real Permissions

A browser-only tracker is useful for learning. Its storage can be cleared, and a second browser or device has a different copy. Publishing that interface does not create shared records. If two people must see the same requests, the next version needs an agreed shared data service and access rules.

For that next version, ask for a data diagram in ordinary language: what is stored, where it is stored, who may read or change it, and how a record is removed or recovered. A login screen identifies a user; permission checks decide what that user can do. Hiding a button is not an access rule. The server or managed database must enforce ownership for direct requests too.

Keep practice and production environments separate. Use fictional test accounts and records. Have the agent explain environment variables: named settings supplied by the runtime or hosting platform. Some settings are public; secrets must stay in the server's protected environment. Ask for independent review before collecting sensitive records, taking payments, or relying on unreviewed code for consequential business actions.

Keep Enough Evidence to Recover and Hand Over

• An owner-controlled source repository and a named last working version.
• A short explanation of screens, data location, and any services the app needs.
• Instructions to start the preview, run checks, build the app, and stop it.
• A record of known limits, test failures, configuration names, and costs without secret values.
• A change summary you can read before approving another release.

When Should You Use a Chat Agent?

A chat agent works through a conversation.

It is useful for:

• exploring an idea
• identifying assumptions
• comparing options
• writing requirements
• explaining technical terms
• reviewing a proposal
• improving a prompt
• challenging scope

Think of a chat agent as a consultant working at a whiteboard.

It can help decide what should be built. It may not have direct access to the repository, terminal, runtime errors, or deployment environment.

ChatGPT and Claude can act as chat agents when used primarily through conversation.

When Should a Coding Agent Touch the Repository?

A coding agent works closer to the implementation environment.

It may be able to:

• inspect repository files
• edit code
• run commands
• read errors
• write tests
• update dependencies
• create commits
• follow repository instructions

Codex and Claude Code are examples of tools commonly used in this role.

A coding agent is closer to a developer working inside the project than a consultant discussing the project from outside.

The distinction is important because a planning conversation and an implementation task require different context.

When Is a Vibe-coding Environment a Sensible First Step?

Vibe-coding environments such as Lovable and Replit reduce the distance between describing an application and seeing a working interface.

They can be useful for:

• prototypes
• early MVPs
• interface exploration
• internal tools
• validating a workflow
• demonstrating an idea

This can accelerate output. It can also hide decisions.

A founder may see a functioning page without knowing:

• where data is stored
• how permissions are checked
• who owns the deployment account
• how a failed update is reversed
• whether the application has tests
• whether secrets are exposed
• whether the generated code can be maintained

The correct response is not to reject vibe coding.

The correct response is to define what must be inspected before the result is trusted.

A skill may teach an agent how to:

• review architecture
• write a specific type of document
• follow a design system
• deploy to a platform
• inspect security risks
• use a particular tool

A skill should be reviewed before use. Check:

• who created it
• what permissions it assumes
• which tools it invokes
• whether its recommendations fit the current project
• whether it changes files or infrastructure
• whether it contains outdated conventions

When Does a Workflow Need More Than One Agent Step?

Agent systems such as OpenClaw, Hermes, and Strands may coordinate:

• models
• tools
• memory
• tasks
• schedules
• approvals
• external services

An agent can be more autonomous than a normal conversation. That autonomy increases the importance of permissions and review.

A useful rule is:

Increase autonomy only after the task, limits, and recovery process are clear.

How Do You Keep an AI Building Workflow Reviewable?

A weak workflow asks one tool to:

• understand the business
• choose the scope
• select the architecture
• design the interface
• write the code
• test the result
• declare the work complete

This combines several judgement-heavy tasks into one instruction.

A stronger workflow separates them.

The founder and chat agent clarify the product.

The founder reviews the decision using the knowledge available.

The coding agent implements a bounded task.

Testing produces evidence.

The next prompt responds to that evidence.

This creates a controlled feedback loop.

What Should You Ask a Consultant?

• Is this a thinking task or an implementation task?
• Does the tool have access to the repository?
• What files or systems can it change?
• Which decisions should remain with the founder or consultant?
• What evidence will prove that the task is complete?
• How will failed changes be reversed?
• What should the agent do when the requirement is ambiguous?