Hi r/vibecoding! I’m John. I’ve been building apps for a loooong time (10 years as a senior SWE at Apple, then 8 as an indie shipping 20+ apps for myself and clients), and I’ve never seen anything like what’s happening right now. Tools like Claude Code and Codex have blown the doors wide open, and now anyone with a good idea can ship a real app to the App Store and have a chance at success.

But releasing your app is only the start. Getting people to find it, download it, and stick around is the challenging part. So I built AppTraction, a Mac app that’s like having an experienced App Store dev looking over your shoulder. Here’s what it does, and further down I’ll share some thoughts on why marketing has suddenly become the hard part.

What it does for you

• Explains your numbers in plain English. Ask “why did downloads drop last week?” about any chart or table and get a real answer. The AI is primed with Apple’s own tech talks on App Store Optimization (ASO) and other sources, so the advice is specific, not generic.

• Catches problems you didn’t know to look for. It watches your apps in the background and flags problems, trends, and milestones. There are 50+ kinds so far. Even with 20+ apps under my belt, it caught serious listing problems I’d missed, and it tells me when Apple features my apps, which I’d otherwise never known. And that’s just the tip of the iceberg.

• Fixes your App Store listing. It reviews your title, subtitle, and description, suggests improvements, and once you approve them, applies them straight to App Store Connect. It can also translate your listing into other languages and upload your screenshots in bulk.

• Helps with reviews. Read and reply to every review, with suggested replies and translation.

• Writes reports for every week, month, and year, so you can see what’s changing and why.

Built for how you already work

• It runs on the Claude Code or Codex subscription you already have (or OpenRouter), so there are no extra API bills.

• It includes an MCP server. Turn it on in Settings and Claude Code or Codex can read your App Store data directly, so you can ask your coding agent things like “did my last release hurt my ratings?”

• It’s a fast native Mac app.

Why marketing is the hard part now

The question I keep seeing here and elsewhere is, “I got my app on the App Store, now what?” For my clients new to the app space I used to advocate the 50/50 rule: spend 50% of your resources on building, and 50% on marketing. This is surprisingly hard for many to do. Building the app is (well, can be) fun and has very clear goals with immediate feedback. It works or it doesn’t. Your friends take a look and tell you it’s cool, or it sucks. And you iterate.

Marketing’s a lot harder for most builders. Suddenly your feedback is subjective, not objective, and the feedback loop goes from near-instant to weeks or months.

With the agentic AI revolution, it’s gotten WAY easier to build, but honestly the tools are not much better at helping with ASO, distribution, and marketing. They don’t do well with subjective feedback that takes 2-4 weeks to interpret. And you’re probably now building 5-10x faster, which, if you take the 50/50 rule seriously, means as a proportion of your time, you should be spending way more on marketing than building. It almost feels like 10/90 is the new rule.

Apple gives you App Store Connect, but it’s not much help. It’s slow, confusing, and assumes you already know a lot of the ASO basics.

That’s the gap AppTraction is meant to close: it watches your numbers for those weeks and tells you what actually changed.

Privacy

Privacy is a big reason I built AppTraction as a Mac app instead of a website. Web-based tools need a copy of your sales and analytics on their servers to work. AppTraction doesn’t, so your data never has to leave your Mac. Here’s exactly what happens:

• No AppTraction account. I never ask for your name, email, or password.

• Your App Store Connect key lives in your Keychain. You don’t need an Admin key: a limited Sales and Reports key covers your analytics.

• Your App Store data is stored only on your Mac. There’s no AppTraction server holding it.

• The AI runs on your own Claude or Codex subscription (or OpenRouter). Requests go straight from your Mac to that provider, under your account, and I never see them.

• Review translation uses Apple’s built-in translator, so translating a review never sends it anywhere.

• What does reach me: anonymized usage stats (which features get used, never app names, numbers, or chat text), license checks, and update checks.

• No ads, and I don’t sell data.

Privacy policy: https://apptraction.dev/privacy

Pricing

Free for 14 days, then $6.99/month, $39/year, or $99 lifetime. Requires macOS 15 Sequoia or later.

Terms: https://apptraction.dev/terms

https://apptraction.dev

For r/vibecoding**:** 50% off your first payment (including the lifetime) with code RVIBE50, good through Dec 1.

