Most vibe-coded projects fail because the person building them hasn't actually felt the pain of what they're building at scale.
You can vibe-code a chat app in 20 minutes because you've used chat apps for years and you know instinctively when something feels wrong but you've probably never watched your app crash under real users and had no idea where to even start looking as AI can only build what you already understand well enough to ask for.
Markdown works because one person owns the whole picture. The moment you add a second client, that assumption collapses.
You're not choosing between markdown and a database. You're discovering that markdown was always a database just one held together by a single person's understanding. The moment no single person owns the full picture, markdown stops being a feature and starts being a liability.
The answer to your questions database for isolation and access control, markdown for the human-readable layer that people actually need to read and edit. Keep the legibility. Drop the illusion that legibility scales.
A decade on systems that couldn't fail didn't teach you syntax it taught you consequences. That's rarer than any skill on your resume.
You need harder problems and primary sources not more material. Kleppmann's Designing Data-Intensive Applications if you're going data. Ousterhout's A Philosophy of Software Design if you're going engineering. Then pick one system you respect, read its internals, and form opinions.
The next level of growth doesn't come with a syllabus. You have to construct it yourself. That's not a gap. that's what senior actually means.
Sublime proved that staying true to your vision is necessary but not sufficient. a product that never compromises but also never evolves is indistinguishable, to the world, from one that simply gave up.
Every editor starts with a point of view and ends as a platform. That's the arc. JetBrains, VS Code, even Zed they all started opinionated and gradually got sanded down by feature requests, enterprise needs, and the pressure to grow.
The dissatisfaction you're seeing isn't about missing features. It's about editors that no longer stand for anything.
Your editor is compelling right now because it reflects one person's taste completely. The moment you start building for 'the market' you join the same race everyone else is losing.
Build it but know what you refuse to compromise on before users start asking you to.
When you struggle through a hard problem, you get two things: the answer, and a slightly sharper mind. AI gives you the first and skips the second.
That's fine once. Scaled across an entire generation of knowledge workers, over a decade that's the collapse Acemoglu is worried about.
We're not just outsourcing tasks. We're outsourcing the friction that makes people grow.
The problem isn't finding code. it's inheriting judgment.
New engineers don't struggle to locate files. They struggle to know which files to trust, which patterns are intentional vs accidental, and which senior engineer silently owns what. That's not searchable.
You're building a map. What they need is a compass.
The adage holds, you're just measuring at the wrong timescale.
Fast and cheap is absolutely happening right now. But "correct" in software was never about whether the code runs today it's about whether the system is still understandable, maintainable, and predictable six months from now when requirements change and the person who wrote it is gone.
LLMs are remarkably good at local correctness. A function works. A test passes. But software systems fail at the joints the places where assumptions from different parts of the codebase meet. That's where models break down, and that's precisely where LLMs are weakest, because they have no persistent model of your system's evolution over time.
The triangle didn't disappear. It just got a time dimension added to it. Fast, cheap, correct right now maybe. Fast, cheap, correct over time still pick two.
The competing feedback loops point is the one that stuck with me. AI doesn't resolve the tension between stability and growth it just gives both sides more firepower. The negotiation stays just as hard.
Your "100 teenagers" framing is good but I'd push it further it's 100 teenagers each with a confident senior engineer in their ear. Which is worse, because it kills the self-doubt that makes juniors ask questions.
No single paper nails that exact claim. SWE-bench Princeton does show that models struggle significantly with real-world issues requiring changes across multiple files and functions which points in that direction. But the local vs global framing is mostly practitioner-observed, not a formally tested hypothesis yet. Fair point, I should have hedged it. https://arxiv.org/abs/2310.06770
Code style still matters, but the reason has shifted and that shift is worth being precise about.
The old argument was humans read code, so write for humans. The new reality is LLMs also read code, and they read it differently. They don't get lost in deep nesting the way a junior dev does, but they are surprisingly sensitive to naming ambiguity, inconsistent abstraction levels, and context fragmentation across files. A well-structured codebase gives the model a coherent "world model" to reason within. A spaghetti codebase gives it conflicting signals, and it hallucinates confidently in the gaps.
So the argument for style hasn't disappeared it's been redirected. You're now writing for two audiences the human reviewer and the model that will modify it next.
The part I'd push back on in your framing "the object design is terrible" is not a style issue. That's the part that actually breaks down under AI-assisted development. Models are very good at generating locally coherent code and very bad at maintaining global architectural integrity across iterations. Bad object design doesn't become invisible to LLMs, it compounds. Every subsequent generation inherits and amplifies the structural confusion.
The write-down-where-you-left-off trick is underrated. I think it works because it gives the brain a kind of "closed" signal the open loop that Zeigarnik describes gets a placeholder, so the mind stops simulating. A physical notebook works better than a digital note for this, at least for me. Something about closing an actual object.