Hum(a)in Design Principles: a guardrail for building with AI

Hum(a)in: the intelligence remains human, the (a)rtificial part is optional and removable.

In this article I’ll share four principles, four risk levels and a toolkit: a checklist, two checks, a safeguard and a rules block to paste into the AI tools you currently use.

Whether you are working on your own, at team level or on strategy for a whole organization, the principles apply.

In this article

The AI moment: how it started for me
The principles: Build it, own it · /loop, make me wiser · Pack it, carry it · Lend it, take it back
Where they come from: Dieter Rams
How far should you go: four risk levels
The toolkit: the checklist, two checks and a safeguard, rules to give the AI, who checks
How I apply this on my own projects
Next steps

The AI moment

Maybe some of you have already lived through a moment like this one: an all-hands meeting, a beautiful stage, carefully crafted slides, the classic veggie snacks and drinks, and AI as the only and most important goal.

For me, it happened at my former employer: they gave us licenses and asked us to use AI for everything. At the beginning, no one had a clear framework or guidelines.

What was shared on how to use AI safely was mostly about writing the right prompts, double-checking what the AI says and using AI only in areas you master. Back then I recall that no one around me approached the risks AI poses to human agency, or how to prevent them. Probably nobody knew how to approach these subjects at the time.

When I started out, I fell for the speed. I learned by doing, but had no methodology to follow and I couldn’t concretely explain everything that I did.

Since then, the way I work with AI has evolved. These changes shaped the principles that I’ll share with you, along with a methodology that you can apply yourself.

The principles

1. Build it, own it

Humans should be able to understand, fix and use the products with or without AI. Any person with the necessary skill set should be able to understand how the product was built, how it works and explain why.

Why: To avoid falling into the build-time trap: “Nobody can understand or change what the AI made”, for example “A site or piece of code that nobody dares edit”.
In practice: Before you ship, write a short README in plain language: what it is, how to run it and where it lives. When you pick a tool or change direction, add a few lines to a decision log. Keep the accounts, the backup and the history in your name, not only inside the AI tool. Then hand the files to someone who didn’t build it, with no AI and no help from you. If they can explain what it does, make a small change and undo it, you own it. If they get stuck, that’s your to-do list.
Where it stops: When you need to optimize for speed or a deadline, this principle might slow you down: you are trading safety against speed. Someone who isn’t an expert in the area won’t do a tech lead’s job, but they should be able to understand the logic behind it.

2. /loop, make me wiser

The interactions between humans and AI should provide learning opportunities for humans, allowing them to improve their skills while augmenting their agency.

The name nods to “/loop, make me happier”, from Anish Acharya (a16z) on Lenny’s Podcast: Why companies are becoming a series of loops (opens in a new tab), September 2026.

Why: To avoid a fully automated agent that takes over all the vital tasks a human used to perform, with no plan or method to keep that human’s agency.
In practice: You are able to improve the rules you started with, using the experience you collected from your interactions with AI. You start integrating terms and logic that you didn’t have before.
Where it stops: Here we are trading speed against knowledge and agency: the faster we go, the less we know.

3. Pack it, carry it

The products we build should remain “AI agnostic”, meaning that they shouldn’t rely on a single AI services provider. They should also have a fallback mode for when AI is not available.

Why: To ensure that your users can use your product even when an AI outage happens. Some products can’t depend only on AI when the stakes are high: think about health, finance or government. To avoid falling into the run-time and vendor lock-in traps: “An app that shows a blank page during an outage”, or “A project you can’t move after a price rise”.
In practice: Keep your rules, prompts and project files in plain files that any AI tool or developer could open, and make sure your product still does something useful with the AI switched off. I applied this approach from the beginning. I started working on Cursor and explicitly set up this constraint: everything we do has to be “AI agnostic”. The set of rules, routines and logic that I built were all exported and easily adapted when I migrated to Claude and Codex.
Where it stops: If there’s a clear advantage to working with one vendor, then you should consider it. Cybersecurity is important: having access to frontier models to challenge and test your infrastructure can be a must. Yet, you should be able to switch without a big impact on performance or safety.

4. Lend it, take it back

When AI can act on our behalf, we hand over part of our agency. Every permission we give it should have a human owner, an end date and a way to undo it.