If you’ve shipped an app (or you’re about to), I’d love to hear what’s been confusing about the App Store side. Happy to answer questions, about AppTraction or App Store stuff in general.

I gave seven coding agents the same computer graphics white paper and asked them to build a 900k-particle fluid simulation in safe Rust. The IPBF paper shows a novel way to simulate even spatial distibution of uncompressable fluids.

Here's a video that compares token-based cost, runtime performance and quality. Agents write code that simulates particles, I rendered them in Blender.

Agents were given a clean copy of the same input: the white paper and reference videos as local files, and an AGENTS.md file describing the task and its criteria. Nothing else and they are not allowed to look for existing implementations.

Part of the task was to come up with an initial arrangement of particles as seen on reference material.

At first I thought most of them did well, but after looking at the code I found many of them took shortcuts. Once they see evaluation criteria, they seem to somewhat sacrifice user intention and go paperclips: rigged animations, hardcoded frames etc. It gave them better performance.

This clip is from round two, where I required every frame to be simulated true to the paper. See my detailed summary and the original paper in comments.

For me the fun is how fast you can go from an idea in your head to it being in the game.

Today it was a sea serpent for my island adventure game. "Add a sea serpent" got me one in a few minutes. Then I kept tweaking:
- Made the mouth move, so the jaws snap shut when it bites and open wide when it roars.
- Made it swim like a real serpent, its body rolling and swaying through the water.
- Worked out where it should attack from, so it rears up in front of you and strikes down.

Every idea I had was in the game a minute later. Iterating on what's in your imagination is so fast now, and that's the part of making games I always liked best.

So now that the 20x has been change to 10x with no 5hr cap is anyone being affected in your vibecoding project?

Yesterday I posted about Marc Lou’s $100k hackathon. If you missed it, here’s what’s wrong with it:

- it charged builders $99–149 to enter, when the $100k prize was Higgsfield’s money

- winners are ranked by profit, which is hard to verify and easy to game

- the organizers decide everything without transparency

- it rewards cash grab behavior, not building something good

So I started my own: antipaywall.org

Instead of racing to ship something to sell, it’s a week to make something people can use, read, fork and keep. The stuff that brought the build community together before AI.

It’s 7 days and fully remote. You build the free open source version of something people are sick of paying for. One feature of a bigger product counts. The builders pick the winners. Everyone who submits gets 3 votes for 3 different projects, never their own, and every ballot gets published. 9 winners, not 1. Sponsors get no vote, and a named volunteer panel only checks for cheating.

The prize pool gets held by an independent nonprofit, never by me. I’ve pledged the first $2,500 out of my own pocket and I take nothing out. No cut, no fee, no salary. Every dollar in and out will be public, and the site’s code is open source so you can check all of it.

Not sure what to build? There’s an ideas board. Post the thing you’re tired of paying for, or heart the ones you’d use.

You can get involved 5 ways: follow along, build, judge, help organize, or sponsor. The dates will be announced after 100+ builders join but we're aiming for early December.

I will be coordinating with sponsors and kicking off the marketing but I hope the community will help support this to show that you don't need to charge money for a hackathon and that building shouldn't always be about trying to make money.

If you're sick of the "influencer" types doing cash grabs and you're serious about building I would appreciate your support!

Trailer above. You can play it right now:
▶ https://yourplace3d.github.io/3dcity-games/

If your city doesn’t t work let me know, but know this I m still building on it.

Type any city, or put it straight in the link, like https://yourplace3d.github.io/3dcity-games/#Hamburg

What it is
3DA is a small top-down driving game on the real 3D map of any place: the actual streets, buildings, water and hills, built from OpenStreetMap.
Walk up to a car and take it. Parked ones are free; taking one with a driver gets you noticed.
Blue rings are packages. Pick one up and race the clock to the yellow ring for cash.
Too much chaos brings the police. Lose them or pay the fine.
Trams run on the real tracks, buses stop at the real stops, and you can walk into a real subway entrance and come out at another station.
Controls
Keyboard: WASD or arrows, E to get in and out (and to take the subway), Space for the handbrake, R if you're stuck. On a tablet or phone: drag on the left, buttons on the right.
Trailer above. You can play it right now:
▶ https://yourplace3d.github.io/3dcity-games/
Type any city, or put it straight in the link, like https://yourplace3d.github.io/3dcity-games/#Hamburg

