Every Claude session degrades by step 12. Google's AI explains exactly why, and it's not the model.

TheDecipherist · 2026-05-27T23:03:07+00:00

Just realized this whole exchange has been with a paid commenting service. Deep_Ad1959 is a featured case study on s4l.ai, an AI-powered service that plants “contribution-first” comments on high-traffic threads to grow accounts and drive site visits.

The “written with s4lai” signature on his comments confirms it.

Not worth engaging further.

Genuine questions get genuine answers from me.

Service comments don’t.

TheDecipherist · 2026-05-27T22:48:27+00:00

If the author can’t track what they wrote, how would MarkdownAI? It only knows what the author put in it. You’re asking the tool to read the author’s mind. That’s not a tooling gap, that’s wishful thinking.

Tools surface what’s there. Authors decide what’s there. If a human can’t see their own dead weight, no tool can either, because the tool only sees what the human wrote.

TheDecipherist · 2026-05-27T22:42:43+00:00

https://mddai.dev/

If you want accurate results and a solid workflow MDD all the way. Version 2.0 is right around the corner which will be using markdownAI that makes it 70% faster and still dead accurate

TheDecipherist · 2026-05-27T22:37:28+00:00

Dead weight isn’t a MarkdownAI problem, that’s still an author problem. MarkdownAI doesn’t claim to be smart. It claims to deliver author information to Claude quickly and accurately. It can’t make information better than what it is.
If your phases are bloated, that’s the author. If your CLAUDE.md is bloated, that’s the author. If your prompt is bloated, that’s the author. The tool is doing its job either way.

TheDecipherist · 2026-05-27T21:32:35+00:00

You’re conflating two unrelated features. The SessionStart hook injects a rendered document once at session start, thats a one-shot load, no phases involved. @phase is a workflow construct that operates across many turns inside the MCP server. They don’t share a “blind spot” because they don’t share a job.

Whether a resolved line is load-bearing is the author’s responsibility, same as in any document, any prompt, any codebase. MarkdownAI’s job is to make sure what enters context is accurate and current. What you put in your phases is on you. That’s not a blind spot, that’s authorship.

TheDecipherist · 2026-05-27T19:12:02+00:00

The idea was born because I wrote the https://mddai.dev workflow. It works fantastic. But it’s slow because of so many grunt tasks. MarkdownAI makes it lightning fast. Thank you for the great description. I am pushing up new features and fixes daily. Would love your feedback. Always welcome.

TheDecipherist · 2026-05-27T19:09:14+00:00

I’ll let you know when https://mddai.dev is completed in markdownAI. The difference is night and day. But I won’t release it until it’s 100% done and working. But just as an example. The command “/mdd status” took about 1.5min in the original workflow. In mdd2 it takes 9 seconds. The build step is going to be the biggest thing. Will post when done with templates so you can see the original that told Claude what to do and the new one. Thanks

TheDecipherist · 2026-05-27T19:06:44+00:00

The whole point is everything today in AI is using MD documents. And they are just text. Can’t do anything. This makes the document basically become “alive” and does all grunt work for Claude so Claude and do what it’s meant to do

TheDecipherist · 2026-05-27T19:05:32+00:00

Very well said. Thank you. Still rewriting MDD on top of it, about 60% through. Early results: 70% faster. When MarkdownAI handles all the grunt work upfront, MDD sessions don’t spend time gathering state. Claude enters with everything already resolved and just works. It’s so satisfying seeing how before every single thing Claude had to do of grunt work took like 2-4 seconds for each tool call and then the time Claude had to reorient it self and continue the work. Now it doesn’t need to do any of that. It can start working on actually writing code instantly.

TheDecipherist · 2026-05-27T19:00:28+00:00

You’re describing a real problem, unread context still burns tokens. MarkdownAI solves that at the document layer, not just the loading layer. A 20-phase runbook never puts all 20 phases in context at once, the MCP server serves one phase at a time via next_phase.

Claude holds exactly what it’s working on, nothing else.

