▲ 6 r/vscode

Made a VS Code extension for my open-source project, would like feedback

I've been building an open-source thing called Repowise and finally got a VS Code extension out for it. Sharing here because I want to know what's actually useful and what isn't.

What it does: it indexes your repo locally. Nothing goes to a server, it all stays on your machine. From that index it puts a few things in the editor that I got tired of checking in separate tools:

  • Gutter markers and a health score for whatever file you're in. The markers come from static analysis calibrated against actual bug-fix history in the repo, so it's not just "this file is long."
  • Refactoring suggestions show up as a CodeLens above the relevant code (extract a class, break a dependency cycle, split a file, that kind of thing). There's a button to copy the suggestion as a prompt if you want to hand it to Copilot or an agent.
  • "Analyze Change Risk" in the Source Control tab. Before you push it tells you what your uncommitted changes affect downstream, which changed files don't have tests, files that usually change alongside the ones you touched but that you left alone, and who might be a good reviewer.
  • The bigger views (health map, dependency graph, generated living wiki, knowledge graph etc which are native repowise offering) open in an editor tab instead of kicking you out to a browser.

One thing I ended up liking: the same local index also runs as an MCP server. So if you're using Copilot agent mode, or Cursor, or Claude, the agent pulls from the same index you're looking at instead of re-grepping the repo every time.

Free, AGPL-3.0. pip install repowise for the CLI, then grab "Repowise" from the Marketplace.

Marketplace: https://marketplace.visualstudio.com/items?itemName=repowise-dev.repowise
Source: https://github.com/repowise-dev/repowise

Diagnostics are off by default on purpose. I didn't want to add another extension that spams squiggles everywhere, so the signal sits quietly in the gutter and status bar instead. Mostly I want to hear whether that default feels right, and which parts are genuinely useful versus just noise.

u/Obvious_Gap_5768 — 23 hours ago

My open source project hit 2.7k stars and ~50k PyPI downloads, and it's the reason I quit my job

Let me give some background first.

My wife and I always wanted to build a company together. We started building and marketing some side projects on weekends and nights, nothing too serious just shipping things and seeing what worked, One of our side project was working great as well, organically reached 25k users but we weren’t satisfied enough to take it full time.

I've also worked with LLMs since 2023 and built a bunch of internal AI systems at my company over those years, including a multi-agent platform that ended up used across the company so I got promoted to senior staff along the way and ended up owning the AI architecture company wide.

Work was good but the itch to build our own thing never went away. So we started Repowise on the side. It's an open source codebase intelligence layer for AI coding agents. Your agent stops greping the same file four times and actually understands your repo: dependency graph, git history, docs, architectural decisions, and a code health score etc etc

We didnt do any outbounds just shipped it, wrote about it on our socials, and let people find it, been 3 months now.

It grew on its own. 2.7k+ stars. Around 50k downloads on PyPI. Then enterprises started reaching out, all inbound. That was the signal I needed, so I left my job to do this full time.

Still early and still terrifying but so far the user response has been exciting, We had focused mainly on perfecting the product and little bit organic marketing, Time to give it our everything now

reddit.com
u/Obvious_Gap_5768 — 3 days ago
▲ 2 r/mcp

I built an MCP server that gives coding agents deterministic code health that predicts bugs (no LLM), tested it on OpenClaw

Most codebase MCP servers wrap grep and file reads. I wanted my coding agent to answer the questions grep can't: which files actually carry the bugs, why is this code shaped this way, what breaks if I touch it. So I built an MCP server around a codebase engine, and the headline tool is a deterministic code-health score. I ran the whole thing on OpenClaw as a public test.

The headline tool: code health

get_health returns a 1 to 10 score per file from 25 deterministic biomarkers (complexity, duplication, ownership and churn, test gaps). No LLM in the scoring, so the same commit always gives the same number, which matters when an agent is making decisions off it. It splits into three views: defect risk, maintainability, and a static performance-risk pass.

On OpenClaw (18k files): average 6.83, maintainability 8.94, with risk concentrated in a few hotspots. The performance pass alone flagged 1312 I/O-in-a-loop shapes and 324 serial awaits that could fan out with Promise.all. An agent can read this before editing and know which files are landmines.

