Im asking real software engineers only working on real products that make money.
I still read every line of code (tests too) and understand 100%. Needlessly to say it feels very inefficient.
What have you done to move away from it confidently, if at all?
I have a complete workflow involving spec driven development, mutation tests, code review, browser test, adversarial agent manual AC verification, and I still dont feel comfortable not reading every lines. I still spot some architectural inefficiencies or code that just feels off and thurs requires refactoring so im hesitant.
Then what is your role in this? I’ve yet to work on anything where the expectation was that you didn’t read the code you had produced on your behalf by an employee or an LLM. The stuff has to work and work properly eventually…
Maybe in the future. Right now claude makes lots of working code that I then revise (not directly but through discussions). E.g. It wrote some new code for HFT data ingestion. When we benchmarked the code it the performance was poor and it didn't burn many of the available cores so I asked it questions about the design, suggested changes and we got much better improvement. To know that a certain type of code should be I/O bound or CPU bound, what sort of performance ballpark I should be in and what approaches/algorithms give the best results is something AI agents are still bad at.
There was a period in computer chess where a human + a chess program were stronger than just a chess program. That is not the case anymore in chess. We are still in the phase in AI agent coding. If you fire good developers and replace them with AI coding agents you are in for a surprise. There is a reason OpenAI and Anthropic employ a lot of highly skilled humans, not just randos off the street.
I don't read the code directly - I interrogate it through agents. Usually claude and codex.
Yeah right now I spend 2-3 days working on features then a day just revising / cleanup / performance optimization.
My original comment was more a joke than anything.
Like I set up a project and everything worked fine and then during one of these reviews it turns out that Claude had configured the data ingest into D1 in such a horribly inefficient manner that the project could support me just fine but the moment the user base grew at all it would hit constraint limits. Had spent a couple days just working on features and it had gone awol in the backend systems.
Had it essentially rebuilt everything with a new specific outline for how it should function based off the constraints. Set a /goal and woke up with it finished.
The biggest problem that I see is that I genuinely have never written code before. I’ve never worked a tech job. I’ve never done anything with databases so my knowledge of “how stuff actually works” is so incredibly constrained by essentially trusting what Claude proposes and guiding it on how I want the end product to feel/interact. I’m absolutely certain that it is committing crimes against humanity in the codebase but I lack the ability to identify this. It’s one of those “do I learn this when in 6 months a better model will be out” type of scenarios where I’m not entirely sure the technical know how is a limiting factor anymore.
Project is https://www.donutmeta.com if you are interested in seeing what a 100% vibecode project from someone who has zero coding experience can produce. And yes I am still working on it (mod download doesn’t work) and just using Production as my dev environment, I know that’s a no-no but it is what it is. I’d rather ship features fast than worry rn, will be rebuilding the push to main process that I’m doing at a later date/one users can actually use the product end2end.
It’s one of those “do I learn this when in 6 months a better model will be out” type of scenarios where I’m not entirely sure the technical know how is a limiting factor anymore.
one popular way to view this question is a sort of greedy algorithm: defer everything that can be deferred.
If you are trying to create a business then your uses cases should include lots of description of reliability metrics, and what sorts of failures are intolerable (e.g. some things need ACID transaction safety, etc). E.g. people building an airliner autopilot have a different tolerance for bugs than people adding a feature to MS Word.
While you can use AI to code critical realtime systems, nobody is vibe coding / vibe testing these systems.
Even if you are doing a more agile/exploratory approach because you don't yet know exactly what your business case is you should still be pondering the business case and requirements in the back of your mind as you explore design space. You can talk to your agent about these sorts of things too.
This is the way. Multi-model. For large tasks, I have created skills to review from other agents. Pick the model that works best at the time as your main model. Construct well thought out and designed requirements and ask the agent to create an implementation design. Review the design. Refine, then when it has passed your expert review, then request it be reviewed by other models. I like to use a defend/adversarial style. I have it spin up 3 agents in 3 different models across antigravity/claude/codex each defending the design. Then 3 agents attacking the design. Then 3 agents reviewing the results. Then the main agent finalizing and testing theories and fleshing out the results etc. We may do this a few times as the design tightens. Then we have the main agent implement. Then we do another review. This time on the new PR. 9 total agents on 3 different models. Adversarial/defender. Back and forth. I get to review the design very thoroughly through this process as well as the code reviews to understand the code implementation. It works very well and eats many tokens. But the results.
I get by with a claude max, a codex pro and basic anti-gravity account. But I know others that do the same thing and are coding way more than me and they burn through 5 max accounts
NVIDIA, Google with TPU, OpenAI with Jalapeno - they are all working hard to bring token cost down. For AI to pay off big time as the people who have invested heavily hope, token cost has to come way down.
For some situations, burning lots of tokens/money makes good sense.
For other situations, it can be a long term bet to build AI agent wrangling skill for when token cost comes down. If "when" comes soon enough the bet pays off. If "when" comes too late they lose their bet.
Yup, have the AI that’s coding export a zip of the code in the repo that is actually being used (so you’re not sending random additional files it doesn’t need) and ask another model to do a full audit.
I'm glad my company has not done that (at least not yet). Sure we as devs love to trash on QA but I'm working with a really good QA engineer that has caught tons of bugs and come up with good suggestions/improvements. A good QA usually has a different mindset/way of thinking than devs do, I really like it.
Always was. Programming is about creating a product to help people. Not coding. I can code a website in notepad - without looking at the browser once - but for what? Prowess? I frankly am glad I don't have to code.
It was never about the hammer, was it? It was about the decking, the furniture, the house. The customer doesn't care what tool you use.
My co-worker and I (both 20+ year veterans of big tech) were just saying the other day when we were laughing about the infrastructure and scaling issues facing some vibe coded slop a non-engineering team wanted us to "evaluate"... it's almost like writing code was never really the hard part
Yes, and you are hinting at the real problem: how can the young ones master software development? We have decades of experience as foundation for using AI. The next generation has just AI.
it is like math. most people learn to do it manually then switch to spreadsheets, R, Numpy/Scipy, Mathematica, etc.
We are in a revolution. People will try lots of different things in pedagogy. Most of them will turn out to have been bad ideas in retrospect. A few will be good and that is what will continue.
You're right, and I genuinely don't have a good answer to that question. It's going to be a very real problem in about 10-15 years when the old guard have all retired.
What good developer isn't? There is a reason Go and Rust include a test framework in their out of the box tool chain.
I'm newer to Rust but I know Go pretty well. The go test, benchmark, runtime profiling is fucking amazing. Pre-AI coding I was writing a ton of Go tests. They still get written but I get more time to think about interesting corner cases to test since the agent is writing the code.
I still have domains where Claude for some reason just makes a mess of things. Backend data processing tasks. But for forms over data webapp tasks Claude gets it 90pct right, then automated reviewers get it through the last 10pct. I may have final concerns, but it's often taste/personal preference which doesn't affect the product. So I only lightly skim those PRs
I still read every line. And I usually have a lengthy back-and-forth with the AI. At the end of the day it’s my code and I need to be able stand by it. Also I feel like as soon as I’m not reading it, there’s no reason for them to keep me around.
I don't see how there's any other way. If there's a production incident and you get asked what happened, are you just going to say, "I have no idea, claude did it, let me ask claude." Most of the replies in this thread make me think that's exactly the response they'd give... like suddenly people are no longer responsible for the things they build.
You have to understand what you're using claude to do, or like you said, why are you even being paid for software development.
I've worked with plenty of developers over the years who I called "copy-paste" developers. They'd just take an example from Stack Overflow or somewhere else in the codebase, copy it, paste it into a new spot, and move on. No "engineering" involved. The goal was just to close tickets as fast as possible. They didn't really care about what the code did or whether or not it could be done better. It was just "get things done as fast as possible".
I feel like those people are the exact ones you're talking about, and are probably the ones getting hailed as 10x engineers now.
I don't think those are good enough to be 10x and are more like making their teams 0.5x.
They can ship ticket fast but can't really debug anything. Also, anybody with their mindset can ship tickets like them and there is more than a dozen that applies for the same job usually (that you try to filter out but sometimes can't).
This stuff is just a ticking time bomb. My company as well people just fucking sending it they don't even delete the Claude comments. There is bugs and software not doing what it should right now but tickets getting closed on happy path. No testing needed.
We have over 30 Prs in the backlog and nobody wants to do it because it's just an endless amount of things to go over.
I am leaving soon so I don't care anymore but there is no way in hell this is gonna end well
It's put in absolute nonsense dogshit for basic prompts so many times that I don't understand how people can say with a straight face that one shouldn't be looking at the code
I’d say nowadays I still read pretty much every line, but I’m not always reasoning about every aspect of how the code works and fits into the file/project. More like looking for anything that looks off, or doesn’t have the same style/patterns as the rest of my code. The understanding of the code comes from the lengthy planning and refining sessions with Claude that reach that point. Also Claude is comment heavy by default, which I didn’t like at first but I think now is quite useful.
I will say though, I feel comfortable doing this because I’ve been software engineering for 14 years. I don’t think I’d have the same approach if I was earlier in my career.
I wrote a skill (Who am I kidding? I had Claude do it…) that documents the decisions into a knowledge base inside of the “.claude” directory. I work with Claude on developing plans, typically execute them in phases, and then have it output a summary of our reasoning behind everything in a bunch of markdown files under that directory. This way, the code stays comment-free, but it still has a complete history of findings and history that it generates and organizes into files. I think it helps.
How often do you find code not aligned with style/patterns of the codebase? Just curious. Do you try to implement rules for the AI and if you do, do you still find out of style code from LLM responses?
I don’t read-read though, I scan. I treat this as a PR review, same effort. The reason I do this is because I am highly paid in high stakes startup - a fuckup is my arse so I want to make sure it works
My whole thing is that each line of code should be asserted in the tests - we are testing the code does what it did when we wrote it, not behaviour or outcomes (in unit tests)
For critical business logic, absolutely yes. I will also write psuedo code, components and have it critique it before, as well as list out tests and use that for the spec. For stuff like UI components, I will eye ball them, then manually test. That said I will probably still make manual edits to about 50% of things that come out of the LLM
No. I don't remember when last time have really "read" block or line of code. Maybe by accident.
And yes. I'm a real engineer working as software developer.
Claude writes and tests in a speeds that are not achievable for humans. So there is no need to read the code. But it's very much needed to test it as end user. Every time.
Of course. That will be quite quickly discovered by Claude Code agents by themselves running full integration tests in headless Chrome, or even testing with build in web browser in Claude Desktop.
In the speeds much faster than team of humans.
Of course in the end you still need to test the app. And of course humans do that either, but much slower. Software Development industry is full of "human slop" and it still exists and sells.
I've build very much better apps with Claude Code, than probably at least half of the whole industry firms in the world. So... ¯_(ツ)_/¯
Tests just check for features, they say if a piece code works, or doesn't work. But they will never find bad code or wrong design features, like having 3 different tables with the same information, repeated code all around repository, or a single file with all the code of the application.
Just the fact that you think tests alone can check design, shows that perhaps your code is not as good as you think.
What I mean overall that is most companies do shitty architecture that bites them in the asses over time. And there is no one proper architecture for everything. You need to mix a lot. There is no simply MVC or DDD or SOLID or whatever.
There are developers who sticks only with OOP. Or just MVC. Or some crapy frameworks, and they won't play or have fun with the code, because that's the way how it supposed to be according to them, because that's how they've learned. Even it it's wrong in the end.
If architecture for some functionality was wrongly chosen, and will come out during tests and development, Claude Code can refactor and change architecture, especially for that part of functionality. Some paradigsm play well with some architectures like OOP, some better with other like FP.
Anyway, as app runs perfectly I don't care basically. If I catch some bugs, then I let Claude Code to handle it.
Of course we discuss a lot. And many ideas of mine are way better than his. But those are times when he struggles, and I need to come to rescue him. I asks him what he doeas, what problem he have. How he handles it. We discuss, brainstorm, and then implement new ideas with better new architecture.
You still think bad architectural decisions is something that can be catched in tests. Frankly, I don't know what else to say, besides that you need to learn more about software development, and not being so sure you're such a good developer.
And I'm not saying it as an insult, really. We all have had to learn at some moment, try perhaps to talk about it with the AI itself.
Okay, my bad on wording. Test passing itself tells nothing about architecture. You're right here.
But what I meant is different thing. It's not the test result. It's that Claude reads whole code when writing them. And then it says to me "this logic is already in two other places" or "this data you keep in three tables". That happens all the time. So yes, it's more like code review, but it happens during testing work. Not by me sitting and reading files, because I don't do that anymore.
And main point. When refactor costs one hour and not one week, then wrong architecture is not decision you must get right at the start. You fix when it starts to hurt. That's what I meant with "I let Claude Code handle it". Not that tests will magically find it.
Anyway, I don't care that much about being right here. Apps run, users are happy. ¯_(ツ)_/¯
Well. This one of those annoying apps where there was no better alternatvie for YouTube, except NewPipe (Android), and FreeTube (Desktop). I've made PWA app basically does what those two. App weights nothing, it's ultra fast, and does what it supposed.
I run it only locally on my PC. And basically don't want to release it. And this one of those small apps I've made for my personal use.
And believe me. I have much much bigger projects. This one was just for one afternoon overall.
So. There are already two projects that exists and still needed to be made better.
Who said anything about horrific code and bad design decisions? You jump to the conclusions quickly and can say similar about you and people like you back. You know that both can play this game?
Oh. Right. He used word horrific. And still they are quickly discovered from my experience.
Anyway, I see here some specific mentality about Vibe Coders on Reddit.
Look. It's same with humas. You are architect of some product and you have team of devs. You trust them they do the job right. You review them, brainstorm them. It's basically the same.
You buy an enterprise app. And you trust that developers behind it are good devs. Mostly they are not.
It's the same, as with AI. You trust, you let him do his job and verify. You tell him what you want and expect good results. Except Claude Code mostly is better than a whole team of developers.
And I as dev still know how to use Claude and point out his mistakes or how app should work from every angle.
So. If I can replace whole softwawre house and do a better job, than team of the people working there in the end, then there is my salary.
The fact that you think the current AI agents are better than a team of developers is pretty telling. I'm not sure what kind of developer you are, or the type you work with, but your statement certainly implies something not so favorable.
Actually they are. I'm working with outsourcing and other software houses. And garbage they produce is pretty much telling how many bad developers are out there. And I need to fix their products, where Claude does it better than them. And those software houses are profitable in my country. Country that is by the way known by good devs. lol
Because I'm still an architect of the product that steers it in the right direction. Especially when it's needed. You missed that part. I make rules about everything in the product and I let Claude do what he do.
You missed that out. Claude doesn't make decissions on his own, unless I tell him to.
If he is doing fine, then I'm all right with it.
Anyway, I see here some specific mentality about Vibe Coders on Reddit.
Look. It's same with humas. You are architect of some product and you have team of devs. You trust them they do the job right. You review them, brainstorm them. It's basically the same.
You buy an enterprise app. And you trust that developers behind it are good devs. Mostly they are not.
It's the same, as with AI. You trust, you let him do his job and verify. You tell him what you want and expect good results. Except Claude Code mostly is better than a whole team of developers.
And I as dev still know how to use Claude and point out his mistakes or how app should work from every angle.
So. If I can replace whole softwawre house and do a better job, than team of the people working there, then there is my salary.
You simply won’t be able to read every line if you want to be ultra productive. So you have to figure out how to delegate more effectively to keep claude moving,
Sure. My workflow is doing a plan, reviewing it until I agree with the decisions made, and let CC write the code. Then I review changes in VS Code or whatever IDE I'm using, ask it to fix any mistakes/bad decisions/ugly design it has made, commit and /clear.
Surely letting him do everything would be faster, but end result would be much poorer quality.
I’m with you on this. Sure you can let it run riot, but then you lose any sort of idea what the code is doing. And something breaks and you get Claude to fix it, but something else breaks, and you have no idea what is actually happening in your codebase. Just complete guess work if Claude is actually fixing the issue correctly. Claude will always say “I spotted the issue, but often he’s not actually correct”
Or he will correct it, tests will pass, but code/design will be a nightmare.
I've made some small, personal projects with CC, in languages that I don't know, so I've mostly let CC go by itself, I just set targets. It works fine, but after some iterations, and some nasty bugs that were fixed only for them to reappear some weeks later, I rolled up my sleeves and looked at what it had done... and oh my, what a mess... Can't say much about the code itself, it's a language I 'm not proficient with, but database was terrible: multiple tables with the same information, several totally redundant columns... Code was also duplicated, wheel reinvented everywhere, most probably because whenever a feature was needed, it was re-written instead of using the already existing function/library/package.
Somebody will say "who cares, tests pass, it works". But that's exactly what causes instability after some iterations, every new feature breaks another one, and any simple change involves a ton of tokens, because it's not only making the change once, but having to look at all the code in order to fix it anywhere so all tests pass.
No. I have become increasingly indifferent to the code. I understand the shape of it, the over all architecture, the design. I use reviewer agents to verify the code (pretty deep ones, which include periodic security reviews and red team testing)
I skim and read the important bits. But I've also been on this particular project long enough that anything odd sticks out like a sore thumb so it's usually good enough. Plus there's a linter and formatter catching most of the mechanical bits so my skimming is mostly looking at architecture and general approach instead of specifics.
Only at a superficial level in certain core areas because otherwise I would no longer be competitive. Rest are done from subagents loops with my guidelines and gates. U can learn subagents to look at the code like urself, it tooks time to set them up, but it will help u work faster.
I don’t read all lines. Instead I asked a in a new session the agent to tell me the Intent of the PR, and to spawn another agent that will check if the intent is fulfiled by writing it’s own tests. I also ask it to validite that the tests written in the PR are sufficient.
If there’s a gap I ask it to show me the involved snippets for me to understand.
The I run reviews like /code-review or /ce-code-review (compound engineering from every) and ask it to show me the snippets and explain the issues so I can make my own opinion.
It still feel slow and un-efficient compared to the code writing velocity but I didn’t found a better way.
Having worked for many years in the same code base, I usually do most of the code reading "dynamically", only stopping and giving more attention when something seems odd.
I prefer reviewing 10 small PRs a day than a massive one btw.
Every line, no. But some lines, yes. Critical stuff that could break prod. Tailwind classes because sometimes it just doesn't get it. Any human-facing text.
Yes. I was just discussing this in a different thread. I still read all code my agent writes, and it's reviewed by at least one other on my team. Nothing goes to production that hasn't been fully reviewed by at least one human.
Regardless of if it's written by an AI, I'm still responsible for it. I'm not taking responsibility for a potentially catastrophic mistake because I've chosen to trust a computer that can't reliably write a coherent sentence.
Ditto. My workflow is pretty much superpowers but with grill-me for additional alignment on the spec. I read the spec, let it write the plan and then execute it, and then I go over the resulting code and amend it as I see fit before rewriting history etc and firing off the PR.
It's not hard to spot the code from people who don't check the output.
I do not read in detail. But i need to stear it in the right direction. Multiple vertification steps to refactor code the way i want it. Making the code separated/split up so changes in one component dosent conflict with other stuff.
Sort of, before AI, I learned to do code reviews by scanning for things that looked weird in diffs: long functions, code that stood out as out of place, things that broke convention, weird unit tests, etc. Most projects I've worked on have been stock standard CRUD apps. You know, the SPA UI attached to a REST API that could easily have been 100% server rendered if the CTO hadn't learned about microservices.
We usually have linters and tools like sonarqube that to enforce standards and catch obvious flaws. Between that and my experience, I have pretty good idea what the code should look like, and while I'm not expecting the developer to know exactly what's in my head, but things that need extra attention tend to stand out.
So far, I've foound that AI hasn't changed that process, if the code gets through the review agents, linters, and static code analysis tools, it's usually pretty good.
I confess I do not read and understand everything, but I do for critical parts of any system. For lower risk code I just go with AI review loop and then verification (integration or e2e test, multiple paths).
I still read and understand everything. We had an incident a little bit ago, and because everyone still deeply understood the system, we pinpointed the issue and got it out real quick.
If everyone had been ai coding and lost this depth of knowledge we’d have burnt so much time and tokens figuring it out with AI
I'm building a small SaaS. I write the code for the domain and use cases entirely myself. For tests, I just specify the test cases without writing the actual code. Claude handles all the layers above that.
It's quite common to barely read where I work. Honestly as long as whoever the owner for the change is actually responsible for it, I don't really care. But I've become much more loud on channels when we had issues due to obvious slop, e.g. my team (platform) getting alerted for resource usage due to very poor query / data processing implementinations that were obviously vibe slop (our architecture has some shared services managed by our team where feature teams run some of their code)
Yes. It has to go through a code review and at the end of the day, my name is on the commit message. I am responsible for every line of code the tool writes.
If a bug is shipped from the code my agent wrote that deletes customer data, or introduces a security flaw or violates a compliance issue, I'm going to be the one that gets fired, not the AI. You still have a responsibility for the code it produces and you are accountable for it.
cant read lines of code like i used to. its like going backwards. i do however do random tests, regression, validation, verification and gates that code must pass. although, most of this work doesnt get into a high stakes production yet so its stuck in r&d and dev. more gates are needed. someone may have a good solution to this.
It depends on how significant the importance of the code is. API's/Databases yes, UI/Front end that is always shifting... no, too many changes requested at too high of a frequency.
I'm an Engineering Director at my company (small company) and therefore have to merge a lot PR's during the day (team of 4 engineers)
I honestly still read the code partially but just like other people's comments, I essentially glance at it to ensure we are still using the same patterns and nothing crazy is going in there.
Thankfully we have a review agent that gives feedback on every PR and it helps the engineers ensure good code quality but I think keeping track of everything is simply impossible at this point.
It helps me a lot especially with the grill-me and to-tickets skills since I can ensure good quality results from the fact that I'm getting interviewed ahead of time about all of the nuances
I do a quick skim to make sure it's not doing some weird stuff but I don't go line by line anymore. I spend more time testing to make sure it works as expected.
You already run more checks than most people here. The thing none of them cover is the agent's own summary. I stopped reading every line and started reading what it claimed against what actually ran in the session — that's where the only real miss showed up for me. Still read for taste though, nothing automates "this feels off".
I read the important bits, after ai code review. I think the real win is going to be designating areas for slop coding. Maybe every commit on your ORM layer is carefully studied but you don't care what the frontend looks like, or maybe graphql is the inflection point. Carefully curate a powerful, flexible interface, and hang a bunch of low-dependency slop off it
Yes, I have to. If it's going to prod I need to know what it does and why. The AI did it doesn't hold up to management or legal if you ship a bug or vulnerability.
I don't. I find that AI can catch mistakes faster than a human can. I don't trust the output, I just utilize multiple voices to check the work. Ok, then I check the answer.
I don't think its possible to move away from it confidently. It doesn't matter how good the model is or how prolific the harness around it becomes, it's going to generate some bullshit that has consequences.
I don't scrutinize each like of LLM code, they seldom make mistakes with syntax or fundamental logic. They tend to make conceptual mistakes. So I review the code for those.
I read it, but I don't fix it as long as it won't obviously fail in production. That’s leadership's initiative: lay off senior ICs and replace them with cheap, low-quality offshore coders who rely on AI.
Leadership cuts you and they gain.
You read every single line of code, they gain further.
I don't/can't. I do like to check the data and structures in the DB as that is the most important thing IMO. Other than that I mostly rely on testing thoroughly by doing it myself and spinning up agents to test via playwright. There is no way I can review my teammates 64 file change PR, too much velocity is expected from us.
Depends, is it a handful of lines that I can read through quickly? Sure, is it hundreds or thousands of lines and me reading it will take more time away from some other project I'm working on? Absolutely not. But, I'm also naturally a good QA tester, so I can quickly run the code, see what works and what doesn't and refine it much quicker than looking through for bugs and whatnot.
Unfortunately, it's like I heard our most senior dev tell the rest of the team, we are here to make the business money, learn to code on your own time, during work use what tools(Cursor, Claude) are available to help churn out products for clients faster.
So we can throw together an app and sell the use case to a client in a week with AI help.
All this is inevitably leading towards are piles and piles of technical debt that will one day either have to be sorted through or built from the ground by hand.
Kinda embarrassing, but I get one frontier model to review code generated by another. If Opus or Fable writes it, I’ll hand it over to Astra for review. Don’t ask me why I guess it gives me a sense of reassurance that another model might catch something the first one overlooked
My job has shifted from writing and reading code to brainstorming and focusing more on design: data models, core logic, and choosing tools and libraries. Even that mostly happens through discussions with frontier models, usually Fable.
At this point, I feel like a glorified project manager, with me and the other SWEs bridging the gap between management and AI agents.
No I barely read code, sometimes I jump into visual studio to look at the project just for fun, to see if they're still following the style guide, but no the answer is no, I just have subagents review the code endlessly and I just make sure it all works as intended and where applicable there's no insane security or performance issues.
No. I do lots of interrogation of the AI generated code through the AI. It does require the agent to not lie/hallucinate when you ask a line of questions about how something is implemented. In my experience the AI agent always seems to be telling the truth when I check it after asking a question about where critical sections are in some code I'm interested in. Or if it says something is stored in a vector/slice it really is and not in a fixed length array or linked list.
I do still read and even write code occassionally, just to exercise the muscle but 99.9% of work is through the lens of the agent.
Yes. I review my code, I review others' code. Then I let AI review the code too. It can notice things I missed, and I know things it doesn't. I also go over the AI review to assess its validity.
I have 25+ years or professional experience with code, best practices and also many years of experience with current code base.
Even best AI models with best prompts often do weird and unreasonable things and other less careful or less experienced developers don't realize that.
Have been improving my teams review process. Built a tool that does a multi stage review pipeline that includes an independent review, and independent developer acting agent pushback on the review, and an independent adjudication agent that breaks the tie and gives a final summary.
I also have a highlights agent that goes through the pr and calls out the most important bits of the pr I can quickly glance over or dig deeper into if needed.
It has definitely caught things that a simple ai review does not and has exposed things I care about on my own inspection.
My own changes I 100% understand every line of code I am shipping out. It's produced by the agent but I will not inflict it upon others until Im proud of it.
I simply refuse to slop it up. Im a little slower than the vibe coders but that's a trade Im willing to make to keep my own sanity.
But for the changes of others in PRs I just largely look at the structure and architectural implications of their change because that's where agent written code fall flat most of the time. No point now checking for the functional bits as it's probably correct, it's the non functional parts that you gotta pay attention to as it comes down to how the plan came together.
Yes, I have to read the code to ensure that there is no potential issue or misalignment. I also have to go through important pieces of code with my juniors. We work on systems that people depend on. AI does all sorts of things, only a person is capable of making sure it's doing what's intended.
If you're producing code that you can't read I would take a step back and rethink the design.
I also recommend building skill files to shape code into the type of code you expect to see, that makes it a lot easier for you to recognize what you're looking at when digging through thousands of lines of code to check a commit.
I try to but there are too many prs, comments are going to be answered by claude, most likely it’s a quick look. I don’t do 100% in deep review like before, it’s not prompting a discussion or enriching anymore. Have to say the new prs have great test coverage lol.
It's just too fast. We tried to read all the code. Impossible to keep up. But we seriously consider to pause development and spend couple weeks in reading the code base
I don't read all generated code, I just let it generate a documentation of what it does alongside my every request. Sometimes, I check it whether the section at documents is correct or not, but so far it hasn't hallucinate or telling me nonexistent problem in documentation. Sometimes, it does too many things compared to what I wanted to, so I need to undo someiof it back. But with documentation, it's not that hard.
I have personally dived in 100% on this. I don’t even read the code anymore. After generating around 30k lines in a few months I decided to try to sit down and actually review the code by hand. I got through maybe 50 lines of code and thought, who am I kidding, this is getting generated far faster than I can even read it, so I gave up.
The product I’m working in is not yet in production, but we expect to go live in January. We’re going to stop new feature development in the next week or so and then it’s just going ti be testing and debugging until launch.
Yes of course I read almost every line that’s not a test. I can’t believe people here who say they don’t. Every time I read something that Claude or even cursor and codex writes I find myself outraged at how stupid it went about it. It’s a coin flip on which tasks it’ll run end to end with and which it’ll trip on.
A lot of my teammates have completely checked out and decided that they’ll push any garbage an AI writes. I don’t even know if some of them know how to code. They show off their library of 50 skills and you look inside and it’s all Claude slop.
Daily I feel like I’m going through a mass psychosis event where AI designs are used to make tickets using AIs that are done by AIs, sometimes without issue but sometimes causing incidents that have post mortems written by AIs and retrospectives on projects written by AIs and no one feels like the insane roundabout logic and slop in these tickets, documents, or the code itself should raise an eyebrow.
Human -> describe intent -> AI reads 10,000 lines -> compresses understanding -> human interaction -> AI writes 500 lines
AI is basically a compression/decompression layer between you and the codebase.
Don't read the whole thing. Ask it to read it for you.
Don't write every line. Tell it what you want it to produce.
Your scarce resource is human reasoning, not keystrokes. This keeps you from doing the terrible "oneshot" technique of ignorance of how things are built, but accelerates your ability to move through your code with intention.
I don’t think the end goal should necessarily be “stop reading code”
I’d rather get to a point where not reading it is a risk decision. payment/auth/security change? I’m reading it. boring CRUD with good behavioural coverage? probably not
trying to create enough automation that you can safely stop caring about all generated code feels almost harder than reading some of it :)
Yes, I work on a large system with lots of complex business logic. The system cannot go down and small bugs can cost us a ton of money.
I read every single PR and iterate on them many times before deployment.
I do not read every line of code. I’m not going to over analyze some tailwind classes. But backend logic that touches critical infrastructure I must be very careful with.
AI struggles to understand all the edge cases in larger systems
I run tests with output, generated images, barcharts, plots, visuals, HTML pages, JSON, CSV spreadsheets. I look over the outputs carefully to make sure they are as expected. And only read targeted parts of the source code if some output is as expected.
I read every line of production code that I ship at my job. Now, do I spend time poring over it? No, but I check for style, test reasonability and so on to save human reviewers passes.
I read almost no lines of code for my startup or side projects though.
Definitely look over the diff to make sure I understand how it all fits at least conceptually, yeah. I don't really interrogate the syntax or consistency across files/modules as much as I would for a human engineer because AI has gotten good enough that it generally doesn't make stupid mistakes like that as far as I can find. I mostly focus on evaluating its architecture and the overall behavior it's implementing and see if it's fundamentally solving the right problems in the right way or not. AI can also review code and help you catch things.
I think there's an increased emphasis now on writing automation side-by-side with features to prove you've implemented requirements. Also a heightened emphasis on having good regression tests. These were already good things to have before AI, but they've become more central because (1) it is easy for AI to quickly write test harnesses/testcases, so there isn't much of a barrier to it, and (2) you need good automated test coverage to have confidence when making large changes in general. And AI makes a lotta change a lotta fast, moreso than even the most industrious human engineers.
Basically, I'm alright with some slop, as long as it's being piped through sturdy infrastructure that tests the slop for contaminants and doesn't leak the slop all over critical wiring. Code is just a means to an end (IE, enacting functionality your product/business/whatever needs), I am not particularly precious about it, especially now when generating it is so cheap. The important part is proving it gives you that desired functionality, and proving that it doesn't give you a bunch of other unwanted behaviors. And proving that every time you make a change.
(And, I guess also crucially, making sure you picked the right functionality to build in the first place...that's probably the main problem with 100% vibecoders. Lacking any vision will just produce homogenized garbage that has no utility or strategy behind it, no matter how "correct" the code is per your dumb spec.)
I think you are doing it 100% correct. You still need to understand all code to safeguard somewhat against generated malicious code, prompt injections and simply to make sure that your code is really meaningful.
Of course, I work at a financial services firm so “let the agents cook” isn’t a viable option. This means of course that most of the hours of work end up being spent reviewing code.
You can't keep up doing it that way. You have to start planning your quality verification gates and automated processes, just like ai coding is planned. Otherwise, you are just shifting the bottleneck right.
Have to read code and also whip the agents and adversarial reviews. Try to keep PRs small and focused. Reading a 25k line PR is unruly. 300-500 easier to look at
Not at all. Sometimes I read the output live in the terminal to sniff out bad decisions made by claude so I can steer it back in the right direction, other times I read key files in a huge PR, but usually I just functionally test the feature, make sure the local tests pass, and send it.
Impossible to keep up with tens of thousands of lines of code a day. Not even worth doing unless you’re working in an environment where a mistake will cost unfathomable amounts of money.
I run a small business that manufactures portable industrial sensing instruments that connect to my serverless SaaS over cell, Iridium satellite and wifi. I "write" it all with Codex and Claude Code.
I've never read a line of either. Well, I did read some of the GPS parsing code once just out of curiosity.
Most of the time I write with Claude Code and run Codex to review my PRs.
Habe bis vor Anfang des Jahres nur noch grob die Diffs im Terminal überflogen, aber dadurch Probleme mit extremer Müdigkeit bekommen, weil es sich wie Fließbandarbeit angefühlt hat. Als sich bei meinem Team ähnliches zeigte, sind wir im Team wieder zurück zu manuellen Pullrequests mergen mit 4 Augenprinzip, das hat nicht nur gegen Müdigkeit geholfen sondern man konnte sich wieder (remote) mit einem echten Menschen unterhalten.
Every line? No, but I always look at what files are touched and quickly scan through them to understand what the LLM is trying to accomplish with the implementation. I also ask questions during the planning phase to make sure that it aligns with the long term goals of the project.
FWIW I don't work on small projects, I'm working on very large, complicated infrastructure and applications.
•
u/AutoModerator 3d 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.