>Are so much people in programming implementing middleware / wrapping existing API all day that it gives them a feeling of liberation to be able to delegate those tasks ?

Yes. A lot of jobs are providing the glue between other pieces like this and not inventing new algorithms and such.

Perhaps this is why there is such a divide in sincere opinions about AI.

https://github.com/timescale/pg_textsearch

BM25 index for postgres, mostly written by a single (very smart) guy and Claude Code.

> Anecdotally, we use Opus 4.5 constantly on Zed's code base, which is almost a million lines of Rust code and has over 150K active users, and we use it for basically every task you can think of - new features, bug fixes, refactors, prototypes, you name it. The code base is a complex native GUI with no Web tech anywhere in it.

https://news.ycombinator.com/item?id=46522437

Zed is open source so you can look at their PRs and commit history. They even rolled their own Rust GUI framework for the project so it’s a decent case study of working on code that is barely in the training data (if at all).

No true Scotsman would ever do the kind of programming that 95% of the programming in the world is right?

Anyway https://www.reddit.com/r/osdev/comments/1opsicd/just_how_far...

Blas and faer are used only for small corners of the API (linalg and fft) which is exactly what numpy does. I encourage you to follow your own advice and look more closely at the interaction of ufuncs, strides, and dtypes.

> Are so much people in programming implementing middleware / wrapping existing API all day that it gives them a feeling of liberation to be able to delegate those tasks ?

Yes

The overwhelming majority of production code are simply wrappers and APIs calling existing frameworks and libraries

The type of projects you’re talking about are so unbelievably rare that almost nobody starts them or makes progress on them because predominantly they are social organizations that happen to export code

My question is why use AI to output javascript or python?

Why not output everything in C and ASM for 500x performance? Why use high level languages meant to be easier for humans? Why not go right to the metal?

If anyone's ever tried this, it's clear why: AI is terrible at C and ASM. But that cuts into what AI is at its core: It's not actual programming, it's mechanical reproduction.

Which means its incapabilities in C and ASM don't disappear when using it for higher-level languages. They're still there, just temporarily smoothed over due to larger datasets.

I've been a software engineer professionally for over two decades and I use AI heavily both for personal projects and at work.

At work the projects are huge (200+ large projects in various languages, C#, TypeScript front-end libs, Python, Redis, AWS, Azure, SQL, all sorts of things).

AI can go into huge codebases perfectly fine and get a root cause + fix in minutes - you just need to know how to use it properly.

Personally I do "recon" before I send it off into the field by creating a markdown document explaining the issue, the files involved, and any "gotchas" it may encounter.

It's exactly the same as I would do with another senior software engineer. They need that information to figure out what is going on.

And with that? They will hand you back a markdown document with a Root Cause Analysis, identify potential fixes, and explain why.

It works amazingly well if you work with it as a peer.

Yeah... don't get me wrong I find a lot of value in these tools. They do help with a lot of the tedium, can be helpful as debugging assistants, and in the right hands (with the right oversight) can indeed generate solid code.

But we are, even as of Opus 4.5, so wildly far away from what the author is suggesting. FWIW my experience is working in the AI/ML space at a major tech company and as a maintainer + contributor of several OSS projects.

People are blindly trusting LLMs and generating mountains of slop. And the slop compounds.

For some people, code == junk?

[dead]

If you're on a Mac, it can speak the notification instead for more detail!

``` "hooks": { "Notification": [ { "hooks": [ { "type": "command", "command": "jq '.message' | say" } ] } ] } ```

Hah! I’ve done something similar. I created a bunch of pre-defined voice messages with Eleven Labs and then have a script that randomly calls them via the same hooks.

https://github.com/daveschumaker/homebrew-claude-sounds

Omg, this is so great, that you so much! Gonna set up a bunch of A320 warning sounds to scare me in case I am idle for too long :)

If LLMs were like compilers, you could put src/ into .gitignore and only upload the prompt.

Even the earliest compilers didn't work by the programmer writing code, copying the assembly output into their source tree, and throwing away the code.

This is not a value judgement, they simply aren't the same thing at all.

>> Compilers are deterministic, making their generated assembly code verifiable

