pre.dev

Overview

pre.dev develops a coding-agent product and supplies verified tasks for model post-training. Its public website presents an agent aimed at extended software work, alongside a research offering labeled RL Tasks. The site also includes benchmark research and browser-agent work.

The coding product emphasizes planning, continuity across sessions, and sustained execution. The training-supply offering concerns software-engineering tasks whose outcomes can be checked. These are related activities, but a subscription to the coding product should not be assumed to include access to a training dataset or commercial rights to its task collection.

For this directory, pre.dev is most relevant as a source of coding tasks and evaluation material. Its own agent work can provide context for the problems it studies, while published performance claims need to be assessed under the conditions of each comparison.

Why verified coding tasks matter

Our assessment is that post-training benefits from problems that represent a real capability gap and have a trustworthy outcome check. In an illustrative development task, an agent could be asked to extend an application while preserving existing behavior. A successful result should include a working feature and evidence that related workflows still function.

Verification must go beyond accepting a plausible patch. A narrow grader can overlook missing requirements or reward changes that bypass the intended problem. Longer tasks also need sufficient time and context to be solvable, otherwise a low pass rate may reflect an unsuitable setup rather than meaningful difficulty.

Evaluating fit

Ask for a representative RL task with the initial project, instructions, dependencies, and grading logic. Inspect how the task was sourced and whether the reference outcome is achievable under the stated budget. Compare training results on unfamiliar projects, keeping public benchmark material separate from purchased examples. For a combined agent-and-data engagement, make the product boundaries explicit: software access, task licensing, hosting, and support can have different terms. A pilot should report which engineering failures improve and which remain unresolved. The most useful evidence is better completion of realistic work, supported by reproducible checks and a clear account of the data used to produce the improvement.