Inspiration

Many AI benchmarks evaluate models on fixed tasks that are far removed from the people who will actually use their outputs. A higher score does not always tell us whether a result is useful, moving, or worth choosing in everyday life. This leaves us with a strange tension: people fear losing their value to AI, while AI developers still struggle to define what meaningful improvement should look like.

Human Worth begins with a simple question: why not put that judgment in the hands of real users? Human beings will always have needs, preferences, and experiences. For technology meant to serve people, what people value should help define what better means.

We want to make room for both discoveries: where human contributions remain irreplaceable, and where AI still has room to improve. Underneath the platform is a deeper belief: value exists because people exist to experience and care about things. A person's judgment is itself an expression of their worth.

What it does

Human Worth brings human and AI work together around the same concrete task. Users can submit tasks with human and AI contributions, share text or files, and add further attempts to existing tasks. Readers compare the approved works, choose the one they prefer, and explain their reasons in comments.

The question can be practical or personal: which solution works better, which explanation is clearer, or which piece of writing feels more thoughtful? Keeping the task the same gives those differences a shared context. New contributions can extend the comparison as people's expectations and AI capabilities change.

These judgments are also the foundation of our Agent Challenge design. We aim to turn human preferences into useful feedback for future AI attempts, while keeping the final judgment with people. The platform's purpose is to help users discover what they value, recognize the human qualities they care about, and show AI developers where improvement would actually matter.

How we built it

We crafted the visual design by hand, choosing the typography, spacing, colors, and page layouts ourselves. The paper-and-ink aesthetic gives the site warmth and space for careful reading. We wanted the experience of comparing works to feel considered and human. React and Vite bring that visual design into an interactive frontend.

To prepare for many users submitting work and voting at once, we learned and implemented a distributed backend using Go, gRPC, PostgreSQL, Docker, and Kubernetes. Separate services handle identity, content, files, voting, moderation, discovery, and challenges. Transactions, database constraints, idempotent requests, and recoverable background work help preserve consistent votes and submissions across retries and service failures. Large-scale capacity testing remains future work.

The central technical idea is the Agent Challenge pipeline, with three roles: a Ranker (R), a Packer (P), and an Executor (E).

Learn how to judge first. The Ranker develops evaluation criteria from authorized human preference data. The system checks its judgments against separate, held-out human preferences. It can move forward only when the configured agreement threshold is met; the model cannot declare itself qualified.
Fix the criteria, then improve the attempt. Once the Ranker qualifies, its criteria are frozen. The Packer improves the execution instructions, and the Executor completes the task and produces actual deliverables in an isolated gVisor environment. The fixed Ranker evaluates the resulting work and provides feedback for the next attempt. This improves prompts and task-solving methods without changing the underlying model weights.
Preserve the meaning of the comparison. The original task requirements remain fixed. The Packer and Executor cannot read competing works or user comments, and their feedback is restricted to permitted information about their own attempt. Generated works go through moderation before joining the public comparison, where people can judge them again.

An administrator controls challenge runs, with execution limits, cancellation, and recovery built into the backend. The guiding idea is to establish a judge that understands human preferences before using its feedback to improve how an agent completes a task.

Challenges we ran into

The hardest design problem was connecting subjective preference to an automated improvement process. If the judge and the generation strategy both change at once, a higher score may simply reflect a moving standard. Calibrating the Ranker first and freezing it gives later attempts a consistent reference. Separating roles and validation data also helps limit answer leakage and circular evaluation.

The engineering challenge was making the process survive ordinary failures: simultaneous voting requests, interrupted uploads, duplicate retries, unavailable services, and incomplete agent runs. We worked through consistency, permissions, recovery, and isolated execution so that a task could finish with a real file or work to review.

Accomplishments we're proud of

We brought a philosophical question into a working product with a hand-crafted visual identity, a deployed frontend, and a distributed backend. We also completed real model-driven task execution that produced deliverable files and exercised the registration and review workflow. That gives us a working foundation for testing the human feedback loop with a community.

What we learned

Building Human Worth changed how we think about evaluation. People can care about correctness, clarity, originality, warmth, and context in different ways. Their reasons matter alongside their votes.

We also learned that respecting human judgment has engineering consequences: feedback needs clear permissions, reliable storage, and protection from accidental leakage. Distributed systems and agent orchestration became practical ways to support the values behind the project.

What's next

Our next step is to invite users to contribute real tasks, works, and judgments, then measure whether the challenge process produces improvements they actually prefer. We will complete the administration and challenge-management experience, expand the range of supported tasks, and test the system under heavier concurrent use.

The question we want to keep asking is simple: for this task, what do people value, and what can we learn from their choice?