Published a paper in Nature with the CEO of Anthropic. He resurrected three-year-old abandoned code using Claude Code.

700,000 lines of ancestral code. People came and went in waves, and the unfinished project had been on hold for three years, with no one daring to touch it. Until the chief developer wrote an "instruction manual" for Claude Code, and the project was completed in two weeks.

Brendan MacLean, the chief developer who had been working at the Department of Genome Sciences at the University of Washington for nearly two decades, was staring at the code on the screen, his brows furrowing deeper and deeper.

This code belonged to a functional module of Skyline, the file view panel, which had been on hold for a full year.

The developer who wrote it graduated and left the laboratory, leaving behind a semi - finished product. In the past, this kind of unfinished project had only one ending: it would lie in the repository forever, with no one daring or wanting to touch it.

But this time was different.

Two weeks later, the development of this panel was completed, and the name of a co - author, Claude, appeared in all the final code submissions.

17 years, 700,000 lines, people left but the code remained

Skyline is an open - source software of the MacCoss Laboratory, used to help researchers detect and quantify proteins in plasma and tissues, which is crucial for biomarker discovery, disease research, and drug development.

With 700,000 lines of C# code and 200,000 automated tests running every night, it has been iterating since 2008.

This is no ordinary laboratory.

Dario Amodei, the co - founder of Anthropic, was once a member of the MacCoss Lab and co - authored a paper in Nature Biotechnology with Brendan in 2012.

At that time, Skyline had only been under development for four years, and Dario was still in the Department of Radiology at Stanford.

Paper address: https://www.nature.com/articles/nbt.2377

Brendan is the chief developer of this project and the only "core link".

In the past nearly two decades, undergraduates came and went, postgraduate students graduated, post - docs changed jobs, and interns never came back after the summer vacation.

Every time a group of people left, the code remained, but the people who understood the code were gone. By 2024, there were areas in the code repository that literally no one dared to touch.

Brendan spent decades doing the same thing: training new people.

He taught them hand - in - hand to get familiar with this huge code repository, understand the relationships between components, and understand the specifications accumulated over 17 years. He was very familiar with this methodology.

But he never thought that one day he would apply the same methodology to an AI.

A flash of inspiration: "train" the AI like an intern

Brendan first tried Claude.ai in the browser.

The experience could be summarized in four words: extremely painful.

He described a problem, got a response, and then copied the entire C# file back into the project. It could only handle isolated problems that could be described clearly without referring to other code in the project. As soon as it involved incremental modifications, it was completely useless.

Every conversation seemed to start from scratch. Claude didn't know what Skyline was, how the components were related, or the specifications accumulated over 17 years.

Wait a minute. He was very familiar with this pain point. Isn't this exactly what it's like every time he trains new people in the laboratory?

New people don't know the overall picture of the project, the relationships between the code, or the unwritten rules that only old - timers understand.

The only difference is that new people will gradually learn, while Claude forgets everything after each conversation.

So he made a decision: train Claude Code like an intern.

Specifically, he created an independent code repository called pwiz - ai, specifically for storing the context for the AI, completely separate from the main code repository. The CLAUDE.md in the root directory is the "topographic map", telling Claude the project's structure, compilation method, and testing process.

Project address: https://github.com/ProteoWizard/pwiz-ai

But the topographic map only solves the problem of "knowing where", not the problem of "knowing how to work".

The real professional knowledge is stored in the skills. For example, he wrote a debugging skill to pull Claude out of the "blind guessing and trial - and - error" mode.

The description of this skill is very strict: "Always load when troubleshooting bugs, failures, or unexpected behaviors", forcing Claude to do root - cause analysis before taking action.

Coupled with the MCP integration, Claude can read real test data, exception reports, and user tickets.

With three layers of context in place, the effect is immediate.

After building the context, the communication cost of teaching Claude to debug the code repository dropped precipitously.

Because it already knows what the code does. The starting point of the interaction is understanding, not a blank slate.

The code that no one dared to touch was completed in two weeks

After building the context, Brendan started using it to clean up the technical debt that had accumulated over the years.

This story dates back to three years ago.

At that time, the developer in charge of maintaining the nightly test management module of Skyline left. This module was written in Java, and its technology stack was completely different from the C# of the Skyline main body.

