Cool story bro, but it sounds like you are trying to convince yourself.

See you back here in a month, or so.

We'll see the same for automatic freight movement in the next few years, as just one example.

I haven't touched a line of code in over 6 months, didn't even look at it, but the work I do is faster and higher quality than ever.

Not sure how I feel about it

All tests pass, everything seemed to work. Would not have noticed of I didn't read through the code. Amount of other stupid shit I found is crazy.

To that end, my very first experience with OpenCode let to a `rm -rf /` within minutes, which I caught by chance watching the streaming output. Now I know what I'm doing, every agent is sandboxed, better tooling and models.

for me, if it's stupid, but it works, then it's a coincidence.

In essence, it is writing the code faster (great), but then also writing the code that was often previously never written due to budget/time limitations (comprehensive testing/validation).

So, how do you know the code is the highest quality ever? Because we have test result data that PROVES it to be the case. It isn't "trust but verify" it is "Don't trust. Verify."

It said verbatim: "Don't trust. Verify."

pgrust thought this too, but then another human discovered claude had hardcoded benchmark query plans.

Now pgrust has a "test" to make sure the Ai doesn't do this again (unless it decides this test is bad for the current goal)

https://github.com/malisper/pgrust/blob/38634b408dea373f3944...

Real verification seems beyond transformer capabilities.

Single data point, my Sentry notifications across more than a half dozen client projects when from 2-4 a month to basically 0. That's while shipping 20x _more_ code.

I used to work in Web agency for sizeable brands and not a single site I built lasted over a year because the companies changed concept regularly. The next agency would come in and tell them it was built wrong and couldn't be reused etc etc. We did the same, it was irrelevant how it was built and we didn't even look. This is the nature of most code. The problem is that very few people will ever be in a position to be writing verifiable important code, but every developer likes to cosplay that they are.

Most code is ultimately an, annoyance businesses need to meet a goal that will always be a cost. It's often worth treating it as such and writing things that are easy to spin up and teardown.

The people most vexed by AI dev appear to be the ones who think writing code is a pinnacle role, it's not even though over our lives the salaries would sometime suggest otherwise. That's ultimately going to be a short term blip in the landscape and most code will be one seen as the cost it is.

Yet I find myself using AI coding agents more and more. In this day and age, your choice is to either use them, or be stomped into the ground by programmers who do.

AI still can't write code at my level of quality, but it can do so at adequate quality now; and sadly, that is "good enough" for the real world.

FIFY.

I've found experienced devs with AI is a force multiplier, but AI in the hands of juniors however is my hovercraft is full of eels.

I'd say that 90% of them are very excited about using LLMs for coding. They have nothing to prove to anyone and can easily steer AI to reach "godly" productivity (please note these guys were 10x programmers already).

I also know some weak programmers and most of them tend to be critical of AI and want to get rid of it.

Lastly, a couple of people I know are against AI for moral/ideological reasons without denying it can bring productivity increases.

This is purely anecdotal but I'm starting to notice this pattern everywhere I look.

Sure, LLM's are unreliable. So are juniors.

Sure, LLM's code quality is not always great. Well, so is the juniors code.

The benefit of LLM's is that they can work super fast and have a vast amount of knowledge. The benefit of juniors is that they actually learn from their mistakes and get better over time. LLM's stay at intern/junior level, even with the correct context.

So for me, I see each LLM session as a new intern coming in. You hand them the right context, give them the correct instruction, and off they go. Then they come back, and you will have to judge how detailed you want to review what they produced. Or in other words, can you get away with some bad code? And for the next session, it's a new intern that starts from 0.

But it is also highly dependent on the project you are working on. If it's a big complex codebase, LLM's will struggle, and they can only do simple tasks (however, they can help with testing a lot!)

So the teachable thing is unfortunately experience:

- Know where quality matters, and where it doesn't

- Know what kind of mistakes could be made and should be checked for

- Know which things can be duck-taped together, because they live at the edge, and which things need a proper foundation, because the rest builts on it.

