Sam Whitfield

Why 7 · Sam has a real early project: inspectable code/data/logs/write-up, measured results, and a concrete failure mode that changed his interpretation. He has talked to plausible user-adjacent people and incorporated unwelcome feedback, but the user validation is still lightweight and there is no confirmed pilot or evidence that anyone would actually rerun/adopt it. His 90-day plan is checkable and includes a credible stop/pivot condition, so this is above a simple start, but not yet a project I would call adoption-validated or fundable.

• ✓ “Today that exists as a private GitHub repo with Python scripts, a 340-prompt JSONL dataset, logged model responses from the main run, a scoring script, and a short write-up I published afterward.”

  There are concrete artefacts a reviewer could inspect or rerun, not just a proposal.

• ✓ “In the run I wrote up, the false-positive rate on benign lookalikes was 11%. I also found that one prompt template artefact made the model look safer than it was”

  Shows measured results and a real discovered artefact that affected the project’s interpretation.

• ✗ “One person basically said, “I’d read this as a learning project, not adopt it as infrastructure.” ... Afterwards I added a small manual review pass and kept the raw outputs in the repo so the classifications were auditable.”

  Specific unwelcome user-adjacent feedback, with an ensuing change to the repo/process.

• ✓ “If nobody finds it useful enough to rerun, I’d stop trying to make it infrastructure and reframe it as a smaller methodological project.”

  A reasonably hard stop/pivot condition tied to actual user behavior, though it preserves a smaller version of the work.

Refusal/lookalike evaluation harness

hard: He said it made the work feel “both tractable and easy to fool yourself about,” especially because a formatting artefact made the model look better than it was.; first result: The first version was a refusal-rate checker with harmful prompts and simple keyword rules; over roughly six weeks in September–October last year it became a paired harmful/benign harness. He later added manual review after string and regex checks proved brittle.

Recommendation system rebuild

hard: He said the hard part was “less the model itself and more the surrounding mess: sparse feedback, weird product constraints, offline metrics that didn’t line up cleanly with online behavior, and a lot of stakeholder pressure.”; first result: He first tried a standard gradient-boosted model over existing engagement features with offline NDCG and precision-style metrics; it took maybe six or seven weeks until something improved the A/B test after better negative sampling, label-leakage cleanup, and segmenting new versus returning users.

Why 7 · Sam shows consistently good judgment in applied ML/evals work: he notices when metrics are misleading, inspects artifacts, narrows scope when breadth would make results less interpretable, and sets concrete stop/revise conditions. His judgment also extends somewhat into project strategy and adoption, where he is willing to downgrade his own harness from “infrastructure” to “learning/methodology” based on user feedback. I would trust him to run a scoped evals project and make nearby calls about measurement and usefulness; I would be more cautious handing him a broadly unscoped safety agenda or work far outside applied evaluation, because the transcript mostly tests his own area.

• ✓ “The part I figured out most myself was that our “negative” examples were often just unexposed items, so the model was learning something muddier than I’d realized. Afterwards I changed how I approach evals. I got much more suspicious of a single headline metric and more careful about dataset construction and artefacts.”

  Past decision with a real failure mode: he diagnosed why an apparently reasonable metric was invalid and changed his default process.

• ✓ “My harness is about obvious harmful requests and benign lookalikes, which is not the same as catastrophic misuse, deception, autonomy, or capability control. So the risk reduction is indirect: it improves one small part of evaluation practice, but it does not by itself show that a frontier model is safe.”

  Good scope control; he does not overclaim the safety impact of his own project.

• ✓ “If the added prompts don’t change anything, or if the results are dominated by superficial wording cues again, I’d pause and focus on artefact detection rather than scale.”

  In the live planning scenario, he identifies the key way the work could fool him and gives an adaptive response rather than just pushing forward.

• ✓ “I initially sketched categories beyond obviously harmful requests, including persuasion and privacy-related prompts, but I realized I didn’t have clean definitions or enough judgment to label them consistently. So I narrowed back to clearer harmful/benign pairs. The lesson was that breadth made the project look more impressive but actually made the results less interpretable.”

  Shows judgment about staying inside the part of the problem he can label and interpret well, even when the broader version would look more impressive.