This is true (to an extent), but the generated LLM code is also verifiable. We use automated tests to do it.

I suspect the argument is that both AI and a compiler enables building software at a higher level of abstraction.

> Compilers are deterministic, making their generated assembly code verifiable

People keep saying this like it is an absolute fact, whereas in reality it is a scale.

Compilers are more deterministic than LLMs in general, but no they are not completely deterministic. That's why making reproducible builds is hard!

https://stackoverflow.com/questions/52974259/what-are-some-e... and https://github.com/mgrang/non-determinism give some good examples of this.

This leads to the point: in general do we care about this non-determinism?

Most of the time, no we don't.

Once you accept that the next stage is accepting that most of the time the non-deterministic output of an LLM is good enough!

This leads to how do I verify it is good enough which leads to testing and then suddenly you have a working agentic loop....

> I will never as long as I live understand the argument that AI development is more fun.

Some people find software architecture and systems thinking more fun than coding. Some people find conducting more fun than playing an instrument. It's not too mysterious.

AI lets you pick the parts you want to focus on and streamline the parts you don't. I get zero joy out of wrestling build tools or figuring out deploy scripts to get what I've built out onto a server. In the past side projects would stall out because the few hours per week I had would get consumed by all of the side stuff. Now I take care of that using AI and focus on the parts I want to write.

Seems some people I know who really like AI aren't particularly good with their editors. Lots of AI zealots use the "learn your tools" when they are very slow with their editors. I'm sure that's not true across the board, but the sentiment that it's not worth it to get really advanced with your editor has been pretty prevalent for a very long time.

I don't care if you use AI but leave me alone. I'm plenty fast without it and enjoy the process this author callously calls "wrestling with computers."

Of course this isn't going to help with the whole "making me fast at things I don't know" but that's another can of worms.

~20 years working in tech for me, mostly big companies, and I’ve never been more miserable. I also can’t stop myself from using Claude Code and the like.

I think it’s a bit like a gambling addiction. I’m riding high the few times it pays off, but most of the time it feels like it’s just on the edge of paying off (working) and surely the next prompt will push it over the edge.

> is more fun because you don’t have to “wrestle the computer”

Indeed, of all the possible things to say!

AI "development" /is/ wrestling the computer. It is the opposite of the old-fashioned kind of development where the computer does exactly what you told it to. To get an AI to actually do what I want and nothing else is an incredibly painful, repetitive, confrontational process.

Fun is a feeling, so one can't really have an argument that something is fun or not - that would be a category error no?

You've got a good analogy there though, because many great and/or famous painters have used teams of apprentices to produce the work that bears their (the famous artist's) name.

