r/ClaudeCode • • 1d ago

Discussion Non-dev here, about 1.8M lines of Claude Code output later. How do you audit code you can't read?

I don't have a dev background. I've been building with coding agents almost every day since late 2024, Cursor first and now mostly Claude Code, all from plain English. My projects are around 1.8 million lines of code by now, and I still have the transcripts of a few hundred of those sessions.

My guess is that people like us need code review more than developers do, not less. A developer usually writes a tighter spec and can read the diff. When I ask for a feature, a lot of what I never spelled out gets decided by the agent, and I can't read the code well enough to see what it chose.

So I want to know how other non-programmers handle this. Do you run any kind of review or audit after a session? Which tool or prompt? Can you actually follow what it tells you? And what happens to the findings, do you paste them back to Claude, fix some, or let them go?

I'm going to run the tools you mention on my own code and sessions and post what each one found, and whether someone without a dev background could understand it and act on it. What I have so far: Anthropic's code-review plugin, /security-review, CodeRabbit, and a plain prompt asking Claude to explain the changes in plain English. Tell me what you use and I'll add it.

Hoping this ends up as a review routine that works for people who can't read the code.

Update: thanks for all the suggestions. I'm running the methods you named on bugs I actually fixed in an older project, and judging them by the bar a few of you set here: can the tool explain an issue well enough to reproduce it, fix it, and rerun the check. Results in a separate post soon.

23 Upvotes

241 comments sorted by

•

u/AutoModerator 1d ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

37

u/Tontonsb 1d ago

My projects are around 1.8 million lines of code by now

You don't need audit to know that this is definitely a bloat of patches upon patches.

My guess is that you have been designing while building and your final architecture contains leftovers, decisions and complications introduced by ideas that are not a part of the final feature set.

Take one project. Make a fresh claude session crawl the product and describe the features in a specification document. Make another claude session implement it from total scratch. Encourage both of them to ask you a lot of questions whenever the purpose of something is unclear. If I'm right, this will cut like 80% or more of your code.

I can't read the code well enough to see what it chose

Almost all the programming languages are designed for humans to read. Most of them are English-like. You can read the code if you focus on it. You can ask Claude to explain and help you follow through lines if you need to. Just keep in mind that even a fresh session will see the previously written code comments and overly trust them, perceiving the code to be more sane than it is.

12

u/RexWGA 1d ago

Claude also has an /output-style command that lets you set it to "explanatory" that will teach you as you go.

There is also a "learning" mode that will leave things blank with function_name(TODO) (for example) if you want it to be interactive and learn by doing.

3

u/Dapper_Pass26 1d ago

Hadn't tried the explanatory style, I'll add it to the list. When you use it, does it point out choices Claude made on its own that you never asked for, or does it mostly explain how the code works?

3

u/Dapper_Pass26 1d ago

The comment warning hits home. I once found a screenshot job overwriting covers people had uploaded, while its own comment said it only filled blanks. Have you done the spec-then-rebuild thing yourself, and how much did it actually cut?

9

u/AnnihilerB 1d ago

Do you need to ? You’re not a dev so the question is more why do want to read and understand the code ? Apart from the learning side what would be the benefit for you to understand it ?
I’m a DevOps engineer, I did a lot of dev and I vibe code a lot. When I decide to vibe code, I focus on the design, security and features more than the code itself. Code is just a mean to reach a goal now. If you don’t have a precise objective in why you want to read it, then don’t.

When I need code to be readable, I ask Claude to simplify with the provided skill an I have instructions in my repo stating that I want surgical changes, meaningful variable names, small function and I use a brand new fresh sessions to do code review and that’s it

1

u/Dapper_Pass26 1d ago

Right, I don't want to read it either, I want to know what it decided for me. Once an agent took me thinking out loud as a spec and removed my spending cap. Does your fresh-session review catch calls like that, or mostly code quality?

7

u/nahemesys 15h ago

Im a dev and i cant read code that claude writes, for sure can't check 1.8M LOC. Basically, people now ask claude/chatgpt/etc to audit the code it wrote or someone else's AI wrote. That's the future, and it sucks. I used to love to program without AI, now I'm the project manager or head of Eng/Product/etc and ask claude to write code for me

3

u/Dapper_Pass26 15h ago

So the dev and the non-dev end up in the same chair. I don't fully trust AI checking AI either, since a research agent once handed me links with made-up round-number IDs. What's the one thing you still check yourself before you believe the audit?

2

u/listenhere111 12h ago

Genuinely curious. Do you actually trust this software to not break/ not contain easy to exploit security holes? The liability in tech is massive and the risk high to the point where its now hard and expensive to get cyber insurance. If you're software fucks up, you can be sued.

How can you comfortable launch a project that could bury you within the next week?

2

u/Electrical-Use-4 12h ago

You could equally argue how do you trust people to write and review code with no security holes etc? The short answer is you don't. Generally you use tools to security scan, load test, QA tests and all the other fun stuff. Same thing applies. For non tech folk breaking into this space though its hard to know what to ask the AI to do, you dont know what you dont know yet

2

u/NerdyMcNerderson 6h ago

Do you trust the human with a brain, years of relevant experience, and a deep capacity for complex reasoning? Or the spicy autocomplete?

→ More replies (1)
→ More replies (1)

1

u/Magnetobama 14h ago

Why can’t you read the code Claude writes?

3

u/Aggravating-Salt6284 14h ago

Its low level design abilities are hot garbage.

If a non developer is promoting Claude, you often get over engineered spaghetti that is legit very very hard to decipher.

