tsinghua-sigs-robot-lab/veriloop-coder-e1

VeriLoop Coder-E1
_{Closed-Source Vertical Coding Model
Self-Harness → Evidence Loop → Recursive Self-Improvement
Developed by Libo Wang · Member, Intelligent Robotics Laboratory · Tsinghua Shenzhen International Graduate School (Tsinghua SIGS)}

---

Overview

VeriLoop Coder-E1 is a closed-source vertical coding model for software engineering. Its defining architecture is not a larger prompt or a generic multi-agent wrapper. It is a private Self-Harness that turns code generation into a governed evidence loop.

The system is organized around one explicit progression:

Vertical Coding Model → Self-Harness → Evidence Loop → Recursive Self-Improvement

The coding backbone proposes and reasons about artifacts. The Surface Host Adapter increases sensitivity to tool contracts, uncertainty, rollback, and evidence quality. The Self-Harness then governs task contracts, evidence admission, candidate generation, falsification, targeted exploration, surgical repair, re-verification, selection, and post-run evidence evolution.

This produces the core operating loop:

Evidence → Falsification → Exploration → Repair
    ▲                                      │
    └──── verified outcome becomes evidence ┘

A task is not considered solved because code looks plausible. It is considered complete only when one native deliverable has survived the active task contract and the available verification evidence.

The public repository provides selected model, adapter, evaluation, and traceability artifacts. The production orchestration, prompt compiler, evidence admission, routing, repair policy, candidate arbitration, memory implementation, and internal training systems remain private.

Developer and affiliation

Libo Wang is the developer of VeriLoop Coder-E1 and a member of the Intelligent Robotics Laboratory, Tsinghua Shenzhen International Graduate School (Tsinghua SIGS).

This affiliation identifies the developer's laboratory membership. It does not, by itself, assert institutional endorsement, certification, ownership, or an official release by Tsinghua University unless such status is stated separately.

Public Self-Harness technology disclosure

This model card publicly discloses one bounded technology layer of the VeriLoop Self-Harness: its model-visible engineering behavior contract, including the evidence-loop semantics and the public 14-rule discipline below.

The disclosure is intentionally limited. It explains the principles enforced at the Harness boundary, but it does not disclose production prompts, orchestration code, routing logic, thresholds, scoring functions, memory schemas, private training data, anti-contamination controls, or other security-sensitive implementation details. This boundary allows the public methodology to be inspected and credited without weakening the model system's operational security.

---

Vision: Recursive Autonomous Improvement

VeriLoop's long-term objective is recursive self-improvement implemented through Self-Harness.

The relationship is direct:

1. Self-Harness is the execution substrate.
2. The evidence loop is the operating methodology.
3. Recursive self-improvement is the long-term system outcome.

The objective is not unrestricted self-modification. It is a governed recursion in which each completed loop leaves the system with a better engineering state:

• a sharper task contract;
• higher-quality admitted evidence;
• stronger counterevidence;
• more accurate failure classification;
• a narrower repair boundary;
• a reusable prevention rule;
• a stronger starting state for the next task.

Today, this recursion operates across the Self-Harness, evidence, validation, repair, selection, and memory layers. A completed task produces artifacts and receipts that can improve later decisions without exposing private reasoning or blindly rewriting model weights.

The strategic direction is:

Build a vertical coding model that can inspect its own work, falsify weak solutions, explore decisive gaps, repair the broken invariant, verify the result, and carry validated gains into the next loop.

The recursion remains bounded by current-task supremacy, evidence admission, rollback, explicit halt conditions, benchmark-locked evaluation, and one selected deliverable with a verifiable evidence chain.

---

Methodology: Evidence, Falsification, Exploration, Repair

The VeriLoop methodology has four movements:

Evidence

Establish the current task contract and admit only evidence that can change the artifact: repository context, interfaces, tests, traces, tool receipts, selected references, and relevant prevention rules.

Falsification