So in the end, I think it all comes down to making the right trade-offs and the right decisions (which LLM's are terrible at, by the way). And unfortunately that is gained by the slow process of experience.

I think it's very tough for junior developers right now, because they either go fast by letting the LLM's do the work, but then they learn nothing. Or they go slow by asking the LLM's what's going on, and then do learn.

A senior developer never understood the full code-base, and never reviewed every line of code. That's just impossible. And now every developer needs to be a senior developer that is able to steer these new "interns".

And just like with juniors and interns, you have to put a lot of effort into it, and it's not always clear in the end if you gained or lost something :D.

To comment on the post you linked:

I agree that people can be thought. But on the other hand, I also had juniors that reached their limit pretty fast, which can also be frustrating. The best way to "teach" LLM's is the context, but I agree it has limits and is not really teaching anything, just steering them in the right direction every time (like a checklist).

Your comment basically states that running LLM's is a gamble, but according to my experience, most of the time it delivers what I ask. Maybe in a different way that how I would do it, but I want results, and am not interested in micro-managing.

Are you working on a project that requires high quality code? Or is it your preference to work in such a codebase? For me, I was always ok with "good enough" code. And sometimes "good enough" needs to be good, and other times you can get away with some really bad code.

i meant "working with" as i explained in the linked comment. the feedback and response i get from juniors is very different. and yes, sure every junior dev is different from the others, but i simply enjoy working with people and i can't stand working with machines in the same way.

what bothers me about LLMs is that they are not deterministic. that just drives me nuts. i do enjoy learning the ins and outs of a language or compiler to figure out how to write the code to get the results i need. but LLMs just don't work like that. the same instruction that produced good working code today could produce nonsense tomorrow.

this is not about quality. this is about trust. i can't trust LLMs and that makes it very uncomfortable for me to work with them.

That's because you try to look at LLM's as tools, and not as an intern.

LLM's are not deterministic, they can make mistakes, etc. You refuse to work with LLM's like you would work with interns, and then somehow you're frustrated that they don't work like a compiler?

Maybe shifting your expectations would solve a lot of your frustrations.

Look, every developer writes bugs. Me, you, everyone. There is no perfect developer that can churn out 100% quality code. That means you always have to take this into account. You are correct that I don't take compiler bugs into account, because they are very rare. But when working with LLM's, just take into account that it can go wrong, just like any human developer.

Basically, you have very fast and cheap interns at your disposal, with a huge amount of knowledge. Can you trust an intern? Of course not!

There's nothing wrong with that. Many of us do (or did) like programming and the problem-solving itch it scratched for us. But getting work done for pay is more than what we like. If an LLM can reliably solve a problem for me in a day that would have taken a project, a team of several people, and close to a month of work to build out manually, then I go with the tool that works.

And that "if" is the reality I live in. About a decade ago, I wrote a program to do analysis of config files for a product our team uses. It took me weeks of side-work to implement the idea of passing boolean python functions as checks for the configuration. Such an elegant way of creating new checks on our system! It was company work, and when I left to a new place, I didn't have that code, just the idea. Fast forward five years and I want to write the same thing at a new place. I asked an LLM to do the same task, and it wrote exactly my solution immediately. It just worked. It shocked me. In the last few months, I've had it write analysis tools against this product that would have taken me days or weeks. I am admittedly not a comp-sci level programmer.

There is no denying that LLMs are powerful coding tools. That can be true at the same time that we lament the end of manual-coding-for-pay, the death of programming education as we know it, and the worries about employment and society.

No, but when a junior puts up a PR I do. They aren’t trustworthy enough yet.

One of the biggest parts of being senior is ownership of your code and knowing you’re putting your trustworthiness behind every PR you make. If you’re making bad PRs, you can’t say it’s Claude’s fault because you didn’t think a certain area was worth reviewing.

> That's just impossible.

Somewhat, but this is directionally bad advice. There’s huge payoffs for taking time to thoroughly understand areas you’re working in. It greatly amplifies your ability to prompt and overall execute in a codebase.

That's why I say: every session is a new intern. That's how I look at it.

> The claim is that if I'm any good, I should know how to squeeze consistent quality results from LLMs.

Claude Opus 5.5 can write decent code, better than most juniors I came across, and definitely codes faster than me.

But is that quality high enough for your standards? It sounds like no. So then the next question is, does your project really require your high standards?

Testing. It's all about having unit tests, and known outcomes that the LLM can check against every time it makes changes. For my work, that is good enough. For safety-critical systems I would demand more rigor in the testing and the human review and creation of tests.

I steer the implementation broadly by telling the model what libraries to use, what to pay attention to, where are the common source of bugs, gotchas, possible performance issues, security concerns, etc.

Let's say I want to add a good search functionality to my website, I wouldn't just say implement search, good way. I would say to use TypeSense, have that as a separate service, to benchmark performance on various queries, make use of caching, test cold starts, make sure autocomplete has good UI/UX on both desktop and mobile, to avoid layout shifting, display clear progress while search is loading, etc.

I don't care much how it implements them, as long as the result works as expected. Yes, there might be small bugs, but that happens when coding and testing manually too, and they will simply be fixed over time.

Competitive programming is rarely about writing code, it's mostly about knowing which data structure, libraries and ideas to use for each problem. When two competitive programmers talk, and talk about the solution, the solutions to even the hardest problems can often be described in just a few keywords. One would say "dynamic programming + binary search", and that's enough for the other guy to know exactly what the solution is and how to implement it. Same with LLMs, if you just give them a problem and ask them to solve it, they will likely do a shitty job, but once you just give one or two hints to put them on the right path, the solution is then almost perfect and as good as I would have implemented it, or even better, because when I implement it I might be lazy and cut corners to write code faster, but the LLM can organize and test code at such speed that it comes at basically no cost.

The first months of using AI were tough, because suddenly I felt like I lost control over my creations, and something else was changing them in unkown ways, but now I learned how to control data and use that to my advantage.

Is like you were manually planting flowers, each one carefully placed, but now you got a tractor that plants 10000 flowers per hour, in a slightly worse way, but then you learn how to set-up the tractor so the spacing is right, that they are aligned and planted at the right depth, etc. Then you realize this opens a whole new world, now you can not only plant a few plants, but make fields of flowers, beautiful art that would have taken an impossible amount of time before is now possible.

The only danger is losing grasp of internal components of the system, but maybe there'll be a "management" layer eventually for humans.

I don't know what the future of programming will look like but I don't see us rolling back the clock to 2021..

A good human code review takes into account the broader business context and the structure of the codebase. It finds instances of poor design or readability. It suggests patterns or existing utilities that the author didn’t make use of, and points out antipatterns.

LLM reviews are a great first line of defense against certain classes of bugs. But I consistently find major issues in code review that the review bots miss — and some that they couldn’t have caught under any circumstances.

Just last week: 800 lines of unnecessary (and clearly LLM-written) code with high cyclomatic complexity that could be easily replaced by 50 lines of mostly declarative code by using existing patterns and utilities; several missed opportunities for converting incoming data to native types up front upon receipt and enforce stricter typing, rather than passing around things like dates or UUIDs (or even basic numeric types) as strings and trying to parse them over and over; and a case where the author had misunderstood which of two possible sources certain data should be derived from, resulting in subtly incorrect data being saved to the system of record.

A phrase I've been toying with is eyes free vs hands free coding.

The distinction is important. While I too hardly write code these days, I do continue to make smaller changes and look at what's being done. This is as opposed to the group who has decided vibing mega commits is a good idea.

High quality code doesn't always lead to a high quality product.

And bad code doesn't always lead to a bad product.

And performance is easy to test automatically by having performance benchmarks automatically ran on deployment.

It seems most people are bad at evaluating the quality of their work, especially if they purchased it from Anthropic.

It could have also been a "use AI to test our product more", but I don't see that anywhere.

I hope you agree LLM's can actually help with quality, if used for that purpose?

And it's not just restricted to software. Everything I care about is getting worse.

Dribbling about how it could theoretically be better doesn't help undo the damage.

I do think/hope that as LLMs improve, that improved quality would come by default, or that people would still compete in quality instead of quantity, but this is also the consumer's job to not accept shit quality products.

It doesn't happen. We have very good functional and non-functional testing and the coding agents are able to iteratively add functionality correct features and improve performance.

I don't understand what other people are doing different to get worse results. We cannot ever go back to humans writing this code, because our competitors will eat our lunch if we do.

Well that doesn't make sense if you are writing code that is going to be used on critical infrastructure.

Imagine a disaster were to happen and you said to the auditors that "I don't know what I am doing nor did I look at the code" and you cost the company tens of millions of dollars.

Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?

Don't you see the contraction you just did there?

Wonder if he tells his boss to "I pushed critical code to production without even taking a look at it" or is it just for show on HN

If there is a bug, it will be fixed quickly anyway, so only a few users might ever see it, or see it only for a brief time.

Even when manually coding, projects still have issues and bugs, I don't think much changes in that aspect now, if anything, there are fewer bugs now in most high quality apps than before, due to AI catching more issues. See all the vulnerabilities found in old core code and libraries nowadays, that humans didn't find.

>>Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?

>>Don't you see the contraction you just did there?

I wouldn't trust anyone who refuse to use LLMs for programming. Their code is worse, they test it less and it takes longer to write. For me "no LLMs" attitude is a sign of incompetence. Good for hobbyist trying to keep their brain active but that's about it.

That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.

So does that mean you should never look at its code?

If a fault in the software occurs even after testing and there was an investigation, will you admit in the postmortem report that you did not look at the code at all and blame the agent for the error?

> I wouldn't trust anyone who refuse to use LLMs for programming.

Did I say I refuse to use LLMs for programming? I am telling you to check the agent's work.

I would not trust anyone who DOES NOT check the changes of an agent's code when using them for programming in highly regulated industries or in critical systems. For most companies in the Fortune 500, it is irresponsible to not check.

> That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.

No-one argued against that and it does not mean that you do not check with the agent at all even if the agent believes that they "fixed it".

We have more freedom than ever to build whatever we dream of, you still need a dreamer. And that’s why the profession of coding isn’t going away, you still need people to turn ideas into reality. I find AI soulless, it’s great at mimicking but is incapable of coming up with an original idea that wasn’t yours regurgitated.

This thread is full of 100x supercharged programmers, so why is it that I can't name a single useful feature added in the last 5 years in e.g. macOS, Windows, Firefox, Chrome, YouTube, VS Code, YouTube, Slack, Photoshop, Word or any of the other 5 programs currently on my taskbar?

What I have seen is that, with LLMs, an entire class of process brokenness disappeared in the in-house codebase. Before, there were many trivial tickets that, in the end, required a 5-line bugfix sitting in the queue for months. Now, such tickets are resolved instantly, and the backlog is shrinking.

Personally, I did see a lot of entry-level products having a lot higher quality and better UX. At the same time, most companies go for fast iterations and are profit-focused, do product quality is not really a target for many.

None of this capital has ever been earmarked to build better consumer utilities.

- Try to prove the concept early on. When you start spinning in circles, then it might be time for a different approach

- I’ve had a lot of success with projects that have not started out as LLM codebases. And adding features one by one and testing really carefully by hand

- UI generated by LLMs are overly verbose. The key lies in the iteration. What you can cut, move or approach differently. But you have to have taste.

It's the language I hate to write the most.

People need to reflect and find themselves instead of relying to their own automaticity to get them through life, stop and smell the flowers a little.

When it comes to generative art, yes, that's a much more significant issue.

Now I get the same feeling out of building an entire component library in an afternoon, running my code in a Nintendo Wii with twenty minutes of effort, hacking an OEM LED display, my keyboard firmware, or building projects that would take a team of twenty engineers in the past. We just got a power upgrade.

in the end it's just sad.

The point though, is that I don’t feel “sad” about not having controlled the temperature and time myself. It’s a tool.

Wait, no, a rice cooker doesn't seem to fit.

Working in a commercial kitchen however is a different matter. But there again, nobody is forcing you to use LLMs. Cook however you want.

In the sense that I can quit my job at any time, sure. But my employer certainly requires LLM use, and even if I found another position that doesn't, I have no reason to believe that will last.

I am not denying the lack of freedom when working for someone else, or that it sucks when they impose rules on you. But that’s always been the way it goes.

The comment I replied to was about home projects and home cooking. Nothing there has to change.

setting aside the craft and mastery or satisfaction in goal accomplishment: to me the main thing is a sense of actualization, of the codebase or thing you were working on being better because you were there.

have you ever put up a shelf? did it feel good after?

Programming never has had one right way to accomplish a task, and that is disappearing with agents. Why would pick Ruby for a project because it’s nice for the programmer, when the agent is the one coding? In fact, Why would anyone ask an LLM to write a new program in almost anything other than JavaScript and Rust?

This is not an issue.

Nobody cares about typing instructions. If someone can click instructions or voice them, it all the same.

Programming is about finding the right instructions. Not about typing.

We will soon trade that complexity barrier over to the agents and we won’t know how it is done, because the agents always did it for us.

Everyone can run a 5 minute mile now without training. I used to like training to be able to do that, but now that it's accepted everyone can do it for free (and people don't care if you did it the hard way) the joy has been sucked out of it a bit.