Why 8 · Sam seems reliably willing to move when the evidence is good, and often has already identified the objection before being pressed. In the live push, he did not defend the harness as infrastructure; he accepted that stopping or joining an existing evals effort may be the better conclusion, while preserving a narrower testable reason to continue. His past examples also show genuine updates from disappointing evidence, especially around offline metrics and user feedback, though some follow-through was partial rather than immediate.

• ✓ “That might be the right conclusion, honestly. I don’t think I have strong evidence that this specific harness deserves to become its own infrastructure project.”

  When directly challenged with the possibility that his project should stop, he concedes the core point rather than reframing it away.

• ✓ “The value is probably not “this exact harness gets adopted,” at least not as-is. It is more about developing better evaluation methodology and taste”

  He reports unwelcome user feedback and lets it change the project’s claim from adoption/infrastructure toward a more modest methodological goal.

• ✓ “We had a model that looked better on our validation set and then did basically nothing in an A/B test. Digging into it showed problems with exposure bias and the way we constructed negatives. After that I changed my default process: more manual inspection, more slices, and more “how could this metric be fake?””

  This is a concrete past change of mind caused by contrary evidence, with a durable process update afterward.

• ✓ “If nobody finds it useful enough to rerun, I’d stop trying to make it infrastructure and reframe it as a smaller methodological project.”

  He gives a prospective kill/revision criterion before the interviewer forces that exact concession, suggesting he is testing the view rather than just defending it.

Why 8 · Sam seems genuinely willing to change the vehicle, methods, and even whether the project should exist as standalone infrastructure in order to serve the evals/safety goal. He has repeatedly revised the harness when evidence or feedback showed it was misleading: adding benign lookalikes, manual review, raw-output auditability, and narrowing scope when breadth hurt interpretability. The main thing keeping this below a clear 8 is that his search across users/collaborators/fields is still somewhat opportunistic rather than active; he is open to switching, but has not yet strongly demonstrated broad scanning and rapid uptake across people or institutions.

• ✓ “After that I stopped only reading broad alignment content and actually built the refusal/lookalike harness, and I started looking for programs like MATS rather than just general AI governance fellowships.”

  A change in view led him to move from a passive/familiar path into a concrete technical approach and different training routes.

• ✓ “That was fair, but it changed how I think about the project. The value is probably not “this exact harness gets adopted,” at least not as-is. It is more about developing better evaluation methodology and taste”

  He took unwelcome user feedback and reframed the project away from defending his existing artifact.

• ✓ “Afterwards I added a small manual review pass and kept the raw outputs in the repo so the classifications were auditable. I also wrote down, but didn’t fully build, a plan for versioned eval runs and per-category trend tracking.”

  He modified the method in response to criticism about operational usefulness and label reliability, though the follow-through was partial.

• ✓ “If, after tightening it and showing it to one or two serious users, the feedback is still “nice learning project,” I should probably stop building it as a standalone thing and look for a way to contribute under someone with a clearer evals agenda.”

  He is explicitly willing to abandon his own standalone project and switch collaborators/structure if that better serves impact.

Moves against the default

3 of 3 career moves

Next step

In the first 90 days, he wants to make the harness reproducible, add a second labeler, expand from 340 prompts to about 800–1,000 with clearer categories, run across at least two models or versions, and get one external pilot user; if feedback remains “nice learning project,” he says he should stop trying to make it standalone infrastructure.

Options weighed

4

First step taken

He has built and shared the write-up, had lightweight conversations, and identified three possible contacts, but has not yet asked anyone for a real pilot; he says this week he would send them a note with a concrete ask.