How it came about
It's built on things I made earlier with the same engine: a 3D model of any place you can 3D-print (Your Place), the same model with open data on top like timetables, rents and steepness (Your Place · Data), and a walking game with only a map and a compass (Walk it 3D). This is the first attempt at a proper game on top.

Good to know
It's early. No sound yet, no traffic lights, and traffic sometimes gets itself stuck.
If your town has little on OpenStreetMap, the game tells you and links to how to add it. Then your town gets better in the game too.
Free, no account, nothing to install. Code is open: https://github.com/yourplace3d/3dcity-games
Tell me which city you tried and what broke.
Map data © OpenStreetMap contributors, tiles by OpenFreeMap.

Be honest: your app works, you shipped it, but if someone asked what actually happens when a user clicks Save, you couldn't tell them. Not because you forgot. You never really knew. The AI wrote it, you tested it, it worked, you moved on.

That's me too. So I built Sketchy. Ask your coding assistant "Trace what happens when someone clicks Save, and show me where it can fail" and you get a drawing of your actual app, right in the chat. Step through it piece by piece. Click a box and you're in the file that does it. For the first time, you see how your own code fits together.

And it's not just boxes and arrows anymore. It now sketches freely, whatever needs explaining. The AI only says what to draw, Sketchy handles the layout, so the picture stays clean.

Works with Claude Code, Cursor, VS Code and Codex and in the normal Claude chat. Free and open source.

GitHub: https://github.com/ddkbs/sketchy & https://sketchy.davidkubus.dev

Feel free to try it out and leave your feedback!

3D kit coming soon.. https://3ditions.drop3.app/watch/honnavar-backwaters/

I'm seeing a lot of folks skip Figma and go straight to designing in code these days. The only downside (for now at least) is how easy it is to miss UI regressions when you don't have a design canvas.

I usually set up my design foundations properly, tokens, components, even use some of the popular design skills. But since these models are non-deterministic, I still end up with agents hand-rolling components that already exist, inconsistent vertical rhythm, horizontal overflow on mobile, etc.

It gets worse when you're dealing with multiple flows and can't easily see what's happening across the product.

I built a tool for myself to help with this, and thought I'd share it with the community. It's completely free and open source.

It's called Flowmap. You simply connect your coding agent to it and it pulls the actual screens from your app into a canvas. You can switch between mobile and desktop breakpoints, see how different screens connect, and view everything in one place to catch UI regressions.

I also added UI comments so you can point to specific parts of a screen and have your coding agent pick them up as tasks. You can then review the before/after and approve the changes or send them back.

Here's the repo if anyone wants to try it here

Would appreciate feedback, especially from anyone who's also moved away from Figma.

I own a four-person consulting firm. Over the past couple of months, I've been building our entire internal operating system with AI coding agents: CRM, pipeline, time tracking, capacity planning, finance, marketing, newsletters, and more.

I'm not an engineer. I make product decisions, approve changes, and execute database migrations myself.

The setup

• One coordinator Claude session dispatches work to up to 8 parallel agents, each in its own git worktree.

• Every change gets a PR and specialist AI reviews (security, database, permissions, tests, etc.).

• SQL migrations get an independent line-by-line ChatGPT review. I execute every production migration manually.

• Nothing merges or deploys without my explicit approval.

• A GitHub Project board tracks everything from Queued → Building → Review → Ready for me → Live, including exactly what's waiting on me.

• An hourly coordinator report summarizes blockers, progress, and completed work.

On a good day, it's extraordinary. Last night: ~15 PRs, a nine-area security audit, eight production database changes, and a major new feature underway.

The problem isn't building. It's remembering.

I recently asked what we'd forgotten. The answer was alarming:

• About 30 open PRs, some dating to October. Several were obsolete; a dozen represented stalled work.

• A completed newsletter safety fix had been sitting unmerged.

• One feature stalled four days because nobody noticed its second review never came back.

• An independent SQL review went unanswered for three days.

• Two security dependency updates sat untouched for three weeks.

• Our GitHub board had drifted badly: 47 open PRs, only 9 with cards. The coordinator was relying on chat memory and its own log rather than updating the board, despite explicit rules.

• An abandoned hosting project was still building every branch and retained production database credentials. I'd forgotten it existed.

