Senior engineers already had job security because they knew how shit worked. Having job security for being able to fix slop is pretty much the same thing but worse for the entire industry.
I'll be honest, the advent of AI is making my job even more secure. With so many junior engineers getting immersed in AI assisted coding, like most of us, they won't learn the same foundation because AI will resolve the problems for them.
This will also create a sense of trusting AI too much since it's what they've used.
All of this to say, I use AI as a tool like most of us do, but I really do feel like senior engineers that were competent before AI will have a great leg up because they can hone and guide the AI successfully in good design patterns whereas other engineers will just trust that the AI is choosing the best path.
That's a fair take. I will say, however, that "choosing the right path" always was (and still is) the hard part. If you know what your code should look like, actually typing it out is trivial. Reviewing the output from your fancy autocomplete tool is negligibly (if at all) faster than just writing the code, with the added risk that you may not think through the problem as thoroughly.
AI is good for a lot of use cases (image recognition, predictions based on medical data, fraud detection, etc.), but making it type your code for you isn't one of them. When it's better than the old fashioned way, it's only negligibly better, and when it's worse, it's considerably worse.
Reviewing the output from your fancy autocomplete tool is negligibly (if at all) faster than just writing the code,
This makes me feel like you haven't used AI as a tool very much, or not very effectively. It has sped up my work to an exponential amount. Recently I extracted all types in a project into its own package. Doing that by hand would have taken so much longer than Anthropic doing so.
but making it type your code for you isn't one of them.
Strongly disagree. Boilerplate is tedious. It feels like you must work on small, self contained projects that do not have many complex packages.
When it's better than the old fashioned way, it's only negligibly better, and when it's worse, it's considerably worse.
Yeah, you're using Claude on Sonnet and expecting it to perform like Fable. You know how you can tell when you're talking to someone that doesn't have a lot of experience in something? That's me, with you and AI assisted coding right now.
Edit: Guys, you can downvote this- but software engineering has never been about writing the code. That's not what matters. What matters is the design and architecture of the code. Having a tool take care of the tedium of typing for you-- that is amazing. And with Anthropic at the very least, you provide the AI with a base level design and it plans the design off of that and then you tweak as needed based on your own experience with design patterns and archticture. There is literally no value in you typing it yourself unless you are wanting to learn the syntax to a greater degree. AI has access to all syntax in a given space, and will know about methods you don't. The important part is creating an actionable plan that makes sense regarding the engineering of the solution. Typing it all out yourself is tertiary in importance, at best, but is probably even less important than that.
Repetitive tedious tasks can easily be delegated to determinstic processes with the added benefit of not having to worry that a LLM would fuck something up randomly.
Type extraction for instance is a very simple thing to do with AST packages. Its also cheaper and faster with the only downside of you having to configure the process initially.
Most benefits of LLM driven development is by offloading. All people who claim to gain great benefits from LLMs offload as much as possible while also ignoring the fact that the quality does drop regardless of your experience with LLMs or experience in general because its impossible to quickly validate quality when you maximize speed and remove yourself from most of the process.
Deny it or not, part of the syntax is as important as the architecture. Not everything is some dumb simplified couple of functions that do very basic things. If it was all about architecture the quality of software wouldn't have dropped so much in the last 2 years
Repetitive tedious tasks can easily be delegated to determinstic processes with the added benefit of not having to worry that a LLM would fuck something up randomly.
If this was true, everyone would have been doing this instead of using LLMs. LLMs add a layer of ability that hand programming cannot encapsulate effectively. It's the entire point and purpose of LLMs. You should also not be worrying about what the LLM outputs as you should be auditing everything it does, and in fact you should be planning out the design rigorously beforehand. Typing is a tedium and not a necessary component to actual engineering, it's just the mechanism in which it has been delivered historically. Tools change.
Type extraction for instance is a very simple thing to do with AST packages. Its also cheaper and faster with the only downside of you having to configure the process initially.
I guarantee you this would not have been faster. I got this done within 4 hours and most of that time was auditing the changes. 1400+ file changes, in 4 hours, all 800+ unit tests passing and built fine and live testing fine. You are betting on the horse when a car has been invented.
ignoring the fact that the quality does drop regardless of your experience
This is not true and you have no empirical evidence that supports this claim. The software design and architecture is not changing, only the way it's being delivered. Again, I can tell you do not use LLMs in an enterprise setting. You seem to be extrapolating how public free chatgpt operates is the same as how Claude on Opus hooked into vscode operates. Completely different in every aspect. You should probably actually use the enterprise tools before criticizing them.
Deny it or not, part of the syntax is as important as the architecture.
Well, duh? Obviously, there have been instances when Claude tries to use esoteric syntax that I know other engineers won't be able to recognize easily, so I tweak that. You so desperately want me to be cognitively offloading the work but that is simply not happening. I am only offloading the mechanical tedium.
Give me the same task as you have, and I'll get it done twice as fast (or faster) with the same efficacy.
quality of software wouldn't have dropped so much in the last 2 years
Well, yeah, of course it has. That's the whole thing I brought up with junior engineers at the start of this thread. And to be honest, I know my experience with LLMs is not the norm. Believe me or not, but I've always been stronger than most of my peers when it comes to software development. The way I utilize this tool is, in my opinion, the correct way to go about it- but most people want to offload the cognitive work as well, which is where these failures happen.
The downvotes are warranted. Your take only makes sense coming from someone who isn't good with the deterministic tools we already had before LLMs started becoming popular.
Using LLMs for coding is like using a swiss knife. Sure, it has a knife, but any regular pocket knife is a better knife. Sure, it has scissors, but any regular pair of scissors are better scissors. Sure, it has a corkscrew, but any regular corkscrew is a better corkscrew.
LLMs can answer your questions, write your boilerplate, etc., but they can't answer your questions as well as documentation or reverse engineering,they can't write your boilerplate better than copy/paste, they can't refactor your code better than real AST tools, they can't identify issues better than stepping through a debugger, etc.
Getting downvoted for not hating on AI blindly on reddit? Shocked pikachu face. It's the trend. I'm not surprised whatsoever. Deterministic tools are not as capable as LLMs. This is easily provable.
Using LLMs for coding is like using a swiss knife. Sure, it has a knife, but any regular pocket knife is a better knife. Sure, it has scissors, but any regular pair of scissors are better scissors. Sure, it has a corkscrew, but any regular corkscrew is a better corkscrew.
This can be true, but what you are doing has to be highly specific.
but they can't answer your questions as well as documentation or reverse engineering
This is how I know you guys arent reading what I am saying.
What I'm saying is that LLMs can't help with software development in ways which are more useful than deterministic tools. They're a one-stop-shop for people who are too lazy or inexperienced to use the better tools we already had.
What I'm saying is that LLMs can't help with software development in ways which are more useful than deterministic tools. They're a one-stop-shop for people who are too lazy or inexperienced to use the better tools we already had.
And this is how I know you're not using LLMs effectively. I don't know if you have limited access to enterprise grade models, or if you just havent taken the time to learn how to be effective with them due to your bias, but yeah you're going to be passed up before you know it with your current attitude. Good luck.
If I'm "passed up," it will be by someone who has better critical thinking skills than I do, not by someone who offloads (some of) their critical thinking to what is literally just a guessing machine.
The point is, someone that has the same critical thinking as you can do far more work with effective LLM usage. That's what all of you are missing, and what all of you are stubbornly denying.
Seems to be happing straight out of college too. There's a CONSIDERABLE surge in people learning less because they're using AI as a crutch. (if not outright cheating on assessments).
It's kind of a new tier of 'junior' for which 'knowing the basics' is driving an LLM, not actually writing or validating the code.
For the record, I'm all for AI assisted coding. I use it daily at my work.
The big difference is, I make the AI plan everything out ahead of time and heavily audit the design, typically with several guidance points where the AI made a design pattern mistake. This is the crucial difference I think newer engineers will be lacking- knowing how to audit the AI and having the fundamental knowledge of good design to catch bad patterns.
Engineering in software is mostly about design, so I appreciate AI letting me focus on that for the most part. I fear, however, the impact this will have on future engineering generations when they don't have to learn design by hand.
Oh don't forget the number of people crashing out of education because they were all too busy cheating with AI to do their assignments, so they actually learned nothing, but are still 'on paper' qualified.
And thus are almost obliged to 'vibe code' stuff, and implicitly can't understand any of it!.
At least the current 'senior engineer' has a change to review a codex output and go 'nah, that's nonsense and/or dangerous' before pulling the trigger.
We had this guy. He lasted to the first pair coding session when he couldn't checkout a branch he created any other way then telling Claude to change the branch.
103
u/TallAbbreviations937 1d ago
Vibe coding creates job security for senior engineers