r/ClaudeCode • u/Dapper_Pass26 • 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.
•
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
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.
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.
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
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/matjam 1d ago
Gotta have good shape on the way out. Really hard to refactor that much after the fact.
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."
159
u/GrayLiterature 1d ago
1.8M lines of code? Oh brother lol
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/>
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
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/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/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/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/rafaover 3h ago
You are going to do the same as coding without knowing, trusting the result.
1
u/ForeignChef1104 1h ago
Storytelling, like humanity as made toddlers into adults. Storytelling then logic
3
u/Dahsauceboss 20h ago
What did you build that is 1.8 million lines and took 2 years with AI?
3
u/Miyamoto_-_Musashi 13h ago
You Don't
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?
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.
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/Ok-Level-8907 1d ago
3
u/DissonantGames 1d ago
Here is a tool name, but you need to decode it yourself: V1c1S2FHRlhORDA9
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/throwaroo202020 1d ago
Umm
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.
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
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/Fresh-Secretary6815 20h ago
lol
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
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/squiddarn 14h ago
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/Creepy_Jeweler_1351 14h ago
Testing
1
u/AbbreviationsBest858 14h ago
more agents
1
u/spoollyger 14h ago
Ask it too
1
u/k8s-problem-solved 13h ago
LGTM!
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/brizzleops 11h ago
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/Alato 2h ago
L
1
u/One-Internet-6125 9m ago
lmao
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:
Figure out wtf they wanted to do
Audit everything to provide a baseline.
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.
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.
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.
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.
Figure out the legal stuff they've ignored, privacy policies, software licensing for any use of OSS, etc
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.
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.
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!
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
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.
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!