I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written. Slowly your brain just gets trained to mid thinking like an LLM. At least that’s my theory and I think there was some study that showed that interacting with an LLM at the start of a problem significantly narrowed the solution space to something sub optimal

    >  Slowly your brain just gets trained to mid thinking like an LLM

What's interesting to me is how many people have found out with the LLM boom that they don't want to be developers/engineers, they want to be managers, delegating all the work to another entity and checking in occasionally to see how the coding is coming along

But the question is, will this atrophy our ability to write and understand code? Is reviewing enough? Won't we inevitably get lazy and stop reading enough code?

Reading always was a worse way to learn than doing. When we stop doing, we will have to triple our reading (if that's even enough), but will we do that or just trust the agents more and more?

I'm a Software Engineer and I think the author is probably right that many Software Engineers are misguidedly placing too much weight on their ability to read and write code.

The valuable part of Software Engineering isn't PARSING a solution into code and back again, taking into account all the idiosyncrasies and edge casey bugs of any given language chosen for the implementation. Of course that is a discrete and impressive skill, but it's no longer terribly valuable.

The valuable part of Software Engineering is "given this problem, what's an elegant, efficient, testable, scalable, maintainable, observable solution?".

Most of CS is already a solved problem, so even that is mostly a matter of assembling those solved-problem pieces together and choosing the flavor of how it's expressed. (for me, it's pure functions, for others, it might be OOP)

AIs are pretty good at that too, so it seems to me like the Software Engineers role is now to cultivate taste (what, in a perfect world, systems SHOULD look like) and balance it with pragmatism. (what does the system/business/time/resource constraints look like TODAY)

Feels AI-written as well and a recycling of 1000 versions of this point.

People bragging that they "dont touch code" and only "argue" with agents are reinventing the slowest possible IDE.

Obviously the agents are great at producing large chunks of code, but they often make minor and sometimes trivial mistakes which need amending.

Typing something like "in src/auth/session/token_manager.ts the refreshTokenExpiry variable should be refresh_token_expiry. update every reference and make sure nothing else changes" and waiting for the LLM to do its thing takes longer than opening the file and doing the rename yourself.

If you are describing microscopic edits in natural language you are not avoiding coding. You are coding through an extremely verbose, lossy interface with higher latency and lower precision.

EDIT: flagged?

Following the calculator analogy made by another person here and not disrespectful but joking intentended but this sounds kinda:

"I'm done. I'm not going to do a calculation, remember a single formula or theorem anymore. Now I'm just choose the problem that I want to solve and the math branch that I wanna use. I think all these educations stages (decades) was the toll we had to pay and I'm not going to pay anymore. "

Also who can say that is able to consider all weights that each decision involves and be able to surpass AI's broad view!?. I mean ... mythos finding a full chain of processes to make an exploit from a single bug? We can beat that ?! For how long ?

I don't know where it is going to end up but as a newcomer to the field I 'll try to keep learning programming and build a solid base. Focusing less on knowing all little syntax of each language or library and outsourcing all boring and repetitive tasks to AI.

I don't take sides here: I welcome such a wonderful tool but everything has its tradeoffs.

I’m forcing myself to write code.

This idea of reviewing an architecture that you never coded is just a fantasy.

At some point in time, me and a lot of people, thought that using Redux was a great idea until we had to manage verbosity and middlewares. Now we had to deal with the consequences of our decisions and we learned.

I also think this article is just a rage bait

Only a few sentences in and its like reading linkedin... Obviously written using ai with little to no review.

In regards to the title/subject, if you completely stop thinking about code in terms of actual programming comprehension you are setting yourself up for failure. Unless you are a senior with 5+YOE and have an insane list of useful projects completed without using AI, you need to keep learning features of the language and writing code by hand or your skills with atrophy and you will become less effective over time.

> After many years into coding I found out that writing the code was the toll I paid to get those decisions into reality.