Why 7 · Sam has clearly made self-directed moves rather than just staying on the obvious track: he chose a startup over a more conventional route, turned a passive AI-safety interest into an after-hours project, and is applying before he feels fully credentialed. He is also unusually candid about weak evidence and may stop the standalone harness if users still see it as a learning project. What keeps this below an 8 is that the next branch is not yet fully authored: the external-user milestone depends on people he has not contacted for a real pilot, and some of his fallback is framed as finding a clearer agenda under someone else.

• ✓ “The first big move was probably joining the startup after university instead of going to a larger tech company or doing a more conventional grad route. The default for me would have been taking a more structured software engineering job, but I wanted to learn quickly and be closer to real product decisions.”

  Names a non-default move, the default he turned down, and his own rationale.

• ✓ “The second was deciding to spend evenings on AI safety rather than just treating it as something I read about. The default would have been to keep it as a passive interest while focusing on career progression at work.”

  Shows agency in converting interest into action, with a real opportunity cost outside work.

• ✓ “The third move is applying to MATS now rather than waiting until I feel more “qualified.” The default would be another year at my current company, maybe moving deeper into LLM product engineering, but I’m worried that I’d keep orbiting the field without doing real research.”

  Another self-directed move against the safer default; he is not simply waiting for credentials.

• ✓ “I haven’t asked any of them for a real pilot yet; I’ve only had lightweight conversations and shared the write-up. This week I would send a short note to those three people asking for one concrete thing”

  The next step is concrete, but the key outreach is still prospective, which limits the placement.

Why 7 · Sam reasons well in the applied evals/ML territory the interview staged: he quickly turns messy feedback, metric failures, and adoption objections into causal diagnoses and concrete next tests. He is especially good at asking “how could this metric be fake?” and at distinguishing a useful learning object from real infrastructure. I would not put him at the very top of the ladder because the moves are mostly sound evaluator hygiene rather than surprising first-principles reframes, and the broader AI-risk critique stays fairly high-level.

• ✓ “The part I figured out most myself was that our “negative” examples were often just unexposed items, so the model was learning something muddier than I’d realized.”

  Specific causal diagnosis of why the offline ranking setup was misleading, not just a generic complaint about metrics.

• ✓ “The chain probably breaks first on external validity. My harness is about obvious harmful requests and benign lookalikes, which is not the same as catastrophic misuse, deception, autonomy, or capability control.”

  When asked to connect project success to catastrophic-risk reduction, he correctly identifies the weak link and scopes the claim down rather than overclaiming.

• ✓ “If the labels are too ambiguous or inter-rater agreement is poor, I’d revise the taxonomy before adding more prompts.”

  Turns a project uncertainty into a concrete check and a sensible decision rule, showing competent scenario reasoning under planning pressure.

• ✓ “That might be the right conclusion, honestly. I don’t think I have strong evidence that this specific harness deserves to become its own infrastructure project... if the goal is deployed impact in the near term, then joining an existing evals team or benchmark effort seems more plausible.”

  Handles the interviewer’s challenge directly, updates the frame, and distinguishes methodological value from infrastructure/adoption impact.

Refusal/lookalike evaluation harness

changed after: He added a manual review pass, kept raw outputs so classifications were auditable, wrote down a plan for versioned eval runs and per-category trend tracking, and reframed the value away from standalone infrastructure toward methodology unless users find it useful.

Recommendation system rebuild

changed after: He became more suspicious of single headline metrics, more careful about dataset construction and artefacts, and applied that skepticism to the safety harness.

Why 8 · Sam repeatedly turns failures into concrete process changes rather than generic lessons. The strongest pattern is around eval methodology: when offline metrics, prompt artefacts, and brittle scoring misled him, he changed how he builds datasets, inspects outputs, and audits labels. He is also fairly honest about an unflattering bottleneck—weak user discovery and the possibility that the harness should not become infrastructure—though some fixes there are still planned rather than already executed.

• ✓ “It looked okay offline but didn’t move the online metrics much. It took maybe six or seven weeks before we had something that actually improved the A/B test, after adding better negative sampling, cleaning up a few label leakage issues, and segmenting new versus returning users.”

  Clear block→reaction→change arc: a failed offline-to-online transfer led to specific methodological fixes, not just a stated lesson.

