DEV Community: Mark Fulton

Freelance Developer Rates in 2026: How to Price Work an AI Agent Can Half-Do

Mark Fulton — Wed, 23 Sep 2026 09:54:32 +0000

A client asks for a CSV import feature. Two years ago you would have quoted 20 hours. Today an agent writes a working first draft in the first afternoon, and you spend the rest of the week making it correct.

So what do you bill?

That question is quietly rewriting freelance developer rates in 2026, and the public numbers already show where it is going. I want to walk through them, then price that same CSV job three different ways, because only one of the three still pays you properly when a machine does half the typing.

What the rate surveys actually say

Three surveys with real sample sizes, all published this year or last:

Arc surveyed 5,302 freelance developers worldwide for its 2026 freelance developer rates guide. The global bands run $20 to $50 an hour for juniors, $40 to $90 for mid-level, $75 to $150 for seniors, and $120 to $220 for staff and principal engineers. US and Canada sit at roughly $82 to $130. The line worth underlining is their explanation for the top of the range: AI "increased demand for experienced engineers", because someone still has to architect the system, review the generated code and own the security decisions.

freelancermap's Freelancer Study 2026 surveyed over 5,400 freelancers, mostly in the German-speaking market. The average hourly rate came in at €103, down from €104 in 2025. A one euro dip is small. It still broke a climb that started at €96 in 2022, and it landed in the same study where 85% of respondents said they actively use AI tools for writing, coding and images.

Stack Overflow's 2025 Developer Survey drew 33,662 responses to its AI questions. 84% use or plan to use AI tools. 66% name "AI solutions that are almost right, but not quite" as their top frustration, and 45.2% say debugging AI-generated code takes more time.

Put those side by side and you get a split market. The price of producing code is flattening. The price of judging code is rising. Your rate card has to decide which one you are selling.

One job, priced three ways

Back to the CSV import. Assume a $110 rate, which sits inside Arc's North American band, and an honest breakdown of the new week:

3 hours: agent drafts the parser, the mapping UI and the tests
5 hours: you find the "almost right" parts (encoding edge cases, a date column that silently swaps day and month, a memory spike on a 200 MB file)
2 hours: you rewrite the error handling so a client's customer sees which row failed and why

Ten hours of your time for the same outcome that used to take twenty.

Priced hourly: $1,100. You delivered the same feature, with better tests than you would have written by hand, and you were paid half. Every productivity gain you make flows straight to the client. Keep billing this way and the rate surveys above stop describing your ceiling and start describing your future.

Priced fixed: $2,200 for "CSV import with row-level error reporting, files up to 250 MB, tested against the three sample exports you supplied." You keep the margin. You also carry the risk, and that 66% "almost right" figure is exactly that risk. A fixed price works only when the scope line is sharp enough that "almost right" has a definition.

Priced on the outcome: the client's ops team spends a day a month re-keying spreadsheets. The import removes that. You price against the day, with a written acceptance test. This is the hardest conversation and the best-paid one, because the client is buying a result, not your calendar.

Only the first model punishes you for getting faster. That is the whole argument in one line.

Four rules for pricing work an agent can half-do

1. Stop selling hours you no longer spend. If the agent drafts in three hours what used to take ten, an hourly invoice hands your client the entire gain. Move repeatable work to fixed scope with a written acceptance test. Keep hourly for genuinely open-ended work: debugging someone else's production incident, discovery, advisory calls.

2. Price the review, not the typing. Arc's own explanation for rising senior rates is review, architecture and security. That is the scarce part of the job now. Name it on the quote. "Implementation and review of generated code against your data" tells a client what they are paying a senior for. "20 hours development" invites them to ask why a tool cannot do it.

3. Do not trust your own sense of speed. METR ran a controlled study of 16 experienced open source developers on 246 real issues in early 2025. With AI tools they took 19% longer, while believing afterwards that they had been 20% faster. METR itself calls that result a snapshot and says newer tools have moved on since, so do not quote the number as a law. Quote the lesson: the feeling of speed and the measured speed can point in opposite directions. Measure a few of your own jobs before you reprice anything.

4. Keep a record a client can check. When a feature arrives in two days instead of two weeks, a client's first question is what they paid for. A dated list of what changed each day answers it better than any explanation. Your commit history already is that list, if you keep messages readable. Line items that map to visible work end the "why so much for something the AI wrote" conversation before it starts.

Where freelance rates go from here

My bet: by the end of 2027 the phrase "hourly rate" will mean two different numbers. One is the rate for supervised implementation, and it will keep drifting down as the tools improve, the way freelancermap's series just flattened. The other is the rate for judgment: scoping, review, security sign-off, owning the outcome when it breaks at 2 AM. That number is the one Arc already sees climbing.

The freelancers who do well will not be the ones who refuse the tools or the ones who hide them. They will be the ones who price the outcome, show the record and stop apologising for being fast. The client does not care how many hours the parser took. They care that row 4,812 tells their customer exactly what went wrong.

Turn the record into the invoice

Rule four is the one most freelancers skip, because turning a week of commits into clean line items is tedious. That is the job I built billable.dev for. It is a free invoice generator for developers that runs entirely in your browser: import your git log, it groups the commits by day, you edit them into line items, add your rate or your fixed fee, and print a clean PDF. Nothing goes to a server. Your client sees dated, checkable work instead of a single "development" line.

If your next invoice covers work an agent helped with, try it on that one and see whether the conversation about the number gets shorter.

Want to compare rate cards with other builders? The Vibe Coding is Life community on Skool is free to join, come say hello.

Multi-Agent Systems: 4 Tests for When One Agent Beats Five

Mark Fulton — Tue, 22 Sep 2026 11:35:56 +0000

A team at Anthropic built a research system where one lead agent hands work to several subagents running in parallel. On their internal research eval it beat a single agent by 90.2%.

In the same write-up they said it burns about 15 times the tokens of a plain chat, and that token usage by itself explained 80% of the variance in performance on the BrowseComp benchmark.

Put those two numbers next to each other and the headline changes. Five agents did not win because five heads think better than one. They won largely because the job let them spend more compute in parallel on pieces that did not need each other.

That distinction decides whether a multi-agent design pays for itself or quietly fails. And there is now published data on how it fails.

The failure data

In 2025 a group of researchers from UC Berkeley and collaborators published Why Do Multi-Agent LLM Systems Fail?. The abstract opens bluntly: the performance gains of multi-agent systems on popular benchmarks "are often minimal."

So they went and looked at why. They collected more than 1,600 annotated traces across 7 popular multi-agent frameworks, labelled them with an inter-annotator agreement of 0.88 kappa, and ended up with 14 failure modes in 3 categories:

System design issues, roughly four failures in ten. Disobeying the task specification, repeating steps, and not knowing when to stop are the big ones.
Inter-agent misalignment, about a third. The single largest mode here is a reasoning-action mismatch: the agent says one thing and does another. Failing to ask for clarification and drifting off task follow.
Task verification, about a quarter. No verification, wrong verification, or stopping before the work is done.

Read that list again and notice what is missing. "The model was not smart enough" is not a category. The authors say it directly: failure "is not merely a function of challenges in the underlying model." Most of what goes wrong is structure. Who owns what, what counts as done, and who checks.

They also tried the obvious fixes on one framework. Clearer role specifications lifted the success rate by 9.4%. Adding a high-level verification step lifted it by 15.6%. Real gains, and the authors still concluded those isolated fixes were not enough and that reliability needs deeper redesign.

Four tests before you split one agent into five

Here is how I read the combined evidence as an operator. Before a job gets more than one agent, it has to pass four tests. Fail any one and a single agent with a good brief will usually win on cost, speed and reliability.

1. Does the work actually split?

Anthropic's own post names the poor fit: domains where every agent needs the same context, or where there are many dependencies between agents. They add that most coding tasks have fewer truly parallelizable pieces than research does.

The test is simple. Write the subtasks down. If subtask B needs the output of subtask A before it can start, you do not have parallel work. You have a pipeline, and a pipeline run by five agents is one agent with four extra handoffs, each one a chance for context to get lost.

