The Hidden Cost of AI-Driven Development 

LLMs as a Daily Programming Tool 

Large language models (LLMs) have firmly entered the daily workflow of modern software developers. 
They promise speed, convenience, and productivity — sometimes even a touch of magic. But once the initial excitement fades, a more uncomfortable question emerges: are we becoming better developers, or just faster reviewers of code we didn’t truly think through? 
I’ve been using LLMs (various ones, but mostly ChatGPT and Claude), both externally and integrated into my IDE (IntelliJ IDEA). 
My overall experience is quite positive when it comes to short, one-line (or few-line) suggestions — they save me some typing time, and I’ve grown somewhat addicted to them- fancy autocomplete.

From Small Suggestions to Larger Code Blocks 

Sometimes, I also use LLMs to generate slightly larger pieces of code (say, a single method), but only when I can describe the inputs, outputs, and invariants very precisely. This often — though not always — yields satisfactory results. 
I’ve also experimented with having LLMs generate more complex code, such as an entire class meant to handle a real business case (a real one, mind you — not some generic example that LLMs already “know” from open GitHub repositories), and I’d like to share some thoughts on that. 

When LLMs Generate Business Logic 

My experience generating business-logic code has generally been disappointing. The first draft is almost always unacceptable, and I usually must go through a long back-and-forth process with the LLM to fix and refine the solution. In the end, when the code is finally decent, my impression is that I could have done it faster, better, and — finally — with more satisfaction by coding it myself. 
One particularly unpleasant surprise was that LLMs can sometimes completely ignore direct instructions. For example, I once asked an LLM to generate code that creates SEPA Direct Debit messages with randomly generated IBANs — and it still created a single method with a hard-coded IBAN value. 
Experiences like these make me wonder how the future of software development will look if, instead of writing code directly, developers prompt LLMs and iteratively correct whatever they produce. 
Will this be faster? More accurate? More (dare I say it?) fun? 
Given the current state of things, I would have to answer a firm „NO” on all three counts. But that’s just my perspective — as valid (or not) as anyone else’s. 

Two Observations from Code Reviews 

I would like, however, to share two points that came to mind when comparing the experience of correcting LLM-generated code versus writing the code from scratch by myself. 
Both points are based on my observations from projects where I did little coding, but a lot of code review — mostly of junior developers’ work. I found correcting LLM-generated code quite like that experience, with one notable difference: junior developers tend to be much more proactive in asking clarification questions, challenging task descriptions, and so on. LLMs, on the other hand, rarely do that — they simply “assume” things most of the time (so: +1 to junior devs vs. LLMs 😊). 

Mind Trap #1: The Assumed Solution Approach 

The first one I call the assumed solution approach mind trap. 
When reviewing junior developers’ code, I often propose many smaller and larger changes, fixes, and improvements to their solutions. Yet, even after applying all of them, the code still doesn’t feel right to me. It seems cumbersome, not very expressive, unnecessarily convoluted — and I can’t quite pinpoint why. 
In such cases, I step back from the code, revisit the requirements with a fresh mind, and then it usually hits me: the entire approach to solving the problem is incorrect or suboptimal. The developer uses the wrong data structures, the wrong type of algorithm, or misses opportunities to apply elegant, existing patterns. 
During the review, I am essentially fixing and patching fundamentally flawed code — without realizing it — because I subconsciously adopt the author’s line of thinking. Only after stepping back from the code can I identify the real issue and address the root cause rather than just the symptoms. 
I’ve noticed that when I write code myself, I tend to be more thoughtful, creative, and open to exploring different approaches. I rarely need to start over from scratch due to an incorrect initial approach. 
So, my conclusion is this: when I spend my time correcting LLM-generated code, I risk frequently patching and refining a fundamentally incorrect solution — simply because I am drawn into the LLM’s way of addressing the problem. 

Mind Trap #2: “I Know It When I Code It” 

The second one I call “I know it when I code it.” 
This one is quite nice, because it often made me look smart (which I’m not — not really) in front of business analysts or product owners. 
When I code a certain business case, I translate business requirements into the nitty-gritty of ifs, thens, and elses (figuratively speaking, of course — translating business logic into clean, manageable code is much more than that). 
While writing business code, I always try to consider all possible execution paths — “what happens on the else side of a given business rule?” Over time, this kind of thinking became a second nature to me. 
Since it is the business logic (and often has very little to do with real logic), I frequently have to go back to the analyst and ask: 
“Hey, what happens when value A is such and B is such, and how does this apply to rule Z?” 
What usually follows is the analyst scratching their head and saying: 
“Wow, I hadn’t thought about that! How did you catch it? That’s smart — nice!” 
Well — it’s not smart. I just didn’t know what to put in my proverbial else clause. 

Why This Matters With LLM-Generated Code 

But what does this have to do with LLMs and a future where developers mostly review and accept AI-generated code? Quite a lot. 
Catching unhandled conditions, missing corner cases, or unaddressed processing paths is much harder when reviewing someone else’s code than when writing your own. 
With LLM-generated code, we run an even greater risk of missing certain business conditions — because, at least for now, LLMs won’t come back to you with a question like, “What should I do in this case?” They’ll just assume whatever seems plausible — and LLMs are notoriously bad at guessing, especially when it comes to messy, often illogical business rules. 

Final Thoughts 

So, there you have it — my five cents about the future of coding with LLMs and its possible pitfalls. 
A small disclaimer: I don’t claim that the above is universally true or applies to everyone. Maybe it’s just how I think and work. If you have a different opinion or experience, I’d be happy to hear it. 
Wrapping up, there’s one more thing: writing your own code from scratch is almost always way, way, way, way more fun than reviewing or fixing someone else’s code — whether it’s written by another developer or by an LLM. 
We really need to think about how we move forward (assuming we’re still given the choice at all). AI-driven development has its merits and can feel almost magical at times (hello, one-line autocomplete!), but what do we trade off in this deal? 
The points above are just the tip of the iceberg. There are far-reaching and profound consequences of relying on AI to do developers’ work. If I had to sum it up in one sentence, I’d say this: 
By using AI, we may be sacrificing long-term goals — skill acquisition and mastery — for dubious short-term productivity gains that often benefit someone else more than us. 
Is that fair trade? 

Comments

Dodaj komentarz Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Komentarz *

Nazwa *

Adres e-mail *

Witryna internetowa

Zapamiętaj moje dane w tej przeglądarce podczas pisania kolejnych komentarzy.