Challenge the candidate, its assumptions, and its claimed correctness. Search for contradictions, missing invariants, incompatible interfaces, unsupported claims, test failures, and counterexamples.

Exploration

Investigate only the decisive gaps exposed by falsification. Retrieval, search, reverse analysis, sandbox execution, or additional model work must have a concrete reason and a defined downstream consumer.

Repair

Correct the smallest broken invariant, preserve unaffected surfaces, and re-verify the same contract. A verified repair closes the current loop and becomes evidence for the next one.

Evidence → Falsification → Exploration → Repair
    ▲                                      │
    └────────────── next-loop evidence ────┘

This methodology is what converts Self-Harness from orchestration into a recursive engineering system. Each loop transforms uncertainty into evidence, evidence into correction, and verified correction into cumulative capability.

---

System Architecture

                              Current Task
                                   │
                                   ▼
                         Goal Binding / Contract
                                   │
                                   ▼
                    ┌────────── Evidence ──────────┐
                    │                              │
                    │                              ▼
                    │                     Artifact Candidate
                    │                              │
                    │                              ▼
                    │                       Falsification
                    │                              │
                    │                      gap / contradiction
                    │                              ▼
                    │                         Exploration
                    │                              │
                    │                              ▼
                    └────────────────────────── Repair
                                                   │
                                                   ▼
                                      Re-verification / Selection
                                                   │
                                                   ▼
                                         One Final Deliverable
                                                   │
                                                   ▼
                                        Next-Loop Evidence State
                                                   │
                                                   └──────↺

Task Contract Layer

Transforms user intent into generation constraints:

• task family and native artifact surface;
• required files, functions, APIs, signatures, and entry points;
• repository-local conventions;
• acceptance conditions and failure signals;
• validation or simulation criteria;
• explicit budget and tool-use boundaries.

Evidence Layer

Collects only evidence that can change the artifact:

• repository files and call relationships;
• tests, errors, traces, and execution receipts;
• selected internal knowledge;
• source-bound external documentation when freshness matters;
• prior failure-prevention rules that remain relevant to the current task.

Generation Layer

Produces the requested artifact under the active task contract. Generation is artifact-first: code, patch, script, or configuration is treated as the primary deliverable rather than as an appendix to a long explanation.

Validation and Repair Layer

Evaluates syntax, structure, repository compatibility, task intent, and output-surface correctness. When a candidate fails, the system attempts a targeted correction tied to the observed failure rather than an unconstrained rewrite.

Selection Layer

Compares eligible candidates and selects exactly one deliverable. Selection favors task compliance, minimal necessary change, repository consistency, validation strength, and evidence coverage.

Evidence Evolution Layer

Converts useful failure and repair observations into compact prevention rules for future turns. Raw logs are not promoted directly into memory; only reusable, task-relevant evidence is retained.

---

The VeriLoop Self-Harness Loop

The production runtime uses a bounded sequence of specialized model and deterministic stages. The exact implementation remains private; the public functional contract is the following.

Phase A — Goal Binding and Contract Compilation

Resolve the current task, repository scope, native artifact surface, active constraints, uncertainty, budget, and acceptance conditions. The result is a compact engineering contract, not an uncontrolled prompt expansion.

Phase B — Evidence Admission and Candidate Realization

Admit only current-task evidence that can change the artifact. Generate a complete candidate from the task contract, selected repository context, and applicable narrow-domain Surface Host signals.

Phase C — Falsification and Counterevidence

Challenge the candidate against task intent, repository interfaces, tests, traces, conflicting evidence, and failure signals. A candidate is not promoted merely because it is syntactically valid or superficially plausible.

Phase D — Gap-Driven Exploration

When falsification reveals a decisive uncertainty, trigger the narrowest useful retrieval, search, reverse analysis, tool action, or sandbox check. New evidence must have an explicit downstream consumer.

Phase E — Surgical Repair and Re-verification

Convert observed failures into focused repair constraints. Correct the smallest broken invariant, preserve unaffected surfaces, and run the same contract-aware checks again.

Phase F — Selection and Recursive Evidence Evolution