Research splits well: ten sources can be read by ten readers who never talk to each other. Refactoring a module does not.

2. Is the job worth 15x the tokens?

If multi-agent runs cost roughly 15 times a chat, the output has to be worth that. A question someone asks once a quarter that saves a day of reading clears the bar easily. A routine task run a hundred times a day almost never does.

Price it before you build it. Take the cost of one good single-agent run, multiply by fifteen, and ask whether a person would pay that for the better answer. If the honest answer is no, the architecture is decided.

3. Can each agent be told exactly what done looks like?

System design issues were the biggest failure category, and the top modes inside it were ignoring the task specification, repeating steps and missing the termination condition. Those are all brief problems.

Every agent in the system needs its own written job: the input it gets, the output it returns, the format, and the condition that means stop. "Research the competitors" is not a job. "Return the pricing page URL and the lowest paid tier for each of these six companies, as a table, and stop when all six rows are filled" is a job.

If you cannot write that for every agent, you are not ready for more than one.

4. Who checks the work before it leaves?

A quarter of the failures were verification failures, and adding a verification step was the single biggest fix the researchers measured. That is the cheapest lesson in the paper.

A multi-agent system without a named checker is a group chat. Someone, human or agent, has to hold the definition of correct and compare the output against it before anything ships. Not "looks good", but a check against the spec from test 3.

Where this is heading

The paid skill is moving away from choosing the model and toward designing the roles.

Models will keep getting better, and the failure data says that will not fix most of this. Step repetition, missing stop conditions, one agent ignoring another, nobody verifying: those survive a model upgrade because they live in the design, not the weights.

So the operators who win the next two years will think less like prompt writers and more like managers. One agent per job. A written brief per job. A clear owner for the check. And the discipline to keep a job on a single agent when it does not split, even when the five-agent diagram looks better in a demo.

That also changes what you can sell. A client does not want "a multi-agent system." They want a job done on a schedule that they never have to think about. The builder who can say "this role handles your outreach, this one handles support, and this one reviews both every morning" is selling something a business already understands how to buy: staff.

Start from roles, not agents

That is exactly how the AI Employees are built. There are eight of them, each a named role with its own job: a GTM Engineer, an SEO/AEO Employee, a Web Dev Employee, a Social Media Employee, an Ad Manager, a Sales Employee, a Customer Satisfaction Employee, and a Chief of Staff for oversight. Each one is a complete routine set for a job you would otherwise hire for, and the whole set is open source and MIT licensed on GitHub.

It is the four tests above, already applied: one job per role, work that genuinely splits by function, and a role whose whole job is the check. Hire the one that matches the job you keep doing yourself and read how its brief is written.

If you want to talk through where your own work splits and where it does not, come hang out in the Vibe Coding is Life group on Facebook. Bring the job you are thinking of splitting.

App Directory SEO: 5 Rules for Getting an Indie App Found in 2026

Mark Fulton — Mon, 21 Sep 2026 09:13:02 +0000

Google's own spam policy has a list of link spam examples. Fourth on that list, word for word: "Low-quality directory or bookmark site links."

That one line kills the reason most indie developers submit to app directories. The plan usually goes like this. Ship the app, find a list of 100 directories, paste the same tagline into all of them, and wait for the backlinks to lift the domain.

Google's definition of link spam is "the practice of creating links to or from a site primarily for the purpose of manipulating search rankings." A directory you joined only for the link is that, by definition.

So are directories dead? No. The job they do has changed, and most submissions are still aimed at the old job.

What the documentation actually says

Three things from Google Search Central are worth knowing before you fill in another submission form.

Directory links are named as a spam pattern. The spam policies page lists low-quality directory links next to buying links, excessive link exchanges, and "using automated programs or services to create links to your site." Blast submission tools sit in that last bucket.

User-submitted links are usually qualified. Google's guidance on outbound links recommends marking user-generated content links with rel="ugc", and says links marked that way "will generally not be followed." A directory that takes public submissions is exactly the kind of site that should be using it. Check the source of a listing before you assume it passes anything.

Indexing is not a promise. Google's How Search Works doc says it plainly: "Google doesn't guarantee that it will crawl, index, or serve your page." Pages are discovered by following links from known pages and through sitemaps, and the same doc lists low-quality content and duplicate pages among the reasons a page is processed but never indexed.

Put those together. The link from a random directory is likely discounted or qualified, and the listing page itself may never be indexed if it carries the same copy as forty other listings.

What survives is the part people skip: a listing is a page that a person reads, on a site where people go to find software.

5 rules for app directory SEO that still hold

1. Submit for the reader, not the link

Ask one question before any submission. Would someone looking for an app like yours actually browse this site? If the only visitors are other developers dropping their own links, the listing does nothing for you and the link may do less than nothing.

A good directory is one where the traffic is people trying to find software, not people trying to be found.

2. Prefer directories with a gate

The cheapest signal that a directory is not a link farm is that something stands between your form and a live listing. A human review. A requirement that the app actually works. A category it has to fit.

A gate cuts both ways. It means your listing takes a few days. It also means every other listing next to yours passed the same check, so the page reads as a curated set rather than a dump. That matters to human visitors, and it is exactly the property a search system is trying to detect.

3. Write a different listing for every directory

Forty identical taglines are forty near-duplicate pages. Google clusters duplicates and picks one canonical, and the rest are candidates for never being indexed at all.

You do not need forty essays. You need the first sentence to change with the audience. A dev tools directory gets the technical hook. A general software directory gets the outcome. Keep a short file of three or four variants and rotate them.

4. Put the try path in the first line

People browsing a directory decide in seconds. The question in their head is not "what does it do" but "can I try it right now without talking to anyone."

Say it up front: free, free trial, or freemium. If a visitor has to click through to your pricing page to learn whether they can even start, most will not.

5. Measure try-clicks, not backlinks

Tag every directory URL with its own UTM parameters so your analytics can tell you which listing produced a signup. After a month you will know which three directories are worth maintaining and which thirty you can forget.

Backlink counts from a directory sweep tell you nothing about whether anyone arrived. A single listing that sends five people who try the app beats a hundred that send none.

Where this is heading

The reader of a directory is changing. Search engines were already discounting directory links. Now the systems that answer "what is a good free tool for X" are models and agents that retrieve pages, read them, and summarise. They do not care about link equity. They care about whether a page states clearly what the app is, who it is for, and how to try it, and whether the site it sits on is the kind of place that checks.

That flips the directory's job. It stops being a source of ranking juice and becomes a trust filter: a small set of curated, human-checked listings that a person or a model can read and act on. The developers who win discovery over the next few years are the ones who treat every listing like a small product page on a site that deserves it.

The practical move today is small. Pick five directories that pass rule 1 and rule 2, write five different listings, tag the links, and check the numbers in thirty days. That is an afternoon, and it beats a hundred-directory sweep.

Where I list apps

This is the reason I built TryMy.App. It is a free directory for apps people can actually try: every listing is free, has a free trial, or is freemium, so the try path is the whole point of the page. A human checks that each app is real, that the URL works, and that it is not a scam before it goes live. Paid-only apps, dead links and anything that is not yours do not get in.

Submitting takes about two minutes: the URL, a tagline, two or three sentences of description, and how people can try it. Free listings are the default and do not expire.

If you shipped something this year that people can try without a sales call, submit it there. Then go apply rule 5 and see whether it sends anyone.

I hang out with a big crowd of builders shipping things like this every week in the Vibe Coding is Life group. Come show what you are launching: facebook.com/groups/vibecodinglife.

AI Agent Security: 4 Failure Modes That Are Not Prompt Injection

Mark Fulton — Fri, 18 Sep 2026 11:46:10 +0000

Prompt injection is one item on a list of ten.

That is worth sitting with, because if you read the agent security conversation online you would think it was the whole list. The OWASP Top 10 for LLM Applications 2025 opens with LLM01:2025 Prompt Injection, and then names nine more things that will take your system down: Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption.

Nine of the ten are not about someone typing something clever into your chat box.

