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 tháng trước·1 comments

Ask HN: Is it just me?

18 points·by twoelf·3 tháng trước·33 comments

[untitled]

1 points·by twoelf·4 tháng trước·0 comments

[untitled]

1 points·by twoelf·4 tháng trước·0 comments

[untitled]

1 points·by twoelf·4 tháng trước·0 comments

Monocod

1 points·by twoelf·4 tháng trước·5 comments

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

2 points·by twoelf·5 tháng trước·2 comments

comments

twoelf
·3 tháng trước·discuss
Yes, it does help, when you know exactly what it needs to be doing, then you can see the truth.
twoelf
·3 tháng trước·discuss
https://x.com/twoelf47/status/2038633678277107986
twoelf
·3 tháng trước·discuss
https://x.com/twoelf47/status/2038633678277107986
twoelf
·3 tháng trước·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 tháng trước·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 tháng trước·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 tháng trước·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 tháng trước·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 tháng trước·discuss
[dead]
twoelf
·3 tháng trước·discuss
[dead]
twoelf
·3 tháng trước·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 tháng trước·discuss
Yeah. Sometimes we have to finish ourselves. The vibe gets you started, but it rarely gets you all the way there.
twoelf
·3 tháng trước·discuss
[dead]
twoelf
·3 tháng trước·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 tháng trước·discuss
https://x.com/twoelf47 , follow for updates
twoelf
·4 tháng trước·discuss
Okay
twoelf
·4 tháng trước·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 tháng trước·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.