Case Study How Open is too Open? Velocity above Governance (OpenAI . OpenClaw . OpenSource)

Max Health.tech

 

How Open is too Open? Velocity above Governance — A real-world case study

What happens when an open-sourced personal assistant is over-hyped? 

OpenAI hosted a large-scale event as its most viral marketing stunt ever —  in the midst of a growth spurt. 

 

A launch combining recruitment, product positioning and community engagement under one roof —  where Open could be a little..too Open. 

 

Feb 6, Frontier Tower, San Francisco. An event hosted by OpenAI opens its doors to tech-savvy participants - welcomed by lobster rolls and claws - the first tip-off to a well-thought-out marketing hype around OpenClaw brought to the public by the creator himself.

On Day 2 of the event - catering coincidence aside —  the OpenAI Codex Hackathon took place and to my surprise, seconds after sitting down, the OpenClaw creator grants access to the maintenance portal to the attendees - we weren’t handpicked - it was randomly distributed to log onto and take part in an unscoped, unpaid, unsupported project with as final goal: bringing down the PR count and merge into a main. No guidance, no onboarding and no time for staging. Head counts could have been dropping out any second - the speed of execution was high and the hype was on.

 

A contribution guideline without guidelines for contributions under the (non)watchful eye of a project owner aka the benevolent dictator (quoted by himself Jan 2nd) which was a bold positioning at a moment of rapid growth. The BDFL model can work. It has worked before. But it works best when the project is small or when oversight scales with growth and the project owner is skilled enough to maintain genuine oversight. Once the scale outgrows that capacity, structure needs to grow with it. Otherwise, momentum replaces governance.

 

Scalability aside, we are dealing with real data, and if not handled well and problems are overlooked —  it can cause real damage. AI and its alacrity growth are already raising eyebrows as it is. The benevolent dictator is a well-known pattern when there is a huge hype around one individual, and the “best practice” way to handle that situation is to re-assign authority to a board of people. It is truly difficult but necessary to handle this well in order to minimise harmful consequences. “The best-case outcome is a BDFL who recognises when to transition to a broader governance model before the drawbacks cause real damage.”

 

I walked away from that table only to meet - no other than, Sam Altman, but this was most likely not a coincidence. That hackathon was part of their marketing campaign. Codex 5.3 was released that same day. Anthropic dominates code generation, and Google dominates image generation. Codex is consistently promoted over competing tools and MCP gets dismissed so it was no surprise when on February 15th it was officially announced that Peter joined OpenAI as an employee.

Nevertheless, I accepted the invitation to become an unincentivised maintainer of OpenClaw as I am also eager to learn and sharpen my knowledge in different settings, and here, my ambition led me to fall through the cracks of a person with decision-making power without sufficient structural guardrails to take in questions and follow-up on actions.

 

 

The Problem

Over tens of thousands of GitHub Actions minutes were burned in a few days. Failed builds, redundant test runs, CI churn from missing gates. I found many files with thousands of lines of code and hundreds of duplicate functions across the codebase. Both identical functions and slight variations of the same logic, written by AI agents that had zero awareness of what already existed. The current codebase is being vibe-coded with minimal human oversight.

 

How it presented itself

It’s a simple, somewhat too mainstream data gathering ecosystem:

1. An AI agent gets a task.

2. It writes code that “works”, meaning it passes the immediate test and satisfies the prompt.

3. Nobody checks whether the code duplicates existing functionality.

4. Nobody notices the file went from 3,000 lines to 5,300

5. It gets merged

6. Repeat

 

The LLM does not know that a nearly identical helper function already exists 1,000 lines above, or in the next module over, if it is not told to look for it. It solves the problem in front of it and moves on. Like a living cell that reproduces without control. When you put the human out of the loop, the codebase grows in volume, but decays in quality. The only criticism is now satisfaction. “Did I get what I wanted?” If not, then the AI has to iterate further until I get what I wanted.

 

Security concerns are more than valid when people tend to value hype over governance. If you wonder how OpenClaw is being released: once every few days by using code in the main branch to create a new capsule release.

 

My contribution

I went through the codebase and identified duplicate and near-duplicate functions. Consolidated shared logic into reusable helpers. Broke apart files that had no business being thousands of lines long. Set up a quality gate so new submissions actually get reviewed for duplication and structural fit before they land on main. Enabled typechecking for modules. The codebase got smaller and more maintainable, and CI stopped choking on broken builds.

 

The process

Asking for staging after I saw that every PR gets directly merged into the main codebase might need refinement in the choice of processing and organising the data to keep aligned with governance best practices.

 

But the project owner had no time to think about it. A few days later, I was the top contributor, and people started reaching out to me via email, pinging me in their PRs, asking for reviews, offering jobs, even on X! Not because I implemented staging or shipped features but because I removed unnecessary codelines. “Your contributions to openclaw/openclaw caught my attention, and I wanted to reach out.” 

 

The Response

When I asked for staging — I noticed something familiar in fast founder-led environments: strong direction can unintentionally reduce contradiction. If the narrative is velocity and AI-first execution, few people want to be the ones slowing it down. Being rejected by a project owner of such calibre shifts dynamics. So the narrative continues: “we accept AI-generated code of any kind”.

 

