"Si tacuisses, philosophus mansisses."
Sounds rich coming from you guys who wanna gatekeep technology as though it's in your basement!
XF Internal Linker V2 - The Vibe Coding journey begins!
- Thread starter new_view
- Start date
Sounds rich coming from you guys who wanna gatekeep technology as though it's in your basement!
Pretty much yes, rather be arrogant than be bullied.
Oh, look, someone has resorted to strong language.
Oh, wow, lmao.
You know Claude is smarter than you, right, in many domains? Oh, even smarter than I could accomplish in a lifetime, including YOU!
Check this out: you think, I just type "Hey Claude, build an app in 3 hours", that's it, done. I am not that stupid, lmao, or maybe you are stupid to think so. Get a grip; if you don't like my thread, you can create yours...
Tell you what, mate, me and buddies - Claude, Codex, and Antigravity - we have some cool vibes to do, further mathematics with Wolfram Mathematica.
Well, you are not using it to the best of its abilities or tools.
SKILL ISSUE. You ain't got the vibes.
maybe efficient in the sense it saves time, but as folks pointed out in another thread - there's a lot of bugs and security holes in addons being made by AI.
I would personally ban them from the forum or have a very strict addon inspection process by the owners here, because one vulnerability by a poorly coded addon, especially with AI, could wreck havoc on someone's project.
I did a few plugins for WP with GPT and it was a complete mess. Not only did it constantly make mistakes and shut an entire website down, but it followed up with bad fixes. It may get things to a functional state, but that doesn't mean it's safe to use, so proceed with a LOT of caution here.
Learn about Claude tools.
Agreed, still, a skill issue.
Codex requires patience, especially xhigh, unless you have fast mode and Pro or above.
I fire up my bots on Max and xhigh, let them argue back and forth... while I just laugh it off. Such is life.
Agreed, still, a skill issue.
Codex requires patience, especially xhigh, unless you have fast mode and Pro or above.
I fire up my bots on Max and xhigh, let them argue back and forth... while I just laugh it off. Such is life.
Welcome to the new school; class is in session.
to be fair, smart phones and social media were pretty much the worst inventions.
the internet peaked at myspace and AOL... getting us online, all day on the phones, from anywhere was just baddddddd.
True, I ain't got the vibes. So use your skills and keep guessing around. People like you contribute to my job security. So master your skills and vibe on and on!
So I figured you have negative vibes.
Also, I don't need you; your services mean nothing to me.
You just came to my thread to be a smartass and a hater.
I agree. But think about the dystopia this AI stuff is going to create in the next 50 years. Every piece of content eventually is going to be 90% AI generated, and it’s just really depressing to me. I don’t enjoy talking to or reading messages from bots when I am online.
you're 100% right. everything produced by AI will be lifeless garbage never worth reading.
One of my latest inventions. I call it "AutoIssues." It fixes all the stuff luddites were whining about.
An AutoIssue means a saved work item in the app’s database. The system uses AutoIssues to track problems, follow-up work, failed checks, and lessons from previous fixes.
The system creates AutoIssues from many places. An agent can file one when it finds a bug or a bad practice. App error tools can file one when the product crashes or logs a serious warning. Speed tools can file one when they find a slow area. Test tools can file one when they find weak tests. GitHub check runs, which are the automatic checks that run after code changes, can file one when they fail.
Each AutoIssue keeps the important facts in one place: what went wrong, where it happened, how serious it looks, what source reported it, and whether someone has fixed it. When the same problem appears again, the system tries to update the existing issue instead of creating a pile of copies.
At the start of a work session, the agent must read the open AutoIssues. The system sorts them by importance and picks a required batch from each source. That rule forces agents to fix real stored problems before they move on to new work.
When an agent fixes an AutoIssue, the agent must record a lesson. The lesson has two parts: the trap, which says what was easy to miss, and the fix shape, which says what kind of change solved it. Future agents read those lessons before changing the same area, so they do not repeat the same mistake.
AutoIssues also connect to commit checks. A commit means saving a code change into the project history. Before a commit can finish, the repo checks that the required AutoIssues were truly fixed, not just mentioned in chat. The database must show that the issue is resolved, has a resolve time, and includes the lesson.
Given a problem appears, when the system records it as an AutoIssue, then future agents can find it, fix it, and leave a useful lesson behind.
An AutoIssue means a saved work item in the app’s database. The system uses AutoIssues to track problems, follow-up work, failed checks, and lessons from previous fixes.
The system creates AutoIssues from many places. An agent can file one when it finds a bug or a bad practice. App error tools can file one when the product crashes or logs a serious warning. Speed tools can file one when they find a slow area. Test tools can file one when they find weak tests. GitHub check runs, which are the automatic checks that run after code changes, can file one when they fail.
Each AutoIssue keeps the important facts in one place: what went wrong, where it happened, how serious it looks, what source reported it, and whether someone has fixed it. When the same problem appears again, the system tries to update the existing issue instead of creating a pile of copies.
At the start of a work session, the agent must read the open AutoIssues. The system sorts them by importance and picks a required batch from each source. That rule forces agents to fix real stored problems before they move on to new work.
When an agent fixes an AutoIssue, the agent must record a lesson. The lesson has two parts: the trap, which says what was easy to miss, and the fix shape, which says what kind of change solved it. Future agents read those lessons before changing the same area, so they do not repeat the same mistake.
AutoIssues also connect to commit checks. A commit means saving a code change into the project history. Before a commit can finish, the repo checks that the required AutoIssues were truly fixed, not just mentioned in chat. The database must show that the issue is resolved, has a resolve time, and includes the lesson.
Given a problem appears, when the system records it as an AutoIssue, then future agents can find it, fix it, and leave a useful lesson behind.
Markdown (GitHub flavored):
**Core Shape**
AutoIssues uses Django, which is the Python backend framework. The central table is `AutoIssue` in [models.py]. It stores `source`, `external_id`, `fingerprint`, `canonical_fingerprint`, `title`, `description`, `affected_files`, `severity`, `status`, `priority_score`, and `lessons_learned`.
The architecture uses Python as the control layer. Python reads tools, validates inputs, writes database rows, and runs commit checks. Faster compiled code handles heavy math or strict decision logic.
**Python Commands**
The command layer sits in `backend/apps/auto_issues/management/commands`.
Important commands:
- `print_open_issues`: reads open rows, groups them by source, sorts by `priority_score`, and prints the session-start marker.
- `file_hook_finding`: creates or updates one `source="agent"` AutoIssue when a hook finds a problem.
- `file_mutation_survivors`: reads mutation-test reports. Mutation testing means a tool changes code on purpose and checks whether tests catch it. Survivors become `source="mutation"` AutoIssues.
- `resolve_autoissue`: closes rows only when the agent supplies `Trap:` and `Fix shape:` lessons.
- `verify_autoissue_quota`: proves the session fixed the required issue count before commit.
- `cluster_autoissues`: reads open issues, creates feature hashes, calls the clustering service, and writes proposed cluster assignments only when `--apply` is used.
**Deduping**
`services/fingerprinting.py` creates a canonical fingerprint. That means a stable short hash for the same root problem across sources. `services/dedup.py` uses that hash to update one row instead of creating repeats. It stores source repeats in `source_observations`.
**C++ Stuff**
Python imports these modules through `pybind11`, which is the bridge that exposes C++ functions as Python modules.
Relevant native modules:
- `scoring.cpp`: batch score math.
- `papertrail_dedup.cpp`: MinHash plus locality-sensitive hashing. MinHash estimates text overlap; locality-sensitive hashing finds likely matches without comparing every pair.
- `lesson_index.cpp`: fast in-memory indexes for lesson lookup and cached proof data.
- `counting_bloom.cpp` / `compressed_bloom.cpp`: Bloom filters, which quickly answer “have we probably seen this before?”
- `count_min_sketch.cpp`: compact counting for repeated things.
The “C++ daily AutoIssue picker” is not live code yet. Its spec says C++ should eventually parse heavy profile data, score candidates, select the top issues, then return results to Python.
**Haskell Stuff**
Cabal, the Haskell build tool, defines two executables:
- `findbugs-haskell`: reads facts and outputs confirmed bug findings.
- `findbugs-cluster`: reads graph edges and groups related issues.
`FindBugs.Clustering` uses union-find, which groups connected nodes efficiently. It takes issue-pair similarities, applies a threshold, and returns clusters. Haskell owns the strict decision logic: “which items belong together?” Python owns database writes.
**Quality / AutoIssue Bridge**
`scripts/turbo_mutation.py` runs mutation tools for Python, C++, Go, Rust, TypeScript, and Haskell. It spreads eligible compiled-language work across helper machines, collects reports, then calls `manage.py file_mutation_survivors`. That turns weak-test findings into real AutoIssues.Attachments
Lesson learned.
Commits are taking too long because of the hard blocking of AutoIssues stuff; basically, the quota was 40, meaning, for example, if Claude/Codex wrote garbage code, it would get blocked until they (i.e., LLMs) fix it themselves automatically (more like a self-review). The quota comes from an observability stack like GlitchTip, SonarQube, Pyroscope, Faro, Tempo, Loki, and agents themselves, including other custom-made Rust stuff that is sent automatically to AutoIssues, meaning I don't have to do jack nothing lmao; it's fully automated.
For example, I don't have to open something like Sentry; I don't have to read logs; all I have to do is look at a dashboard and address severe bugs up close and personal. The next evolution is making the agents discuss with each other nightly with scheduled tasks while I sleep. When I wake up in the morning, I read the summary like a boss and the consensus to approve.
That being said, why would a commit get blocked? Well, because of pre-commit hooks, the generated code has to go through many quality tests, e.g., mutations, unit tests, randomized tests, security tests, linting, and among other dozen things. Seems like the AutoIssues system works as designed, and it's okay but quite slow in terms of development velocity -- not a good way to do things -- so I thought of making the hard-blockers upon commit turn them to soft-blockers/warnings, then making them hard-block as pre-push hooks. Pretty neat, maybe.
Anyway, good thing is, I don't have to read a single line of code; I don't have to touch the command line, IDEs make me nauseous, I don't have to babysit anyone, i.e., Claude, Codex, or Gemini. I have noticed, though, Claude Opus Ultracode with its own subagents alongside Gemini 3.1 Pro invoked via PowerShell and as part of Claude's Workflow, ready to rock, is a force to reckon with, mate. In a nutshell, you can make Claude Code control AGY CLI as a worker agent (should have noticed this earlier; anyway, it's fine, you live and learn). You can also make Claude control AGY review Claude's written code. Note: AGY = Antigravity CLI.
Otherwise, the next step is Kubernetes with Google's Bazel; this sounds interesting. People say Bazel is complicated; there is only one way to find out. Maybe mess around and find out.
Once K8s and Bazel stuff plus other automated AWS + GCP stuff is out of the way, the major leap forward is Wolfram Engine and MATLAB, the fun part: mathematics, golden fixtures, and reranking.
After that, the next major update is "Deterministic Code Validation Engine for AI-Assisted Vibe Coding." That would require 5 million lines of code; It will be written in Rust. The good thing is Claude Opus approved the plan with a score of 97/100. Initially the Claude rejected the plan. Claude said your plan is nonsense, but after refinements the score was 97%; my personal advice for vibe coders is to tell Claude to be absolutely brutal and discard your garbage ideas until you revise your plan over and over again while it grills you with no mercy.
This will take many weeks; anyway, Claude will create dozens upon dozens of plans from each masterplan's section using this prompt:
Still have to decide whether the DCVE for AI-Assisted Vibe Coding goes first because the Rust Ranking Decision Engine requires 10 million cases- yep, you read that right, 10 million cases.
It reaches 10 million by counting verified ranking cases, not by writing 10 million lines of code for Rust, although the DCVE for AI-Assisted Vibe Coding will have a minimum of 5 million lines of code (it's just too complicated to describe it in a few words, but to get a sense of it, it's a
deterministic validation firewall) and an SDK to add any local LLM or paid API to help crunch numbers or flag out garbage theorems.
The Rust Ranking Decision Engine stays small and strict. The scale lives in a verification factory:
Then connect XF to the local App and crawl the web as though I am Google; nah, just kidding - you'd need datacenters - but on a serious note, the app needs tonnes and terabytes of data; this is why crawling the web makes senses, 100 terabytes is a good starting point, but still no cigar, 10 petabyte, that can move the needle while stripping garbage boilerplate will make the app learn, and the custom ranking weights, meta-algorithms, will move in real-time mirroring Google's Search Engine Updates. Well, sounds like a plan?
Commits are taking too long because of the hard blocking of AutoIssues stuff; basically, the quota was 40, meaning, for example, if Claude/Codex wrote garbage code, it would get blocked until they (i.e., LLMs) fix it themselves automatically (more like a self-review). The quota comes from an observability stack like GlitchTip, SonarQube, Pyroscope, Faro, Tempo, Loki, and agents themselves, including other custom-made Rust stuff that is sent automatically to AutoIssues, meaning I don't have to do jack nothing lmao; it's fully automated.
For example, I don't have to open something like Sentry; I don't have to read logs; all I have to do is look at a dashboard and address severe bugs up close and personal. The next evolution is making the agents discuss with each other nightly with scheduled tasks while I sleep. When I wake up in the morning, I read the summary like a boss and the consensus to approve.
That being said, why would a commit get blocked? Well, because of pre-commit hooks, the generated code has to go through many quality tests, e.g., mutations, unit tests, randomized tests, security tests, linting, and among other dozen things. Seems like the AutoIssues system works as designed, and it's okay but quite slow in terms of development velocity -- not a good way to do things -- so I thought of making the hard-blockers upon commit turn them to soft-blockers/warnings, then making them hard-block as pre-push hooks. Pretty neat, maybe.
Anyway, good thing is, I don't have to read a single line of code; I don't have to touch the command line, IDEs make me nauseous, I don't have to babysit anyone, i.e., Claude, Codex, or Gemini. I have noticed, though, Claude Opus Ultracode with its own subagents alongside Gemini 3.1 Pro invoked via PowerShell and as part of Claude's Workflow, ready to rock, is a force to reckon with, mate. In a nutshell, you can make Claude Code control AGY CLI as a worker agent (should have noticed this earlier; anyway, it's fine, you live and learn). You can also make Claude control AGY review Claude's written code. Note: AGY = Antigravity CLI.
Otherwise, the next step is Kubernetes with Google's Bazel; this sounds interesting. People say Bazel is complicated; there is only one way to find out. Maybe mess around and find out.
Once K8s and Bazel stuff plus other automated AWS + GCP stuff is out of the way, the major leap forward is Wolfram Engine and MATLAB, the fun part: mathematics, golden fixtures, and reranking.
After that, the next major update is "Deterministic Code Validation Engine for AI-Assisted Vibe Coding." That would require 5 million lines of code; It will be written in Rust. The good thing is Claude Opus approved the plan with a score of 97/100. Initially the Claude rejected the plan. Claude said your plan is nonsense, but after refinements the score was 97%; my personal advice for vibe coders is to tell Claude to be absolutely brutal and discard your garbage ideas until you revise your plan over and over again while it grills you with no mercy.
This will take many weeks; anyway, Claude will create dozens upon dozens of plans from each masterplan's section using this prompt:
Rich (BB code):
The plan should have slices; each slice should be self-contained to make it easy to copy and paste when vibe coding with LLMs, so that these things can be built in a clean, meticulous manner. Each slice must have a goal, clear boundaries, an ADR, a PRD, expected files to be created or modified, requirements, specs (patents or academic papers), test cases written in BDD style, edge cases, reusable libraries or new libraries for speed and quality to look out for, memory management, CPU management, disk management, parallel processing, and helper pcs support. The implementation stage should use TDD, KISS, and DRY, while adhering to what the specs say and addressing the test cases and edge cases. Unit tests must be conducted, along with static analysis and linting. Finally, every slice should end with a mandatory code review. With these questions answered and solved -- does the code match the specs; are errors handled properly? No spaghetti code, no verbose, useless, overengineered code. Slices should be comprehensive, and there should be dozens of them covering everything from start to finish, leaving no stone unturned and no room for error.Still have to decide whether the DCVE for AI-Assisted Vibe Coding goes first because the Rust Ranking Decision Engine requires 10 million cases- yep, you read that right, 10 million cases.
It reaches 10 million by counting verified ranking cases, not by writing 10 million lines of code for Rust, although the DCVE for AI-Assisted Vibe Coding will have a minimum of 5 million lines of code (it's just too complicated to describe it in a few words, but to get a sense of it, it's a
deterministic validation firewall) and an SDK to add any local LLM or paid API to help crunch numbers or flag out garbage theorems.
The Rust Ranking Decision Engine stays small and strict. The scale lives in a verification factory:
- Generate cases
- normal candidates
- missing feature values
- duplicate links
- extreme scores
- zero/near-zero weights
- stale data
- profile changes
- memory-limit cases
- top-N ordering cases
- real regression cases from past runs
- Ask Wolfram for trusted math answers
- Use wolframscript.exe for batch fixture generation.
- Wolfram computes expected score math, normalization, ordering checks, monotonicity checks, and edge-case results.
- It writes compressed fixture files, for example batches of jsonl.zst.
- Wolfram is never called by live production ranking.
- Rust streams the cases
- Rust reads a small chunk at a time.
- It scores candidates.
- It compares Rust output against the expected Wolfram output.
- It drops the chunk and moves on.
- This keeps memory under the 2 GB cap.
- Shard across machines
- Small checks run on normal commits.
- Bigger checks run on Dell through the repo’s turbo path.
- Release/nightly checks run the full 10 million.
- Each shard reports: cases tested, failures, seed range, fixture checksum, Rust version, Wolfram version.
Then connect XF to the local App and crawl the web as though I am Google; nah, just kidding - you'd need datacenters - but on a serious note, the app needs tonnes and terabytes of data; this is why crawling the web makes senses, 100 terabytes is a good starting point, but still no cigar, 10 petabyte, that can move the needle while stripping garbage boilerplate will make the app learn, and the custom ranking weights, meta-algorithms, will move in real-time mirroring Google's Search Engine Updates. Well, sounds like a plan?
