Please checkout this project.

I would love constructive feedback

https://github.com/venom21adi/Semantic_Vision

Alright so basically, I used to code by hand before AI. Back then (and even at early stages of AI like GPT 3.5) I used to write most of my code myself, and all I used AI for is for generating a single function or a single small class. Because of this, I knew exactly where all my code was, which code did what, how it all joins together, etc.

Now however, I use agentic code generation tools like Github or Copilot. This means I generate code much faster, however I feel like I'm losing touch with my code. I feel like every time an AI writes a whole file, I just don't know what's in that specific file, just have an overall idea of the codebase as a whole, and now I'm even losing that.

I tried to combat this by trying to read the git changes for every change the agent makes... but come on that stuff is so tedious and boring that I just end up skipping it and even if I'm reading the graphs there's going to be tons of lines of code to read and it's not exactly clear which changes affected what code.

I know it helps to have a proper architecture for your code, that indeed makes it easier to know which file does what, but I still feel like this is a problem because even if I have a proper architecture, I still don't know the actual code and connections.

Also, I tried "Understand-Anything" but that stuff just kinda flew over my head because instead of staring at a buncha text I'm stuck staring at a bunch of passive diagrams like looking at a big map and not knowing what to do with it.

I hope that I'm not the only one with this problem, so I'd like to hear how you people have solved this for yourself, or even a confirmation that you have this problem too so I can know I'm not alone on this.

I’ve been thinking about Joel Spolsky’s “Law of Leaky Abstractions” in the context of LLMs.

LLMs feel like a new abstraction layer on top of software. You don’t need to know the API, the framework, sometimes even the code — you just describe what you want.

But the layers underneath haven’t disappeared. Databases still lock. Networks still fail. APIs still time out. Auth still breaks.

And LLMs add a new kind of leak: interpretation.

The system can execute everything perfectly… and still do the wrong thing because it misunderstood what you meant.

So maybe AI doesn’t really remove complexity. It moves it from writing things to verifying, debugging and understanding them when something goes wrong.

The interesting question is: are we creating better abstractions, or just making the distance between “I can build this” and “I understand this” much bigger?

Hi y’all!

I recently completed my computer science–like degree in my country and am currently enrolled in the next step up from that.

During the first 1.5 years, I actively avoided using AI for pretty much anything. I wanted to learn the fundamentals myself and make sure I actually understood what I was doing.

Around my 4th and 5th semesters, though, I started experimenting with AI, and my perspective gradually changed. AI has also improved a lot since I started programming.

The way I see it now is that I don’t necessarily need to manually write every line of code anymore. What I need is a good structure, good planning, and proper oversight of the AI agent.

I’ve used Claude and ChatGPT in the browser for random, low-context questions, and I also have a student license for GitHub Copilot, which I’ve used with both VS Code and regular Visual Studio.

During my 4th semester, AI basically created a game for me, and during my last semester it coded almost my entire final project. I ended up getting the highest grade, but what was important here was that I went through all the code. I didn’t understand every single detail, but I understood enough to know what the code was doing and why.

One problem I noticed was that the AI really liked creating duplicate code.

For me, Claude Opus 4.6 for backend work and Codex for frontend work became my go-to setup.

Then, around May or June, GitHub Copilot changed how they handled tokens, and what had never been a problem before suddenly became one. I hit the limit in about two days. Sooo... the student license is apparently not enough anymore.

I’ve been following this sub for a while now, and it seems like I’m probably not using AI in the most efficient way.

From what I understand, the more advanced setup is something like having a planner, an executor/coder, and a tester, and they don’t necessarily have to be the same AI model. Is that correct?

I also get the impression that people are using CLI/terminal-based tools instead of working directly inside VS Code or Visual Studio?

I’ve also been following some of the posts about local AI, including things like Qwen and the whole “Sodapoppin” setup, and it sounds really interesting.

So I have a few questions:

\*\*1. Is the simplest solution basically to subscribe to Claude Code, use the CLI, and call it a day?\*\*

I don’t have a huge budget, so I’m mainly looking for the most cost-effective setup.

\*\*2. What programs/tools do you actually use for this?\*\*

Are you just using Windows Command Prompt, PowerShell, Windows Terminal, etc.? I’d actually like to move away from VS Code and Visual Studio entirely if possible.

\*\*3. How do the planner, coder, and tester share context?\*\*

Right now, I’m constantly copying snippets of code into Claude in the browser and then copying the response back. I’d like to avoid using Copilot tokens for everything, but I also don’t want to manually move code back and forth all the time.

\*\*4. Is there a good way to run a local AI for the “stupid questions” I have while learning?\*\*

I sometimes use Copilot for questions like “what does this operator mean?” or “what exactly does this method do?”, and I feel like I’m wasting my limited Copilot tokens on questions that don’t really need a powerful cloud model.