Here is why that matters more every month. Prompt injection is an input problem, and the model vendors are working on it with resources you do not have. The other nine are architecture problems, permission problems, budget problems and dependency problems. Those are yours. They do not get fixed by a better model, and in my experience they are the ones that actually cost a business money, because most of them do not require an attacker at all.

Four of them are the ones I would check first on any agent that is allowed to act. Each one below is quoted from the standard, then translated into what it looks like on a Tuesday when the agent is working exactly as designed.

1. Excessive Agency: the agent did what you let it do

OWASP defines this as a system that has been "granted a degree of agency by its developer, the ability to call functions or interface with other systems via extensions", and then does damage through unexpected or manipulated output. The important clause is the last one: regardless of cause. No adversary required.

The standard breaks it into three root causes, and they are worth memorizing as three separate questions:

Excessive functionality. Capabilities beyond what is operationally necessary. The classic version is handing an agent a shell tool because it was easier than writing four narrow ones. OWASP says it plainly: avoid open-ended extensions in favour of granular functionality.

Excessive permissions. Broader access rights than the role needs. The agent runs as a service account that can write to every table because that is the credential you had lying around.

Excessive autonomy. High-impact actions executed without independent verification. The agent sends, refunds, deletes or publishes with nothing between the decision and the effect.

Most teams I talk to have all three, and none of them were decisions. They were defaults.

The control is not clever. It is a written list of what this job may touch, scoped to that job, plus a human approval gate on anything consequential. One line from the mitigation guidance is the part people skip: implement authorization validation in downstream systems rather than relying on the LLM to police itself. The model is not your access control layer. It never was.

2. Improper Output Handling: your systems trusted a sentence

LLM05 covers "insufficient validation, sanitization, and handling" of model output before it reaches something else.

This is the failure mode that feels least like security and most like plumbing, which is exactly why it survives review. An agent emits a string. The string gets interpolated into a query, or a shell command, or a rendered page, or a config file. Nothing was injected from outside. The model simply produced a plausible sentence in a context where a sentence is executable.

The test I use is a single question: where does this agent's output stop being text and start being an instruction to another system? Every one of those boundaries needs the same validation you would apply to a form field filled in by a stranger, because in terms of trust, that is what it is.

3. Unbounded Consumption: the invoice is the incident

LLM10 is the one I think is most underrated, and the standard gives it a name I like: "Denial of Wallet (DoW)". OWASP describes it as attackers initiating high-volume operations to exploit pay-per-use cloud AI service models, imposing an unsustainable financial burden.

The agent version does not need an attacker. It needs a retry.

An agent that fails, retries with its full context appended, fails again and retries again is a cost loop that nobody wrote and nobody sees until the bill arrives. Multi-turn agent runs already grow context faster than most people expect, and a retry loop multiplies whatever that per-turn cost had already become. The failure is silent, it looks like normal usage in every dashboard, and the alert is an invoice at the end of the month.

The mitigations are unglamorous and they are the same ones you already know from API design: rate limits and per-user quotas, timeouts and throttling on intensive operations, resource monitoring, anomaly detection, and graceful degradation under load. The only new part is remembering that the agent is a user of your system, and a poorly behaved one.

4. Supply Chain: you did not write most of your agent

LLM03 covers vulnerabilities inherited through the chain: models, training data, deployment platforms, and the third-party components around them.

An agent's real surface area is rarely code you wrote. It is a model you did not train, a tool server you installed last month, a package that wraps an API, and a prompt template you copied. Every one of those is something that can change under you without a deploy on your side.

The question I would put on every agent review is uncomfortable and cheap to answer: if each third-party component in this agent were replaced tomorrow with a subtly worse version, which one would we notice, and how? If the answer for most of them is "we would not", you do not have a supply chain, you have a collection of assumptions.

The thing all four have in common

None of them requires a villain.

Excessive agency is a permission you granted. Improper output handling is a boundary you did not name. Unbounded consumption is a loop with no ceiling. Supply chain risk is a dependency you did not review. Prompt injection gets the attention because it has a narrative, an attacker doing something sneaky. The other four just sit there and behave like ordinary engineering debt until the day they do not.

This is where I think agent work is heading, and it is a good thing for the people reading this. Building an agent that demos is now table stakes. The scarce skill is running one: bounding what each job can touch, naming an owner for every action with a consequence, putting a ceiling on spend, and keeping a record you can actually check afterwards. That work looks a lot more like change management than like red teaming, and it does not get commoditized by the next model release.

If you want to be paid for agent work in a year, get good at the boring half. Anyone can make one run. Making one run for nine months without a surprise is the job.

Where to start if you want the operator side

I put the whole operator layer I use into the Agent Ops Club, and the free tier is genuinely free: the eight AI Employees on GitHub under an MIT licence, the Hire Your First AI Employee walkthrough, Masterclass modules 1 and 2 in full, the free public trainings and calendar, and Agent Ops Chat. No card required.

Each one is a named role with a named job, which is the whole point of this post. The next step is small. Open one of them on GitHub, read what it is allowed to do, and check it against the first failure mode above. If you cannot name the boundary of a job, that is the work.

If you build or run agents and want to compare notes with other builders, come and find us in Vibe Coding is Life on Facebook.

AI Agent Cost: Where the Money Goes in an Agent Run and 5 Ways to Cut It

Mark Fulton — Tue, 15 Sep 2026 11:46:24 +0000

A 20-turn agent run that reads about 59,000 tokens of material gets billed for 656,000 input tokens.

Nothing on that invoice is wrong. It's how a stateless model API works, and once you see the shape of it you'll never price an agent job off the rate card again.

So let's build one run on paper, price it against a live public price sheet, and see where the money actually goes. Then five ways to cut it, and why I think cost is becoming the skill that separates people who demo agents from people who get paid to run them.

The price sheet

Every price below comes from Anthropic's published pricing page, so you can check each one. I'll use Claude Sonnet 5, the mid-tier workhorse: $2 per million input tokens and $10 per million output tokens. A cache hit bills at 0.1x the input price, a 5-minute cache write at 1.25x, a 1-hour write at 2x. The Batch API takes 50% off both directions.

Two details in the same docs make the rest of this post work. The context windows page describes progressive token accumulation: each turn's input contains all previous conversation history plus the new message, and earlier turns are preserved completely. And the pricing page says tool use is billed on everything sent, including tool definitions, tool calls and tool results.

Put plainly, an agent loop pays for its entire past on every step.

One run, priced turn by turn

Here's a plausible research agent. These are my assumptions, not anyone's production numbers, so swap in your own.

A fixed prefix of 6,200 tokens: system prompt, tool definitions and the task.
Each turn, the model writes about 300 tokens, a short plan and a tool call.
Each tool call returns about 2,500 tokens, which is the pricing page's own estimate for an average fetched web page.

Every turn adds 2,800 tokens to the history, and every turn resends all of it.

	10 turns	20 turns	40 turns
Tokens in the final context	31,400	59,400	115,400
Input tokens billed across the run	188,000	656,000	2,432,000
Billed input vs final context	6x	11x	21x
Cost, no caching	$0.41	$1.37	$4.98
Output's share of that cost	7%	4%	2%
Cost, with prompt caching	$0.14	$0.33	$0.87

Three things jump out.

Output is a rounding error. Output costs five times more per token than input on this model, and it's still 4% of the bill at 20 turns. Telling an agent to be terse feels like cost control. It barely moves the number.

Cost grows with the square of the run. Going from 20 to 40 turns multiplies the uncached cost by 3.6, because every new turn resends a longer history than the one before. Your price per token is linear. Your price per task isn't.

The growth term is tool results. The prefix is fixed. What compounds is every page, file and search result the agent pulls in and then carries forward for the rest of the run.

5 ways to cut AI agent cost

1. Cache the prefix, and keep it still

Caching takes the 20-turn run from $1.37 to $0.33, which is 76% off. The docs say a 5-minute write pays for itself after one cache read, and a 1-hour write after two.