I'm happy they are having fun, but these takes are getting worse and worse every day, this is the equivalent of saying, I don't like writing or typing but I love telling stories.

No developer would ever say "I love typing on my split keyboard in vim, it's why I became a developer."

Maybe it's not a bad thing though people are different and this is showing them what they really like, delegating certain things to focus on others. Maybe I should try work with an LLM to act as my architect.

This text is regurgitated on a daily basis. I skimmed through the text and could tell not only that but also that the author has given up on writing altogether.

> I think harder about the real problems

Are you /really/? If an LLM gives you an immediate, coherent answer, there's a risk you accept the framing too quickly instead of doing the harder work of questioning premises, testing alternatives and noticing what might be missing.

With all the people saying that you're going to have problems because the LLM is not good at refactoring or large code bases or OOP, etc. the point may be that if you're working to develop skills, an LLM herder might be a good one. Even if the models are almost, but not quite, good enough yet - they will be.

When looking for a career move you might want to focus on the trajectory more than the current state.

Everybody knows you don't go full AI engineer.

Opposite, I trust less and less the more I use these things. Must write certain things myself, especially types. Sometimes I'll even touch a new file myself (I know, creating files yourself?!) and write some pseudocode in a new file alongside some voice vomit

Also, /only/ verifying is exhausting...

Same here. It’s working well, though only using it for personal projects.

The one project that did give me pause was an S3 Server. Not entirely sure I trust that…

Toying with the idea of sticking a proxy in between that runs the vibe coded S3 in parallel to a classic server and see if the results track

The problem I have is that I find generic code reviews really, really boring. With agents I write less code but read more code that I didn't write myself, which makes the job more boring than it was.

I would rather let AI do the code reviews and focus on test coverage.

Very well written article.

For my biggest codebase I too read every diff. I know the project intimately. I care about it and I’ll pay the cost if it’s wrong.

For smaller greenfield projects it’s up in the air. If it works it works.

This would be fine if LLMs had a dedicated language or a well-tuned abstraction that suited their abilities well. Right now we are trying to fit our square languages into the LLM's round hole.

I’ve been on and off and on the bandwagon on this.

My current verdict. When used properly, and if you actually read the code, pushback when needed and don’t get approval fatigue, and also practice hand coding here and there, you can definitely get immense productivity boosts while not compromising on quality. The issue is blindly accepting AI code, architecture, “are you sure this is prod ready?” “Ok ship it” is not going to end well. Too many times I caught the top SOTA models, 1M context, effort on max, suggest or do terrible things and say it with confidence.

TLDR if you read the code (and understand the architecture), and know when to push back. This can work amazingly well.

Otherwise you will gradually build a Rube Goldberg machine.

I just can't get behind this perspective, perhaps because I am a 'bad prompter', simply due to the lack of capability from current models. I end up rejecting them, asking them to implement again, they spew out tons of crap code instead of a 10 line fix, and on, and on.

Note that I'm not saying the agents are useless. They certainly write a lot of code and sometimes it is good. But I don't think you can get away without touching code yourself simply because at some level it is often the most concise way to get your idea across. I find it best to implement a core set of changes by-hand, and then ask the system to e.g. replicate them to other dependencies. I genuinely don't understand how anyone can work on a system with any complexity, and get the results they actually want, without touching code.

Sounds like they're not touching writing either.

The author appears to have gone full AI blog writer as well.

After a time the codebase feel foreign…

Most of the AI submissions are from people who are here to self-promote their own content and have little to no other participation. It's like this stuff appeals to a different audience than made up this site 5 years ago. Everything and everyone feels so nonsubstantive now.

I’ve found it interesting too.

It’s like I spent 20 years mastering painting in watercolour… nerding out on other painters, canvas options, even the backstory on some guy that makes a specific paint etc.

And I don’t regret any of that. but now I’m just loving creating my art 100x faster.

I thought I loved the craft (and I did) but more, I loved the product.