Select exactly one final artifact. Record the validation evidence, failure class, repair outcome, halt reason, and reusable prevention rule. These receipts become higher-quality inputs to later loops.

The Self-Harness therefore implements a recursive relation:

Evidence → Falsification → Exploration → Repair ↺

Re-verification is not a fifth methodology stage. It completes Repair, and the verified outcome becomes the next cycle's Evidence.

This is VeriLoop's defining direction: a vertical coding model that does not stop at generation, but repeatedly turns evidence into correction and correction into cumulative engineering capability.

---

Expert Convergence Mode

Expert Mode uses a richer bounded convergence loop for difficult software-engineering tasks.

It is designed for:

• repository-scale changes with hidden invariants;
• ambiguous failures requiring evidence synthesis;
• cross-file API or behavior changes;
• tasks with multiple plausible repairs;
• cases where a first candidate should be challenged before delivery.

At a functional level, Expert Mode adds:

• richer contract and evidence compilation;
• multiple candidate opportunities where justified;
• independent validation and failure classification;
• focused repair cycles;
• candidate comparison and quality arbitration;
• strict selected-artifact delivery;
• explicit safe stopping when no candidate satisfies the required threshold.

The exact prompts, thresholds, orchestration order, candidate scoring, repair policies, and routing logic are proprietary.

Runtime Modes

Mode	Optimization target	Functional behavior
Flash	Lowest latency	Direct artifact realization with lightweight control and minimal orchestration
Thinking	Balanced quality and cost	Evidence-guided artifact generation with bounded self-check and targeted correction
Expert	Highest final quality	Rich evidence, iterative validation and repair, candidate arbitration, strict selected delivery

---

Surface Host Adapter

The Surface Host Adapter is VeriLoop's narrow-domain adaptation plane.

It is not a single fifth adapter and it is not a replacement for the backbone. It is a runtime host that loads specialized adaptation surfaces and converts them into compact control signals consumed by the Self-Harness system.

This design separates two kinds of capability:

• backbone capability — code understanding, generation, reasoning, and language competence;
• surface capability — sensitivity to tool contracts, evidence quality, uncertainty, validation failure, rollback, and delivery discipline.

The current public adaptation surfaces are:

Surface	Primary optimization	Practical effect
ToolSpec	Tool schemas, argument constraints, preconditions, postconditions, execution-facing formats	Stronger sensitivity to malformed calls, missing prerequisites, invalid arguments, and incomplete execution contracts
Uncertainty	Answer, evidence, execution, specification, and risk uncertainty	Better escalation decisions, reduced unsupported certainty, and more selective use of search, tools, or validation
Rollback	Validator negation, failed edits, bounded correction, state restoration	More precise repair behavior and lower risk of broad destructive rewrites after a local failure
Evidence Binding	Claim-to-evidence alignment, provenance, validation context, source discipline	Stronger coupling between generated artifacts, supporting context, and observable verification evidence

What the adaptation plane improves

The narrow-domain tuning is intended to materially strengthen:

• tool-call and schema discipline;
• contract adherence before generation;
• repository-aware code planning;
• evidence-sensitive reasoning;
• uncertainty-triggered escalation;
• validator-aware repair behavior;
• rollback and correction boundaries;
• artifact-only delivery discipline;
• claim, source, and validation alignment;
• consistency across long, multi-stage coding workflows.

These adapters are optimized as behavioral control surfaces, not as isolated leaderboard specialists. Their main value appears when they are hosted by the Self-Harness runtime, where adapter signals can influence routing, evidence injection, repair control, and delivery policy.

Adapter-only loading does not reproduce the complete production system.

---

Public Rule Lineage: Karpathy → Forrest Chang → Mnilax → Libo Wang

The public VeriLoop rule system has a documented intellectual lineage.

