AI-NATIVE DEVELOPMENT FRAMEWORK.
We've turned work people used to run by hand into patterns AI can run precisely.
We've turned the marketing and product development work we built up as a development company into AI workflows and skills.
AI does the work; people make the calls. With this system, we run AI development as an organization.
MARKETING WORKFLOW.
We've turned the whole PDCA cycle of running media into AI skills.
We run everything from goal setting to daily reporting, task creation, production and post-launch evaluation as one cycle.
We've turned each step of that cycle into AI skills, and we build and run our own CMS, Autorial, as the platform those skills run on.
AI turns the reports into tickets and works through them. People receive a report of the changes and review it.
Anything especially important, such as articles, is assigned to a person, who gives it full attention and finishes it.
FIG. 01-A
The media operations cycle
Seven steps, run by AI skills and our CMS, Autorial. People make the call on the steps in cyan.
FIG. 01-B
From report to ticket to fix
AI turns reports into tickets and handles them, and people review the change report. Important work such as articles is assigned to a person.
Step by step
01 — GOAL
Set goals
From the business goals, we decide which metrics to track and what the reports look like.
Human decision
02 — REPORT
Report daily
Every day, SEO research and shifts in the numbers are compiled into a report.
03 — TICKET
AI writes tickets
Based on what moved in the report, AI writes the next actions up as tickets.
04 — CREATE
Fix and create
AI works the tickets, producing and reviewing creatives and articles. Important pieces such as articles are assigned to a person.
05 — CHECK
Check the rules
Before anything goes live, we check it against regulations such as the medical advertising guidelines.
06 — PUBLISH
Publish and watch
After publishing, we check how users respond.
07 — CONFIRM
Review and evaluate
A person receives the report of the changes, reviews it, and evaluates the results against the goals.
Human decision
Back to 01 Goal, and the cycle keeps turning
TICKET DRIVEN DEVELOPMENT.
We've built the project manager's job into the workflow.
Ticketing, requirements definition, organizing user stories during implementation. We now run almost everything that used to be the project manager's territory through AI workflows.
At contract development firms, the most labor-intensive job has always been turning requests and designs into tickets and documents. We built that job into the workflow and put an end to tickets being updated while the docs stay out of date.
For the task board, we use Notion, our own board and others, extended to fit each product.
The hardest part was QA on real devices. Behind it sits a knowledge wiki on how to operate each service, defining the site's specifications and how to use it. That is what lets AI actually operate the service and test it.
The other wall was that when QC is left to AI, what was checked, and how, is hard to keep on record. So we built koma, an internal tool that manages the evidence of browser QC. It records every action AI takes in the browser as a screenshot and a check item, one action at a time, so the run can be replayed and shared later. The QC steps are kept as test cases and carry straight over to the next QC.
In client development, this browser QC is the biggest bottleneck. Because tickets and docs, the implementation and the QC evidence are all kept as one continuous record, whoever reviews the work can follow what was checked, and how, frame by frame, and make the call. That is the pattern we hold for AI-driven client development.
This doesn't run on AI performance alone. What holds the workflow up is our know-how, experience and track record in building the pattern and running it, measurably, in everyday work.
FIG. 02-A
How a ticket moves
A single ticket moves across the board, from filing through QA to done.
FIG. 02-B
Branch strategy
Each ticket gets its own working branch. A PR brings it back into the development branch for QA, and merging into the production branch deploys it.
FIG. 02-C
Tickets and docs in sync
When a ticket is updated, the docs are updated with it, and the code is written to follow the docs.
FIG. 02-D
The knowledge wiki behind device QA
Because the site's specifications and how to operate it are defined in a wiki, AI can actually operate the service and test it.
FIG. 02-E
QC evidence, kept in koma
AI's actions are recorded as a screenshot and a check item per action, then replayed and shared. The QC steps carry over to the next QC as test cases.
Step by step
PLAN
01ICEBOXFiledTurn requests into tickets
Every client request and every issue we notice becomes a ticket first. Nothing stays as a conversation or a chat message; it starts with a record.
What happens here
Ticket the request
AI turns requests from meetings and chats into tickets, so there's never a question of who said what.
Set the requirements
We make clear what has to work for the ticket to be done.
Sort out user stories
We write down who uses the feature and why, so the reason for building it stays on the ticket.
- 02TODOReady
Get it ready to start
Large requests are split into workable pieces, and we decide what comes next.
What happens here
Break it down
A ticket that is too large is split into units that are easy to build.
Estimate the work
We estimate the effort and catch gaps against the schedule early.
Set the order
We decide what to start first from business impact and urgency.
BUILD
03IN PROGRESSActiveFix the docs first, then build
Once work starts, the status moves to in progress. The docs are updated first, and the code follows them.
What happens here
Create a branch
Each ticket gets its own working branch so changes never get mixed up.
Update the docs
Spec and design docs are updated first, so tickets and docs never drift apart.
Build it
The code is written to follow the updated docs.
- 04DONEBuilt
Check everything a machine can check
When the build is done, everything that can be checked automatically is checked before review.
What happens here
Code checks
Type checks and lint remove typos and type mismatches.
Build test
We confirm the build passes the same way it will in production.
Open a pull request
The pull request sums up what changed and why.
- 05MERGEDMerged
Put it where you can try it
Reviewed changes are merged into the development branch and shipped to an environment you can actually click through.
What happens here
Review
We check that the change matches the ticket's requirements.
Ship to development
Merging into the development branch updates the development environment.
Preview it
A preview URL shows the screens working just as they will in production.
TEST
06QCQuality checkOperate it for real, and check
The stage that takes the most work and the most know-how. Using our knowledge wiki, AI actually operates the service in real browsers and on real devices to test it.
What happens here
Read the knowledge wiki
AI reads the wiki of site specs, screens and flows, how to operate it and what to test, and decides what to do and how.
Test in the browser
It opens the screens in a real browser and checks the display and each action one by one, recording a screenshot and a check item in koma for every action.
Test on devices
It does the same on real devices such as smartphones.
- 07QC OKVerified
Keep the results, with evidence
Test results go into a QA report. Anything that fails goes back to in progress to be fixed.
What happens here
Write the QA report
A list of what was checked and how it turned out. The QC steps are kept as test cases for the next QC.
Keep the evidence in koma
The screenshot and check item for each action are kept in koma, so anyone can replay and check them later.
Send back NGs
Bugs go back to in progress with steps to reproduce, and are tested again once fixed.
RELEASE
08PM REVIEWPM reviewA person looks, and decides whether it ships
The final call is made by a person, who reviews the report AI filed and decides whether to release.
Human decision
What happens here
Check against the request
Does what was built match the original request and requirements?
Review the report
The QA report is reviewed and the koma evidence replayed, and anything questionable is sent back.
Decide the release
Including timing, a person decides whether it goes out.
- 09DEPLOYDeploy
Ship it, and keep watch
Merging into the production branch deploys it, and we confirm it works in production. From here, operations and monitoring take over.
What happens here
Deploy to production
Merging into the production branch deploys by the same steps every time.
Test in production
We confirm the main actions work in production too.
Start monitoring
Uptime, internal and external monitoring go in, and operations takes over.
Handed off to 03 Operations and monitoring
OPERATE FROM DAY ONE.
Monitoring and operations start the moment we deploy.
The moment a product is deployed to production, we put uptime, internal and external monitoring on it, the same way for every product.
When an alert fires, we respond, and for minor bugs and server-error-level issues we have a system that fixes them automatically.
Routine work such as maintenance, operations, monitoring and development, and everything else a development company does, has been turned into workflows and skills.
FIG. 03-A
Monitoring and auto-fix
Three kinds of monitoring keep watch on production, and minor bugs are fixed automatically.
Step by step
01 — LAUNCH
Go to production
Monitoring is set up with every deploy, the same way every time.
02 — MONITOR
Monitor
Uptime, internal and external monitoring keep checking that nothing has stopped or slowed down.
03 — ALERT
Raise an alert
When something abnormal is detected, an alert goes up and we start responding.
Human decision
04 — AUTO-FIX
Fix automatically
Minor bugs and server-error-level issues are fixed automatically.
Monitoring continues and feeds into the next round of development
WHAT CHANGED
LESS DRIFT. FASTER PAYBACK.
On schedule, at the right cost, with faster payback.
We started out as a development company.
We took work that was costly to run by hand and made it run precisely through workflows.
As a result, we can now propose product development with schedules and budgets that are easy to forecast.
- 01 — ON SCHEDULE
Little drift from the plan
We can now keep schedule delays and slippage from unexpected rework to a minimum.
There is also less gap between what was planned and what gets built. - 02 — RIGHT COST
Costs that fit the product
One trusted director can now run an entire project.
This keeps development costs far lower than running it with a large team, so we can propose plans with a good balance of revenue and cost. - 03 — FASTER PAYBACK
Faster return on investment
The cycle from a decision to the next output is short, so products reach the market sooner.
The sooner they reach the market, the sooner the initial investment pays back, and the easier it is to commit budget.
BUILD IT WITH THIS WORKFLOW.
We'll build the next product with this workflow.
We run both new product launches and the ongoing development of live products on this workflow. It's fine if the requirements aren't settled yet.