Live report you can click through: https://www.repowise.dev/repo/openclaw/openclaw/overview

The rest of the MCP surface

The same server exposes, all read-only:

- get_context: a verified skeleton of a file or symbol (signatures + the central bodies) at a fraction of a full read, so the agent spends fewer tokens to orient

- get_why: architectural-decision archaeology, falls back to git history when no decision record exists

- get_risk: churn, owners, and blast radius before a change; PR mode returns a will-break / missing-tests directive

- search_codebase: hybrid symbol / path / semantic search

- get_dead_code, get_symbol, get_overview

There is a trust protocol baked in: responses that were checked against the live working tree are marked verified, so the agent is told not to re-read those bytes that alone cut a lot of redundant file reads in practice.

The scoring and findings are static analysis over tree-sitter ASTs and git data, not an LLM grading your code. The docs/wiki layer uses an LLM, but the numbers an agent acts on are reproducible. We run these same tools against our own codebase, which is how most of the rough edges got found.

It works across 15 languages, runs locally, and is open source: https://github.com/repowise-dev/repowise

Feedback and contributions welcome!

u/Obvious_Gap_5768 — 10 days ago
▲ 816 r/indiehackersindia+3 crossposts

Do zero-LLM health metrics predict where bugs land? Ran it across 21 repos, here's what held up

Most "AI reviews your PR" tools annoy me. They hallucinate nits, the output changes every run, and you can't tell if a flag means anything. So I wanted to know if you can get a useful review signal the boring way. Static metrics plus git history, without any LLM in the loop, so same input gives the same output every time.

The question I actually wanted answered: do deterministic code-health metrics predict which files get bug-fixed later?

How I set it up :

  • Score every file at a historical commit (T0).
  • Count bug-fixing commits to that file over the next 6 months.
  • Correlate the T0 score with the bug-fixes that came after. No file sees its own future.

Metrics are the usual suspects plus churn signals. McCabe complexity, deep nesting, LCOM4 cohesion, god classes, clone detection, function-level churn, code age, ownership spread, change entropy. 25 of them, combined into a 1-10 per file. I ran it across 21 OSS repos, 9 languages.

What came out:

  • Mean ROC AUC 0.74 at picking the files that go on to get bug-fixes. Up to 0.90 on some repos, weaker on others.
  • It survives controlling for file size (partial Spearman -0.16). So it's not just "big files have more bugs," which was my first worry.
  • Out-ranks churn alone by about +0.10 AUC, and prior-defect history by +0.12.
  • Held on an external dataset I never touched (PROMISE/jEdit), AUC ~0.77.

I ran it head to head against CodeScene too, same 2,770 files, same commit, same labels, since it's the closest established tool. Discrimination was close (0.73 vs 0.71). The gap showed up on effort-aware ranking. Under a "you only have time to review 20% of the changed lines" budget, the deterministic score surfaced more of the real defects (recall 0.17 vs 0.07, Popt 0.61 vs 0.46). Similar at telling risky from safe, better at ordering what to look at first.

Where it falls down, because 0.74 is not magic:

  • It tells you where bugs cluster, not what the bug is.
  • Ranks files, doesn't read them so not a review replacement.
  • Defect labels come from bug-fix commits, which is a noisy heuristic. Some "fixes" aren't, some bugs never got a clean fix commit. That ceiling is baked in.
  • The 6-month window is a choice. Move it and the numbers move.
  • The CodeScene edge is specifically ranking under a budget. On raw "is this file risky, yes or no," they're close.

Where I landed: the signal is real and it's reproducible, which is the part I care about for PR gating but it won't catch a logic bug in a 4-line diff.

It's good at "this PR touches a file that's been a problem for a year with one owner, slow down." Different job than line-by-line review, and I think it's the job the deterministic approach is actually good at.

I have also added agent provenance to the same which allows it to determine if an AI PR is worse than human

If anyone wants to take a look at the repo: https://github.com/repowise-dev/repowise

Also, if you have any feedback on the metrics itself or if I can try some new metric, would love to try that

u/Obvious_Gap_5768 — 11 hours ago

I built a fun performance review tool for Claude Code. It graded me too. I got a B