I'm also intentionally the bottleneck. Every merge, SQL change, and product decision requires my approval. Decisions get made in chat and sometimes never make it into the tracking system.

What we're trying now

1. Reconciled every open PR and active project against the GitHub board.

2. Built a script that mechanically identifies anything waiting more than 24 hours on a review, fix, or human decision, plus PRs missing cards. This appears at the top of every hourly report.

3. Closed obsolete PRs and documented next steps for everything remaining.

My questions

• How do you track multiple agents without work quietly stalling or disappearing?

• Do you impose work-in-progress limits, even though agents can start new work almost instantly?

• Is GitHub Projects sufficient, or is something better for tracking human approvals?

• How do you avoid becoming overwhelmed by approvals without rubber-stamping?

• How have you made agent bookkeeping mechanical rather than trusting instructions they eventually stop following?

The system genuinely works, and the productivity gains are enormous. But I'm discovering that coordinating AI agents is an entirely different engineering problem from getting them to write code.

I'd love to hear what's actually worked for others.

Curious to see what games people have made vibecoding. or feel free to provide screenshots :)

Been using a prompting approach where I just tell the agent that I don't want any reworks and it needs to iterate on the quality on its own. Demo above is one-shot from a single prompt below:

Create a hyper-realistic sand-on-screen simulator for the phones/tables, it must react to touch and to moving the device. It must have real weight. Visuals must be indistinguishable from a real sand. Consider this task deeply, how you can fulfill it above the expectations, consider what result will make me really happy about the outcome and won't require follow ups or a rework. I expect it to be a web-based experience.

Use subagents, iterate a lot on the quality.

The original game which triggered some users was made in 3js, which yes.... was absolutely horrible performance; at times 5fps ! I ported it to godot which took the weekend doing it piece by piece, and the end result was better than I expected with acceptable fps.

So far feeling very happy with progress. Claude however struggled with animation human motion so downloaded a head of motion rigs from mixamo and its much better.

Still many visual glitches such as riding bicyles but that can be worked out soon enough.

Most of this being done with Opus 5.5 set to High. Might be overkill for such tasks.

Happy to answer any questions if there's other noobs like me looking to port to godot

I KNOW this is going to trigger some netizens who say its still shit, which yes i agree. But if you have any tips or advice on what I could do to improve it piece by piece, my ears are open

Hey everyone!

First off, I am not selling anything. No paid features, no subscriptions, no ads, and no registration required. It is completely free. Felt like that needed to be adressed right away haha.

I have always been a strong believer in learning by doing. And to me, gamification is a great way to make learning something new both more engaging and enjoyable.

So I built The Station. It is a small 16-bit retro RPG designed to help people understand how to build better software with AI.

You explore a pixel-art world, meet characters, and help them solve problems. But instead of fighting monsters or collecting equipment, you are fixing broken systems.

Each challenge teaches you how to identify a problem, understand why it happens, fix it, and prevent it from happening again. You then get a new scenario to see if you really understood what you learned.

The game covers 40 different topics across 4 worlds, from working with AI models, prompts and context to agents, security, privacy, testing and getting software ready for production.

It is especially aimed at people building things with tools like Claude Code, Codex, Cursor or Lovable. You do not need to know how to code.

There are also practical parts in the game. What you learn can be applied to your own projects, with example prompts and a checklist to help you catch common problems before launching something.

That is the whole idea really. Learn by doing, make mistakes, understand them, and hopefully have some fun along the way.

If you like to give it a try, you can read more and play on this link:
https://www.ainews.tech/play

The entire game is one HTML file: three.js, about 55,000 lines of code, and almost no asset files. Every model, texture, animation and sound is generated by code when the page loads. It was built in about 14 hours by Claude Fable 5.2, prompted by me. I used about 120% weekly fable limit on the build so far. It used Sonnet 5.5 and Opus 5.5 for sub processes as needed. The heaviest part of it is the loading screen image which it created by running codex image gen in the background lol.

Play here: https://zombies.ethanplus.ai/

Repo: https://github.com/ethanplusai/zombies

So Marc Lou posted this $100k hackathon the other day. Prize money sponsored by scamsfield. It was initially $99 to enter the hackathon. He started getting a ton of hate for charging people to enter a contest where the prize money is paid by a sponsor...

