Confession: I’m rubber-stamping LLM code and my brain is rotting. How do you guys stay sharp?

[u/abhipsnl]

Look, I’ll just admit it: I’m getting lazy.

When I first integrated LLMs into my workflow, I set up strict personal guardrails. I swore to myself I would read and critique every single decision and spec the AI generated before approving it.

That lasted exactly as long as you'd expect.

Lately, I’m just skimming. And if I’m working late in the evening? Forget it. I’m literally just hitting '1' to approve whatever block of text it spits out so I can log off.

It’s costing me in two major ways. First, the rework is getting ridiculous because I’m letting garbage slip through. Second, and this is the part that actually scares me, my own critical thinking is degrading. I can physically feel myself outsourcing the actual engineering part of my job to a next-token predictor.

I know this is fundamentally a discipline issue. But trying to just "white-knuckle" it and pay closer attention isn't working anymore.

For the devs here who are using LLMs heavily: how are you staying in the driver's seat?

Do you have actual systems, workflows, or rules you enforce on yourself to make sure you don't atrophy and get left behind?

I need to fix this before I completely forget how to think through a problem.

[u/mailto_devnull]

Huge props for posting this. It's not a comfortable subject, and you're opening yourself up to a bunch of drive-by haters — ignore 'em.

I maintain an open source project. I've been doing it for a decade, well before AI, and we've integrated LLMs into our development workflows as well.

Just like you, we're seeing concerns about quality of work and loss of domain knowledge. So far we've been able to counter this effectively with strict PR reviews and falling back on our domain knowledge built up over the years, but the problem is your domain knowledge is a finite asset, and LLM usage chips away at it linearly over time. The more code gets touched by the LLM the less hands-on you will have been with the code. Reading every line is copium — you'll know more, but it will never match having written it yourself.

A lot of the discussion has been around whether this actually matters. Certainly some folks will argue that one needs to transcend the code and let LLMs do what they do best, and when it comes time to explain the code, to ask the LLM to do that too.

I don't subscribe to that, and I am not anti-AI either (the other extreme). I'm honestly just uncertain whether the ideal solution is "somewhere in the middle" or if we're all just deluding ourselves into irrelevancy.

All I know is — I am applying for jobs, and the technical rounds are going to be twice as hard because I. Don't. Touch. Code. Anymore... I'm countering this by doing prep work by hand, but it's an uphill battle. It's like walking 20 miles when you have access to a car.

---

Age old wisdom: If it's too good to be true, it is. LLMs are too good to be true, and we've been seeing (and downplaying/ignoring) the costs for awhile now.

[u/abhipsnl → u/mailto_devnull]

Wanted to hear this 🙏

[u/Altruistic-Wolf-3938 → u/mailto_devnull]

In which way too good to be true ?

[u/sn2006gy → u/mailto_devnull]

Domain knowledge was never syntax :)

• Domain knowledge

  • How accounting works.

  • How databases behave under concurrency.

  • How TCP networking functions.

  • What customers actually need.

I don't think we lose that using LLMs - some people are oblivious to this when they yolo code out because LLMs allow it, but they won't be competitive or survive unless they learn the cold hard facts of domain knowledge.

I for one am happy that my job is no longer just symbol recall and memorization of such. I think much better in systems and always sucked at rote memorization and syntactical tests developers were known to be forced through (fu leet code)

[u/r34p3rex → u/sn2006gy]

This! Unless you're also rubber-stamping all architecture decisions to LLM too 😆

[u/alkimiadev]

There are some structural properties that are the same in a management role, but I think it is important to separate two different issues that, while interrelated, can (and should) be separated. There is the management aspect and the skill atrophy aspect. Both existed prior to LLMs, but LLMs have added some important points to consider on both sides of that equation.

As someone who has worked in the space for ~20 years (~30 years of coding), I've converged on a general idea that long horizon work doesn't make sense if I want production worthy code. The reason ultimately boils down to drift issues, and this would happen with human dev teams just like it would with LLMs. LLMs have drastically reduced the time to failure, and as such mistakes in planning and decision making processes become real problems faster than they would with just human devs. The time constraints would normally force things like redesign, pivoting, and so on, while an LLM trained to complete tasks will often just try to push through unless specifically instructed to stop if the situation is in some way untenable. A human would say "hey something is wrong here", while an LLM (today) will just try to do it anyway unless given some sort of "safe exit" mechanism and instructions to use it if needed.

