twoelf

Yes, it does help, when you know exactly what it needs to be doing, then you can see the truth.

I've laid the groundwork to do this locally, but the current crop of LLM agents just can't close the loop. Trying to get them to finish the job inevitably sends me right back into the spiral. Thinking i should do it manually.

Read my other posts too.

Fair. “It understands” is probably the emotional description, not the technical one.

The practical problem is that it can imitate understanding well enough to get a large project moving, then break down right where durable system memory and architectural consistency matter most.

So yes, it’s a tool. The problem is that it’s useful enough that “just don’t use it” is not a real answer, and broken enough that you eventually have to build around the gap.

Okay.But if I need three different framings just to converge on one coherent implementation, I’m still doing architecture recovery by hand. That’s a big part of why I started building something local around the codebase itself.

Yes, this is very close to what I meant. They keep reconstructing the codebase from fragments instead of actually carrying the system forward, so you get re-implementation, duplicates, missing edge cases, and slow architectural drift.

Yes, exactly. That’s why it feels so strange in practice. It can mimic understanding well enough to get you moving, but when the project gets deep enough, you find out it was generating plausibility, not actually holding the system in its context.

Mine goes a bit further than that. It structures the codebase first, feeds that into local agents, and then uses whichever model is on top with actual system context instead of making it guess from prompts.

Yeah. Sometimes we have to finish ourselves. The vibe gets you started, but it rarely gets you all the way there.

Yeah, but humans can learn, remember, and usually don’t hallucinate. They get better over time on a specific codebase, framework, and system.

https://x.com/twoelf47 , follow for updates

Okay

This isn’t a concept. I rebuilt what I believe the foundation should be and have it working already. Monocod is a live prototype that understands the codebase itself instead of reconstructing context every time.

Here's Express.js (the npm package, 141 files). Scanned in 551ms on a laptop:

  - 1,953 components extracted
  - 17,505 typed dependencies mapped (not just "A calls B" — ownership, injection, weak ref, circular, etc.)
  - 25 architectural blocks detected automatically
  - 498 architectural smells found
  - 116 dead code detections
  - 100% classification consensus (zero ambiguous)

  Component distribution:
    Core logic:    425 (21.8%) — app, router, route objects
    Terminals:     744 (38.1%) — constants, test assertions
    Helpers:       346 (17.7%) — utility functions
    State stores:  313 (16.0%) — express, request, Router, factories
    Features:      110 (5.6%)  — test-specific app instances
    Middleware:     10 (0.5%)  — andRestrictTo, sendfile
    Entry points:    5 (0.3%)  — users, restrict, getCookie

  Architectural problems detected:
    CRITICAL: 532 components in circular dependency chains
    ERROR: God Class — `app` has 67 outbound dependencies
    ERROR: God Class — `router` has 83 outbound dependencies
    Stateful services at 0% health (critical coupling)

  Cross-cutting concerns found automatically:
    trust proxy logic in request.js (8 components)
    response callback chain: onend, onaborted, onerror, onfinish
    pure functions — 71 components, 93% health
    boundary validators — 98% health

  All of this is known to be true by anyone who's worked on Express.
  The God Object pattern in `app` is a documented community concern.
  The circular deps between app↔router↔request↔response are well-known.

  551ms. No LLM. No cloud. Deterministic — same input, same output, every time.

  Happy to run it against any public repo if you want to suggest one.