Documentation debt happens when docs and code are decoupled. One fix is to make specs stateful artifacts
with change detection. In Shadowbook (disclosure: I built it), specs are files with hashes; when a spec changes, linked issues get flagged and can’t be closed until someone acknowledges the drift. That creates a feedback loop between docs and implementation without “vibe documenting.” It doesn’t solve everything, but it makes contradictions visible and forces a review gate when context shifts.
I have been thinking of something similar for quite some time. Though my idea was more like making comments "first class citizens", and in certain formats they can link to each other/external documents, tracking inconsistent changes.
This might also extend to runtime checks (e.g. some business invariant in the form of an assert that has such a "dependency-tracked" comment)
i would like to see a mobile app for this to vibe code on the fly. currently the DIY options are good but clumsy UX wise as they’re workarounds. if i can open worktrees from an ios app it would be great.
Multiple config files of Xcode projects are not publicly documented as far as I remember and personally I have preferred to require my agents not to modify them out of fear it might break something and be hard to fix. I don't know how agentic programming will work in Xcode but I would expect it to do it using a safer approach, so that's also another case where it might have an advantage.
Your workflow looks very interesting especially the describe_ui part, are you already able to do this today?
I've been using tuist plus codex cli and vscode. only using Xcode for running and debugging. I would love to get rid of xcode entirely. The tuist plus xcode project is a tiny shim - the rest of the app is in spm packages.
Tuist generates the code project from a simple swift confiuration file similar to Package.swift. I don't know why apple can't just throw away the proprietary and ugly Xcode project files and provide a sane build system that would work in any IDE, on the command line, in CI and now with AI agents.
They could open up the instruments format while they are at it for the same reason, do they really gain anything by making it proprietary?
I still open Xcode for every branch after having Claude do an initial implementation, to review the changes using its version editor, step through code using the IDE’s various code navigation features, and build/run to manually validate the changes. I do have claude analyze and test, though.
> If you want a clean comparison, I’d test three conditions under equal context budgets: (A) monolithic
> AGENTS.md, (B) README index that links to docs, (C) skills with progressive disclosure. Measure task
> success, latency, and doc‑fetch count across 10–20 repo tasks. My hunch: (B)≈(C) on quality, but (C)
> wins on token efficiency when the index is strong. Also, format alone isn’t magic—skills that reference
> real tools/assets via the backing MCP are qualitatively different from docs‑only skills, so I’d
> separate those in the comparison. Have you seen any benchmarks that control for discovery overhead?
This solves distribution well. Curious about the change propagation story though - what happens when you update your .ai/ source and tools have cached/transformed versions?
I ran into this building a spec/skill sync system [1] - the "sync once" model breaks down when you need to track whether downstream consumers are aware of upstream changes.
For files that don't need transformation (AGENTS.md, skills, most rules), LNAI creates symlinks. .claude/CLAUDE.md → ../.ai/AGENTS.md. Edit the source, all tools see it immediately.
For transformed files (Cursor's .mdc frontmatter, GEMINI.md sub-directory rules), you re-run lnai sync. LNAI maintains a manifest tracking of every generated file with content hashes, so it knows what changed and cleans up orphans automatically.
So it's not really "sync once", it's "symlink for instant propagation, regenerate-on-demand for transforms." The manifest ensures LNAI always knows its downstream state.
This system can also break down if you create new skills/rules in the specific tool directories (.claude, .codex, etc.) but that is against LNAI's philosophy. If you need per-tool overrides you put them in `.ai/.{claude/codex/etc.}` sub-directories and LNAI manages them for you.
The "natural overthinking increases incoherence" finding matches my daily experience with Claude.
I maintain ~100 custom skills (specialized prompts). Sometimes Claude reads a skill, understands it, then overthinks itself into "helpful" variations that break the workflow.
Has anyone else found prompt density affects coherence?
Following up - I built a tool "wobble"[1] to measure this: parses ~/.claude/projects/*.jsonl session transcripts,
extracts skill invocations + actual commands executed, calculates Bias/Variance per the paper's formula.
Ran it on my sessions.
Result: none of skills scored STABLE. The structural predictors of high variance: Numbered steps without clear default, Options without (default) marker, Content >4k chars (overthinking zone), Missing constraint language
Not a big use case outside of criminals and refugees" - the refugee use case alone matters to hundreds of millions living under capital controls or currency collapse. Argentinians escaping peso devaluation aren't criminals. Ukrainians moving value during invasion aren't edge cases.
Whether Bitcoin is good at this is debatable. Whether it's a real use case isn't.
Wow. And just like that fliki.ai and similar products have been sherlocked. Great time to be a creator, not the best time to be a product developer, production designer
reply