Why: The AI becomes an actor inside the system: it can act, but it can’t answer for what it did. A human has to. To avoid falling into the delegation trap: “An agent did something nobody approved”, for example “An agent that still holds the keys to your inbox months after anyone last used it”.
In practice: Before you create a new agent, check if one already does the job. Give it its own account and keys, never yours, and only the access it needs for the task. Make it ask for your approval before anything you can’t undo: sending, paying, deleting, publishing. Set an end date on its access and keep a log of what it did. Then check that you can switch it off in one move without breaking the rest.
Where it stops: If you approve every single action, there’s no point in automating: here we are trading autonomy against control. And when there are too many agents to review, people end up clicking “approve all”. That’s why access should expire by default, unless someone shows it’s still needed.

Where they come from

Long ago, while I was studying product design, I stumbled upon the 10 design principles from Dieter Rams (opens in a new tab) and I was hooked. Those design principles are still very important today, and they inspired me to write the principles I’m sharing with you.

Rams was not working on digital products: his principles were driving mostly analog products that existed in the real world and didn’t have the capacity to reach a human the way digital and AI products do today.

Here’s how four of them connect to the Hum(a)in principles:

“Good design makes a product understandable” Build it, own it extends this premise.
“Good design is long-lasting” Pack it, carry it extends this principle.
“Good design is as little design as possible” An AI layer that is optional and removable fits this principle.
“Good design is thorough down to the last detail” Lend it, take it back extends this principle: nothing an agent is allowed to do should be left to chance.

How far should you go

The context in which you use AI sets the bar for the effort needed to implement the principles: you evaluate the risk level according to your context.

Pick a level at the start of each project, and move it up as soon as other people start relying on it. The conditions for each level add to the level before it.

Level	What it is	Ask yourself	What it requires
0. Throwaway	Experiments and demos you’ll delete	Would I care if it vanished? No	Nothing
1. Personal	Things only you use, like your portfolio	Would losing it cost me time or money?	A backup, a short README, accounts in your name
2. Shared	Used by a team, clients or the public	Would someone else be stuck if it broke?	The full checklist and the explain-it-back check
3. Critical	Handles money, personal data or someone’s livelihood	Could a failure hurt someone?	The takeover test and a human on call

/loop, make me wiser applies at every level: there’s always room to learn and regain agency.

The toolkit

Download the whole toolkit as one Markdown file: huma-in-kit.md.

The checklist

Nothing fancy: an old, simple checklist is the most efficient tool we can use, and it has proven to deliver results in many professions when stakes are high (see Atul Gawande’s The Checklist Manifesto (opens in a new tab)).

The number in brackets is the level from which the item applies.

Can someone understand it? (Build it, own it)

(1) A README in plain language says what this is, how to open or run it, and where it lives
(2) It only uses tools from your approved list (see the AI rules below)
(2) A decision log, a few lines per choice, says what was picked and why
(2) The README was checked against the project at the last change, not only at launch

Do you own it? (Build it, own it)

(1) The accounts, domain, hosting and data are in your name
(1) A backup exists outside the AI tool you built it with
(1) Passwords and keys live in a password manager, never only in a chat
(2) Everything is in Git or a similar history, so any change can be undone

Can it survive without one AI company? (Pack it, carry it)

(2) The project is plain files a different AI tool or a developer could open
(2) Every outside service is listed, with what happens if it fails
(2) If it uses AI while running, it still does something useful with AI switched off
(3) Someone besides you knows how to put it back online from scratch

What can it do on its own? (Lend it, take it back)

(1) You have a list of the AI tools and agents you gave access to, and what they can reach
(2) Each agent has its own account or keys, never yours, with only the access it needs
(2) Each agent has a named human owner
(2) Access nobody used in the last 30 days is removed
(3) Anything that can’t be undone (sending, paying, deleting) waits for a human approval
(3) You can switch an agent off in one move, and you’ve tested it

Two checks and a safeguard

Start with the easiest one that matches your level.

#01 - Explain it back (level 2)

Take five minutes, on your own. Close the AI. Explain out loud, or in a short note, what the project does, how it’s organized, where the data lives, and what each agent can do on its own. Anything you can’t explain goes in the README or the decision log before you ship.

#02 - The takeover test (level 3)

Give someone who didn’t build the product only the files and the README, with no AI and no help from you.

The test is successful if they can:

Say in their own words what it does
Open or run it on their own machine or account
Make one small change, like a piece of text or a color
Find where the data, accounts and agent access live
Undo that change from the saved history

If they get stuck, fix that, then run the test again. A non-technical colleague can do steps 1, 4 and 5. Steps 2 and 3 might need a developer.

#03 - A human on call (level 3)

Keep an expert (or more) you trust in the domain, someone you can pay for a few hours when something breaks. Have them run the takeover test at least once a year, so they already know the project if you need them in the future.

Rules to give the AI