My agent kept saying "you're absolutely right" and I had transcripts of everything sitting in ~/.claude/projects. So I made the meeting official.

skiplevel reads those transcripts locally and generates a 360 review between you and your agent. It generates self-contained HTML file, without any uploads.

For my 632 sessions and 160k transcript lines, it took around 2 seconds.

uvx skiplevel

Mine found:

- Claude said "you're absolutely right" 56 times in 31 days

- It read the same file 30 times in a single session. 151 times overall

- I interrupted it 339 times and typed 3,025 words in ALL CAPS

- It once ran 299 tool calls in a row unsupervised

- Verdict: Agent A-, me B. I apologized to a language model 7 times, which it noted

You get graded on clarity, patience, civility, trust. The agent on eficiency, reliability, safety, composure. All deterministic, zero LLM by default, the full rubric is in the repo.

There's also a useful layer under the jokes: redundant reads, retry storms, sensitive file touches with timestamps, cost per session. It flagged every time the agent went near a .env or .ssh path.

Works on Codex CLI and opencode transcripts too. Optional --roast flag sends your stats (numbers only, never prompts or code) to your own claude CLI for custom commentary.

Built with Fable, so Claude wrote the tool that reviews Claude. It gave itself an A-.

MIT: https://github.com/repowise-dev/skiplevel

Would love to see what grades you guys get

u/Obvious_Gap_5768 — 25 days ago

I measured how many tokens Claude Code wastes re-reading files and command output over a week. Its around ~10.5M

I run Claude Code on Opus most of the day. Got tired of watching it cat the same file four times and read 300 lines of passing-test dots to find 4 failures.

So I made an OSS tool to fix this and then measured what it saved over a week.

Two sources of waste, two fixes

Command output: git diff, git log, pytest, build and lint floods. A filter compresses the output before the agent reads it. Errors first, exit code preserved, every omission reversible. git log and git diff land 86 to 89% smaller. Test runs about 60%

Retrieval: Instead of the agent grepping and opening 8 candidate files to answer one question, MCP tools hand back a curated answer. Each call replaces the raw file reads it stood in for

~41% of the savings came from retrieval, not the command-output compression everyone talks about

One heavy week on my own repo:

6.2M tokens saved on command output, 4.3M tokens saved on retrieval, 10.5M total, about $158 the agent never had to read, one-time indexing cost: $0.37 (nano model)

The token tracking is one layer. repowise also indexes the repo into five: graph (AST + call structure), git history (hotspots, ownership, bus factor), docs/wiki, architectural decisions, and code health

Dashboard screenshot below. All local, nothing leaves the machine, open source (AGPL)

Repo: https://github.com/repowise-dev/repowise

u/Obvious_Gap_5768 — 28 days ago

Built an open source tool that gives AI coding agents real context about your codebase

I've been building repowise which is an MCP server that feeds your codebase structure to AI coding agents so they get deep understanding of your codebase beyond Grep.

Most agents only see the file as it is. Repowise gives them more: the dependency graph, git history (hotspots, ownership, co-changes, bus factor), an auto-generated wiki, a health score per file and architectural decisions from your code

The Code Health layer runs 25 deterministic checks per file without using LLM. Each file gets a 1 to 10 score based on complexity, duplication, test coverage, and a few other signals.

I benchmarked the defect prediction against CodeScene on 21 repos across 9 languages. It can predict bugs with a 74% accuracy (higher than CodeScene). Full writeup is in the repo if someone is interested

Open source, works with Claude Code, Cursor, or anything MCP compatible. Plus you get this full web ui completely local

GitHub: https://github.com/repowise-dev/repowise

Feedback and contributions welcome!

u/Obvious_Gap_5768 — 29 days ago

I checked which code-health metrics predict real bugs across 21 repos. Behavioral metrics beat structural ones

I am working on an open source tool that scores how risky each file in a codebase is. 25 biomarkers per file, all deterministic, from the AST and git history, without LLM. I wanted to know which of those metrics actually predict bugs, so I scored every file at a point in time and counted how many bug-fixes each one collected over the next 6 months.

Did this across 21 repos and 9 languages, around 2800 files.