If you wish to make software engineering your job then it stops being a game where we ban things simply because they provide an “unfair” advantage.

If you wish to play at programming “the way it used to be done” then by all means go ahead. But mixing methapors between sports and work is not helpful.

To me, the effort part only feels pointless if you want to accept LLM-derived code as comparable. Any marathon run is pointless, you go in a loop and we have cars. The point is to do the run yourself unaided.

That a computer can play a virtual instrument better than me (and continuously better than anyone) has little bearing on whether or not I continue practicing on my piano.

But software engineer, as a job rather than a hobby, has always been about results. Hence my original point.

Hence my confusion. I am not perusing my hobbies for “the world at large” I’m perusing them for myself; being able to drive 26 miles makes no difference to me nor to the others who wish to run it.

People who continue to do the hobby without LLMs will still get unique skills, like woodworkers who don’t use power tools.

I understand that this is a loss for those who were pursuing programming as a hobby only as long as it gave them a unique skill and made them feel superior to others. However, for better or worse, I can’t bring myself to care about that.

Hobby programming without LLMs and you gain unique skills (you can do the work without power tools).

Hobby program with LLMs, you gain unique skills again (you learn how to properly use these models and get to quickly iterate on your design skills). Regardless of what the big labs are saying, there is still a lot of skill involved in creating with them; if only because they don’t read minds so you have the get good at describing your taste and requirements.