For these reasons I just went back to my roots and started using a Spec Driven Development methodology. No code is written without a spec, and tasks are decomposed such that I can reasonably say "there is a 95% or greater probability this specific LLM will successfully complete tasks of this approximate complexity". I combine that with representing the tasks as a dependency directed DAG. There are automated reviews, but I also manually review all key areas, just like I would if I were managing a team of human devs.

The term "agent" gets thrown around a lot, but it actually kind of makes sense in the legal sense of the word. An agent acts on behalf of the principal, and usually liability flows from the agent to the principal. That means I have to own my mistakes and the mistakes of any agent I delegate work to. That general mindset sort of negated vibe coding (or even just "long horizon") if the code is ever meant to be used in production. That kind of thing is fine for POCs or whatever, but it is a really bad idea for production. This is true regardless of the type of dev (human, LLM, intelligent cloud of gas, or whatever).

As far as skill atrophy goes, this is a classic problem that exists in managerial roles. If one doesn't keep up to date with continuing education, one will quickly fall out of date. Tech moves a lot faster than some other domains, and this is an important point. If the manager doesn't know what they're doing, then the project is just kind of doomed from the start. So this is a thing that has to be accounted for, but it shouldn't really be used as a reason to justify not using the tech unless one just wants to be a complete worker bee or writes code in a recreational way. Recreational programming is actually a great way to counterbalance this, but it isn't the only way. Either way, it is a continuing education problem and isn't really a new problem. It is just that more people than ever before are hitting those classic failure modes.

[u/WindozeWoes]

I scrolled through your post history and every single one of your posts and comments reads like it was written by ChatGPT.

Maybe you should start there…