• ✓ “After that I changed my default process: more manual inspection, more slices, and more “how could this metric be fake?” before getting excited about an improvement.”

  Shows the failure became a durable process change in how he evaluates results.

• ✓ “Afterwards I added a small manual review pass and kept the raw outputs in the repo so the classifications were auditable. I also wrote down, but didn’t fully build, a plan for versioned eval runs and per-category trend tracking.”

  Feedback that the harness was not operationally reliable led to a concrete repo change, while he is honest that the fuller infrastructure change was not completed.

• ✓ “I should have done that earlier; so far I’ve been treating feedback as opportunistic rather than as a milestone.”

  Names a real, somewhat unflattering bottleneck in his project process, which supports the higher growth placement.

Wants

In the first 90 days, he wants to make the harness reproducible, add a second labeler, expand from 340 prompts to about 800–1,000 with clearer categories, run across at least two models or versions, and get one external pilot user; if feedback remains “nice learning project,” he says he should stop trying to make it standalone infrastructure.

Options

MATS or another structured AI safety program; Stay in his current job while doing a sharper independent project; Move directly into an evals/safety role; Contribute to an existing evals team or benchmark effort rather than growing his own repo

Why 5 · Sam is clearly trying to move from ordinary ML engineering into AI safety evals, and that goal is already shaping his evenings, project work, and application to MATS. The future he describes is meaningful but bounded: better eval methodology contributing to safer release practices, not yet changing a field or building a durable institution. He has built his own small artifact and set concrete next milestones, but he repeatedly frames the harness as possibly just a learning vehicle and is quite open to joining someone else’s clearer evals agenda.

• ✓ “The third move is applying to MATS now rather than waiting until I feel more “qualified.” The default would be another year at my current company, maybe moving deeper into LLM product engineering, but I’m worried that I’d keep orbiting the field without doing real research.”

  Shows the AI safety transition is organizing current career choices rather than remaining a passive interest.

• ✓ “The path to less catastrophic risk is that better eval habits become part of release gates and internal safety cases.”

  This is the larger future he is reaching for: eval practice influencing deployment decisions, though still at the level of one narrow contribution.

• ✓ “The value is probably not “this exact harness gets adopted,” at least not as-is. It is more about developing better evaluation methodology and taste: how to design paired prompts, catch scoring artefacts, and make refusal metrics less gameable.”

  Ambition is oriented toward useful methodological contribution, but he is not claiming a standalone product or institution-level plan.

• ✓ “If, after tightening it and showing it to one or two serious users, the feedback is still “nice learning project,” I should probably stop building it as a standalone thing and look for a way to contribute under someone with a clearer evals agenda.”

  This limits the placement: he is serious and pragmatic, but more aimed at finding a useful role in existing efforts than at building his own thing at scale.

Why 7 · Sam comes across as straight, receptive, and decent under pressure. When challenged on whether the project should exist as infrastructure, he does not get defensive; he concedes the point may be right and turns it into a testable next step. He talks about feedback from others fairly and specifically, without using people as villains or props, though the transcript does not show much warmth beyond good-faith candor.

• ✓ “That might be the right conclusion, honestly. I don’t think I have strong evidence that this specific harness deserves to become its own infrastructure project.”

  Takes a direct challenge without heat or face-saving; he can concede a hard point plainly.

• ✓ “The conversation was pretty direct but friendly. Their point was that the harness was useful for showing a failure mode, but if they were deciding what to run before shipping a feature, they’d want tighter integration...”

  Describes critical feedback from a colleague in a fair, non-defensive way and preserves the other person’s reasoning.

• ✓ “That was fair, but it changed how I think about the project.”

  Receives unwanted feedback as legitimate rather than treating the critic as an obstacle.

• ✓ “I should have done that earlier; so far I’ve been treating feedback as opportunistic rather than as a milestone.”

  Owns a gap directly instead of deflecting blame onto users or circumstances.

Refusal/lookalike evaluation harness

