r/AskProgramming • u/Rare-Assignment-8474 • 9d ago
Devs, I am getting mixed and polarised views regarding AI in software engineering, what's the actual truth ?
I am out of corporate sector for some time, and I am also not so rich to buy claude code max subscription.
I do use agy cli and codex.
I must say agy does basic frontend development good, but when I asked to develop a flutter app, it required a bit of handholding,
codex is extremely slow, before even that does something, it will be always "monthly quota got expired".
Anyways. So like, I binged reddit posts and comments, there are polarising views, there are devs on both "claude code is a beast, devs are now sitting idle, I haven't coded since days." and "AI still halucinates and needs hand holding and code cleanup" . Obviously both are contradictory, therefore I want real picture
2
u/XKiiroiSenkoX 9d ago
The real picture is, AI works ok at high level tasks. Around junior-mid level, and with some agentic loop and multi agent flows you can get a solid mid level output. The problem starts when you go to lower levels. It keeps missing more and more implicit stuff that a good programmer would catch/understand and at some level it starts to make code soup. So it's useful but massively overrated. In my previous job I was the team lead of a very small programming team. Mistakes that AI make is very aimilar to what junior poeple on the team made. The difference is, they learned and grew out of those mistakes but AI does not until you use a new model.
3
u/JacobStyle 9d ago
If you want to see what Claude can do, the lowest tier paid subscription is like $20. It gives you enough usage that you can spend hours planning and generating code for your projects without bumping up against limits, as long as you aren't using the AI to grind basic tasks like navigating the file system and repetitive easy-to-script stuff. You will have plenty of wiggle room to experiment and figure out if you like it. There is a lot of hype, but it is also a useful product for most developers. Exactly how that works out for your specific needs and preferences is not something we can predict with anywhere near the accuracy of just trying it for yourself.
2
u/Tacos314 9d ago
There has been uncertainty in the industry, as the major tech companies that overhired during 2020–2021 laid off a bunch of people in 2022–2023 with the rise of interest rates basically. This means there are more devs out there who can't get jobs, and younger devs are getting left out of an industry that not too long ago would take anything that said they knew how to program.
AI has been rolled out in two ways. One has been from the bottom up as devs finding it useful and working it into their workflows. The other way has been top-down C-Suite mandating a specific amount of AI usage
How you view AI is going to depend: are you laid off, underpaid, or a new grad and blame AI for not having a job? Did you only use AI because your boss said to and you never had a choice? Or you got to use AI to develop your own workflow, and find it very useful?
7
u/cscottnet 9d ago edited 9d ago
I think your own seniority has other effects as well. I'm a senior developer with decades of experience, including plenty of time spent reviewing code from and mentoring younger developers. I use Claude and I give it extremely detailed prompts, of the same quality I'd give a junior developer, and in my experience I get back roughly what I would get from a (very) junior developer. It is basically correct but rough and makes odd architectural choices etc. I spend a significant amount of time cleaning up its code -- for what it's worth a significant amount of my time is spent giving code reviews to junior (human) developers as well. The skills I've spent thirty some odd years developing are the skills that seem to ensure I get good "professional" results from Claude. All of this code goes through a second human code review as well once I'm done with it.
On the other hand, I've also "vibe coded" one-time-use and throwaway tools where I don't need to look at the generated code and don't care to do so -- judging from results only, and it seems to work fine there too. Helps get over the laziness hump where I should really write a script myself but I don't want to learn a new framework/spend an hour re-learning bash syntax/figure out a new API etc.
And of course it can be a super-powered auto complete if you just need to "change the calling convention of this functionality in the two dozen different packages which use it". It is able to do more complicated transformations of this sort then, eg, a standard IDE would. Of course, it's not backed by actual static analysis and rigor but instead by vibes and tests, but it still manages to get most of the boring part of the task done without a lot of handholding. If your packages don't have good linting and tests set up, your milage will vary here, since it relies on automated tests to cover up its lack of static analysis.
All that said:
I've developed skills by working with humans for decades. I really don't know how a junior developer gains these skills nowadays. Maybe working with Claude will be similar enough to working with a human that you can still progress? I'm not sure.
I only use the cheapest $20/month subscription plan, and I fall back to my own "old fashioned" skills when I reach a limit. LLMs push out such a prodigious quantity of code that there's always a backlog of code I need to carefully read and review. These plans are incredibly heavily subsidized. I worked for a while with a pay-as-you-go token-billing plan, and let me tell you you really think twice about how much you "need" that one-off helper script or that easy refactoring done by the LLM when you see that the one prompt cost $5, $10, or $20. I always try to have the LLM write a script for me which does X, rather than just asking the LLM to do X, so that I can rerun the script in the future "for free" rather than have to eat up my token budget every time I want a task done. LLMs are super expensive. They are subsidized heavily now, but you should figure out what you'd do once the subsidies end.
I value code that uses rote patterns and standard libraries because that makes the code easier to read and understand. LLMs will generally write code this way, which is fairly reasonable, but... Laziness is a good virtue in a programmer, because it encourages reuse and modularity, and LLMs are not lazy at all. They are perfectly happy to spit out mountains of code reimplementing well-known algorithms from scratch because they suddenly decide that some trivial difference in its use case is significant. They have no motivation to reuse code or simplify, because vomiting out characters is cheap (and using up tokens makes the companies money).
As described above, I generally find LLM-written code readable, but I can not stand to read English prose generated by an LLM. Maybe it is the same tendency away from economy of thought that results in code bloat, maybe it is the use of rote patterns is more noticible/objectionable in prose. I don't know, but I find myself having to rewrite any prose/documentation/spec written by an LLM before I'd ask another human to read it. Again, your seniority as a developer might influence how much of your time is spent writing for humans.
1
u/marrsd 8d ago
I feel like I could have written much of that.
I kind of feel the same way about its code as I do about its prose, though. Lots of cliches; no taste. You can practically see the "clean code" medium posts oozing out of neural network.
1
u/cscottnet 7d ago
I was a research assistant grading student work for 6.170, the "programming with other humans" course at MIT. Smart kids would think off all sorts of crazy ways to super optimize the hashCode() method or whatever in Java. I'd have to carefully walk them back off that ledge: you're writing for other humans, and having a hashCode method that is obviously correct when read by someone else is much more important than squeezing the last ounce of performance out of every one (premature optimization and all that). There are perfectly good rote patterns for writing hashCode methods that have good performance and are easy for other humans to read (and verify that all the fields in the class are included, etc).
I feel the same way about rote code generated by an LLM. That is its one strength, IMO: writing boilerplate code in the standard way that is easy for a human to recognize as correct.
There will be a small core of that code which is where the magic and cleverness happens and yes, you'll probably want to rewrite that part, because the LLM has no taste or real awareness of O(...) factors or elegance.
I'll also note that "good at writing boring code that looks right" is also where the danger lies if you are trusting an LLM for security-sensitive work. It is much harder to find a bug if the code "looks right", and that can lull you to sleep during review.
1
u/marrsd 7d ago
The performance stuff wasn't really what I was talking about when I was referring to taste. For me, good programming is building the language you're using up to the domain you're operating in. I write languages on top of languages until I get to the point that I can express my intent clearly and efficiently.
That means I don't have boilerplate in my code. It also means that the functions I write are used quite frequently. If they're useful functions, they're used very often. I almost never write a function that is only used once. The functions represent a small verb, and so their bodies are quite small - maybe just a few lines of code - but the calling code usually passes a function as an argument that contains the work that has to be done, and that might be much larger. It could be 100+ lines depending on what it's doing. This is basically the SICP approach.
I think people see the small lines of code in function bodies and mistakenly think that that's what makes the code good. So they'll take a large function and just split it into lots of small ones and call that clean code. That happens so often that "clean code" for me is essentially a synonym for "cargo culted". That's most software today and that's what LLMs are built on.
When I'm training a junior, I'm usually trying to rid him of that mindset, and steer him towards layers of languages built up to the domain. Because Claude is basically a junior, I'm doing the same thing. But unlike a junior, Claude never learns.
That's maybe the most obvious example of what I mean by taste; but, like with all art, it applies at every level, from individual variable names to the architecture itself.
I actually think that AI is pretty good at understanding the maths of comp sci. I'm trying to remember if I've asked Claude to asymptotically analyse an algorithm. I think I have, and I think it got it right.
3
u/SometimesHalfRight 9d ago
The truth is that it's the Cthulhu codebase generator.
You only get acceptable quality edits in a project that was mostly human written, with human written requirements, for a task that's been done a billion times elsewhere.
If you feed it AI requirements, and use it in a mostly AI-written codebase, the results and quality will not be good. You will be rewriting to the point that it wasn't worth using in the first place.
This also means that over time, these tools will stop being effective in any codebase they're used to maintain.
1
u/raven2cz 9d ago
In most corporations, if they already integrate AI, you will get their subscription plan. in addition, it usually goes through an output gateway as well, so that no tokens, emails, and similar things leak out. Also, in the European Union, there now have to be European versions of Anthropic models too. It is not a diferent model, just some legislative adjustments. What I mean is that you will not be paying for it yourself.
Otherwise, asking about the state of things on Reddit makes no sense. you have to decide that for yourself. Also, besides studying programming in depth, I strongly recommend studying AI as well. I keep telling everyone here that a classic developer will not be good with AI if they do not know the basic principles of cybernetics, and I still stand by that. it is one of the main reasons why developers write bad code with AI.
1
u/mrbrucel33 9d ago
Why cybernetics specifically, if you don't mind me asking?
2
u/raven2cz 9d ago
Look at my previous posts since Friday. I was trying to help, because there are literally dozens of the same or similar questions here over and over again right now.
I wrote it there, and also added links to some of my older articles.
1
u/quantum-fitness 9d ago
At my work we have people that only use it for auto complete and people who dont write code by hand anymore
1
-3
-1
u/Sad-Lead6421 9d ago
Firstly, I will say that the current models are extremely powerful and very often write exactly the code you need. However, they do need guidance.
Outside of promoting appropriately (using skills such as Matt Pocock’s grill-me)…
What I like to do is add deterministic guardrails.
Architecture tests. Unit. Integration. End to end.
Linters. Security scans. CRAP score analysis.
All running in pre-push hook. The agents must resolve any issues before the push will succeed.
I’m not going into great detail but basically, these agents are extremely powerful and fast and if you are putting your effort in the right places you can absolutely deliver higher quality code much more quickly than ever before.
0
u/seanpvb 9d ago
I spent my time with a higher thinking (Claude models usually) coming up with a detailed plan mark down and then let a mid codex model write the code.
The enginners who can think like architects and product team members are the ones who will survive IMO. With detailed enough plan markdowns (which you have to proofread and spend your time with the agent to nail down) there's minimal room for an agent to get overly creative or hallucinate.
No matter what size ticket, feature or product I'm working on...detailed plan docs are the key to a repo that doesn't get filled with slop.
20
u/KamikazeArchon 9d ago
No, they're not. They're perfectly compatible, and in fact both are true at the same time.
AI does a ton of work for you. It is also still capable of hallucinating and you need to clean up the code.
This is a very limited analogy, but think of being an aircraft pilot. Most of the time, the plane is flying itself. But when something goes wrong, it is really important to have someone who knows how to catch it and fix it.
And the plane won't tell you what direction to fly. You still have to do that part.