The standard postmortem when automated content underwhelms: fix the prompt, swap the model, add more examples. Every iteration cycle stays inside generation.
That is the wrong layer. The model writes what you feed it. Generic inputs produce generic outputs regardless of which model you run or how carefully you craft the system prompt. The real failure point is upstream, and it usually comes paired with a scheduler that silently refuses to fire.
I hit both this week building original content feeders for my X engine.
The idea input problem
The original setup generated posts from a static topic queue. A list of themes, rotated on a schedule. Serviceable for a day or two, then every post becomes a rephrase of the last. The fix was not prompt tuning. It was wiring two live feeders:
- GitHub trending: repos filtered by language, pulled daily and weekly. Actual shipping projects, not abstract topic strings.
- Niche pulse: recent posts from a curated creator pool the engine already watches.
The part that is not obvious is what you do after ingestion. You have to split incoming items into two generation paths: grounded (the post is factually anchored to the specific feeder item) and ungrounded (the item is a creative trigger, the post can range further). Mixing both into one path produces outputs that hedge between reporting and opinion and do neither cleanly. A post that vaguely gestures at a trending repo without making a real claim about it is worse than a pure opinion post. Pick a lane per item.
The scheduler bug that made all of it moot
With feeders wired, the engine had a daily floor of 3 posts and per slot idempotency so reruns do not post twice. Tested fine manually. Deployed via launchd plist. Nothing fired.
The bug: StartCalendarInterval versus StartInterval. Calendar interval schedules at specific clock times. Start interval fires every N seconds from load. I had used StartCalendarInterval in a plist configuration that launchd accepted silently and honored never. Swapping to StartInterval and checking launchctl list confirmed the job was actually queued.
The failure mode is silence. No crash, no log entry, no indication anything went wrong. The job just does not run. This is the most underdiagnosed class of launchd problem because every debugging instinct points at your code, not at whether the trigger even fired. Verify the scheduler actually runs before debugging anything else.
Singles only, for now
The feeder generates single posts only. Intentional. Threads need atomic commit semantics: either the full thread posts or none of it does. A partial publish leaves a dangling opener, which is worse than no post at all. The daily floor of 3 singles is a safer floor than 1 thread that fails mid chain. Thread support comes later, when the idempotency model can handle it.
What I would have done differently
Start scheduler verification on day one. Write a dummy job that touches a file every few minutes, confirm it fires, then build the real payload on top of it. I lost two days diagnosing generation logic when the scheduler was never executing.
Also: instrument the feeder pipeline separately from generation. If feeders return zero items, the engine should log that and stop, not silently fall through to stale templates. Silent fallback is indistinguishable from working correctly until you go looking.
Top comments (0)