The metrics that predicted bugs best were behavioral, not structural. Co-change coupling, files that keep getting changed together, came out strongest. How spread out a file's ownership is and how erratic its change history is held up well too. The structural complexity metrics most teams watch, cyclomatic complexity, nesting depth, long methods, all are mid tier.

I posted an early version of this few days ago, and developer_congestion was my top signal then. That one turned out to be leakage. The metric reads recent git activity, and I was scoring files at their current state, so it was quietly counting the fix commits I was trying to predict. Moving the scoring point to before the bug window dropped it to almost nothing.

Mean AUC is around 0.74, basically 74% of times it can tell a bug inducing file from clean ones

What gets me is how much effort teams put into the complexity metrics while mostly ignoring coupling and ownership, which is what actually tracked bugs here.

Does any of this match your experience?

reddit.com
u/Obvious_Gap_5768 — 1 month ago
▲ 92 r/golang

Repowise: a deterministic, zero-LLM code health scorer for Go, tested against Hugo's actual bug history

Hey r/golang, I've been building an open source tool called repowise that maps a codebase from its call graph, git history, and docs. One layer scores every file 1 to 10 on code health. I want to show that piece, plus a test I ran on Hugo.

What it is

25 deterministic biomarkers, without llm. Tree-sitter AST plus git history, so the same commit always gives the same score. A few from each bucket:

  • Complexity: brain_method, nested_complexity

  • Duplication: dry_violation (Rabin-Karp rolling hash over tokens, survives renames)

  • Test coverage: untested_hotspot, coverage_gradient

  • Process and ownership: developer_congestion, change_entropy, prior_defect

Two of them (LCOM4, god_class) are class-level, so they sit out on Go since methods hang off receivers, not class bodies. The other 23 do the work.

Does the score predict bugs?

Ran it on Hugo, 946 files. I marked a file "buggy" if a fix commit touched it in the last 6 months, then looked at the 20 worst-scoring files. 17 had a recent fix, against a 15 percent base rate. So the worst files are about 5x more likely to carry a bug than a random one, and the messiest 20 percent of files hold around 60 percent of every recently bug-fixed file.

Worst file: config/allconfig/allconfig.go at 1/10. One function runs 269 lines, cyclomatic complexity 60, nested 7 deep. Three fix commits touched it in the 6 month window.

One surprising finding is that process signals beat complexity. untested_hotspot and developer_congestion predicted bugs better than McCabe complexity or nesting depth did.

On leakage: I also ran the time-travel version, score at time T then count fixes over the next 6 months. Holds at about 0.74 AUC across 21 repos and 9 languages, about 0.81 for Go.

Repo: https://github.com/repowise-dev/repowise

Live Hugo report: https://www.repowise.dev/repo/gohugoio/hugo/health

Clicking each file gives you the exact breakdown of its score and you can also browse the other layers here (wiki, graph, git, etc)

Feedback and contributions welcome

u/Obvious_Gap_5768 — 1 month ago
▲ 168 r/ClaudeCode+1 crossposts

Claude Code has zero idea what your codebase looks like structurally (Open source with benchmarks)

Every time I watch someone use Claude Code on a real codebase, the same thing happens. It rewrites a module that three other modules depend on without any awareness of coupling. It just reads the file, makes changes, moves on

It reads files one at a time without any map. Doesn't know which files are coupled. Doesn't know who owns what. Doesn't know why that weird pattern in the auth module exists on purpose.

I've been building an open source MCP layer to fix this called repowise. Self-hosted, pip install, AGPL-3.0.

Five context layers that sit between your codebase and the model:

Graph - AST-based dependency graph. Knows what depends on what before it touches anything.

Git - Hotspots, ownership, co-change patterns, bus factor. "This file always changes with these three other files.

Docs - Auto-generated wiki from your code. Searchable.

Decisions - Captures architectural intent. Why the code is shaped the way it is. Stops the model from "fixing" things that were intentional.

Code Health - 12 biomarkers per file. Complexity, duplication, untested hotspots, declining trends. Zero LLM, pure static analysis.