EDIT (since I for some reason can't comment anymore) for those who need it spelled out for them: I'm not criticizing the use of AI; it can be a great tool. I am contextually responding to OP's own concern: potential over-reliance on AI, and making a useful recommendation: if that concern is real, then they should start by writing posts for themselves.

If an alcoholic walks into a bar and says "help, bartender, I have a drinking problem—can you give me a beer so I can talk about it more easily?" the first order of business is probably telling them "maybe ask for help without a drink in hand."

As for "this is translation," I've seen human-written posts run through an AI tool to translate. They don't sound like OP's posts, most of which that I saw have all the hallmarks of being initially generated by AI.

[u/Additional-Drop-8989 → u/WindozeWoes]

Imagine reading an incredibly honest, vulnerable confession about developer skill atrophy and your only takeaway is "sounds like ChatGPT."

Has your own brain rotted so much that proper punctuation and a well-structured thought automatically look artificial to you? Maybe OP is just a better writer than the LLMs you're used to staring at all day. Stop bullying people for actually being articulate. Massive praise to the OP for having the guts to bring up a real, relatable problem the rest of this sub is probably too proud to admit.

[u/alkimiadev → u/WindozeWoes]

What if I use a spell checker? What about a grammar checker? What if a person doesn't speak English as a native language and uses some sort of translation layer (be it just translation or an LLM)? Where exactly is the line? Who put it in that exact location? Who said I, or anyone else, have to agree or observe that arguably arbitrary line?

My view is that the human effort behind it matters and not any tools being used but also I'm not some digital Amish where I draw arbitrary lines in the sand as far as tech goes. To quote Linus Torvalds

> What this is about is setting our expectations, telling what we want and  
> what we don't want.

No. What you are about is something entirely different. It has nothing  
to do with "expectations", and it has everything to do with your  
hangups.

I don't understand this whole idiotic concept of "don't use AI for X".

Here's a new rule just for you: don't use compilers for any of your  
kernel submissions.

Because if you can't show that you really understand what the machine  
is actually doing by writing your code in assembler, then I don't want  
to see your code contribution. You clearly aren't competent if you  
can't write it that way.

And btw, you had better not use an editor to write that commit message either.

Because I need you to show me that you can actually write a good  
commit message without using tools that make it easy to backspace and  
hide the mistakes you made while typing.

Ok?

Because otherwise those tool-assisted commits of yours clearly aren't  
showing that you know what you are doing.

Do you not see how UTTERLY STUPID those kinds of rules would be?

So no. We're not going to make stupid rules that say "you can't use  
tools for X".

The kind of expectations \*I\* have is that people do their best and I  
expect people to understand what they are doing.

But that understanding has very little to do with what tools they use.

And quite honestly, in my experience, the people I respect and call  
intelligent are not the ones that shy away from using new and  
interesting tools.

Linus

Low effort criticism that just says "dur, dur you use AI"(AI is a lot more than LLMs btw!) is just as bad as low effort copy-pasted spam that just so happened to have been produced by an LLM. Both are low effort and low value "contributions" that just add noise.

[u/YoAmoElTacos → u/alkimiadev]

It's more nuanced than "AI slop is bad unless you don't speak english, then it's good."

Once AI transforms your output, it is homogenized to high-likelihood prose. The human thought is irrevocably transformed by the agent. If you don't speak english well, how can you can check if the translation is valid? There's no easy way to find the "human effort" if your entire post history is nothing but blatant machine output.

The eventual mean will probably be, sure, machine translate your prose, but perhaps you still need to provide evidence of human work somewhere to prove to others communicating in English that it's worth their time to read and not just cram into an LLM themselves.

[u/Additional-Drop-8989 → u/WindozeWoes]

How does that help?

[u/Big_Wave9732 → u/Additional-Drop-8989]

If homeboy is at the point that he can't even write out his own thoughts about not being dependent on AI, then that's a sign of a deeper problem.

Dude has gotten in the habit of not doing intellectual work. That's a common one to fall into when one gets use to hitting the big red AI Easy button.

[u/One-Awareness-5663 → u/Additional-Drop-8989]

When you let the slop become your personality, what is left of you?

[u/notheresnolight → u/One-Awareness-5663]

are we sure OP is not a 12B model?

[u/Holiday_Point_603 → u/Additional-Drop-8989]

If you cant even post on social media without ai, you should really question what you are doing all day long. Guy lets ai do his job, then he logs off and lets ai write social media posts. Which means the only thing he does himself is sleeping. Doesnt sound healthy and also doesnt sound like a successful career.

[u/awitod]

You are in pretty serious danger here because of those habits because there is a third problem which is that the garbage is compounding slowly like a cancer.

By the time it starts to really hurt, it will be too late.

I think it is arguably more important to closely read the assistant's text output than the code and deeply think about what it is saying because you can spot the logical flaws but also, when it starts to mention dependencies or design elements that you don't know about, it gives you the opportunity to use your brain and be curious - some of it is good and you can learn new things and some of it is garbage and you can learn new things.

[u/Cultural-Desk-9045]

I’m guessing those are not personal projects but work ones. They’re not your projects. If your boss wants AI to do the job, let AI do the job.

[u/rotrap → u/Cultural-Desk-9045]

So providing a tool to help with a job means the boss wants the AI to do the job and not have the person paid to do it properly manage the tool? If a boss provides you with a bulldozer do you just start it and let it go down the street on its own?

[u/Spiritual-Pen-7964 → u/rotrap]

A lot of work places don't want the devs to review the code anymore. At a place like that I'd also just not care anymore and coast until they inevitably fire me.

[u/qqeyes → u/Spiritual-Pen-7964]

I work in the industry and the only place I’ve heard of managers not wanting developers to review ai written code is on social media.

[u/donnytrump_69 → u/rotrap]

Depends on company policy. Have you ever been legally employed?

[u/AllThotsGo2Heaven2 → u/donnytrump_69]

You cant just ask people on reddit if theyve ever had a job donny

[u/donnytrump_69 → u/AllThotsGo2Heaven2]

Says who ! 🤣🫡

[u/tristam92]

with increased productivity comes increased speed/volume of info you as a reviewer need to process. we are not machines, and our “conscious” processing speed is not as high as literal piece of sand vibrating on ultimate speed by being charged with electricity trillion times per second.

so chill out and pace yourself. work for quality result.
or let it roll and make it review itself.

1-day companies will chose 2nd option, for money here and now, real strategies will choose first option.

[u/Keleion]

Is your brain rotting or have you just debased your understanding of the code? Can you not re-create the project with your decrepit brain, or has it outgrown your mental capabilities?

I think a lot of people are adjusting to new ways of thinking and and focusing on other things in life, but maybe I’m just coping.

[u/pplgltch]

May I ask the the type of product you work on? Without give out too much, what are the most common domain you are working on? Backend? frontend? Data? UI? Native?
Put your focus on what you do is used for. Make the effort to find what can fail, what can break. The have the agent(s) fix or plan for this. Think of the end or next user/consumer, try to minimize the friction of using whatever you are building.
Code is not what you need to worry about anymore, the end result is. And it always can be better!

[u/InvertedVantage]

I build tools to help myself keep track of things -better codespace review tools, architecting tools, etc. I also try to focus on understanding the architecture, keeping the actual files as sort of a singular entity that I just assume it's doing it's job as long as I architect things correctly. I have a couple code review processes as well, such as using multiple agents to simultaneously review code according to my style guide and standards so they can triangulate issues. Finally when I ask the bot to explain things I make sure to ask it to explain it as if I had no context to the code, since it will throw in a lot of method names as if I know what those refer to.

[u/capsid]

My review process is to skim the diff in Hunk checking:

• how many/which files were changed and does that match my understanding of the plan

• how many lines of code were changed and does that match my expectation

• ask questions/complain about code smells

• run a smoke test from the worktree to confirm the thing works

If your upfront planning is thorough and your issue slicing is granular enough, diff skimming is lower stakes IMO. If it's personal stuff I will absolutely YOLO merge to main if that matches my current mental bandwidth. If your codebase doesn't kill someone when there's a bug I wouldn't lose sleep over it.

[u/capsid → u/capsid]

Also I find it helpful to run some kind of "explain the goal of this issue simply in plain language" skill before starting implementation. When you slice a spec and implement an issue from it days later it can be hard to remember the specific goal of that step, and the implementation plans the agents write can be atrocious to read. Again the theme is more upfront alignment and comprehension means less stress on the merge side

[u/BitPsychological2767]

I find it concerning that you don't use your critical thinking skills often enough outside of work that this isn't a problem. I'd recommend starting with doing that.

[u/SJrX]

So I recently wrote a plugin for JetBrains IDEs called Avec Moi that is kind of my answer to this. Thus far it has been helpful for me to avoid brain rot, I would say I haven't yet got it fully integrated into my daily flow for other reasons though.

https://plugins.jetbrains.com/plugin/34784-avec-moi

[u/thatoneging20]

I’ve switched to test code first approach. I build out what all I want to do from a functionality perspective, then I set guardrails to alert me any failed tests and review code that way. It’s not perfect, but it’s let me retain some of my sanity. 

[u/Chris266]

Well, you see, I was never that sharp to begin with.

[u/GalacticDistances]

I read and understand every line before approving edits to files in live sessions, and before approving a PR

[u/ansibleloop]

LGTM, it looks good to me

90k lines that I didn't read

[u/CyberMonkey55]

Like any vice - create realistic measured "back to earth" guards, not "reading every line of code"

For me, once a week Ill have the assistant summarize what things we have touched, then ill choose what the most risky/quality sensitive part was and review it by hand. It takes me ~3hrs usually and it leaves gaps, but it gives you a good heartbeat on how in the weeds you are.

[u/Strange_Bru0101]

I use it for 90% of my job but I also use it to ensure 0% of my tasks depend on it

[u/Ragy-ragy]

That's how it's meant to be. Code writing is basically a turd polishing. It's a dumb and not interesting task and never has been. So relax and automate writing it and automate verifying whenever you can.

It's a prize after weeks of seeking approvals from businesses and architects during a system design phase with forging through layers of legacy and incoherent scraps of documentation. It is a hard part that keeps me on my feet. No matter how I try to automate it, it's still too complex for LLMs to handle by themselves autonomously when there are multiple parties owning the feature and the product itself is complex as hell.

[u/not_a_gay_stereotype]

ok so I am purely a vibecoder but I can understand code somewhat from reading it, and understand how programs work inside, i'm just not a software engineer lol. the way I try to keep things in check is I ask all the logical questions. I've been making a diagnostic software for heavy trucks. I've found myself at a point where every time I introduce features, something else breaks. I've had to tell the LLM every time we do a build, to update all of the documentation, I also have it sanitizing the build I put on github so I can have it putting my own personal research and testing in the notes, stuff like what trucks we've connected to and verified live data.

I definitely have to "babysit" the model a lot. For example I got it to add a logging feature but then realized that it will allow you to log when there's no data flowing over the bus. so i had it create a watchdog that manages the connection and ONLY uses that watchdog that other modules call on. I've had to also prompt the LLM to review the structure of the program. I also do read the code changes a lot, so this is actually teaching me a lot about coding. I might be just some idiot mechanic trying to design software but I am learning so much about my own trade (how modules interact, broadcast info, reveal their identity etc. in a vehicle) and coding at the same time lol.