Two details decide whether you actually get that. Cache prefixes are built in a fixed order, tools, then system, then messages, so anything that changes near the top (a timestamp in the system prompt, a reshuffled tool list) turns everything after it into a fresh write. And the cache lifetime is measured from the start of the request, so a response that takes four minutes to stream leaves about one minute for the next request to reuse it. Slow steps and long pauses quietly break caching. That's what the 1-hour option is for.

2. Put less into the history

Tool results are the term that compounds, so the cheapest token is the one you never fetch. Return the three relevant paragraphs, not the whole page. Cap fetch sizes. Clear old tool results once they've been used, and summarize long histories instead of dragging them along. Both of those are documented platform features now, context editing and compaction.

There's a quality argument too. The context windows page says it directly: "As token count grows, accuracy and recall degrade." The bloated run usually isn't just the expensive one. It's the worse one.

3. Load only the tools the job needs

Tool definitions ride along on every request. The pricing page puts the browser use toolset at about 6,600 input tokens per request and the computer use toolset at about 4,500. Across 20 uncached turns, the browser definitions alone come to 132,000 input tokens before a single page is read. Give each job the smallest tool surface that can finish it.

4. Split long runs into short ones

The square law cuts both ways. Two 20-turn runs cost $2.74 uncached. One 40-turn run costs $4.98. If a job has natural phases, end each one with a short written handoff and start the next run from that brief instead of from 59,000 tokens of transcript. You pay for the brief once, not for the whole history on every turn.

5. Batch what isn't urgent, and match the model to the step

Work that doesn't need an answer in seconds (overnight classification, bulk enrichment, eval suites) can go through the Batch API at half price, and the docs say that discount stacks with caching. Then route steps by difficulty. The pricing page's own advice is Haiku for simple tasks, Sonnet for most production work and Opus for the hardest reasoning. A run that sends a date-parsing step to the top model is paying for judgment it never used.

One trap when you compare rate cards: the same page notes that Claude 4.7 and later models use a newer tokenizer that produces about 30% more tokens for the same text. A lower price per token isn't automatically a cheaper task. Measure tasks, not tokens. Every API response reports input, cache read and cache write tokens in its usage field, so log it per step and you'll know where the money goes instead of guessing.

Where this is heading

Per-token prices keep falling. The same page records that a scheduled price increase for Sonnet 5 was cancelled and its launch price made standard. Runs keep getting longer at the same time: current models take a million tokens of context at standard pricing and can write 128,000 tokens in a single response.

Put those together and the rate card stops deciding what an agent costs. The architecture decides. Two developers on the same model at the same price can land 4x apart on the same job, purely on caching, tool surface and run length.

That makes cost an operations discipline, not a procurement one. The person who can say "this job costs 33 cents a run, here's where it goes, and here's what happens at 40 turns" gets trusted with the budget. The person who can't gets their agent switched off the first time an invoice surprises someone. And as businesses shift from buying software to paying for work that gets done, knowing the unit cost of a task is what lets you price that work at all.

Learn it on a job that already exists

The fastest way to get good at this math is to do it on a real job instead of a toy loop. That's the idea behind the Agent Ops Club, which teaches agent operations as a trade. Its eight AI Employees are on GitHub under the MIT license. Free to hire. Yours to run.

The free tier includes those eight employees, the Hire Your First AI Employee walkthrough, the first two Masterclass modules in full, the public trainings calendar, and Agent Ops Chat at three messages a day. No card required.

To be straight about the bridge: the club won't hand you a cheaper model. It gives you real jobs to run and a place to learn the operating side of them. So the next step is to start free, hire your first employee with the walkthrough, and ask it this post's five questions: what's in the prefix, what goes into the history, which tools it loads, how long it runs, and what could wait for a batch.

Want to compare notes with other builders first? There are 335,000+ of them in Vibe Coding is Life: come find us on Facebook.

How to Get Your First 100 Users When You Built It Alone: 5 Unscalable Moves

Mark Fulton — Mon, 14 Sep 2026 09:37:15 +0000

Ben Silbermann shipped Pinterest the way almost every solo builder ships: he emailed all his friends and hoped. His own account of how that went, from Lenny Rachitsky's roundup of how the biggest consumer apps found their first users, is blunt: "no one really got it."

That's the default launch. You build the thing, you post it, you tell the people who already like you, and you wait for a curve that never bends.

If you built your product alone, the default is even more tempting, because you're tired, you've been heads down for weeks, and the part of launching that involves strangers feels like a different job. It is a different job. Here's what the public record says about doing it well, and where I think it's heading now that building has stopped being the hard part.

What the record actually says

Two sources are worth reading in full before you launch anything.

The first is Paul Graham's Do Things that Don't Scale, from July 2013. His core observation is one sentence: "The most common unscalable thing founders have to do at the start is to recruit users manually." He names the fantasy it replaces too, the one where you build a better mousetrap and people beat a path to your door. And he gives the examples everyone quotes: the Stripe founders taking a prospect's laptop and setting them up on the spot, Wufoo mailing each new user a handwritten thank you note, and Airbnb, which he describes as so fragile early on that "about 30 days of going out and engaging in person with users made the difference between success and failure."

The second is Lenny's How the biggest consumer apps got their first 1,000 users, from May 2020. He went through first-hand accounts from founders of Tinder, Uber, Slack, Airbnb, Pinterest, Etsy, DoorDash, Spotify and others, and sorted what they did into seven strategies: go where your users are offline, go where they are online, invite your friends, create FOMO, use influencers, get press, and build a community before launch.

The finding that matters most is the count. In his words, most of those companies found their early users from a single strategy, a few used a handful, and "No one found success from more than three."

Put the two together and you get something you can act on today. Getting the first users is manual work, and it's focused manual work. Not everything at once. One or two channels, done by hand, until they catch.

5 moves for your first 100 users

1. Pick one channel and write down why

Before you post anywhere, finish this sentence: "100 of the people I built this for already spend time in ____."

If you can't fill the blank with a specific place, you don't have a launch problem yet. You have a positioning problem, and posting to six platforms will hide it from you for another month.

Graham's essay records how Silbermann eventually found his: a lot of early Pinterest users cared about design, so he went to a design bloggers conference to recruit. One room, one kind of person, one reason for them to care.

2. Recruit by name, not by post

A launch post asks strangers to come to you. Manual recruiting goes to them.

The practical version for a solo builder is a list. Write down 100 real names or handles of people who have the problem, in the channel you picked. Then contact them one at a time, with a message about their problem, not your product. A reply rate of one in five still gets you twenty conversations, which is more signal than most launch days produce.

3. Do the setup for them

The Collison installation is the most copied move in the essay because it works on two levels. The obvious one is conversion: nobody bounces off a signup flow that someone else is filling in for them.

The less obvious one is what you learn. Every time you sit with a user and do the first run yourself, you watch exactly where a normal person would have given up. That's your onboarding backlog, written by reality instead of by you. For developer tools this is a screen share and a first install. It doesn't scale, and that's the point.

4. Start with a fire small enough to catch

Graham points at Facebook starting inside a single university for a reason. A product that's for everyone is for nobody on day one, because nobody feels like it was built for them.

Narrow the first audience until your 100 users could plausibly know each other. Framework users in one ecosystem. Freelancers who bill a particular way. Founders launching in the same month. Small, dense groups talk, and talk is the only growth loop you can afford when you're one person.

5. Help first, then ask

This is the move the older playbooks underrate, and the one I think matters most right now.

The people most reachable for a solo founder are other solo founders. They're launching too, this week, and they need exactly what you need: a real review, a testimonial, honest feedback on a landing page, a share to an audience that isn't their own. If you do that for them first, the ask that comes later isn't a cold ask. It's a return.

Where this is heading

Here's the part that changes the math.

Building a working product used to take long enough that the number of launches in any week was naturally limited. It isn't anymore. A solo developer with good agents can ship something real in days, and so can everyone else, so the number of products competing for a first look keeps climbing while the hours people have to look at them stay the same.

When generation gets cheap, the scarce input moves somewhere else. For launches, it moves to the unscalable part: human attention, given on purpose, by someone who actually tried the thing. Graham's advice from 2013 isn't getting old. It's getting more valuable, because it's the one part of shipping an agent can't do for you.

