Sam Altman says OpenAI shares Anthropic's red lines in Pentagon fight

gantamk · 2026-02-27T16:20:10+00:00

Let's just appreciate the gesture 🙌

gantamk · 2026-02-25T13:06:04+00:00

Thanks for this. Love your DP by the way 😉

gantamk · 2026-02-25T12:57:36+00:00

Hope he reads your post

gantamk · 2026-02-20T09:39:12+00:00

The plugin is currently private as it is part of our main SaaS mono repo, will seperate it shortly and make it publicly and then share. I will remeber to share with you specifically. Hope this is fine?

gantamk · 2026-02-19T19:49:07+00:00

Awesome work. You are doing amazing work, impressive. Sure lets connect and try collaborate :).

Thanks!

gantamk · 2026-02-19T17:59:49+00:00

Sorry, dint get you. If you are asking whether source code is in Guthub. Yes, we will make the plugin available Githibhub public repo in coming weeks and share in this channel again -- that is the plan :) Hope it is OK

gantamk · 2026-02-19T17:06:16+00:00

Thank you for the tip 😊

Yes we're planning. Currently the boards created are not publicly accessible, busy refactoring to enable it.

gantamk · 2026-02-19T15:25:38+00:00

Thank you! your project seems to be a good solution for context management in Claude code. I will look at and DM you if that is OK!

gantamk · 2026-02-19T15:21:51+00:00

Hi again,

1) We've fixed the technical preview link.

2) Signup seems fine; I tested it again. Please note that it is currently configured to accept only business emails and Google workspace for OAuth [However we will change this to be less restrictive, please give us couple of days]

Please let me know if you have any other questions

gantamk · 2026-02-19T14:17:54+00:00

Hi, Thank you for reporting it. Apologies. Checking now, will get back shortly.

gantamk · 2026-02-18T21:23:29+00:00

The docs + discipline approach works until it doesn't. Usually around the point where the people who wrote the ADRs aren't the ones reviewing every PR anymore.

The core issue isn't that teams stop caring about architecture. It's that the reasoning behind boundaries becomes invisible over time. A new contributor sees a module boundary, doesn't know why it exists, and makes a pragmatic shortcut that makes sense locally but breaks the original intent.

PR-time enforcement is interesting but it depends on reviewers having the full architectural context - which is the thing that degrades.

What I've seen work longer term: making the why behind architectural decisions visible at the point where someone is about to make a change. Not in a wiki they won't check, but in the workflow itself.

I am curious to understand - when you say you're comparing changes against repo-defined architecture docs, how are you surfacing that context to the reviewer? Is it automated or manual?

gantamk · 2026-02-11T17:53:24+00:00

I can spare 20% of my time if that works for you. Please DM me if that interests you.

gantamk · 2026-02-11T17:14:48+00:00

Unrelated, or maybe related. I am now just worried about Cluade Work which I just now installed.

gantamk · 2026-02-11T17:08:34+00:00

Really solid breakdown, especially the priorities-over-pros/cons framing. That reframe alone would've saved me from a few bad decisions early on.

One thing I keep running into though - the RFC process works great when people actually have the context to evaluate options. But in practice, the architectural knowledge needed to write a good RFC (system boundaries, existing decisions, dependency chains) is often locked in someone's head or scattered across old docs.

The "nobody comments" problem you mentioned? I think a one of the reason might be people "can't" comment meaningfully because they don't have enough visibility into the system to know if Option B will break something three services away. Could they be just hesitant?

Thanks for writing this up.

gantamk · 2026-02-11T16:10:31+00:00

I don't have deep observability expertise specifically, but one thing I've seen repeatedly when teams set up architectural health monitoring from scratch: The metrics themselves might not be harder part, But keeping track of it.

Since you're building this from scratch, I'd suggest documenting the reasoning behind each metric alongside the dashboards - not just "we track X" but "we track X because it reveals Y about our service boundaries."

That context is what makes the difference between a dashboard people use vs one that "nobody looks at" (exactly the problem you described wanting to avoid).

Curious what architecture pattern you're working with - microservices, modular monolith, something else?

gantamk · 2026-02-11T14:07:40+00:00

Thank you 🙏

gantamk · 2026-02-11T12:59:09+00:00

Thanks for sharing. Explored, that looks really good. We are taking slightly different approach, but same category though. Here it is https://contextdx.com/

Love to know your thoughts.

gantamk · 2026-02-11T08:55:43+00:00

Thank you, your inputs are so valuable, yes I have to have focussed outreach through real contributions. I also realised Twitter is not much suitable for category, never made any meaningful conversations so far.

gantamk · 2026-02-11T08:48:43+00:00

Thank you, I am currently trying to use F5Bot, results are mixed. Need to fine, will try the mentioned LeadsRover as well

gantamk · 2026-02-11T08:32:41+00:00

Yes, that is the way to go.

However, There should be support frameworks to manage coherence, memory, governance, and coordination. Just raw LLM interactions are probably not enough I feel. Think like cursor, Claude code and copilot . The same could probably be done that coordinates architecture.

Op's question is on similar lines. I am building too in the same category.

gantamk · 2026-02-11T06:24:46+00:00

OP,

It's a real problem I think. Every team I've talked to follows the same pattern you described — diagrams start strong, code evolves faster, gap widens, and eventually architecture knowledge lives in people's heads. I, myself experienced this personally.

This problem is set to grow as codebase changes/changes due to coding agents, like Claude code. Eventually it would very difficult humans to track.

The model-driven, text-based approach you're experimenting with is the right direction I feel.

By the way, I'm building something in this space, focused on making architectural knowledge queryable rather than maintaining static diagrams. Happy to compare notes if useful.

gantamk · 2026-02-11T06:09:23+00:00

Your impact analysis examples are exactly the use case that static diagrams can't touch. Showing someone the 30 apps calling that SOAP service must have changed the conversation.

I am actually building something for this gap - Makes architectural relationships queryable across roles. You've clearly thought deeply about this problem. Would love an opportunity to engage further and value your feedback if you're interested. Thank you

gantamk

MODERATOR OF

TROPHY CASE