HackerTrans
TopNewTrendsCommentsPastAskShowJobs

twoelf

no profile record

Submissions

Ask HN: Is it still worth making "Huge" Language Models for dev tools?

2 points·by twoelf·3 mesi fa·1 comments

Ask HN: Is it just me?

18 points·by twoelf·3 mesi fa·33 comments

[untitled]

1 points·by twoelf·4 mesi fa·0 comments

[untitled]

1 points·by twoelf·4 mesi fa·0 comments

[untitled]

1 points·by twoelf·4 mesi fa·0 comments

Monocod

1 points·by twoelf·4 mesi fa·5 comments

No LLM, No training data, No cloud – Engine that understands architecture

2 points·by twoelf·5 mesi fa·2 comments

comments

twoelf
·3 mesi fa·discuss
Yes, it does help, when you know exactly what it needs to be doing, then you can see the truth.
twoelf
·3 mesi fa·discuss
https://x.com/twoelf47/status/2038633678277107986
twoelf
·3 mesi fa·discuss
https://x.com/twoelf47/status/2038633678277107986
twoelf
·3 mesi fa·discuss
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.
twoelf
·3 mesi fa·discuss
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.
twoelf
·3 mesi fa·discuss
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.
twoelf
·3 mesi fa·discuss
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.
twoelf
·3 mesi fa·discuss
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.
twoelf
·3 mesi fa·discuss
[dead]
twoelf
·3 mesi fa·discuss
[dead]
twoelf
·3 mesi fa·discuss
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.
twoelf
·3 mesi fa·discuss
Yeah. Sometimes we have to finish ourselves. The vibe gets you started, but it rarely gets you all the way there.
twoelf
·3 mesi fa·discuss
[dead]
twoelf
·3 mesi fa·discuss
Yeah, but humans can learn, remember, and usually don’t hallucinate. They get better over time on a specific codebase, framework, and system.
twoelf
·4 mesi fa·discuss
https://x.com/twoelf47 , follow for updates
twoelf
·4 mesi fa·discuss
Okay
twoelf
·4 mesi fa·discuss
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.
twoelf
·5 mesi fa·discuss
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.