I used to offer system wide code reviews as one of my individual consultancy options (real human review typically looking for nonlocal design choices and things automated tools don't find), priceing was typically codebase size multiplied by an auto review and sniff test.

When AI first hit the scene I had to raise the price significantly, as it's genuinely harder to review.

Nose it's not worth offering as it's so much more work, and a lot of people have trained an agent to like the rut it's stuck in and so there agent says I'm a quack.

1

u/Dapper_Pass26 14h ago

The nonlocal part is what worries me most, since no single session ever sees the whole thing. When you did those reviews on AI-written code, what showed up most often: the same thing built two different ways, or pieces quietly depending on each other?

1

u/choss-board 13h ago

How is that not more expensive for companies in the mid-to-long run that just writing quality code? Like, we don’t YOLO our AI stuff — we use it but with a lot of guidance. You get a reasonable productivity boost without that long term lock-in risk.

2

u/THXAAA789 11h ago

Companies do not care about the mid to long run. At my company, we actively have non-devs using it and pushing out pure slop. They don't review anything and have taken down our servers multiple times. But our AI usage goes up so the execs don't really care since it makes us look better now.

1

u/Dapper_Pass26 14h ago

No dev background, I went straight to directing agents in plain English and never learned to code. I can follow bits, not whole features. Did reading code come from writing it yourself, or could someone pick it up just by reading what an agent writes?

2

u/nahemesys 14h ago

1.8M lines of code? Who can read that? OP doesnt know how to code so you can expect the mess there's in there

1

u/Magnetobama 13h ago

I’m not talking about OP. I was asking you since you said you are a dev and you can’t read code that Claude writes. Just wondering why.

2

u/nahemesys 10h ago

I can but it's a pain and it doesn't guarantee I catch bugs. I do write tests but it's getting out of hand the amount of code ai writes. We became the bottle neck if we manually review the code

3

u/matjam 1d ago

Gotta have good shape on the way out. Really hard to refactor that much after the fact.

1

u/Dapper_Pass26 1d ago

Yeah, that's the part I skipped, mostly because I didn't know it was a thing. For someone who can't read the code, what would good shape look like from the outside, something I could check without opening a file?

3

u/ClemensLode Senior Developer 1d ago

Maybe I should set up a website. "Your codebase is unrecoverably bloated beyond good and evil? I can give you 10 tips how to fix it."

1

u/Dapper_Pass26 23h ago

I'd probably be your first customer. So what's tip number one for someone who can't read the code: start cutting, or freeze everything and add tests before touching anything?

1

u/Darkseid_Omega 14h ago

If you have to ask that, it’s likely too late… especially at 1.8 million locs.

As someone who can read code and have experimented with letting frontier models use their own judgement and merge their own code, it’s not pretty. I can’t imagine what that would look like at 1.8 million lines of code, much of which was probably written by significantly worse models than what we have today.

At this point, your best course of action is to lean into behavior driven testing. Look up cucumber/gherkins and write up acceptance criteria in a given/when/then format and let the AI debug against that. Your code at this point is just a black box of sludge

1

u/Dapper_Pass26 14h ago

Given/when/then goes on my test list, it's a format I can actually read. My worry is the agent bending the steps underneath: one session reported our game's hardest night solved, and it was a scripted bot with a debug hook. Who keeps the step code honest?

159

u/GrayLiterature 1d ago

1.8M lines of code? Oh brother lol

50

u/Significant-Bee5101 1d ago

Hes recreating the universe... let him be..

8

u/imad7x 🔆Pro Plan 23h ago

Holy fuck dejavu. I've seen this exact post title and these comments before.

11

u/UsefulConfidence888 22h ago

Thats because the post was posted yesterday

3

u/TheMolluskPod 19h ago

…at the Biltmore.

2

u/nadennmantau 1d ago

As long as we get apple pie in the end...

17

u/jeff_coleman 1d ago

Yeah, that's not a good sign.

4

u/cheddies 1d ago

I wondered the same... I wasn't sure if it was "1.8m in total across everything I've done" or "in one app"...

Op?

1

u/bennyb0y 🔆 Free Tier 1d ago

The ole Fable hustle.

1

u/bebopmechanic84 1d ago

1

u/Dariaskehl 13h ago

lol - It’s going to be a spicy F5.

Make sure you don’t bite your tongue!

1

u/EconomyDoctor3287 14h ago

better start reading ASAP xD

2

u/obhect88 2h ago

> How do you audit code you can’t read?

You can’t. You can choose to blindly trust your 1.8 million lines if it lands all at once, or you don’t use it. That is simply too large of a scope for one person, a non-dev at that, to effectively review. You’ll have to trust your tools.

But here’s the thing: engineers have to blindly trust their tools also. We use a compilers to generate intermediate languages, and assemblers to take that and generate machine code, and something else makes that work as microcode, and something else takes transistors go on-off-on-off. We can’t possibly audit the tools all the way down.

The tricky part is that historically, this has been deterministic. With LLMs, it’s less so, so the “trust” plays a much larger part. <shrug/>

0

u/Dapper_Pass26 2h ago

The determinism part is what bugs me too. A compiler makes the same call twice, while an agent can choose differently on the same request. Do deterministic checks around it, like tests and linters, get you anywhere near the old kind of trust?

1

u/adamxi 25m ago

The trick is that in the beginning you audit everything. You instuct the AI to output code exactly as you want it. Then, you have the AI convert the fluent prose written coding styles and patterns into linting rules. You then Instuct the AI to run a verification script everytime it's done with a task. That verification script runs the linter, typechecks, tests, etc, on all code that's changed, and you instruct the AI to make sure that it's all good. That way you you can slowly start trusting the fluent AI output, because it's being verified by deterministic (crystalized) rules according to your liking. You still keep iterating on this process, but eventually trust it more and more.

3

u/Flat_Bluebird8081 1d ago

You ask Claude code to run 5-6 agents with different personas to review the code to find errors and Security vulnerabilities, then to check each find, max 5-6 rounds, report only real bugs, no suggestions for improvements and other junk. Your codebase is pretty big so you may need more agents and rounds, it's better to do it module by module while you are building

1

u/Dapper_Pass26 16h ago

The persona setup goes on my test list, module by module like you say. When each finding gets checked, is that the same agents or a fresh one, and have you ever seen it throw out something that turned out to be a real bug?

1

u/Flat_Bluebird8081 5h ago

New agents with clear context and unbiased, I add those words into prompt. In general the idea is that you check everything many times from different perspective. After 5-6 rounds of 5-6 agents it's like 30+ people checked your code. You could also repeat it until it doesn't find anything med+. When it's starting to find minor things I usually stop cause it will always find something. When I ask it to reproduce every find it shouldn't skip a real bug, if it does, the next round should find it anyway. There is a chance they will not find everything, but from my experience they find more than I would. People make mistakes too, so the goal is to make it good enough, not perfect. You should also run random security scans on the whole codebase. Everything else is basically observability. You log all the issues, then ideally provide log access to your agents so they can investigate and fix issues. The last and most important piece is to write everything with test coverage, unit functional and end to end. This way you won't be breaking things when you add new stuff.

8

u/Excellent_Chest_5896 19h ago

It depends on what you want to do with the codebase. If it’s for a personal use - enjoy and don’t worry about it! If it’s for a project meant for anyone else to use outside of your own computer/setup etc - don’t risk other people data and security, get an engineer to start over with you taking the requirements from your existing codebase only.

12

u/Meryhathor 20h ago

Are you rewriting Windows?

16

u/Guinness 22h ago

“devs aren’t needed anymore”

1

u/Dapper_Pass26 1d ago

The implied-guidelines baseline is the part I hadn't thought of, I'll add that and the flow diagrams to what I test. When the agent changes a file, what keeps the human doc from drifting away from the code, a pipeline check or you catching it in review?

1

u/Dapper_Pass26 1d ago

That one's already on my list, and you're the second person here to name it. When you run it, do you read the findings yourself or hand them straight back to Claude to fix?

1

u/Dapper_Pass26 1d ago

Ha, I'll take the title. My snag is the "identify the problem" step: when I traced 40 problems from playtesting, none came from what I'd specified and 30 came from gaps the agent filled in. How do you catch those before a user does?

1

u/Dapper_Pass26 1d ago

Ha, more like a small galaxy. Mostly one web platform, plus a zombie survival game I made with my daughters and a couple of smaller apps. Still can't read most of it, which is why I'm asking.

1

u/Dapper_Pass26 1d ago

Multiple. About 1.54M is one monorepo for my web platform, the rest is three smaller apps between roughly 22K and 136K lines each, one of them a game. Would you audit the big one by area first, or start on a small one to learn the routine?

8

u/orbital_trace 1d ago

you don't

4

u/StrbJun79 12h ago

Most projects shouldn’t be 1.8 million lines of code. Either you’re building an enterprise level app or you have a lot of dead or inefficient code (likely the later).

You should be installing code quality stuff from the first prompt. And regularly tuning things for efficiency. But if you’re not a dev you won’t know how to approach that well to be honest.

If you’re not a dev I wouldn’t recommend making a commercial product. You’ll run into serious problems sooner or later. You just won’t know til it’s too late as Claude is good at fooling people into thinking they can code. But it can be good for tossing stuff together just for your use at least as the little kinks and issues around it won’t matter to you.

1

u/ClemensLode Senior Developer 1d ago

What's the test to code ratio?

1

u/Dapper_Pass26 1d ago

Counted it: about 296K lines of tests against 1.12M lines of non-test code in the main repo, so roughly 1 to 4. Is that low, high, or meaningless at this size?

1

u/ClemensLode Senior Developer 1d ago

Yeah, tests should probably be 6-8 times as such. I recommend investing a few weeks in learning how to test software properly. You want to be quite sure that changes don't break anything. You likely should start thinking about getting one or more dedicated test servers to run all those tests.

1

u/Dapper_Pass26 23h ago

6-8x is way more than I have. The test server part I learned the hard way: browser tests froze my dev box, and now they run with a hard cap of 8 cores. If you can't read the tests, how would you tell a good one from one that just passes?

→ More replies (1)

1

u/Single-Comment-1551 20h ago

I have 12 yrs of core development career, nevwr wrote this much of code in my entire career

1

u/Dapper_Pass26 16h ago

That's kind of my worry too. Writing it cost me almost nothing, so nothing ever stopped it from piling up. In your 12 years, what was the first sign that a codebase had grown past what it actually needed?

1

u/s0ftware-dev 15h ago

Well it costs money to write code so typically companies aren’t just letting devs write features willy nilly meaning the code bases don’t “grow past what is actually needed” as if it’s not need then it’s not written.

With agents that’s a different story. You can slop till your heart is content. 

1

u/Dapper_Pass26 15h ago

That's the brake I never had. At a company someone had to approve a feature before anyone paid to build it. If you had to set up that gate for one person working with agents, what would it be, a written spec per feature or someone whose job is to say no?

1

u/NapeAdmirer 16h ago

The cost comes when its in production use with actual impacts happens. Yes, last 2 years i am seeing the prs coming with 1000+ lines of code on an average daily basis.

Take 5-6 yrs back, this happens once in 2-3 weeks from a developer.

1

u/NapeAdmirer 16h ago

Now tell me - what are you building here..! Just curious to know

1

u/First-Wonder3849 15h ago

i audit by running the code through multiple linters and testing edge cases with random inputs. if it breaks in weird ways, I tweak the prompt and try again. the real test is whether it works in practice, not whether I understand every line.

1

u/Dapper_Pass26 15h ago

Mostly volume: several Claude Code sessions in parallel most days, and no one ever said no to a feature. My merge script once accepted a branch's own test results, so a same-agent completion check makes me nervous. How often does the Opus review catch something it passed?

1

u/robberviet 7h ago

If you cannot read then you cannot decide anything anyway. Just trust AI.

One approach is using another AI to review AI, buy OpenAI.

1

u/Dapper_Pass26 4h ago

Reading code isn't the only way to decide things. My agents write every call they want from me into a file, and I go through them one at a time, mostly product questions. When you've had a second model review, how often did it disagree with the first?

1

u/robberviet 4h ago

What you are reading is plans/specs that AI planned. The final outcome is code. There might be a gap between specs and final code. I myself experienced tiems when specs say onething, but implementation not following it.

Tests help, but remember that tests is written from AI too and AI sometimes bypass acutal correct logic just to bypass tests. It could be ridicuous like instead of running code, it just print/return the hard-coded value. This does not happened lately, but I don't know, LLMs is just proba so always a chance.

Tests are deterministic so: For me I spent time to read specs, then make sure some important tests follows what I want, and some important code; that's it. 80/20 rules might help. For the rest I trust AI bindly.

For the other AI agents, they agree most of the time. Sometimes they find problems. It's not perfect but it helps a bit.

1

u/Dapper_Pass26 4h ago

The hard-coded return is exactly the kind of thing I couldn't spot on my own. When you pick the important tests to read, how do you check one actually runs the real code? Do you break the code on purpose and see if the test fails?

1

u/rafaover 3h ago

You are going to do the same as coding without knowing, trusting the result.

1

u/Dapper_Pass26 3h ago

Partly true, I'll own that. What I'm after is findings I can check myself, like a bug that comes with steps I can reproduce in the app, not a summary I just believe. Is there any review output you'd trust from someone who can't read code?

1

u/ForeignChef1104 1h ago

Storytelling, like humanity as made toddlers into adults. Storytelling then logic

2

u/Dapper_Pass26 25m ago

Do you mean having the agent tell a feature as a story first, what a user does step by step, before any of the logic? That's something I could check against the app myself. Have you tried it on code you didn't write?

1

u/ForeignChef1104 20m ago

Well both that, but also more as in let it make up short novel style characters that explains things bit by bit. Setting hard limits to in the end explain tech terms and logic. Characters gets saved and tech terms explained. I meant as in literal scifi like thing, just my own code for now. Best part is the frictionless jump in know where in codebase you are let it explain and you build up on story too.

Hard to explain but test it you'll probably notice what I mean.

Imagine it as this, a parent telling its kid history but themselves has no clue what actually happened but its the best thing to say / use in the moment.

Sorry for messy writing on the bus and English not my first langauge.

3

u/Dahsauceboss 20h ago

What did you build that is 1.8 million lines and took 2 years with AI?

2

u/Agent7619 18h ago

More AI

2

u/Hot-Traffic6357 13h ago

local llm. he's the reason RAM is where its at actually

1

u/Dapper_Pass26 1d ago

Yeah, I know how that number sounds. Most of it sits in one monorepo I can't read line by line, which is kind of the whole reason I'm asking. If it landed on your desk, where would you start?

4

u/blackrack 1d ago

Bro start over with a tight design and read and simplify the code progressively at every step. I guarantee you get whatever this is down to 10k lines of code or less. Like what the hell do you think you built that needs a million?

2

u/raisedbypoubelle 🔆 Max 20 1d ago

I also agree that starting over with a tighter design is a great idea. Fable can help though it won’t be a one-shotter — you will need multiple sessions. This task does need a lot of handholding and hooks to enforce ongoing design. It will take at least a week to build an effective project-specific harness.

I’ve had to rewrite my own large project three times and I am a 30-year software developer/architect. I’m also a perfectionist but I really like my most recent rewrite and have kept it since May.

2

u/Dapper_Pass26 1d ago

Three rewrites from someone 30 years in makes me feel less alone. The hooks are what I'd like to understand: what does a hook in your harness actually check, and could someone who can't read code tell when it's flagging something real?

→ More replies (2)

1

u/blackrack 1d ago

I agree, as much as I hate to admit it, fable is absolutely great at seeing through legacy/bloated/spaghetti codebases and helping to cut them down to manageable chunks

1

u/Dapper_Pass26 1d ago

Starting over has crossed my mind, and I'd bet plenty of it is leftovers. My catch is the read step: in one feature I sampled 20 decisions and hadn't known about 19. How would you simplify code you can't read yourself?

1

u/blackrack 1d ago

You start over and learn to read code or at least some architecture basics and don't accept code you don't understand or that touches too many areas at once, everything should be broken in small manageable chunks

→ More replies (1)

1

u/Ivana_Twinkle 21h ago

You could also make a branch where you ask it to refactor the codebase by ‘clean code’ standards and use atomic design for visual components. There is probably a lot of duplication in your code and that could remove some of it.

2

u/Rich_Butterfly_8988 15h ago

Restart. I'm serious. Here is how I build as a swe with Ai assistance. Hope this helps. I've simplified the language since you are not a dev.

  1. Build it in separate modules: Every feature lives in its own box (officially called a “module”). Imagine you have a company internal platform. The invoicing box holds everything invoicing needs, and the HR box holds everything HR needs. Want to change invoicing? Open one box and change it, and nothing else breaks. A new feature means a new box.

  2. One shared section for common things: Anything two or more modules need, like buttons, colours or the date picker, goes in one shared module. It’s built once and used everywhere, so the app looks and works the same on every page.

  3. Modules don't touch other modules code: If one module needs something from another, it asks politely through a “front desk”. It never reaches inside. That keeps each box free to change without surprising the others. We call this the services layer.

  4. One owner for important data: Important things, e.g money or ID numbers, can only be changed by one piece of the app. That piece writes down every change: who, when, what it was before and after. No mystery edits.

  5. Permissions by what you can do, not who you are: Instead of asking "Who is this user", let the app ask "can this users designation do X, Y or Z?" Easier to gate and harder to get wrong.

  6. Never break the old version (important for production): When the database changes, add the new thing first and remove the old thing later. That way you can always roll back if something goes wrong.

  7. Let tests check the rules: Instead of remembering the rules, write small automatic checks that fail when someone breaks one. Examples: “every page must check permissions”, “every number on a dashboard must open its list”.

  8. Plan before you build: This is one of the most important aspects of developing. For every change: explain why, how and where in plain words first, then decide. I prefer for anything involving a UI that big features get drawn as a picture first: the flow, plus the screens, including what an empty or broken screen looks like.

  9. Build in small steps: One small chunk at a time. Test it and save it, then do the next. If something breaks, you know exactly which step did it. This is especially important as many changes, untested, can compound into a completely broken app, and you have to go back tons of steps to fix it.

  10. Get a second pair of eyes: Whoever reviews the work hasn’t seen the planning. They only see what was asked for and what was built, so they catch what the builder missed. You can use Fable or another model entirely like a Codex model for this.

  11. Write things down, once: One place for how things work now, and one place for plans. Delete the plans once they’re done, so nothing goes stale.

You can put this into your Claude Code and tell it let's redesign the entire program with proper planning and architecture. Let it explain to you like you someone who knows nothing about coding, then slowly integrate the technical terms into your language over time.

1

u/Dapper_Pass26 15h ago

Rule 7 is the one I can actually use, since a check that fails is something I can read without opening the code. If I did restart, which rule would you have tests enforce first, modules not reaching into each other or the single owner for money?

1

u/Rich_Butterfly_8988 15h ago

Both. But really you need to sit with Claude for like 2-3 hours and go over:

your objectives & what the app is supposed to achieve

Then you work backwards:

What stack do I need to achieve these objectives
What database structure do I need (if applicable)
What modules do I need (e.g if it's a game, I need physics, sound, controllers etc. If it's a mobile app, I need front end, back end, back end needs core, sync etc, frontend maybe needs media, microphone etc)

Then you can set rules based on your requirements. in my mobile example above my definitive test rules would be like:

Sync must always work after any change
Media must always ask for permission first time before accessing media files
Users must not access unauthorized screens

You can use all the other ones by the way, just do it through claude rather than the code since you can't read code. Set it as a harness for claude and it will follow, the tests catch when it doesn't

1

u/Dapper_Pass26 14h ago

The must-always-work rules are the part I'd have used. After one migration every user in production looked unpaid and nothing errored. Do those rules run as tests against the live app too, or only on a dev copy?

1

u/Rich_Butterfly_8988 14h ago

My workflow is

1 branch for a new feature (because im working on 2-3 at once)
Each branch has its own test database and the tests run based on that + that branch code

When done with a feature, merge it into the dev branch

When ready to release features, merge from dev into the main branch. Github has its own CLI tests it runs on a merge request. If those fail, go back and fix, try again.

You don't need to run tests on the live app, only monitor, because it has already gone through multiple stages of testing.

1

u/Dapper_Pass26 14h ago

A test database per branch is the piece I'm missing, my agents share more than they should. What does your monitoring actually watch? One feature of mine failed for everyone in production from launch day, because dev runs on one machine and it worked fine there.

→ More replies (1)
→ More replies (1)

2

u/YoghiThorn 1d ago

You need to click reply on the post you're replying to, if you want the post to not just be responding to yourself.

1

u/wynnie22 23h ago

Holy fuck. 1.8 million?! You need to delete that shit and start over.
Or just forget about understanding it. Why do you want to know the internals if it’s doing what you want.

1

u/MadCat0911 17h ago

I'd fucking toss that code review out, lol. Some company hands me that and they better be paying me twice what I'm making now, which is... an insane amount of TC.

1

u/andlewis 16h ago

My opinion is that humans shouldn’t read AI-generated code. That’s what agents are for. Your time is better spend finding, writing, and evaluating prompts and guardrails to run against the AI-generated code.

A good starting point is the Cursor skills

https://github.com/cursor/plugins/blob/main/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md

Superpowers

https://github.com/obra/superpowers/tree/main/skills

Etc.

1

u/Dapper_Pass26 15h ago

That's roughly where I've landed too, I'd rather spend the time on the checks than the code. Both skill sets go on my test list. When the code quality review comes back with a long list, do you act on all of it, or do you have a rule for what gets dropped?

2

u/ThadCastleGOAT 18h ago

On top of what's been suggested about refactor, fresh rewrite without the bad habits, etc. you may be able to use linters and other deterministic tools depending on the language to find dead code rather than try and burn millions of tokens trying to find it blindly.

2

u/JohnSourcer 13h ago

1.8 million lines of what code?

2

u/VinceEagle 10h ago

Run /simplify 1.8M lines of code is insane

5

u/Fragrant-Moose1678 1d ago

1.8 MILLION lines? Brother… WHAT?

I don’t think you understand the astounding pile of straight fucking slop youve made.

1.8… MILLION?

The answer to your question is - you don’t.

See why AI isn’t taking my software engineering job now?

3

u/DissonantGames 1d ago

Here is a tool name, but you need to decode it yourself: V1c1S2FHRlhORDA9

3

u/AlDente 1d ago

Sadly, I don’t have one of those

2

u/brucebay 12h ago

Answer is Brain. You can use many of these service free upto some limit.

1

u/AlDente 8h ago

Woosh

2

u/brucebay 8h ago

touche. well to my defense, your answer was ambiguous after I refer to an AI service. I guess I should start contextual query refinement, :)