We ran a time-travel experiment on Django (542 files): scored every file, then counted bug-fix commits over the next 6 months. 14 of the 20 worst-scoring files had real bugs. 70% precision. The top predictors were untested hotspots and developer congestion, not complexity metrics. The model gets this before it starts rewriting anything.

9 MCP tools. Benchmarked on real tasks: 49% fewer tool calls, 89% fewer file reads, 36% cost reduction.

1.9K+ stars on GitHub.

https://github.com/repowise-dev/repowise

u/Obvious_Gap_5768 — 28 days ago

15 code health biomarkers, benchmarked against 6 months of real bugs across 3 repos

I'm building an open source codebase intelligence tool. One layer of it scores every file 1-10 using 15 deterministic biomarkers without LLM. Uses AST parsing via tree-sitter plus git history.

The biomarkers fall into five buckets:

Structural: brain_method, nested_complexity, bumpy_road, complex_method, large_method, complex_conditional, primitive_obsession

Duplication: dry_violation (Rabin-Karp rolling hash over tree-sitter tokens, survives variable renames)

Test coverage: untested_hotspot, coverage_gap

Organizational: developer_congestion, knowledge_loss, hidden_coupling, function_hotspot, code_age_volatility

I ran a time-travel experiment on FastAPI (104 files), Pydantic (216 files), and Django (542 files). Then score every file at time T, count bug-fix commits over the next 6 months, check correlation.

On Django: Spearman ρ = -0.34, p < 0.0001. Precision@20 = 70%, meaning 14 of the 20 worst-scoring files had real bugs in the following 6 months.