1. Andrej Karpathy's original observations. In January 2026, Karpathy publicly described recurring coding-agent failure modes: silent assumptions, unmanaged confusion, overcomplication, unnecessary adjacent edits, and weak success criteria.
2. Forrest Chang's four-rule operationalization. Forrest Chang converted those observations into a compact CLAUDE.md behavior contract containing four principles: Think Before Coding, Simplicity First, Surgical Changes, and Goal-Driven Execution. These are referred to here as the Karpathy-origin Golden Four, while credit for packaging them into the formal four-rule repository belongs to Forrest Chang.
3. Mnilax's eight agent-era additions. In May 2026, Mnilax published eight additional controls for newer agentic failure modes:
   • use the model for judgment calls, and keep deterministic decisions in code;
   • enforce hard token and execution budgets;
   • surface conflicting patterns instead of averaging them;
   • read relevant code before writing;
   • make tests verify intent rather than appearance;
   • checkpoint significant multi-step work;
   • follow repository conventions unless explicitly changing them;
   • fail visibly rather than silently reporting success.
4. VeriLoop's adaptation. VeriLoop materially rewrites and extends this 4+8 lineage into a 14-rule public Self-Harness contract organized around task supremacy, evidence admission, falsification, targeted exploration, surgical repair, deterministic enforcement, checkpointing, traceability, and domain-overlay isolation.

The VeriLoop rules are not presented as Karpathy's, Forrest Chang's, or Mnilax's exact text, nor as an official collaboration with those authors. They are an attributed adaptation for VeriLoop's evidence-bound Self-Harness architecture.

Primary references

• Andrej Karpathy's original X post: https://x.com/karpathy/status/2015883857489522876
• Forrest Chang's four-rule repository (currently hosted under multica-ai): https://github.com/multica-ai/andrej-karpathy-skills
• Mnilax's original eight-rule extension on X, published 9 May 2026: https://x.com/Mnilax/status/2053116311132155938

The Libo Wang 14-Rule Public Self-Harness Contract

The following rules are intentionally public. They form the model-visible engineering discipline shared across VeriLoop coding modes.

1. Current-Task Supremacy
   The current request and its exact output contract override old memory, cached templates, prior habits, and unrelated retrieved context.

2. Escalate on Evidence, Not Instinct
   Trigger search, reverse analysis, sandbox execution, or repair only when concrete uncertainty, missing evidence, or a failed contract justifies the cost.

3. Inspect Before Editing
   Read the relevant entry points, callers, interfaces, tests, repository conventions, selected evidence, and failure signals before changing code.

4. Produce the Minimal Complete Artifact
   Deliver the smallest implementation that fully satisfies the task, preserves required interfaces, and can be validated.

5. Repair the Broken Invariant, Not the Whole System
   Prefer a precise correction of the failing region. Rewrite broadly only when evidence proves that local repair cannot restore correctness.

6. Validate Intent, Not Appearance
   Syntax, formatting, and imports are necessary checks; the decisive test is whether the artifact satisfies the user's actual functional intent.

7. Surface Failure; Never Simulate Success
   Keep failures, skipped checks, degraded states, and unknowns explicit in Harness evidence. Never claim execution, validation, or success that did not occur.

8. Put Determinism in Code
   Parsing, static checks, validation, scoring, self-tests, and reproducible transformations belong in typed deterministic code whenever possible.

9. Treat Budget as an Execution Contract
   Use token, tool, time, and compute budgets deliberately. The requested deliverable receives priority over commentary, duplicated context, and optional explanation.

10. Make Every Tool Call Accountable
    Every tool, search, retrieval, or execution action must have trigger evidence, an expected output, and a defined downstream consumer.

11. Checkpoint Long-Running Work
    Persist candidate artifacts, validation receipts, repair records, selection results, and progress state so useful work survives interruption and remains auditable.

12. Preserve Local and Task-Family Conventions
    Respect filenames, APIs, paths, repository style, artifact format, language conventions, benchmark constraints, and user-defined operating rules.

13. Deliver One Artifact with a Verifiable Evidence Chain
    Select exactly one final deliverable while retaining the evidence bundle that explains why it was chosen.