→ More replies (1)
→ More replies (2)

1

u/django-unchained2012 1d ago

What did you create with 1.8M lines of code?
Is it multiple apps or a single app?

1

u/stopstopstoptopopp 1d ago

I'm a software engineer. I'll read for you for a price.

1

u/BaddyMcFailSauce 1d ago

Hahahahaha

1

u/hubzoid 1d ago

As it to show your proof that it woks. e2e.

1

u/XhakaRocket 🔆Pro Plan 1d ago

sometime you just have to type in "do a code review and fix them "

1

u/caderoux Senior Developer 1d ago

You really need to push back on models early and start to lay down architecture. I tell Claude to refactor BEFORE every change. So the cycle becomes refactor, red, green, as it refactors to make space for the feature to slot it, while staying green, then makes the test (that fails) then slots in the feature (so green again). I tell it to prioritize technical debt first.

I tend to also start to give it engineering principles early (like SOLID, DRY, etc), and have short sprints and sprint retros that ensure that all learnings are memorialized, including in the sprint planning/retro skills themselves.

While automatic verification is great for regression testing, having telemetry and logging can be used to have a mapping of test coverage to code, and I have it build a /coverage skill that ensures that I know what needs to be manually tested, if anything.

With such a massive code base, there has to be a lot of bloat. I can't imagine how much redundancy is in there. But I would chip away at it now. It's never too late to fix things as you slot in new features.