In the past, this kind of half - finished project would only be thrown into the trash. In academic laboratories, personnel turnover is the norm. Any semi - finished product in progress is basically a permanent semi - finished product.

Brendan's handling method was no exception. After the person left, he stopped adding any new features to this module. It remained on hold for three years.

Until recently, he asked a LabKey developer to write a configuration document using Claude Code.

Then, he spent less than a day adding the feature he had been thinking about for years and also updated the page layout with CSS.

Even more impressive is what followed.

Skyline has more than 2,000 tutorial screenshots, which were previously maintained manually. Now, all of them are automated and nearly 100% reproducible.

Claude also wrote a C# MCP server, allowing it to "see" the differences between the screenshots.

Every morning before Brendan sits down to work, the daily report automatically generated by Claude is already in his inbox, summarizing the nightly test failures, exceptions, and unresolved tickets.

The developer in the laboratory who was originally least interested in AI programming tools has now built and released a brand - new data visualization panel using Claude Code.

This change is not limited to the MacCoss Laboratory.

In the same week, OpenAI presented another answer

One day before Anthropic published this blog, OpenAI also released an open - source project, Symphony.

Currently, it has received more than 18,000 stars on GitHub.

Project address: https://github.com/openai/symphony

The reason is that engineers sometimes need to open 3 to 5 Codex sessions simultaneously, and switching between contexts can drive people crazy.

Symphony's approach is simple and straightforward: turn the Linear project kanban into a control center for AI programming.

Each open - state issue is automatically assigned an agent. The agent runs continuously in an independent workspace, restarts automatically if it crashes, and takes over new tasks automatically.

All humans need to do is review the results.

According to OpenAI's statistics, in the first three weeks after some teams launched Symphony, the number of successfully merged PRs soared by 500%.

But the sharp increase in output is only on the surface. The real change is that the team's perception of "work" has been completely subverted.

When engineers no longer need to stare at Codex sessions, the "perception cost" of each code change drops significantly.

Want to try a refactoring plan? Just submit a ticket. If you're not satisfied with the result, just discard it. The cost is almost zero.

Even product managers and designers can submit feature requests in Symphony without cloning the Git repository or opening a Codex session.

Describe the requirements in plain language, and you'll receive a review package with a demonstration video in a short while.

What's more interesting is how Symphony was born.

Its core is actually a SPEC.md, a specification document written in Markdown. OpenAI asked Codex to implement it in six languages: TypeScript, Go, Rust, Java, Python, and Elixir, to polish the ambiguous areas in the specification.

Finally, they even used Symphony to orchestrate Codex and rewrite Symphony itself.

Of course, OpenAI also admits that not all tasks are suitable for this approach.

For tasks with extremely vague requirements and heavy reliance on intuition and professional judgment, engineers still have to open an interactive Codex session and do it themselves.

"Training an apprentice" and "running a factory"

Although the approaches are different, Anthropic and OpenAI are answering the same question: how to make AI work in real engineering processes.

Anthropic's answer is "depth". A senior developer spends time building a context layer, teaching the AI to understand a specific code repository like training an intern. CLAUDE.md, skills, and MCP, each layer deepens the AI's understanding of the project. The core belief is that the quality of the context determines everything.

OpenAI's answer is "scale". Create an orchestration layer, automatically assign an agent to each task, and the agent runs non - stop, restarting if it crashes. Engineers change from "code writers" to "kanban managers". The core belief is that the efficiency of orchestration determines everything.

One is like a master training an apprentice, and the other is like running an automated factory.

Interestingly, the two approaches converge at a key point.

Brendan wrote CLAUDE.md and skills to solidify project knowledge, and OpenAI wrote WORKFLOW.md to solidify the development process.

Both sides found that things that were previously passed down orally and through muscle memory now have to be written down in black and white in documents for the AI to understand.

Whether it's "context engineering" or "Harness engineering", it's essentially the same thing: turning human implicit knowledge into machine - readable explicit assets.

Both approaches work, but they are suitable for different scenarios.

Facing a 700,000 - line old code repository, you need Brendan's in - depth context engineering. For a new team - level project, Symphony's large - scale parallel scheduling is more suitable.

But there is one thing that both companies agree on.