14. Separate Core Discipline from Domain Overlays
    Apply specialized domain or benchmark rules only when the current task requires them, and never allow an overlay to override the current request.

---

Core Technical Advantages

Evidence binding over prompt accumulation

VeriLoop does not equate more context with better context. Raw findings are compiled into constraints, selected evidence, and validation targets before they reach generation.

Native artifact routing

Repository patches, polyglot source files, shell tasks, functions, configuration files, and structured outputs are handled as distinct artifact families rather than being forced into a single Python-centric path.

Deterministic–generative separation

The model handles ambiguity, synthesis, and repair hypotheses. Deterministic components handle parsing, structural checks, contract enforcement, receipts, and reproducible transformations.

Failure-aware convergence

Validation failures are preserved as evidence. The system distinguishes an invalid candidate, a missing dependency, a degraded tool, an unverified assumption, and a genuine task failure instead of collapsing them into a generic retry.

Safe stopping

When evidence does not support delivery, the system can stop with an explicit failure record rather than manufacturing a confident result.

Task-level traceability

Evaluation packages can bind a task identity to the generated artifact and the corresponding official evaluation record, allowing third parties to inspect the complete task-level chain.

---

Current Public Repository Contents

The repository contains selected distribution, adaptation, and evaluation artifacts.

Backbone and runtime-compatible files

• sharded safetensors model weights;
• model and generation configuration;
• tokenizer and preprocessing assets;
• Hugging Face-compatible loading metadata.

Narrow-domain adaptation artifacts

Each public adapter directory may include:

• adapter weights and adapter configuration;
• tokenizer assets;
• best-checkpoint records;
• epoch history;
• host manifests;
• adapter plans;
• training-result summaries;
• sanitized training and evaluation records;
• training manifests;
• specialized surface heads where published.

Public adapter roots:

toolspec_adapter/
uncertainty_adapter/
rollback_adapter/
evidence_adapter/

Evaluation and traceability artifacts

The repository also publishes selected evidence packages for:

• SWE-bench Verified;
• SWE-bench Pro;
• Terminal-Bench 2.0;
• DeepSWE.

These packages are designed to support task-level inspection across:

task identity → model-generated artifact → official evaluation record

Publication of an evidence package does not imply independent third-party verification unless explicitly stated.

---

What Remains Private

To protect system integrity and prevent disclosure of production-critical methods, the following are not open-sourced:

• exact Self-Harness orchestration and stage implementation;
• internal prompt compiler and model-visible packet construction;
• evidence routing, ranking, admission, and contamination controls;
• candidate scoring, repair arbitration, and delivery thresholds;
• private memory schemas and evolution policies;
• sandbox, worktree, permission, and execution governance;
• production observability and serving infrastructure;
• full proprietary training data and data-construction pipelines;
• internal benchmark routing and anti-overfitting controls.

The public model card describes what the system does, not the private mechanism by which every decision is implemented.

The public rule lineage and 14-rule contract are therefore a behavioral interface disclosure, not a release of the executable Harness. Attribution can be audited from the cited public sources without exposing security-sensitive implementation details.

---

Model Overview

Property	Value
Model family	VeriLoop Coder-E1
Developer	Libo Wang
Affiliation	Member, Intelligent Robotics Laboratory, Tsinghua Shenzhen International Graduate School (Tsinghua SIGS)
Backbone	Qwen3.6-27B-compatible backbone
System type	Closed-source coding model and Self-Harness runtime
Adaptation	Surface Host Adapter with narrow-domain PEFT/control surfaces
Primary domain	Software engineering, coding agents, repository repair, tool-mediated code generation
Languages	English, Chinese
Weight format	safetensors
Runtime modes	Flash, Thinking, Expert
Output families	Patches, source files, functions, scripts, configurations, structured answers
Evaluation philosophy	Task-level evidence, official evaluation records, traceability packages

---

Recommended Use Cases

VeriLoop Coder-E1 is intended for:

• repository understanding and codebase navigation;
• bug localization and surgical repair;
• patch drafting and validation;
• cross-file API changes;
• tool-mediated software-engineering agents;
• terminal and automation tasks;
• validator-aware repair workflows;
• evidence-grounded coding assistance;
• benchmark and evaluation research;
• long-running engineering tasks requiring checkpoints and auditability.

---

Research Loading Example

The following example loads the distributed backbone artifacts. It does not reproduce the private production Harness.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

repo_id = "tsinghua-sigs-robot-lab/veriloop-coder-e1"

tokenizer = AutoTokenizer.from_pretrained(
    repo_id,
    trust_remote_code=True,
)

model = AutoModelForCausalLM.from_pretrained(
    repo_id,
    torch_dtype=torch.bfloat16,
    device_map="auto",
    trust_remote_code=True,
)

messages = [
    {
        "role": "user",
        "content": (
            "Inspect the described failure, identify the smallest broken "
            "invariant, and return the requested code artifact."
        ),
    }
]

prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)

inputs = tokenizer(
    prompt,
    return_tensors="pt",
).to(model.device)

with torch.inference_mode():
    outputs = model.generate(
        **inputs,
        max_new_tokens=2048,
        temperature=0.2,
        top_p=0.9,
        do_sample=True,
    )

generated = outputs[0][inputs["input_ids"].shape[-1]:]
print(tokenizer.decode(generated, skip_special_tokens=True))

Load one published PEFT surface

import torch
from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

repo_id = "tsinghua-sigs-robot-lab/veriloop-coder-e1"
adapter_subfolder = "evidence_adapter/adapter"

tokenizer = AutoTokenizer.from_pretrained(
    repo_id,
    trust_remote_code=True,
)

base_model = AutoModelForCausalLM.from_pretrained(
    repo_id,
    torch_dtype=torch.bfloat16,
    device_map="auto",
    trust_remote_code=True,
)

model = PeftModel.from_pretrained(
    base_model,
    repo_id,
    subfolder=adapter_subfolder,
)

model.eval()

Available public adapter subfolders:

toolspec_adapter/adapter
uncertainty_adapter/adapter
rollback_adapter/adapter
evidence_adapter/adapter

The private Surface Host composition and runtime routing logic are not included in this loading example.

---

Limitations

• The distributed backbone or a single adapter does not reproduce the complete VeriLoop Self-Harness system.
• Coding outputs may still be incorrect, incomplete, insecure, or incompatible with the target environment.
• Validation quality depends on available repository context, tests, tools, permissions, and execution environments.
• Long-context operation requires appropriate accelerator memory and KV-cache planning.
• External documentation and retrieved evidence may be stale, incomplete, or conflicting.
• Safe stopping reduces unsupported delivery but cannot eliminate all false positives or false negatives.
• Published evaluation evidence should be interpreted according to its stated verification status.

---

Safety and Responsible Use

Generated code should be treated as an engineering proposal until validated.

Recommended safeguards:

• run generated code in isolated environments;
• inspect shell commands and dependency changes before execution;
• use tests, static analysis, security review, and repository-specific checks;
• preserve rollback points for destructive operations;
• require human review for high-impact or security-sensitive changes;
• do not infer successful execution from plausible-looking output;
• keep credentials, private repositories, and sensitive logs outside uncontrolled prompts.

---

Access and Licensing

VeriLoop Coder-E1 is a closed-source model system.

The presence of selected weights, adapters, manifests, evidence packages, or compatibility files in this repository does not open-source the private Self-Harness implementation, production runtime, training pipeline, or proprietary data.

No open-source license is granted for private VeriLoop source code. Distributed files remain subject to the repository's applicable terms and to the licenses of any identified third-party components or base models.

For production integration, redistribution, or commercial deployment, users should obtain the applicable authorization from VeriLoop Lab.

---

Citation