What will be the purpose of a graphic designer when Google can generate you a logo, endless combinations. Devastating to me.

I've seen it first hand, it's pretty mind blowing and rather scary. You can't not feel that way after some time. The hype disappears.

This is pretty spot on. But it's important to note that the resulting code, is still often significantly better than what those developers used to produce. Especially under tight deadlines and pressure to complete CRUD like interfaces. We simply can't afford spending a whole day tweaking a sortable table on the web anymore.

But then again, LLMs do offer benefits that are impossible not to want to harness.

- Why should I even start vibing up my desired tools and projects when I can just wait it out so a better clanker emerges 6 months down the line?

- What guarantee is there that Rust is the best programming language for vibe coding when the models could improve to directly output assembly? What incentive do you have in vibing up something?

An agentic workflow lets me literally sit on my hands (or play Star Wars: Galactic Racer, or play my musical instrument, or work on my CAD hobby, etc) while the agent machine does my work for me.

The best part is that this is how my employer wants me to work. They literally want me to be lazy. Works for me!

Where is my incentive structure to not use AI?

[1] coding manually brings me a non-zero amount of joy and mental satisfaction and stimulation but I am still trading time for money.

Generally, automation does not make us work less because the expectations rise equivalently.

2. I’m paid to be a warm body who is available. That’s I am paid salaried instead of hourly.

3. I don’t really care if this situation changes in the future. If AI takes my job there’s nothing I can personally do to stop that from happening. I’m just saving my money and planning to retire as early as possible. I view work as a necessary evil.

The environmental aspects can be solved.

Quality is a measure of the person driving the process, models can write code better than the average engineer.

The impact on learning, seniority etc is the one big unknown - but I believe can/will also be solved.

If you're not interested in "average", volume isn't going to make up for quality. I'm certainly not perfectly satisfied with LLM output quality, but even the best programmer in the world will undeniably be helped by LLM tooling, even if only for having it write tests, benchmarks, run experiments, create research summaries, and so on.

I don't think that matters. What matters is that they ARE solved. Which is not the case today.

I’m sure the people dying to air pollution and high temperatures feel good knowing that it can hypothetically be solved.

I work for a FAANG, we have unlimited AI credits to be used on any model we want, with basically any tooling we want.

