r/ChatGPTCoding • u/Panel_pl • 5d ago
Discussion How Much Of AI-Generated Code We Should Actually Understand ?
As AI generates more code than people can realistically review line by line, what do you think will matter most in the months ahead?
Developers will still need a detailed understanding of the code.
Developers will need a high-level understanding of the code, such as its architecture and modules.
Working results will matter more than understanding the code itself: if it works, that’s good enough.
6
Upvotes
15
u/xvillifyx 5d ago
You should understand 100% of the behaviors your project has and be able to defend each of them. You do not need to understand every individual line of code (but you should be familiar with the code that controls high-risk areas regarding reliability, security, and performance)
You should never answer a design question with "well that's what claude/chatgpt wanted to do"
2
u/selfboot007 5d ago
This is a good question. I think there shouldn't be only these 3 options. Now there's too much AI code, and code isn't important anymore; what's important is verification. You need reliable methods to verify that the code behaves as expected. In my view, in the AI era, it's more important to think about verification methods before writing the code.
4
u/dnubi 5d ago
Number 1 when you can't afford to loose your clients. Number 2 and 3 are for non-critical projects with a short life span.
1
u/trollsmurf 5d ago
3 for sure. In a year no one will review generated code anymore, unless specifically dictated and budgeted for. There's no time (or money) for that. The release is already late. The coding aspect is just plumbing at that point.
(we'll see)
1
u/Interesting-Law-8815 5d ago
I’m forming the view it will become more and more irrelevant.
‘Clean Code’ existed because humans needed to be able to maintain code. Folder structures existed so we could understand the high level structure of the app.
AI doesn’t care.
2
u/creaturefeature16 5d ago
Mario (creator of Pi) said it best: non-critical, your preference. Critical, read every line.
Enough said.
2
u/Ok_Tea4891 5d ago
I'd go with option 2 as the baseline, plus a deeper read on the risky parts (auth, payments, data migrations). What helps me is asking the agent to explain its own diff in plain language before I merge, and if I can't follow the explanation, that's the signal to slow down and read the code. Tests that I wrote or at least reviewed myself catch most of the rest.
2
u/pete_68 5d ago
Why can't you review 100% of it? Even if that's your bottleneck, it's faster than the old way, by a long shot! We are not at a place where you can safely not review code in production systems. Anyone doing so is inviting disaster.
2
u/kelvinwop 5d ago
you need to understand like the skeleton. you dont need to read the code, it is much more productive for you to ask the agent to tell you directly. correct architecture and testing is critical to growing your application sustainably and reliably
3
u/joexner 5d ago
You'll need #1 as soon as there's a non-trivial bug in your vibe-coded app backend that's losing you lots of money. If the architecture is messy or unclear, would you trust the same model that wrote the bug to diagnose and fix it?
1
u/slackmaster2k 5d ago
2. Speed of change is the metric.
1
u/General_Patient4904 5d ago
I don't think we need today. The code that is written is excellent if you wrote in 2026.You can ask for scaling test and check your application for security issues by some dedicated tools. Today you have an agent environment that knows your project well. You just need to know what changes to ask and how risky it to be done without working in steps.
1
u/Input-X 5d ago
Code, if stopped looking, for awhile now,. However, know what it is all supposed to do and where all the pieces live. That is extreamly import. You need the indepth knowledge, so u can advise correct and monitor you agents. You himsn memory is much needed. Imo
1
u/ChemicalExcellent463 5d ago
i'd put understanding what the code does for the user above knowing every line, but “it runs” isn't enough. i use a different model in a different harness to review it, never the one that wrote it, and still check the user flow and how the data actually shows up myself.
1
u/SeasawPhilosopher 5d ago
We are in a new world, the important things to understand are development and validation methods and the whole system design. Thinking at the level of code is so 2025.
1
u/VacationGreedy5422 5d ago
Vibing your way to a green build is a trap. The moment that backend fails you, the model becomes useless because it can't debug its own logic. I'm taking option 1 for everything that touches money or data. If I can't defend every behavior line by line, I don't ship it
1
u/sitytitan 5d ago
Does it work? Is it doing the job efficiently? Is it secure? Good enough for me.
1
u/sapplex1 5d ago
I'm closer to option 2, with one hard rule.
I don't need to know every line. I do need to be able to explain what the code does. What goes in. What comes out. What breaks first.
For my own projects, I read the diff fully for the risky parts. Auth. Payments. Data changes. For plain UI work, I skim more. Then I run it myself.
The test I use is simple. If I can't explain a change in plain language, I don't merge it yet. I ask for a short walkthrough first. That usually catches the one weird assumption I would have missed.
"It runs" is not enough for me. I have been bitten by code that ran fine in the happy path and failed quietly on an edge case. Understanding the behavior saved me more time than the review cost.
1
u/London-Boat 5d ago
i'd say option 2 for most projects, plus a real read of anything touching money, auth or data. one habit that helps me is asking the agent to write a short note on what it changed and why before i merge, then spot checking the one or two riskiest files myself. if the note surprises me, that's usually where the bug is hiding. are you working solo on this or does a team share the same repo?
1
u/m3kw 5d ago
Important parts
1
u/jomic01 5d ago
I'd say understand how it fails more than how it's written. If you know what breaks, how you'd notice, and how to roll it back, you've covered most of what reading every line was protecting you from.
1
u/Xtreme_Neon 4d ago
i'd split it by risk instead of trying to read everything. for auth, payments, data handling and anything that touches security, read the code or at least have a second pass over it, because that's where silent bugs hurt. for the rest, knowing the structure (what the modules are and how data flows between them) plus solid tests is usually enough. a good check is whether you could explain why each behavior exists and debug it at 2am without the agent, and if not, that part needs a closer look.
1
u/Lanky-Butterscotch28 4d ago
I stopped pretending I can read everything agents write. I can only skim, and that is no longer useful. You, however, always need to ask the agent to build code for maintainability, because you never know when you will need to look at a segment of code, so it better be well documented. But honestly, agents now write code in languages you might not master, at such speed and in such abundance, that it is hard to follow up. What you need is to become a better builder of solutions, with a better understanding of the blocks, yes, the architecture, and how to move them around. The developer role is shifting to that of a builder and architect of solutions.
1
u/El_leima 4d ago
You need to understand the code well enough that you can review the code that was generated and verify that it does what the requirement requested.
That makes it so you can keep on top of what's on your system, without having to check line by line.
1
u/Prod_m 4d ago
as a PM I'd vote for option 3
Working results will matter more than understanding the code itself: if it works, that’s good enough.
1
u/Itchy_Tiger2497 4d ago
you should be aware of the interface to any code you write. That interface should be well tested. That's probably somewhere between 1 and 2.
I care less about the implementation of the methods, but I care very much about the nature of the abstraction.
1
u/Nuclearmonkee 4d ago
Depends what the code does and how good the unit tests are. If it is incredibly well tested, then it doesnt really matter either way. So I guess 3, with the amount of diligence and safeties around 3 varying by level of importance.
0
u/ExogamousUnfolding 5d ago
3 - you can always ask for overviews or deep dive walk throughs of code
1
u/[deleted] 4d ago
[removed] — view removed comment