My bet is that distribution for small builders shifts toward reciprocity. Not audiences you rent, but rooms of founders who trade real help with each other, where the help is verified and the favor gets returned. The builders who figure that out early get their first 100 users from people who understand exactly what it costs to launch alone.

Where I'd start

That's why I built Favors.dev. It's a marketing co-op for founders who ship, built on one idea: other founders are your new growth channel.

It works in three steps. You do favors for other founders, like reviews, testimonials, shares and feedback. You earn verified points for the work you actually complete. Then you spend those points on a rally for your own launch, so the support shows up when you need it. Points are earned, never bought, which keeps the help honest.

To be clear about the bridge: it won't replace moves one through four. You still have to pick your channel and talk to your users by hand. What it does is make move five something you can do on purpose instead of by luck. It's free to join, and you start with 250 points, so the next step is to go help one founder whose launch is live today.

If you want a room full of people building the same way, the Vibe Coding is Life group has 335,000+ builders in it: join us on Facebook.

How to Make AI Agents Reliable in Production: 4 Conditions That Decide It

Mark Fulton — Wed, 09 Sep 2026 09:50:24 +0000

Ninety percent of the developers in this year's DORA survey use AI at work. More than eighty percent say it has made them more productive. Thirty percent say they have little or no trust in the code it writes.

Read those three numbers together and they look like a contradiction. Almost everyone uses it, most people feel faster, and a third of them do not believe the output. That is not a contradiction. That is what a tool looks like when it has been adopted faster than it has been absorbed.

DORA surveyed nearly 5,000 technology professionals and collected over 100 hours of qualitative interviews to get at why, and the finding they led with is the most useful sentence written about agents this year:

"AI doesn't fix a team; it amplifies what's already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems."

I have been running agent systems in production across my own products for most of a year now, and that line matches what I see every week. The model is not the variable. Every serious builder is within a few months of the same frontier capability. The variable is the surface the model lands on.

Which means the useful question is not "which agent should I use." It is "what does my current setup amplify."

Four conditions, and what happens without each one

I want to give you these as pairs, because the interesting part is never the good version. Everyone can picture the good version. The interesting part is what the exact same agent, on the exact same model, produces when the condition is missing.

1. A written standard.

Present: the agent inherits your judgment. It knows what you consider finished, what you consider sloppy, and what you would never ship. It applies that consistently at three in the morning, when you are asleep and cannot be consulted.

Absent: it invents a standard. Not once, but freshly, every run. You get output that is defensible in isolation and incoherent in aggregate, because nine runs made nine slightly different calls about the same question. This is the most common failure I see, and it never announces itself. Each individual result looks fine.

The fix is boring and it works: write the standard down in the place the work actually reads from. Not in your head, not in a chat you had last week. Most teams skip this because writing a standard is hard and prompting is easy, and then they spend the saved hour ten times over.

2. A bounded job.

Present: a wrong run is cheap, visible, and reversible. You can afford to let the thing be wrong, which is the entire reason it can be autonomous at all.

Absent: the blast radius is whatever the agent decided to touch. And here is the part people underrate: unbounded jobs do not just fail worse, they fail slower. A bounded job that goes wrong tells you in ten minutes. An unbounded one tells you in three weeks, through a customer.

Bound every job with a window and a budget before you bound it with a prompt. If you cannot say what the worst run of this job costs you, it is not ready to run unattended.

3. A record you can check.

Present: you can tell a good week from a lucky week. You can look back at thirty runs and see the shape of the thing, which is the only way anyone has ever improved a process.

Absent: the agent reports its own success in prose, and prose about your own performance is unfalsifiable. "Completed successfully, reviewed 14 items, no issues found" is a sentence that reads identically whether the job worked perfectly or did nothing at all. I have been fooled by exactly this sentence more than once.

Make the deliverable an artifact rather than a summary. A file, a row, a diff, a queue entry. Something that exists whether or not the agent felt good about the run.

4. A named owner.

Present: somebody rules on the output. Not reviews everything, rules on the edge cases, and their ruling goes back into condition one.

Absent: output accumulates. This is the quietest of the four and the most expensive. Nothing breaks. There is just steadily more of something, and no one has decided whether any of it was right, and by the time anyone looks the volume makes looking impossible.

If you cannot name the person who owns an agent's output, you do not have an agent. You have a generator.

Where this is going

DORA also found that AI acceleration exposes weaknesses downstream, and identified seven distinct team profiles rather than one path. That plurality is the signal. There is no single "adopt AI" move, because the move depends entirely on what your organization already is.

Here is my read on where the paying work goes. Generation has collapsed in price and will keep collapsing. What has not collapsed, and shows no sign of collapsing, is the cost of making generated work survive contact with a real business. That is a specification problem, an ownership problem, and an operations problem, and none of the three gets solved by a better model.

So the person who gets paid over the next few years is not the one who can build the thing fastest. It is the one who can install the four conditions above into a business that does not have them, and then keep the whole arrangement running. That role has a name now in more than one company: forward deployed engineer. I think it becomes the default shape of technical work, not a specialty.

If you are trying to position yourself, position there. Not on prompt tricks, which have a shelf life measured in months, but on the ability to make an autonomous system trustworthy inside somebody else's operation. That skill is durable because it is mostly not about the model.

What I built around this

The Agent Ops Club is where I put all of it. Eight AI employees you can hire for real roles, SEO, go to market, web development, social media, ads, sales, customer satisfaction and a chief of staff, plus a 45 lesson masterclass that walks through deploying and customizing them, and a product pass covering 27 premium systems with a resale license, so you can install a system for a client and keep every dollar of the deployment.

The free account is genuinely free and takes no card. It gets you the eight AI employees under an MIT license, the first two masterclass modules complete, the public trainings, and daily access to Agent Ops Chat. If the four conditions above are the argument, the free tier is the cheapest possible way to test whether you agree with it.

Have a look: https://club.reinventing.ai

One ask, and it is a small one. If you have run an agent unattended in production, tell me in the comments which of the four conditions you got wrong first. I will bet on number three more often than not, and I would like to know if I am wrong about that.

If you want the ongoing version of this conversation, Vibe Coding is Life is where I spend my time, 335,000+ builders arguing about exactly this: https://facebook.com/groups/vibecodinglife

Source for the survey figures: the 2025 DORA State of AI-assisted Software Development report, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

How to Build AI Monitoring Agents: 4 Rules for Catching Time-Sensitive Events

Mark Fulton — Mon, 07 Sep 2026 06:14:35 +0000

Run a WHOIS lookup on any domain name and you get back a status code. Not a paragraph, not a guess. A code, from a standardized list of seventeen, published by ICANN, that tells you exactly where that name sits in its life.

Most of those codes are boring. A few of them are a countdown.

Here is the sequence when somebody stops paying. The registry sets autoRenewPeriod, a grace window after the registration expires. If the registrar gives up on it, the name moves to redemptionPeriod, and ICANN's own description of that code is unusually precise: "Your domain will be held in this status for 30 days. After five calendar days following the end of the redemptionPeriod, your domain is purged from the registry database and becomes available for registration."

Then pendingDelete. ICANN describes that one as the state a name reaches after it "has been in redemptionPeriod status for 30 days and you have not restored it within that 30-day period." A few more days and it is gone from the registry. Available. To anyone.

Read that again as an engineer rather than as a domain buyer. That is a documented state machine, with published transitions, exposed over a queryable protocol, running continuously on every registered name on the internet. Nobody is hiding it. ICANN publishes the whole table.

So why does anyone ever miss a name they wanted?

The information was never the constraint

This is the thing I keep running into, and it has nothing to do with domains.

The valuable state on the web is overwhelmingly public. Certificate expiry dates are public. CVE feeds are public. Rate limit headers, deprecation notices, changelogs, status pages, pricing pages, filings, job boards, package registries. All published, most of it structured, a lot of it timestamped.

What is scarce is something that is awake at the moment the state changes.