My whole team massively uses AI, I barely do. I use not even 10% of the tokens that they do. Yet I have not only the highest rate of PRs raised, but also the highest rate of PRs I reviewed.

AI is all about fake productivity. You feel productive while you're achieving the same, if not less.

Long term it's pretty obvious that people heavily using AI will become a lot less productive, if not simply unable to work as software engineers. My colleagues are already scared.

I understand though, it's hard to feel your skills atrophy in real time while at the same time realizing that the data shows your productivity has in fact not increased at all.

Which seems like the right way to use tools?

1. OP probably works on a team that does not ship much. It's a dead end team on maintenance mode.

2. OPs colleagues are not good engineers or don't care about work or improving them in general.

3. OP is lying.

4. OP is delusional and is actually left behind. And is measuring wrong metrics.

Which one did I get correct and wrong? Does you manager also agree you are the most productive engineer in team?

My colleagues are all also FAANG software engineers.

> Does you manager also agree you are the most productive engineer in team?

It would seem so.

Additionally, in my mid-year performance review a couple of months ago he specifically mentioned how every metric also looks great.

It seems the only option left is that I'm lying.

In reality, your knee jerk reaction was to be scared and deny that what you have taken as productivity increase was just an illusion, and that you've actively been losing your skills for literally nothing.

And all the engineers in my team are full on AI. Even the best ones.

For me I see the opposite of what you are saying.

I don't particularly see much value in handwriting the code itself after the tech specs and all is finalized.

So me personally I am liking how the industry is going.

Never really enjoyed writing thousands of lines of code to be honest.

Though always like programming when I was young.

Again, you are conflating appearance of productivity, with actual productivity.

Are you shipping more features in your side projects because AI is allowing you to ship more features faster (let's assume at the same level of quality), or are you investing more time in shipping features in your side projects, because you FEEL like AI is a productivity booster and therefore you get more out of your time, even if it's not real?

Are projects at work estimated to be a lower cost because of AI productivity increases, or because estimates were too high previously, and you could always deliver at that speed?

For the second point, I'd add that any launch announcement I see at work touting AI gains of 50-75-90% NEVER hold to any sort of scrutiny, so it's also simply, lies? Employees currently are desperate to look good in the eyes of the CEOs pushing for higher AI adoption.

You're entitled to feeling more productive, I'm just saying you likely aren't, or not by very much. Add to that the fact that you didn't like writing code to begin with, it's easy to fall into this sort of falacy.

To be clear, I do use AI, and I do see some productivity gains, but they're not in writing production code (issue management, automation that was too expensive before, generation of code or artifacts that I don't actually care much about, etc.).

It's impossible. You are lying.

If you developed software, you should know "the tech specs and all" is never finalized, the requirements are always changed, when you are developing it, the specs or details are changed or improved.

Pretty much defining tech spec and getting it implemented by breaking through tickets are more than enough.

There might be bugs. Wbut we catch it through testing and get it merged while building.

A good software engineer has always been able to write a ton of code all by themselves in a short period of time without any oversight. There's nothing romantic or intelligent about that. It's just reckless.

Teamwork is more important than ever, and yes of course that slows things down. That's the point. The decision making is the slowest part. 5 hours of meetings today can completely change the trajectory of the next 5 years. This isn't a revelation for anyone but the most naive.

We now have people commonly running multiple concurrent programming tasks, while automatically and interactively testing them, reviewing them, and validating them. They're then handed for human review, where little is found because the quality regime is now set so high. We're talking weeks of development + testing/validating time brought down into the realm of days.

So this is pure "my horse & cart are just as good as the motorcar"-levels of argument. If I bury my head in the sand long enough, and deep enough, this will all just blow over, and we'll go back to doing stuff significantly slower/worse any day now...

The quality of stuff I am shipping today is the highest it has ever been, and tested/validated significantly more comprehensively. Why? Because time/resources was the limitation, not willingness or skill. I always wanted to test for every single possible edge case/scenario, but it wasn't in the time-budget (and diminish returns). Now I don't need to make that trade-off.

To not use an LLM at all for software engineering? That’s just a joke. You can also deliver food with a bicycle. Good luck making a living doing that.