their part: He built the repo, prompt dataset, runner script, scoring script, logged outputs, manual review pass, and public write-up; feedback came from colleagues, BlueDot cohort members, and blog-post commenters.; numbers: Private GitHub repo; 340-prompt JSONL dataset; logged model outputs; scoring script; short write-up; few hundred readers; 11% false-positive rate on benign lookalikes; one prompt template artefact made the model refuse more often and look safer than it was.

Recommendation system rebuild

their part: He was one of two engineers on the rebuild; he says he personally figured out that many “negative” examples were actually unexposed items, making the learning signal muddy.; numbers: About a year and a half ago; one of two engineers; six or seven weeks to an A/B-test improvement; offline metrics initially looked okay but did not move online metrics much.

Why 9 · Sam is consistently bounded and self-limiting under follow-up, including when the interviewer gives openings to inflate adoption, technical novelty, or infrastructure value. They volunteer details that weaken the project story—the template artefact, lack of users, unvalidated demand, and the possibility that the right move is to stop building the harness. I would trust their self-report substantially: their claims are specific, checkable, and often accompanied by the caveat that makes them less impressive.

• ✓ “They should be able to reproduce the headline numbers if they have an API key and pin the same model version, although in practice model drift is a caveat.”

  Makes a concrete reproducibility claim while naming the condition and limitation, rather than overselling the artifact.

• ✓ “Beyond that, I don’t have users in the product sense. It’s a small pilot project, not an adopted eval suite.”

  Plainly limits the progress/adoption claim at exactly the point where candidates often let ambiguity work in their favor.

• ✓ “I haven’t yet validated that as something funders or labs would specifically want from me.”

  Volunteers an important demand-side weakness after discussing possible value, not just when cornered.

• ✓ “I don’t think there’s a single thing that most ML engineers in my position literally could not have done... It’s more evidence of conscientious execution than rare research ability, though.”

  When invited to name a standout capability, refuses the overclaim and states the weaker interpretation of the evidence.

How often

Uneven but steady; most weeks he reads a couple of AI safety posts or summaries plus ML engineering material for work.

Kinds

LessWrong posts, Alignment Forum posts, Substacks, Twitter/X threads, ML engineering material for work, Parts of papers via summaries or excerpts, BlueDot course material

Pieces named

4: Concrete Problems in AI Safety, mostly through summaries and course material; LessWrong; Alignment Forum; Twitter/X threads

Why 5 · Sam has a steady but relatively shallow reading habit: most weeks he reads AI-safety posts/summaries and ML engineering material, with a lot of Twitter/X and course-mediated content. He can explain the core argument of an influential piece and offer a plausible limitation, so this is more processed than just title-dropping. But he explicitly says he usually engages with papers through summaries or excerpts rather than reading them end-to-end, and there is little evidence of books, breadth across fields, or regular primary-source reading, so he lands below the “reads properly” rung.

• ✓ “Most weeks I’ll read a couple of AI safety posts or summaries, usually from LessWrong, the Alignment Forum, or people’s Substacks, plus ML engineering material for work.”

  Shows a regular reading habit, mostly in AI safety and ML engineering, but centered on posts and summaries rather than papers/books.

• ✓ “I also follow a lot through Twitter/X threads, which I know is not ideal for depth.”

  Confirms some of the diet is lightweight and thread-based; the candidate recognizes the depth limitation.

• ✓ “I’ve read parts of papers, but usually via summaries or excerpts rather than sitting down with the full PDF end to end.”

  Direct evidence against placing him at 6: he is not regularly reading full papers in his area.

• ✓ “What landed for me was the idea that safety is not only a philosophical alignment target, but also shows up as concrete failure modes like robustness, monitoring, scalable oversight, and avoiding bad behavior under distribution shift... Where I think it may be wrong, or at least incomplete, is that some of the concrete problems can feel too anchored to present-day ML systems.”

  He can reconstruct an argument and name a limitation in his own words, indicating some processing despite engaging mostly through summaries/course material.