When stricter quality gates were set in place, some people were not happy about it. I see this pattern forming across the AI-assisted open source ecosystem. The pressure to merge PRs and ship features actively punishes the people doing real code maintenance work.

 

2 days later, the code quality gate I had installed, which prevented new duplicate functions from being introduced and code files from growing endlessly, has already fallen. commit/c2178..  was removed for being “useless”, when the gate had already saved thousands of CI minutes while preventing duplicate codes from being merged.

 

And from the project owner you may ask? There was no response. In fast-moving environments, that often signals that priorities lie elsewhere. Regardless, on February 14th, he assigned tasks to a wide array of agents, both locally and in the cloud, to continue with the refactorings and deduplications I started. The intention to improve was visible. The method to optimisation appears to be reactive rather than preventive. 

 

 

The Numbers

Snapshot

Date

Files

Total LOC

Duplicate function names

Before CI gate removal

Feb 12

3,840

694,527

415

Before the project owner’s sweep

Feb 13 (end of day)

4,052

731,516

429

After sweep

Feb 14

4,166

741,598

419

So the duplicates went up from 415 → 429 between Feb 12-13 (new code was being added faster than dedup was happening), and the project owner’s sweep on Feb 14th brought it back down from 429 → 419. That shows effort. But new duplicates are still being introduced while cleanup happens in parallel.

Refactoring in waves is not a substitute for guardrails upstream. It is just not possible to outsource structural thinking entirely to multi-agent systems. The consequence is structural decay disguised as progress.

 

An upstream structural safeguard would have reduced human logistics burden —  the project owner could have re-enable the simple but highly effective code quality gate and pay naturally intelligent humans to clean up. In fact, the project owner’s artificially intelligent agent swarm is still refactoring non-stop, and brought duplicate functions down to 378. It took 637 commits to correct the structure. 

 

The Bigger Question

I believe AI should be more accessible to everyone. That is the stated mission of projects like this. But accessibility without oversight produces exactly what I found: AI-made codebases that are not maintainable without AI. AI is making humans depend on it.

 

AI does not need centralised authority without friction. It needs real human oversight and people who are comfortable pushing back. My take is that this project could be risky, not because of AI, but because hype compresses feedback loops. Benevolent dictator models depend on self-correction. When growth accelerates faster than governance evolves, risk scales quietly in the background. My question is, when will security measures be embedded so the system can scale whilst staying aligned with governance. Even if it takes a little more time to implement. 

 

What makes this more urgent is that governments are now actively discussing the use of code that is one big mess. When software influences public infrastructure, healthcare systems, or democratic processes, the public has a right to know whether anyone with real accountability is actually reading the code. Anonymity has its place in open source, but accountability cannot be optional when the stakes are this high.

 

 

So what is next?

Safeguards would need to be assigned around guidelines as the first step toward keeping control. If only AI knew how the code that drives AI to work would work but still needed a human brain to check to secure governance over automation, there would be some control left. OpenClaw is not unique - everybody can vibecode their personal assistant now. Every digital idea can be copied and implemented within no time. The world is about to change drastically. Still, I am not losing hope; instead, I built RepoWatch.

This tool points out obvious code quality issues, lists contributors and uses various traditional algorithms to detect duplicate code across PRs. It is derived from an old uni project I made before AI was a thing, where I had to find potential plagiarism in 50 code submissions made by other students. Back then, I did some research and implemented my interpretation of document fingerprinting. I am sure that similar ideas will become more important in the future in order to prevent duplicate data from being processed. My tool aims to bring clarity and transparency so that not only AI can understand code, but also humans, as well as open standards and metrics to determine the uniqueness and consistency of a codebase.

 

New worldwide AI systems should be embedded after gatekeeping is aligned with governance. Fields such as healthcare cannot afford velocity over quality. It needs beta testing, scalability frameworks, protected gateways and specifically assigned knowledgeable gatekeepers to effectively implement and use final code. 

 

Above-mentioned insights have been laid out and highlighted during an event I organised in the exact same location 2 weeks later, during one of my recurring events, which I call Healthtech connect by Max Health - the agenda was as follows:

 

Agenda:

19:00 - Dinner

20:00 - Maximilian Nussbaumer about maintaining OpenClaw, and what OpenClaw means for HealthTech

21:00 - Farewell drinks

 

HealthTech Connect is a collaborative community where enthusiasts, founders, and investors come together to challenge the status quo of healthcare technology. It’s a space for meaningful conversations, bold ideas, and practical insights. Connecting people who are building, funding, and shaping the future of digital health.

 

MaxHealth will be present at the Health.tech Global Summit in Basel from March 3-5, 2026, to discuss how to optimise healthcare infrastructures following the FHIR on SMART principles implementations and work together from the ground up.

 

Do you want to meet in person? Book your introductory meeting here.

 

Get to know us

Discover our solutions and Book a meeting

 

Discover our resources

SMART on FHIR in real-life practices talk at the HL7 FHIR DevDays 2025 YouTube

Out of the FHIR Podcast Substack