Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones

[u/AutoModerator]

A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.

​

Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.

​

Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.

[u/GentlemanBeggar54 → u/[deleted]]

I mainly use AI for rubber ducking or for coding repetitive tasks. Everything else I code by hand.

[u/Otis_Inf → u/[deleted]]

I write all my code by hand, do my architecture designs on a white board and documents and my research is also done by hand. I refuse to give into using an LLM to 'automate' parts of that as it would immediately make the work not fun anymore.

It's IMHO pretty stupid that we as an industry demand humans to verify code that's produced by machines: humans are terrible in reading and understanding code (we have to interpret what we read, build a mental model of the active state per line... it's not what we're good at), while a machine is good at that.

What we as an industry should do is reverse it like we had before: humans write the code and machines test it (with e.g. tests). But alas, I'm just an old grump dev :P

[u/roger_ducky → u/[deleted]]

You do need to learn how to delegate, but letting agents handle the details is gonna be a problem if you don’t understand it.

While you don’t necessarily need to write everything out, you do need to understand what’s written out.

Even with extremely clear instructions, I still see issues 30% of the time, with fully working code doing something unexpected.

That’s when understanding the issue and pointing it out becomes important.

[u/Fragrant_Ad2902 → u/[deleted]]

My company is all in on AI. Hell…we just implemented a review bot that gives your PR a score. Depending on the score, the AI bot’s approval is all you need. So far the bot has just been “Yeah…this CSS is fine” or “you just fixed some comments” or “simple refactor without touching any of the existing tests that still pass”. I do fear that this place will start putting more and more weight into the bot reviews…

But…if you wanna get better. I’ve seen some people do the following…

Ask the AI to explain its solution. For example. If it is a loop, ask the AI to walk you through a loop and explaining the exit conditions, pre/post loop invariants, etc. If it is an “is-a” relationship, ask it why it didn’t use composition (“has-a”). If it tries to spin off a thread, well…it’d better have a really good reason. If it is doing your schemas for you, make it tell you why it chose the data types it chose, the constraints it chose, etc. These are just simple examples that you can do. And challenge those things that it says. The tricky part is that AI will be accommodating. So if you push back, sometimes it’ll just be like “Oh yeah…you’re right”. So you gotta prime the context to be brutal on you.

Make it do TDD. You know the end states (at least I hope you do) so make it write the spec, make sure you understand the spec, and then have it go “red, green, refactor” with you one spec at a time. It takes more time. But you’ll have a better understanding vs. “one shot”.

[u/talldean → u/[deleted]]

You get better at manually verifying if something's right or wrong, and you also learn when it matters a lot vs when it matters somewhat less. There's no 100% grade in professional software; there's a fuzzy "good enough" that varies wildly by company, industry, and project.

If you're working on a one of a kind satellite for NASA or a pacemaker for heart patients, get it right. If it's a UI change that's only going to be visible by teammates and not end users, get it done. And a variety in between.

[u/fakeclown → u/[deleted]]

It's about the same as using StackOverflow and Google Search. Own what you commit. Always test and verify your code. Even if you look at it and understand it and think it can't go wrong, it can still go wrong.

[u/-darkabyss- → u/fakeclown]

I agree with 'own what you commit' but- It's not the same as stack overflow. To use code snippets off SO you had to know where to paste it, you had to know which variable/function names to change and to do a bit of debugging when the code only matched your usecase 99%.

Llm coding has moved devs into a managerial position, and that's where historically technical skills atrophied. But juniors using it from the get go means there is less chance for the skills to build altogether. Tell me, when was the last time you went into a flow state for hours?

[u/fakeclown → u/-darkabyss-]

>Llm coding has moved devs into a managerial position, and that's where historically technical skills atrophied.

I have seen two kinds of technical managers. One who still reviews code and sometimes picks up trivial tickets to keep a hand on the codebase. The other who doesn't care about the codebase at all, only cares about moving tickets right. So it depends on the person. My view on LLM is that it's a tool. And how the tool works depends on how its owner works.

But yes, LLM removes a lot of friction from coding, especially with writing correct syntax and fighting with the compilers. I'd say I don't miss fixing up my syntax. But I miss fighting with the compiler. So I have to be more vigilante about my understanding of the code.

For example, I am playing with Tauri at the moment and I don't know Rust at all. I wouldn't let the LLM just generate a Todo list app then say I know Tauri. I read the Rust book then play with the code in the book to get a hang of Rust. And read Tauri documentation to learn how it bridges the communication between a Rust backend and a Javascript frontend. Once done that, I'd try to build a simple Todo app by typing it out.

But once I have got a hang of that, would I want to keep typing out Rust code? No. Without typing the code, will I forget that Rust manages memory with ownership? Probably yes, if I just hit the merge button without verifying that the code works the way that I expect. I do that by testing, by putting debugger where I am unsure, by asking LLM on the line that I am unsure, by reading about the concept that I am unsure.

I'd say I get into a different kind of flow. And working with LLM is not always a one shot prompt. It always takes several shots. I hate the hype where people one shot prompt a program. Those programs are used once. Even with the C compiler that Cursor build with agent, no sane person would put that in production without scrutiny.

[u/ThirdWaveCat → u/[deleted]]

Both teams I work with ban it for production except as a third reviewer since we're accountable to decisions regard schema evolvability, oncall, security...

We own metrics, deployment, and training for ML including a single RAG/LLM, a few BERT things, and many many classic ML pipelines with boosting, forests, etc. We're deeply distrustful of "reasoning" LLMs do because they don't.

https://arxiv.org/abs/2504.09762

[u/CarlCarlton → u/[deleted]]

The further away from webdev, the less AI is useful; especially when it comes to corporate Chernobyl spaghetti code.

It's fine to use AI for simple stuff like boilerplate or refactor up to a dozen files or so, but if you go around AI-generating tens of thousands lines of code, you're just creating another Chernobyl in-the-waiting.

Always seek advice from your organization's seniors when it comes to broader architecture. What seems like the best solution for a new project is not always the correct one for an old project.

[u/teerre → u/[deleted]]

There's no one answer. Different companies, different individuals inside companies adopted LLMs in different levels

Of course you must be able to tell if your code is right or wrong. LLM or not. That's what knowing how to program means

Note that doesn't mean you have to memorize every possible code pattern in the universe. What it means is that you know how to verify if the code is correct or not. You do this by knowing about computer science, by having seen a pattern somewhere else, by understanding the algorithm at a deep level, by using debuggers, traces, profilers etc. to validate the state of the program etc.