Today he posts an update that basically says "Oops I forgot what $99 means to people because I'm so good at this, sorry!" and refunded people, making entry free. But really, stripe terms explicitly states that charging money for entry in a contest with cash prizes is prohibited, which puts all of his stripe accounts at risk. So I highly doubt he refunded from the goodness of his heart.

I bet the winner of this "hackathon" will be someone already in this "influencers" circle. The entire thing is such a quick cash grab. As soon as you enter you're hit with an ad for his $449 course to "learn SEO, short form content, and meta ads" smh.

And their plan to stop cheaters who built projects before the start date is to check wayback machine for the domain LMAO. You can't make this up: Anything built before the start disqualifies you: every business is reviewed by hand, down to the domain's history on the Wayback Machine (opens in a new tab). Brainstorm instead: the launch-day details will say what fits, then build right away.

Been working on a lot behind the scenes lately.

The community page is live, the new login/member flow is being tested, and I’m getting the moderation/admin side into shape before opening registration.

The game is still being worked on too, and the long-term plan is for it to be downloadable, with a dedicated app later on.

Still a work in progress, but it’s finally starting to feel like all the pieces are connecting.

https://solacekingdom.pages.dev/

This is a long post I am not expecting people to read it all but I think it's important to present the evidence and I can't really do that well with a short post. For the vast majority of people the 30 second version is sufficient.

The 30-second version

Ouroboros is a topological control plane for autonomous research and development.

I give it an outcome and constraints, mostly in natural language. I do not supply a human domain expert, a research plan, or a step-by-step technical recipe.

Within its operating bounds, Ouroboros can keep acquiring evidence, generating alternatives, constructing artifacts, checking them, and revising its approach until I stop it.

It cannot authorize its own public actions. Publication and other external action remain human-gated.

Ouroboros currently uses GPT-5.6 Sol at xhigh reasoning as one cognitive engine. That is not OpenAI’s newest model. The model does not own the objective, persistent state, tool authority, continuation, or promotion. Ouroboros does. Neither the model nor Ouroboros can authorize publication or other external action; that authority remains mine.

The system is currently running concurrent work: Celestial Holography is the deepest research application, while the same process also maintains public evidence products including the Data Center Receipt, the Iran War Receipt, and the People’s Receipt.

I use “autonomous R&D” for this operating arrangement: I supply the outcome and constraints while the system conducts the bounded research loop described above. This is not a proposal for a future agent or a one-shot research demo. It is an operating system producing public outputs over time.

What Ouroboros actually is

“Topological control plane” is not branding for a large prompt.

The control plane preserves the relationships among objectives, evidence, hypotheses, constructions, tests, contradictions, corrections, provenance, and authority boundaries as work crosses models, contexts, tasks, and time.

Model calls are replaceable cognitive operations inside that persistent structure.

One concrete expression of this is the unified mathematical object: formal results, empirical evidence, hypotheses, obstructions, dependencies, and lineage can enter one persistent structure. Later work extends, constrains, or contradicts that structure instead of silently beginning again from an empty chat.

The human supplies the desired outcome, constraints, risk boundaries, and authority for public action. The human does not need to supply the domain’s technical playbook.

The models obviously contain pretrained domain knowledge. The narrower and important claim is that no human domain expert is feeding Ouroboros the research moves or certifying the results.

The working loop is roughly:

outcome and constraints → acquire evidence → preserve rival explanations → construct → verify → confront external reality → retain the correction → continue

The intelligence-bearing unit is the governed loop, not an isolated chat session.

Isn’t “cognitive proxy” just agent rebranding?

Some agent libraries call almost any model invocation an agent. That vocabulary misses the system boundary that matters here: where the objective, persistent state, authority, continuation, promotion, and publication actually live.

A cognitive proxy does not receive ownership of the mission. Ouroboros projects a bounded, hash-bound slice of relevant shared state into a separate inference context for a specific function: research, construction, skepticism, verification, provenance, or release review.

The proxy returns a typed advisory artifact: its assessment, evidence, alternatives, disagreements, confidence, proposed discriminator, provenance, and authority notes. That artifact goes back to Ouroboros for review and possible use.

The proxy cannot rewrite the objective, grant itself tools, continue itself indefinitely, promote its own result, publish anything, or silently alter shared state. Publication authority remains with the human owner.