I don't want to be a manager, but I also don't want to be a technician (for the most part). I want to be an engineer, which means my job is to solve problems. LLMs help me solve problems faster, so I use them.

Sometimes I get the urge to write code by hand and I do it, though. Less frequently, the LLM is inept at solving my problem, so I have to resort to the old fashioned way.

I think it's a symptom of software jobs paying really well for multiple decades. It attracted many people who are in it for the money only, and not the process or result (nothing wrong with that, imo). These are the people who fully embrace the vibe coding model and enjoy managing an AI more than developing anything by hand.

Three quarters of my university class couldn’t code properly, like seriously struggled with basic coding tasks but still made their way through the course.

You then get into the work environment where despite hiring efforts you still find those numbers hold.

I’m not surprised LLM usage has taken off.

You seem to think you can only be an engineer if you are holding the shovel yourself.

Building software consists of many parts. I love each individually. I was always a bit dissatisfied about how they interact and how they block each other. I love puzzle solving, I love debugging, but I kinda hated building software because it depended on those elements and I'm not fond of context switching.

I can love building software now. And I didn't become a manager because people bs never interested me. LLM doesn't feel like a person. It feels way better.

I do not manage LLMs, I manage people.

I always considered myself a builder, a creator. The end result is interesting and it's important for me the end result to be just as I envisioned it.

Typing code isn't exciting. Thinking, planning, finding solutions and driving the LLM to implement the finished product is.

I wonder if people thought something similar when moving from writing low level machine code by hand to high-level languages. No one looks at the actual machine instructions anymore! Will our ability to understand low level instructions atrophy?

Already happening. For many people, coding isn't the only thing they've abandoned. They've also traded science and engineering for LLM punditry. Rather than "focusing on solving problems," as they often claim, they spend their time chasing unscientific debates about which model or magic prompt "performs better." By unscientific, I mean there's nothing measurable, no reproducible methodology, and no way to validate their hypotheses. Or rather, their wild speculations that change every week.

I think I read so much code over the last 15 years, that its not a thing i will lose.

But at least for me, I really read a lot of code, a lot of PRs from others and evaluated them.

Accountability is the key. You are accountable for the work product. You need to do what is necessary to make sure that the product meets standards. How you do it is of secondary importance. If reading code is what is needed to guarantee quality and you stop, that is on you.

Trust creep is the part I worry about too. Today I read every diff.

There is a saying that many countries have offshored building hardware, aka manufacturing. Now they are offshoring software building to AI. Perhaps the silicon valley will grow a rust belt.

I don't think it's necessarily a question of laziness. It's more about velocity.

Your CTO was just shown a demo where a fairly complex piece of software was spat out in MVP form within a few hours. Something that used to take months is now more-or-less completed in a two-week period, including deployment.

The CTO knows that competitors are seeing the exact same thing and are going to try it for themselves. Now your company has to use the LLM because that's going to enable the development speed seen in the demo if they want to stay in business.

There's the iron triangle of engineering: fast, cheap, good. You used to have to pick two. And in reality, you still have to pick two, but a lot of this technology is sold as allowing you to pick all three. It lets you pump out a MVP:

1. fast - it's done in a few days 2. cheaply - you don't have to pay engineers as much or at all 3. it's "good" - it looks good enough for the client to accept it instead of suing you and give you revenue.

The third part is where this breaks down. Like you say, people aren't reviewing this code. It's probably 85%-95% of the way to fulfilling all use cases, but that 5%-15% is the critical part where there's SLA violations and risks to business, property, or people. The thing is, clients have to find that within the first 90 days to have it impact the books for that quarter, and they probably won't. Also, you have lawyers who can drag it out further. If the company really gets screwed by quality problems, well, sell to a competitor or someone and return value to shareholders that way. There's always some way to get cash back.

So we've pushed out code faster, gotten revenue booked, and have a way to not lose money in the short-term, which is ultimately the only term that matters. The goal was never making good code; it was making money as fast as possible. Velocity. LLMs deliver on that.