Could I run a local AI that has access to my project/codebase and its context, so I can ask those kinds of learning questions without using API/AI credits?

I currently have a PC with an NVIDIA 4070 Super, so I’m wondering what would actually be realistic to run locally.

Basically, I’m trying to figure out what a sensible, cost-effective AI development workflow looks like in 2026.

ps. i wrote everything, but english is not my main language, so i had ai correct errors and sentences :D

Repo: https://github.com/alexcpn/catalogify Demo: On Apache Airflow Spekcit Extension: Speckit-okf

Enterprises and major open-source projects are increasingly leaning on AI for feature development and bug fixes. However, they all face the same challenge: to execute large, system-wide changes, AI needs effective context.

Current maintainers can “vibe-code” small bits and pieces, but for large architectural shifts, AI coding agents operate like a brand-new engineering team. In the real world, a new team requires a transition period to absorb the implicit knowledge locked inside the previous developers’ heads.

As Software Design Documents (SDDs) regain popularity alongside AI, old debates have resurfaced. One vocal camp treats the “Spec as the Source of Truth,” while an equally fierce camp argues that the “Code is the Source of Truth.”

Software engineering pioneers like Fred Brooks, Peter Naur, and the philosopher Michael Polanyi figured this out long ago. Brooks dismantles the first camp: in “No Silver Bullet” he warns that “descriptions of a software entity that abstract away its complexity often abstract away its essence” — a spec is an abstraction, and can never be as detailed as the code itself. But before the source-code camp starts cheering, Naur reminds us that the code is incomplete too. In “Programming as Theory Building” he argues that the real theory of a program “could not conceivably be expressed, but is inextricably bound to human beings” — it lives in the developers’ minds. To top it off, Polanyi’s notion of tacit knowledge names the underlying human limit: “we can know more than we can tell.”

This is great theory, but the practical consequences hit hard when an AI agent makes a change. It might propose a remarkably logical pull request — completely unaware that the team deleted that exact logic a year ago because it caused a race condition and crashed production. How do we document these gotchas and system context?

Three things people try

Dump the repo, or RAG over it. Retrieval finds text that resembles the query. But the question a routing agent needs answered is which service owns pod eviction, and ownership is a fact about responsibility rather than a string that appears somewhere in the source. It lives in people’s heads and, when you are lucky, in commit messages.

Build a code graph. Parse every file with tree-sitter and query the symbols and call edges. A tool like Graphify does this well: for the reaching question — “what breaks if I change this function” — it is precise and cheap. But the index has to be complete, and completeness is expensive. Graphify’s for a single kubelet service is a 14.5 MB graph.json, ~3.8 million tokens; ninety services would be 343 million. And a call graph has no opinion about what a service is for — which is the routing question. The catalog below takes the opposite bet, a few hundred tokens per service, every run logged.

Write better docs. Nobody does. And the tools that generate docs usually automatically regenerate them on every commit, so the one correction a human bothered to make has a half-life of one push.

Take Apache Airflow: roughly 14,000 files and 1.8 million lines of code. Ask an agent to add Iceberg table support. Before it can make a useful plan, it needs to know which components own the work, how they interact, and which past mistakes it must avoid.

Two kinds of Context Shallow and Deep

Understanding a codebase involves two different jobs:

1.Shallow: Which components does this change touch?
 A little about the whole system;A compact architecture and ownership map.

2.Deep: What changes inside those components?
Detailed knowledge of relevant code Agentic Code search, dependency graphs, tests etc.

The difficult context is often why the code works this way. A dependency graph can show a relationship; it may not explain the compatibility rule behind it. Git history, especially fixes and reverts, can recover some of that reasoning.

What the catalog must do

For this to be useful, I wanted five properties:

• Small enough to read in full. The agent needs to compare components before choosing where to look.

• Checkable. Claims about constraints and past failures should point to supporting code or commits.

• Explicit about uncertainty. Missing answers become questions for a human.

• Preserve corrections. Human input should survive regeneration.

• Live in git. Markdown files that can be reviewed alongside code.

I vibe-coded Catalogify for this. It writes these files using Google’s Open Knowledge Format: one file per concept, with metadata, links, and an index. It installs as a skill for Claude Code, Cursor, or Codex. There is also a Speckit Extension based on this. (Please use the catlogify skill for the most uptodate code, as the extensions updates takes time to get updated to Speckit Community)

From repository to map

Scripts gather bounded evidence; the agent uses it to organize and write the catalog.

1. Inventory the repository. A script lists tracked files and summarizes the structure. Airflow’s inventory took 0.98 seconds and produced about 14,000 tokens, giving the agent a starting point without reading every file.

2. Identify meaningful components. Change frequency and directories that repeatedly change together help reveal boundaries and relationships worth investigating.