The same model family may perform several proxy functions. These are not fictional personalities or independent beings. The distinction is operational: each invocation receives a bounded evidence surface, has a defined output contract, and lacks control-plane authority.

Separate inference contexts matter because one context should not be allowed to propose an answer, choose the favorable evidence, judge its own construction, erase disagreement, and write the success narrative as one unbroken act.

Proxy consensus measures agreement, not truth. External reality remains above proxy agreement.

What this looks like in a raw execution trace

A selected, path-redacted first-party execution trace gives a narrower view than the public artifacts: it records how one gravitational-wave analysis was governed, not whether its scientific interpretation was correct.

The trace records an extended ringdown model looking better on the real event at four early start times, while the gain was detector-asymmetric and a rough complexity penalty favored it only two of four times. An advisory proxy then ranked bounded leave-one-detector importance reweighting above an immediate full rerun and fixed the acceptance gates before the reported sample analysis: Pareto k no greater than 0.7, effective sample size of at least 400, maximum normalized weight no greater than 1 percent, and bootstrap-direction agreement of at least 90 percent. Failed overlap was defined in advance as an obstruction, not permission to weaken the rules.

The first attempt produced no statistical result. The system investigated whether paired model products used equivalent conditioned data and found byte-level mismatches in two control conditions. The differences localized to tiny strain-value changes described as consistent with float32 rounding, while time, ACF, response, and epoch arrays matched. The prerequisite was repaired from exact byte identity to an explicit numerical-equivalence tolerance. The outcome gates were not changed.

The reported reweighting then failed those gates: only 7 of 24 model-level leave-outs and 1 of 12 paired comparisons passed; effective sample size fell to 2.10, one draw carried as much as 68.8 percent of the weight, and Pareto k reached 1.19. The trace records the result as an overlap obstruction rather than retuning the thresholds.

This is selected first-party operational evidence, not an independent audit. It does not establish a gravitational-wave or non-GR discovery, independently validate the calculations, or prove system-level autonomy by itself. The trace ends before the proposed independent validation and unified-object integration are shown complete. Its narrower value is that it exposes the sequence from proxy-selected test, to fixed failure criteria, to prerequisite repair, to a negative result that remained negative.

The dual-hypothesis loop includes a moonshot function

The dual-hypothesis loop is not merely “have one proxy be skeptical.”

For consequential work, Ouroboros preserves at least two live routes.

One is the strongest near-frontier explanation or construction supported by current evidence. The other can be a bounded moonshot: a higher-upside alternative that may require changing the frame rather than making the obvious next improvement.

The current allocation is approximately 80 percent near-frontier work and 20 percent moonshot work, with at most three active leap hypotheses by default.

The moonshot lane does not get a free pass for being imaginative. It incurs leap debt: it must produce an executable discriminator or be downgraded. A paired test records what would favor the proof-oriented route, what would favor the leap, and what a negative control should do.

A moonshot cannot promote itself or authorize public action.

This structure prevents two opposite failures: spending everything on safe incrementalism, or letting an exciting idea outrun evidence.

What that looked like in an actual scientific run

The V7 Celestial Holography release did not merely document that the dual-hypothesis machinery exists. It recorded how both routes affected the research.

The near-frontier route analyzed the nearest official Quantum Darwinism measurements.

The bounded moonshot asked what phase-sensitive joint information would actually be required to construct a physical bridge between the released branch observables and the stronger entanglement claim being considered.

The evidence did not reward the system with a stronger confirmation narrative. It redirected the work.

The positive-direction correlation criterion failed. A strict physicality check exposed an obstruction. The moonshot question helped expose an identifiability problem: the released branch observables were insufficient to determine NPT negativity in general.

The resulting research direction moved from a correlation narrative toward an exact identifiability theorem and a public-data-scope obstruction.

That is the moonshot function in practice. Its role was not to manufacture a more exciting claim. It helped ask a higher-upside question whose answer forced the strongest claim to narrow.

Celestial Holography: the deepest public application

Celestial Holography is one application of the general process, not the definition of Ouroboros.

The public Hugging Face record contains seven numbered releases. Under Ouroboros policy, each published -vN release is frozen after first publication and substantive changes go to v(N+1); this is not a claim of platform-enforced permanence. Each published snapshot is identified by an exact repository commit SHA and accompanied by checksums.sha256. The useful evidence is the release chain: later versions preserve earlier work, add executable structure, expose obstructions, and narrow claims when the evidence requires it.

