Ryan Tsuji

Following up on the AI harness post from last week: here's the heart of it. I redefined our entire dev platform with one premise — built for AI, operated by AI, used by AI. This post is about the knowledge graph that makes that possible. ryantsuji.dev/posts/cortex-p…

"AI changes everything," people keep saying. After building and running an AI platform for our org, my biggest takeaway is the opposite. The principles don't change. Only the machinery does. I wrote up the thinking behind everything I've published so far, from code graphs to AI observability to automated review. ryantsuji.dev/posts/ai-nativ…

Part 2 of the observability series is out, the practice side. The focus is PII, the part whose weight has gone up most in the AI era: hashing it so plain text never enters the stack, letting AI search logs without ever seeing personal data, and driving self-healing on top of that foundation. If Part 1 was about shaping telemetry for AI, this one is about doing it safely. ryantsuji.dev/posts/ai-obser…

Observability Design for the AI Era (Part 1, the design side). "AI era" in the title, but the core question hasn't changed: why you want to measure something, and how you shape it once you do. It's about the design judgments behind that, not a new stack. Four surfaces (app / infra / CI / LLM), each shaped to the question it answers. ryantsuji.dev/posts/ai-obser…

Last week: building a knowledge graph across 46 production repos via static analysis. Without semantic search though, only half-useful. Part 2 is up — how I gave it context. ~50k MCP tool calls / 73 users in 2.5 months, including stylists & support, not just engineers. dev.to/aircloset/maki…

@DorMoshe @SylwiaLask8977 @ThePracticalDev @dzakh_dev @ITNEXT_io @ctrotechDev Thank you for reading my article deeply and sharing!

📰👨‍💻 I just published #Angular #TypeScript Trends #425 dormoshe.io/newsletters/42… @SylwiaLask8977 @thepracticaldev @ryantsuji @dzakh_dev @itnext_io @ctrotechDev @dormoshe #dormosheio #javascript #frontend #webdev

My post made @ThePracticalDev's Top 7 Featured DEV Posts this week 🎉 It's the series finale on the philosophy behind cortex (our internal AI platform) and how I design harnesses around AI rather than trust it. DEV's list: dev.to/devteam/top-7-… Article: dev.to/ryantsuji/ai-i…

46 repos of legacy production code unified into one knowledge graph via static analysis. The static-analysis layer alone wasn't enough — and honestly, building it was hell 😅 If you're stuck somewhere similar, hopefully this helps. ryantsuji.dev/posts/code-gra…

Series Final is out. After six posts on the AI harness I built, the throughline came down to one line: "AI isn't something to trust — it's something to design." ryantsuji.dev/posts/cortex-p…

Part 5 ("The Author Doesn't Have to Be an Engineer") has been generating sharp comments on dev.to: "Standing up a stack is hard, building on top of one isn't." "The harness translates domain taste into checks the system can enforce." "Who lays the rails in ten years?" Worth a read for the thread alone. dev.to/ryantsuji/the-…

Part 5 of the AI harness series is out. Non-engineers (PMOs, business leads) ship PRs straight to the production repo. The harness owns quality. Real PR examples of what actually merges without an engineer touching it. ryantsuji.dev/posts/cortex-n…

@devlucas56 Not sure I follow — what do you mean?

@ryantsuji Hmm structure is overwhelming fr... Are you more focused on scaling users, infrastructure, visibility, or partnerships?

Following up on the AI harness post from last week: here's the heart of it. I redefined our entire dev platform with one premise — built for AI, operated by AI, used by AI. This post is about the knowledge graph that makes that possible. ryantsuji.dev/posts/cortex-p…

@devlucas56 AI reviews PRs, fixes request changes, self-healing, recurrence prevention and enable adding features without engineers. These are series articles. ryantsuji.dev/series/buildin…

@ryantsuji What support system are you Building along with this

It's interesting 20% of the access to my dev.to articles is from chatgpt.

Result: the pattern that caused the incident becomes structurally unwritable from then on. Self-healing fixes symptoms. Self-healing + self-strengthening is what makes the quality gate compound over time.

But "just fix it" doesn't compound. cortex's rule: every fix PR must add one new Guide. - lint rule - CI guard - type constraint - guideline entry Without it, the AI reviewer issues REQUEST_CHANGES — can't merge.

For Part 4 of the AI Harness series I just published: "Fixed Before Anyone Notices, Stronger After Every Fix — Self-Healing + Recurrence Prevention". The pitch is less about the auto-fix part, more about how every fix has to add a new Guide. ryantsuji.dev/posts/cortex-s…

The role shifts from human-in-the-loop to human-on-the-loop. Engineers don't write or review code at this point — they make judgment calls. The review guidelines the AI follows (JP/EN) are open source: github.com/air-closet/cor…

Part 3 of the AI Harness series is up. People say AI-assisted dev hits a review bottleneck and quality drops. In practice we see the opposite: review velocity and quality both go up, but only if the harness extends to the reviewer side too. ryantsuji.dev/posts/cortex-a…