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 months ago·1 comments

Ask HN: Is it just me?

18 points·by twoelf·3 months ago·33 comments

[untitled]

1 points·by twoelf·4 months ago·0 comments

[untitled]

1 points·by twoelf·4 months ago·0 comments

[untitled]

1 points·by twoelf·4 months ago·0 comments

Monocod

1 points·by twoelf·4 months ago·5 comments

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

2 points·by twoelf·5 months ago·2 comments

comments

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