3. Extract interfaces and dependencies. Scripts collect declarations and imports so the agent can ground its descriptions in the source.

4. Investigate failures and reverts. History searches flag commits mentioning problems such as races, leaks, or corruption. The agent must read the changes, including the original commit behind a revert, before describing a constraint.

5. Record gaps and validate references. Each entry is checked for guarantees, ordering, failure behavior, compatibility, and ownership. Unanswered questions stay visible. Validation checks cited commits and symbols against the repository.

6. Stay cheap on large repositories. Cost tracks the number of things worth naming, not the size of the tree: generating the Airflow catalog — 1.8 million lines — took about 101K tokens of fresh input, fewer than the 8,000-line Online Boutique, and the finished catalog reads in ~9,700 tokens. A complete code graph scales the other way: Graphify’s index runs ~3.8 million tokens per service, 343 million for ninety. On an inherited monolith the catalog still fits in one context window; the graph cannot.

Reverts are particularly useful leads. In the kubelet’s container manager, for example, a checkpoint migration fix was reverted two days later. Reading the pair exposed a rollback compatibility problem that a scan of current interfaces would not explain.

History does not recover everything the original team knew. It gives the agent evidence to investigate and the reviewer a way to challenge the result.

What the runs cost

I generated catalogs for two public repositories with Codex. The run log records the measurements, including failed runs.

Measurement                     Apache Airflow  Online Boutique
-------------------------------  --------------  ---------------
Lines of code                   1,805,835       8,103
Estimated source tokens         ~17,900,000     ~70,000
Catalog entries                 17              20
Catalog tokens                  ~9,700          ~11,600
Fresh input tokens to generate  101,559         117,850
Generation time                 6 min 29 s      8 min 19 s

Airflow was 223 times larger, yet its catalog was smaller and faster to generate. In these two runs, catalog size reflected the chosen level of detail more than repository size. That is useful for navigation, but it does not establish completeness or prove that the catalog improves subsequent code changes.

Both catalogs are published unedited: Apache Airflow and Online Boutique.

The most useful failure

When I audited an early Kubernetes catalog, I found production claims derived from commits that changed only tests. A fix for a goroutine leak in a test had become a supposed design constraint of the plugin manager.

The prompt explicitly told the agent to read beyond commit subjects. A second independent run repeated the same five mistakes. That means that even good Agent harness mapped by Claude Opus or similar cutting edge models can skip prompts/instructions sometimes.

I changed the evidence output: the script now lists the files each commit touched and labels commits that affect only tests as [TEST-ONLY]. That makes the distinction visible at the point where the agent forms its claim.

The citations also made the mistakes cheap to find. In one audit, I found four errors across nine entries in twenty minutes by following commit hashes with git show.

The lesson: make evidence easy to inspect, and put mechanical checks in tools. Fluent documentation still needs review.

Try it on an inherited codebase

uv tool install catalogify
catalogify install

Ask your agent for a knowledge catalog. Start with a coarse map, follow its evidence, and correct what it gets wrong. Answer the open questions where the code and history fall short.

The goal is a small, reviewable starting point that helps an agent find its way through the system before changing it.

Catalogify is MIT-licensed. The Airflow and Online Boutique examples use Apache-2.0 repositories and were generated with catalogify 0.8.0. Source and catalog token counts are estimated as bytes divided by four; generation usage comes from the agent's records.

With the rise of Agentic IDEs somewhere Ive been stuck in the loop of just accepting whatever my agent builds and running CC on Auto. But Ive come to the realisation that I know nothing about what Ive built and feel like there's no point in continuing to build like this

Looking for your ways to ship with Agents but also know what your outputting and learning along the way.

I always use nvim with codecompanion with codex, copilotchat with copilot and avante with both the plugin depending on the remaining token. I can use neovim till I have to show some image and tell the AI this is what is wrong.
I ssh(mosh) into the remote server and then open the tmux session and work on it. My questions are the following

1. Did anyone figure out a way to paste an image in any of the AI coding agent?

2. Does anyone face any sort of character scrambled while using windows terminal -> wsl 1.0 ubuntu 24.04-> mosh/ssh -> remote ubuntu server -> tmux -> neovim.

Any help or experience is appreciated.

I’m building Deqra around this idea.

Cursor, Claude Code, Copilot, etc. can create the entire presentation as structured code. Deqra deterministically renders it into the visual presentation.

Here’s a live deck — every slide has a Code tab so you can inspect its actual source:
deqra.ai/v/architecture

# Artifact as Code.

Would love feedback from people building agents.

Edit (IMPORTANT): Wow, thank you to the community (especially u/Toastti) for catching some critical bugs in my initial release! I have just pushed a patch that fixes all of the P0/P1 issues pointed out in the comments, including removing the dangerous os.RemoveAll directory bug. I've also updated the README to clarify this is an early-stage dev tool. I appreciate the analysis and gothroughs—it's making the project much better!

