← Back to Archive

Agentic Build Rules


A set of general rules I abide by for all my agentic coding projects.


01. Define Your Principles

Before you set off building, aim to have a clear understanding of what the project achieves.

  • What does the ultimate user experience feel like?
  • When should information be abstracted, versus displayed to the user?
  • Are there any reference examples that get close to your vision?

Ask your agent to interview you about the project principles that should be universally respected during the build.

Every project should contain a foundational document of rules and principles that teaches all future agents how to approach new features.

Try this prompt:

You're my engineering manager, and I'm the project PM. What do you need to know from me to start with a solid foundation to build from?

Specifically in terms of UI design principles, I've really enjoyed pointing my agents at Jakub Krehel's 'Make Interfaces Feel Better' skill: https://github.com/jakubkrehel/make-interfaces-feel-better

Define Your Principles

02. Be User Obsessed

When choosing a direction, pick the one with less to read, fewer decisions, and no surprises.

  • Hide any processes that can be hidden.
  • Disable options when they'd conflict or cause errors.
  • Remove things at every opportunity. Don't add without considering what can be safely lost.
  • Offer presets instead of free entry. Guide the right choices.
  • Keep options limited, so that a 'good' state is the default for everyone.

Assume that you have 10 seconds of anyone's attention before you lose them forever. Make it count.

If it isn’t immediately clear what something does, it shouldn’t be in the UI.

Try this prompt:

Complexity lives in the code, not in the interface. Every visible element must earn its place and be immediately obvious to the user what it achieves.

Be User Obsessed

03. Short Feedback Loops

Explain one feature at a time, then look at it, and react to what you experience.

  • Don't scale to the finished product from the jump.
  • Building in small chunks is more easily changeable, and less distracting.
  • Describe what you see and do as a real person.

Take screenshots of what you like, and what you don't like. Practice describing how your experience of a feature makes you feel.

Even if an agent has access to headlessly drive a project and 'see' it's own output, there is no replacement for real human understanding.

Try this prompt:

Show me a quick proof of concept so I know we're on the same page. Give me a few test user journeys to explore and provide feedback.

Short Feedback Loops

04. Direction Descisions

Develop a build plan with your agent, setting a clear 'to do' list of priorities. Don't get caught up in a technology direction.

Implementation choices should live with your agent, while you remain the arbiter of taste.

  • An agent's inherent 'jargon' always masks inhuman choices that might surprise you. Prioritise plain language.
  • Plan ahead for what 'good' looks like. Work with your agent to understand if one 'to do' must come before another to reach 'good'.
  • Tailor your solution to your scale. If you're the only user, you can accept trade offs you otherwise wouldn't at 1000 users.

Try this prompt:

To reach my desired result of X, what decisions do we need to make now so that you can feel confident in your implementation choices? Use plain language so we understand each other.

Direction Descisions

05. Continuous Progress

Every correction can make the next session smarter. Write it down where the agent will read it.

  • Keeping a written history of decisions will make every new session feel more richly contextualised to what you care about.
  • Tools or principles that are often repeated can be turned into frameworks that others can clone.
  • Past projects become starting point references for the next one.

Try this prompt:

Review the decisions I've made so far about the project and find any similarities between them to better inform our project principles.

Continuous Progress

06. Re-Evaluate

Your first idea is never the best. User feedback quality is dependent on your curation. What you choose to keep is equally important as what you ignore.

  • Look for patterns of frustration in feature requests. Address the underlying pattern, not the specific suggestion.
  • Use your own tool. Pause the build for two weeks before evaluating what's next.
  • Explore lots of different project types outside the area of focus you're building within. Learn from everything.

Try this prompt:

Imagine you're a new user visiting the project for the first time, and you have none of the build context that we've previously worked on. What would you be confused about? What doesn't work as you expect?

Re-Evaluate