Intent-Based Development

When I ask AI to implement a feature, I describe what to build. Inputs, outputs, screen behavior and error handling give me a basis for checking the implementation. But how do I judge whether that feature fits the product I want to make?

A product can do something for its users, or help them learn to do it themselves. Which experience I want changes how I should build the same feature. That choice carries the builder’s philosophy.

So I record the job the product should do and the principles it should uphold, then refer to them when choosing the next feature. I started by making the direction concrete before handing off implementation.

Define the product’s job first

First, I define what the product should do for its users: whose problem it addresses, and what I want them to be able to do. That job is what I call its mission here.

The job includes the builder’s value judgments. I have to decide which changes are desirable, what to leave in the user’s hands and what to do on their behalf. I wanted that direction in place before adding more features to the list.

A mission still leaves choices open. If a product recommends something, I need to decide whether users must follow the recommendation or can change it. If preserving their choice is a principle, the ability to change the recommendation becomes a feature requirement.

Starting from the mission, I need to record those requirements so the next task can follow the same direction.

Record intent as a basis for the next decision

I use intent to mean this record of what the work should achieve. It describes the change I want to make, the conditions I want to uphold and the questions I need to answer about the result. Intent-based development means using that record when choosing features, implementing them and judging their outcomes.

For example, if I want to preserve user choice, I can require that users be able to modify or reject a recommendation. Whether that design actually makes them feel they have a choice remains a question to investigate. I separate the principle I have chosen from the effect I expect the design to have.

I also distinguish the product’s lasting direction from the intent of an individual task. The product philosophy provides criteria for many tasks. A task’s intent specifies what to change this time and what result to check against those criteria.

I turn personal philosophy into criteria for product decisions by making it concrete in mission and intent.

Connect intent to the development workflow

harness-maker puts this connection into the development process. It configures procedures for AI research, specification and implementation review to fit the project. The part that records the product’s purpose, principles, metrics for checking goals and open questions is called the intent layer.

Combine that with project facts the code cannot tell you and the current task’s progress, and you have the world model. It lets the next task refer to what we wanted, what we learned and how far we got. Maker is the entry point that reads this state and routes work to the procedure for starting or resuming it.

For a task linked to an intent, I choose which intent it serves while defining the specification. Relevant observations are collected through research → specification → planning and implementation → review → verification → wrapup. Review also checks whether the plan has drifted from that intent and its scope. At wrapup, I examine the evidence and agree to the updates I want recorded in the goals and questions. The updated state is then read back before the next decision.

This connects mission and intent to a software development life cycle (SDLC) that brings evidence from the result back into the next decision. Finishing the task and attaining its intent are separate judgments. If the evidence is insufficient, the outcome remains unconfirmed or we wait for more observations.

Turn SpotOn’s philosophy into product requirements

SpotOn, the tennis product I am building, currently has a mission: tell a player one thing to improve next. I also decided what experiences I want players to have as the product does that job.

• Choosing goals and acting in ways they willingly endorse. This is autonomy.
• Feeling capable of doing something and developing mastery. This is competence.
• Feeling connected to other people, with mutual care and concern. This is relatedness.

I chose Self-Determination Theory (SDT), which treats these three as basic psychological needs, as SpotOn’s product philosophy. Applying it to tennis, I interpreted it as a direction in which players choose their goals, see evidence of their progress and share that experience with partners or coaches.

I kept the existing mission and added criteria for carrying it out to the file that records development intent. These are the fields and examples used in SpotOn.

What to record	Field	Example recorded in SpotOn
The desired change for users	vision	Support autonomy, competence and relatedness so players enjoy tennis longer and more deeply
Conditions features must uphold	rules	Let players modify or reject AI recommendations. Require observational evidence for ability displays. Let players choose which items to share
Assumptions still to investigate	open_questions	Do players want to choose their own goals? Does this design lead to actual progress and continued use?

I did not turn the whole philosophy into a separate task intent. A task needs a defined scope: what to change and what result to check. For now, I recorded the philosophy as direction, conditions and open questions that several tasks can refer to.

Carry the criteria into feature specifications

To design a feature from this record, I need conditions that can be checked in the implementation. A goal-selection feature should let players choose their own goals and modify or reject AI recommendations. Writing that into the specification means the implementation review checks whether users can change or reject a recommendation as well as whether one appears.

Even an appealing example needed limits when it came to displaying progress. The philosophy’s source text included a Skill Tree: earning abilities and unlocking the next ones, as in a game. But some example abilities were things the racket sensor could not observe. Displaying them as written would make unverified skills look confirmed.

So I set a condition: within the product’s scope, an ability can be displayed or unlocked only when there is a validated way to establish it from sensor measurements. I adapted the design requirements to what the product could substantiate. Wanting users to feel they have improved does not justify displaying progress I cannot verify.

I also carried choice into the feature for sharing progress records with a coach. Players should choose which items to share. I wanted to support those relationships while leaving the decision about what to share in the player’s hands.

If players can do more on their own, I want to give them more room to judge and act themselves rather than have AI keep providing the same help. That led to the direction of reducing AI assistance in areas they have mastered. For automated coaching work, I therefore require the specification to state the evidence needed to judge mastery, which assistance should be reduced and under what conditions.

These are design requirements for upcoming features. How much they improve a player’s abilities, and when it is appropriate to reduce AI assistance, remain things to investigate.

Separate implementation completion from intent attainment

Once a feature is implemented to the specification, I can check its behavior. Then I need to check whether it produced the change I wanted. Implementing the ability to reject a recommendation does not, by itself, tell me whether players feel they have a choice. That requires examining their experience.

Choosing SDT as the philosophy has not established SpotOn’s effectiveness. Choosing a goal might burden some players, and the way abilities are displayed might make them feel evaluated rather than make their progress tangible.

This is where the recorded open questions matter again. I need to find out whether goal selection makes the first use harder. I also need to decide how to check outcomes such as whether improvement holds without AI intervention, or whether players return to play tennis with a partner.

Wanting to preserve autonomy is my choice. Whether my design realizes that choice is something to judge through user experience and measurement. Completing a feature is no reason to close the questions too.

Carry the same intent into the next task

Choose one feature to build next and write down three things before handing off implementation.

1. Which part of the product’s job does this feature help with?
2. Which principle should it uphold, and what feature requirement follows from that principle?
3. Once it is implemented, what change in the user’s experience will you check alongside its behavior?

Recording those answers together lets you return to the reason for the feature when reviewing the next task. Whether the record is actually read and used in decisions still needs to be checked during the work.

Use a principle you want to uphold as a criterion for your next feature.