Seems people read the blog but not the code, I looked at the stated rewrite of Numpy in Rust:
> As an introductory project, I rewrote Numpy in Rust. It was great fun.
That's not a rewrite at all it's just a wrapping of an existing linear algebra Rust library (faer, blas, etc..) with a more Numpy like API. It seems to me that every AI project I look at is just a mashup/wrapper over existing things. Where are the real bootstrapped new things with AI ? Is there any big OSS project (Linux kernel, postgresql, Django, whatever) with serious bugfixes or new features implemented by AI that we could look at ?
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 ?
>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.
> 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.
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).
This is a thing you can credibly say only if you've never used a popular new non-mainline editor. Sublime Code was "buggy as hell" too; all new editors are. Editors are incredibly difficult to do well. And Zed is doing it on hard mode, cross-platform.
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
I get vibe-coders not having a good experience once the honeymoon is over. But I'm fascinated that a professional software developer could have such a different experience than I do.
• LLMs generate junk
• LLMs generate a lot of junk
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.
One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a lot more functionality while keeping dependencies minimal.
I haven't tried C or ASM yet, but it has been working very well with a C++ project I've been working on, and I'm sure it would do reasonably well with bare-bones C as well.
I'd be willing to bet it would struggle more with a lower-level language initially, but give it a solid set of guardrails with a testing/eval infrastructure and it'll get its way to what you want.
We used higher level programming languages because "Developer time is more expensive than compute time", but if the AI techbros are right, we are approaching the point where that is not going to be true.
It's going to take the same amount of time creating a program in C as it does in Python.
Pretty interesting take this. I wonder if there is a minimal state management we could evolve which would be sufficient for LLMs to use while still making it possible for a human to reason about the abstraction. It won't be as bloated as the existing ones we came up with organically however.
I mean, you're basically LLM-washing other people's code, then. All those UI components that other people wrote and at least expected attribution may not be libraries anymore, sure. But you've basically just copied and maybe lightly modified that code into your project and then slapped a sticker on it saying "mine." If you did that manually with open source code, you'd be in violation of the attribution terms almost all the licenses have in common. But somehow it's okay if the computer does it for you?
It is a gray area. What if you took Qt, removed macros, replaced anchoring with css for alignment, took all widget properties out into an entity component system and called it ET, could Trolltech complain? It is an entirely new design and nothing like they built. A ship of Theseus if you will.
The Ship of Theseus has nothing to do with the identity of the parts. That is not in question at all; they are explicitly different parts. The thought experiment is the question of the identity of the whole.
Qt in your example is a part. You're application is the whole. If you replaced Qt with WxWidgets, is your application still the same application?
But to answer your question, to replace Qt with you're own piecemeal code doesn't do anything more to Qt than replacing it with WxWidgets would: nothing. The Qt code is gone. The only way it would ship-of-theseus itself into "still being Qt, despite not being the original Qt" would be if Qt required all modifications to be copyright-assigned and upstreamed. That is absurd. I don't think I've ever seen a license that did anything like that.
Even though licenses like the GPL require reciprocal FOSS release in-kind, you still retain the rights to your code. If you were ever to remove the GPL'd library dependency, then you would no longer be required to reciprocate. Of course, that would be a new version of your software and the previous versions would still be available and still be FOSS. But neither are you required to continue to offer the original version to anyone new. You are only required to provide the source to people who have received your software. And technically, you only have to do it when they ask, but that's a different story.
The premise of your question is wrong. I would still write Python for most of my tasks even if I were just as fast at writing C or ASM.
Because the conciseness and readability of the code that I use is way more important than execution speed 99% of the time.
I assume that people who use AI tools still want to be able to make manual changes. There are hardly any all or nothing paradigms in the tech world, why do you assume that AI is different?
My small-program success story with genAI coding is pretty much the opposite of your claim. I used to use a bash script with a few sox instances piped into each other to beat-match and mix a few tracks. Couldn't use a GUI... Then came gpt-5, and I wanted to test it anyway. So I had it write a single-file C++ program that does the track database, offline mixing, limiter and a small REPL-based "UI" to control the thing. I basically had results before my partner was finished preparing breakfast. Then I had a lot of fun bikeshedding the resulting code until it felt like something I'd like to read. Some back and forth, pretending to have an intern and just reviewing/fixing their code. During the whole experience, it basically never generated code which wouldn't compile. Had a single segfault which was due to unclear interface to a C library. Got that fixed quickly.
And now, I have a tool to do a (shuffled if I want) beat-matched mix of all the tracks in my db which match a certain tag expression. "(dnb | jungle) & vocals", wait a few minutes, and play a 2 hour beat-matched mix, finally replacing mpd's "crossfade" feature. I have a lot of joy using that tool, and it was definitely fun having it made. clmix[1] is now something I almost use daily to generate club-style mixes to listen to at home.
I don't get this. AI coders keep saying they review all the code they push, and your suggestion is to use even harder languages the average vibe coder is unable to understand, all in name of "performance"? Faster code maybe, and exponentially increasing the tech debt and amount of bugs that slips through.
It wasn't even long ago that we thought developer experience and capacity for abstraction (which is easier to achieve in higher level languages) was paramount.
> AI coders keep saying they review all the code they push
Those tides have shifted over the past 6 weeks. I'm increasingly seeing serious, experienced engineers who are using AI to write code and are not reviewing every line of code that they push, because they've developed a level of trust in the output of Opus 4.5 that line-by-line reviews no longer feel necessary.
(I'm hesitant to admit it but I'm starting to join their ranks.)
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.
Depends on what it is, the quick bash script I write to verify something or the core of SaaS that's being launched have different levels of strictness, style, testing, etc.
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.
I use AI as a rubber duck to research my options, sanity-check my code before a PR, and give me a heads up on potential pain points going forward.
But I still write my own code. If I'm going to be responsible for it, I'm going to be the one who writes it.
It's my belief that velocity up front always comes at a cost down the line. That's been true for abstractions, for frameworks, for all kinds of time-saving tools. Sometimes that cost is felt quickly, as we've seen with vibe coding.
So I'm more interested in using AI in the research phase and to increase the breadth of what I can work on than to save time.
Over the course of a project, all approaches, even total hand-coding with no LLMs whatever, likely regress to the mean when it comes to hours worked. So I'd rather go with an approach that keeps me fully in control.
Yeah my guess is that it takes roughly the same amount of time regardless if it's AI agents or hand coding, the time just gets spent in different ways (writing vs reading for example).
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.
nice, next step is to write a custom function that derives a useful but repeatable message from the hooks and put a little cache in front the Eleven Labs message gen. For example: "In {Project}, Claude needs your permission to run {command}"
That way you can stay comfortably in the free plan with awesome voice messages
I have a different voice for my laptop compared to my main computer and can also pick per project
The author presents a false dichotomy when discussing "Why Not AI".
... there are some serious costs and reasonable
reservations to AI development. Let's start by listing
those concerns
These are super-valid concerns. They're also concerns that
I suspect came around when we developed compilers and
people stopped writing assembly by hand, instead trusting
programs like gcc ...
Compilers are deterministic, making their generated assembly code verifiable (for those compilers which produce assembly code). "AI", such as "Claude Code (or Cursor)" referenced in the article, is nondeterministic in their output and therefore incomparable to a program compiler.
One might as well equate the predictability of a Fibonacci sequence[0] to that of a PRNG[1] since both involve numbers.
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
> People keep saying this like it is an absolute fact, whereas in reality it is a scale.
My statement is of course a generalization due to its terseness and focuses on the expectation of repeatable results given constant input, excluding pathological definitions of nondeterminism such as compiler-defined macro values or implementation defects. Modern compilers are complex systems and not really my point.
> This leads to the point: in general do we care about this non-determinism?
> Most of the time, no we don't.
Not generally the type of nondeterminism I described, no. Nor the nondeterministic value of the `__DATE__` macro referenced in the StackOverflow link you provided.
> 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 is where the wheels fall off.
First, "most of the time" only makes sense when there is another disjoint group of "other times." Second, the preferred group defined is "non-deterministic [sic] output of an LLM is good enough", which means the "other times" are when LLM use is not good enough. Third, and finally, when use of an approach (or a tool) is unpredictable (again, excluding pathological cases) given the same input, it requires an open set of tests to verify correctness over time.
That last point may not be obvious, so I will extrapolate as to why it holds.
Assuming the LLM in use has, or is reasonably expected to have, model evolution, documents generated by same will diverge unpredictably given a constant prompt. This implies prompt evolution will also be required at a frequency almost certainly different than unpredictable document generation intrinsic to LLMs. This in turn implies test expectations and/or definitions having to evolve over time with nothing changing other than undetectable model evolution. Which means any testing which exists at one point in time cannot be relied upon to provide the same verifications at a later point in time. Thus the requirement of an open set of tests to verify correctness over time.
Finally, to answer your question of:
how do I verify it is good enough
You can't, because what you describe is a multi-story brick house built on a sand dune.
> Assuming the LLM in use has, or is reasonably expected to have, model evolution, documents generated by same will diverge unpredictably given a constant prompt.
> This leads to the point: in general do we care about this non-determinism?
> Most of the time, no we don't.
well that’s a sweeping generalisation. i think this is a better generalised answer to your question.
> It depends on the problem we’re trying solve and the surrounding conditions and constraints.
software engineering is primarily about understanding the problem space.
are 99% of us building a pacemaker? no. but that doesn’t mean we can automatically make the leap to assuming a set of tools known for being non-deterministic are good enough for our use case.
it depends.
> Once you accept that the next stage is accepting that most of the time the non-deterministic output of an LLM is good enough!
the next stage is working with whatever tool(s) is/are best suited to solve the problem.
> are 99% of us building a pacemaker? no. but that doesn’t mean we can automatically make the leap to assuming a set of tools known for being non-deterministic are good enough for our use case.
This seems irrelevant?
Either way hopefully you test the pacemaker code comprehensively!
That's pretty much the best case for llm generated code: comprehensive tests of the desired behaviour.
Abstraction is only useful when it involves a consistent mapping between A and B, LLM’s don’t provide that.
In most contexts you can abstract the earth as a sphere and it works fine ex:aligning solar panels etc. Until you enter the realm of precision where treating the earth as a sphere utterly fails. There’s no realistic set of tests you can right where an unsupervised LLM’s output can be trusted to generate a complex system which works if it’s constantly being recreated. Actual compilers don’t have that issue.
automated tests are not verification. The "llm as a compiler" provides zero guarantees about the code.
A compiler offers absolute guarantees that what you write is semantically preserved, barring bugs in the compiler itself. An llm provides zero guarantees even with zero bugs in the llm's code.
I don't know what you are arguing, or why. Please follow the thread in its full context. Specifically, the argument the article author is making is that moving to a higher level of abstraction also cost developers the benefit of understanding the internals. Ultimately, that ended up not mattering very much.
The OP pushed back on this, saying compilers are deterministic and LLMs are not, and that lack of determinism makes LLM output unverifiable. I said the latter is not true because you can perform verification using tests. You claimed tests are not verification because LLMs don't preserve the semantics.
I'm not sure why semantics matter. LLMs providing no guarantees regarding the preservation of semantics is not important because you can guarantee the behavior of the generated code using tests. In most domains, this is sufficient. You tell the LLM to write code that does X, Y and Z, and then verify X, Y and Z using a test. That's it.
I will never as long as I live understand the argument that AI development is more fun. If you want to argue that you’re more capable or whatever, fine. I disagree but I don’t have any data to disprove you.
But saying that AI development is more fun because you don’t have to “wrestle the computer” is, to me, 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 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.
I am one of those, but that's why I went into the ops side of things and not dev, although the two sides have been merging for a while now and even though I deal with infrastructure, I do so by writing code.
I don't mind ops code though. I dislike building software as in products, or user-facing apps but I don't mind glue code and scripting/automation.
Don't ask me to do leetcode though, I'll fail and hate the experience the entire time.
That is accurate for me. I have never enjoyed coding puzzles or advent of code. My version of that is diving into systems and software when it breaks. That is fun...as long as my job or income is not on the line
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.
> I get zero joy out of wrestling build tools or figuring out deploy scripts to get what I've built out onto a server.
And for me (and other ops folks here I'd presume), that is the fun part. Sad, from my career perspective, that it's getting farmed out to AI, but I am glad it helps you with your side projects.
Yeah, that is one of my main uses for AI: getting the build stuff and scripts out of the way so that I can focus on the application code. That and brainstorming.
In both cases, it works because I can mostly detect when the output is bullshit. I'm just a little bit scared, though, that it will stop working if I rely too much on it, because I might lose the brain muscles I need to detect said bullshit.
Im super interested to know how juniors get a long. i have dealt with build systems for decades and half the time its just use google or stackoverflow to get past something quickly, or manually troubleshoot deps. now i automate that entirely. and for code, i know what good or not, i check its output and hve it redo anything t5hat doesnt pass my known stndards. It makes using it so much easier. the article is so on point
Also just.. boring code. Like I'm probably more anti-AI than most, but even I'll acknowledge it's nice to just be like... "hey this array of objects I have, I need sorted by this property" and just have it work. Or how to load strings from exotic character encodings. Or dozens of other bitchy little issues that drag software dev speed down, don't help me "grow" as a developer, and/or are not interesting to solve, full stop.
I love this job but I can absolutely get people saying that AI helps them not "fight" the computer.
I've always believed that the dozens of 'bitchy little issues' are the means to grow as a developer.
Once you've done it, you'll hopefully never have to do it again (or at worse be derivatives). Over time you'll have a collection of 'how to do stuff'.
I think this is the path to growth. Letting a LLM do it for you is equivalent to it solving a hard leetcode problem. You're not really taxing your brain.
My point is that it's tempting and irresistible (based on other comments in this thread) to move from basic attribute sorting, to basic CRUD, SQL queries, CSS/Tailwind, typescript error resolution then using it for Dijkstra, because why not?, it's so nice.
Then we're just puppetmasters pulling the strings (which some think this is the way the industry is going).
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.
Isn't that because the "best in class" LLM-enabled IDE or dev environment keeps changing every few months, or even more frequently if you're price conscious and want to use the most powerful coding models?
Agreed but it's not even that. I worked with someone who was insanely fast with RubyMine. All the shortcuts were second-nature and shit just flew onto the screen. So generally, the argument would be to be really good with whatever editor you have. It also goes outside of that, like snippets are still very viable for lots of boilerplate.
At the same time, one of the best developers I worked with was a two-finger typist who had to look at the keyboard. But again, I don't care if you're going to use AI (well, that's not entirely true but not going to get into it) but the tone of this article that "You should learn it, " I take issue with.
~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.
It feels like this to me too, whenever I give it a try. It's like a button you can push to spend 20 minutes and have a 50/50 chance of either solving the problem with effortless magic, or painfully wasting your time and learning nothing. But it feels like we all need to try and use it anyway just in case we're going to be obsolete without it somehow.
If it doesn't work, it's an annoyance and you have to argue with it.
If it does work, it's one more case where maybe with the right MCP plumbing and/or a slightly better model you might not be needed as part of this process.
Feels a bit lose-lose.
> I also can’t stop myself from using Claude Code and the like.
just.. uninstall it? i've removed all ai tooling from both personal+work devices and highly recommend it. there's no temptation to 'quickly pull up $app just to see' if it doesn't exist
It’s become a core expectation at work now (Meta). If I’m not actively using it, then I’ll be significantly dinged in performance reviews. Honestly, it’s forced me to consider going to work elsewhere.
It does _feel_ like the value and happiness will come some versions down the road when I can actually focus on orchestration, and not just bang my head on the table. That’s the main thing that keeps me from just removing it all in personal projects.
Is this coming from the hypothesis / prior that coding agents are a net negative and those who use them really are akin to gambling addicts that are just fooling themselves?
The OP is right and I feel this a lot: when Claude pulls me into a rabbit hole, convinces me it knows where to go, and then just constantly falls flat on its face and we waste like several hours together, with a lot of all caps prompts from me towards the end. These sessions last in a way that he mentions: "maybe its just a prompt away from working"
But I would never delete CC because there are plenty of other instances where it works excellent and accelerates things quite a lot. And additionally, I know we see a lot of "coding agents are getting worse!" and "METR study proves all you AI sycophants are deluding yourselves!" and I again understand where these come from, agree with some of the points they raise, but honestly: my own personal perception (which I argue is pretty well backed up by benchmarks and by Claude's own product data which we don't see -- I doubt they would roll out a launch without at least one or more A/B tests) is that coding agents are getting much better, and that as a verifiable domain these "we're running out of data!" problems just aren't relevant here. The same way alphago gets superhuman, so will these coding agents, it's just a matter of when, and I use them today because they are already useful to me.
no, this is coming from the fact OP states they are miserable. that is unsustainable. at the end of the day the more productive setup is the one that keeps you happy and in your chair long term, as you'll produce nothing if you are burnt out.
This is definitely the feeling i get. Sometimes it works amazingly well that I think "Oh may be the hype was right all along, have I become the old guy yelling at claude?" but the other times it fails spectacularly, adds a really nasty bug which everyone misses for a month or cant even find the file I find by searching.
I am also now experimenting with my own version of opencode and I change models a lot, and it helps me learn how each model fails at different tasks, and it also helps me figure out the most cost effective model for each task. I may have spent too much time on this.
> 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.
I think you're looking at it from the wrong angle. Wrestling the computer is stuff like figuring out how to recite the right incantation so Gradle will do a multi-platform fat bundle, and then migrate to the next major Gradle version. Unless you have a very specific set of kinks, tasks like these will make you want to quit your career in computers and pick up trash on the highway instead.
You very likely have some of these toil problems in your own corner of software engineering, and it can absolutely be liberating to stop having to think about the ape and the jungle when all you care about is the banana.
The hard part of software engineering, and indeed many other pursuits, is working out what it is you actually need to happen and articulating that clearly enough for another entity to follow your instructions.
Using English, with all its inherent ambiguity, to attempt to communicate with an alien (charitably) mind very much does /not/ make this task any easier if the thing you need to accomplish is of any complexity at all.
> Using English, with all its inherent ambiguity, to attempt to communicate with an alien (charitably) mind very much does /not/ make this task any easier if the thing you need to accomplish is of any complexity at all.
This just isn't the case.
English can communicate very simply a set of "if.. then.." statements and an LLM can convert them to whatever stupid config language with I'm dealing with today.
I just don't care if Cloudflare's wrangler.toml uses emojis to express cases or AWS's Cloudformation required some Shakespearean sonnet to express the dependencies in whatever the format of the day is.
Or don't get me started on trying to work out which Pulami Google module I'm supposed to use for this service. Ergh.
I can express very clearly what I want, let a LLM translate it then inspect the config and go "oh that's how you do that".
It's great, and is radically easier than working through some docs written by a person who knows what they are doing and assumed you do too.
Expressing "I want to build a Java app in a single file that I can execute on Windows, MacOS, and Linux" is absolutely straightforward and non-ambiguous in English, whereas it requires really a lot of arcane wizardry in build tooling languages to achieve the desired result.
Claude will understand and carry out this fairly complex task just fine, so I doubt you have actually worked with it yet.
Now we have to figure out how to recite the right incantation to Claude to get it to recite the right incantation to Gradle in an exchange redolent of "guess the verb" from old Adventure games. Best case if you get it wrong: nothing happens. Worst case: grue will eat you.
Sanchez's Law of Abstraction applies. You haven't abstracted anything away, just added more shit to the pile.
There’s no incantation though. You ask Claude in whatever terms feel right to you to do the thing, say "update the gradle config to build a multi platform jar", and it does make it happen.
No, it is not. What you are doing is something not too different from asking your [insert here freelance platform] hired remote dev to make an app and enter a cycle of testing the generated app and giving feedback, it is not wrestling the computer.
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/)
i like what software can do, i don't like writing it
i can try to give the benefit of the doubt to people saying they don't see improvements (and assume there's just a communication breakdown)
i've personally built three poc tools that proved my ideas didn't work and then tossed the poc tools. ive had those ideas since i knew how to program, i just didn't have the time and energy to see them through.
> 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.
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.
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.
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 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.
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.
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.
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.
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 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!
> 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"
The compiler reliably and deterministically produces code that does exactly what you specified in the source code. In most cases, the code it produces is also as fast/faster than hand written assembly. The same can't be said for LLMs, for the simple reason that English (and other natural languages) is not a programming language. You can't compile English (and shouldn't want to, as Dijkstra correctly pointed out) because it's ambiguous. All you can do is "commission" another
> Do you resent folks like us that do find it fun?
For enjoying it on your own time? No. But for hyping up the technology well beyond it's actual merits, antagonizing people who point out it's shortcomings, and subjecting the rest of us to worse code? Yeah, I hold that against the LLM fans.
That a coding agent or LLM is a different technology than a compiler and that the delta in industry standard workflow looks different isn’t quite my point though: things change. Norms change. That’s the real crux of my argument.
> But for hyping up the technology well beyond it's actual merits, antagonizing people who point out it's shortcomings, and subjecting the rest of us to worse code? Yeah, I hold that against the LLM fans.
Is that what I’m doing? I understand your frustration. But I hope you understand that this is a straw man: I can straw man the antagonists and AI-hostile folks but the point is the factions and tribes are complex and unreasonable opinions abound. My stance is that people can dismiss coding agents at their peril, but it’s not really a problem: taking the gcc analogy, in the early compiler days there was a period where compilers were weak enough that assembly by hand was reasonable. Now it would be just highly inefficient and underperformant to do that. But all the folks that lamented compilers didn’t crumble away, they eventually adapted. I see that analogy as being applicable here, it may be hard to see the insanity of coding agents because we’re not time travelers from 2020 or even 2022 or 3. But this used to be an absurd idea and is now very serious and highly adopted. But still quite weak!! Still we’re missing key reliability and functionality and capabilities. But if we got this far this fast, and if you realize that coding agent training is not limited in the same way that e.g. vanilla LLM training is by being a verifiable domain, we seem to be careening forward. But by nature of their current weakness, absolutely it is reasonable not to use them and absolutely it is reasonable to point out all of their flaws.
Lots of unreasonable people out there, my argument is simply: be reasonable.
No it’s certainly not, and if you do want to lump coding agents into blockchain and NFTs that’s of course your choice but those things did not spur trillions of dollars of infra buildout and reshape entire geopolitical landscapes and have billions of active users. If you want to say: coding agents are not truly a net positive right now, that’s I think a perfectly reasonable opinion to hold (though I disagree personally). If you want to say coding agents are about as vapid as NFTs that to me is a bit less defensible
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
What about a table saw with no guard, a wobbly blade, and directions from management to follow a faint line you'd have a hard time doing with a scroll saw?
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.
All parts of making a movie are fun. If you hire people who are passionate at each task, you will get 1000x better result. It may be 10 days late but better to be late than slop.
Thats not quite true. The “lone genius” type went against the grain and created something new while still showing some skill (well, that’s debatable in modern art).
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.”
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?
> 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?
I would call the designing of the building art, yes. But I wouldn’t call it construction.
I would also call designing a system to be fed into an LLM designing. But I wouldn’t call it programming.
If people are more into the design and system architecture side of development, I of course have no problem with that.
What I do find baffling, as per my original comment, is all the people saying basically “programming is way more fun now I don’t have to do it”. Did you even actually like programming to begin with then?
I do think a huge number of people are infatuated with the idea of programming but hate the act itself. I have tried to teach a lot of people to code and it is rare to find the person who is both enthusiastic and able to maintain motivation once they realize every single character matters and yes, that bracket does have to be closed.
Of course not everyone who programs AI style hate programming, but I do think your take explains a large chunk of zealotry: It has become Us v. Them for both sides and each is staking out their territory. Telling the vibe coder they are not programming hurts their feelings much like telling a senior developer all their accumulated experience and knowledge is useless if not today, for sure some day soon!
> I do think a huge number of people are infatuated with the idea of programming but hate the act itself. I have tried to teach a lot of people to code and it is rare to find the person who is both enthusiastic and able to maintain motivation once they realize every single character matters and yes, that bracket does have to be closed.
I think it's legitimate that someone might enjoy the act of creation, broadly construed, but not the brick-by-brick mechanics of programming.
Did the CNC lathe decide where to make the cuts based on patterns from real artists it was trained on to regurgitate a bland copy of real artists work?
I suspect that lots of developers who are sour on relying on AI significantly _would_ agree with most of this, but see the result of that logic leading to (as the article notes) "the skill of writing and reading code is obsolete, and it's our job to make software engineering increasingly entirely automated" and really don't like that outcome so they try to find a way to reject it.
"The skillset you've spend decades developing and expected to continue having a career selling? The parts of it that aren't high level product management and systems architecture are quickly becoming irrelevant, and it's your job to speed that process along" isn't an easy pill to swallow.
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.
Certainly not my intention. Some of my post is projection: I don't like the implications of the AI enthusiast stance, and I know I want "actually, AI can't fully take over the task of programming" to be true even though my recent experience with uses it to handle even moderately complex implementation has been quite successful.
I've also seen the opposition narrow in scope but not firmness over the last year from some coworkers while watching others outsource nearly all of their actual code interaction, and I think some of the difference is how invested they are in the craft of programming vs being able to ship something.
So, if you like the part AI is expected to take over and see it as part of your value, it makes sense that your threshold are higher for accepting that outcome as accurate. Seems like typical psychology rather than an attack.
If one is not writing code your ability to read code will degrade quickly and be reduced to a basic sanity check as to whether you need to add more constraints (prompts, tests, etc.). Anyone who thinks they can read code without writing code at a level needed to understand what is going on (for anything non-trivial) is fooling themselves.
Yep. I'd say it's an order of magnitude more effort to read code you haven't written too, compared to reading code you wrote. So there is approximately zero chance the people using AI to generate code are reading it at a level where they actually understand it, or else they would lose all of their supposed productivity gains.
The linked Claude generated script for giving more control over permissions in tool use is… typically Claude.
The code interleaves rules and control flow, drops side effects like “exit” in functions and hinges on a stack of regex for parsing bash.
This isn’t something I’ve attempted before but it looks like a library like bashlex would give you a much cleaner and safer starting point.
For a “throwaway” script like this maybe it’s fine, but this is typical of the sort of thing I’m seeing spurted out and I’m fascinated to see what people’s codebases look like these days.
Don’t get me wrong, I use CC every day, but man, you do need to fight it to get something clean and terse.
AI development for me is not fun. It may be faster and more productive, jury still out on that. But typing code and understanding each line has its advantages. AI also takes out a lot of creativity out of programming and climbing the abstractions isnt for everyone.
Do we want everyone to operate at PM level? The space for that is limited. Its easy to say you enjoy vibe coding when you are high up the chain but for most devs we are not as experienced or lucky to be able to feel stable when workflows change every day.
But I dont feel I have enough data to believe whether vibe coding or hand coding is better, I am personally doing tedious task with AI, and still writing code by hand all the time.
Also the author presents rewriting Numpy in rust as some achievement but the AIs most probably trained on Numpy and RustyNum, AI are best at copying the code so its not really a big thing.
None of these articles address how we'll go from novice to expert, as either self-taught or through the educational system, and all the bloggers got their proverbial "10k hours" before LLMs were a thing. IMO This isn't abstractions, the risk is wholesale outsourcing of learning. And no, 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.
Can someone tell me what the current thinking is on how we'll get over that gap?
> 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!
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.
The more I use AI, the more I think about the book Fooled By Randomness.
AI can take you down a rabbit hole that makes you feel like you are being productive but the generated code can be a dead end because of how you framed the problem to the AI.
Engineers need enough discipline to understand the problems they are trying to solve before delegating a solution to a stochastic text generator.
I don’t always like using AI but have found it helpful in specific use cases such as speeding up CI test pipelines and writing spec; however, someone smarter than me/more familiar with the problem space may have better strategies that I cannot of think of, and I have been fooled by randomness.
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.
Re audio, I have been working on a nice little tool called Claudio[0] which adds sounds to Claude Code in a nice configurable sort of way. It's still pretty new but it's a lot better than directly hooking to avplay :)
I disagree with them on the large PR section. I agree that we sometimes don’t review these in detail, but the thing that enables that for me is a trusted contributor explaining deterministically what they did. I renamed whatever variable, or I changed whatever script in all these places, I updated whatever lint rule and fixed all the errors, I moved whatever to a separate package.
All of these can create a diff across lots of files, but can be easily explained to a reviewer.
The problem is that I can’t trust an LLM to act deterministically the way I trust some people to. So I can’t just take that higher level view of “yep cool that sounds like a good idea” and skim the changes.
I think this take doesn’t take into account the slope of improvement we have seen from AI. Take Claude opus 4.5, I’ve seen dramatic improvements in the models ability to handle large context windows
Rather than spending iterations crafting precise permissions, why not just run with
--dangerously-skip-permissions
If run in a devcontainer[1][2], the worst thing that can happen is it deletes everything in the filesystem below the mounted repo. Recovery would entail checking out the repo again.
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.
> it at least nominally knows how to jailbreak out of containers
Source please. If it's contained (as in Claude runs INSIDE the container, not outside while having access to it) I don't understand how it technically could blue pill out of it. If it were to be able to leave the container then the container code would be updating accordingly to patch whatever exploit was found somehow. So I don't believe this but maybe I'm wrong, hence why I'm asking for a reference.
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.
>>I get it, you’re too good to vibe code. You’re a senior developer who has been doing this for 20 years and knows the system like the back of your hand.
>> [...]
>>No, you’re not too good to vibe code. In fact, you’re the only person who should be vibe coding.
All we have to do is produce more devs with 20 years of experience and we'll be set. :)
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".
> "I will never as long as I live understand the argument that AI development is more fun."
What I always find amusing are the false equivalences, where one or several (creative) processes involving the hard work that is a fundamental part of the craft get substituted by push-to-"I did this!1!!" slop.
How's the saying go? "I hate doing thing x. The only thing I hate more is not doing thing x". One either owns that, or one doesn't. So that is indeed not mysterious. Especially not in a system where "Fake it till you make it" has been and is advertised as a virtue.
Weird question. If a system you are using is intended to extract from you, and unwillfully and nonconsensually stealing your intellectual property because the unaccountable big companies do shady stuff (the "AI" companies) is it justified to use it for the productivity gains because it will 'eventually' get there anyway?
Does the potential gain as an early adopter make it morally ok.
Because thats what these tiered uses of these AI and how it's been getting better works imo. It got lots of training data from juniors and seniors using it the last 2 years, it got better. It gets more appealing and leverages human psychology and marketing to get higher level engineers to train it as it and the companies extract more data. It needs and gets more data from the people willfully complying and using it. Wondering if theres a game theory design for this conundrum - what typically happens in nature in these scenarios?
I'm so completely over these types of articles. Just as the AI techbros want to convince people that "the genie is out of the bottle" and that these services & practices are inevitable, it is also the case the the cohort of people who explicitly eschew using genAI is significant and growing. Nobody is being convinced reading this…like "wow, I vowed never to use genAI as a software developer, and then suddenly I read this article and now I've seen the light!"
> That being said, there are some serious costs and reasonable reservations to AI development.
Neither this nor the discussion here so far mentions ethics. It should.
According to latest reports AI now consumes more water than the global bottled water industry. These datacenters strain our grids and where needs can't be met they employ some of the least efficient ways to generate electricity generating tons of pollution. The pollution and the water problems are hitting poorer communities as the more affluent ones can afford much better legal pushback.
Next, alas, we can't avoid politics. The shadow that Peter Thiel and a16z (who named one of the two authors of the Fascist Manifesto their patron saints) casts over these tools is very long. These LLMs are used as a grand excuse to fire a lot of people and also to manufacture fascist propaganda on a scale you have never seen before. Whether these were goals when Thiel & gang financed them or not, it is undeniable they are now indispensable in helping the rise of fascism in the United States. Even if you were to say "but I am using code only LLMs" you are still stuffing the pockets of these oligarchs.
The harm these systems cause is vast and varied. We have seen them furthering suicidal ideation in children and instructing them on executing these thoughts. We have seen them generating non-consensual deepfakes at scale including those of children.
"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.
"We already do this today with human-written code. I review some code very closely, and other code less-so. Sometimes I rely on a combination of tests, familiarity of a well-known author, and a quick glance at the code to before saying "sure, seems fine" and pressing the green button. I might also ask 'Have you thought of X' and see what they say.
Trusting code without reading all of it isn't new, we're just now in a state where we need to review 10x more code, and so we need to get much better at establishing confidence that something works without paying human attention all the time.
We can augment our ability to write code with AI. We can augment our ability to review code with AI too."
Later he goes onto suggest that confidence is built via TDD. Problem is... if the AI is generating both code and tests, I've seen time and time again both in internal projects and OSS projects how major assumptions are incorrect, mistakes compound, etc.
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.
One of the things about "math" is how theorems need to be proven to work for all numbers. I remember reading a thought experiment decades ago about an alien mathematics which didn't prove a theorem formally but would consider it proven if it worked for all numbers up to some really large number. Perhaps even just some large number of spot checks. And statistically maybe that's a functional approach?
And that's what it feels like now. We have the "old school" developers who consider CS to be equivalent to math, and we have these other people like you mention who are happy if the code seems to work 'enough'. "Hackers" have been around for decades but in order to get anything real done, they generally had to be smart enough to understand the code themselves. Now we're seeing the rise of the unskilled hacker, thanks to AI...is this creating the next generation of script kiddies?
Yes, they don't care about the contents as long as the code appears to work correctly in the happy path, they ignore edge cases and bugs an mark the ticket as solved and move on, leaving an broken, unmaintainable mess in their wake.
These are exactly the types of people who LOVE ai because it produces code of similar quality an functionality that they would produce by hand.
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.
Let's not rewrite history. Somehow the counter point to these AI discussions seems to be some revisionist fantasy past where humans would only write perfect code at the height of the craft. That's just not true, there was plenty of shit code around before and business interests never cared one iota about "clean" code.
So no, we haven't gone from "making software as good and efficient as possible", that was always a niche.
I meant not just recently, not just because of AI but there was a time when we were required to write efficient code because of hardware limitations and inability to patch quickly. AI is still not a having a massive impact on software dev yet, but it benefits from last 2 decades of lowering standards.
"AI development is more fun. I do more of what I like (think, experiment, write) and less of what I don't like (wrestle with computers).
I feel both that I can move faster and operate in areas that were previously inaccessible to me (like frontend). Experienced developers should all be doing this. We're good enough to avoid AI Slop, and there's so much we can accomplish today."
If frontend was "inacessible" and AI makes it "accessible", I would argue that you don't really know frontend and should probably not be doing it professionally with AI. Use AI, yes but learn frontend without AI first. And his "Experienced developers should all be doing this" is ridiculous. He should be honest and confess that he doesn't like programming. He probably enjoys systems design or some sort of role involving product design that does not involve programming. But none of these people are "developers".
I don't care that AI development is more fun for the author. I wouldn't care if all the evidence pointed toward AI development being easier, faster, and less perilous. The externalities, at present, are unacceptable. We are restructuring our society in a way that makes individuals even less free and a few large companies even more powerful and wealthy, just to save time writing code, and I don't understand why people think that's okay.
>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.
Saying "well the world sucks so what's new" isn't a perspective a lot of folks are going to resonate with. Just because we can recognize troubling patterns from the past in the present doesn't mean we just volunteer to lie down and take a boot to the neck. Positive change is always possible. Always.
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 are also making all software much worse at the same time. I dont think every app needs AI but apparently they do. Notion used to be a Zen writing app back in the day, canva used to an app where you can do simple graphics without a complicated tools panel.
I think Pete's article last year made a good case for regarding this as the "horseless carriage" stage, i.e. growing pains around how to use a new technology effectively.
Or maybe it's analogous to the skeuomorphic phase of desktop software. Clumsy application of previous paradigm to new one; new wine in old bottles; etc.
Edit: on closer look, you've been breaking the HN guidelines so badly and so consistently that I've banned the account. Single-purpose accounts aren't allowed here in any case.
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.
My comment wasn't about you in particular but the industry as a whole.
Much of the software written historically is to automate stuff people used to do manually.
I'd wager you use email, editors, search engines, navigation tools and much more. All of these involved replacing real jobs that existed. When was the last time you consulted a city map?
Computers themselves replaced computers (yeah, a job title). Your medical software certainly automatizes someone else's job, otherwise no one will pay you to write them. You just don't care about them.
Or you do, but you believe it's worth it because your software helped more patients, or improved the overall efficiency and therefore created more demand and jobs - a belief many pro-AI people hold as well.
AIs don't generate junk. Engineers with little experience _think_ they generate junk. Or engineers on that bandwagon, which in my opinion is driven by denial or naivety
If you know what the fuck you're doing, they're incredible. Scary so.
Seems people read the blog but not the code, I looked at the stated rewrite of Numpy in Rust:
> As an introductory project, I rewrote Numpy in Rust. It was great fun.
That's not a rewrite at all it's just a wrapping of an existing linear algebra Rust library (faer, blas, etc..) with a more Numpy like API. It seems to me that every AI project I look at is just a mashup/wrapper over existing things. Where are the real bootstrapped new things with AI ? Is there any big OSS project (Linux kernel, postgresql, Django, whatever) with serious bugfixes or new features implemented by AI that we could look at ?
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 ?
>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.
Which does indicate that even if AI becomes good at coding, we will still need humans to glue all the AI stuff together.
yeah, I don't think the jenga tower is changing but the levels of abstraction will.
https://github.com/timescale/pg_textsearch
BM25 index for postgres, mostly written by a single (very smart) guy and Claude Code.
Incredible.
If I get production ready bm25 and incremental view maintenance in postgres, it really will do everything I care about.
Especially with the browser/client synch maintenance stuff people are working on.
I feel like we should pin this or something as a canonical counter to the now excruciatingly tired claim:
“Generative software code doesn’t work”
> 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).
Zed on Linux is buggy as hell. On macos it's somehow more stable. Maybe Zed is indeed a "good" example of Ai-coded products.
This is a thing you can credibly say only if you've never used a popular new non-mainline editor. Sublime Code was "buggy as hell" too; all new editors are. Editors are incredibly difficult to do well. And Zed is doing it on hard mode, cross-platform.
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...
There's a good thread in there highlighting the fact that a novice wouldn't be nearly as successful as the OP who has the experience to guide the LLM.
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
I get vibe-coders not having a good experience once the honeymoon is over. But I'm fascinated that a professional software developer could have such a different experience than I do.
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.
One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a lot more functionality while keeping dependencies minimal.
I haven't tried C or ASM yet, but it has been working very well with a C++ project I've been working on, and I'm sure it would do reasonably well with bare-bones C as well.
I'd be willing to bet it would struggle more with a lower-level language initially, but give it a solid set of guardrails with a testing/eval infrastructure and it'll get its way to what you want.
We used higher level programming languages because "Developer time is more expensive than compute time", but if the AI techbros are right, we are approaching the point where that is not going to be true.
It's going to take the same amount of time creating a program in C as it does in Python.
Pretty interesting take this. I wonder if there is a minimal state management we could evolve which would be sufficient for LLMs to use while still making it possible for a human to reason about the abstraction. It won't be as bloated as the existing ones we came up with organically however.
I mean, you're basically LLM-washing other people's code, then. All those UI components that other people wrote and at least expected attribution may not be libraries anymore, sure. But you've basically just copied and maybe lightly modified that code into your project and then slapped a sticker on it saying "mine." If you did that manually with open source code, you'd be in violation of the attribution terms almost all the licenses have in common. But somehow it's okay if the computer does it for you?
It is a gray area. What if you took Qt, removed macros, replaced anchoring with css for alignment, took all widget properties out into an entity component system and called it ET, could Trolltech complain? It is an entirely new design and nothing like they built. A ship of Theseus if you will.
The Ship of Theseus has nothing to do with the identity of the parts. That is not in question at all; they are explicitly different parts. The thought experiment is the question of the identity of the whole.
Qt in your example is a part. You're application is the whole. If you replaced Qt with WxWidgets, is your application still the same application?
But to answer your question, to replace Qt with you're own piecemeal code doesn't do anything more to Qt than replacing it with WxWidgets would: nothing. The Qt code is gone. The only way it would ship-of-theseus itself into "still being Qt, despite not being the original Qt" would be if Qt required all modifications to be copyright-assigned and upstreamed. That is absurd. I don't think I've ever seen a license that did anything like that.
Even though licenses like the GPL require reciprocal FOSS release in-kind, you still retain the rights to your code. If you were ever to remove the GPL'd library dependency, then you would no longer be required to reciprocate. Of course, that would be a new version of your software and the previous versions would still be available and still be FOSS. But neither are you required to continue to offer the original version to anyone new. You are only required to provide the source to people who have received your software. And technically, you only have to do it when they ask, but that's a different story.
The premise of your question is wrong. I would still write Python for most of my tasks even if I were just as fast at writing C or ASM.
Because the conciseness and readability of the code that I use is way more important than execution speed 99% of the time.
I assume that people who use AI tools still want to be able to make manual changes. There are hardly any all or nothing paradigms in the tech world, why do you assume that AI is different?
The promise of the original definition of vibe coding was you treating code as disposable, no more valuable than LLVM build cache.
You aren't supposed to make corrections, review it, or whatever.
But the LLM does, and some amount of conciseness/readability will help.
They've got good at C now. I can't speak for ASM.
Here's a C session that I found quite eye-opening the other day: https://gisthost.github.io/?1bf98596a83ff29b15a2f4790d71c41d...
I had it write a new stdlib implementation (wasm<->JS) for a custom web based fantasy console I'm writing.
It did ok at that.
We'll - Doom runs so ok enough for what I wanted anyway.
No, it's not a copy of other WASM stdlib implementations.
I pretty much do most of my AI coding in Rust. Although I do still use Python or Typescript where appropriate.
If you read on in the post you might be interested in the section titled
Drop Python: Use Rust and Typescript
https://matthewrocklin.com/ai-zealotry/#big-idea-drop-python...
It cuts to training data and effort. A lot of effort has been put in to optimize for python, even down to tokenization.
My small-program success story with genAI coding is pretty much the opposite of your claim. I used to use a bash script with a few sox instances piped into each other to beat-match and mix a few tracks. Couldn't use a GUI... Then came gpt-5, and I wanted to test it anyway. So I had it write a single-file C++ program that does the track database, offline mixing, limiter and a small REPL-based "UI" to control the thing. I basically had results before my partner was finished preparing breakfast. Then I had a lot of fun bikeshedding the resulting code until it felt like something I'd like to read. Some back and forth, pretending to have an intern and just reviewing/fixing their code. During the whole experience, it basically never generated code which wouldn't compile. Had a single segfault which was due to unclear interface to a C library. Got that fixed quickly.
And now, I have a tool to do a (shuffled if I want) beat-matched mix of all the tracks in my db which match a certain tag expression. "(dnb | jungle) & vocals", wait a few minutes, and play a 2 hour beat-matched mix, finally replacing mpd's "crossfade" feature. I have a lot of joy using that tool, and it was definitely fun having it made. clmix[1] is now something I almost use daily to generate club-style mixes to listen to at home.
[1] https://github.com/mlang/clmix
I don't get this. AI coders keep saying they review all the code they push, and your suggestion is to use even harder languages the average vibe coder is unable to understand, all in name of "performance"? Faster code maybe, and exponentially increasing the tech debt and amount of bugs that slips through.
It wasn't even long ago that we thought developer experience and capacity for abstraction (which is easier to achieve in higher level languages) was paramount.
> AI coders keep saying they review all the code they push
Those tides have shifted over the past 6 weeks. I'm increasingly seeing serious, experienced engineers who are using AI to write code and are not reviewing every line of code that they push, because they've developed a level of trust in the output of Opus 4.5 that line-by-line reviews no longer feel necessary.
(I'm hesitant to admit it but I'm starting to join their ranks.)
Isn't it also because LLMs are trained on existing software, and the programs we would write in Python or JS have few examples in C ?
Yes. That is what the commenter means by "mechanical reproduction" and "temporarily smoothed over due to larger datasets".
Because you want to modify those later instead of having read only blob?
Wouldn't the AI that wrote the original code be in a better position to modify it too?
Lets start a space station to squeeze a glass of juice.
That's a very good example.
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.
For some people, code == junk?
Depends on what it is, the quick bash script I write to verify something or the core of SaaS that's being launched have different levels of strictness, style, testing, etc.
Apparently not as much anymore!
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.
I use AI as a rubber duck to research my options, sanity-check my code before a PR, and give me a heads up on potential pain points going forward.
But I still write my own code. If I'm going to be responsible for it, I'm going to be the one who writes it.
It's my belief that velocity up front always comes at a cost down the line. That's been true for abstractions, for frameworks, for all kinds of time-saving tools. Sometimes that cost is felt quickly, as we've seen with vibe coding.
So I'm more interested in using AI in the research phase and to increase the breadth of what I can work on than to save time.
Over the course of a project, all approaches, even total hand-coding with no LLMs whatever, likely regress to the mean when it comes to hours worked. So I'd rather go with an approach that keeps me fully in control.
Yeah my guess is that it takes roughly the same amount of time regardless if it's AI agents or hand coding, the time just gets spent in different ways (writing vs reading for example).
> My personal favorite hooks though are these:
These are nice but it's even nicer when Claude is talking when it needs your attentionEasy to implement -> can talk to ElevenLabs or OpenAI and it's a pretty delightful experience
If you're on a Mac, it can speak the notification instead for more detail!
``` "hooks": { "Notification": [ { "hooks": [ { "type": "command", "command": "jq '.message' | say" } ] } ] } ```
thanks man! I've actually gone a bit further with hooks and speech synthesis
https://hooked.arach.dev/ and https://speakeasy.arach.dev/ - it's a fun setup
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
nice, next step is to write a custom function that derives a useful but repeatable message from the hooks and put a little cache in front the Eleven Labs message gen. For example: "In {Project}, Claude needs your permission to run {command}"
That way you can stay comfortably in the free plan with awesome voice messages
I have a different voice for my laptop compared to my main computer and can also pick per project
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 :)
The author presents a false dichotomy when discussing "Why Not AI".
Compilers are deterministic, making their generated assembly code verifiable (for those compilers which produce assembly code). "AI", such as "Claude Code (or Cursor)" referenced in the article, is nondeterministic in their output and therefore incomparable to a program compiler.One might as well equate the predictability of a Fibonacci sequence[0] to that of a PRNG[1] since both involve numbers.
0 - https://en.wikipedia.org/wiki/Fibonacci_sequence
1 - https://en.wikipedia.org/wiki/Pseudorandom_number_generator
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.
here you go, a prompt only library: https://github.com/dbreunig/whenwords
That's great. Here's "me" implementing a JS version of that library in one shot using Github Copilot and a 1 sentence prompt:
> Implement when.js as a simple, zero-dependency js library following SPEC.md exactly.
https://github.com/jncraton/whenwords/pulls
> 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....
>> 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.
My statement is of course a generalization due to its terseness and focuses on the expectation of repeatable results given constant input, excluding pathological definitions of nondeterminism such as compiler-defined macro values or implementation defects. Modern compilers are complex systems and not really my point.
> This leads to the point: in general do we care about this non-determinism?
> Most of the time, no we don't.
Not generally the type of nondeterminism I described, no. Nor the nondeterministic value of the `__DATE__` macro referenced in the StackOverflow link you provided.
> 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 is where the wheels fall off.
First, "most of the time" only makes sense when there is another disjoint group of "other times." Second, the preferred group defined is "non-deterministic [sic] output of an LLM is good enough", which means the "other times" are when LLM use is not good enough. Third, and finally, when use of an approach (or a tool) is unpredictable (again, excluding pathological cases) given the same input, it requires an open set of tests to verify correctness over time.
That last point may not be obvious, so I will extrapolate as to why it holds.
Assuming the LLM in use has, or is reasonably expected to have, model evolution, documents generated by same will diverge unpredictably given a constant prompt. This implies prompt evolution will also be required at a frequency almost certainly different than unpredictable document generation intrinsic to LLMs. This in turn implies test expectations and/or definitions having to evolve over time with nothing changing other than undetectable model evolution. Which means any testing which exists at one point in time cannot be relied upon to provide the same verifications at a later point in time. Thus the requirement of an open set of tests to verify correctness over time.
Finally, to answer your question of:
You can't, because what you describe is a multi-story brick house built on a sand dune.> Assuming the LLM in use has, or is reasonably expected to have, model evolution, documents generated by same will diverge unpredictably given a constant prompt.
So what?
You tell it once. It writes code.
You test that code, not the prompt.
> This leads to the point: in general do we care about this non-determinism?
> Most of the time, no we don't.
well that’s a sweeping generalisation. i think this is a better generalised answer to your question.
> It depends on the problem we’re trying solve and the surrounding conditions and constraints.
software engineering is primarily about understanding the problem space.
are 99% of us building a pacemaker? no. but that doesn’t mean we can automatically make the leap to assuming a set of tools known for being non-deterministic are good enough for our use case.
it depends.
> Once you accept that the next stage is accepting that most of the time the non-deterministic output of an LLM is good enough!
the next stage is working with whatever tool(s) is/are best suited to solve the problem.
and that depends on the problem you are solving.
> are 99% of us building a pacemaker? no. but that doesn’t mean we can automatically make the leap to assuming a set of tools known for being non-deterministic are good enough for our use case.
This seems irrelevant?
Either way hopefully you test the pacemaker code comprehensively!
That's pretty much the best case for llm generated code: comprehensive tests of the desired behaviour.
I suspect the argument is that both AI and a compiler enables building software at a higher level of abstraction.
Abstraction is only useful when it involves a consistent mapping between A and B, LLM’s don’t provide that.
In most contexts you can abstract the earth as a sphere and it works fine ex:aligning solar panels etc. Until you enter the realm of precision where treating the earth as a sphere utterly fails. There’s no realistic set of tests you can right where an unsupervised LLM’s output can be trusted to generate a complex system which works if it’s constantly being recreated. Actual compilers don’t have that issue.
>> 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.
automated tests are not verification. The "llm as a compiler" provides zero guarantees about the code.
A compiler offers absolute guarantees that what you write is semantically preserved, barring bugs in the compiler itself. An llm provides zero guarantees even with zero bugs in the llm's code.
>> A compiler offers absolute guarantees
I think one of the sibling comments addresses this myth rather neatly: https://news.ycombinator.com/item?id=46563383
tl;dr compilers are not fully deterministic either.
please point out where i said "deterministic".
I said guarantees that semantics are preserved.
I don't know what you are arguing, or why. Please follow the thread in its full context. Specifically, the argument the article author is making is that moving to a higher level of abstraction also cost developers the benefit of understanding the internals. Ultimately, that ended up not mattering very much.
The OP pushed back on this, saying compilers are deterministic and LLMs are not, and that lack of determinism makes LLM output unverifiable. I said the latter is not true because you can perform verification using tests. You claimed tests are not verification because LLMs don't preserve the semantics.
I'm not sure why semantics matter. LLMs providing no guarantees regarding the preservation of semantics is not important because you can guarantee the behavior of the generated code using tests. In most domains, this is sufficient. You tell the LLM to write code that does X, Y and Z, and then verify X, Y and Z using a test. That's it.
I will never as long as I live understand the argument that AI development is more fun. If you want to argue that you’re more capable or whatever, fine. I disagree but I don’t have any data to disprove you.
But saying that AI development is more fun because you don’t have to “wrestle the computer” is, to me, 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 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.
I am one of those, but that's why I went into the ops side of things and not dev, although the two sides have been merging for a while now and even though I deal with infrastructure, I do so by writing code.
I don't mind ops code though. I dislike building software as in products, or user-facing apps but I don't mind glue code and scripting/automation.
Don't ask me to do leetcode though, I'll fail and hate the experience the entire time.
i like delivering value, AI lets me do that better on low risk projects very fast
> I like delivering value
I understand where comedians get their source material now.
That is accurate for me. I have never enjoyed coding puzzles or advent of code. My version of that is diving into systems and software when it breaks. That is fun...as long as my job or income is not on the line
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.
Has anybody tried getting an LLM to pitch them an idea for software that they then implement themselves? I might actually try that now...
> I get zero joy out of wrestling build tools or figuring out deploy scripts to get what I've built out onto a server.
And for me (and other ops folks here I'd presume), that is the fun part. Sad, from my career perspective, that it's getting farmed out to AI, but I am glad it helps you with your side projects.
Yeah, that is one of my main uses for AI: getting the build stuff and scripts out of the way so that I can focus on the application code. That and brainstorming.
In both cases, it works because I can mostly detect when the output is bullshit. I'm just a little bit scared, though, that it will stop working if I rely too much on it, because I might lose the brain muscles I need to detect said bullshit.
Im super interested to know how juniors get a long. i have dealt with build systems for decades and half the time its just use google or stackoverflow to get past something quickly, or manually troubleshoot deps. now i automate that entirely. and for code, i know what good or not, i check its output and hve it redo anything t5hat doesnt pass my known stndards. It makes using it so much easier. the article is so on point
Also just.. boring code. Like I'm probably more anti-AI than most, but even I'll acknowledge it's nice to just be like... "hey this array of objects I have, I need sorted by this property" and just have it work. Or how to load strings from exotic character encodings. Or dozens of other bitchy little issues that drag software dev speed down, don't help me "grow" as a developer, and/or are not interesting to solve, full stop.
I love this job but I can absolutely get people saying that AI helps them not "fight" the computer.
I've always believed that the dozens of 'bitchy little issues' are the means to grow as a developer.
Once you've done it, you'll hopefully never have to do it again (or at worse be derivatives). Over time you'll have a collection of 'how to do stuff'.
I think this is the path to growth. Letting a LLM do it for you is equivalent to it solving a hard leetcode problem. You're not really taxing your brain.
>Letting a LLM do it for you is equivalent to it solving a hard leetcode problem. You're not really taxing your brain.
But things like "hey this array of objects I have, I need sorted by this property" are not hard leetcode problems
They're precisely the kind of tedious, but not taxing, problems that we prefer to farm out to someone else. Like asking a junior to do it.
My point is that it's tempting and irresistible (based on other comments in this thread) to move from basic attribute sorting, to basic CRUD, SQL queries, CSS/Tailwind, typescript error resolution then using it for Dijkstra, because why not?, it's so nice.
Then we're just puppetmasters pulling the strings (which some think this is the way the industry is going).
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.
Isn't that because the "best in class" LLM-enabled IDE or dev environment keeps changing every few months, or even more frequently if you're price conscious and want to use the most powerful coding models?
yep.. learning vim or all of the keybinds/tools at ones disposal in $jetbrains_editor would _actually_ make some peers 2x faster but alas..
Agreed but it's not even that. I worked with someone who was insanely fast with RubyMine. All the shortcuts were second-nature and shit just flew onto the screen. So generally, the argument would be to be really good with whatever editor you have. It also goes outside of that, like snippets are still very viable for lots of boilerplate.
At the same time, one of the best developers I worked with was a two-finger typist who had to look at the keyboard. But again, I don't care if you're going to use AI (well, that's not entirely true but not going to get into it) but the tone of this article that "You should learn it, " I take issue with.
You can write 10000 lines of code without AI in a day? Impressive
~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.
It feels like this to me too, whenever I give it a try. It's like a button you can push to spend 20 minutes and have a 50/50 chance of either solving the problem with effortless magic, or painfully wasting your time and learning nothing. But it feels like we all need to try and use it anyway just in case we're going to be obsolete without it somehow.
> But it feels like we all need to try and use it anyway just in case we're going to be obsolete without it somehow.
I feel this exactly. I’ve been one of the biggest champions of the tech in my org in spite of the frequent pain I feel from it.
If it doesn't work, it's an annoyance and you have to argue with it. If it does work, it's one more case where maybe with the right MCP plumbing and/or a slightly better model you might not be needed as part of this process. Feels a bit lose-lose.
> I also can’t stop myself from using Claude Code and the like.
just.. uninstall it? i've removed all ai tooling from both personal+work devices and highly recommend it. there's no temptation to 'quickly pull up $app just to see' if it doesn't exist
It’s become a core expectation at work now (Meta). If I’m not actively using it, then I’ll be significantly dinged in performance reviews. Honestly, it’s forced me to consider going to work elsewhere.
It does _feel_ like the value and happiness will come some versions down the road when I can actually focus on orchestration, and not just bang my head on the table. That’s the main thing that keeps me from just removing it all in personal projects.
You could use ai in read only mode and use it as a rubber duck.
I do this a lot and it’s super helpful.
sorry to hear. perhaps you could goodhart's law it and setup some background cron that simulates usage
Is this coming from the hypothesis / prior that coding agents are a net negative and those who use them really are akin to gambling addicts that are just fooling themselves?
The OP is right and I feel this a lot: when Claude pulls me into a rabbit hole, convinces me it knows where to go, and then just constantly falls flat on its face and we waste like several hours together, with a lot of all caps prompts from me towards the end. These sessions last in a way that he mentions: "maybe its just a prompt away from working"
But I would never delete CC because there are plenty of other instances where it works excellent and accelerates things quite a lot. And additionally, I know we see a lot of "coding agents are getting worse!" and "METR study proves all you AI sycophants are deluding yourselves!" and I again understand where these come from, agree with some of the points they raise, but honestly: my own personal perception (which I argue is pretty well backed up by benchmarks and by Claude's own product data which we don't see -- I doubt they would roll out a launch without at least one or more A/B tests) is that coding agents are getting much better, and that as a verifiable domain these "we're running out of data!" problems just aren't relevant here. The same way alphago gets superhuman, so will these coding agents, it's just a matter of when, and I use them today because they are already useful to me.
no, this is coming from the fact OP states they are miserable. that is unsustainable. at the end of the day the more productive setup is the one that keeps you happy and in your chair long term, as you'll produce nothing if you are burnt out.
Oh sure of course, I missed that part!
This is definitely the feeling i get. Sometimes it works amazingly well that I think "Oh may be the hype was right all along, have I become the old guy yelling at claude?" but the other times it fails spectacularly, adds a really nasty bug which everyone misses for a month or cant even find the file I find by searching.
I am also now experimenting with my own version of opencode and I change models a lot, and it helps me learn how each model fails at different tasks, and it also helps me figure out the most cost effective model for each task. I may have spent too much time on this.
The gambling analogy has been brought up before.
https://pivot-to-ai.com/2025/06/05/generative-ai-runs-on-gam...
> 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.
I think you're looking at it from the wrong angle. Wrestling the computer is stuff like figuring out how to recite the right incantation so Gradle will do a multi-platform fat bundle, and then migrate to the next major Gradle version. Unless you have a very specific set of kinks, tasks like these will make you want to quit your career in computers and pick up trash on the highway instead.
You very likely have some of these toil problems in your own corner of software engineering, and it can absolutely be liberating to stop having to think about the ape and the jungle when all you care about is the banana.
The hard part of software engineering, and indeed many other pursuits, is working out what it is you actually need to happen and articulating that clearly enough for another entity to follow your instructions.
Using English, with all its inherent ambiguity, to attempt to communicate with an alien (charitably) mind very much does /not/ make this task any easier if the thing you need to accomplish is of any complexity at all.
> Using English, with all its inherent ambiguity, to attempt to communicate with an alien (charitably) mind very much does /not/ make this task any easier if the thing you need to accomplish is of any complexity at all.
This just isn't the case.
English can communicate very simply a set of "if.. then.." statements and an LLM can convert them to whatever stupid config language with I'm dealing with today.
I just don't care if Cloudflare's wrangler.toml uses emojis to express cases or AWS's Cloudformation required some Shakespearean sonnet to express the dependencies in whatever the format of the day is.
Or don't get me started on trying to work out which Pulami Google module I'm supposed to use for this service. Ergh.
I can express very clearly what I want, let a LLM translate it then inspect the config and go "oh that's how you do that".
It's great, and is radically easier than working through some docs written by a person who knows what they are doing and assumed you do too.
Expressing "I want to build a Java app in a single file that I can execute on Windows, MacOS, and Linux" is absolutely straightforward and non-ambiguous in English, whereas it requires really a lot of arcane wizardry in build tooling languages to achieve the desired result.
Claude will understand and carry out this fairly complex task just fine, so I doubt you have actually worked with it yet.
You've clearly never had to work with Gradle. :-)
Now we have to figure out how to recite the right incantation to Claude to get it to recite the right incantation to Gradle in an exchange redolent of "guess the verb" from old Adventure games. Best case if you get it wrong: nothing happens. Worst case: grue will eat you.
Sanchez's Law of Abstraction applies. You haven't abstracted anything away, just added more shit to the pile.
There’s no incantation though. You ask Claude in whatever terms feel right to you to do the thing, say "update the gradle config to build a multi platform jar", and it does make it happen.
This is not your average abstraction layer.
Understanding memory and using a debugger is hard but I'll take that over telling an AI my grandma will die if it does something wrong.
>AI "development" /is/ wrestling the computer.
No, it is not. What you are doing is something not too different from asking your [insert here freelance platform] hired remote dev to make an app and enter a cycle of testing the generated app and giving feedback, it is not wrestling the computer.
If I wanted to manage, I would have gone into management.
For people like me, anything that makes the computer more human-like is a step in the wrong direction, and feels much more like wrestling.
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/)
yeah, well said
i like what software can do, i don't like writing it
i can try to give the benefit of the doubt to people saying they don't see improvements (and assume there's just a communication breakdown)
i've personally built three poc tools that proved my ideas didn't work and then tossed the poc tools. ive had those ideas since i knew how to program, i just didn't have the time and energy to see them through.
> 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.
->...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.
Well, so far I tried using LLMs in hobby/open source/personal projects where I get benefits of code working.
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.
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 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.
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.
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.
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.
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.
Computers are one big kludge pile because they can do anything.
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!
> 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"
The compiler reliably and deterministically produces code that does exactly what you specified in the source code. In most cases, the code it produces is also as fast/faster than hand written assembly. The same can't be said for LLMs, for the simple reason that English (and other natural languages) is not a programming language. You can't compile English (and shouldn't want to, as Dijkstra correctly pointed out) because it's ambiguous. All you can do is "commission" another
> Do you resent folks like us that do find it fun?
For enjoying it on your own time? No. But for hyping up the technology well beyond it's actual merits, antagonizing people who point out it's shortcomings, and subjecting the rest of us to worse code? Yeah, I hold that against the LLM fans.
That a coding agent or LLM is a different technology than a compiler and that the delta in industry standard workflow looks different isn’t quite my point though: things change. Norms change. That’s the real crux of my argument.
> But for hyping up the technology well beyond it's actual merits, antagonizing people who point out it's shortcomings, and subjecting the rest of us to worse code? Yeah, I hold that against the LLM fans.
Is that what I’m doing? I understand your frustration. But I hope you understand that this is a straw man: I can straw man the antagonists and AI-hostile folks but the point is the factions and tribes are complex and unreasonable opinions abound. My stance is that people can dismiss coding agents at their peril, but it’s not really a problem: taking the gcc analogy, in the early compiler days there was a period where compilers were weak enough that assembly by hand was reasonable. Now it would be just highly inefficient and underperformant to do that. But all the folks that lamented compilers didn’t crumble away, they eventually adapted. I see that analogy as being applicable here, it may be hard to see the insanity of coding agents because we’re not time travelers from 2020 or even 2022 or 3. But this used to be an absurd idea and is now very serious and highly adopted. But still quite weak!! Still we’re missing key reliability and functionality and capabilities. But if we got this far this fast, and if you realize that coding agent training is not limited in the same way that e.g. vanilla LLM training is by being a verifiable domain, we seem to be careening forward. But by nature of their current weakness, absolutely it is reasonable not to use them and absolutely it is reasonable to point out all of their flaws.
Lots of unreasonable people out there, my argument is simply: be reasonable.
> Norms change. That’s the real crux of my argument.
Novelty isn't necessarily better as a replacement of what exists. Example: blockchain as fancy database, NFTs, Internet Explorer, Silverlight, etc.
No it’s certainly not, and if you do want to lump coding agents into blockchain and NFTs that’s of course your choice but those things did not spur trillions of dollars of infra buildout and reshape entire geopolitical landscapes and have billions of active users. If you want to say: coding agents are not truly a net positive right now, that’s I think a perfectly reasonable opinion to hold (though I disagree personally). If you want to say coding agents are about as vapid as NFTs that to me is a bit less defensible
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
What about a table saw with no guard, a wobbly blade, and directions from management to follow a faint line you'd have a hard time doing with a scroll saw?
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.
All parts of making a movie are fun. If you hire people who are passionate at each task, you will get 1000x better result. It may be 10 days late but better to be late than slop.
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.
Thats not quite true. The “lone genius” type went against the grain and created something new while still showing some skill (well, that’s debatable in modern art).
It shaves yaks for me. I appreciate that.
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
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?
> 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?
I would call the designing of the building art, yes. But I wouldn’t call it construction.
I would also call designing a system to be fed into an LLM designing. But I wouldn’t call it programming.
If people are more into the design and system architecture side of development, I of course have no problem with that.
What I do find baffling, as per my original comment, is all the people saying basically “programming is way more fun now I don’t have to do it”. Did you even actually like programming to begin with then?
I do think a huge number of people are infatuated with the idea of programming but hate the act itself. I have tried to teach a lot of people to code and it is rare to find the person who is both enthusiastic and able to maintain motivation once they realize every single character matters and yes, that bracket does have to be closed.
Of course not everyone who programs AI style hate programming, but I do think your take explains a large chunk of zealotry: It has become Us v. Them for both sides and each is staking out their territory. Telling the vibe coder they are not programming hurts their feelings much like telling a senior developer all their accumulated experience and knowledge is useless if not today, for sure some day soon!
> I do think a huge number of people are infatuated with the idea of programming but hate the act itself. I have tried to teach a lot of people to code and it is rare to find the person who is both enthusiastic and able to maintain motivation once they realize every single character matters and yes, that bracket does have to be closed.
I think it's legitimate that someone might enjoy the act of creation, broadly construed, but not the brick-by-brick mechanics of programming.
Did the CNC lathe decide where to make the cuts based on patterns from real artists it was trained on to regurgitate a bland copy of real artists work?
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? "
I suspect that lots of developers who are sour on relying on AI significantly _would_ agree with most of this, but see the result of that logic leading to (as the article notes) "the skill of writing and reading code is obsolete, and it's our job to make software engineering increasingly entirely automated" and really don't like that outcome so they try to find a way to reject it.
"The skillset you've spend decades developing and expected to continue having a career selling? The parts of it that aren't high level product management and systems architecture are quickly becoming irrelevant, and it's your job to speed that process along" isn't an easy pill to swallow.
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.
Certainly not my intention. Some of my post is projection: I don't like the implications of the AI enthusiast stance, and I know I want "actually, AI can't fully take over the task of programming" to be true even though my recent experience with uses it to handle even moderately complex implementation has been quite successful. I've also seen the opposition narrow in scope but not firmness over the last year from some coworkers while watching others outsource nearly all of their actual code interaction, and I think some of the difference is how invested they are in the craft of programming vs being able to ship something. So, if you like the part AI is expected to take over and see it as part of your value, it makes sense that your threshold are higher for accepting that outcome as accurate. Seems like typical psychology rather than an attack.
> "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.
If one is not writing code your ability to read code will degrade quickly and be reduced to a basic sanity check as to whether you need to add more constraints (prompts, tests, etc.). Anyone who thinks they can read code without writing code at a level needed to understand what is going on (for anything non-trivial) is fooling themselves.
As if reading books was enough to make you an author.
Yep. I'd say it's an order of magnitude more effort to read code you haven't written too, compared to reading code you wrote. So there is approximately zero chance the people using AI to generate code are reading it at a level where they actually understand it, or else they would lose all of their supposed productivity gains.
Yeah if people were good at reading code we wouldn't have the whole LGTM meme where the reviewer gives up as soon the PRs is bigger than 500 lines.
I actually don't think they would agree with most of this. Why would you think that?
The linked Claude generated script for giving more control over permissions in tool use is… typically Claude.
The code interleaves rules and control flow, drops side effects like “exit” in functions and hinges on a stack of regex for parsing bash.
This isn’t something I’ve attempted before but it looks like a library like bashlex would give you a much cleaner and safer starting point.
For a “throwaway” script like this maybe it’s fine, but this is typical of the sort of thing I’m seeing spurted out and I’m fascinated to see what people’s codebases look like these days.
Don’t get me wrong, I use CC every day, but man, you do need to fight it to get something clean and terse.
https://gist.github.com/mrocklin/30099bcc5d02a6e7df373b4c259...
AI development for me is not fun. It may be faster and more productive, jury still out on that. But typing code and understanding each line has its advantages. AI also takes out a lot of creativity out of programming and climbing the abstractions isnt for everyone.
Do we want everyone to operate at PM level? The space for that is limited. Its easy to say you enjoy vibe coding when you are high up the chain but for most devs we are not as experienced or lucky to be able to feel stable when workflows change every day.
But I dont feel I have enough data to believe whether vibe coding or hand coding is better, I am personally doing tedious task with AI, and still writing code by hand all the time.
Also the author presents rewriting Numpy in rust as some achievement but the AIs most probably trained on Numpy and RustyNum, AI are best at copying the code so its not really a big thing.
None of these articles address how we'll go from novice to expert, as either self-taught or through the educational system, and all the bloggers got their proverbial "10k hours" before LLMs were a thing. IMO This isn't abstractions, the risk is wholesale outsourcing of learning. And no, 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.
Can someone tell me what the current thinking is on how we'll get over that gap?
> 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.
The more I use AI, the more I think about the book Fooled By Randomness.
AI can take you down a rabbit hole that makes you feel like you are being productive but the generated code can be a dead end because of how you framed the problem to the AI.
Engineers need enough discipline to understand the problems they are trying to solve before delegating a solution to a stochastic text generator.
I don’t always like using AI but have found it helpful in specific use cases such as speeding up CI test pipelines and writing spec; however, someone smarter than me/more familiar with the problem space may have better strategies that I cannot of think of, and I have been fooled by randomness.
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.
Re audio, I have been working on a nice little tool called Claudio[0] which adds sounds to Claude Code in a nice configurable sort of way. It's still pretty new but it's a lot better than directly hooking to avplay :)
[0]: https://claudio.click
I disagree with them on the large PR section. I agree that we sometimes don’t review these in detail, but the thing that enables that for me is a trusted contributor explaining deterministically what they did. I renamed whatever variable, or I changed whatever script in all these places, I updated whatever lint rule and fixed all the errors, I moved whatever to a separate package.
All of these can create a diff across lots of files, but can be easily explained to a reviewer.
The problem is that I can’t trust an LLM to act deterministically the way I trust some people to. So I can’t just take that higher level view of “yep cool that sounds like a good idea” and skim the changes.
Ah, Human beings! Famous for their determinism, reliability, and for not making logical errors!
There are some that I trust more than I trust any LLM!
Who knew that these massive high-dimensional probability distributions would drive us insane
I think this take doesn’t take into account the slope of improvement we have seen from AI. Take Claude opus 4.5, I’ve seen dramatic improvements in the models ability to handle large context windows
Rather than spending iterations crafting precise permissions, why not just run with
If run in a devcontainer[1][2], the worst thing that can happen is it deletes everything in the filesystem below the mounted repo. Recovery would entail checking out the repo again.1. (conventional usage) https://code.visualstudio.com/docs/devcontainers/containers
2. (actual spec) https://containers.dev/
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.
> it at least nominally knows how to jailbreak out of containers
Source please. If it's contained (as in Claude runs INSIDE the container, not outside while having access to it) I don't understand how it technically could blue pill out of it. If it were to be able to leave the container then the container code would be updating accordingly to patch whatever exploit was found somehow. So I don't believe this but maybe I'm wrong, hence why I'm asking for a reference.
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.
Claude will only ever ask if it is allowed to connect to the domain name, so if it got a malicious link from a web search, you’re SOL anyway.
atleast you get one prompt, with --dangerously-skip-permissions you get no prompts
>>I get it, you’re too good to vibe code. You’re a senior developer who has been doing this for 20 years and knows the system like the back of your hand.
>> [...]
>>No, you’re not too good to vibe code. In fact, you’re the only person who should be vibe coding.
All we have to do is produce more devs with 20 years of experience and we'll be set. :)
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...
I did double quote it, but you're right—I should have made it clear.
I clicked out of the article since it starts out with a contradiction.
Experienced engineers can successfully vibe code? By definition it means not reading the output.
If you’re not reading your output, then why does skill level even matter?
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?
the time spent reading threads like this is better spent on buying lottery.
> "I will never as long as I live understand the argument that AI development is more fun."
What I always find amusing are the false equivalences, where one or several (creative) processes involving the hard work that is a fundamental part of the craft get substituted by push-to-"I did this!1!!" slop.
How's the saying go? "I hate doing thing x. The only thing I hate more is not doing thing x". One either owns that, or one doesn't. So that is indeed not mysterious. Especially not in a system where "Fake it till you make it" has been and is advertised as a virtue.
Weird question. If a system you are using is intended to extract from you, and unwillfully and nonconsensually stealing your intellectual property because the unaccountable big companies do shady stuff (the "AI" companies) is it justified to use it for the productivity gains because it will 'eventually' get there anyway?
Does the potential gain as an early adopter make it morally ok.
Because thats what these tiered uses of these AI and how it's been getting better works imo. It got lots of training data from juniors and seniors using it the last 2 years, it got better. It gets more appealing and leverages human psychology and marketing to get higher level engineers to train it as it and the companies extract more data. It needs and gets more data from the people willfully complying and using it. Wondering if theres a game theory design for this conundrum - what typically happens in nature in these scenarios?
I'm so completely over these types of articles. Just as the AI techbros want to convince people that "the genie is out of the bottle" and that these services & practices are inevitable, it is also the case the the cohort of people who explicitly eschew using genAI is significant and growing. Nobody is being convinced reading this…like "wow, I vowed never to use genAI as a software developer, and then suddenly I read this article and now I've seen the light!"
> That being said, there are some serious costs and reasonable reservations to AI development.
Neither this nor the discussion here so far mentions ethics. It should.
According to latest reports AI now consumes more water than the global bottled water industry. These datacenters strain our grids and where needs can't be met they employ some of the least efficient ways to generate electricity generating tons of pollution. The pollution and the water problems are hitting poorer communities as the more affluent ones can afford much better legal pushback.
Next, alas, we can't avoid politics. The shadow that Peter Thiel and a16z (who named one of the two authors of the Fascist Manifesto their patron saints) casts over these tools is very long. These LLMs are used as a grand excuse to fire a lot of people and also to manufacture fascist propaganda on a scale you have never seen before. Whether these were goals when Thiel & gang financed them or not, it is undeniable they are now indispensable in helping the rise of fascism in the United States. Even if you were to say "but I am using code only LLMs" you are still stuffing the pockets of these oligarchs.
The harm these systems cause is vast and varied. We have seen them furthering suicidal ideation in children and instructing them on executing these thoughts. We have seen them generating non-consensual deepfakes at scale including those of children.
For a senior engineer, some very odd takes here:
"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.
"We already do this today with human-written code. I review some code very closely, and other code less-so. Sometimes I rely on a combination of tests, familiarity of a well-known author, and a quick glance at the code to before saying "sure, seems fine" and pressing the green button. I might also ask 'Have you thought of X' and see what they say.
Trusting code without reading all of it isn't new, we're just now in a state where we need to review 10x more code, and so we need to get much better at establishing confidence that something works without paying human attention all the time.
We can augment our ability to write code with AI. We can augment our ability to review code with AI too."
Later he goes onto suggest that confidence is built via TDD. Problem is... if the AI is generating both code and tests, I've seen time and time again both in internal projects and OSS projects how major assumptions are incorrect, mistakes compound, etc.
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.
One of the things about "math" is how theorems need to be proven to work for all numbers. I remember reading a thought experiment decades ago about an alien mathematics which didn't prove a theorem formally but would consider it proven if it worked for all numbers up to some really large number. Perhaps even just some large number of spot checks. And statistically maybe that's a functional approach?
And that's what it feels like now. We have the "old school" developers who consider CS to be equivalent to math, and we have these other people like you mention who are happy if the code seems to work 'enough'. "Hackers" have been around for decades but in order to get anything real done, they generally had to be smart enough to understand the code themselves. Now we're seeing the rise of the unskilled hacker, thanks to AI...is this creating the next generation of script kiddies?
Yes, they don't care about the contents as long as the code appears to work correctly in the happy path, they ignore edge cases and bugs an mark the ticket as solved and move on, leaving an broken, unmaintainable mess in their wake.
These are exactly the types of people who LOVE ai because it produces code of similar quality an functionality that they would produce by hand.
Sloopers
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.
Let's not rewrite history. Somehow the counter point to these AI discussions seems to be some revisionist fantasy past where humans would only write perfect code at the height of the craft. That's just not true, there was plenty of shit code around before and business interests never cared one iota about "clean" code.
So no, we haven't gone from "making software as good and efficient as possible", that was always a niche.
I meant not just recently, not just because of AI but there was a time when we were required to write efficient code because of hardware limitations and inability to patch quickly. AI is still not a having a massive impact on software dev yet, but it benefits from last 2 decades of lowering standards.
AI Development is good for those who want to do it. But not a terminal career decision for those who don't.
"AI development is more fun. I do more of what I like (think, experiment, write) and less of what I don't like (wrestle with computers).
I feel both that I can move faster and operate in areas that were previously inaccessible to me (like frontend). Experienced developers should all be doing this. We're good enough to avoid AI Slop, and there's so much we can accomplish today."
If frontend was "inacessible" and AI makes it "accessible", I would argue that you don't really know frontend and should probably not be doing it professionally with AI. Use AI, yes but learn frontend without AI first. And his "Experienced developers should all be doing this" is ridiculous. He should be honest and confess that he doesn't like programming. He probably enjoys systems design or some sort of role involving product design that does not involve programming. But none of these people are "developers".
I don't care that AI development is more fun for the author. I wouldn't care if all the evidence pointed toward AI development being easier, faster, and less perilous. The externalities, at present, are unacceptable. We are restructuring our society in a way that makes individuals even less free and a few large companies even more powerful and wealthy, just to save time writing code, and I don't understand why people think that's okay.
>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.
Saying "well the world sucks so what's new" isn't a perspective a lot of folks are going to resonate with. Just because we can recognize troubling patterns from the past in the present doesn't mean we just volunteer to lie down and take a boot to the neck. Positive change is always possible. Always.
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 are also making all software much worse at the same time. I dont think every app needs AI but apparently they do. Notion used to be a Zen writing app back in the day, canva used to an app where you can do simple graphics without a complicated tools panel.
I think Pete's article last year made a good case for regarding this as the "horseless carriage" stage, i.e. growing pains around how to use a new technology effectively.
AI Horseless Carriages - https://news.ycombinator.com/item?id=43773813 - April 2025 (478 comments)
Or maybe it's analogous to the skeuomorphic phase of desktop software. Clumsy application of previous paradigm to new one; new wine in old bottles; etc.
[flagged]
> Disgusting work
Please don't do this here. Thoughtful criticism is fine on this site but snark and name-calling are not.
https://news.ycombinator.com/newsguidelines.html
Edit: on closer look, you've been breaking the HN guidelines so badly and so consistently that I've banned the account. Single-purpose accounts aren't allowed here in any case.
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.
I've spent my 20 year career working largely in medical software. The only jobs I've been replacing are pancreas that stop functioning correctly.
Maybe don't speak for all of us.
My comment wasn't about you in particular but the industry as a whole.
Much of the software written historically is to automate stuff people used to do manually.
I'd wager you use email, editors, search engines, navigation tools and much more. All of these involved replacing real jobs that existed. When was the last time you consulted a city map?
Computers themselves replaced computers (yeah, a job title). Your medical software certainly automatizes someone else's job, otherwise no one will pay you to write them. You just don't care about them.
Or you do, but you believe it's worth it because your software helped more patients, or improved the overall efficiency and therefore created more demand and jobs - a belief many pro-AI people hold as well.
The job used to be the patients'. Manually managing type 1 diabetes isn't a fun job. Try reading Think like a pancreas for the fun details.
Patient outcomes are significantly better with modern technology.
> You just don't care about them.
Yeah, okay.
AIs don't generate junk. Engineers with little experience _think_ they generate junk. Or engineers on that bandwagon, which in my opinion is driven by denial or naivety
If you know what the fuck you're doing, they're incredible. Scary so.
One man’s trash is another man’s treasure.
I thought the article was going to be about AI zealotry but it was just AI zealotry.
Yup.