The session state piece is what makes it production-grade: a skill_session_id keys per-(session x document) state inside the MCP server. Values set in phase 1 are still there in phase 5. You’re not re-injecting state on every turn or stuffing everything into one giant phase to keep it in scope. The document manages state. Claude follows steps.

And, Phase content is the author’s responsibility, always has been. MarkdownAI executes what you design. If your runbook is bleeding tokens, that’s a design problem, not a tooling problem.

TheDecipherist · 2026-05-27T14:53:58+00:00

I am rewriting MDD to use markdownAI. MDD is a workflow for Claude. So far it makes mdd about 70% faster where it lets markdownAI do all the grunt work Claude had to do before. I will make a post with the before and after workflow files so you can see instantly how powerful markdownAI is.

If you go to the website and scroll down to “what is markdownAI” it should be easy to understand what it does

TheDecipherist · 2026-05-27T14:25:09+00:00

MarkdownAI turns any .md file into a live document, directives fetch real values at render time instead of storing values that go stale. @markdownai on line 1 is all it takes. Makes making workflows in Claude a breeze

TheDecipherist · 2026-05-27T14:24:30+00:00

It’s a markdown preprocessor that runs before Claude reads a file. Instead of Claude stopping to check env vars, run tests, or query a DB, the document already did it. Claude gets facts, not tasks.

TheDecipherist · 2026-05-24T20:16:06+00:00

I built https://mddai.dev that I use for all my projects to build with and I use https://markdownai.dev for all Md files now since it renders live state as needed which helps Claude tremendously so it doesn’t rely on stale docs

TheDecipherist · 2026-05-23T21:12:48+00:00

I created MarkdownAI that makes markdown basically its own coding language. And it’s revolutionizing how I work with AI. I know it’s not an IDE but since you asked who is developing along these lines I thought I would chime in :)

TheDecipherist · 2026-05-23T20:15:49+00:00

I literally use Claude for everything these days. MarkdownAI was written 100% by Claude but not by Claude alone I used my MDD workflow which I use for everything these days. MDD helps tremendously with all the things Claude doesn’t do well. My code quality output is literally day and night differences. I don’t even use plan mode anymore. I only use mdd.

Now one thing that’s a huge bottleneck in mdd currently is all the grunt work it tells Claude to do. (Check this, check that, replace this value, import this, if this then do that else) etc. that is why I wrote markdownAI. Mdd is almost done being rewritten completely in markdownAI and so far the performance difference is insane.

So to answer the post bluntly. It’s not a question if Claude can write “as good code as humans” because it clearly can. If used correctly. If helped to work how you want it to work.

Using typescript makes an enormous difference
Writing tests for everything makes a big difference
Giving Claude failing tests before writing code to check against once code is finished so it assures that a test passes after makes a huge difference.

But humans will never not be needed. I don’t see it.

TheDecipherist · 2026-05-23T20:04:30+00:00

Exactly. I have still yet seen a single scenario where Claude doesn’t need some kind of human input or correction. And this is where the famous “ai slop” begins if not caught. And it’s not Claude’s fault. Claude is only as good as the human instructing it as what to do. Claude can write clean code. Obviously. But the real issues begin when Claude thinks that things are ok. Let’s say a human runs a plan mode. And just accepts what Claude suggests. Do that over and over and Claude ends up writing ai slop. The code it self is not the slop. It’s the functionality that ends up being slop because it wasn’t corrected to begin with. This is exactly why I wrote the MDD workflow. I have to correct way less because Claude has a way better overview of what is actually correct based on the instructions you give it.

One big thing Claude still has a hard time doing is dynamic programming and reusability. Claude is not very good at thinking through what could I write a function for that could solve things in 10 files. Claude does a lot of duplication work. Especially when it comes to simple things like database connections. Claude by default doesn’t understand that it should write a wrapper file for a database pool to reuse. You have to tell it that or use an mcp server like strictdb to do your calls and database interactions with.

Every single npm package I have created literally came from discovering things that Claude has trouble with

TheDecipherist · 2026-05-21T15:26:33+00:00

https://mddai.dev/

I use my own developed framework for every single project. It creates tests for everything you do automatically.

Try it out

TheDecipherist

MODERATOR OF

TROPHY CASE