AI development means describing the software you want and directing AI to build it. You decide what matters; AI handles much of the implementation.
You are still responsible for the application. Your work moves toward intent, judgment, and verification, while AI takes on more of the mechanical implementation.
The more specific you can be about what you want, the better the result will be. Do not worry about getting everything right the first time. Start with what you know, review what the AI builds, and keep improving your description as you learn what is missing or unclear.
The quality of the result depends less on whether you can dictate code and more on whether you can clearly express the problem and recognize a good solution.
The application contract
The description and decisions you agree on with the AI form the application contract. The name is literal: it is an agreement between you and the AI about what the application does.
The contract describes who the application is for, the work it needs to support, the business rules it must follow, and what a successful result looks like. Focus on what your business and users need rather than how the software should be built.
AI tools must not break the contract. They can choose how to implement the application, but every choice must remain inside its boundaries. If a tool produces something you did not want, treat that as evidence that the contract was not explicit enough. Return to the contract, add the missing rule or constraint, and let the AI revise the implementation from that clearer agreement.
This makes correction durable. You are not only fixing one screen or one piece of code; you are improving the shared definition that guides future work.
Do not put the entire contract in one large document. Keep it as a collection of small, focused documents organized into three groups:
| Type | What it means | What you will find there |
|---|---|---|
Reference (reference) | How things work | Facts about the business and application, what different parts do, available features, and important terms |
Instructions (instructions) | How to do something | Step-by-step guidance and rules for making a specific change |
Playbooks (playbooks) | How to complete a bigger task | A complete process that brings together several instructions to achieve a goal, such as adding users or building a new application |
This structure makes the contract easier for people and AI to navigate, update, and apply to the work at hand.
The AI development loop
AI development follows a simple loop:
- Describe the application you want, including its structure, behavior, and constraints.
- Build a complete version within that contract.
- Review the result against the contract and real workflows.
- Deploy it where its users can rely on it.
Describing includes planning. As you explain the application, you and the AI make the important decisions and turn them into an explicit contract before implementation begins.
Review often reveals something missing, unclear, or wrong in the description. When it does, return to Describe, improve the contract with what you learned, and build again. Refinement is not a separate stage; it is another pass through the same loop with better information.
Deployment does not end the loop either. Real use produces better information: where people hesitate, which steps are missing, and which assumptions were wrong. Bring that evidence back to Describe and begin the next pass.
If you're coming from traditional development
Traditional development often starts with a document such as a product requirements document, followed by implementation. Almost immediately, the application begins to drift from the document. New decisions are made during development, details change, and the original requirements stop reflecting what the software actually does.
An application contract remains part of the development process. The AI builds against it, you review the result against it, and any new decision is added to it before the application changes. The contract and the application keep moving together, so the original business requirements do not get lost during implementation.
If you are familiar with test-driven development, think of this as TDD for the whole application—but one that actually works. The contract is written in business language, describes the result rather than the code, and directly guides the AI doing the implementation.
Describe what you want to build
Start with the situation, not a list of screens.
Explain who will use the application, what they are trying to accomplish, what information they work with, and what a successful outcome looks like. Include constraints that would make an otherwise plausible result wrong.
Build an application for a facilities team to schedule inspections across our buildings. Inspectors need a mobile-friendly checklist, facilities managers need to see overdue work, and failed checks must create a follow-up task with an owner and due date.
This gives the AI a model of the work and begins the application contract. It can infer useful screens and relationships without treating your first list of features as the whole problem.
Make the important decisions
Before implementation, settle decisions that shape the entire application. These usually include:
- The people and roles the application serves.
- The main records and how they relate.
- The workflow from beginning to end.
- Permissions, approvals, or compliance constraints.
- External systems the application must connect to.
- The standard for a successful first version.
These decisions make the contract explicit. You do not need to decide every field or button. Decide what would be expensive, risky, or confusing to discover accidentally during implementation. Let smaller reversible choices emerge during the build.
Let AI handle implementation
Once the contract is clear, let the AI work across the whole problem. It can create the data model, user interface, actions, validation, and supporting configuration as one connected system.
Give it access to the information it needs: product conventions, design rules, existing components, service documentation, and a way to run or inspect the application. Good context reduces guesswork and makes the result more consistent.
Avoid prescribing code when the behavior is what matters. “Prevent an inspection from being submitted until every required item has a result” adds a clear rule to the contract while giving the AI room to choose an implementation that fits the application.
Review the result
Review the application as a user before treating the first build as complete.
Walk through the primary workflow with realistic data. Check whether the application makes the next action clear, protects important information, and handles an incomplete or unsuccessful path. Compare the result with the contract, not merely with whether the application renders.
Useful review questions include:
- Can each user complete their main job without explanation?
- Does the application preserve the right information at each step?
- Are important states—empty, loading, failed, and complete—clear?
- Do permissions match real responsibilities?
- Would a mistake be visible and recoverable?
Direct changes
Describe a change in terms of the observed problem and the intended behavior.
Instead of “make this page better,” say: “Inspectors cannot tell which checklist items are required. Mark required items consistently, explain why submission is blocked, and move focus to the first incomplete item.”
Specific direction helps the AI understand both the symptom and the standard for completion. Add the clarified expectation to the contract before directing the implementation change. When visual details matter, point to an existing pattern or provide a reference. When behavior matters, give an example that shows the rule.
Do not treat an unwanted result as permission for a one-off exception. It reveals an ambiguity in the agreement. Improve the contract so the AI has an explicit rule to follow everywhere the same situation appears.
Debug with AI
Give the AI evidence, not just the conclusion that something is broken. Include what you did, what you expected, what happened, and any relevant error or log output.
A capable agent can trace the behavior through the interface, server, data, and external services. Ask it to identify the cause, fix the underlying issue, and verify the original failure path. This keeps debugging focused on an explanation rather than a speculative patch.
Intermittent or high-impact failures deserve more care. Preserve logs and example inputs, and ask the AI to explain how the fix prevents the same class of failure.
Test what matters
Tests are evidence that the application continues to satisfy its contract. Prioritize the behavior that would cause real harm or disruption if it failed.
Test core workflows, permissions, calculations, external integrations, and recovery from failure. Include realistic examples and boundary cases. A test that confirms a meaningful business rule is more valuable than a large number of tests that only confirm implementation details.
Ask the AI to run the relevant checks and report what it verified. For important workflows, also perform a human review in the running application.
Deploy
Deployment turns a working build into a service people can depend on. Before deploying, confirm configuration, secrets, data migrations, access controls, and a way to observe failures.
Release with a clear understanding of who can use the application and how you will respond if something goes wrong. Higher-risk changes may need staged access, backups, or a rollback plan. The right process depends on the consequences of failure, not on how quickly the application was built.
Keep improving the application
Once people use the application, replace assumptions with evidence. Support questions, repeated workarounds, abandoned workflows, and recurring errors all reveal where the application needs attention.
Bring that evidence back into the development loop. Describe what you observed, decide what needs to change, let the AI implement it, and review the result. Small, well-directed improvements keep the application aligned with the work as that work changes.
What you should control
Keep control of decisions that express purpose, responsibility, and acceptable risk:
- The problem the application solves.
- Who it serves and who may access information.
- The contract, including the rules and constraints that define correct behavior.
- Tradeoffs involving risk, cost, speed, and user experience.
- The evidence required before a result is accepted.
- When the application is ready to deploy.
Together, these decisions answer the question you should control: whether the application meets your needs. AI can help you evaluate the result, but that judgment remains yours.
What you should let AI control
Let AI control implementation choices that are well constrained and easy to verify:
- Translating the application contract and agreed structure into code.
- Following established design and engineering conventions.
- Creating routine data operations and interface states.
- Connecting components and services through documented interfaces.
- Running checks, investigating failures, and making bounded revisions.
- Maintaining consistency across repetitive changes.
Control is not all-or-nothing. Give AI more autonomy where the outcome is clear, the work is reversible, and verification is strong. Give it less autonomy where intent is ambiguous or failure has serious consequences.
Where Jotsu fits
Jotsu wraps the entire process in an easy-to-use tool. It handles the details of development, testing, deployment, and running the application, so you can focus on your business requirements and whether the result meets your needs.
The result is a real, working TypeScript application. You can use it as Jotsu builds it, inspect and change the code, and continue developing it with the tools you prefer.
Jotsu never locks you into a particular tool or workflow. Use the tools Jotsu provides, bring your own, or combine them in whatever way works best for you.