Most AI coding sessions end the same way. You describe what you want, the agent generates a fair amount of working code, and for a few hours it feels like you’ve solved the problem. Then you close the laptop…
The next day, the feature still needs you to open the chat, paste context, and tell it what to do next. The code exists, but it doesn’t run on its own.
After building and shipping several small products, the pattern that actually stuck was different. The features that kept being useful were the ones I treated as three separate jobs: write a clear spec, ship a thin working version you own, and then deliberately turn the recurring part into something that runs without you.
The tools matter less than the order you do those jobs in. Here’s how you build features that work without you.
Start with a task you already do
The features that stalled all began as “it would be valuable if the app could…” The ones that kept running started with a task someone (usually me) was already doing by hand.
Write down the actual job first:
- Who does it?
- How often does it happen?
- What do they currently do?
- Which part is annoying enough that they sometimes skip it?
Then define the smallest end-to-end version that would remove the annoyance. Everything else is out of scope until that version has run on its own at least once.
This sounds obvious. In practice, it is the step most people skip because describing a full feature feels more productive than deciding what the feature should refuse to do.
A competitive brief that only summarizes three specific pages and posts to one Slack channel is more likely to keep running than a “full competitive intelligence system.”
A support triage flow that only classifies messages and creates GitHub issues for the ones that match two patterns is more likely to keep running than an agent that tries to draft perfect replies.
Write the spec before you open the agent
Once the job is clear, write a short specification. Not a product requirements document. A few hundred words that answer four questions:
- What outcome should be true when this finishes?
- What inputs does it need, and where do they come from?
- What must it never do?
- How will you know it worked?
I keep these in a plain Markdown file in the project. The agent can read it. I can edit it. Later sessions start from the same file instead of from my memory of the last chat.
When something goes wrong, the first fix is usually to the spec, not to the code.
A usable spec for a weekly competitive brief looks roughly like this:
This is short enough that you will actually write it. It is specific enough that the agent has less room to invent a different product.
Ship a version you can open in your own editor
With the spec written, use the agent to build the thinnest version that satisfies it.
In Friday Code, this usually means pointing it at the spec file and asking it to implement the feature with the integrations you already have connected (Supabase for anything that needs to remember state, Vercel for the deploy, Slack or GitHub for the output). For reference, here are some integrations that come built-in with Friday Code:
The important part is that the result lives in a real project folder on your machine. You can open it in your normal editor, run the tests yourself, and export or push the code whenever you want.
If the agent suggests adding a user dashboard, email digests, and three extra integrations, you can reject those changes because they are not in the spec. The code is not locked inside the chat.
I treat the first working version as disposable scaffolding. It has to run end-to-end once, under my supervision, and produce the outcome the spec described. After that, I can delete half of it if a simpler approach appears.
The goal is not elegant code.
The goal is a feature that has already done the job once without me typing the next prompt.
Turn the recurring part into a scheduled agent
This is the step that separates “I generated some code” from “the feature runs autonomously.”
Most useful work isn't a one-time build. It is the same small job repeating: check the pages, compare them to last time, and post the summary; or read new messages, classify them, and open the issues.
Friday Code’s scheduled agents are built for this. Once the feature works manually, you create a second agent whose only job is to run the existing code or prompts on a schedule.
You give it the same constraints from the spec, tell it where to put the output, and set the cadence. Then you close the laptop.
The first few runs will still need attention. The agent might miss a formatting detail or hit a rate limit. You fix those in the scheduled agent’s instructions or in the underlying code, then let it run again.
After a handful of cycles, the failure rate drops and the feature becomes something you check rather than something you operate.
I have found that scheduled agents stay reliable longer when their job is narrow.
“Summarize these three pages and post the diff” survives more model updates and website changes than “monitor the competitive landscape and alert me to anything important.”
Check the output yourself before you trust the schedule
Before you leave a feature running unattended, run it a few times while you are still watching. Compare the output to what the spec said should happen.
Look at the actual Slack message or GitHub issue, not just the agent’s summary of what it did.
This is the same habit that mattered when I was turning ideas into products: check the flow yourself before you show it to anyone else. With autonomous features, the “anyone else” is future-you who is not in the chat.
If the message is too long, the classification is wrong, or the agent quietly skipped a constraint, you will only notice after it has already run a dozen times.
A short checklist helps:
- Did it use only the inputs listed in the spec?
- Did it stay inside the constraints?
- Is the output in the exact place and format you expected?
- What happens if one of the external services is down?
Fix anything that fails while you are still in the session. Then schedule it.
Keep the spec and the schedule in the same place as the code
The features that kept working months later were the ones where the specification, the scheduled agent instructions, and the code all lived in the same repository.
When a competitor changed their page structure, I updated the spec and the agent prompt in the same commit that adjusted the scraper. When I needed to change the Slack channel, the change was visible next to the rest of the project.
This is ordinary software practice applied to agent-built features. The difference is that the “code” now includes the natural-language instructions the scheduled agent follows.
Treating those instructions as part of the project, instead of as chat history, is what lets the feature survive across sessions, model changes, and time.
What this looks like in practice
One feature I still use started as a manual habit: every Monday I would open three competitor sites, note anything that looked different, and paste a summary into Slack.
After writing the four-line spec above, I had Friday Code build a small script that used Firecrawl on those exact URLs, compared the results to a previous run stored in Supabase, and formatted a message.
I ran it myself twice, fixed the formatting, then turned the same logic into a scheduled agent that posts at 9 am.
The scheduled version has missed a couple of runs when a site blocked the scraper. Each time, the fix was a small change to the agent’s instructions or a fallback in the code.
The feature has otherwise continued without me opening the project. The time I spend on it now is occasional maintenance, not the original weekly task.
The same shape works for other recurring jobs:
- Triaging a Slack channel into GitHub issues
- Generating a short internal changelog from merged pull requests
- Checking that a set of pages still return the expected status
The common pieces are a narrow spec, a version you can open and edit yourself, and a scheduled agent that only does the repeating part.
Handle failures before they become silent
Autonomous features fail. Sites change their markup, rate limits hit, credentials expire, and the scheduled agent returns something that no longer matches the spec.
The difference between a feature that keeps running and one that quietly stops is how early and how visibly those failures surface.
Here’s a useful diagram:
Before you leave a feature unattended, decide what “failed” looks like and where you’ll see it. In practice, this usually means one of three things:
- The agent posts a short failure message to the same Slack channel (or creates a GitHub issue) instead of staying silent.
- It writes a log or status row you can check.
- It stops and waits rather than guessing.
Keep the failure path as narrow as the happy path.
“If the scraper returns nothing, post ‘No data from the three URLs’ and stop” is more useful than an agent that tries to improvise.
Update the spec with the failure case so later sessions inherit the same rule.
The first few scheduled runs will still surface problems. Treat those as expected. Fix the instruction or the code, then let it run again.
Features that survive months are usually the ones whose failures were made obvious early, not the ones that never failed.
The parts that still need you
Autonomous features do not remove judgment. You still decide which job is worth automating, what “done” means, and when the output is no longer useful enough to keep running.
You still review the first several runs. You still own the code and the instructions, which means you can turn the schedule off or change the constraints when the world shifts.
This approach means you don’t have to be in the chat every time the job runs. For tasks that are frequent, well-defined, and already annoying, that difference is large.
Tools change. The sequence that lasts does not: start with a real task, write the constraints first, ship something you own, then schedule the part that repeats.
Features that still run months later followed this order.
Top comments (0)