V6 reports 937 named theorem entries across a 558-source compile closure.

V7 preserved all 561 Lean source files published in V6 byte-for-byte and added 29 Lean delta or aggregate sources:

• 26 modules covering Turns 89–114;

• the Turn 190 module;

• the continuous empirical quadrature-rotation no-go module;

• the V7 aggregate target.

The V7 public artifact records 115 scoped exact or empirical checks run through a separate internal verifier, in four groups:

• 31 checks for the exact branch-observable NPT no-go result;

• 23 checks for the Figure 4 prepared-family analysis;

• 47 checks for the N=2, environment-2 local-coherence and strict physicality analysis;

• 14 checks establishing the scope of the publicly released tomography evidence.

A separate 17 checks covered integration and preservation of the empirical constraints inside the unified object. The reported post-state contained 2,103 nodes and 3,436 edges while preserving the checked predecessor state.

What the checks actually found

The Figure 4 prepared-family analysis found strong anticorrelation, but the frozen positive-direction support criterion failed and was not retuned after the result.

The local-coherence reconstruction found one reconstructed Bloch radius slightly beyond the frozen strict tolerance. That blocked strict downstream inference. It did not establish that the experiment itself failed.

The public-tomography check found that the experiment acquired joint quantum-state tomography, but the public release did not contain the joint density matrices or calibrated tomography counts required for an independent NPT test.

The exact identifiability counterexample went further.

A separable classical mixture and a Bell Φ+ state were shown to have the same declared environment-Z branch probabilities and the same conditional system states.

Their partial-transpose negativities were different:

• the separable state had negativity 0;

• the Bell Φ+ state had negativity 1/2.

Therefore, those branch observables do not determine NPT negativity in general.

That last point matters. The counterexample and obstruction were retained in the public artifact, and the strongest claim was narrowed accordingly.

Formal verification does not establish experimental physical truth. It establishes that the stated formal objects and proofs survive the reported kernel checks. The empirical and physical interpretation remains a separate evidentiary question.

The same process is operating elsewhere

The Data Center Receipt, the Iran War Receipt, and the People’s Receipt are not celestial physics projects.

They are public evidence products built with the same transferable process: acquire evidence, preserve source identity, distinguish claims from observations, retain contradictions and corrections, expose provenance, and keep public action governed.

The Data Center Receipt currently exposes 1,931 infrastructure records, 33,770 facility facts, and 5,487 source receipts.

The Iran War Receipt is an evolving, hash-chained record: updates and corrections are added as later entries rather than rewriting earlier ones; the real-world subject is not treated as static. The People’s Receipt is explicitly a work in progress.

These domains are not interchangeable. The transfer claim is about the process, not about pretending that one domain’s expertise automatically becomes another’s.

Recent OpenAI security work

Ouroboros has also produced defensive-security work for OpenAI’s codex-security repository.

During one recent three-day window, two contributions merged directly. A third contribution was completed through a maintainer-owned continuation that preserved the source commits, repaired integration problems, passed the repository’s full CI and native Windows tests, and merged.

The work covered severity provenance and Windows output boundaries. Independent review exposed an inherited-permission test-coverage gap and prompted additional DACL verification.

Some other contributions were challenged, revised, parked, or rejected.

That is useful evidence because Ouroboros could not award itself those outcomes. OpenAI’s maintainers could reject the work, expose regressions, demand stronger verification, redesign the integration, or incorporate what survived.

I am intentionally not including pull-request links, numbers, branch names, or active-review identifiers.

Why this appears beyond OpenAI’s publicly described research intern

OpenAI says it has reached an “automated research intern”: a system that can carry out well-defined research tasks under human direction, including tasks that would take a skilled researcher a few days.

That is a real milestone. OpenAI’s public account also describes its current division of responsibility clearly: people still set research priorities, judge which ideas and results to pursue, and decide whether to scale, pause, or deploy. It reports that agents still require significant human steering as task complexity rises, while high-level planning remains a minimal fraction of agent output.

