Working With Coding Agents

Coding agents can make it easier to begin contributing to Chahua. You can describe a goal in ordinary language, ask an agent to explore unfamiliar parts of the project, and get help making a focused change.

You do not need to memorize every language or framework before you start. Instead, learn what each part of the application does, where a proposed change belongs, and how to decide whether the result is correct. You can learn more syntax and technical detail as you need it.

What an Agent Can Help With

A coding agent can help you:

Find files related to a feature or problem.
Explain unfamiliar code and terminology.
Find an existing project pattern to follow.
Suggest a plan for a change.
Make focused edits after you approve the approach.
Run formatters, builds, and tests.
Summarize what changed and what still needs checking.

This is useful in Chahua because a feature may involve several parts of the application. An agent can help you follow those connections while you build your own understanding of the project.

What an Agent Cannot Decide for You

An agent begins with incomplete context. It may misunderstand a vague request, miss an undocumented requirement, or make a change that passes a test but does not produce the intended experience.

The contributor remains responsible for:

Describing the outcome they want.
Deciding whether the proposed plan makes sense.
Reviewing what actually changed.
Checking the result in an appropriate way.
Deciding whether the change belongs in the project.

An agent’s completion summary is a claim about its work. The changed files, check results, and observed behavior are the evidence you use to evaluate that claim.

You do not need to understand every character of unfamiliar code immediately. You should understand the purpose and consequences of the change well enough to explain it. Ask the agent to clarify anything important that you do not understand.

A Simple Workflow

The same basic process works for many contributions:

Explain the goal
      ↓
Let the agent inspect the project
      ↓
Review the proposed plan
      ↓
Let the agent make the focused change
      ↓
Review and test the result
      ↓
Keep, revise, or reject the change

Large goals are easier to manage when divided into smaller changes. A focused change is easier to explain, review, test, and undo if the approach turns out to be wrong.

Chahua also contains instructions for agents in AGENTS.md files. These describe project boundaries and checks that should be followed. An agent should inspect the relevant instructions before changing code.

Give the Agent Useful Context

You do not need to design the technical solution yourself. Start by explaining:

The goal: What should be different when the work is finished?
What you observed: What happens now, or what information is missing?
The boundary: What should remain unchanged?
Success: How could someone tell that the result works?

For example:

Add a short note to the welcome page explaining that this book focuses on the PWA and backend. Keep the existing introduction and tone. The book should still build successfully.

This gives the agent an outcome and boundaries without telling it exactly how to edit the file. The agent can inspect the documentation structure and suggest an appropriate change.

When the task involves a bug, include the steps that caused it, what you expected, and what happened instead. Screenshots and exact error messages can also provide useful evidence.

Review What Changed

A diff shows the lines that were added, removed, or replaced. Reviewing the diff helps you see the actual change instead of relying only on the agent’s description.

As you review the diff, ask yourself whether you understand the following:

Which files changed?
What does the change accomplish?
Why was the change made in this location?
Does every change relate to the agreed goal?
Was anything removed or changed unexpectedly?

If you are unsure, ask the agent to explain a section in plain language or show the existing project pattern it followed. You can also ask for a smaller change if the diff is difficult to review.

Verify the Result

Reviewing the code and checking the result answer different questions. A diff tells you what changed. Verification helps show whether the change works.

Depending on the task, verification may include:

Building the project.
Running its automated checks or tests.
Opening the affected page or feature.
Repeating the action that previously failed.
Checking that nearby behavior still works.

Passing checks are useful evidence, but they do not prove every behavior is correct. For a visible change, look at the result. For a behavioral change, try the relevant interaction. Ask the agent what it verified and what it could not verify.

Exercise: Change the Sent Message Bubble Color

Try the workflow with a small, visible PWA change. Treat this as local practice rather than a contribution the project necessarily needs.

Ask an agent to find where the PWA defines the colors of sent and received message bubbles. Ask it to explain what it finds before editing.
Ask it to change only the sent bubble from the Ionic primary color to the Ionic success color. Require the text to remain readable and the received bubble to remain unchanged.
Review the plan. The agent should identify wetty-chat-mobile/src/components/chat/messages/ChatBubble.module.scss and consider both the background and its corresponding contrast color.

Approve the focused edit, then review the diff:

git diff -- wetty-chat-mobile/src/components/chat/messages/ChatBubble.module.scss

Ask yourself whether you understand which selector changed, why each color variable changed, and whether anything outside the requested bubble was affected.
Run the frontend checks:
```
cd wetty-chat-mobile
npm run verify
```
Start the PWA and open a conversation containing sent and received messages. Confirm that only sent bubbles changed and that their text remains readable. If possible, check both light and dark appearance settings.
Keep the change for further practice, ask for a revision, or discard it. Do not submit an exercise-only pull request unless the maintainers want the change.

The goal is not merely to produce a different color. It is to practice asking an agent to explore first, limiting the change, understanding the resulting CSS, and checking the actual interface.

As you continue through this book, you will learn what Chahua’s tools and application layers do. That knowledge will help you give agents better context and review increasingly technical changes without needing to learn everything at once.

Keyboard shortcuts

The Chahua Book