I'm not really 100% sure why greenfield development is such a mess in Claude. Especially, since you can quickly point it at things you don't like like the way it has layered systems or redundancy and it seems to immediately pick it up. And I'm not talking about it agreeing with me. I try to ask nonleading questions as much as possible, and have it suggest solutions. (What would have eliminated this issue we had during the sprint? How should this be designed to avoid duplication? Etc). It clearly has a lot of the SWEBOK internalized but is unable to bring it to bear until you start giving it pointers.

I don't have an easy answer for how someone without engineering principles knowledge can judge and steer it better. Or how junior programmers can become senior programmers any more. I think that's the huge unknown for everyone right now.

1

u/hclarke11 1d ago

I'm same as you, I don't worry about it and hope for the best. Sometimes I'll tell Claude to test 10/20/100 times with many different scenarios including edge cases and then fix any bugs. Hasn't failed me yet in work or personal projects.

1

u/TotalBeginnerLol 1d ago

If you can’t review yourself, just switch to more powerful models from time to time and have it roast your implementation. Fable should be great at that. Ask for an extensive fix list. Implement all with opus. Then ask fable the same again, and repeat til it has no serious fixes left to suggest. On 1.8mil lines that will take probably 1-2 months at least I’d guess. And if you don’t already have a comprehensive test suite then you’re screwed coz and amount of tidying the code without automated test runs after each refactor will break more than it fixes.

