Most advice regarding coding with AI optimizes for the first demo.
Write clearer prompts. Generate more code. Iterate fast. Those tips now feel like bottom-of-the-barrel advice.
The tips that have produced features I can still open and trust weeks later do the opposite: they constrain the agent earlier, force smaller outputs, and treat the natural-language instructions as part of the codebase.
These are the ones that have held up for me:
1. Write the constraints before you generate anything
Opening the agent and describing the feature feels productive. Sessions that need less cleanup start with a short Markdown file the agent reads on every run.
A usable spec answers four questions and stays under a few hundred words:
Goal: Every Monday at 9:00, post a diff of three competitor pricing pages to #competitive.
Inputs:
- Firecrawl results for the exact URLs listed in urls.txt
- Previous run stored in Supabase table `competitor_snapshots`
Constraints:
- Only those three URLs
- No price inference or external search
- Slack message ≤ 800 characters
- If scrape returns empty or errors, post the error and stop (max 1 retry)
Done when:
- Message appears in the channel
- Snapshot row is written with timestamp and raw markdown
Because the file lives in the repo, later sessions and scheduled agents inherit the same boundaries. When the agent suggests adding a dashboard or scraping extra pages, the constraint is already explicit. Updating the spec is usually faster than editing generated code that drifted.
2. Build the thinnest version that can run end-to-end once
Agents expand scope by default. The practical counter is to make the first version satisfy the spec and nothing else, then run it yourself.
For the competitor brief, that means: one script or agent turn that fetches the three URLs, diffs against the last Supabase row, formats a message, and posts it. No auth, no history UI, no email. Once that path has executed under supervision and the Slack message matches the spec, the feature has proven it can exist. Additional surface area is added only after that proof.
In Friday Code, this usually looks like pointing the agent at the spec file plus the existing project folder, letting it use the already-connected Supabase and Slack MCPs, then opening the resulting files in your normal editor to run and verify. The code is not trapped in the chat.
3. Treat the first working output as disposable scaffolding
The moment something runs, the instinct is to keep it. A more reliable pattern is to treat the first successful generation as proof-of-concept scaffolding that you are free to delete.
Because the project is a normal local folder (exportable, git-trackable), you can discard half the generated files if a simpler approach appears. I have repeatedly replaced multi-file agent output with a shorter script once the data flow was clear. The time saved comes from not defending the structure the agent invented before the constraints were tight.
4. Put explicit failure behavior in the spec
Happy-path prompts are cheap. Silent failures are expensive, especially once a job is scheduled.
Add the failure cases while the feature is still manual:
- Empty scrape → post “No data from [urls]” and exit
- Rate-limit or 5xx → log to Supabase
agent_runstable, retry once, then alert - Message length > 800 → truncate with “…” and note the truncation
- Missing previous snapshot → treat as first run and say so
These lines feel pessimistic. They also become the instructions the scheduled agent follows. When a site structure changes, the failure is visible in Slack or the log table instead of disappearing. The fix is usually a one-line spec or prompt update plus a small code adjustment, committed together.
5. Schedule only the slice that has already succeeded manually
Scheduling an ambitious agent the moment the demo looks good is how you get jobs that drift or fail quietly. The sequence that lasts is:
- Run the narrow job manually at least twice while watching the real output (Slack message, GitHub issue, Supabase row).
- Confirm it matches the spec, including the failure path.
- Create a scheduled agent whose only responsibility is to re-execute that same verified logic on the cadence you want.
The scheduled agent does not receive permission to invent new features. Its prompt references the same spec file and the same constraints. In Friday Code this is a second, purpose-built agent that calls the existing code or prompts rather than a single ever-growing conversation. When credentials expire or a page layout shifts, the blast radius stays small.
6. Keep the spec, agent instructions, and code in one repository
Chat transcripts are not a source of truth. Model updates and new sessions discard context. The features that still run months later store three things side-by-side:
-
SPEC.md(the constraints and done criteria) - The implementation (scripts, Supabase migrations, prompt fragments)
- The scheduled-agent instructions (or a
schedule.mdthat the agent reads)
A change to a competitor’s markup updates the scraper, the spec’s expected selectors or parsing notes, and the failure message in one commit. A channel rename is a one-line edit visible in git history. This is ordinary software hygiene applied to agent-built work. It is also what makes the feature maintainable by someone who was not in the original chat—including future you.
Why these reduce support load and improve the product
Each tip lowers the chance that a user builds something that works once in a demo and then breaks or requires constant re-prompting. That directly affects the friction points that show up in community conversations: “it worked yesterday,” “the agent added things I didn’t ask for,” “I can’t find the code,” “the scheduled job stopped, and I don’t know why.”
Writing constraints first and keeping them next to the code makes those failures legible. Scheduling only verified slices makes ownership obvious. Treating early output as disposable encourages the export-and-edit path instead of prompt dependency. These are the patterns worth reinforcing in docs, examples, and office hours because they produce features people can actually keep.
The tools will keep changing. The habits that have produced agent-built features still running without daily prompting have stayed consistent: constrain early, ship thin and owned, make failure explicit, and only then let the repeating part run unattended.
Top comments (0)