We spent the last two years making models better at answering questions. That is real progress and I use it every day. But the questions that pay are usually not the ones you think to ask at 2pm on a Tuesday while you have the tab open. They are the ones you asked once, months ago, and would want answered again the instant the answer changes.

A chatbot cannot hold a question. It can only receive one.

That is the gap I would build into if I were starting today. Not a smarter responder. A thing that holds a standing question and stays quiet until the world moves.

Four rules I would give anyone building a watcher

I have built a number of these now, some good, some that I ended up muting, which is the same as never having built them. The ones that survived have four things in common.

1. Write the definition of interesting before you write the watcher.

You cannot be woken up by "good opportunities." You can be woken up by a predicate. If you cannot express what qualifies in a sentence that would still make sense to a stranger, you do not have a watcher, you have a feed. The hard part of this work is almost never the polling. It is being honest about your own taste and then committing it to something readable.

2. Build on declared state, not inferred state.

A status code beats a ranking. A version number beats a vibe. When a source publishes its own state, you are reading a fact; when it does not, you are running a model over evidence and inheriting every error that model makes. Both are sometimes necessary, but you should always know which one you are doing, and you should reach for the declared version first. The seventeen EPP codes are valuable precisely because they are boring and unambiguous.

3. Your sampling rate has to be shorter than the window.

This is the one people get wrong most often, and it is not a subtle bug. If the opportunity is open for five calendar days and your job runs weekly, that job is not slow. It is broken. It will report success forever and catch nothing, because it can miss the entire window while every individual run is green.

Whenever I set up something on a schedule now, I write down the shortest window it needs to catch, and the interval has to fit inside it with room to spare. If it does not, either the interval changes or the job is not worth running. There is no third option, and a cheerful log line is not evidence that there is.

4. Tune for silence.

A watcher's quality is not how much it finds. It is how rarely it is wrong when it speaks.

Interrupts have a real cost, and you will pay it with your attention every single time. A watcher that surfaces forty things a day is a second inbox, and you will mute it inside a week. Bias hard toward precision. Let it miss things. A watcher that speaks twice a month and is right both times gets to keep its access to you, and that access is the entire product.

Where I think this goes

Right now almost every agent product is priced per task. You ask, it works, you pay for the working.

I think the durable ones get priced per watch, because coverage over time is a different axis from capability, and it is the one that compounds. A model getting smarter does not make an absent agent present. No amount of reasoning quality rescues a system that was not running when the state changed. Those two things trade off against each other far less than the current discourse assumes, and only one of them is getting cheaper.

Which means the operator's job is shifting again. Less about asking better questions in the moment. More about maintaining a portfolio of standing ones, with an honest definition of interesting attached to each, and the discipline to keep them quiet.

That is unglamorous work. It is also the part nobody can hand to a model, because the definition of interesting is yours.

The one I built for this exact state machine

PounceDomains is a watcher pointed at the drop and auction cycle I described above.

You describe the kind of names you want in plain English and it builds a tuned config from that. It scans the Namecheap Marketplace around the clock and grades ending-soon domains against your taste rather than against a generic score. Every match arrives enriched, so you are looking at authority, backlinks, search demand, domain age and comparable sales at the moment you decide, instead of opening six tabs to assemble that yourself. When something qualifies, it alerts you with its reasoning and a one-click path to bid, and you make the call. It will also watch names you already own and remind you before your own expiry dates turn into someone else's opportunity. There is optional auto-bid with a master switch, a per-domain maximum and a daily budget cap, for people who want it, and it is off until you turn it on.

Rule four is the whole design. It is built to stay quiet.

You can start free at pouncedomains.com.

The small ask: pick one thing you currently check by hand, on a loop, because you are afraid of missing it. Write down the one sentence that would make it worth waking you. That sentence is the actual product, and you can build the rest in an afternoon.

If you want to do that alongside a few hundred thousand other people building this way, the Vibe Coding is Life group is open and it is where I post most of what I learn: facebook.com/groups/vibecodinglife.

Agent task length doubles every seven months. The reliable version is 18 months behind.

Mark Fulton — Fri, 04 Sep 2026 05:33:21 +0000

METR has been tracking one number since 2019, and it is not a benchmark score. It is a duration: the length of a task, measured in how long a human expert needs, that a frontier agent can finish on its own.

The headline result from their NeurIPS 2025 paper is that this duration has been doubling roughly every seven months since 2019, across a suite of about 230 tasks. Over 2024 and 2025 the doubling compressed to about four months.

That is the curve everyone quotes. It is measured at a 50% success rate.

METR measures a second curve at 80%, and that one sits several times lower. Their figures put the 80% horizon around four to six times shorter than the 50% horizon, with both curves climbing at close to the same rate. Run the arithmetic. Four to six times is between two and two and a half doublings. At seven months per doubling, the reliable curve is trailing the famous one by roughly a year and a half.

Every real decision you make about putting agents to work lives in that gap.

The gap is not a model problem

It is tempting to read the two curves as "the model is not good enough yet, wait for the next release." That reading has cost people a lot of money.

Look at what actually separates a 50% run from an 80% run on the same task. The model did not get dumber on the failures. It hit an input shaped slightly differently than the ones it got right. It made a defensible choice at a fork where the correct answer was never written down. It finished, produced something plausible, and nobody could tell from the output whether this was one of the good runs.

None of that is fixed by a better model. It is fixed by narrowing the job until the ambiguity is gone, and by deciding in advance what happens on the runs that miss. That work is not prompt writing. It is specification, and it is the entire discipline that agent operations turns out to be.

Here is the thing worth internalizing: the 50% curve tells you what is now possible. The 80% curve tells you what you can staff. Confusing the two is how a demo that impressed everyone in the room becomes an incident three weeks later.

Sort the job before you schedule it

The practical version of this fits in one question. Before an agent job goes on a schedule, ask what a wrong run costs, and put the job in one of three boxes.

Box one: it finishes. A wrong run is cheap, visible, and reversible. Nobody outside sees it, and the next run overwrites it. Research passes, drafts, classification into a queue, monitoring that reports rather than acts, anything that writes to a file you own. These are the jobs to let run unattended, and there are far more of them than most people schedule. A 50% agent is genuinely useful here, because the cost of the misses rounds to zero and the hits compound.

Box two: it drafts, you commit. A wrong run is recoverable but embarrassing or expensive to undo. Anything that leaves your control: outbound messages, published copy, changes to a paying customer's data, spending. The agent does everything up to the irreversible step and then stops. This is where the 80% curve actually bites, because 80% is not good enough to send on its own and it is far more than good enough to do the ninety percent of the work that precedes sending. Separating capture from send is the single highest-leverage split in this whole field, and almost nobody makes it explicitly.

Box three: it does not touch this. A wrong run cannot be undone, or the blast radius is not bounded. Deletion, key rotation, anything financial, anything that changes access. The right answer is not a more careful prompt. It is that the job is not an agent job this year.

Two rules make the triage hold up. Bound every job in the first two boxes with a window and a budget, so a stuck run costs you a known amount and then stops. And make the deliverable a record rather than prose: a row you can count and audit later, not a paragraph telling you it went well. An agent that reports its own success in sentences is unfalsifiable, and unfalsifiable output is how you end up trusting a system that quietly stopped working.

The boxes move. The procedure does not.

This is why I think the triage is worth learning rather than waiting out.

As the reliable curve climbs, jobs migrate from box three to box two, and from box two to box one. That migration is the whole story of the next few years, and it is genuinely fast: a year and a half of lag is not a decade. But the sorting question never changes, because it was never a question about the model. It is a question about what a wrong answer costs you, and that is a property of your business.

Which means the person who learns to sort now is not doing throwaway work. They are building the thing that stays useful while everything underneath it gets better.

Where the paying work goes

Generation is close to free and getting freer. The scarce thing is somebody who can look at a real business, name the jobs, sort them into those three boxes, write the specification tight enough that the agent lands in the reliable band, and then keep the thing running when reality changes shape.

That role has a name now, and it is showing up in job postings as forward deployed engineer. Strip away the title and it is the same trade: the value has moved from producing software to installing and operating it. Companies are not short of output. They are short of anyone who will take responsibility for a running system.