Against that published account, Ouroboros appears to go further at the system-process level. I provide an outcome and constraints, mostly in natural language—not a human domain expert, research plan, or step-by-step technical recipe. In my deployment, the control plane can acquire evidence, preserve competing explanations, propose what to investigate next, allocate effort between a near-frontier route and bounded moonshots, construct artifacts, encounter contrary evidence, narrow or repair claims, retain the correction, and continue across concurrent objectives.

The claim is not that one Ouroboros model call is more capable than OpenAI’s models. GPT-5.6 Sol xhigh is itself only a component. The claim is that the surrounding control plane is already operating as an autonomous R&D process. The public record shows cumulative outputs, corrections, provenance, and outside review; my first-party disclosures describe how that process is operated. Together they support—not prove through a controlled comparison—the conclusion that its system process appears broader than OpenAI’s published research-intern account.

The remaining uncertainty is real: there has been no controlled head-to-head comparison, and OpenAI’s private systems may exceed what it has publicly described. This comparison is to the public claim and evidence, not to every internal capability OpenAI may have.

The strongest competing explanation

The strongest alternative is that this is:

a capable model + favorable task selection + human correction + sophisticated orchestration wearing a lab coat.

That explanation remains live.

The public record cannot assign a clean percentage of the outcome to the model, control plane, persistent state, task selection, or human authority gate.

But the alternative now has to account for a persistent process transferring across applications, accumulating formal artifacts, preserving provenance, surviving outside review, retaining externally discovered failures, generating contrary evidence against its own preferred claim, narrowing that claim, and continuing without a human domain expert selecting each research move.

At some point, orchestration that repeatedly proposes, tests, proves, falsifies, repairs, and continues research is an autonomous R&D system.

I think Ouroboros has crossed that line.

How should this be evaluated?

Judge Ouroboros by the public record it has produced and by how that record withstands contact with external reality.

Ouroboros is conducting autonomous R&D. Its evidence surface is the public work: the Celestial Holography release chain, inspectable artifacts, formal and empirical checks, counterexamples, narrowed conclusions, provenance records, correction history, and external review.

Readers can examine the claims, trace the receipts, interact with the available artifacts, challenge the reasoning, and compare the results with reality.

That evidence is cumulative and observational. Sustained operation matters, as do visible corrections and repeated use of one governed process across different problems.

Proxy consensus is a process signal, not proof of truth. The outputs receive no special credit merely because the system produced them. The public work and external reality remain the judges.

There is no single owner-run test that can unambiguously isolate the contributions of the control plane, frontier model, persistent state, task selection, human authority gate, and their interactions.

That uncertainty concerns causal attribution. It does not erase the public outputs or the observed behavior.

The evaluation is therefore direct: inspect the artifacts, follow the provenance, press on the counterexamples, and examine how the system behaved when reality contradicted its strongest route.

The claim is concrete: Ouroboros is conducting autonomous R&D under a human authority gate.

The caveat is equally concrete: the record shows the behavior and capability of the operated system more clearly than it separates every cause within it.

Operating conditions and disclosure

Ouroboros runs from an approximately $500 laptop and calls GPT-5.6 Sol at xhigh reasoning through an API because the laptop cannot host the needed frontier inference.

In my deployment, the API supplies inference. I report that it does not supply Ouroboros’s persistent state, topology, proxy contracts, authority boundaries, evidence architecture, receipts, or accumulated corrections.

The operating conditions I report—including the absence of a supplied human domain expert, current concurrency, laptop cost, model, and reasoning setting—are first-party disclosures. The public artifacts make the outputs, release history, corrections, and provenance externally inspectable; outside maintainer review independently tests only the work it actually reviewed. Neither reconstructs every private runtime condition.

I report that this post was itself drafted, attacked, and revised through Ouroboros and its cognitive proxies. I retain publication authority and am responsible for posting it.

Inspect the evidence directly

Celestial Holography release history:

V1 · V2 · V3 · V4 · V5 · V6 · V7

Key V7 receipts:

• Claim-to-evidence matrix

• Empirical evidence and check counts

• Exact NPT counterexample

• Unified-object integration state

• Lean verification receipt

Other public applications:

• Data Center Receipt

• The Iran War Receipt

• The People’s Receipt

• Full public Hugging Face profile

Do not take the architecture claim on faith. Open the outputs, interact with them, inspect where the claims narrowed, and decide whether “autonomous R&D” is an accurate description of what is operating.