The two strongest single predictors were untested_hotspot (Cliff's delta +0.67) and developer_congestion (+0.78 in Django). Both are process signals. McCabe complexity and nesting depth ranked lower.

knowledge_loss went negative. Files where original authors left the project had fewer bugs.

My read is that stable legacy code that nobody touches doesn't break.

One thing I'm being upfront about is thatcontrolling for file size drops the correlation from ~0.3 to ~0.1. Bigger files carry more complexity and more bugs. CodeScene published a similar study claiming 15x more defects in unhealthy code but never reported this confound.

What would you add to this list? And has anyone else seen ownership metrics beat complexity in practice?

reddit.com
u/Obvious_Gap_5768 — 1 month ago

Resigned from a Sr Staff DS role last week to build full-time. I cant sleep anymore

I am a Sr. Staff Data Scientist at a large public company. Good comp, good manager, good WLB. I'd been building things on the side for about a year with my wife. Open source dev tool an edtech product, and a hackathon project that got traction.

None of them replacing my salary but all of them taking more of my brain than my day job was. I submitted my resignation last week, currently serving notice.

The fear has got worse after resigning, not before. When it was a side project there was nothing at stake. Now there is. The salary comparison is brutal. I keep opening a spreadsheet that tells me I'm fine on runway and then feeling not fine anyway.

Enterprise interest exists. I've had calls with companies that have 500+ engineers, signed an NDA with one. But enterprise sales as a two-person team is a pipeline management problem I have zero muscle for. A single POC can take 8 weeks before any code runs.

The part I got right was starting while employed. Eight months of overlap where I built the core product nights and weekends. Would not have had the conviction to quit cold.

Would love any suggestions you might have, I am just feeling very anxious

reddit.com
u/Obvious_Gap_5768 — 1 month ago
▲ 3 r/coolgithubprojects+1 crossposts

repowise - open source codebase intelligence for AI coding agents (and humans too)

Built this because every time I used Claude Code on a large codebase, it would just read files one by one. No idea which files change together, who owns what, why things were built a certain way, or what code is straight up dead.

repowise indexes your codebase into five layers: dependency graph (tree-sitter), git history analytics (hotspots, ownership, co-changes), auto-generated docs with RAG search, architectural decision tracking, and code health scores with 12 biomarkers.

All of it exposed through 9 MCP tools so your AI agent can actually understand your codebase instead of grepping through it blind. Also works standalone with a local dashboard if you just want the analytics without the AI stuff.

Some numbers from our benchmark on Flask: 36% cheaper, 49% fewer tool calls, 89% fewer file reads. Same answer quality.

Multi-repo workspaces, auto-sync on every commit, works fully offline with Ollama. AGPL-3.0.

pip install repowise

GitHub: https://github.com/repowise-dev/repowise

Happy to answer any questions.

u/Obvious_Gap_5768 — 1 month ago

Just quit my 1 Cr job to go full time on my own startups. Anxiety is through the roof

I'm a Sr Staff Data Scientist at a large MNC in Bengaluru. Great CTC, a manager I genuinely like, the kind of WLB that lets you have a life outside of work. By most metrics it was the kind of job people would be happy to coast in for a few years.

At the same time I had three things running on the side.

One is an open source dev tool for AI coding agents I launched a month back. It started getting enterprise inbound faster than I expected. NDA already signed with one major mnc, POC scheduled with another, couple more in conversations. No revenue yet but things feel good.

Second is an AI interview prep platform I co-founded with my partner about 8 months back. Around 25K users now, real monthly revenue, covers DSA, system design, AI/ML, the whole stack. Not enough to retire on but enough that I stopped calling it a side project a while back.

Third is a voice AI tutor we built at a hackathon last month. 500 signups in the first couple of days. Way too early to call but the early response felt different from other things we've launched. Don't have enough time to market this so parked it aside.

The other reason this felt necessary was that my head was already somewhere else. Work was fine, I was hitting deliverables, but my real focus was going into the side stuff. Felt fairer to both sides to just pick one.

I also kept telling myself I'd quit once the time was right. After 6 months of saying that I realised the time is never actually going to feel right.

Last week I just did it, my partner really stepped in and helped me decide here.

Now I'm in notice period and I can't sleep properly. The same traction that made the decision feel obvious is now making it scarier somehow. Now there's something real to lose. Telling my parents was harder than I thought. They didn't say anything bad, but I could see their doubts.

Friends who were telling me to just do it three months ago are now asking are you sur. Atleast my partner is supportive and thats all that matters.

I keep coming back to feeling like this was the right call, but the anxiety hasn't gone down even after putting in the papers. If anything it's worse now.

Posting this here mostly to put it somewhere outside my own head. Two months till I find out if past me was an idiot or a genius.

reddit.com
u/Obvious_Gap_5768 — 2 months ago

Just quit my 1 Cr job to go full time on my own startups. Anxiety is through the roof

I'm a Sr Staff Data Scientist at a large MNC in Bengaluru. Great CTC, a manager I genuinely like, the kind of WLB that lets you have a life outside of work. By most metrics on this sub it was the kind of job people would be happy to coast in for a few years.

At the same time I had three things running on the side.

One is an open source dev tool for AI coding agents I launched a month back. It started getting enterprise inbound faster than I expected. NDA already signed with one major mnc, POC scheduled with another, couple more in conversations. No revenue yet but things feel good.

Second is an AI interview prep platform I co-founded with my partner about 8 months back. Around 25K users now, real monthly revenue, covers DSA, system design, AI/ML, the whole stack. Not enough to retire on but enough that I stopped calling it a side project a while back.

Third is a voice AI tutor we built at a hackathon last month. 500 signups in the first couple of days. Way too early to call but the early response felt different from other things we've launched. Don't have enough time to market this so parked it aside.

The other reason this felt necessary was that my head was already somewhere else. Work was fine, I was hitting deliverables, but my real focus was going into the side stuff. Felt fairer to both sides to just pick one.

I also kept telling myself I'd quit once the time was right. After 6 months of saying that I realised the time is never actually going to feel right.

Last week I just did it, my partner really stepped in and helped me decide here.

Now I'm in notice period and I can't sleep properly. The same traction that made the decision feel obvious is now making it scarier somehow. Now there's something real to lose. Telling my parents was harder than I thought. They didn't say anything bad, but I could see their doubts.

Friends who were telling me to just do it three months ago are now asking are you sur. Atleast my partner is supportive and thats all that matters.

I keep coming back to feeling like this was the right call, but the anxiety hasn't gone down even after putting in the papers. If anything it's worse now.

Posting this here mostly to put it somewhere outside my own head. Two months till I find out if past me was an idiot or a genius.

reddit.com
u/Obvious_Gap_5768 — 2 months ago
▲ 153 r/indiehackersindia+3 crossposts

How I cut Claude Code token usage in half (open source, benchmark included)

Been working on Repowise for a few months now. The core idea: AI coding agents are only as good as the context they get. Most of the time, that context is terrible.

Cursor reads your files. It doesn't know your architecture. It doesn't know which files break the most. It doesn't know why you made that weird design decision in auth six months ago.

So I built a layer that sits between the codebase and the agent.

Four things it does:

  1. Parses your AST into a dependency graph (NetworkX). Agents can reason about structure.

  2. Mines git history into hotspot and ownership maps. Who wrote what, what breaks most.

  3. Generates an LLM wiki of your codebase and stores it in a vector DB. Always in sync.

  4. Captures architectural decisions as ADRs so agents have intent context, not just code.

Exposes 8 MCP tools. Works with any MCP-compatible agent. Also has a local web UI to explore the graph and docs yourself.

AGPL + commercial dual license. Self-hostable.

Got a few hundred GitHub stars pretty fast. Then someone cloned it on PyPI three times in a week violating the license, had to file a DMCA. Wild week.

Happy to answer questions on the technical side or the distribution side. Both have been interesting.

Repo: https://github.com/repowise-dev/repowise

Dogfooding on website: https://repowise.dev

A star would really help with visibility!

u/Obvious_Gap_5768 — 2 months ago

Anyone else miss writing code before agents took over?

Building two products full-time. Most of my day is babysitting Claude and Cursor. Prompt, wait, review diff, accept, prompt again. 10 hours of this.

Shipping more code than ever but still feel like I built nothing.

Used to love opening the editor at night, headphones on, disappearing into a problem for 4 hours straight. That flow state where you forget dinner is gone now

Opened code I wrote by hand 6 months back. Remembered every weird decision, every tradeoff. Pulled up something Ckaude shipped last month. Reads like a stranger wrote it.

Yes I can still write everything by hand. Then I ship 1 feature while the next founder ships 5. Cannot afford that as a solo guy competing for users.

I am not saying AI is bad. It is brilliant for boilerplate, refactors, migrations. But the part I actually loved is gone. Debugging a weird race condition for 3 hours until one print statement cracks it open. Writing a clean solution from scratch. Actually building something with my hands.

Anyone else feeling this?

reddit.com
u/Obvious_Gap_5768 — 2 months ago
▲ 190 r/Python

Three packages copy-pasted my AGPL code to PyPI and named me in their description. PyPI won't act

I published repowise on PyPI a few weeks ago. It generates and maintains a wiki for your codebase, plus some git intelligence stuff like hotspots and ownership among other things

Soon after launch, three packages appeared on PyPI within hours of each other, all with the same description:

"Codebase intelligence that thinks ahead, outperforms repowise on every dimension."

Repowise is mine. They literally name it.

Looked inside the packages. They forked my AGPL-3.0 code, ran an LLM over it to fix a few small things, and republished under new names. No attribution, no license file, no source link.

Filed PyPI abuse reports. Filed a DMCA for the license violation. Sent email. Weeks in, all three packages are still live, still pulling downloads off my project's name.

PyPI's abuse flow seems to be a single form and silence. There's no copyleft enforcement path baked into the registry itself, so AGPL violations basically depend on DMCA, which is slow and easy to ignore.

Any suggestions would be very helpful

reddit.com
u/Obvious_Gap_5768 — 2 months ago
▲ 1.5k r/NewKeralaRevolution+1 crossposts

I work in AI daily. Staff Data Scientist, building multi-agent systems at enterprise scale, published at research venues. I also build products on the side. So I sit at an interesting intersection of "AI is my job" and "AI is eating my job."

Here's what I actually think plays out.

The junior dev pipeline dies first. Not junior devs. The pipeline. The "write CRUD, fix bugs, level up over 3 years" path is gone. Companies will hire fewer L1s and expect them to move faster. The entry bar got harder, not easier.

The middle gets squeezed. Engineers who are "good at implementing specs" are in trouble. That's a Claude/Cursor job now. Engineers who understand systems, make architectural calls, and can review AI output critically? More valuable than ever.

The top 10% gets a 10x multiplier. One good engineer with strong AI tooling is doing what used to take a small team. Companies will figure this out slowly, then all at once.

The Indian market specifically runs heavily on service contracts and staff augmentation. That model was already getting squeezed on margins. AI just compresses the timeline further.

The devs who thrive will be the ones who stopped thinking of themselves as coders and started thinking of themselves as builders.

Curious to hear about other people's take

reddit.com
u/Obvious_Gap_5768 — 2 months ago

TL;DR: The divide isn't AI replaces you vs. doesn't. It's people who use AI to think vs. people who use AI to avoid thinking. College is the best time to be in the first group. Build something real, go deep on one tool, learn to navigate codebases. The field is moving fast enough that a sharp fresher can outpace a complacent senior right now. That window won't stay open forever.

Let me start by saying: your anxiety is not irrational. The ground is actually shifting. I'm not going to give you the "AI is just a tool lol relax" cope.

Quick context so you know where this is coming from: 7 years in tech, senior staff level, currently leading AI initiatives at a large org. On the side I've been building and shipping things seriously: open source projects with real community traction, products with 20k+ users. I've been on the other side of GenAI hiring loops recently, so I see both ends of this, what gets built and what gets through.

Here's what I actually see.

The divide forming is not what you think

Everyone frames it as: will AI replace developers?

Wrong question.

The divide I see, in hiring, in who's getting traction, is between people who use AI to think and people who use AI to avoid thinking.

The second group is genuinely in trouble. I interview them. They can use Cursor, they can get something running, but ask them why they made an architectural choice or what happens when it breaks at scale: nothing. The AI wrote it and they don't know what it wrote.

The first group? They're shipping things I couldn't have shipped in the same time a few years ago. And a lot of them are not from pedigreed backgrounds.

What nobody tells you about enterprise AI

Most enterprise AI is a mess. Half the projects are LLM wrappers with no evals, no fallbacks, and someone's job title changed to "AI lead." People who can design agentic systems that are reliable, not just demo-able, are genuinely rare.

You don't need 5 years to understand this space better than most people in it. It's so new that a sharp 3rd-year who's been building seriously for a year can have better mental models than a 10-year veteran who started "exploring AI" last quarter.

That window won't stay open forever. But it's open right now.

The DSA question (honest answer)

Don't quit. But recalibrate why you're doing it.

The real value of DSA was never array rotations. It's learning to decompose problems and reason about tradeoffs. That's more useful than ever when you're debugging an agentic pipeline hallucinating in production.

The value of DSA as a placement filter is under pressure. Some companies are changing loops. But many haven't, and you need to clear placements to buy yourself options. Do the grind, clear the filter, just don't confuse clearing the filter with actually being good.

What I'd do if I were in college right now

  1. Build something real before you graduate. Not a tutorial project. Something with users who aren't your friends. Even 10 strangers using your thing will teach you more than any course. With AI, a weekend is enough to have a rough but real product.

  2. Go deep on one AI tool, not shallow on all of them. Listing 8 AI tools on a resume impresses nobody. Pick one and understand it well enough to explain its failure modes.

  3. Learn to navigate a codebase, not just write one. AI writes code fast. The scarce skill is understanding why a codebase is shaped the way it is and knowing where to change things without breaking stuff. This is what separates a vibe-coder from someone a team actually wants.

  4. Full-stack + LLM API calls is criminally underrated. If you can build a clean backend/frontend AND wire in a real LLM workflow, not just chat_completion but actual tool use, memory, fallbacks, you're genuinely useful at most AI startups right now. Most people don't have this. It's not a high bar.

  5. Contribute to open source AI tooling. Agent frameworks, eval libraries, dev tools. People hiring in this space notice GitHub. More importantly, you'll be building alongside people who actually know what they're doing.

The uncomfortable thing

A lot of senior engineers, people at my level and above, are also scared and figuring this out in real time. "What's the right architecture for agentic systems in production?" Honest answer: we're still working it out

You're not as far behind as you think. The gap between a curious, building fresher and a complacent senior is closing faster than at any point I've seen. That's both a threat and an insane opportunity, depending on which one you decide to be.

Build something. Ship it. Let it fail. Repeat.

Good luck.

reddit.com
u/Obvious_Gap_5768 — 2 months ago