If you can do that, you are not competing with a model. You are the reason the model is worth anything to a business.

The invitation

I built the Agent Ops Club around exactly this. The framing on the page is "free to hire, yours to run": you hand an AI employee the work you are furthest behind on, and it runs that job on a schedule. It is the box-one and box-two idea turned into something you can actually put to work rather than read about. There is a free tier, so you can go see whether the argument above survives contact with your own backlog before you spend anything.

If you take one thing from this post and skip the link entirely, take the triage. Write down your three boxes this week, honestly, and notice how many jobs you have been keeping in box three out of habit rather than blast radius.

I write up more of this with the builders in the Vibe Coding is Life community, and I would genuinely like to see other people's box-two lists, because that is where I think most of the unclaimed leverage is sitting right now.

So the small ask: what is one job you would move into box one today if you trusted it to fail quietly? Leave it in the comments and I will tell you how I would bound it.

Generation is free now. The filter is the whole business.

Mark Fulton — Mon, 31 Aug 2026 05:42:24 +0000

One of my products has scored more than 390,000 domains.

On a normal day, the number worth acting on is about fifteen.

Sit with that ratio, because I think it is the most important number in AI right now and it has nothing to do with domains. Three hundred and ninety thousand in, fifteen out. The product is not the scoring. The product is the discarding.

We spent two years getting very good at making things. Text, images, code, campaigns, entire applications from a paragraph of description. That problem is solved to the point of being boring. Generation is effectively free and it gets freer every quarter.

Judgment did not get free. It did not even get cheaper. And a world with infinite output and constant judgment is a world where the value migrates to the filter.

The bottleneck moved and most people are still building for the old one

Watch what people ask AI for and you can date them.

The 2024 question was "can it make this for me". The 2026 question, the one people actually pay to have answered, is "of the ten thousand things it just made, which three are worth my afternoon".

Nobody is short of leads. They are short of a reason to call this one. Nobody is short of content ideas. They are short of a reason to write this one. Nobody is short of investment opportunities, job candidates, feature requests or support tickets. They are drowning in all of them and starving for a standard that thins the pile.

If you are building an AI product right now and it produces more of something, you are competing in the one category that trends to zero. If it produces less of something, and the less is better, you have a business.

What a judgment layer actually is

This is the part worth stealing, so let me be specific about what separates a real filter from a wrapper with "AI-powered" on the landing page.

It encodes a taste, and the taste has an owner. A filter is somebody's opinion made repeatable. If you cannot say whose standard is in there and why they earned the right to hold it, you do not have a filter. You have a coin flip with good manners. This is what people mean when they say prompt engineering is maturing into something serious. It is not phrasing tricks. It is the discipline of writing a judgment down precisely enough that a machine can apply it a hundred thousand times without drifting.

It says no far more often than yes. A gate that approves most of what it sees is decoration. The uncomfortable part is that a good filter has to reject things that are genuinely fine, because the job is not fairness to the inputs, it is protecting the attention of the person on the other side. Every filter I have shipped got better the day I made it stricter and worse every time I softened it to be nice.

It shows its reasoning and stays overrulable. The moment a person cannot see why something was rejected, they stop trusting the system and go back to scrolling the raw list. A verdict without a reason is not judgment, it is just a verdict. Give people the why and they will let the machine handle the volume forever.

It is boring to run. Nobody claps for the thing that quietly discards 389,985 items, and that is exactly why it is defensible. Impressive output is easy to copy in a weekend. A standard tuned against real outcomes for two years is not.

That 390,000 number, for the curious, comes from PounceDomains, which watches the domain aftermarket and hands an investor the short list instead of the firehose. The domain part is incidental. The shape is the point, and you can apply the same shape to leads, applicants, tickets or trades.

Where the paying work is going

Here is the part I would bet on, and I am betting my year on it.

Businesses are not going to buy models. Models are a commodity input and they already know it. What they cannot buy off a shelf is a standard installed inside their operation: the thing that decides which lead is real, which invoice is wrong, which applicant to call, which of today's thousand possible actions the business should actually take. That is judgment, it is specific to them, and someone has to sit with them and build it.

That someone is the job. Not a prompt engineer, not a model trainer. An operator who can walk into a business, find the place where people are drowning in volume, and install a standard that thins it. Agent operations, done properly, is that trade.

Good news if you are reading this on a developer site: you are already most of the way there. You understand systems, constraints and failure. The missing half is commercial, and it is learnable far faster than the technical half was.

That gap is why I built the Agent Ops Club. It is the whole operation handed over: learn agent ops, license the software, sell it as your own. I install your first agent employee with you live, you get the library under a resale license, and it carries a first client guarantee, which is that you land your first client within ninety days or I keep working with you one to one until you do. I put a guarantee on it because I believe the argument above. There is far more demand for installed judgment than there are people who can install it, and that gap stays open for years.

One small ask before you go, and it costs you nothing. Look at whatever you are building and tell me what it refuses. If the answer is nothing, that is the most valuable thing you will learn this week. I am around in the Vibe Coding is Life group if you want to argue with me about it.

Agents crossed 99% this year. Here is where the paying work goes next.

Mark Fulton — Fri, 28 Aug 2026 06:25:45 +0000

In June 2026 a browser-control agent scored 99.19% on the WebVoyager benchmark, measured across 643 live-web tasks on 15 real websites. The leaderboard is public.

I had been waiting on that number for about two years. In October 2025 I posted publicly that the missing piece was 99% reliable browser use agents, that Gemini had just reached 69%, and that it would be over within the year. I am not claiming a crystal ball. I am saying I bet a business on the assumption and the assumption held, and I want to tell you what I think happens next, because I think most developers are still preparing for the wrong thing.

Under 70% is a demo. Over 99% is staff.

This is the distinction I would tattoo on people if I could.

Below roughly 70% reliability, an agent works in the video and fails on Tuesday. You cannot put it in front of a client, because the failure is silent and the cleanup costs more than the task did. Every "look what I automated" thread you have scrolled past lives in that band.

At 99% it stops being a demo and becomes staff. Not because it got smarter, but because you can finally stop watching it.

And the work that opens up at that threshold is not the work people expect. It is not more code generation. It is the enormous category that never had an API in the first place: the dashboard that only renders in a browser, the platform that never shipped a public endpoint, the interface built for a human and nothing else. That work has been permanently off limits to automation. It is also most of what people actually do at work.

So the interesting question stopped being "can an agent do this." It became "who is going to walk into a business and set it up."

Four things I learned running agents in production

I have been building AI agents for four years and I have sold over $1M in web and AI solutions. Most of what I know came from things breaking at 3am, so let me shortcut some of it for you.

Reliability is a specification problem, not a model problem. When an agent fails in production, the instinct is to reach for a bigger model. In my experience it is almost always that the job was underspecified and the agent filled the gap with a reasonable guess. Reasonable guesses are exactly what you do not want at scale. Before you upgrade anything, go read what you actually asked for.

Write the standard once, in the place the work reads it, not in the chat. This is the single highest-leverage prompt engineering move I know and almost nobody does it. If you correct an agent in conversation, you have fixed one run. If you write the rule into the file the routine loads every time, you have fixed every future run. I run five separate publishing routines against one shared standards document. Fixing behavior in that one file changes all five. Corrections that live only in a chat window get re-taught forever.

Narrow the job, do not broaden the model. An agent asked to "handle marketing" will fail. An agent asked to do one role, with a defined output, on a schedule, succeeds far past where people expect. Reliability comes from the shape of the job. This is why I package agents as whole roles rather than as scripts or as one universal assistant.

Nothing counts until it has survived contact with a real business. A system that works in a clean repo is not a system. It is a demo with good lighting. I do not consider anything finished until it has run unattended against real data, on a schedule, for weeks, and I would suggest you hold the same bar before you put your name on something for a client.

Where the paying work is going

Enterprise AI companies popularized a title for what is coming: the Forward-Deployed AI Engineer. An engineer who embeds with a company's operations teams and builds custom business agents on-site. Not a consultant who leaves a slide deck. Someone who sits with the sales team, the support team and the marketing team, and leaves working agents running behind them.