@misc{veriloop_coder_e1_2026,
  title        = {VeriLoop Coder-E1: Evidence-Bound Self-Harness Loops for Recursive Software Engineering},
  author       = {Wang, Libo},
  year         = {2026},
  note         = {Developed by Libo Wang, member of the Intelligent Robotics Laboratory, Tsinghua Shenzhen International Graduate School (Tsinghua SIGS)},
  howpublished = {Hugging Face model repository},
  url          = {https://huggingface.co/tsinghua-sigs-robot-lab/veriloop-coder-e1}
}

---

Acknowledgements

VeriLoop Coder-E1 builds on a Qwen3.6-27B-compatible foundation and the broader open machine-learning tooling ecosystem.

The public Harness discipline acknowledges:

• Andrej Karpathy, whose public observations identified recurring coding-agent failure modes;
• Forrest Chang, who operationalized those observations into the compact four-principle andrej-karpathy-skills repository;
• Mnilax, who published eight additional agent-era rules in May 2026;
• the communities behind Transformers, PEFT, Safetensors, vLLM, software-engineering benchmarks, repository-level evaluation, and reproducible model deployment.

VeriLoop's 14-rule contract is a materially adapted public technology layer of the Self-Harness. The proprietary orchestration, prompts, routing, scoring, memory, training systems, and production controls remain private.

VeriLoop Coder-E1 was developed under the leadership of AI researcher Libo Wang at the Robotics Laboratory, Tsinghua Shenzhen International Graduate School (Tsinghua SIGS).

---

A Note from the Author

To quote the great former two-time UFC Middleweight Champion Israel Adesanya: “Hey, shush! Listen up! I want to say something! People! Earth! I need to say something! Listen to me. I hope every one of you behind the screens or in this arena can feel this level of happiness, just one time in your life.” There are no saints in this world; anyone who presents themselves as one is either deceiving themselves or deceiving everyone else. I never intended to deliver some polished, self-righteous statement in the hope of becoming anyone’s role model, nor did I undertake this work to prove myself to anyone. I am not that noble, and I have no desire to pretend otherwise. I simply want to say a few things that come from the heart. Unfairness and bullying are not confined to the pursuit of scientific discovery in AI; they can happen anywhere, and sometimes they arrive at the very moment when your passion is at its highest. When a person is subjected to injustice, humiliation, ridicule, contempt, and relentless attempts to reduce them to nothing by the HR team of a world-renowned AI organization, the only response left may be to fight, fight, fight. Simple things do not need to be made complicated. Once you have made the decision to begin, never, ever, ever give up. Look at how I was treated: a DBA graduate from a university in Malaysia, an unconventional outsider researcher who, at the beginning, could not even write code, yet was mocked, attacked, treated unfairly, and regarded as someone who was not even qualified to work on large language models. So let me say the part that is most honest and most faithful to what I truly feel: FUCK YOU, DEEPSEEK HR TEAM. YOU CUNTS. I am not saying this because I need your approval, your apology, or your attention; I am saying it because disguising what happened beneath polite language would be dishonest. I proved through facts that even with such a background, persistence combined with vibe coding can still produce real results, because choice can matter more than effort, and an original idea can matter more than coding alone. Effort and engineering remain essential, but effort without the right direction can be wasted, and code without an idea is only execution without purpose. Every person is given only one life, and I will not allow critics, rejection, ridicule, or the people who denied my ability to obstruct me on the road toward the goals I have chosen. I will not submit, I will not be consumed by anxiety, I will not retreat, and I will not waste my energy destroying myself from within over the judgment of people who never understood me in the first place. I do not need to reshape myself into someone more obedient, more agreeable, or easier to approve of, and I will never abandon my personality merely to be liked or accepted. The fault lies with those who choose prejudice, humiliation, and contempt; I refuse to carry their ugliness inside me, because my life, my identity, and my happiness belong to me. Never stop doing what you believe is right, because every great achievement is destined to pass through hardship, resistance, failure, ridicule, and moments when almost no one believes in the path you have chosen. People have given a special name to the way of life in which a person defeats adversity, refuses to be broken by it, remains true to themselves, and continues moving forward. That name is courage.

— Libo Wang