Eieye

Eieye helps people follow artificial-intelligence news and discussion on Hacker News without reading every story, article and comment thread themselves.

The problem

Hacker News is valuable because the linked article is only half the material. The comments add implementation experience, criticism, disagreement and context that may be missing from the original piece. But following that conversation means opening many stories, tracing long threads and remembering how ideas develop across days or weeks.

A conventional news feed could shorten the articles. It would lose the part that made HN useful. A general-purpose chatbot could answer fluently, but without tight evidence controls it could blur article claims, commenter opinion and facts recalled from model training.

The product needed to reduce the reading burden while preserving where each claim came from.

What I built

I designed and built the product end to end. It has three ways into the same growing body of source material:

• a daily Feed of engaged AI stories, with topic filters and short summaries;
• four weekly briefings covering models, agentic use cases, agent harnesses and enterprise AI usage;
• a research Chat that searches across stories, reads promising articles and discussions, and answers with checked source links.

The ingestion system collects stories from the official HN API, preserves complete comment trees and extracts readable text from linked articles. PostgreSQL stores the canonical source record; keyword and vector indexes support discovery. Daily jobs are idempotent, resumable and designed so one bad story does not stop the rest of the run.

Chat uses one bounded research agent with controlled tools for searching the corpus, inspecting a story and inspecting a discussion. The same evidence model supports the weekly report agent. The application is built with TypeScript, Next.js, PostgreSQL, pgvector, Drizzle, the OpenAI Responses API and Agents SDK, with an AWS deployment path using EC2, RDS, Caddy and systemd.

Where reality disagreed

The first temptation was to treat this as a semantic-search problem: embed everything, retrieve the closest passages and ask a model to summarise them. That was not enough.

A comment only makes sense with its ancestry and replies. A broad question may require coverage across several stories and several facets of the topic. Finding a generated summary is useful for discovery, but it is not evidence for an answer. And when an article has an active HN discussion, reading only the article misses half the product’s point.

The hard part was not getting an agent to find plausible text. It was making the path from question to claim inspectable, bounded and faithful to the sources.

How I investigated it

I turned the product requirements into explicit retrieval and evidence rules, then tested the boundaries independently. Fixtures cover article extraction, HN item validation, discussion-tree preservation, hybrid search, research budgets, source coverage, streaming answers and citation resolution. PostgreSQL integration tests exercise the workflows that depend on real database behaviour.

The About page exposes the same architecture to users. It explains how stories qualify, what the system stores, how Chat researches an answer and why comments are treated as first-class evidence.

What changed

The research loop became deliberately constrained. Search results create leads, but the agent must inspect source material before using it. Broad questions are mapped into facets, coverage is tracked across relevant stories, and article inspection is paired with discussion inspection when both exist.

Citations use internal source identifiers returned during the current research run. The server, not the model, resolves those identifiers into links and rejects sources the agent did not actually inspect. Weekly reports use an immutable publication window and the same source-reading tools, so editorial selection remains flexible without weakening the evidence boundary.

The operational design also became simpler. Daily ingestion and weekly reports run as direct, observable commands with a shared database lock, explicit progress records and retryable failures instead of a separate workflow platform.

What I learned

Evidence-based AI products need two architectures at once: one for finding useful material and another for proving what the model was allowed to say. Retrieval quality matters, but source identity, conversational structure, coverage and citation validation determine whether the resulting answer can be trusted.

The most useful constraints were also product decisions. Treating comments as primary content shaped the schema. Requiring article-and-discussion coverage shaped the agent tools. Checking citations shaped the streaming protocol. Making those boundaries visible helped keep the interface simple without hiding how the system reached an answer.