ultracode became a verb

I noticed it in my fingers

A month ago I wrote “use ultracode and workflows to investigate this”. Today I just write “ultracode an analysis”.

Same tool. Same max effort, same multi-agent Workflows. But the word has moved in the sentence — from something I describe to something I do.

I have used ultracode deliberately since the day it shipped. The new thing is not that I use it. The new thing is that it has become a verb I type without thinking. “ultracode this”. Like “grep”, “dockerize”, “deploy”, “refactor”.

That made me go back and count.

Not because 38 prompts is lab-coat statistics. But because language exposes habits before the calendar does.

What ultracode is

I first wrote about it in One prompt, a whole team, where I tested ultracode on a 404 page and watched Claude Code behave more like a small team than a single assistant.

Short version: ultracode is my name for Claude Code at max effort combined with multi-agent Workflow mode. In other words: xhigh effort plus dynamic orchestration of multiple agents that can investigate, build, compare, and synthesize in parallel.

It started as a setting.

Technically, it is still a setting.

But that is no longer how I use the word.

I dug through the log

All my prompts are logged locally in pks brain. It is not a clean dataset. It is raw developer life: commands, interrupted thoughts, repetitions, streaming duplicates, long continuation summaries, and the prompts I actually typed myself.

Between May 29 and June 26, 2026, ultracode appears in 163 prompts.

After cleanup, 38 of them were real, self-typed asks. The rest was noise from streaming, continuation summaries, and logging mechanics.

Those 163 occurrences were spread across 54 different sessions.

I used ultracode on 24 of the roughly 28 days in the period.

And it was not one project. It was spread across 20+ subprojects in the same repo: kitchen, dronepoul, agent-share, kreds1-talk, www-site, pks-cli, linkedin, and several others.

The interesting part is not only how often. It is how broadly.

Research still dominates.

That makes sense. Multi-agent Workflows are strong when there are multiple sources, multiple interpretations, and a need to distill. It is cheaper to send five agents out to read broadly than to open 27 tabs yourself and pretend you still have the whole picture in your head.

But the table shows something else too: ultracode has started leaking into ordinary product work.

UI. Documentation. Releases. PRDs. Refactors. E2E verification.

Not just “find something for me”.

Also: “take responsibility for a piece of work”.

From setting to verb

I also classified the form of the word itself. Not just what the task was, but how I used the word.

Across the 38 self-typed asks, ultracode was:

This is where it changes.

At first, the word is the subject. I talk about the tool. I ask the system to use ultracode. I describe the mechanics.

Later, the word becomes an action.

The shortest form is also the most revealing.

That is not pretty English. It is not a polished prompt. That is exactly why it is interesting.

I am not explaining to the model what ultracode is. I am using it as a verb and expecting the context to carry the rest.

The same thing happens here:

This does not look like an “AI prompt”. It looks like a message to a colleague while I am already moving on to the next thing.

There are typos. There is Danish developer brain mixed with English project jargon. There is no systematic prompt engineering.

Just: ultracode a review.

That is the kind of linguistic mutation I pay attention to. Not because it is clever. Because it is real.

When a tool becomes a verb in your own language, it is no longer something you consciously choose every time. It has become a motor shortcut.

It is not just research

The easy story would be that ultracode is my research button.

That is partly true. 14 of the 38 asks are research.

But it is not the whole picture.

One of the more interesting categories is gap analysis. Not “what is the best solution?”, but “where is our actual practice inconsistent with what we think we do?”

Here is one of the most meta prompts:

This is not about code in the narrow sense.

It is about release flow, documentation ownership, and whether the truth lives in the product repo or on the website.

This is the kind of work that often falls between the cracks. Too technical to be pure project management. Too organizational to be pure implementation. Too boring for anyone to voluntarily sit down and map the whole chain.

That is a good place to use multiple agents.

Another prompt shows something even more important: trust.

This is the tail of a longer prompt. Not the beginning. It is the closing instruction, where I am not just asking for code, but for proof.

“Ultracode this until you can prove it work”.

It is ugly. But the intent is exact.

Not: “make a suggestion”.

Not: “write a plan”.

Not even just: “implement it”.

But: work through the problem, build it, run the test, document the proof with screenshots at key points in the flow.

That is a different contract.

I am not asking the model to be creative. I am asking it to reduce uncertainty.

And yes, the research form is still there. It is probably the most classic version:

This is the old form: “Use ultracode to research…”

The tool is named explicitly. The task is broad. There is a decision space: buy a certificate, find the cheapest route, investigate whether we can build something ourselves.

An obvious ultracode task.

But the difference is that I no longer use ultracode only for the obvious tasks.

I also use it for small reviews. For documentation questions. For graphs. For comparing release practices. For a UI direction. For pushing a feature all the way to E2E proof.

I have slowly stopped distinguishing between “big task” and “small task”.

Not because everything deserves five agents.

But because the friction of starting them has dropped enough that the question has changed.

Before: “Is this task big enough for ultracode?”

Now: “Is there anything here that gets better with parallel investigation, critique, or verification?”

That is a more useful question.

The cadence was not a clean curve

I would like to be able to write that usage rose smoothly week by week.

It did not.

That is not a growth chart.

It is a learning wave.

The week of June 2–8 was the big exploration. That was where I tested the boundaries. What happens if I put multiple agents on research? On design? On a sales landing page? On documentation? On a product question?

Then usage dropped.

That matters too.

When something new works, I often overuse it for a few days. Not because it is rational. Because I am building a model of where it fits.

After the first wave, a more normal rhythm appeared. 3 asks the following week. Then 9 in the longer final period.

It is not “more every day”.

The more honest version is: ultracode is now fixed in the toolbox.

Not as the hammer for everything.

But as the thing I reach for when the task has more blind spots than one conversation can carry.

The most meta part of the count

There is a small irony in the method.

I did not count all of this by hand.

I dug through pks brain and let the analysis itself run as an ultracode Workflow: 5 agents classifying all prompts, removing log noise, and synthesizing the patterns.

A post about Workflow, researched with a Workflow.

That is both practical and a little revealing.

Because it was not only the result that showed the habit. It was also the process. I had a messy dataset with duplicates and fuzzy boundaries. My first impulse was not to open a spreadsheet and stare at it alone.

My first impulse was: ultracode it.

That is probably the best definition I have right now.

Ultracode is no longer just xhigh + dynamic workflow orchestration.

ultracode became a verb in my own working language.

And when a tool becomes a verb, it has stopped being only a tool you choose.

It has become a default way to think about work.

Part of #100DaysToOffload — documenting agentic development in 2026