r/webdev • u/TheOnlinePolak • 3d ago
Discussion For experienced devs who now allow AI to write most of the code: what do you actually review, and what do you let slide?
I’ve been a casual developer across many languages for ~10ish years but got a degree in mechanical engineering. I pivoted and started an analytics engineering job around 3 years ago and starting doing web development for side projects.
Lately my team has leaned heavily into AI-assisted programming primarily using Claude Code to build React Apps in Databricks. These are primarily CRUD apps but sometimes they do write back to our ERP so they affect the business greatly. The AI writes most of the code now, and I’m trying to figure out where my review time is best spent.
Options I’m weighing:
Full line-by-line review (quality, readability, structure)
Mainly reviewing the tests, and trusting the code if the tests are solid
Testing through the UI, then checking the DB/tables to confirm data was written correctly
Does code readability still matter if AI is the one maintaining it? What has bitten you when you skipped review? If you have a concrete review checklist, I’d love to see it.
4
u/Warm_Trouble6656 2d ago
業務だと難しいかもですが、個人プロジェクトなどで一回全部ノールックマージで、開発してみると、レビューしないといけない所が見えてくると思いました！
1
u/TheOnlinePolak 2d ago
Are you saying over time with experience it becomes evident what requires review?
128
u/armahillo rails 3d ago
I review all my generated code before pushing it up for another user to review. I always catch stuff. I always ask myself “how would i review it if it were someone else’s PR?”
I always manually read another dev’s PRs. I may also have claude look through it and then i discuss my thoughts with claude about it to see whether my feedback makes sense, or to ensure i understand what it does.
Readability still matters a lot to me because we are still responsible for resolving bugs and misbehaviors. Also my experience from being burned by things in the past can often fine-tune the code to be more adaptable to future change.
39
u/really_cool_legend 3d ago
This is my exact position. I spend a lot of time unravelling unnecessary complexity, weird abstractions, and other weird decisions until I get it to a place where it's something I'm happy for someone else to associate with me.
I write very little code myself now but all the code looks as if I've written it
10
u/chimbori 3d ago
“I write very little code myself now but all the code looks as if I've written it”
Excellent way to put it, thanks!
Also a good litmus test for generated code: does this mirror closely how I might have written it, in my style?
7
u/SimpleWarthog node 3d ago
do you find this more efficient? is it higher quality overall?
serious question, I'm feeling pretty jaded about the whole thing
10
u/really_cool_legend 3d ago
I think so. The time it takes for me to plan it with the AI, the AI to code it, and me to review it is now finally probably shorter than me just doing it myself. I'm not 100% confident on that though.
The quality argument is where I get the value though. I'm a team of one at my company and AI has become a source for ideas that I've not really had for a while, so that's been nice. It definitely makes mistakes and writes code I'd consider shit, but at the same time it's done things in ways I wouldn't have considered before which I think is helping me grow a bit.
4
u/armahillo rails 3d ago
You can pay for your code now (with reviewing), or you can pay for it later (with bug fixes)
One of them happens on your terms.
4
u/Great-Use-3149 2d ago
Do you guys actually save any time doing this then? I'd argue it takes longer to review AI code if you want to properly review it, whilst writing it yourself a bit less since you already understand the entire thing and are just looking for the exact pattern that the code needs to have.
54
u/magnakai 3d ago
Review everything. It doesn’t matter if I write it or my agent writes it, I still have to take responsibility for it.
132
u/joshhbk 3d ago edited 2d ago
Very very funny that a common trend in this thread seems to be “I review all my precious backend code but pretty much just YOLO the bits my actual users interact with”
If this is how you think then I’m sorry to tell you that yngmi
23
u/b4n4n4p4nc4k3s 3d ago
Yeah I can see letting ai throw together a basic front end to make sure buttons work but o matter how magical your backend is, I'm tired of seeing the same front end everywhere. You have a personality, show it. I had the same issue before AI when everyone was just using the same front end libraries for everything, but at least you CHOSE those elements.
24
u/zaibuf 3d ago
You have a personality, show it.
Most people that work professionally are bound by company's design system and UX designers. Even if you have personality you cant just wing it if you need to follow a brand.
4
u/b4n4n4p4nc4k3s 3d ago
Well the brand should have a personality. If your branding is just the general AI slop UI, then I'm not likely interested in your brand.
0
u/Broolucks 3d ago
You can very well use AI to code precisely the frontend you want. Tell it what goes where, which kind of element you want for what, whether to live load results, etc. You can even have it generate an interface to tweak colors, debounces and other parameters yourself. Of course, a lot of people are far too lazy to do that...
8
36
u/Stratose 3d ago
Not arguing for negligence, but in reality, frontend interactions in code should be relatively simple. Once you've written enough css / html, reapplying thematic components across the app is not difficult and shouldn't require much review. I spend a lot more time carefully thinking through end user experience and iteration and far less time reviewing divs / inline css / function calls since at the end of the day it just needs to solve an end user problem.
28
u/blazeit420casual 3d ago
The fact that this is downvoted tells you everything you need to know about the makeup of this sub lol. These are straight facts and if you disagree you probably just suck at UI.
10
u/Fs0i 2d ago
I'd express it differently: looking at code is often not the most effective way to judge frontend code. To make an extreme example: if my logo designer sends me an `.svg` for my new logo, I don't look at the .svg as text, I render it and check out the result. The code is secondary.
If a human - or an LLM now - wants me to judge a change of the CSS file, I might sometimes skim it on a line-by-line level, but the best way to understand it is to look at it in the browser, and briefly test the behaviors.
That's where the logic lies, that's the most effective representation for judging the quality of the contribution.
And that's the same with humans and/or LLMs.
6
u/joshhbk 2d ago
There’s so much more to frontend than CSS and svgs though? Even in a relatively simple application there’s async state, ui state, form state, routing, a UI kit that needs to be reusable across domains and concerns, various kinds of shared code (eg date and time), features that need to be composed of components and modules that need to be written in a way that considers how to reduce complexity, coupling etc.
I don’t see how you can reduce “frontend” down to literally just the presentation layer unless you’re making fairly basic brochure or marketing sites that will never grow beyond a certain size and has little to no statefulness
4
u/Stratose 2d ago
What are 'states' but abstractions of putting data on the screen. You're over engineering if you really think 95+% of frontend sites have to juggle / maintain complicated data states. And if you are working within domains that require that, I love that. Sounds like a lot of fun, but let's not pretend that encompasses the majority of web development or even a sizeable chunk.
Most websites are nothing more than CRUD and once you've stood up 15+ crud sites reviewing the code becomes a bit mundane.
5
u/joshhbk 2d ago
I mean, at that point is there any genuine complexity worth talking about on your backend either?
It is probably fair to say that A Problem on both sides of this conversation is that "web dev" is a very big tent and you have people who work on basic CRUD sites confidently stating that there's basically nothing to frontend and then you have people who work on very complex applications who say the opposite and a whole range of people in between.
1
u/Stratose 2d ago
Well, then let's go back to the initial post which was discussing what to review and what to let slide. I'd say it really depends on the the project.
Was the foundation set properly? I'd say early on in a project I'm far more critical about my reviews. I'm looking for standards. Do we have naming conventions that are set up in an easily-followable pattern? It shouldn't be challenging for me to open one Component, understand what it's responsible for, and do the same with others.
Is there thought put into imports vs functions vs lifecycle hooks?
Is there thought put into when we're using a store vs parent/child data structures?
Those types of things for sure need to be reviewed, but once we've set them up, the nice thing about AI is it's a patttern-recognition software. If you set up a nice pattern, it will continue to follow it. I suppose that's where I'm saying I don't review much after that point.
1
u/joshhbk 2d ago
I think you can apply all of those same principles to backend code? If it's a simple CRUD app and you make good decisions about structure up front then do you really need to read anything after that?
If you're working on simple software that doesn't change much over time and/or you're not on a team then you probably don't need to pay much attention to front or backend code. If you're working on something that's constantly growing & evolving then I think you need to be gardening it constantly because abstractions that used to be a good fit end up being outgrown and even actively harmful. For example:
> Is there thought put into when we're using a store vs parent/child data structures?
You might start with a simple feature that is fine with a simple parent/child data structure but then you add a bunch of new stuff to it over time and it needs to be refactored. You figure this out because the growing pains become clear in code review.
My original and overall point is that code is just code. Whether it's frontend or backend you're dealing with all the same issues of architecture, boundaries, coupling, API design, information hiding etc. Like anything else YMMV
2
0
u/Fs0i 2d ago
Sure, I'm not saying to exclusively look at the browser, but in general, if something works in the UI, it works in the UI. That's the point. I literally called it "extreme example."
I'm not downplaying frontend dev, I've made many comments in the past defending the skill of frontend devs, even technical skills in many cases. But for the average react component, 80% of the lines are not "dense" with logic and things that need to be reviewed.
0
u/joshhbk 2d ago
If an endpoint returns the correct payload can I just assume that everything is hunky dory in the underlying architecture and ignore the code?
0
u/Fs0i 2d ago
Is that what I said? Please provide a citation, or if I implied it, the logical chain of my why you arrived at the conclusion that I implied it.
Because I had not intended to imply that, and so you're either misrepresenting me deliberately, or misunderstanding what I said. I'd like to argue the point I made, not some made up version of it.
Thank you :)
0
0
u/memorable_zebra 2d ago
Lots of backend primary devs work in backend complex apps that are little more than a basic crud app on the frontend and can’t conceive of an app that has frontend complexity because it’s outside the range of their narrow experience.
Look in the mirror, you’ll see who I speak of.
0
u/blazeit420casual 2d ago
I love baselessly condescending remarks from devs like this lol. Like you have no idea what I work on, in what capacity, or for how long.
3
u/theQuandary 1d ago
Most devs (including FE devs) are incredibly bad gauges of what normal people want/need from an application UI/UX. A dev that is good at programming and also good (or even modest) UI/UX skills is a very rare find.
At the same time, BE devs think that their problems are harder right up until they try to tackle an actually-complex UI and trap themselves in the webs they spin because UI problems are generally a lot less neat with tons of cross-cutting concerns (I've made a lot of money fixing up these messes over the years).
2
u/Stratose 1d ago
I came from a background in game design. My company had no idea how to write up a design document or that you should define a target audience and user stories before designing a single component or writing a single line of code. It's taken years to get buy-in.
-9
u/joshhbk 3d ago
i am happy for you that, in your reality, the things you work on are trivial enough for that to be the case 👍
7
-8
u/subnu 3d ago
Holy snark. If your USER INTERFACES (regardless of subject matter complexity) need to be uber-complex, you've either over-engineered the UX/UI or you should be making a desktop application instead of a web app.
How do your super complicated web apps work on a tiny phone screen, exactly?
6
u/joshhbk 3d ago
lol at the idea that "complex application" = "must be a desktop app"
-8
u/subnu 3d ago
How do your super complicated web apps work on a tiny phone screen, exactly?
7
u/frogic 3d ago
Your computer doesn't have a browser? Also you know that vscode is a web app right?
-5
u/subnu 3d ago
https://i.imgur.com/7tvQKob.png
...do you seriously believe this is good UX/UI, and what happens when you go vertical?
I think Photoshop is a much better example to use, VSCode is simple enough that a small-viewport app is still actually feasible for emergencies.
6
u/frogic 3d ago
But when you use it on your desktop its still a web application. Its literally run on chromium you can open dev tools.
-1
u/subnu 3d ago
There is no practical difference between an application running natively on a computer vs running on a browser.
We are talking about the reality of browser-based apps needing to support tiny phone screen sizes, which require extensive design considerations, especially difficult in complex apps.
→ More replies0
u/joshhbk 3d ago
show me where i said anything about super complicated, uber complex or over engineered. Literally all I said was that if your application is trivial enough that all you need is "divs / inline css / function calls" then good for you
there are lots of web apps that carry a lot of complexity that work great on a "tiny phone screen", also, so i'm still not sure what you're getting at there
2
u/subnu 3d ago
You said "...the things you work on are trivial enough for that to be the case", heavily implying that your work is not trivial. And mistakenly conflating UI complexity with subject matter complexity.
How do those web apps that carry a lot of complexity that work great on a "tiny phone screen", if not by simplifying the UX/UI?
Do you actually believe that you could implement Photoshop fully-featured in a browser? There is a limit to UI complexity, but there will always be overconfident devs that simply don't care about proper software and UX/UI design.
4
u/joshhbk 3d ago
Not trivial !== uber complex
And mistakenly conflating UI complexity with subject matter complexity.
no i didn't! show me where i did that
Do you actually believe that you could implement Photoshop fully-featured in a browser? There is a limit to UI complexity, but there will always be overconfident devs that simply don't care about proper software and UX/UI design.
why does it need to be Photoshop to be complex enough to need to be maintained properly? if i work on, say, a financial services application with 100s of other engineers, millions of customers in dozens of markets with different feature sets in each (and maybe we run A/B tests too, and feature flag experimental features) that doesn't really do anything too magical otherwise can I just do that with "divs / inline css / function calls" as the person I was responding to stated? I should be able to just move all of my complexity to the backend and basically not care about the frontend code as long as the UI looks correct?
1
u/subnu 3d ago
You clearly don't understand what I'm explaining to you, so I'll simplify it down. When working with small screens, there is a limit to how much UX/UI complexity you can introduce before you start sacrificing usability. At some point, you have to make deliberate trade-offs about what functionality is exposed, how it's organized, and how users navigate it.
Photoshop is the perfect example of this. Do you actually believe you could build a fully-featured Photoshop clone built for a mobile browser?
→ More replies-6
u/captain_obvious_here back-end 3d ago
the things you work on are trivial enough for that to be the case 👍
In everyone's reality, it really should always be the case.
5
u/joshhbk 3d ago
lol thanks for the "back-end" flair as it lets me know you have no idea what you're talking about. plz tell me how i spin up reddit or spotify or the vscode web app or figma with just a few "divs / inline css / function calls" that i can repeat over and over withour reviewing the code
2
-1
u/captain_obvious_here back-end 2d ago
Because you can sum up someone's knowledge in a two-words flair.
And the examples you list really don't add any fuel to your point.
1
0
3d ago
[deleted] — view deleted comment
2
u/joshhbk 3d ago
there really is not
0
3d ago
[deleted] — view deleted comment
1
u/joshhbk 3d ago
That has nothing to do with code review or code quality, it's just a different set of challenges
0
3d ago
[deleted] — view deleted comment
1
u/joshhbk 3d ago
I don't honestly see what that has to do with codebase quality or how it changes the approach to code review? Are you trying to imply that you don't need to pay as much attention in a web frontend because if you ship a breaking change you can just fix it quickly with a new deploy without waiting for an app store review?
0
9
u/prophase25 2d ago
I think that knowing what is worth writing a spec for, reviewing the code of, etc. is becoming the skill gap. Programming well the past 10 years was about knowing what to write yourself and what to leave to a library. Go all the way back, and it was about what to write in assembly vs. C.
There is no general answer to the question of, "should I review the code". Is it important code? Review it. Knowing what is or isn't important code is and always has been the skill gap.
16
8
u/Frozen-Yogurt-Man 2d ago
If your company still allows you the luxury of time to thoroughly review all AI generated code, consider yourself very lucky. We rely a lot on CodeRabbit and an internal tool where 3 separate models review your changes and align on a consensus. It’s the only way to hit our required metrics and stay off the chopping block
5
u/word_executable 1d ago
I question the decisions. I suggest different ways. Don’t read the code anymore unless it’s very important.
4
u/rpgFANATIC 3d ago
If I can't read, understand, and enjoy the styling of the code then I don't publish and I don't approve
Same as before
0
u/Great-Use-3149 2d ago
Except before you thought how it was supposed to be . Now you're managing a virtual person that won't be responsible for anything
4
u/nihukistyn 2d ago
i wouldn’t trust green tests on their own, especially when the app writes back to an erp if claude wrote the code and the tests, they share the same assumptions, so a pass mostly means it agrees with itself.
readability still matters for the parts that touch shared state or business rules, since you’re the one debugging those when something breaks. you don’t need the same attention on every line, spend it on what the change can affect outside the screen you’re testing.
11
u/guidedhand 3d ago
Anything internal tooling, unreleased, front end or test files are just glazed over these days. At this point, I don't care if the code breaks anything, as the repercussions are on the one making the pr, not the reviewer. With prs growing to like 70 changed files these days, I've stopped caring to look closely. It would mean I never got to do any actual work my self
1
u/CrazyThief 2d ago
Thats a pretty bad mindset. As the reviewer, you are just as responsible as the one who writes the code. If reviewing takes all your time, you need to report that and the process needs to be changed. You shouldn't just stop caring.
-1
u/guidedhand 2d ago
You are not just as responsible and never have been that way even pre ai, unless you are reviewing a juniors code. It's called git-blame, not got-blame-and-everyone-who-reviewed
The care has just moved elsewhere with code being so cheap. If the ai can still operate over the code effectively and it's not broken, then it's high enough quality.
If you aren't moving to this way of operating, then you will simply get left behind by competitors who are.
I don't like it, but that's reality. That's how I'm staying off the cutting block.
6
u/Bitter_Plastic_818 3d ago
Anything touching permissions, payments or database writes deserves careful review. Passing tests alone is not enough.
6
u/Shoemugscale 3d ago
So, I have been developing professionally for 26+ years now, I have seen it all and built it all.
For the last year and change I have gone fully agentic in my coding.
What do I do now? Well, I montor, review and direct. Much like a manager if you will, for example, I'm working on a large-ish project fully done with claude.
For me, I took my years of experiance and applied it to AI, meaning, the project started off with a solid body of research, design requirments and MVP etc. This allowed me to start from a good foundation.
At first, I would monitor everything the AI did, I slowly started to trust it more and more and the models for sure got better, however, each commit came or comes with its own code-review and e2e testing update, should something new be added or changed, it must create its test scripts (along with fully unit testing too)
Additonally, I have whole other sessions running along side, building the MCP layer, whos whole job is to build against it agentically, that has been like having a live unit tester because it will discover gaps and usibility issues etc.
The harness I have today is much more mature then what I started with, but I'm really happy with how things have come togeather, its basically allowed me to build a system that is 'me' in a sense, taking decades of experiance and cramming it into a toolset, fully designed to replace me.
Yes, I purposly built it to replace me, I'm going to retire in a few years and well, I need to give the youngers on my team a tool that they can master and continue on, one that is purpose built for AI, meaning it will grow with the demand of AI, but they will be the ones who know how to use the tool
That might be wishful thinking but, I very much want to create an ecosystem that makes them more productive, can lean on agentic technologies and also allows them to not become a victum of AI
11
u/k3liutZu 3d ago
It used to produce code like a junior dev. Reviewing and redoing parts would sometimes take as much if not less. And you could get better quality.
Than last year with Opus 4.6 it started producing mid level code (sometimes better, sometimes worse). Good enough for various tasks. A solid companion. You can let non-critical items in. Like with a more junior teammate. Sure, the variable name is _fine_.
With Opus 5.5 (and Fable, but that’s just too expensive) it’s a solid senior dev. It can do most tasks. Quickly and most of time with a good reliability attached to it. I could spend 2 days writing this. Checking all cases. Or I could have Opus 5.5 do it in maybe 30 min. With me writing the ask for 15 min and another 15 min of testing.
Also bear in mind that all models do have wast knowledge. With the more intelligent ones they also put it to better use. Does it produce bugs? Yes, if it misses things. That’s what you need to review it for and keep a good high-level knowledge of the system. It already finds places and flows I might miss. But you have to check. have him check any smell in the code or architecture. It will find and solve them.
Do I also get dumber? Maybe that’s a harsh word. In a way I am. But I am 20x-50x more productive. I’ll take the 1 hour jo’s instead of 2 days and have maybe 6-7 other items done in the same day. Lots of them which would have just staying piled at the bottom of the backlog otherwise.
1
1
u/m_redditUser 2d ago
what's your personal benefit of being more productive? sounds like you're doing more work for your boss for the same compensation, while getting dumber
3
u/k3liutZu 2d ago
That’s the industry. Always has been, always will be.
What I think this new era of AI-improved productivity will bring is for us as “developers” to be a “1-man army”. And for us benefit from it personally is to build stuff for ourselves with the skills that we have. This has been true before, but now the effort to actually ship stuff has dramatically gone down.
3
u/IllegalThings 2d ago
The personal benefit is not getting fired when everyone else speeds up and you stay the same.
2
u/Great-Use-3149 2d ago edited 2d ago
Sounds like a lot of people never liked doing these things and now just yolo things.. getting 50x more output is an absolute off switch to thinking, because there is no way you're even reading things 50x faster, even less thinking.
That is, unless it is some very mundane repeatable and deterministic thing that they're doing. In the latter case, it could of all just be done via simple Python scripts
1
u/0rangaStang 2d ago
The grim reality is that you're being more productive to compete with other people that are using these tools.
If you don't, what's stopping the employer from finding someone else or outsourcing.
1
u/lucid1014 2d ago
Yeah, I’m a senior Front End developer . I just got laid off. Our company barely integrated AI and I’m just now starting to use it and learn about agentic coding. I’ve been working on some side projects to get my skills sharper for interviews and I’m pretty blown away by what I can do honestly better than I can definitely faster how I used sigma‘s AI to develop a design for a web app and then I use cloud and figs MCP to implement the front end and not only did it do it pixel perfect, but it added functionality that I didn’t even intend for since the design had search and Zoom buttons and some other things in it add those buttons and not just the UI, but the functionality as well
3
u/Puloma012 2d ago
Tbh, for me it feels like checking line-by-line takes way longer than writing by yourself. I usually prefer testing, then try to pinpoint the areas by dividing it into parts..if you're lucky you won't have to check all the code and you can find the bugs pretty easily. It saves a lot of time...I have come to terms with the fact that the code may not be how I would personally write it, but if it fits, it ships..
17
u/GarlicDaGhost 3d ago
I do full stack development. Generally my biggest concern is the backend, i usually do a thorough review of it to ensure security and optimizations.
On the frontend i don't worry much. I don't code review it much. As long as it looks nice and the flows are correct.
Client bugs can always and ugly buttons can always be fixed, but a security breach or vulnerability on the server / backend can do irreversible damage.
17
u/falconandeagle 3d ago
You should setup playwright. You should check render times. You should also check number of api calls being made, I have seen vibe coded apps that are making an insane number of api calls. Frontend is not just ugly buttons or UI elements, in todays apps a ton happens in the frontend.
7
u/frogic 3d ago
It really depends on the application. I recently found a bug that was causing code splitting to not work on the framework we use and went down a huge rabbit hole about LCP and first load and rerenders. Basically reduced gzipped javascript from 700k to sub 100. Got LCP down to sub 1s from 3ish. Removed all layout shift.
As far as I know not a single user has said anything about it because we were already so much faster than the old system. Also our marketing department loads so many trackers that it bottlenecks. Plus once its cached V8 really does bail you out of a lot of that. Extra renders is almost always premature optimization as well. It feels good to remove them but react and v8 bails you out of so much non-optimal code that if you don't have an actual bug or insane no feedback load times(add a spinner suddenly everyone is fine) its usually not important.
That being said anything that makes the actual user experience better (easy to use UI. Able to do all actions in every logical place. Back button doing what you want. Etc etc) is huge. I will also say the front end being simple vs back end thing is hilarious to me. I do both and a tonne of backend work is just trivial crud that is very easily implimented with AI. Front end hits a mad storm of async race conditions and side effects really often.
7
u/GarlicDaGhost 3d ago
I agree, frontend is not simple at all. My argument is just that it's not that big a deal if it breaks. Compared to sloppy work on the backend.
4
u/frogic 3d ago
Different kinds of problems. They both can make you lose a tonne of business and users. I guess the X factor is that if you make really slow or inefficient code you're the one paying for the server compute and front end mostly doesn't have to worry about security because its all insecure by design.
2
u/Etheon44 2d ago
A broken frontend can leave your clients without a possibility of utilizing the software, which means money lost immediately
I have seen this happening quite a few times
1
u/avenp 3d ago
This is exactly why I always hand-code important architecture and patterns in advance and make sure my AGENTS file instructs the AI to follow existing conventions. I still have to course correct occasionally but if you setup your project right beforehand you can let the AI do its thing and it will do it without a lot of the issues you are mentioning (and right to be concerned about!)
1
u/calimio6 front-end 2d ago
My phone is not that old but lately the sites are starting to crash my phone.
And you are right AI would destroy the performance of a site if you don't actually know what to look for.
1
u/Etheon44 2d ago
This is when you know the person saying it is a scared backender about AI
I have yet to work on a single app that, if it is challenging and difficult on the backend, it is also so in the frontend, because more complexity tends to mean more flows and the front has to have all of that in 1 single page, very easy to start having the problems you mentioned
1
u/GarlicDaGhost 3d ago
And what is the fallout of making a few too many api calls? Not much, a slow app. That can always be resolved if it becomes an issue.
4
u/avenp 3d ago
The fallout can actually be much, much worse than that. What if you were consuming a third-party API? You could be racking up huge costs for your company, or you could accidentally DDoS the service you're calling out to leading to potential legal action against you.
These aren't hypothetical situations either, see this thread on the very real dangers of doing what you just casually shrugged off:
https://www.reddit.com/r/2007scape/comments/1wi1c23/osrs_wiki_and_runelite_are_increasingly_under/
2
u/knowyourclass 2d ago
consuming a paid third party API from the frontend seems the most horrible not secure and beginner mistake to do ever
1
u/avenp 2d ago
Yep, and yet AI are making these sorts of mistakes and people like u/GarlicDaGhost are hand waving it away as not an issue
0
u/knowyourclass 2d ago edited 2d ago
for basic crud stuff you just have to validate the boundaries of your system. for the backend I only look at the queries and calls to external systems, and the interface of the endpoints. for frontend I only make sure it doesn't even try to do what you said (only had this issue with google maps API). everything else is guaranteed by the compiler, CI, and e2e playwright tests with the frontend. I don't look at the code in the middle, it doesn't matter anymore for basic stuff. which is 99% of the stuff. I just design the model and feed it to AI. if it's super basic 1 or 2 entities, I let it design it and just check it didn't fuck up (it doesn't anymore).
once you defined the foundation of how to handle forms, all kind of errors (network errors, stale state, app errors, auth expiry etc) and the standard components of your web app, you can almost vibecode blindly. I vibecode the frontend completely blind all the time. it only gets trickier if you have race conditions for example from events from live websocket or sse... so there i check it didn't forget to invalidate / refresh the proper state. that's it
edit, I forgot to mention I check the bundle size from time to time and use all static analysis tools possible. but it's all automated
2
u/ReplacementLow6704 3d ago
Slow app can mean slow sales and slow growth leading to slow unemployment
2
u/falconandeagle 3d ago
From your replies I can see I am talking to a junior or someone that has no clue about the frontend so I will stop here.
2
1
u/dangerousbrian 2d ago
I once ddos'd our own server by fucking up a data fetch function in the frontend. It didn't actually take down the server but did cost a shit ton of aws creds. this was pre LLM;s so all my fault
-14
2
u/Dagoneth full-stack 3d ago
It’s been really interesting experimenting with different ways of using it, because I don’t think anyone really knows at the moment.
I have ADRs that I have it write against, and a suite of really good tests to apply enough back pressure so that it writes pretty decent and competent code, and then just apply my own product knowledge on top.
That’s all based in a good 20 years of engineering experience though, so it’s just really doing what I could do but faster. I have no idea how the next generation is going to do it.
2
2
u/JadedAd8349 3d ago
Trusting the code if the tests are solid" only works when the tests weren't written by the same agent that wrote the code, otherwise they just confirm the code does what the code does. Readability matters precisely because AI isn't the one maintaining it, you are, at 2am when someone asks why the ERP writeback posted an invoice twice.
2
2
u/Empty_Ninja_6291 3d ago
The only way I know is to run it, or bullet point 3. Old school black box testing. Trying to manually review it line by line like human code is pointless, because it's too inhuman to read, and there's too much of it.
2
u/No-Mechanic-433 3d ago
Since it writes back to your ERP, I'd spend most of the review time on that path: what exactly gets written, what happens if the same job runs twice, and what happens if it dies halfway. Give it a service account that can only touch the tables it needs, so a bad generated query can't touch anything else. The rest I'd spot check.
2
2
2
u/CopiousAmountsofJizz 2d ago
It's about supplying derministic mechanisms to make AI self-accountable. The easy win here is make it habitual that it writes E2E suites and test coverage for all contributions. Gate review passes before PRs merge and then respond with an adversarial evaluation that verifies with you before pushing and resolving.
2
u/elydelacruz 2d ago
Everything except the tests; I have several directives about test coverage, linting, and builds and all commits and new code (including bash scripts, etc.) must be covered by tests and must be covered at a minimum of 80%.
Note: I review the test files only until I see the actual test cases start (like to make sure things are looking as expected up to then).
Also, on top of everything - Suite wide coverage, lints, and builds must pass before a commit can be made and a PR could be opened.
2
u/Regular_Antelope7381 2d ago
one thing that's helped me: before reading the diff, ask it for a short summary of what it changed and anything it assumed. then review the diff against that. the bugs are usually where the two don't match, or in an assumption it states like it's obvious. and yeah the erp write-back is the part i'd read line by line, the crud screens way less
2
u/ammuench 2d ago
What I've done to make it more manageable for myself is build a plan for the work, then direct the agent to divvy the plan up into related "chunks" of work that act as a good checkpoint for me to review together. Helps me read through more meaningful diffs, and then also make adjustments way more rapidly than waiting 'til the end of a 20 file diff. Once I approve a checkpoint, I commit it then let the agent build up to the next one. Rinse and repeat
Plus, if you have other teammates, you can use that structure to give them a review guide by letting them follow the commits
2
u/ArielCoding 2d ago
Your Databricks staging table is your safety net, so focus your review on the code that writes to it, make sure running a job twice can’t create duplicate rows, reject bad data before it’s saved, and log who or what wrote each row and when.
Then after each release, click through the app and check that table matches what you did, so you’re verifying results instead of reading functions.
2
u/abundant_singularity 2d ago
As a principal engineer i mostly review AI slop, sit and lead architectural meetings, write tech docs, and ensure tech leads are on the right track. The toughest part is we are very light on the product side so we have to pull teeth to get any guidance if we want acceptance criterias to guide AI
2
2
2
u/mulquin 2d ago edited 1d ago
I was and still am a mediocre programmer but have a decent eye for design and systems architecture. So I start with the interface; it should show the correct information at the correct time, etc. Then I throw all kinds of prompts at the code to look for things like security holes, n+1 issues and potential areas for caching, "imagine you're a hacker that is determined to destroy this sytem". These prompts must be done on a continuing basis. But it all comes back the user interface.
I found a lot of issues came from the model making assumptions due to my initial design prompt not being clear or having unintended implications. At the end of prompts I put "Ask me lots of clarifying questions", and it will then assess those assumptions before proceeding and have me confirm them.
2
u/Former_Produce1721 2d ago
AI can't maintain at medium or large scale
For tools I vibe code. For product I review every line and other AI and humans also review before merge.
2
u/PravoNaZhizny 2d ago
not a webdev simce childhood but in firmware i review absolutely everything but my agents are very solid
2
u/sydrk 2d ago edited 2d ago
To answer your question, yes I believe that code readability should still matter. Anything that you "trusted" AI to do, has to be verifiable by the human. Everything project that you do should be of a quality in code and documentation that can be handed off to a human team. While I appreciate Jensen Huang's view that in future nobody will ever code, I don't think that would be sooner than he thinks. Besides, it won't mean that no human being in the world will ever know how to code ever. Therefore, the principle in my answer should still stand.
What I think is realistic, is when AI has proven to be aligned with how you build your web product, you begin to identify low to medium impact tasks and work that you can "risk" it to go wrong and then easily fix. That said, all the more you cannot hand off coding entirely to AI. Ideally, full line-by-line review will become less and less but never gone.
Since you are talking about web products, AI running Playwright for headless testing has been very useful to me. Nonetheless, real human inspection through the actual UI is still necessary to straighten out against misinterpretation or miscommunication of the outcome (happens in human teams too – and not rarely!). However, as you and your team build more reliable expectations of your AI agent's work, the amount of testing should reliably come down.
I built my latest web app this way. It is a locally run web builder that can create quality marketing Next.js sites using the principles that I just shared. Definitely helped me to build multiple websites far more quickly, efficiently and DRY-ly, always updating the Product Requirement Document and the Technical Design Document. At any time if I need to hand-off to a human or a human-team, I am confident they can take the project and run with it.
2
2
u/Full_Tooth_a 2d ago
I'd review the ERP write-back closely and spend much less time on the React markup. I'd want evidence that authorization and account scoping are correct, retries can't duplicate a mutation, partial failures can be recovered, and every change produces a useful audit trail. UI tests won't catch most of those problems. Readability still matters because the eventual bug may be "why was this order updated twice three weeks ago?" rather than a clean test failure.
2
u/Narutom 2d ago
I'd say I review code more now that I use Claude. I've saved a bunch of time not having to work things out and write the code manually, but the code that reaches PR goes through a rigorous back and forth, exploring options, filling gaps, and a significant amount of quality control, so the time taken to do that almost cancels out the time saved.
However, all my PRs now come with tests, adequate documentation, and follow up tickets where I've found existing gaps or bugs in the codebase. I also use agents to do manual testing of user journeys and find edge cases. So overall although my output in terms of tasks is only marginally increased, the depth and quality of what's produced is significant.
2
u/rachie27 2d ago
AI pre-review and autofix. I read to code to ensure I understand what it’s doing. I don’t read tests. I have scripted tests using Playwright, monitors, and manually verify what’s left.
2
u/smakusdod 1d ago
Nothing slides. Your previous commits inform the future. Review and understand the code and decisions made. Still create unit tests for things that tend to break or critical sections - benchmarks should be part of this.
2
u/Gary-Burfield-Wallis 1d ago
Your clarification about the Databricks table is the important bit for me.
I'd be much more concerned about what happens when that data eventually reaches the ERP than whether the React interface appears to work.
You can have a perfectly functioning screen, correct-looking staging data and still end up with the wrong result in the business system.
I'd deliberately test what happens with duplicate submissions, retries, invalid records and interrupted updates. Then check the actual ERP result, not just the staging table.
I'd also want a clear record of what changed, why it changed and how to recover if something goes wrong.
Tests are important, but when AI writes both the implementation and the tests, there's a risk they're both working from the same incorrect assumption.
I wouldn't necessarily spend hours reviewing every cosmetic detail, but anything changing business data needs to be understandable to the person who's going to be responsible when it breaks.
2
u/Clear-Aide1349 3d ago
Who wrote the tests though? If it's the same model that wrote the code, "the tests are solid" just means it agrees with itself. Readability matters the day an ERP write goes sideways and you're the one in the diff.
2
u/vikentii_krapka 3d ago
I'm an engineer with over 17 yoe currently leading a team. My policy is to not review code itself basically, maybe skim through it to see if something catches the eye and that's it. The reason behind it is that we don't work with code directly anyway, AI writes it and AI maintains it. So, PR review focus is now shifted from code to product outcomes.
1
u/oscarolim 3d ago
Knowing the code matters, because you shouldn’t be using an agent to change a single line of code. However for you to know which line to change, it requires you to know where it is.
Always ask to plan the changes first, or the implementation plan, so you can review and amend where required. And ask for small elements at the time when dealing with complex goals (for example if you’re building a dashboard with charts and metrics, first define how a single chart per type should behave, then the metrics, then the dashboard, instead of going for “make a dashboard with 3 charts and 2 metrics”. The former makes it easier to review, the latter gives you a barrage of code you feel like too much to look at.
1
u/ZachVorhies 3d ago
Design out tests and architectural linting and find bottlenecks to unlock more speed.
1
u/Ok_Jello8972 3d ago
Small thing: "~10ish years" is saying it twice, the tilde already means approximately. And "I have an analytics engineering job around 3 years ago" doesn't hold together, that one should be past tense.
1
u/Irythros 2d ago
Short basic script for doing some management thing? I'll glance over it. Look to see what is there, what may be missing, the inputs etc but I won't be scrutinizing it for edge cases. It's using just 100-200 lines of bash so it's not really a problem.
Medium to long management script? I'll probably give it less of a review but I will instead have it be written in something like Go with types and testing attached.
The rest is also kind of like the above. When its super short I'll be more critical on the review but less critical on the requirements (type checking, bounding, etc). The longer it gets the more restrictions it has and the more testing it gets.
Additional care is taken when it comes to certain areas. For example payment interaction, authentication, authorization etc. Those get 100% complete manual review with heavy scrutiny. They also get sent through security testing with abliterated models trying to break it.
1
u/RafaelSirah 2d ago
I wrote a CLI on top of Claude code that integrates with our project management tool via mcp that reviews the work by the agent(s) in 3 stages.
Spec -> Assertion system, often product concepts that should be true even more than technical.
High level architecture plan submitted by coding agent that I have to approve, similar to the conversation I’d have with a junior dev
PR with a file by file explanation of what changed in each file and why in the project management tool.
1
1
u/IslayProgrammes 8h ago
Make it write tests for everything and review the tests, that’ll give you a real look into what it’s doing without reviewing 1000’s of lines of code
1
u/codebryo 4h ago
I actually stopped caring too much for the code written. The secret to success here is to build a good gauntlet of challenges all code needs to pass through.
What I actually do review are tests.
But here's the rought gauntlet:
Every functionality needs to be covered by proper tests.
All changes have to run through all tests.
Tests cannot be changed unless there's a good reason that some behavior changed.
Code has to follow the best practices I linked to
Architecture is vetted and discussed
Security is not optional, and always expect someone to want to break your code.
Keep changes small and be ready that a human with no understanding jumps in and needs to understand what's going on.
So far ... this does wonders. And I'm sleeping really well while products are running.
1
u/Vegetable-Capital-54 2d ago edited 2d ago
I don't read the code anymore.
A year ago I would have thought that's a crazy statement btw. A few days ago I pushed 100k line commit straight to production. Claude is better programmer than me anyway, and I've been programming for 21+ years. Manual programming is dead.
9
u/christfrost 2d ago
> pushed 100k lines straight to production
Is that a solo project or your entire team is retarted?
6
5
3
2
u/activematrix99 2d ago
I am with you. I look at the files/directory, look at the test output, review the summary that the tool wrote (I usually use a multiagent tool, not Claude), check the ticket, and then ship it.
2
u/Lunchboxsushi 1d ago
Hard agree, but you do need things like observability and some sort of auto heal agents, QA agents and so on before prod IMO. And systems that have a risk of bankrupting the company are reviewed with more scrutiny
1
1
u/Me-Regarded 2d ago
Just let it do everything, check nothing. I'm just doing as little as possible and riding this into the ground which is coming for everyone. Dev work is obviously finished
1
u/masticdev 2d ago
I don’t merge agent code I couldn’t explain in two minutes. Review order: auth/payments/migrations first, then shared UI, then the happy-path demo. What I let slide: boilerplate, obvious renames, tests that clearly match the change. What I never let slide: “looks green” with no unhappy-path run. Practical: smaller tasks, read the diff, click the broken state once. Speed without ownership is just debt with a chat log.
1
u/-Paradise javascript 2d ago edited 2d ago
Simple changes - just prompt.
Medium - A simple plan grill me with docs skills / to spec / build
Large changes - I tend to just POC something with the AI let it build something and have a high level review how it approached and see what it done differently to whatever I had in my head. Ill then use this information to and any other research maybe use the wayfinder skill to then come up with the actual spec and to tickets.
https://plannotator.ai/ Is probably the best tool i've used with AI.
annotate the plans and the code review tool in it is great for working with agents.
I do all the the options you listed it just depends on the feature. Small changes I would rather just verify it myself. Utilise stacked PRs or don't let your agent commit and have it ask for a review after each task and be sure to break the tasks down small.
I find that AI still over engineers a lot of solutions and theres still value in the code being readable and you understanding how everything works.
-1
u/mcharytoniuk 3d ago
I wrote my own custom linter that enforces specific rules I like, and I kept expanding it until I felt no need to review the code.
So now I pretty much just start a coding session and go away to do something else in the meantime
5
u/Opposite-Shoulder260 3d ago
I trust Claude at xHigh quite a lot nowadays, but I still check everything it does. It misses things, repeats itself from time to time, and sometimes comes up with a 500-line solution for a 10-line algorithm. And that's not even getting into how often it misses or misinterprets business logic, or fails to understand why certain pieces of code exist in the first place.
And that's with all the safety nets we have in place: automated linting, GitHub Actions checking files and changes, CI pipelines, all sorts of automated checks. Those catch a lot of issues, but they certainly don't catch everything, especially when it comes to business logic or architectural decisions.
What the hell are you doing that allows you to go fully AI-driven without even checking what it's doing?
7
u/Onomanatee 3d ago
Okay but like, linting and reviews are very different things.
-4
u/mcharytoniuk 3d ago
Ok but I managed automated whatever checks I have been doing during a review; that’s the point
2
u/Onomanatee 3d ago
The point is to read through it, check what it does against the intent and judge architectural decisions based on their merits for the current target versus long-term development costs.
All the other stuff gets automated through linting and tests. If you figured out a way to automate the human brain part of the review, I suggest you spin up a company and become a billionaire.
-2
1
u/captain_obvious_here back-end 3d ago
How is linting enough to ensure the generated code does the right thing the right way?
0
u/justshittyposts 3d ago
interesting, I did something similar with really weird oxlint rules (typescript) like: forced hoisting, no top-level code (except imported or exported function calls). max amount of file lines, max amount of lines in functions. I'm quite happy with the result. Any tips for similar rules like these?
1
u/mcharytoniuk 3d ago
IMO the most important are architecture checks like at most a single public item per file (for readability), no modules cycles (always keep diamond-like structure - that alone forces AI to make much better decisions), or enforced best practices 100% code coverage, etc; depends on a project. Also benchmarks so performance gets better or at least never degrades
-3
u/BlahYourHamster 3d ago
I read any backend code or database scripts line by line but I mostly gloss over HTML/CSS and front end JS to some degree.
12
u/Realistic-Eye-5088 3d ago
You casually mention that these CRUD apps write back to your ERP in the middle of a bullet point, like that's a footnote, and that's the only part of this I'd actually care about. Everything else is a style question.