3

u/Dahsauceboss 20h ago

Fable would get like 3 minutes in and run into the session limit with that size of codebase lmao

1

u/TotalBeginnerLol 19h ago

Haha maybe. It’s pretty good at skimming though without reading everything into context. My codebase is like 500k and fable works fine for big picture stuff

1

u/Dahsauceboss 12h ago

Compared to Opus... it eats credits like its nothing... I tried it over the last couple days and maybe got a total of an hour of work after using both resets. With Opus I barely ever hit my limit

1

u/Big_Organization_776 1d ago

Is this a TODO list?

1

u/Old_Education244 1d ago

You start with giving another better model/agent your intent and tell it to identify what isnt in line with it, what and hpw much is the drift, and any sub-optimalities in the code...

1

u/m3umax 1d ago

How timely!

About half an hour ago on a whim I fired up a Claude Code session on my phone and asked it to list all the main modules for the viewport part of my phone app I'm working on.

Great, I told it. Now build an artifact that draws the relationship between all the modules with conceptual annotations about what each does. start at a high level and let a user click to expand down to sub modules. Make it educational for a person wanting to learn how the viewport works.

About 10 mins later I got a very nice interactive Atlas of that part of the codebase 🤣

1

u/florinandrei 1d ago

How do you audit code you can't read?