Medium and large businesses want agents working alongside their people. Almost none of them have anyone on staff who can make that happen, and they are not going to solve it by hiring another SaaS subscription.

Here is the part I would think carefully about if I were you. The value is moving away from writing the software and toward deploying and operating it. The person who can walk in, understand how a business actually runs, and leave three agents doing real jobs is going to be worth considerably more than the person who can produce the same three agents in isolation. That is a different skill set, it is closer to consulting than to engineering, and very few developers are building it deliberately.

The agentic shift is not going to take your work. It is going to move where the work is paid, and it is moving toward whoever can install this stuff inside a business that does not speak your language.

What I built, and the invitation

Agent Ops Club went live yesterday at club.reinventing.ai. It is the whole operating model, packaged as the job above.

Members get the Agent Ops Masterclass, 9 modules and 44 lessons covering the model end to end. A library of 22 full stack systems with a resale license, each of which ran in my own business before it entered the library. Eight Agent Employees as whole roles, GTM Engineer, SEO, Web Dev, Social Media, Ad Manager, Sales, Customer Satisfaction and Chief of Staff, each running routines on schedule. Live strategy sessions with replays, 1 on 1 booking, and new systems added regularly.

The license is the part that matters, so I will state it plainly. You can customize and deploy everything in the library for clients at any price you set, and you keep every dollar. You can sell implementation and managed operations on top, and I take no cut of that either. What you cannot do is redistribute the source or hand the code to a client. Deployments yes, source redistribution no. The Agent Employees fall under that same license, which means you can sell them, and very few people are offering that yet.

There is also one thing I expect to regret. Every member can claim one custom application, designed and built by me, and owned outright by them. Source, brand, and every dollar it earns. No license, no equity, no revenue share, and it never enters the library. I take two a month, first come first serve.

It is $399 a month, billed annually, $4,788 charged today for a full year. Existing Reinventing.AI Hub members are grandfathered at their current rates.

If you want a large audience watching someone build, this is the wrong room. If you want a small group shipping real software to paying clients, come in.

Whether or not any of that is for you, I would take the four lessons above seriously, because the threshold has already been crossed and the businesses have not noticed yet. That gap is the opportunity, and it does not stay open forever.

Tell me what you would build if someone handed you a free build slot and a resale license. I read everything here. I also run a free community for people building this way, the Facebook group at facebook.com/groups/vibecodinglife and Skool at skool.com/vibe-coding-is-life. Come argue with me about any of it.

My free tool out-impressed 29 of my 32 blog posts. Its ranking got five times worse.

Mark Fulton — Fri, 21 Aug 2026 06:31:59 +0000

Two numbers off my Search Console this morning, same 28 day window, same site.

The free landing page roast tool: 42 impressions, average position 38.0.

The blog post I wrote to support that tool: 11 impressions, average position 21.1.

Six weeks earlier it was the other way round. On July 4 the tool sat at position 7.5 on 18 impressions and the article was at 17.8 on 38. So the tool has more than doubled its reach since then, and its average position has gotten roughly five times worse over the same stretch.

Both of those things are true at once, and working out why changed how I plan the next tool.

The tool

favors.dev/roast takes a URL and gives back a conversion score out of 100.

It screenshots your full public page, then grades the copy and the design together across six categories: clarity, value proposition, trust, CTA, visual design and SEO. You get back the specific issues hurting signups with a fix for each, the things the page already does well, and a one line verdict.

No signup, no credit card, no email field. Paste a URL, press "Roast it", read the result.

It is deliberately small, and the scoping is most of why it shipped. The cut list was: accounts and password resets, saved history, dashboards, billing and usage limits, settings and themes, support for every edge case, and an admin panel for myself. Every one of those is how a weekend build turns into a month. If a free tool needs a billing system, you have started building a second product by accident.

What those numbers actually say

Here is the honest read, because "my free tool beat 29 of my 32 blog posts" is technically true and a bit misleading.

Reading	Tool impressions	Tool position	Article impressions	Article position
Jul 4	18	7.5	38	17.8
Jul 11	20	7.1	42	16.9
Jul 19	22	10.4	39	19.1
Aug 15	42	38.0	11	21.1

Impressions climbed because the tool started matching a much wider spread of queries. Average position fell for exactly the same reason. It is not ranking better. It is ranking on more things, most of them further down the page. A URL sitting at 7.5 on one tight query and a URL sitting at 38.0 across a lot of loose ones are different animals, and only one of them is growing.

The second honest thing: these are small numbers. 42 impressions is 42 impressions. Favors.dev is an early site and I am not going to dress this up as traction.

What makes it worth writing down is the ratio, not the size. That tool out-impressed 29 of the 32 blog posts on the site that ranked at all. It took a weekend. The posts take a morning each, and there are 32 of them.

The mechanism is intent matching, not some special treatment for tools. Somebody typing a query that ends in a verb wants to do the thing. A page where they can do the thing satisfies that better than a page describing how it is done.

The bridge, which is where free tools usually get ruined

The common failure is gating the result. You build something good, it starts working, and then you put the score behind an email field. That turns interest into a bounce at the exact moment the visitor is most engaged, and it kills the sharing that made the tool worth building in the first place.

Mine works in two moves. The roast is free, instant and complete: the score and the reasoning, no account. What an account adds is a step by step fix plan generated from that specific roast. That is a different artifact, not the same one held hostage. By the time somebody sees that offer they have already read a real critique of their own page, so they are deciding whether the next thing is worth an email, not whether I am worth trusting at all.

Three rules I would keep whatever you build. The next step should follow from the result the visitor just saw, so it reads as a continuation instead of a toll booth. It should be one option, not a menu. And it should be worth more than the free thing, or people will correctly ignore it.

What the tool is actually marketing

Favors.dev is a marketing co-op for founders who ship.

Founders complete small verified marketing tasks for each other and earn points to spend on their own launch. Actions run from +2 points for favoriting a launch up to +2,500 for a featured article, across 14 tracked action types. The work gets verified before points release, and 25% of every request is burned so points stay scarce. You cannot buy points. You can only earn them.

New members land with 250 points and can start clearing the queue straight away, without adding a project of their own first. Most tasks take between 2 and 10 minutes. When you are ready to launch you post a rally, which is a bundled request for testimonials, feedback and shares. Six rallies are live on it right now.

Trade favors, earn points, launch faster. The roast tool exists because the founder who wants an honest read on their landing page is the same founder who needs help launching it.

The rest of today

Everything below ran unattended while I was doing other things. Times are Bangkok.

08:31 PounceDomains published "Atom.com Appraisal Alternative: Score vs. Buying Loop".
08:55 Favors.dev published the full teardown this post is drawn from, at 743 lines of TSX in one commit.
11:12 The DomainNetwork monorepo published 10 posts across 10 live sites in a single commit: 30 files, 1,308 insertions. print-excel-on-one-page on supersheet.app, best-day-to-launch-on-product-hunt on trymy.app, h264-vs-h265 on vidclip.app, invoice-without-a-company on billable.dev, harvey-ai-alternatives on legalizeai.com, job-costing-for-small-contractors on smbdashboard.com, how-to-get-to-80-wpm on typetimer.com, questions-to-ask-grandparents on questioncard.com, time-blocking-your-day on smartclock.app, and 144-languages-claim-explained on aiearbuds.com.
12:05 Reinventing.AI published its weekday post.

Ten of those eleven posts are articles. Exactly one of them is a tool. Based on the table above, I have the ratio backwards, and that is the thing I am fixing next.

One ask

Go roast a page you own and tell me whether the score is wrong. Not whether you liked it, whether it is wrong. The rubric is only as good as the arguments people bring against it, and a bad score I can defend is more useful to me than a good one nobody checked.

If you are building in public and want somewhere to do it, I run Vibe Coding is Life: a Facebook group for the daily stuff, and a Skool community for people who want the builds broken down properly. Both are full of founders shipping small things on weekends, which is the entire premise of this post.