Pulse has no editorial team. It has no ops team, no researcher, no one on call to fix a bad summary at 6am. It has me, and a scheduled AI routine that does the actual daily work. Building it changed how I think about the "AI will take your job" conversation I keep having with founders and with people about to enter the workforce — because I just spent weeks on the other side of that question, deciding exactly what to hand off and what not to.
The job I didn't hand off
It would have been easy to build Pulse as "AI writes everything, I approve nothing." I didn't, and the reason is the same reason I wouldn't hire a junior researcher and never read their work: trust has to be earned by the output, checked continuously, not assumed because the byline says AI.
What I actually own is the editorial spec — what counts as a good story, how sourcing has to work, why African coverage isn't optional, what "original summary" means versus lightly-reworded plagiarism. That spec is the product. The AI executes it daily; I'm the one who decided what "good" means and who keeps checking that the output still matches it.
That's the distinction I think gets lost in most AI-anxiety conversations: the job at risk was never "have judgment." It's "spend hours doing the mechanical version of applying judgment you've already exercised once." Pulse didn't replace my editorial judgment. It let me exercise it once, as a spec, instead of re-exercising it every single morning by hand.
The part that actually took the time
If you'd asked me before I started, I'd have guessed the hard part was "get an AI to write a news summary." It wasn't. Any reasonably capable model can write a competent 150-word summary of a source it just read.
The hard part was everything around that: deciding a story counted as worth covering at all, building a rule that guaranteed African coverage instead of hoping it showed up, deciding what "original" meant precisely enough to enforce it, figuring out how to dedupe against yesterday's run, deciding when a story goes stale and should be deleted rather than left to rot. None of that is a writing problem. It's a judgment problem, encoded into rules precise enough that an autonomous process can follow them unsupervised, every day, without me in the loop.
That's the actual skill this project sharpened, and it's the one I think is going to matter most going forward: not "can you get AI to produce output" — everyone can now — but "can you specify, precisely enough, what good output even means, for a process you won't be watching."
Why this isn't a story about replacing writers
I want to be direct about something, because I talk to a lot of founders and a lot of people early in their careers who are anxious about exactly this: Pulse is not evidence that AI writes better than a person, and it's not a case for laying off a research team. It's evidence of something narrower and, I think, more useful — that a well-specified, well-bounded, repetitive research task can run unattended, at a quality bar I'm willing to build my own work on top of, if someone puts in the real work of specifying it properly first.
The people who lose ground here aren't "writers" as a category. It's whoever keeps doing the mechanical version of a task they've already mastered, by hand, when the actual valuable part of their skill — the judgment about what's good — could be turned into a spec that runs itself. The people who gain ground are the ones who go do that specification work, then spend the freed-up hours on the thing that still needs a person: in my case, actually writing the blog, not researching for it.
What I'd tell someone about to try this
If you're a founder wondering whether a task in your business is a candidate for this treatment, the test I'd actually use isn't "is it repetitive." Plenty of repetitive tasks aren't ready — they still need a human making judgment calls that haven't been written down anywhere. The test is: can you write down, precisely, what "done well" looks like, to the point where someone else reading your spec cold could tell good output from bad? If you can't yet, that's not an AI problem, that's a "you haven't fully understood your own judgment" problem — and it's worth doing that work regardless of whether AI ever touches the task.
Once you can write that spec, the AI part is genuinely the easy half. Pulse took real engineering — a scheduled pipeline, an authenticated ingest boundary, a data model that enforces the editorial rules structurally instead of hoping they get followed — but the hardest design decisions were made with a pen, thinking through what "good" meant, before a single line of that pipeline got built.
The Takeaway
- The job at risk was never "have judgment." It was doing the mechanical version of judgment you've already exercised, by hand, forever.
- Specify precisely before you automate. If you can't write down what "good" means clearly enough for a stranger to grade against it, that's not ready to hand off yet.
- The engineering is the easy half once the judgment is written down. The hard design decisions happen before any code gets built.
That's the actual lesson. Not "AI writes for me now." It's: the leverage was always in doing the judgment work once, properly, and building something that keeps applying it after I've stopped thinking about it. Pulse is what that looks like when you follow it all the way through.