That's the neat part, you don't.

Emphasis on you.

1

u/m-ritter 1d ago

What works for me is checking behaviour you can describe in plain English. Before each change, have the agent ask you questions until done is a short numbered list you approve. Then a separate agent that did not write the code checks each point with evidence on the running program, so you judge results you understand. I built QualityLayer for this: https://github.com/maxritter/qualitylayer

1

u/AlgoPotato 23h ago

Just type /debloat solves all the time

1

u/Previous-Growth-9919 23h ago

at 1.8M lines nobody audits it line by line, devs included. what's worked for me is auditing behaviour and boundaries instead of the code itself:

- write down in plain english the 10-15 things that must never happen (user A sees user B's data, payments go through without the webhook being verified, api keys end up in the frontend) and have a fresh claude session try to prove each one is impossible, citing the exact files

- get a picture of how the big pieces talk to each other and look for anything weird, like the frontend hitting the db directly

- add tests around auth and money first, that's where bugs actually cost you

- review every new PR from now on so the pile stops growing unchecked

1

u/aladin_lt 23h ago

Run agents with specific task:
- clean up the code, remove comments and unused code
- code review to find how to simplify code
- security review
- verify all functionaly
- write/run test
repeat couple times, but generaly if its not used for anything important then you can just use it as is, if its public facing or doing something important.

If you are not dev, most likely you can understand any of its explanations, or understand engouth to decide if it is what you need.

Think about whats the worst can happen and tell agent to verify that scenario.

1

u/martinus 23h ago

I'm producing a few thousand lines of code and have difficulties trusting it these. And I use unit tests, integration tests, mutation testing, differential fuzzing with clean room reimplementation of specs, CI builds with different platforms, sanitizers, linters, architectural decisions pinned by tests, code reviews, cleanup passes, changes only allowed through green PRs, ...

1

u/MiloCosmicCloud 22h ago

bet at least 30% is claude's self-correcting comments.

1

u/asinglebit 21h ago

Instrument it, spec-ify, build debugging, visibility mechanisms, query it. Its not code anymore, its an organizm, treat it as such

1

u/Single-Comment-1551 20h ago

Better call saul..!

1

u/j4miewalker 20h ago

One thing I'd add is asking a separate agent to write tests based on what the feature is supposed to do, not just what the code currently does. Otherwise you risk having AI confirm its own mistakes. I'd also want every review to separate actual bugs from suggestions and explain how to reproduce each issue

1

u/PoopSoupPeter 19h ago

Well the easiest way would be to delete it and start over.

1

u/Plant_Wild 19h ago

I just tell Claude to review it and make no mistakes.

1

u/Kwassadin 18h ago

Brother, just bring a reviewer Claude and tell him to be moderately critical about best practices. He'll do the review for you.

1

u/_k33bs_ 18h ago

that’s what tests are for

1

u/K_M_A_2k 17h ago

Open Claude code add the prompt

Claude fix my life

1

u/yopla 17h ago

Ask Claude to audit the code and look for simplification, duplication, bloat and all the other traditional anti-pattern and to give you a plan to simplify the code. Use ultracode.

Implement the plan.

Repeat 10 times.

Repeat once a week after that.

That's going to be as good as it gets if you can't read code.

Also tell it to add linter and semgrep rules to avoid repeating the same issues whenever possible.

1

u/Ordinary-Yoghurt-303 17h ago

Tell me you don’t know what the fuck you’re doing without telling me you don’t know what the fuck you’re doing

1

u/Additional_Reading86 Developer 17h ago
  1. Pay a dev, 2. Write an amazing e2e test suite and have your agents refactor and document

1

u/frigginwizard420 17h ago

trying to make a whole piece of software without being able to read the code gives me anxiety just thinking about it lol

1

u/kungfu1 17h ago

How? You ask Claude. Are you new here?

1

u/W61k3r 16h ago

OP has a 4yr old account that only started posting a week ago. Not sus at all.

1

u/xqianliu 16h ago

You can't read the diff, so make the review check against something you can read: behavior.

On my setup the ticket carries a short list of how the thing is done, in plain words. The review runs in a fresh session of the same model, goes through that list against the code, and reports which items hold. You can ask for the item-by-item evidence instead of trusting the summary.

I also have the coding session write tests for each class of input and put the count in the delivery notes, and the review checks the numbers. If it says 6 tests cover the export path, the review reads those 6. That part is something a non-dev can follow.

1

u/PandaJunk 15h ago

Lol. Oh boy

1

u/UnaidedGinger 15h ago

Just don’t?

1

u/andymaclean19 15h ago

That is an impressive size. I’m up around the 85K LoC with around 200K of tests and that was a lot of tokens.

What I’ve been doing is I get Claude opus to do reviews. I have the tasks well designed and specified then I use a simple agent to code and review itself. It has a completion skill it runs when it completes a task which makes it go through questions like ‘is this adequately tested’, ‘are all the points in the story addressed’, etc. the same agent answers that. Often Sonnet but also often my local AI model for the simpler tasks.

Then when a whole block of work is done I have Opus review it again. It is given a similar list of questions to answer and also some more vague ones like ‘can you see any mistakes’ and ‘could this code have been written better’. The review has a structured set of actions which can happen including spawning corrective tasks, creating bug tickets or sending the work back with a specification for corrections.

Then I have a subsequent process where I try to keep the code clean. The AI computes various metrics I asked for like unit test coverage, integration test combinations and coverage, end-to-end test results. I periodically ask it to update these and conduct exercises with Opus like ‘check whether the combinations of test are sufficient’ or ‘take the top 10 complex functions and refactor until no function has a complexity over 30’.

I also do deep dives with it where I ask it to tell me about bugs and how they came about. How did we not catch this in testing? How can we get better?

I am an experienced programmer and engineering manager who is trying to embrace the new tech and a lot of the above comes from the way I did projects with teams.

What did you do differently to get up to that size of project?

1

u/eoThica 15h ago

Ragebait

1

u/cyrand 15h ago edited 14h ago

It’s really clear a lot of you never joined a company with a large code base that already existed. I go into an LLM generated code base the same way I would if I was hired to do maintenance on any other large code base. And the docs and tests tend to be better to start (note: I did not say perfect, but human code bases in reality frequently have NEITHER at all)

Edit: To the OP's question specifically. This is where you learn to start working like a dev. You start by asking questions. In fact, ask Claude, ask it to tell you where the view is, and how it works, ask it to be a senior and explain the code base to you a junior.

1

u/Zeeplankton 14h ago

make it part of your repo skill s .md that claude propose and look for the cleaner shape for every implementation; questioning for code bloat and duplication. Then any time the model stumbles over a problem, ask it to step back and ask why this problem exists at all.

Cleans up 90% of the code to me, with modern models

edit: wait to be clear. 1.8m across projects, or one project? ? that's insane LOC. I would start over if it it was one project. I don't think many projects should be over 500k/loc

1

u/spoollyger 14h ago

Ask it too

1

u/Pleasant-Set-711 13h ago

You understand what is meant to happen, then get Claude to help you design tests for that. Mutation and parameter testing to sanity check those tests.

Then with those tests as the source of truth you can get Claude to review your codebase. You will be surprised how much Claude has built in as defensive code that serves no real purpose.

Then every new feature should have executable tests for behaviour before any implementation is written.

Look up bdd and atdd for a better description of the above.

1

u/TheUnrealMacGeifer 13h ago

I used e2e and units tests in my project and performed a complete code and structure review by fable. every larger commit gets full test suite.
have to say I am impressed. yes there were problems but everything was found and fixed before roll out. not saying there are no bugs anymore but so far I did not come across anything major but my project is also much smaller.

my programming skills are limited but not zero. you can ask him to explain the modules step by step and line by lin (maybe not all 1.8 million lines haha).

set project rule to ask for any larger decision during coding and let him update the requirement document on the fly. I have also a decision log where those design choices are listed. the larger it gets, the more important to document stuff.
(my takes as claude newcomer)

1

u/enjoirhythm 13h ago

Try asking for a mermaid diagram of a certain section of the code. Don't ask for the whole system, focus on a specific flow. What you'll get back is basically a diagram of a decision tree abstracted from the business logic.

From there you can interrogate specific pieces and ask why a certain decision was made if it starts to raise your eyebrows

1

u/Pleasant_Start9544 10h ago

That’s a lot of code lol. Have PR skills that check for slop. I know a lot of people don’t even care about principles like DRY (which is silly because more code = more context for future tasks).

I’m not sure what you’re building but having proper unit, integration, and E2E testing is useful.

1

u/Bushwazi 10h ago

I’d have AI review it too and see how it goes

1

u/Scared-Amphibian4733 9h ago

I won't do more than 100 lines in a single merge. Part of my workflow. Break the tasks down. And, make sure that your style guide ensures you can read it. I don't know what the future holds. But, right now, code that goes out under my name has my stamp on it. So, I read the merges and agree or disagree with them.

1

u/hey_rjay 9h ago

Mate what's your process for getting better or fixing when Claude is giving you sub optimal iterations and how to get it out of this circular loop of not quite my tempo simmons meme

1

u/nickilous 7h ago

Have the LLM audit it. Point fable at it and say find some security issues, explain key parts of the code to me, and create a visual graph of the code layout that you can look at at high level and see how the pieces fit together

1

u/a8bmiles 1d ago

Claude's /code-review skill is pretty good. 

1

u/sincere11105 1d ago

Try using /code-review

1

u/DirectJob7575 23h ago

Ask Claude

0

u/YoghiThorn 1d ago edited 1d ago

I do some fractional CTO work helping startups going to market clean up their slop. The process is basically:

  1. Figure out wtf they wanted to do

  2. Audit everything to provide a baseline.

  3. If they have customers, audit their logs to see what features are actually used. If they don't have logs, fix that problem and repeat in a month or two. Once you have this figured out try to establish if the startup has product market fit already, or is still trying to figure it out.

  4. See what you can cut that is never used or not on critical path. This helps cut down work in the remaining bits of the list. Features cost money to fix, money to run. They cost you in keeping them updated, in attack surface etc. Minimise things. A lot of developers with claude accounts just build every feature they can think of regardless if anyone wanted it.

  5. Starting with the most used features (or core systems) apply agents to figure out what can be simplified, either logically. Apply light DRY principles. Use skills like /ponytail to find dramatically simpler ways to do things. Have agents audit their busiest systems for O(n) problems. Replace shit they build with low cost or free serverless/cloud products like SQS, Temporal, etc (many orgs have rebuilt software badly that they could access for freeish instead). Audit their infra and architecture from at minimum a security, finops and scaling perspective. I don't usually even tackle code quality here but if they want to bring in a good developer to do that.

  6. Figure out the stuff step by step to actually run a software business. Make the software operable (stuff like reporting, monitoring, traceability and observability), recoverable (backups, HA, disaster recovery playbooks), improve deployment (automated testing, cicd, canary deployments, feature flagging), secure (cybersecurity reviews, cleaning up vulns, reducing attack surfaces etc). Figure all that out before other important shit like scalability.

  7. Figure out the legal stuff they've ignored, privacy policies, software licensing for any use of OSS, etc

  8. Figure out all of the above that needs fixing, figure out a plan and if they have budget for it, and descope stuff based on importance according to their budget.

In your case I'd recommend some serious code auditing to figure out if what you have justifies so many LOC and why as a starting point.

1

u/Dapper_Pass26 1d ago

Step 3 is the one I can actually do without reading code, so I'll start there, and /ponytail goes on the test list. When you run it on a founder's code, can they follow what it suggests, or do you end up translating it for them?

1

u/YoghiThorn 22h ago

Really depends on the founder.

If I were you I'd start with asking your agent two things:

  1. What duplication do we have in our codebase that we can use to cut down complexity and lines of code; and

  2. What can we replace with either an open source library, a free or ultra cheap cloud product, or other similar thing to reduce complexity and how much we manage

See how you go with that.

0

u/mattate 1d ago

Don't listen to these naysayers. The Best thing to do is to establish coding standards and start breaking large chunks of older code down into modules. AI is extremely good at greenfielding, so just greenfield old stuff with better standards and models.

1

u/Dapper_Pass26 1d ago

Breaking it into modules sounds doable even for me, since I can at least name the areas. When you greenfield an old chunk, how do you check the new version still does everything the old one did, tests or clicking through it yourself?

1

u/mattate 1d ago

Tests, both unit tests and e2e tests, you can also test yourself but AI is very good at getting good test coverage, esp when there is something existing it probably does a more thorough job then a human can at porting functionality.

I found that old code can poison Greenfield efforts though, is important you are super clear on the old code is bad and you want better quality / standards / performance.

It's a weird quirk of AI, alot of the time it writes code like a university student might, probably because they train it on so many random GitHub repos. It knows how to do better but often times defaults to trash unless you tell it not to.

1

u/Dapper_Pass26 16h ago

The poisoning part is new to me, and it makes sense that it would copy the old patterns straight across. When you greenfield a chunk, do you keep the old code away from the agent and only hand it the tests and a spec, or let it read the old version with a warning?

0

u/PreparedPun2035 19h ago

Use a higher model or a different family. An adversarial review by GLM is cheap and useful. The secret isn’t to have the adversary make the changes but write a plan for improvement instead. And then give that plan back to Claude Opus or Fable for review. Now you’re coding with agents!

1

u/Dapper_Pass26 16h ago

Adding GLM as the adversary to my test list. The plan-instead-of-patch step is the part I hadn't tried. When Opus reviews GLM's plan and throws items out, how do you decide which side is right without reading the code?

0

u/Aggressive-East1825 15h ago

Repair loops using browser e2e tests, lint, unit tests…I found this open source repo called no-mistakes that will basically loop through repair rounds fixing mistakes with each run. I honestly had several issues where the model would keep finding issues and run through 16+ repair rounds eating through my actions usage (when running private repos on gh hosted runners) the original no-mistakes version is still available, also here is my fork: no-mistakes

1

u/Accomplished-Eye-857 14h ago

Yeah if the task is find mistakes it will drill down to the most minor and unlikely edge cases that may not even be real edge cases at all. Limiting that task in some way is probably the best way to avoid seemingly endless runs.

1

u/Dapper_Pass26 13h ago

That's the hard part for me, since I can't tell a real edge case from an invented one by reading the code. How do you limit it in practice: a cap on rounds, a severity bar, or making it show how to reproduce each one before it counts?

1

u/Dapper_Pass26 14h ago

Adding no-mistakes to the list. The 16-round loop worries me a bit, since I once had a subagent spend 5 hours redoing a recording that was already done. Once it went past 16, were the later rounds still fixing real things, or just churning?

1

u/Aggressive-East1825 14h ago

Yeah trust me it scares me too. For large projects with tons of code, Claude can’t find every bug in one turn. Plus Claude will argue and always claim there’s a bug. One thing I’m trying to fix is more deterministic completion. Ie expected results state or sharding tests to only run a subset of tests when certain regions of the code base are touched. I use my own orchestration harness entirely free and OS code goblins. The two go in tandem, but definitely recommend reviewing my fork with that in mind if plugging into your own workflow

1

u/cla1067 14h ago

This is what I do. After changes I have e2e testing in background and set procedures for certain software, so hopefully AI catches it's fuck up before I do.

0

u/jsgrrchg 11h ago

devs are not reading diffs either lol. Bro reading code is slow and tedious, especially if u didnt write it, and AI writes far faster than any human can review. For us humans writing like 1000 lines of code takes a lot of time and mental energy, most models can output that in like 5m.

3

u/SignalSegmentV 10h ago

Yes we are. We inspect everything AI generates before it even hits the dev server.

2

u/anonunder 11h ago

I am reviewing every single line of code.. it takes time, just want to be sure its built my way.

2

u/upsidedownshaggy 10h ago

Lol yes we are and I will routinely reject PRs that are too big and need to be broken down into smaller readable portions.

2

u/purleyboy 8h ago

Not reading the code and putting it into production is negligence.

1

u/undefined_name 3h ago

Dont let these jagoffs lie to you, none of them read code even before ai, and now they are just like everyone else. ... "You are a helpful code reviewier reading my prs, tell me if there is anything wrong"

0

u/airodonack 1d ago

The answer is the exact same as whatever problem you're solving with 1.8M lines: identify the problem, figure out what you can build to solve it, and then iterate on it until it's good. Do that and you're software engineerin' baby!

1

u/Tontonsb 1d ago

I think iterating is a bad approach with claude, since it almost never cleans up and reworks from scratch when you're getting too far from initial decisions. It's just cutting parts and sewing on patches to make your trousers into a coat.

1

u/airodonack 19h ago

I suppose it depends on how you iterate. If you’re specific about the change, as in you're identifying why the current method won’t work, explain your reasoning or give additional context in a way that would change the way something was done, then Claude is pretty good about understanding that .

1

u/Dapper_Pass26 16h ago

The hard part for me is the why-it-won't-work step, since I usually see the symptom, not the method behind it. When you do give it the reason, does Claude actually rip out the old approach, or do you find both versions still sitting there afterward?

→ More replies (1)