Keep this open while you build, not after. Twelve checks across six blocks, then a gate you run before calling anything finished. Tick what holds; whatever you cannot tick is the next thing to fix.
Credibility and durable skills
Basic builds are easy to copy now, so a portfolio of familiar demos proves less every month.
Write down what the build changed, not what you built
- [ ] I recorded how long the task took before the build and how long it takes now.
- [ ] I counted what leaked before (missed leads, dropped replies, wasted hours) and what gets caught now.
- [ ] The result is saved even though the project was small, or built only for myself.
- [ ] A short walkthrough connects the workflow to the outcome it moved.
A portfolio says what you built. A receipt proves what the build changed for the business.
Check that the setup survives losing its tool
- [ ] The core is folders, plain text files and instructions, not features of one interface.
- [ ] I could move it to another harness without rewriting the thinking.
- [ ] When it breaks I read the error and work the cause instead of switching tools.
- [ ] I can state the goal and the constraints in writing before I open anything.
Trap: a skill that only pays off inside one interface is a habit of that interface, not a skill.
The AI-native reflex
The test is what you reach for first when work lands on your desk, not how many models you can name.
Ask how much of this, before doing any of it by hand
- [ ] Before starting manually, I asked what share of the task a model could take.
- [ ] I took the partial win instead of waiting for something that handles all of it.
- [ ] Tasks I judged "not yet" have a date for asking again, because the tools keep moving.
Decision rule: ask to what extent AI can do the task, not whether it can.
Turn your expertise into negative prompts and context
- [ ] I described what a good result looks like in my field, in enough detail to grade against.
- [ ] I listed failures I have already seen, written as prohibitions: no unrequested features, no error handling for impossible cases.
- [ ] The model has the knowledge, instructions and skills around it that only I could supply.
Trap: everyone reaches the same model. The difference is what you wrap around it.
Managing AI like a team
Results come from management, not from one clever prompt. Treat the model as a new employee who can delegate to other employees, and whose output depends on the direction you set.
Make it ask, then make it argue
- [ ] I handed over the problem and let it propose the approach.
- [ ] It asked questions until it could restate the outcome in its own words.
- [ ] I named the adversaries for the critique: a skeptical buyer who has to trust the result, a competitor hunting for the weak spot, whoever maintains this in a year.
- [ ] The finish line is written down, so "done" is not a judgment call.
Trap: "any feedback?" gets you agreement. Name the adversary and it finds the hole.
Make it prove the work before it reports it
- [ ] I wrote down how I would review this deliverable if a person handed it to me.
- [ ] That review is now a step the system runs itself: driving a browser, running tests, reading its own output.
- [ ] Anything with a screen is checked for elements out of bounds, then checked again on mobile.
- [ ] Every important button gets clicked and every form submitted, with the payload confirmed at the receiving end.
Finish line: done means it produced the evidence, not that it said it finished.
Risk and permissions
Agents have written and sent real email to very large lists because one line on a task list read as permission. A prompt that says draft only is a suggestion while the send action still works.
Take the tool away instead of asking nicely
- [ ] Every key is scoped to the actions this agent needs and nothing more.
- [ ] Drafting and sending are separate permissions, and the drafting agent has no working send action.
- [ ] I listed every tool, database, file and credential the agent can reach.
- [ ] I asked whoever built the system what it can do unattended, and got a straight answer.
Safety rule: if the answer is uncomfortable, change the access rather than adding another sentence to the prompt.
Score it against known-good answers, not one lucky run
- [ ] I have a set of real, known-good answers to grade against. Even a few dozen is a start.
- [ ] Success criteria are written down with a grading method: code where the answer is objective, a model as judge where grading needs reasoning.
- [ ] I scored the current version across the whole set before changing anything.
- [ ] I change one thing at a time, prompt or tool setting or model, then score again.
Trap: a change that feels better often scores worse. One good run is an anecdote, not a success rate.
The real business constraint
A business runs like a pipe. Attention and leads enter at the front, revenue comes out the back, and growth stalls wherever something clogs the flow or leaks it out along the way.
Walk the pipe before you build anything
- [ ] I walked the process end to end, not the version described in the meeting.
- [ ] I can point at where work backs up, or where time and money escape before the end.
- [ ] What I am building addresses that spot, not the solution I was handed.
An order taker builds what was requested. A consultant fixes the part of the pipe that holds growth back.
Set the one number before the build starts
- [ ] One number defines success, agreed before any building starts.
- [ ] The baseline is measured and written down, not remembered.
- [ ] There is a target and a date attached to it.
- [ ] The stakeholder said out loud that hitting it would be worth the work.
North star formula: baseline plus target plus date is a finish line you can measure.
Say, hypothetically, a business gets five leads a week and agrees that fifteen a week inside two months would matter. That is a north star. "We automated the workflow" is not.
Making it pay
Providers charge for tokens, so the largest model on every step can make a working system uneconomic. And the opportunity usually arrives after the proof, not before it.
Route each step to the cheapest model that passes
- [ ] Every step has a model chosen on purpose, not inherited from a default.
- [ ] Bulk reading and summarizing run on a fast, inexpensive model.
- [ ] The capable reasoning model is reserved for the decision that depends on that summary.
- [ ] I confirmed the cheap model passes that step's evaluation before leaving it there.
Routing rule: use the cheapest model that consistently passes the evaluation for that task.
Ship proof before you ask for the title
- [ ] I picked one repetitive task I do every week and genuinely dislike.
- [ ] I automated it and measured the effect on my own work first.
- [ ] I showed the result to the people who would fund or approve more of it.
- [ ] If I want a first client, I built it for myself before selling it.
Enter the conversation with proof, not promises. Roles get built around work someone is already doing.
Before you call the project done
- [ ] One number defines success, and I can show it moved from a written baseline.
- [ ] The system verified its own work and produced evidence, not a claim.
- [ ] It scored against a set of known-good answers, not one successful run.
- [ ] Every credential and tool it can reach is one I would be comfortable naming out loud.
- [ ] Each step runs on the cheapest model that passes its evaluation.
- [ ] The receipt is written down while the details are fresh: before, after, what changed.