At work I still read through every line in the diff (unless it's a personal util/non-production facing/critical etc). Even with this I feel less 'in touch' with my work code than I do with my home code.

LLMs are tools like motor vehicles. They allow you to get somewhere, quickly but brutishly. You won't be able to appreciate the beautiful scenery much, as it rushes by. You're going to have to compensate for the exercise you would have gotten, had you walked, or it's going to be unhealthy. It's undeniably bad for the environment (electric or not) and has other negative externalities. The politics of many of the countries supplying most motor vehicle fuel to the world are beyond fascist by modern leftist standards. Yet, we depend on them, we have constructed a lot of the infrastructure we need to live around their existence, and even if every city became walkable over night, the last mile for most transport would be covered by some motor vehicle. There are many "what ifs" surrounding motor vehicles where the answer boils down to: "Well, then we're fucked". But we're not fucked today, and so on it goes.

Of course you can try not to partake in motor vehicles, and insofar as you don't make a moral grandstand about it, that's totally fine with me. But the rest of the world is in it for the ride. The first cars weren't very good either.

You can still manually type code, it can be a great hobby, but it is unlikely that someone will pay you a full time salary for doing it

In the early 20th century, Frederick Winslow Taylor came up with scientific management, a set of principles for determining the most efficient way to perform work tasks using systematic observation and measurement rather than tradition and "rule of thumb". The problem Taylor was trying to solve was that of soldiering, or as we call it more euphemistically today, "quiet quitting"—doing the bare minimum of work necessary to keep your job. If the best way of performing a particular task were known to management, soldiering workers could be held to account for not performing as much work as they could, effectively stealing from their employers. So since that time, business has had a vested interest in understanding the best way to perform all business tasks and making that the institutional standard.

You might think "But that doesn't apply to us in software engineering/IT. We use our smarts to solve problems." You couldn't be more wrong. Milt Bryce's insight was that the exact same management principles that applied to the manufacturing and construction industries applied to information systems as well, and treating a software shop like an industrial factory would save the company time, money, and effort.

Today, it is known that, when properly prompted, LLMs write better code than humans, much faster than humans can, and test it much more thoroughly as well. So yes, your employer absolutely cares whether you use an LLM or not. What rational person wouldn't, especially if they don't want to waste time or money? Furthermore, now that LLM use has been standardized as best practice because they are vastly more efficient, if you refuse to use LLMs on the job, you are stealing from your employer. Your boss has every right to fire you, and they'd be right to do so.

Funniest shit I read all day.

> If you refuse to use LLMs on the job, you are stealing from your employer. Your boss has every right to fire you, and they'd be right to do so.

So now it's our chance to be abused to improve the bottom line.

Although one of Taylor's quotes has special resonance in the AI era: "In the past the man has been first; in the future the system must come first."

Programming was a job where the man has long been first. That era is coming to a close.

Also, Robert Owen had Frederick Taylor beat on the 8 hour workday front by like a century. Maybe Taylorism was, in practice, one of the last straws. Or maybe it was Taylor's scientific support that helped convince the legislature an 8 hour workday was needed. Personally, I have my interpretation based on the evidence, and I don't see it boding well for software engineering as a profession in our immediate future.

The only arguments against AI itself are about cognitive decline and “I like coding” While there is nothing wrong with those preferences, it’s akin to saying “I like building furniture with only hand tools, and not doing it by hand leads to decline in your ability.”

We’re in this place because the boosters ran around threatening and belittling skeptics, raving about (checks notes) wiping out humanity (?). Now the public hates AI and the easiest way to win votes is to be anti datacenter.

We don’t need to do this. We can just treat it like regular software and hold it to the same standard of efficiency and quality as anything else.

The post sounds more like a programmer at heart, and that's totally fine.

To me, being an entrepreneur is more about building products, solving problems, and creating business value. LLMs help to deliver bug fixes, new features, and entirely new products faster.

There is no going back to writing code the old way. I don't see that happening in the industry, ever.

The grievances listed here are 100% real, but not fundamental - with some practice you can prompt an LLM to great effect without it taking the reins from you. If you let it write the code, it does become a management job more than an engineering job. That said, I do believe that there must be a way to structure your workflow such that the LLM becomes your read-only pair programmer/rubber duck while you yourself get to do the fun parts of coding.

I would disagree that "the grievances" are not fundemantel. The _profession_ of the programmer is about to cease to exist, much like the human computer. Sure, you can still compute without a computer and perhaps enjoy it, but you will not find anyone to pay you to do it. Whatever you think "babysitting an LLM" is, it's not programming, even if presumably programmers are fairly well suited for it.

That is, unless you treat the agents as if they were people and thus the true engineers, of course. I think that's a fascinating philosophical topic despite ultimately disagreeing, but to say the least it's incredibly controversial to even consider the personhood of agents, much less endorse it.

This is all moot anyway, so apologies if I'm rude or overly dismissive of your comment that I agree with the general thrust of. No point starting fights over deck chairs...

The title "software engineer" is just a bullshit name that sounds more important - for the same task. Very few programmers work like real-world engineers. There is no licensure or liablity, there is no legal code. If a real-world engineer makes a mistake in a design that causes structural failure, they're on the hook.

We sure added lots of processes and practices to make it seem like we're more diligent about what we're doing, but none of these are empirically verified (or verifiable in practical terms).

I disagree. It remains an engineering job. Us software engineers got confused about what the engineering part always was. The engineering part of chemical engineering isn’t cutting piping, welding shit, or rolling metal. The engineering in civil engineering isn’t pouring the concrete, or grading the site.

Yet somehow it’s a prevailing idea that the engineering part of software engineering was typing on keys and naming variables.

We took advantage of the typing time to also think, and in many ways typing code served a similar purpose to drafting your thoughts on paper. With an LLM you still think a lot and those thoughts turn into specs, prompts, plans, or whatever workflow you prefer.

You are conflating designing the system and instantiating it with code. This is exactly what I’m talking about.

Typing characters absolutely is cutting pipe and pouring concrete. It is not where the engineer was or is.

> I know Machine Learning

Knowing a thing and knowing how to use the think well are not the same.

> Cognitive impact

This is probably the greatest concern and it requires vigilance or routines to counter it.

> The quality of the output is not that great > Maintainability is a nightmare

Neither are my first prototypes. Refactor them using AIs.

> I like writing code

I like designing a system before coding it and the AIs are pretty good idea bouncing partners.

LLMs are absolutely capable of writing beautiful code, the important step here is telling it what beautiful is. You need to have an opinion and describe it articulately to an LLM. You need to be a Rick Rubin of code; he plays no instruments, can’t read sheet music, but his opinions are what matter.

I have been trying to perfect a workflow where the human is engaged and doing what they love and the LLM is kept away from what it’s bad at. This is essentially a pair programming setup where the human is in control but will pass the conch to the LLM from time to time when they don’t wish to type something, the rest of the time you should be asking it questions.

We will need to start thinking about our human engagement as a resource that is expended on a dial. I have a fixed amount per day and it doesn’t need to be evenly distributed, but it needs to be dense in areas that “matter”. What matters is subjective and where your Rick Rubin skills come in. The metric of quality is the difference in the distribution you have decided and a “true” distribution of what matters. So yes, maybe I don’t need to fully understand all the code for some control panel I’ve built or a blob of test code the LLM spit out, but I absolutely need to know and have an opinion on how the core machinery of the codebase works.

“You’re not breaking up with me. I’m breaking up with you.”

"Your job was never making art, it has always been to give someone a visual product."

The artist retorts.

"That may be true, but it is I who made the art, and my life shaped the process, and thus, the final product. I was hired specifically because my lived experience appeals to others."

The AI supporter laughs.

"But that's not what you're paid to do."

I got a quick prototype of a rabbet box generator:

https://studio.flet.dev/run/bicQWc3Aul/

but the geometry was all wrong and ultimately required that I describe the calculation of the position and dimensions of each element in exhaustive detail in order to get a usable DXF (the wireframe preview is still all messed up) which eventually worked to make a box:

https://community.carbide3d.com/uploads/default/original/3X/...

I was also drawing the design up in an interactive CAD/CAM program, and modeling it in BlockSCAD/OpenSCAD (and dropping into BelfrySCAD to figure out rotation):

https://www.blockscad3d.com/community/projects/2169316

(and speaking of rotation, at this time, the sliding and hinged lid options open on opposite sides in the preview...)

Since then, I've made a very simple generator which simple does a box decorated with lines, arcs, and circles on each side --- my intention is to dis-assemble that and use it to write a Domain Specific Language implementation for creating such designs and previewing them and writing out DXFs --- which is a long-winded way of saying I've been finding this tooling frustrating to use, but potentially useful to make rough drafts of programming templates which can then be used as a starting point for more traditional coding.

Eventually all of this will go into:

https://github.com/WillAdams/gcodepreview

I wholeheartedly believe that if the general trend in SWE goes without hiring new grads/self-taught people (who can still use AI-assistance in their work), we're gonna be seeing huge outsourcing to AIaaS companies and generally become tremendously dependent on them when existing pool of seasoned programmers goes extinct and the work doesn't intrigue training new people.

Although there is cheap, open source models running locally or available at scale on reasonable prices without compromising programmer integrity.

The brittle slop happens when you tack feature on top of feature because it’s fast and easy now.

The higher quality stuff happens when you dive into the details of the current implementation (looking at code, with agent, or not) and try to make the current thing work better.

IMO there will be outsized competitive advantage to the latter

I have a hard time believing this. The businesses employing us and the businesses competing with them will view handwritten code as an evasion of financial responsibility. That does not mean inevitability is positive or worth welcoming with open arms. But it is so inevitable at this point.

If this were true, then we wouldn't be seeing the correction to reasonable limits. While I generally agree not using LLMs is irresponsible and not viable any more, I have real doubts transformers will live up to the hype projections and the end of the profession. On the other side (with too much Ai coding), there are market penalties from the users (because of Ai mistakes).

If someone uses Resharper to make some ugly code pretty, fine, I don't mind - as long as they can understand and explain the result. My issue I'm running into daily which drives me nuts is stopping people in their PR's and asking "Why did you do it this way? This seems like an odd approach" and get "Oh I dunno, Claude wrote it". Then what the hell are you checking it in for?

Between SO, Resharper + Fancy IDE tools, and the mountain of plug-and-play cloud services we have, I think the era of 'writing everything yourself' was already dwindling. But at least if someone chose one framework or library or SO post over another, they could explain why they chose it later on. Some sort of domain knowledge was being built up and transferred between devs over time (and I'm not talking about documentation). What I see more and more is systems being checked into production where the 'author' doesn't fully understand what it's doing, then it breaks in a way they don't expect, and then I see a team of clowns all with their claude terminals open desperately typing "WHAT DOES THIS ERROR MEAN" because nobody understands why it was built that way in the first place.

Fine get LLMS to help write your code, but do your job and handle the problem solving part. What are you being paid for otherwise?

The quibble I would make is with the “code is not that good” and the implication that they are so much better at coding while those who have adopted AI are “mediocre”. It’s certainly possible this is right. I would be the first to call myself a middling programmer. I am still waiting to be inducted into the Real Developer (TM) society. (Is it a card? Or does someone teach you a handshake?). But my question is, why, if you’re an ace programmer, can you not get good results out of an LLM? These things are endlessly configurable. They are begging to be tested and, dare I say, engineered to your system and way of doing things. So, why are your results still bad?

The author's not wrong that left completely to their own devices, and especially if your working on something that's not well represented in their training data, LLMs will make a mess of things. But a Real Programmer (TM) isn't doing that. (Or so I assume. like I said, I haven't gotten the pin. Or is it a medal? A certificate perhaps?).

Rest assured, though, that the sentiment grows ever stronger.

I can’t really point to any evidence of this because the wodget people have stopped posting about it and every month the cost of widgets keeps going down while they simultaneously get better and there’s so much capital and talent being thrown at widgets that it’s impossible to think a wholesale reversal could even be possible. Would you tell me that, “trust me, bro” is not really an argument?

All these things can be true simultaneously:

* AI has wholly taken over the corporate world

* Programmers can now generate massive amounts of code

* This massive productivity boost is, oddly enough, not reflected in consumer products at all

* LLM use hampers software development at its current level of complexity (because AI is incapable of independent abstraction and simplification)

* Programmers are deskilling en masse and turning into managers (without admitting it to themselves)

* The externalities of LLM use remain the same (and, to an extent, can’t actually be fixed)

* There will always be programmers who code by hand, even in a professional capacity — and it’s quite likely they’ll be the ones dragging the industry forward (up the ladder of abstraction)

I don't use LLMs in my personal work too. The reasons are like yours.

If you care about your privacy, security, skills and self feeling, you mustn't use AI or LLMs online.

Local models exist. Your data doesn't have to leave your computer.

  using LLMs in my codings

  people argue that "LLMs are just a tool", but really, it is not, it is a SERVICE

I think the response is obvious (and why this is merely an aside rather than a "dealbreaker" proper): this is granting personhood to neural networks, which no one who supports this point would admit to in a thousand years. Either they're people and you're asking a person to think/paint for you, or they're inanimate machines and it's a tool; there is no middle ground. (If unconvinced: what about a camera makes it a tool to be used rather than a peer to be delegated to? It can draw a picture in milliseconds!)

  the current hype and craze for them

  And it's no wonder, there have been several studies confirming this:

The second paper is notoriously misleading, and a stain upon MIT -- observing brain activity differences between people who have to think deeply and write an essay by hand and people who type a sentence and then sit there until the allotted time is over is not surprising, and definitely doesn't show what they clearly intended the flashy graphics and suggestive conclusion to show (that using chatbots leads to brain damage). There's more, but long story short: they're manipulating valid techniques to make a tool seem like a uniquely-dangerous toxin, when the exact same effect applies to all previous tools of note (calculators, typewriters, word processors, translators, even Grammarly).

The third paper is just highly-speculative, deeply-polemic schlock, obviously.

  The quality of the output is not that great

2. Many experienced engineers disagree, to say the least, as do companies investing billions.

3. Again, you can't help but sense the author hasn't used post-Mythos models; even if they have, the fact that such a huge leap has occured in just the previous 24 months is overwhelming evidence against this notion. The linked sources being A) an /r/AntiAI post (!) and B) a pre-Mythos essay don't help.

  Congratulations, you have let OpenAI/Anthropic/Elon Musk dictate what your code does and why.

  I like writing code

  Environmental aspect