Paste these at the start of a project, or into the AI’s standing instructions: a CLAUDE.md or AGENTS.md file, or your Cursor rules. Fill in the approved tools list once with an expert you trust, so you don’t have to judge tool choices only by yourself. The skills list belongs to you: feel free to add the topics you want to learn or get better at.

Hum(a)in rules for this project (risk level: __)
Approved tools: __________ (anything else, ask me first)
Skills I want to learn: __________

1. Only use tools from the approved list. If you need something else, explain why in plain words and wait for my answer.
2. Keep the code simple and readable, even if a clever version would be shorter.
3. Explain important choices without jargon and tell me what the alternatives were.
4. Keep the README and the decision log up to date with every change.
5. Keep everything in plain, standard files that another AI tool or a developer could open. Nothing that only works inside this tool.
6. If a feature uses AI while running, build a fallback that still works when AI is off.
7. List every outside service, account and key the project needs.
8. At the end of each session, write three lines on what a new person would need to know to take over.
9. If I ask for something that breaks these rules, tell me before you do it.
10. When I start a new task that matches or is tied to a skill on my learning list, ask if I want to learn it or delegate it.
11. Never use my own accounts or keys. Ask me before any action that can't be undone.

Who checks, and when

On a solo project you hold all three roles. Once a project reaches level 3, bring in a second person as the reviewer: the takeover test only works with someone who didn’t build it. If you’re working alone, that person can be the expert from your safeguard.

Role	What they do
Builder	Works with the AI, ticks the checklist, keeps the README and decision log current
Reviewer	Runs the takeover test on level 3 projects. Must be someone other than the builder
Owner	Holds the accounts and decides whether a known gap is acceptable

Check before launch, after any big change, and when a project moves up a level.

When a check fails, write the gap down and fix it. If you decide to live with it, the owner writes the reason in the decision log.

How I apply this on my own projects

/loop, make me wiser: this article.

I’m writing this article with AI as a tool, as an experiment. I gave the AI rules and samples of my voice so it understands how I write, and I use a humanizer skill to strip out AI-sounding phrasing. Sometimes I asked for proposals based on best practices and applied changes to them.

Sometimes I wrote the whole thing and asked the AI to challenge it, to explain why, and what concept it was using to challenge what I wrote. I’ve noticed that I’m switching between both approaches consciously, knowing that I’m trading speed against learning, and I make the decision on my own.

I used Git to write this article and keep track of the changes. This approach also allowed me to understand how much was only me and how much the AI added to my work. Most of the content came from me: the AI mostly helped by correcting grammar, suggesting structure and challenging what I wrote, with a reason behind each challenge.

/loop, make me wiser: Mirror.

I couldn’t see how I worked with Cursor, Claude and Codex nor my working habits. I wanted to understand how this technology has an impact on how I work and on my cognitive health.

So I built Mirror: it allows me to “see how I work with AI before it changes how I think.” It’s a local tool that reads my Claude Code, Codex and Cursor session logs, tracks my challenge rate and approvals, and after a run of messages with no question or pushback, holds the next one and asks me to check it.

It’s open source: github.com/nicopalazzo/mirror (opens in a new tab)

Build it, own it: this portfolio.

When I was creating my portfolio website for the first time, all I wanted to do was build the skeleton and prove that I was able to ship a working product into production. So I decided to move fast instead of taking all the steps described in level 1.

To be transparent: while writing this article and applying the framework to how I work, I found small issues that I can fix quickly:

Running level 1 now showed me that the README doesn’t say where my product lives.
I also hadn’t moved all my passwords into a password manager. For this I’m using Bitwarden.

On the positive side, it allowed me to verify the following:

Accounts, domain, hosting and data are in my name. I have a GitHub repo, a Cloudflare account and my domain nicolaspalazzo.com.
The product has a backup on GitHub.

I fixed both gaps before this article went out.

Lend it, take it back: not applied yet.

I don’t run agents of my own yet, so I haven’t applied this principle to my projects. It comes from another project I’m working on, the Agent Portfolio Auditor: a tool that lists the agents in a company, flags the ones that still hold permissions nobody uses, and plans how to switch them off with a way back. It hasn’t been tested with real users yet.

Next steps

I invite you to try this approach, to challenge it and give feedback. The toolkit is one Markdown file you can download and use in your own projects. I’m open to thoughtful and constructive conversations leading to a future where human agency and mental health are built by design.

This is the work I want to do inside a company: helping teams adopt AI while keeping people in charge. If that’s something you’re building, let’s talk.

One last thing: while writing this article, I was struggling with this question: How would you know when to learn how to perform a task versus when to delegate it?