I'm reminded also of chefs and sous-chefs, and of Harlan Mill's famous "chief surgeon plus assistants" model of software development (https://en.wikipedia.org/wiki/Chief_programmer_team). The difference in our present moment, of course, is that the "assistants" are mechanical ones.

(as for how fun this is or isn't - personally I can't tell yet. I don't enjoy the writing part as much - I'd rather write code than write prompts - but then also, I don't enjoy writing grunt code / boilerplate etc., and there's less of that now, - and I don't enjoy having to learn tedious details of some tech I'm not actually interested in in order to get an auxiliary feature that I want, and there's orders of magnitude less of that now, - and then there are the projects and programs that simply would never exist at all if not for this new mechanical help in the earliest stages, and that's fun - it's a lot of variables to add up and it's all in flux. Like the French Revolution, it's too soon to tell! - https://quoteinvestigator.com/2025/04/02/early-tell/)

->...it's commissioning.

I like this. I'm going to see if my boss will go for me changing my title from Solutions Architect to Solutions Commissioner. I'll insist people refer to me as "Commissioner ajcp"

Plenty of people will tell you that they enjoy solving business problems.

Well, I'll have to take their word for it that they're passionate about maximizing shareholder value by improving key performance indicators, I know I personally didn't sign up for being in meetings all day to leverage cross functional synergies with the goal of increasing user retention in sales funnels, or something along those lines.

I'm not passionate about either that or mandatory HR training videos.

It’s more like saying you love painting, but you’re glad you no longer have to hike into the wilderness, crush minerals, boil oils, and invent pigments from scratch before you can put brush to canvas.

> I will never as long as I live understand the argument that AI development is more fun

AI is more fun for programmers that should've gone into management instead, and prefer having to explain things in painstaking detail in text, rather than use code. In other words, AI is for people that don't like programming that much.

Why would you even automate the most fun part of this job? As a freelance consultant, I'd rather have a machine to automate the whole boring business side so I could just sit in front of my computer and write stuff with my own hands.

If you have to work in a language or framework with a lot of arbitrary-seeming features, ugly or opaque translation layers, or a lot of boiler-plate, then I absolutely understand the sentiment.

Programming a system at a low-level from scratch is fun. Getting CSS to look right under a bunch of edge cases - I won't judge that programmer too harshly for consulting the text machine.

This is especially true considering it's these shallow but trivia-dominated tasks which are the least fun and also which LLMs are the most effective at accomplishing.

I don't care about technology for what it is. I care about it for what it can do. If I can achieve what I want by just using plain English, I'm going to achieve what I want faster and more thoroughly enjoy the process. Just my two cents.

People have given most of the answers, but here's another one: At work, when I write code, I spend a lot of time designing it, making good interfaces, good tests, etc. It gave me joy to carefully craft it.

At home, I never had the time/will to be as thorough. Too many other things to do in life. Pre-LLMs, most of my personal scripts are just - messy.

One of the nice things with LLM assisted coding is that it almost always:

1. Gives my program a nice interface/UI

2. Puts good print/log statements

3. Writes tests (although this is a hit or miss).

Most of the time it does it without being asked.

And it turns out, these are motivation multipliers. When developing something, if it gives me good logs, and has a good UI, I'm more likely to spend time developing it further. Hence, coding is now more joyful.

And it turns out, these tend to

There are some things that I think become more fun, like dealing with anything you don't actually find interesting. I recently made a quick little web app and I hand-coded the core logic since I find that part fun. But I vibe-coded the front-end, especially the CSS, because I just don't find that stuff very interesting and I'm less picky about the visuals. Letting the AI just do the boring parts for me made the overall project more fun I think.

But it’s not really an argument, it’s a statement about feelings. Some people really do prefer coding with AI. Is that so strange? Often we’ve spent 1 or 2 decades writing code and in our day jobs we don’t see a lot of novel problems come our way at the level of the code anymore (architecture, sure, still often novel). We’ve seen N number of variations on the same thing; we are good at doing them but get little joy in doing them for the N + 1th time. We find typing out api serializers and for loops and function definitions and yaml boilerplate just a little boring, if we already have a picture in our head of what we want to do. And we like being able to build faster and ship to our users without spending hours and extra brain cycles dealing with low-level complexity that could be avoided.

I am happy to accept that some people still prefer to write out their code by hand… that’s ok? Keep doing it if you want! But I would gently suggest you ask yourself why you are so offended by people that would prefer to automate much of that, because you seem to be offended. Or am I misreading?

And hey, I still enjoy solving interesting problems with code. I did advent of code this year with no LLM assistance and it was great fun. But most professional software development doesn’t have that novelty value where you get to think about algorithms and combinatorical puzzles and graphs and so on.

Before anyone says it, sure, there is a discussion to be had about AI code quality and the negative effects of all this. A bad engineer can use it to ship slop to production. Nobody is denying that. But I think that’s a separate set of questions.

Finally, I’m not sure painting is the best analogy. Most of us are not creating works of high art here. It’s a job, to make things for people to use, more akin to building houses than painting the Sistine Chapel. Please don’t sneer at use if we enjoy finding ways to put up our drywall quicker.

Who's actually coding?

You're never really wrestling the computer. You're typically wrestling with the design choices and technological debt of decisions that were in hindsight bad ones. And it's always in hindsight, at the time those decision always seem smart.

Like with the rise of frameworks, and abstractions who is actually doing anything with actual computation?

Most of the time it's wasting time learning some bs framework or implementing some other poorly designed system that some engineer that no longer works at the company created. In fact the entire industry is basically just one poorly designed system with technological debt that grows increasingly burdensome year by year.

It's very rarely about actual programming or actual computation or even "engineering". But usually just one giant kludge pile.

I love building things with computers. I'm not particularly interested in the coding.

I've coded professionally for 30 years (ergh!). I'm ok at it.

But I love building things with AI. I haven't had this much fun since the early 2000s.

I have been developing for 30 years professionally and 10 years before that as a hobbyist or in school

Development is solely to exchange labor for money.

I haven’t written a single line of code “for fun” since 1992. I did it for my degree between 1992-1996 while having fun in college and after that depending on my stage in life, dating, hanging out with friends, teaching fitness classes and doing monthly charity races with friends, spending time with my wife and (step)kids, and now enjoying traveling with my wife and friends, and still exercising

I understand this sentiment but, it is a lot of fun for me. Because I want to make a real thing to do something, and I didn't get into programming for the love of it, I got into it as a means to an end.

It's like the articles point: we don't do assembly anymore and no one considers gcc to be controversial and no one today says "if you think gcc is fun I will never understand you, real programming is assembly, that's the fun part"

You are doing different things and exercising different skillsets when you use agents. People enjoy different aspects of programming, of building. My job is easier, I'm not sad about that I am very grateful.

Do you resent folks like us that do find it fun? Do you consider us "lesser" because we use coding agents? ("the same as saying you’re really into painting but you’re not really into the brush aspect so you pay someone to paint what you describe. That’s not doing, it’s commissioning.") <- I don't really care if you consider this "true" painting or not, I wanted a painting and now I have a painting. Call me whatever you want!

What part of making a movie is fun? Acting, costumes, sets, camerawork, story, dialogue, script, sound effects, lighting, editing, directing, producing, marketing?

Creating software has a similar number of steps. AI tools now make some of them much (much) easier/optional.

And the thing I don't get about how excited people are is that if what LLMs really do is change software development from coding to code review, which is the part of software development that is universally hated.

One can have fun with all manner of things. Take wood-working for example. One can have fun with a handsaw. One can also have fun with a table saw. They're both fun, just different kinds

Most master painters of the past had teams organized as workshops where the majority of the painting was NOT done by the master.

The “lone genius” image is largely a modern romantic invention.

I have zero desire to go hunt down and create a wrapper to avoid some kernel bug because what I want to do can’t be implemented because of an edge case of some CPU-package incompatibility.

I have found in my software writing experience that the majority of what I want to write is boiler plate with small modifications but most of the problems are insanely hard to diagnose edge cases and I have absolutely no desire nor is it a good use of time in my opinion to deal with structural issues in things that I do not control.

The vast majority of code you do not control because you aren’t the owner of the framework or library your language or whatever and so the Bass majority of software engineering is coming up with solutions to foundational problems of the tools you’re using

The idea that this is the only true type of software engineering is absurd

True software engineering is systems, control and integration engineering.

What I find absolutely annoying is that there’s this rejection of the highest level Hofstetter level of software architecture and engineering

This is basically sneered at over the idea of “I’m gonna go and try to figure out some memory management module because AMD didn’t invest in additional SOC for the problems that I have because they’re optimized for some Business goals.”

It’s frankly junior level thinking

It shaves yaks for me. I appreciate that.

Well, washing cloths has definitely become "more fun" since the invention of washing machines... Cleaning your flat has become "more fun" since vacuum cleaners. Writing has become "more fun" since editors overtook typewriters. Bedroom studios power most of the clubs I know. Navigating a city as a blind pedestrian has definitely become more fun since the introduction of the oh-so-evil-screentime-bad smartphone. I could go on forever. Moving has become more fun since the invention of the wheel... See?

[dead]

> not really into the brush aspect so you pay someone to paint what you describe. That’s not doing, it’s commissioning.

What if I have a block of marble and a vision for the statue struggling from inside it and I use an industrial CNC lathe to do my marble carving for me. Have I sculpted something? Am I an artist?

What if I'm an architect? Brunelleschi didn't personally lay all the bricks for his famous dome in Florence --- is it not architecture? Is it not art?

Thinking the same thing, nobodies calling the Pope a painter because he paid Michelangelo to paint a chapel.

In b4 someone mentions some famous artists had apprentices under them.

I might start watching golf, and everytime someone else get's the ball in the hole i'll take credit for it. "Did you see what did there? "

You are essentially making a character attack on anyone who disagrees with this article. You dismiss outright reasonable objections you have not heard and instead you presume fear and loathing are the only possible motivations to disagree.

> "the skill of writing and reading code is obsolete, and it's our job to make software engineering increasingly entirely automated"

This simply is a mediocre take, sometimes I feel like people never actually coded at all to have such opinions

> The parts of it that aren't high level product management and systems architecture are quickly becoming irrelevant

Embedded in this, is the assumption that many SWEs can actually do those roles better than existing specialists.

If they can't - end of the line

Remains to be seen if that pill needs swallowing at all. At least for reading code.

I actually don't think they would agree with most of this. Why would you think that?

> I don't accept the argument that correct and LLMs errors is the same as correcting a junior devs errors because the junior dev would (presumably) learn and grow to become a senior. The technology doesn't exist for an LLM to do the same today and there's no viable path in that direction.

But the technology does exist. The proof is in the models you can use today, on two lines:

First, what you describe is exactly what the labs are doing. We went from "oh, look, it writes poems and if you ask for code it almost looks like python" 3 years ago. Since then, the models can handle most programming tasks, with increasing difficulty and increasing accuracy. What seemed SF 3 years ago is literally at your fingertips today. Project scaffolding, searching through codebases, bug finding, bug solving, refactorings, code review. All of these are possible today. And it all became possible because the labs used the "signals" from usage + data from subsidising models + RL + arch improvements to "teach" the models more and more. So if you zoom out, the models are "learning", even if you or I can't teach them in the sense you meant.

Secondly, when capabilities become sufficiently advanced, you can do it locally, for your own project, with your own "teachings". With things like skills, you can literally teach the models what to do on your code base. And they'll use that information in subsequent tasks. You can even use the models themselves for this! A flow that I use regularly is "session retro", where I ask the model to "condense the learnings of this session into a skill". And then those skills get invoked on the next task dealing with the same problem. So the model doesn't have to scour the entire code base to figure out where auth lives, or how we handle migrations, and so on. This is possible today!

> how we'll go from novice to expert

You spent the proverbial 10k hours like before. I don't know by AI has to lead to the lack of learning. I don't find people stop learning digital painting so far, even digital painting, from my perspective, is even more "solved" than programming by machines.

I heard that Pixar had a very advanced facial expression simulation system a decade ago. But I am very willing to bet that when Pixar hires animators they still prefer someone who can animate by hand (either in Maya or frame-by-frame on paper).

I can tell you the current thinking of most of the instructors I know: teach the same fundamentals as always, and carefully add a bit of LLM use.

To use LLMs effectively, you have to be an excellent problem-solver with complex technical problems. And developing those skills has always been the goal of CS education.

Or, more bluntly, are you going to hire the junior with excellent LLM skills, or are you going to hire the junior with excellent LLM skills and excellent technical problem-solving skills?

But they do have to be able to use these tools in the modern workplace so we do cover some of that kind of usage. Believe me, though, they are pretty damned good at it without our help. The catch is when students use it in a cheating way and don't develop those problem-solving skills and then are screwed when it comes time to get hired.

So our current thinking is there's no real shortcut other than busting your ass like always. The best thing LLMs offer here is the ability to act as a tutor, which does really increase the speed of learning.

AI can also make you invest useful time in things that are not useful or not needed. It also deincentivizes collaboration. If everyone builds thier own version of say Beebook with 5 features, thats worthless compared to BeeBook opensource or even corporate Beebook with thousands of features and complex workflows. And everyone who worked on thier own version of BeeBook wasted thier time.

With AI you have to be careful to know what is important, you dont want to waste your time doing random stuff that may not even get a single user. If its for fun, thats fine but if you want to build a business or improve your output, I would advise people to choose well.

Ah, Human beings! Famous for their determinism, reliability, and for not making logical errors!

On windows I create a new locked down user with NTFS permissions denied everywhere except the target project path. I then run the agent app as that user with otherwise unrestricted powershell access.

Be careful running claude in a devcontainer with no other restrictions - it at least nominally knows how to jailbreak out of containers, even though it appears heavily moralized not to. If you (for example) feed it arbitrary web data that contains a prompt sufficiently persuasive to get to try, it's pretty capable of doing it.

Still leaves you open for data exfil. Your AI goes to a site to check documentation, but oh no that site wants it to make an API call with a very specific token.

LLMs also try and find short cuts to get the task done, for example I wrote some code (typescript) for work that had a lot of lint errors (I created a pretty strict rule set)

And I asked codex to fix them for me, first attempt was to add comments to disable the rules for the whole file and just mark everything as any.

Second attempt was to disable the rules in the eslint config.

It does the same with tests it will happily create a work around to avoid the issue rather than fix the issue.

> Our ability to zoom in and implement code is now obsolete Even with SOTA LLMs like Opus 4.5 this is downright untrue. Many, many logical, strategic, architectural, and low level code mistakes are still happening. And given context window limitations of LLMs (even with hacks like subagents to work around this) big picture long-term thinking about code design, structure, extensibility, etc. is very tricky to do right.

> If you can't see this, I have to seriously question your competence as an engineer in the first place tbh.

I can't agree more strongly. I work with a number of folks who say concerning things along the lines of what you describe above (or just slightly less strong). The trust in a system that is not fully trustworthy is really shocking, but it only seems to come from a particular kind of person. It's hard to describe, but I'd describe it as: people that are less concerned with the contents of the code versus the behaviour of the program. It's a strange dichotomy, and surprising every time.

I mean, if you don't get the economics of a reasonably factored codebase vs one that's full of hacks and architecturally terrible compromises - you're in for a VERY bad time. Perhaps even a company-ending bad time. I've seen that happen in the old days, and I expect we're in the midst of seeing a giant wave of failures due to unsustainably maintained codebases. But we probably won't be able to tell, startups have been mostly failing the entire time.

Its sad we have gone from making the software as good and efficient as possible to "good enough, ship it". This is the main reason AI agents are successful.

Original author of the post here. Just to give credit where it's due, that was a quote from this other excellent article written by someone else:

https://www.stochasticlifestyle.com/a-guide-to-gen-ai-llm-vi...

The definition of 'vibe code' is somewhat nebulous at the moment. For many it means "only look at the end product (website) and use prompts to fix it" but for others it means "mostly don't hand-code anything, but check the diffs".

> If you’re not reading your output, then why does skill level even matter?

Few thoughts here.

Experience helps you "check" faster that what you asked for is actually what was delivered. You "know" what to check for. You know what a happy path is, and where it might fail. You're more likely to test outside the happy path. You've seen dozens of failure modes already, you know where to look for.

Experience also allows you to better define stuff. If you see that the output is mangled, you can make an educated guess that it's from css. And you can tell the model to check the css integration.

Experience gives you faster/better error parsing. You've seen thousands of them already. You probably know what the error means. You can c/p the error but you can also "guide" the model with something like "check that x is done before y". And so on.

Last, but not least, the "experience" in actually using the tools gives you a better understanding of their capabilities and failure modes. You learn where you can let it vibe away, or where you need to specify more stuff. You get a feeling for what it did from a quick glance. You learn when to prompt more and where to go with generic stuff like "fix this".

Don't you think "having a concrete idea of what sort of code change / end behavior you're looking for" affects the prompts and LLM output?

Do apply the same logic to conductors too?

One man’s trash is another man’s treasure.

>hat makes individuals even less free and a few large companies even more powerful and wealthy

You're what, 250 years behind at this point?

Since the dawn of the industrial revolution there is a general trend that fewer can make more with less. And really even bigger than AI were fast fuel based transportation and then global networks. Long before we started worrying about genAI, businesses have been consolidating down to a few corporations that make enough to supply the world from a singular large factories.

We fought the war against companies. Companies won.

Now you're just at the point where the fabric makers were, where the man with the pick axe was, where the telephone switch operator was, where the punch card operator was.

Good news: the evidence points to it being slower than non-ai workflows. So we're destroying our economy, society, and planet to make worse software, more slowly! :)

We, as SW engineers, have been doing that to many industries for the last 40+ years. It's silly and selfish to draw the line now that we're in the crosshairs.

Yup.