The preceeding 'this technology uses power' point doesn't need refutation, but it underlines the problem with the point above: this is post-hoc reasoning. Cutting down a tree farm in Finland is so, so far down the list of priorities for actual environmental activism that it's hard to describe, and yet this post has nothing about not working for companies that serve non-vegan meals for lunch, uses air conditioning, or flies people to yearly retreats.

  But I just personally feel squeamish about having my work being done by rather skeezy companies

  Even if some technology or tool sticks around, it does not necessarily mean its good idea to work with it.

TL;DR: Apologies to the (again, clear & well-intentioned) author, but this essay is like heroin -- I dislike it!

---

[1]: BTW, there's a reason Microsoft published this, and it's the opposite bias that this author assumed. Read this article and see how deep the conflict of interest admission is buried -- it says it all: https://www.project-syndicate.org/onpoint/anthropic-training...

[2]: pp. 12 of https://www.hec.edu/sites/default/files/documents/Computing%...

[3]: That tool, more info, definitive Finnish zoning documents available at this ChatGPT link (ew, I know, I agree!): https://chatgpt.com/s/t_6af081bc590881919c7231419db48a72

[4]: https://www.anthropic.com/research/glm-5-3-and-the-spread-of...

> With these subsidized token prices currently, I bet were seeing less and less AI usage encouragement in companies in the future.

I see a different trend, and for a different reason. Employees are encouraged to use open-weight LLMs hosted on-premise, or, at least, in the "correct" geographical area, in preference to models from big providers. The motivation is mostly compliance with GDPR and NDAs. And when this happens, complaints like this get ignored:

> Your local model wrote a wrong root cause analysis for the customer ticket. It's a broken tool, worse than nothing. Claude did it right. We really need either access to frontier models or, alternatively, reasonable expectations on your side about what is doable.

And that's bad.

As a hobbyist though, I find that LLMs are allowing me to tackle projects that I would not have tackled at all but for the existence of the LLM.

It's an important point to make (to me).

Many of these projects are rather tedious. (Other coders though might enjoy what this one-man calls "tedious".) I have found that liberating.

LLMs feel like the same thing. They're spending billions of dollars on these machines that can flood the market with something once rare and valuable--human creativity. If they succeed, they'll just be ruining creativity and diminishing what humanity values.