I made my dietitian sister a reader that scans PubMed every day, picks the work most likely to matter to her, and rewrites it in language she can comfortably understand.
It did not begin as her product. It began because I wanted the same thing for myself.
I had not read enough arXiv papers to give an AI a respectable list of papers I already knew. I found white papers heavy, boring, and difficult to turn into a habit. I did not want a machine to help me perform being a research person. I wanted it to help me understand one interesting idea today, then make tomorrow slightly easier.
The first version sounded obvious: scan the daily papers, use what the system knows about me, and produce a short personalized edition.
That idea was nearly worthless.
The useful product emerged from everything I complained about after it existed.
The next edition begins by showing what yesterday’s reading changed.
A research paper rewritten in my language
The current reader gives each selected paper the same small structure:
- A human hook
ELI5FoundYouQuestionCaveat
Found says what the researchers actually did and learned. You connects the work to something I already care about, believe, or am building. Question gives me somewhere useful to push. Caveat stops an attractive result becoming a grand claim.
The arXiv edition connects a finding to ideas the reader has already developed.
An edition starts with an overview and a short list of recommendations. When yesterday’s recording produced a real unresolved question, the next edition starts with a verified follow-up.
This is not meant to help me avoid understanding research. “Read arXiv without reading arXiv” would be the wrong goal. The better framing is:
arXiv, rewritten in your language—with a conversation attached.
I want supported, progressive reading. If the system works, the boundary of what I can understand should move over time. The summaries are scaffolding, not the destination.
Codex made it cheap enough to discover the product
I did not begin with a complete specification. I described the reading problem to Codex, argued with what it built, and kept using the result.
Codex turned those reactions into a working system: a daily source sweep, a private reader, a recorder, durable feedback processing, and a next edition that could prove what changed. ChatGPT Sites gave that system a real surface early—a private, signed-in site I could use on my iPad—without making me assemble a conventional web stack first.
That speed changed the product process. I was not reviewing a mock-up and guessing how I might behave. I was reading, getting distracted, navigating away, rambling into the recorder, and checking whether the next edition had listened.
This is the part of ChatGPT Sites I find most exciting. It makes a personal tool real enough to produce honest behaviour before the idea has been polished into a formal product. Codex can then turn that behaviour into code, rules, tests, and another deployed version.
The first version did not need to be right. It needed to become usable quickly enough for reality to correct it.
The first “personalized” edition was mostly AI
The first real run swept 1,475 arXiv announcements. The system had stored my interests in education, language, UX, voice, programming, sensing, and other areas.
It still gave me an AI-heavy edition.
That failure exposed a distinction I now use everywhere:
A preference being stored does not mean it affected the decision.
The profile looked personalized. The output was not.
I made the system rescan the same batch. The replacement edition spread its selections across education, language and cross-linguistic ideas, UX and HCI, programming and testing, and embodied sensing. When it could not find a strong paper for one of my interests, it said so instead of padding the category with a weak match.
That correction became policy. Personalization should not collapse into “more of the topic you mention most.” It should preserve some breadth, distinguish interest in a topic from interest in a particular paper, and spend the most valuable slots on work that might change or extend an existing belief.
An ordinary confirmation can wait in the long tail. A paper that makes me update deserves the card.
Simple prose was not enough
The corrected selection was better, but the writing still felt like a white paper about white papers.
The early cards had headings like “What did the researchers actually learn?” and “Why might this connect to your work?” The information was useful. The scan cost was ridiculous.
I kept cutting:
- Number the papers.
- Give each one a human subtitle.
- Tell me what was tested.
- State the finding as briefly as honesty allows.
- Connect it to my actual projects and beliefs.
- Stop explaining how to skim.
- Stop repeating the date and product name.
The interface eventually compressed itself to labels such as Overview, ELI5, Recommended, Record, and Pending.
That sounds cosmetic. It was actually part of the learning model. An adaptive interface should learn how much explanation its owner needs about the interface itself.
I read once and ramble once
The feedback mechanism had to match how I behave, not how a tidy product manager behaves.
I did not want to annotate every paper. I wanted to open the edition on my iPad, tap Record once, read, speak whenever I had a reaction, tap Finish, and walk away.
One recording can contain several kinds of signal:
- I do not understand this term.
- Is this actor a human, a model, or an evaluation metric?
- This connects to something I am building.
- That does not challenge my belief for the reason you claim.
- This category should be broader.
- Show me more of the long tail.
- Follow up on this tomorrow.
- This explanation is too long.
- The product state is wrong.
That is much richer than thumbs up or thumbs down. The recording teaches the reader what I care about, what I already believe, what I understand, what language works for me, and what kind of evidence changes my mind.
So far the system has recovered and processed four verified arXiv feedback sessions: about 51 minutes of audio across 247 uploaded chunks.
The next edition does not merely say it has “learned my preferences.” It has to show the effect: a changed selection, a better explanation, a stored connection, or a follow-up grounded in something I actually said.
My ordinary mistake designed the recorder
The best product test happened when I stopped behaving like a tester.
I started recording, navigated elsewhere inside the reader, and later saw a page claiming it was not recording. The recorder component had disappeared, but the old browser recorder was still alive and uploading invisible ten-second chunks.
The first recovery attempt missed the session because it searched only for recordings marked waiting. I had never pressed Finish, so the supposedly lost session was still marked recording.
It eventually recovered 172 chunks, 48.6 MB, and roughly 34 minutes of audio.
My perfectly ordinary act of zoning out and navigating away revealed the difference between a demo recorder and one safe enough to become a habit.
The failure forced several permanent changes:
- Recording state persists across internal navigation.
- The interface cannot claim recording stopped while a detached recorder is alive.
- Leaving the whole page triggers a warning.
- Recovery can inspect incomplete sessions, not only cleanly finished ones.
- Finished-but-unprocessed is different from recording now.
- Uploaded chunks are preserved, hashed, verified, and processed repeat-safely.
“Pending” had previously meant several incompatible things. Once those states were named properly—recording, uploading, finished and waiting, transcribed, ingested—the product stopped inventing fake behaviour around an ambiguous word.
The hard part of personalization was state
Many of the most important failures had little to do with model intelligence.
The system nearly republished an identical paper batch because arXiv’s announcement date, mailing date, listing heading, and my Perth delivery date did not line up cleanly. Arguing about dates produced plausible explanations but not a trustworthy answer.
The fix was to stop using dates as identity. A batch is now identified by a deterministic fingerprint of its unique paper IDs. If the fingerprint has not changed, the feed is not fresh.
On another day, the scheduled job ran repeatedly but upstream data arrived after the polling window. Nothing should be manufactured to make the automation look successful.
That became another distinction:
“The job ran” and “a fresh edition exists” are different states.
The same discipline applies at the other end. Processing is not complete because an agent wrote a brief. Completion means the source was fresh, synthesis finished, the site built, the edition deployed, the dated route was verified, and the reading experience actually exists.
Personalization turned out to be a state-management problem before it was a model problem: provenance, freshness, pending states, separate identities, repeat-safe processing, and proof that yesterday’s feedback really reached today.
Then I rebuilt the pattern for my sister
Once the interaction worked for me, I adapted it for Nina.
The reusable part was not “an arXiv summarizer.” It was the contract:
- Sweep a fresh research corpus broadly.
- Select conservatively against one person’s interests and knowledge.
- Rewrite each item into a predictable reading grammar.
- Let the person react naturally in one voice note.
- Turn verified feedback into tomorrow’s selection and explanation.
For a dietitian, arXiv is the wrong source. Nina’s version uses PubMed and prefers direct human evidence, practice relevance, guidelines, systematic reviews, meta-analyses, appropriate clinical trials, and strong observational work when it is the best evidence available.
Her first edition swept 2,159 PubMed records, screened 554 nutrition-adjacent candidates, and selected 12 across seven sampler lanes. It found no strong ADHD-specific paper that day and said so.
The adapted PubMed edition makes the selection funnel visible, then asks the reader to correct it.
The interaction grammar is reused; the evidence policy and personal state are not.
Only the interaction grammar was copied. Her profile, recordings, feedback queue, knowledge state, storage, publishing history, and evidence policy are separate from mine.
Reuse the contract, not the person.
How you could invent your own version
You do not need to begin with embeddings, an agent framework, or a complicated research API.
Start like this:
- Choose the field you want to follow.
- Explain why its current reading experience fails for you.
- Give the system a small seed list of interests and what you already understand.
- Ask for one broad manual edition.
- Correct the selection and presentation aggressively.
- Store those corrections as explicit rules.
- Schedule it only after the manual edition is useful.
- Add one low-friction feedback mechanism.
- Require tomorrow’s edition to show what changed.
- Preserve enough raw input and state to diagnose failure.
Do not treat a shown paper as a learned paper. Do not infer comprehension from a click. Do not let a profile become a decorative document that the ranking step ignores. And do not confuse a completed background job with a finished experience.
The most interesting thing here is not that an AI independently designed the right reader. It did not.
The agent supplied implementation speed. I supplied purpose, taste, contradictions, behavioural reality, and the refusal to accept each locally plausible version as final.
That is also my strongest case for Codex and ChatGPT Sites. Not that they produced the perfect app from one prompt. They made the cost of turning a thought into real, private, usable software low enough that I could teach the product by using it.
I did not program the system line by line. I taught it through use, disagreement, and repeated demands that yesterday’s correction become tomorrow’s default.
The AI supplied the implementation velocity.
I supplied the loss function.