You know what your business needs. Learn to turn that knowledge into clear instructions, useful examples, and a result you can check.

Cezar can help you build and change software. Your part is to explain what should happen, supply what you already know, and decide whether the result works for the people using it.

Four habits to build with

• Describe the change.

  Explain what happens today, what should happen instead, and what must keep working.

• Define done.

  Give examples with expected results. Include a normal case, a boundary, and something that must be blocked.

• Give Cezar a place to start.

  Bring a document, a screenshot, an existing application, or your own explanation. Make missing information visible.

• Verify each step.

  Build one useful part, try it, and compare it with the result you agreed. Use what you learn to choose the next change.

Learn on one small change

These four lessons follow an illustrative example: a sales team needs approval before sending an offer with a discount above 10%. The exact rule is just an example. Replace it with a process you know.

In each lesson you will find a technique, a message you can adapt for Cezar, and a short exercise. You can use the same habits with an Open Mercato example or software your team already has.

You do not need a perfect specification to begin. Start with what you know. Ask Cezar to surface unclear decisions, then improve the brief together.

Tell Cezar how the work should change. Start with a situation you can describe to a colleague.

“Build me an approval system” leaves many decisions open. Who needs approval? For what? What happens while they wait? A more useful request explains the behavior you want.

Use four short sentences

The last sentence protects something that already works. It also helps you keep the first change small: solve approval before adding reminders, dashboards, or extra approval levels.

Ask about the gaps

You may not have decided what happens when an approved offer changes. Say so. Cezar can help identify the question; the person responsible for the process chooses the rule.

Before asking Cezar to build, write down a few situations that would prove the change behaves as intended.

You can describe a test in ordinary language: when this happens, I expect that result. Cezar can help turn those examples into checks. Your job is to confirm that the expected results match the business rule.

Try the rule from four angles

The last two rows add business decisions. They are rules for this example, not rules Cezar should assume for every company. Confirm them before building.

Examples reveal missing decisions

“A manager approved it” sounds complete until someone changes the offer. Does the approval still apply? Working through a concrete situation exposes that question early.

Start with a normal case, a boundary, a forbidden action, and a later change. You can add more examples as you learn. A few agreed examples are a starting point, not proof that every possible case is covered.

Give Cezar something real to work from. A useful explanation is enough to start; existing material makes it more precise.

Bring what you have

• A document or spreadsheet: attach a relevant example and explain which parts matter.
• A screenshot: describe what happens before and after that screen. A picture alone does not show the rules behind it.
• An existing application: point Cezar to the project and ask it to inspect how this process works today.
• No documentation: walk through a real example in your own words. Explain who acts, what they see, what they decide, and what happens next.

Use made-up customer details when real data is unnecessary. Name the source of a rule and point out where a document might be out of date.

Ask for three lists

Before changing the application, ask Cezar to show what already exists, what needs to change, and what is still unknown. This helps avoid rebuilding a feature you already have or treating a guess as a fact.

Have an existing project? Turn it into a reusable process note.

A Markdown file is a plain text document with headings. You can keep a note such as current-process.md with the project and reuse it in later tasks. Ask Cezar to create it from the material it can actually inspect.

Try this with Cezar

Read the available project files and documentation for this process. Create current-process.md describing the users, steps, rules, permissions, and connected systems. Reference the files or documents behind your findings. Separate confirmed behavior, inferences, and unanswered questions. Do not change the application. Then summarize the note in plain language so I can check it.

For a developer, this note can also include the relevant code locations, how to run the app, and existing checks. Keep it focused on the process being changed. Review it before treating it as the source for future work.

Ask for one useful part of the process, then check it before adding the next part.

For our example, the first complete step is: a salesperson requests approval, a manager decides, and the application allows or blocks sending. Reminders and reporting can follow after that path works.

Replace “done” with a demonstration

Ask Cezar to run the examples you agreed and show the results. Then try the process yourself as the people who will use it.

• Expected: what should happen according to your rule?
• Actual: what happened when the check was run?
• Evidence: what observation or test result supports that conclusion?
• Not checked: what still needs access, information, or someone’s help?

A hidden approval button alone does not prove that a salesperson cannot approve an offer. Ask Cezar to check that the application enforces the permission too. If it cannot, keep that check visibly unfinished.

Make feedback specific

Instead of “approval is broken,” say: “After the manager approves 11%, I can increase it to 15% and still send. I expected a new approval.” You have given Cezar a way to reproduce the problem and recognize the fix.

Ask it to repeat that scenario after the fix and keep an appropriate check for future changes. Your working example becomes useful knowledge for the next task.