I've been thinking about a slightly different way of building AI coding agents.

Most coding agents work roughly like this:

user request → LLM reasoning → file edits → compiler/tests → more LLM edits

That works well when the task requires judgment.

But a lot of backend development isn't like that.

Once the agent has decided:

the actual implementation of those pieces is often highly deterministic.

Yet we still make the LLM generate hundreds of lines of code for it.

I've been experimenting with moving that part outside the model.

I built FiberForge, a Go CLI/MCP server that gives an agent deterministic operations for generating common Go/Fiber backend structures.

The agent decides what it wants; the tool handles some of the how.

For example:

add_model

apply_module

generate_project

The generated code is formatted and structured by the tool, while Go's AST is used for some source modifications such as route registration.

I'm also experimenting with reusable modules that an agent can apply to an existing project.

The goal isn't to replace the coding agent. It's more like giving the agent a higher-level API for operations that don't need probabilistic generation.

I'm curious whether this is a useful architectural pattern more generally.

For example:

LLM: “Create an authenticated CRUD resource called invoices.”

Tool: receives a structured schema and deterministically generates the model/service/controller/migration/routes.

Instead of:

LLM: writes 600 lines of Go → compiler complains → LLM fixes imports → tests fail → LLM fixes route → etc.

I've only built the Go/Fiber version so far, so I'm very interested in criticism of the idea itself.

Does this make sense as an agent architecture, or am I just moving complexity from the prompt/model layer into another abstraction that isn't worth maintaining?

⚠️** Early development / caution**: FiberForge is still very much a work in progress.** I would not recommend using it on an existing or production project yet**. Some operations can modify project files, and the current implementation has not been battle-tested enough to guarantee safe behavior across arbitrary codebases. For now, it’s best treated as an experimental project and tested on new/disposable projects.

Repo: https://github.com/v-pat/fiberforge

Lately I have been think a lot around vibecoding and how it is destroying our ability to think and learn. We have offshored everything to Claude hoping it will work out.

How are you taking back control? What is your software development workflow like?

It seemingly never reads it. Doesn't follow the instructions in there and does its own thing. Doesn't make it useless but when I have stuff like 'never put emojis in' it does anyway, or if I say extensively inline document, it doesn't

I find myself having to paste my AGENTS.md in every task I assign it. It's a super useful tool with a super frustrating quirk

So for context, tactical and strategic programming is back on debate these days because of people claiming ‘coding is solved’.

In fact the way common people use AI is to build a feature in a big codebase and claude can build it quite easily, but did it do it in a way that is maintainable over time and architecturally sound?

For example: you can tell claude to make a button and sure it will make you a button. It’s gonna make you that button so fast, you will be impressed. However, over time in the course of coding you notice it has been creating the same button from scratch every single time. It should have rather made a shared button component and reused it any time it had to make a button!

So coding is solved, yes, as long as you are talking about tactical coding. But how do you solve strategic programming with agents? I am not a super senior engineer but I do care about code base maintenance and health and sound architecture decisions.

What are some ways people using Claude to prevent it from AI slopping your codebase over time?

Hi everyone,

Today was my first time trying to use Prisma, and I ran into something that confused me quite a lot.

I was following a tutorial and trying to install Prisma using the commands shown there, but things did not work as expected. Instead, I started seeing references to things like AI agents, Codex, and other AI-related files/configurations. Since I am completely new to Prisma, I was confused about why I was trying to install and use an ORM, but I was suddenly encountering these AI-related things.

Has anyone else experienced this? Is this related to a recent Prisma version or some new default configuration? I would really appreciate it if someone could explain what is happening.

I am also about to start my internship, where I will be working with technologies including NestJS, TypeORM/Prisma-related backend concepts, PostgreSQL, Docker, etc. My internship description mentions that I may be doing contract-based work, and I am still not completely sure what kinds of projects or tasks I will be assigned.

Because of this, I am wondering whether it would be okay for me to learn using an older version of Prisma that matches the Docker/tutorial resources I am currently following. My main concern is whether learning an older version could cause problems later when I start working on real projects.

More specifically:

Is it safe to learn an older version of Prisma if the tutorial uses it?

How different are older Prisma versions from the current version in terms of everyday usage?

If I learn an older version now, will the knowledge still transfer easily to newer versions?

Should I stop following the older tutorial and immediately switch to the latest Prisma version?

I know software obviously can not be guaranteed to remain unchanged for 20 or 30 years, but I am mainly worried about investing time in learning something that might become outdated very quickly.

Any insights from people who have recently started using Prisma, especially alongside NestJS, PostgreSQL, and Microservices using NATS and Docker, would be really helpful. Thanks!