I found myself working mostly at the requirements and architecture level, but do not give up proper code-review, creating skills along the way that maintain conventions.
Exactly this. I got into this field because designing programs and writing code is enjoyable. I'm probably behind on using AI and need to get more up to speed, but I never want to stop coding by hand.
> I'm probably behind on using AI and need to get more up to speed
Same.
My difficulty is that for the past 8 years I've been working for (tiiiiny) SaaS business where I don't have anyone I can simply ask in-person "hey, can you show me how to 'do' all this newfangled AI agentic team coding?"; so my only direct-exposure is with the painful Copilot sidebar chat, which I now find myself allergic to.
So let's see elsewhere: while searching online for some (reputable) "agentic coding courses" my results are for the same kind of people who used to run those dodgy coding-camps from 10 years ago. I'm having difficulty finding resources for practicing SWEs like myself wanting a continuing-professional-development course experience, not a get-rich-by-buying-my-course video library from a contemptable AI booster
Even more surprisingly, my local major university (UW.edu) doesn't seem to offer any certificate courses for getting into agentic development either[1] despite offering courses on C++, Six Sigma, and actual ML/AI courses. It's maddening. I can't be the only one with this problem...
I don't understand this. A skill critical to software engineering is learning how to learn. Just download Claude Code (or open alternative) and try to make things.
See how it fails or succeeds. Look at the supported features, try them out, think about how you might use them in your workflow.
I'm not anxious about my codebase; I'm anxious about all the fun parts being sucked out of my job as though I'm being promoted from IC to management - and given the inevitability of progress I can see how my new role as an agent shepherd, too, could be obsoleted in the near-future.
...so I've been avoidant of the whole thing ever since 2023, burying my head in the sand to avoid those feelings of anxiety and uncertainty-about-the-future, and it now makes it difficult for me to engage with the topic head-on.
Ah, well... I can't say that there's any real hope.
I dove in in ~2023, and I'm about as deep in it as one can be. The better I get at it, and the better the agents get, the less time I spend even doing what I do - one prompt will often take 3+ hours. I often keep 8+ agents churning for the whole workday (and leave them running when I leave, too, and it's very often that they'll work from 4pm to midnight or later). I was responsible for 499 commits last week (very little new functionality, though), and I felt pretty useless at the end of it. I keep thinking I should code something, because coding feels productive in comparison, but going by results, it's pretty far from economical to write code by hand, and quickly approaching as bad as shipping goods by foot.
Depends on the day. Mostly playing with the applications I'm developing to try and find gaps or rough edges, or reading over code and developing further AI tooling when I find disgusting code (to try to detect/fix/prevent disgusting code of that nature). Also, talking to coworkers to learn about the products we build and the business we're in.
Burke Holland has a few good videos that helped me. For example this on agents[1]. He uses Copilot but the principles are similar for Claude Code, Codex, OpenCode and other harnesses:
So far in the LLM coding revolution I still feel like it's software development. I just work with systems on the level of features and architecture instead of flow control statements. Some day we might lose that too, but I think it will take a while.
> I just work with systems on the level of features and architecture instead of flow control statements.
That's kinda at the level I enjoy though - where I get to think-through things when figuring out exhaustiveness and correctness; introducing refinement-types into a codebase that's previously nothing but ints-and-strings; and trying out new and cutting-edge language-features directly.
I know I can prompt Claude etc into trying to do those things, but from what I've seen from other people doing it the result is somewhat of a mess - or just plain inelegant.
-----
May I ask how well Claude/Copilot/etc works with FP languages instead? So far - and back in early 2024 - I've only messed-around with asking ChatGPT to generate Haskell programs and the results were hallucinated gibberish.
Can't comment on FP, haven't touched it since SMLNJ in the late 90s. I fear my mind is now congealed in OOP paradigms and the threshold to FP is too high.
Anyway I can say this - the free web interface to ChatGPT in 2024 vs what you get with agent harnesses and the latest large models now is like comparing a wombat fetus to a college graduate.
Get one of the 20 or so dollar subscriptions, install Claude code, codex or similar and start by explaining what program you want to make and which language you want to do it in. Have it make a plan first, and do some back-and-forth to refine it until you're ready to let it implement.
If your experience is from ChatGPT two years ago I think you will be floored by the results, even in Haskell.
In a way it is cheating, as it is all built on countless copyright infringements and non-consensual use of other people's works.
Only that businesses have decided it is OK as long as they are benefitting to steal from everyone else, and basically force us to be the acting hand in all of it, or threaten us with starvation (no job, no income).
If you're also happy getting paid for it, then the company will just stop paying you. If you rely on such income to have a visa, you'll 100% sure to accept that you're forced into this and you will give up coding, or else.
One of the things businesses tend to not understand is, that if you take the fun out of the activity, you also lose the passion of the people performing the activity, no matter how many times actors at the job fake passion in front of higher ups. If you lose the passion, what you will be left with it mediocre development and shoddy software.
Maybe that's "enough" for the business to survive. But it surely won't be the reason it succeeds. It can still succeed for other factors though, but the business has given up on one path to success, which is making better software than the competition.
Seems like there’s broadly two ways to use LLMs for coding - either as a way to generate the same code you would have written but faster, or as an opaque program-generator where you have no idea what the code is doing. One of these methods results in roughly the same amount of understanding and the other one radically less.
> For example, have you ever seen an agent follow the boy scout rule? Where they leave code better than they found it? And would you WANT them to try to do this?
Yes, it's in the rules; run profiles, check code coverage, do a critical review, post the report and follow up tasks. 90% of people I've worked with did not follow these boy scout rules nearly as well as today's frontier LLMs.
That quote is the lead in to an example I talk about after this quote illustrates what I often see.
> Agents bias to making the current change as safely as possible. I had a situation in a previous codebase where one morning, pre-caffeinated, my meat brain mentioned using browser local storage. So some random state was managed in local storage. Everything else through a backend database. When I looked at the code, the amount of wrapping and indirection to preserve this idiotic human mistake probably tripled the LoC. Agents can amplify our one-off bad decisions by being so conservative.
You can of course solve this many ways. And many of boils down to just how a particular humans brain works. Some will solve this by not reading code. Some will read / write code.
Whatever works for you is great. But many there is upside to the precision of not having code intermediated through the LLM for many.
Why is this even a legit question? I need to keep writing code to stay relevant, not to forget my craft, be able to review code... So many reasons. AI doesn't change a thing.
Before my time ppl mostly did things in asm, I bet the vast majority of people reading this have never touched assembly and will never have any reason to. This is quickly becoming true of most "code". AI has changed that.
One way to "stay relevant" would be to admit that.
assembly is compiled deterministically so you don't really need to look at it, LLMs though can write a variety of things at random based on the prompt. It is not the same.
Note as some may be confused by the "1 hour ago" with comments older than that: this submission was rescued by dang when a previous discussion existed: https://news.ycombinator.com/item?id=48883341
fwiw I think the rationale behind it is counterproductive because the only difference between a OP submitting their article link and someone else submitting their article link is internet points.
Apparently it's not obvious to everyone, but if you can't write code, you can't review it. I do know people, and companies, that says: "So what, we ask Claude to write the code, Codex will then do the review". The thing that then strikes me as odd is that they still ask for the code in Python, Java, or some other high level language.... Why? Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much. They still want to be able to read the code. So they need developers that can read, debug and reason about the code, yet they don't want to give them the training that's required to do this?
They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.
I'm as hateful of LLMs hollowing out the job market as the next guy, but the reality is the frontier LLMs are really good at writing anything that's been done and documented on the Internet a million times and unfortunately most of what software devs have been doing the last couple decades is shitting out cookie cutter CRUD apps.
I have my doubts about whether the state of the industry is going to advance as long as we're having LLMs do all the creation, but that's another diatribe.
Without a revolutionary new platform to build apps on that no one has ever developed for before, there is basically no reason to believe there is any software left that has some business or economic value that hasn't already been written.
When Gutenberg invented the printing press, he could not have predicted the teleprompter. Now that code is easy to generate, it’s plausible that we will use much, much more of it than before.
It’s also a bit ironic to imagine that we’re at the end of new software ideas on a site owned(?) by YC.
it's also plausible that with an ability to generate as much code as we want with little effort, we will quickly discover how much code we actually need, and then plateau at that point.
Personally, I think we've already reached that point.
Even at YC, I have not really seen any startup doing anything interesting where their main value prop is enabled by new proprietary code that does stuff no one else can already do.
Are teleprompters a net positive achievement? They were needed for live television, they will be superseded I guess by AI generated news avatars. And 24-hour news coverage is in the business of generating content non-stop, to sell advertisements, regardless if there are newsworthy events or not, the machine never stops producing.
It's the end of history. What could we possibly discover about a series of technologies that are already nearly 100 years old now?
I've heard people say that various things are "solved" now because of LLMs too -- programming included. This implies we've "solved" thinking. I'm worried about these sentiments.
Mature tech evolves more slowly. Think about cars, there's nothing new about them any more. But wait, what about electic cars? Aren't they a new thing? And driverless cars. And soon flying taxis. Automobiles are an old invention but they are still evolving.
The reason the evolution of cars has slowed down so much is basically regulatory compliance.
With the current ongoing revolution in home manufacturing (starting with 3D printing; currently there is a lot of work done in home CNC machining), it would be easily possible to get a huge leap towards "print your own car".
The reason why you see nothing of this is basically red tape.
This is probably true in the consumer facing software space. But in business, industry, and academia, often there are novel data generated by some new or refined process. And this needs new software that correctly handles both the nature of these new data and meet the goals the data is collected to advance. This sort of software is also usually poorly represented in training sets, if represented at all.
this implies that the only thing that can change what needs doing are technology platforms, which about 6000 years of human civilization would indicate is not the case.
>They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.
I'm disputing this. You can have a training corpus in assembly as big as any other language: just feed the compiled result(in assembly) of the CRUD apps to the LLMs.
> They don't have Claude write assembly because there is no training corpus on people making CRUD apps in assembly.
I suspect that despite its translation abilities, this is true, but I'd like to see it do things in languages that are more or less appropriate for tasks to see how much the training corpus matters vs. its ability to translate. Assembly is a bit of an extreme example because you're either writing it as close to C as possible (C is essentially portable assembly) or you're writing complex, unreviewable code that happens to work. And who know if it's been trained on register allocation, or resorts to doing everything on the stack because it works.
Not really, assembly shows you what the machine instructions actually are. In C you have loops, functions structs. All things that make no sense in assembly.
Loops (conditional JMPS - JE/JNE/JZ/JNZ/JB/JNB.. and a dozen others) and functions (CALL, RET) exist in assembly. Goto is there too (all JMPs). C makes assembly sense.
Oh that's an interesting thought. Goto's are considered harmful, because holy hell as a human trying to understand and reason about code, the spaghettifcation if someone else used gotos all over the place and I have to reconstruct their thought process just doesn't sound like fun. But if we're no longer writing code by hand (which, I gotta be honest, I'm using AI to write a lot of code for me these days), then does that still matter? If a human isn't going to have to understand the code, can we get more performance out of existing systems by considering goto's useful?
Compilers only really use them for things like break and the end if blocks. There isn't much to gain by being able to execute anything arbitrarily, and then go...where? There might be places here and there within a function where compilers already take advantage of it, but I doubt it's useful in the way you think.
I assume there's a clear technical reason why GOTO is harmful, it adds to the complexity of the code, makes it harder to understand and fix and evolve. Wouldn't the same difficulties affect the LLMs ability to understand and fix and evolve the code as well?
As a human with a human level of working memory, the number of things I can keep in my head and map to concepts and functions is unfortunately limited. An AI running on an Nvidia supercomputer has higher limitations on what it can hold in its working memory, so could theoretically handle more than my human brain can.
goto is already useful as an end-of-function cleanup. You pop one at the end of each function (the naming is local to the function) and that's the place where you free ram if the pointer's not null and close the file if the handle is not null and so on.
Then you don't have to litter all of your if/else clauses with hundreds of memory frees and cleanups - you just "goto"
The fact that this is controversial to some people just shows how rules like "Dont use goto" become stupid - if one is trying to make code simpler then there are cases were not using it is the more confusing and error prone choice.
As for "can we now do anything" well if you don't ever need to debug "anything" then yes and if you have any small doubts about your LLM then no.
Both points are specious. C disassembly is usually not an orthogonal translation of the structures in the code, usually due to optimisation.
> In C you have loops, functions structs. All things that make no sense in assembly.
One can reasonably infer that a loop will roughly translate to some type of conditional jump instruction. Function structs are just pointers and call instructions. The former point was that there is little runtime getting in the way of how the constructs could be expressed, and a long time ago it may have been the truth, but not for modern compilers.
You’re getting down voted, but it would really be nice if they rebuilt the thing in Rust or something like that. I’m just tired of these enormous JavaScript bundles pretending to be desktop apps. Especially when we need to squeeze as much juice as possible out of our machines.
There’s a very real dichotomy at play here. Position 0: humans depend upon AI. Position 1: AIs depend upon humans.
At first blush, it seems achingly obvious that position 1 is true, whilst position 0 is a false play by con artists.
Well, at first blush I agree! But first blushes are notorious for being famous last words (blushes).
You see, we always knew that the tool shapes the hand. That is, as we use computational (discrete) devices, we ourselves become more computational, discrete.
But what we did not anticipate is that the tool would fool others as the ACTUAL HAND. I am so fooled. Daily.
My friends. Does technique encompass being? Answer me this!
I have a personal game framework that I have LLMs write games in, which is in AssemblyScript. AssemblyScript is certainly closer to TypeScript than it is to WebAssembly, but it's still this thing where the host shares some big chunk of memory with the script and you pick some memory locations to read and write as your means of exposing APIs, and there's not a lot of training data on games written in AssemblyScript and even less in my game framework specifically (none) - and the LLM does an excellent job.
I guess since fable has learnt deeply about 10+(maybe 100+) popular programming languages, it can just easily reason about the new 101st programming language.
As soon as human software engineers are Ubered away from the field, it will ramp the price up to that of a human software engineer or more, have no doubt.
claude helped me build a functional visual modem (using the cameras and microphones/speakers) for mac/iPhone in about a day and <100 prompts. i’ve worked on mobile apps once 10 years ago and have never built one from scratch. i've built a handful of UIs in 20 years on different platforms. my actual work was mostly in systems software. so it would have probably taken me weeks to months to build this from scratch. it would have cost substantial money to outsource this and iterate on ui and core algo as i did.
i've been curious about the feasibility of this concept for quite some time and now i have an actual example to study and measure and hack on, for a fraction of the cost of my pro sub. it wasn’t trivial, i doubt a non-swe could get it done in that time, but i'm a pretty happy customer overall.
It's also conveniently forgetting that AI was trained on the whole internet, a corpus of code including every garbage solution in SO wrong answers or random junior blogs. I didn't see any claim AI could select "best practices" from their sources, so putting AI to correct another AI has high chances of statistically selecting the same wrong solution, because that was just a common thread in those old posts they used as reference.
I think you're pretty wrong here, but I'm no expert so anyone who wants to correct me please do so.
As I understand it, there's post-training step that does exactly that, they get real developers to select good and bad code and help the AI figure that out. AFAIK it's the reason why Claude was able to leap-frog OpenAI in coding last year, they did this refinement step a lot better.
And now they've taught the older models this, they can use existing models to bootstrap the newer models without humans involved, and bring humans in to just assess the trickier stuff.
Claude's coding efficiency is largely due to their control plane governing the actual execution of the model - rules, evaluators and basically looping over results. Not related to the model training or fine tuning.
Fable wrote a pretty decent test suite covering typical Prolog programs, including things with non-trivial execution patterns like "append" that do complex backtracking on multiple branches. And I've run a modest number of test queries by hand, trying a few things. It's entirely possible that there's a bug there somewhere. But it's better than I would have done on the first try, implementing a Prolog interpreter in assembly. And I've worked on actual production compilers a few times.
I am honestly not happy about the way that models can now just take what should have be a fun multi-weekend project and knock out in a couple of hours. But I'm not going to pretend that Fable is stupid, or that it did a bad job on any of the test projects I gave it. It struggles more on big, messy real-world code bases, absolutely.
WebAssembly has as much to do with assembly as JavaScript has with Java. I highly doubt the "slightly easier" and my attempts with LLM's and assembly so far were largely disappointing, but I also think there is no compelling reason this has to be the case.
I have written assembly for about 5 different processors, including 65C02s, 680x0s, cute little DSP3210s that managed the CPU cache manually, utterly cursed TI320C40s, and (of course) a bit of Intel. WebAssembly is simpler than some of these architectures in some ways.
But it's not that much simpler. And once you add the WASM GC stuff, WebAssembly gets weird. It's a Harvard architecture with separate value memory, linear memory, GC memory and "tables", all accessible in completely ways, with a weird mandatory type system (especially for the GC stuff). And the docs are often terrible. And yes, I've also written WebAssembly by hand.
So yes, I would, overall, classify WebAssembly as "slightly easier". But not dramatically so. And the training data for actually writing non-trivial things by hand isn't that great, not compared to something like Intel assembly.
(Don't talk to me about TI320C40 assembly. If Fable can one-shot a Prolog interpreter written using that without finding a reference manual, it's time to hang up my hat and learn to make goat cheese.)
And the amount of logic needed to understand code, including how to fix it or modify it further depends on how complicated the code-structure is.
I wonder about this: Does LLM write better code in a better language?
Humans often have more difficulty fixing existing code than reqriting it from scratch, and un-structured un-constrained code would be a big reason for that.
But maybe it doesn't apply to an LLM if it always rewrites all code from scratch?
LLMs are designed to imitate humans not compilers. Hardly anyone is capable of writing modern optimized Assembly code by hand outside of a few snippets here and there (not in a reasonable amount of time at least)
I have a few personal projects, i let codex do all the code - i do the thinking and testing.
One time, something didn't work as expected - its the first time it happened with this project. I read through the section of code and it was perfectly readable and well-written.
Turned out a plugin wasn't effecting the audio, so i just got it to pad some blank audio onto the beginning before processing it, then remove it at the end of the process. That fixed the issue, there was nothing wrong with the code but my ability to think laterally is what made it work.
We're getting to the stage where you can just ask them to write code and they will do what you want, and it writes good code. Its up to you to test everything beyond the internal tests it writes.
I’m finding it all boils down to cognitive differences.
Some people find code easier to read than the English description. It’s more precise and many experienced devs can scan it and know what’s happening
Many other people can’t read code. Or they find English easier to read than code.
Thats not a knock on anyone. Maybe the latter will rule the world because the former focuses too much on irrelevant details. Or maybe me there are just different types of problems that need differing levels of attention to detail.
The code tells you HOW, the English should be telling you WHY. Both are usually needed IMO. Even a tiny bit of "why" can be extremely helpful to understanding in my experience. I don't want generated AI garbage that merely describes the code - I want the reason the whole thing exists and what was wanted by the person who wrote it.
AKA "Direction", which obviously the LLMs follows, and suck at coming up with by themselves. Humans though, when they have purposeful direction and manages to execute it, ends up creating a (small) beautiful life-changing revolution almost.
Pretty sure Casey Muratori and Demetri Spanos cover why in one of their videos online.
Less about “trusting” the llm and more about how complex it is to work with binaries due to machine code being different per machine and hard to interpret the context of the code as well as offsets.
In that sense because high level languages come with the ability to add context to what code does. It’s like the understanding a human has when given decompiled C code ghidra gives you vs C source code a developer wrote.
Also the compiler helps the llm write “compiled / working code”, if it just spat out machine code it most likely not even run at all.
But yea generally if you can’t write code at all, reviewing it is even harder.
No defense for not writing or reading code if want to call yourself a software engineer or programmer.
However I do think there is reason to use Java or Python (as much as I loathe both) they have GC, and it'd be a lot easier for AI to fuck up memory safety in something like assembly or C.
One has to program computers to be a computer programmer. If one just prompts LLMs, they are a software prompter. I think both can fit under the title of a software developer or perhaps even software engineer.
Ask the ai what the game theory is for training employees... the Nash equilibrium is under training and self funded certification/training for devs in low trust environments.
> Apparently it's not obvious to everyone, but if you can't write code, you can't review it.
There's more to it than that: writing is thinking. If you stop writing code, you aren't thinking anymore.
Many argue that they're now thinking at a higher level (maybe they weren't before?), but, guess what, that high-level design can be done better by the LLM than by you anyway. It's only temporary.
I think writing is summarizing your thoughts outside of thinking. Thinking happens at least for me before I write.
I know what I want to do before I write, and writing is just one medium to get it out there. If there was a faster way, to get my thoughts there I would use that.
> Thinking happens at least for me before I write. I know what I want to do before I write, and writing is just one medium to get it out there. If there was a faster way, to get my thoughts there I would use that.
A lot of people observe that their thoughts get better when they do the work to write them out.
Yes, it gets better, but not because of writing, it gets better because of building, playing it out and observing the results. The trial and error. It wouldn't matter whether I built via voice to command AI or wrote the code myself.
E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
> Yes, it gets better, but not because of writing, it gets better because of building, playing it out and observing the results. The trial and error. It wouldn't matter whether I built via voice to command AI or wrote the code myself.
This is a poor argument. The trial and error is the LLMs trial and error of your intention (ironically driven by you), not your trial and error.
It's like saying "It wouldn't matter if I instructed an LLM to solve my trigonometry problem or if I wrote the the solution myself; either way I'm learning trig".
> E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
What exactly are you needed for in this scenario, other than saying "make me $PRODUCT"? The LLm is going to be a lot better at architecture than you are. Your role is limited to A/B testing the result for human use.
You’re not wrong, but there’s a nuance here. More often than not our thoughts fool us into thinking we have something clear when we have only a vague idea of what you want to do.
I kinda [wrote about this before](https://dielsonsales.github.io/2023/05/11/starting-a-new-blo...) but the takeaway is that writing forces you to structure your thoughts, giving them a final shape and enables you to notice flaws or gaps in your own thinking process. It’s impossible to do this without writing.
It would be good to have specific situations here I guess, otherwise it's quite abstract, and I'm not sure what to make of it.
As to your post, I think rather than writing it's the act of pressuring yourself to figure the thing out that is making you more knowledgeable about the thing.
You are putting it out publicly out there so you really want to be certain that you are correct, and therefore you do a lot of research.
If you wanted to be accurate and prove a point, the motivation mechanism could vary, but also the eventual communication mechanism could vary. It doesn't necessarily have to be in writing, it could be a live debate or simply something else you built. The writing or the product are end product, but the process of wanting to produce something is what made you research and to understand.
by writing code by hand - you're the author & editor at the same time.
if you're skilled enough - you quickly get to the desired state vs the llm which while might produce a lot of code - but it likely won't give the end state you desire.
an analogy - Jason Fried gave - producing software by llm's is like bragging you're a photographer by pressing the shutter button on an automatic camera.
while the art of photography - is about producing the single perfect photo - that communicates the photographers intent (what they want the world to see & experience).
likewise in software - what we make should be deliberate.
Just so you know, most people nowadays can create decent pictures or even movies with smartphone. Not automatic camera, not polaroid, not Polaroid camera, not analog Canon FD, not cardbox camera.
Where will you put a line between photography and pressing button?
I don't write code anymore and I doubt I ever will ever again.
On the flipside I review exponentially more code than ever before.
>Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much
It's not "not trusting" the llm its that the llm has been undergoing reinforcement learning is on coding. Plus generating assembly is extremely token inefficient.
Perhaps new devs should write all their code by hand until they feel comfortable doing that. Then, they can start using LLMs gradually, just a little bit at first, all the way to fully AI generated code.
However, that would just make the difference in productivity between junior and senior developers even more pronounced! It’s really difficult to see how things will play out in the future without junior developers disappearing, causing a slow death of the profession. LLMs will probably never be good enough to do everything a developer needs to do: understand and improve or clean up requirements, consider future needs, test outside the box, evaluate performance and decide where and when to improve it…
Yeah it's a real catch-22. I think you're right though, LLM tech will keep up just enough to replace that lost workforce, till some day development as we know it will no longer exist, perhaps when the code becomes too abstract and complex for normal humans to ever hope to maintain without automation, similar to what happened to most assembly developers when the compiler came along.
If nobody can review it that's fine since we'll be generating at least 50k LOC per day and nobody could review that anyhow. We can just get every other LLM model to review the output. What can go wrong?
> Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much
No, people do advocate for this. It may simply not be as portable however as something that is high level able to be compiled to assembly for many machines.
It's the logical outcome of believing that human skills aren't important and that you can "think at a higher level". You can't spend all your time thinking at a higher level if you cannot fully trust the output and the assembler argument is just taking the thing to an extreme to make that point.
churning out assembly code would cost far more in tokens, wouldn't make financial sense for the improved performance which doens't matter that much for most use cases.
This isn’t obvious at all. Editors can evaluate and improve the work of writers even without being bestselling novelists themselves. Richard Williams coached his girls to world championships without winning one himself. Roger Ebert never even made a movie.
No one gets hurt or dies when roger ebert whiffs on a movie review. Now imagine I tell you I've built a bridge. I have no idea how to perform the necessary calculations. I have no idea how to verify the necessary calculations. But, I've built you a bridge. It kind of looks like a bridge. Will you drive across it?
Not all software is mission critical. But some software is.
First of all, obviously there's more training data on high level languages than assembly / compiled binaries. Secondly, Python, Java or even C is portable to another device. You know, one of the main points of high level languages: that you don't have to rewrite your app from scratch each time you want to change the machine it runs on.
Thirdly, compilers also do type checking and other static analysis and dynamic checks (array length etc). So it's not only got more guardrails against "mistakes" by the LLM, but it's also most likely "easier" for the LLM to "reason" about (in the sense that LLMs can reason).
If we look at the progress made from ChatGPT 3.5 (Nov 2022) and up to today...shoot, I'm really starting to wonder if we'll even be reviewing code in 4 years.
And I'm not saying this as some sort of AI maximalist. If progress keeps up, I seriously doubt software engineering and development will, as we know it today, will be a thing in the next 5-10 years. Maybe humans will be left with designing the UI, but everything else will be abstracted away and AI will be doing all the actual work behind the scenes.
You’re assuming that progress will continue at the same rate (it’s plateaud a bit as far as I can tell, I can look for sources tomorrow but am on phone now :))
& I think it’s fairly demonstrated that the industry isn’t profitable for training ever increasingly huge models, which get exponentially more expensive each iteration
I wonder, LLMs have progressed at great speed, because they have learned to duplicate what humans did and recorded in the documents and source-code that became the training materials for the LLMs. But now that humans don't write any more code, there is no new learning materials for the LLMs. There are no new things for them to learn. Therefore I expect they will plateau, the progress is no longer so fast.
And maybe we'll get something like a Mad Cow Disease, when AI "eats its own brains". To avoid that from happening we will need continued human inputs, and review.
Already loathing the idea of not even being able to directly blame humans and their incapability for making shitty websites, that require JS for everything, including typing a text in an input field. If we get there and the LLMs build the same crap, dialed up to 110, because even more suits want first and foremost fancy looks, rather than function, and because that's the majority of training data corpus they learned from ... I might have an existential crisis coming in. The web already sucks hard enough. At least let me blame incapable human beings for this situation.
>It’s our job to build the software factory - not just the software. Software engineers maintain the assembly line allowing anyone to prompt for a change and ship immediately.
The job of the software engineer increasingly becomes to make himself unnecessary: to empower the nontechnical business users to do as much as reasonably possible, without his/her intervention.
This has, of course, been the dream of computing, since its inception! And the true aim of every "high level" or "beginner friendly" (looking at you javascript!) language.
But finally, now that the computer actually speaks English (and is beginning to stop making completely insane errors), it gradually becomes feasible.
This isn't the first or even the tenth attempt at making computer programming accessible to everyone. Remember COBOL? COBOL made the computer speak English. It didn't help.
A specification detailed enough to control every aspect of the resulting product is called a program. Compilers are AI. The prevalence of compilers hasn't harmed the programming industry at all, quite the opposite.
I think if you’re doing it right, the core of your code should be the simplest expression of the underlying business logic. Of course there’s always going to be supporting layers, and maybe those don’t need to be reviewed. But if you haven’t read the code, there’s an extent to which you don’t know the business logic.
What I mean by "talk to the agent in code" really is to code. Establish patterns. Then have the agent use those patterns as reference for other areas of the project.
"Hey Claude, can you please make a full matrix of tests according to the following pattern and parameters? Thanks." That's 15-20 minutes of work that can run in the background while I do something else.
First you write a programming language in which the language primatives are the business logic primatives, then you write a trivial program that describes what the business does in the new language.
I was thinking about an experience I had recently, and how it relates to my feelings about AI... And it bummed me out a lot.
So I took over an open source project called Omnivore. It's a reading app in the vein of Pocket. The hosted version used pdf-lib to inject some functionality into the pdf viewer. Namely, highlighting, note taking, and storing location. pdf-lib is a licensed application, so when taking it to fully self-hosted this needed to change.
I migrated it over to pdf.js. And I went through the entire process. I added all the functionality bit by bit. It didn't take exceptionally long, maybe 1-3 days. But that process was really satisfying. I found a bug, fixed it, and then found a stackoverflow issue where someone was also experiencing the same issue and suggested the fix. https://stackoverflow.com/questions/59151218/pdfjs-error-on-...
I'm pretty sure an ai could have done all of this. And therein lies my fear and my upset with AI. Not only would it have robbed me of that experience, but it shows that I have in a way been devalued. Because I do think that took a level of skill. And now that's gone...
If you’re not writing code it won’t be long until you get to a point where your agent won’t be able to dig you out of whatever hole you’ve dug for yourself and then you are fubar because you’ve just completely forgotten how.
I write organic code in 2026 because I do not have a choice. Which, honestly, I am thankful for most of the time. My employer has no LLM mandates nor do they supply us an LLMs to use.
In my personal life, I cannot justify more than a $20 sub per month. I only use the Web Chat anyway. Shelling out $100-$200 a month for a sub in which I would get little to no ROI is a poor choice. Besides, I've never hit the limit on my $20 a month plan either.
The day I am forced to prompt LLMs all day, every day is the day I am cashing out of programming as a career. Though to be clear, I have no opposition towards anyone that uses LLMs, and think they are fantastic tools when used appropriately. (I love them as a StackOverflow replacement, and have learned a lot from going back and forth with LLMs).
> Not because agents are worse at coding that[sic] humans.
And then the whole article shows tangible reasons where the agents are truly worse at code than humans. Code never is just the text. If intelligence you have is not truly general, you cannot expect things like clarifying wider context, hierarchically ordering knowledge based on criteria and producing consistent results despite transfer learning and retraining.
And no, we are not even close to the multimodal capabilities of human brain to hierarchy encode and reproduce knowledge. Otherwise the correct "reasonable" economic action would be genociding all humans, and I'm pretty sure that this is what billionaires effectively want out of AI.
Every time I read some take about keeping up one's skills when using agents people get so tantalisingly close to the obvious answer, and then fall short.
If the tools are making you worse, don't use the tools.
"Instead, we’re switching to this wrong-headed mindset that coding agents are like compilers. That mindset gives us permission to ship terribly written code. Agents aren’t compilers - they’re more like freshly onboarded interns."
I feel this statement these days during code reviews. I know some amazing engineers whose output lately just isn't the same.
The relevant question is who is going to pay you to write code manually. It's something that's increasingly hard to justify. The answer is of course that people are not paying for code to be written or generated but for some problem to be solved. Whoever does that with the least amount of drama and cost gets the business. And using AI tools just allows for compressing the timelines a bit in a way that is hard to ignore.
Most code out there isn't all that great. I've been in this industry since the nineties. There are a lot of not so great software engineers doing mediocre work. People are romanticizing how great and magnificent their code is (or used to be). The reality of manually crafted code is of course a lot less flattering. Many code bases become hard to maintain over time and are riddled with bugs. And it's not like sloppy code is a new thing. Poorly executed software projects have been very common for a long time. That's not going to go away.
You seem to assume that people still have an inherent advantage here. Mostly those sectors compensate for well documented human failures with very rigid and expensive processes and testing. And of course despite that, stuff still goes wrong occasionally.
I actually think AI based automation is going to be a key enabler in those kinds of strict environments as well. Recent work on identifying e.g. security bugs seems to be resulting in a lot of improvement that has somehow escaped decades of human scrutiny. With good quality harnesses (manual or automated), I don't see any big objection against using generated code here.
There are ways humans have an advantage. Not in the line by line code, but in the experience of having the whole mental model in your head.
Writing some code with the whole context in your head is the human advantage.
I’m not precious about that code. Maybe it needs to be rewritten by an agent. Or we could build good abstractions so it’s trivial to see the system. We could also use systems that by their design force us + agents away from security, performance, etc
198 comments
[ 4.4 ms ] story [ 105 ms ] threadSame.
My difficulty is that for the past 8 years I've been working for (tiiiiny) SaaS business where I don't have anyone I can simply ask in-person "hey, can you show me how to 'do' all this newfangled AI agentic team coding?"; so my only direct-exposure is with the painful Copilot sidebar chat, which I now find myself allergic to.
So let's see elsewhere: while searching online for some (reputable) "agentic coding courses" my results are for the same kind of people who used to run those dodgy coding-camps from 10 years ago. I'm having difficulty finding resources for practicing SWEs like myself wanting a continuing-professional-development course experience, not a get-rich-by-buying-my-course video library from a contemptable AI booster
Even more surprisingly, my local major university (UW.edu) doesn't seem to offer any certificate courses for getting into agentic development either[1] despite offering courses on C++, Six Sigma, and actual ML/AI courses. It's maddening. I can't be the only one with this problem...
[1] https://www.pce.uw.edu/search?type=certificate&programType=c...
See how it fails or succeeds. Look at the supported features, try them out, think about how you might use them in your workflow.
Before you know it, you'll be proficient.
You have to learn how to self-teach.
Doesn't have to be stressful. Plan to throw away whatever happens. Do it in a VM if your nerves demand it. No reason it can't be fun.
...so I've been avoidant of the whole thing ever since 2023, burying my head in the sand to avoid those feelings of anxiety and uncertainty-about-the-future, and it now makes it difficult for me to engage with the topic head-on.
I dove in in ~2023, and I'm about as deep in it as one can be. The better I get at it, and the better the agents get, the less time I spend even doing what I do - one prompt will often take 3+ hours. I often keep 8+ agents churning for the whole workday (and leave them running when I leave, too, and it's very often that they'll work from 4pm to midnight or later). I was responsible for 499 commits last week (very little new functionality, though), and I felt pretty useless at the end of it. I keep thinking I should code something, because coding feels productive in comparison, but going by results, it's pretty far from economical to write code by hand, and quickly approaching as bad as shipping goods by foot.
So far in the LLM coding revolution I still feel like it's software development. I just work with systems on the level of features and architecture instead of flow control statements. Some day we might lose that too, but I think it will take a while.
[1] https://www.youtube.com/watch?v=-BhfcPseWFQ
That's kinda at the level I enjoy though - where I get to think-through things when figuring out exhaustiveness and correctness; introducing refinement-types into a codebase that's previously nothing but ints-and-strings; and trying out new and cutting-edge language-features directly.
I know I can prompt Claude etc into trying to do those things, but from what I've seen from other people doing it the result is somewhat of a mess - or just plain inelegant.
-----
May I ask how well Claude/Copilot/etc works with FP languages instead? So far - and back in early 2024 - I've only messed-around with asking ChatGPT to generate Haskell programs and the results were hallucinated gibberish.
Anyway I can say this - the free web interface to ChatGPT in 2024 vs what you get with agent harnesses and the latest large models now is like comparing a wombat fetus to a college graduate.
Get one of the 20 or so dollar subscriptions, install Claude code, codex or similar and start by explaining what program you want to make and which language you want to do it in. Have it make a plan first, and do some back-and-forth to refine it until you're ready to let it implement.
If your experience is from ChatGPT two years ago I think you will be floored by the results, even in Haskell.
And then it feels like a chore slogging through whatever it produced to verify it is correct.
Only that businesses have decided it is OK as long as they are benefitting to steal from everyone else, and basically force us to be the acting hand in all of it, or threaten us with starvation (no job, no income).
Maybe that's "enough" for the business to survive. But it surely won't be the reason it succeeds. It can still succeed for other factors though, but the business has given up on one path to success, which is making better software than the competition.
Yes, it's in the rules; run profiles, check code coverage, do a critical review, post the report and follow up tasks. 90% of people I've worked with did not follow these boy scout rules nearly as well as today's frontier LLMs.
Is the author implying this is bad?
> Agents bias to making the current change as safely as possible. I had a situation in a previous codebase where one morning, pre-caffeinated, my meat brain mentioned using browser local storage. So some random state was managed in local storage. Everything else through a backend database. When I looked at the code, the amount of wrapping and indirection to preserve this idiotic human mistake probably tripled the LoC. Agents can amplify our one-off bad decisions by being so conservative.
You can of course solve this many ways. And many of boils down to just how a particular humans brain works. Some will solve this by not reading code. Some will read / write code.
Whatever works for you is great. But many there is upside to the precision of not having code intermediated through the LLM for many.
Can I use agents to code a SWE project? yes, with nuances.
Can I write code for a SWE project? yes, with nuances.
Its more options now, I'll write code about projects I deeply care and will use llm at work where its shared slop and forced usage.
One way to "stay relevant" would be to admit that.
fwiw I think the rationale behind it is counterproductive because the only difference between a OP submitting their article link and someone else submitting their article link is internet points.
I'm as hateful of LLMs hollowing out the job market as the next guy, but the reality is the frontier LLMs are really good at writing anything that's been done and documented on the Internet a million times and unfortunately most of what software devs have been doing the last couple decades is shitting out cookie cutter CRUD apps.
I have my doubts about whether the state of the industry is going to advance as long as we're having LLMs do all the creation, but that's another diatribe.
Without a revolutionary new platform to build apps on that no one has ever developed for before, there is basically no reason to believe there is any software left that has some business or economic value that hasn't already been written.
We’ve created software for virtually every place we can put software. There’s nothing new.
It’s like bridges. We’ve seen all the ways bridges can be built by now. There’s nothing new left to discover.
It’s also a bit ironic to imagine that we’re at the end of new software ideas on a site owned(?) by YC.
Personally, I think we've already reached that point.
Even at YC, I have not really seen any startup doing anything interesting where their main value prop is enabled by new proprietary code that does stuff no one else can already do.
It's the end of history. What could we possibly discover about a series of technologies that are already nearly 100 years old now?
I've heard people say that various things are "solved" now because of LLMs too -- programming included. This implies we've "solved" thinking. I'm worried about these sentiments.
https://en.wikipedia.org/wiki/End_of_history
With the current ongoing revolution in home manufacturing (starting with 3D printing; currently there is a lot of work done in home CNC machining), it would be easily possible to get a huge leap towards "print your own car".
The reason why you see nothing of this is basically red tape.
This is a really good idea for completely different reasons. :-)
I'm disputing this. You can have a training corpus in assembly as big as any other language: just feed the compiled result(in assembly) of the CRUD apps to the LLMs.
I suspect that despite its translation abilities, this is true, but I'd like to see it do things in languages that are more or less appropriate for tasks to see how much the training corpus matters vs. its ability to translate. Assembly is a bit of an extreme example because you're either writing it as close to C as possible (C is essentially portable assembly) or you're writing complex, unreviewable code that happens to work. And who know if it's been trained on register allocation, or resorts to doing everything on the stack because it works.
Not really, assembly shows you what the machine instructions actually are. In C you have loops, functions structs. All things that make no sense in assembly.
Then you don't have to litter all of your if/else clauses with hundreds of memory frees and cleanups - you just "goto"
The fact that this is controversial to some people just shows how rules like "Dont use goto" become stupid - if one is trying to make code simpler then there are cases were not using it is the more confusing and error prone choice.
As for "can we now do anything" well if you don't ever need to debug "anything" then yes and if you have any small doubts about your LLM then no.
> In C you have loops, functions structs. All things that make no sense in assembly.
One can reasonably infer that a loop will roughly translate to some type of conditional jump instruction. Function structs are just pointers and call instructions. The former point was that there is little runtime getting in the way of how the constructs could be expressed, and a long time ago it may have been the truth, but not for modern compilers.
WebAssembly is slightly easier than real assembly, but here Fable used WASM GC extensions, which are poorly documented and not yet super common.
Fable didn't even need to debug it; I believe essentially all the assembly worked correctly on the first try.
I have feelings about this, but I'm not pretending it isn't real.
At first blush, it seems achingly obvious that position 1 is true, whilst position 0 is a false play by con artists.
Well, at first blush I agree! But first blushes are notorious for being famous last words (blushes).
You see, we always knew that the tool shapes the hand. That is, as we use computational (discrete) devices, we ourselves become more computational, discrete.
But what we did not anticipate is that the tool would fool others as the ACTUAL HAND. I am so fooled. Daily.
My friends. Does technique encompass being? Answer me this!
Much cheaper than a human software engineer. But comparable to the wages for some human workers.
ROI won't make itself up.
Chinese models will be enlisted in NATS - the National Terrorism Advisory System.
Can't have the fat, rich big boys who give the campaign contributions fail.
i've been curious about the feasibility of this concept for quite some time and now i have an actual example to study and measure and hack on, for a fraction of the cost of my pro sub. it wasn’t trivial, i doubt a non-swe could get it done in that time, but i'm a pretty happy customer overall.
so you don't know if it works properly or not
As I understand it, there's post-training step that does exactly that, they get real developers to select good and bad code and help the AI figure that out. AFAIK it's the reason why Claude was able to leap-frog OpenAI in coding last year, they did this refinement step a lot better.
And now they've taught the older models this, they can use existing models to bootstrap the newer models without humans involved, and bring humans in to just assess the trickier stuff.
I am honestly not happy about the way that models can now just take what should have be a fun multi-weekend project and knock out in a couple of hours. But I'm not going to pretend that Fable is stupid, or that it did a bad job on any of the test projects I gave it. It struggles more on big, messy real-world code bases, absolutely.
But it's not that much simpler. And once you add the WASM GC stuff, WebAssembly gets weird. It's a Harvard architecture with separate value memory, linear memory, GC memory and "tables", all accessible in completely ways, with a weird mandatory type system (especially for the GC stuff). And the docs are often terrible. And yes, I've also written WebAssembly by hand.
So yes, I would, overall, classify WebAssembly as "slightly easier". But not dramatically so. And the training data for actually writing non-trivial things by hand isn't that great, not compared to something like Intel assembly.
(Don't talk to me about TI320C40 assembly. If Fable can one-shot a Prolog interpreter written using that without finding a reference manual, it's time to hang up my hat and learn to make goat cheese.)
I wonder about this: Does LLM write better code in a better language?
Humans often have more difficulty fixing existing code than reqriting it from scratch, and un-structured un-constrained code would be a big reason for that.
But maybe it doesn't apply to an LLM if it always rewrites all code from scratch?
The whole point is to rewrite everything in a language you don't understand and then ignore whether it's better because you can't tell.
That language, of course, must be Rust.
One time, something didn't work as expected - its the first time it happened with this project. I read through the section of code and it was perfectly readable and well-written.
Turned out a plugin wasn't effecting the audio, so i just got it to pad some blank audio onto the beginning before processing it, then remove it at the end of the process. That fixed the issue, there was nothing wrong with the code but my ability to think laterally is what made it work.
We're getting to the stage where you can just ask them to write code and they will do what you want, and it writes good code. Its up to you to test everything beyond the internal tests it writes.
Some people find code easier to read than the English description. It’s more precise and many experienced devs can scan it and know what’s happening
Many other people can’t read code. Or they find English easier to read than code.
Thats not a knock on anyone. Maybe the latter will rule the world because the former focuses too much on irrelevant details. Or maybe me there are just different types of problems that need differing levels of attention to detail.
How can you be sure that's what the code the LLM wrote actually does?
Yet...
Less about “trusting” the llm and more about how complex it is to work with binaries due to machine code being different per machine and hard to interpret the context of the code as well as offsets.
In that sense because high level languages come with the ability to add context to what code does. It’s like the understanding a human has when given decompiled C code ghidra gives you vs C source code a developer wrote.
Also the compiler helps the llm write “compiled / working code”, if it just spat out machine code it most likely not even run at all.
But yea generally if you can’t write code at all, reviewing it is even harder.
However I do think there is reason to use Java or Python (as much as I loathe both) they have GC, and it'd be a lot easier for AI to fuck up memory safety in something like assembly or C.
One has to program computers to be a computer programmer. If one just prompts LLMs, they are a software prompter. I think both can fit under the title of a software developer or perhaps even software engineer.
There's more to it than that: writing is thinking. If you stop writing code, you aren't thinking anymore.
Many argue that they're now thinking at a higher level (maybe they weren't before?), but, guess what, that high-level design can be done better by the LLM than by you anyway. It's only temporary.
A lot of people observe that their thoughts get better when they do the work to write them out.
E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
This is a poor argument. The trial and error is the LLMs trial and error of your intention (ironically driven by you), not your trial and error.
It's like saying "It wouldn't matter if I instructed an LLM to solve my trigonometry problem or if I wrote the the solution myself; either way I'm learning trig".
> E.g. I iterate and see the architecture or the system work out, or I get other ideas because of something I don't like, etc.
What exactly are you needed for in this scenario, other than saying "make me $PRODUCT"? The LLm is going to be a lot better at architecture than you are. Your role is limited to A/B testing the result for human use.
I kinda [wrote about this before](https://dielsonsales.github.io/2023/05/11/starting-a-new-blo...) but the takeaway is that writing forces you to structure your thoughts, giving them a final shape and enables you to notice flaws or gaps in your own thinking process. It’s impossible to do this without writing.
As to your post, I think rather than writing it's the act of pressuring yourself to figure the thing out that is making you more knowledgeable about the thing.
You are putting it out publicly out there so you really want to be certain that you are correct, and therefore you do a lot of research.
If you wanted to be accurate and prove a point, the motivation mechanism could vary, but also the eventual communication mechanism could vary. It doesn't necessarily have to be in writing, it could be a live debate or simply something else you built. The writing or the product are end product, but the process of wanting to produce something is what made you research and to understand.
by writing code by hand - you're the author & editor at the same time.
if you're skilled enough - you quickly get to the desired state vs the llm which while might produce a lot of code - but it likely won't give the end state you desire.
an analogy - Jason Fried gave - producing software by llm's is like bragging you're a photographer by pressing the shutter button on an automatic camera.
while the art of photography - is about producing the single perfect photo - that communicates the photographers intent (what they want the world to see & experience).
likewise in software - what we make should be deliberate.
Where will you put a line between photography and pressing button?
My point being - tools change with time.
I don't write code anymore and I doubt I ever will ever again.
On the flipside I review exponentially more code than ever before.
>Just ask Claude to dump out assembly, or a compiled binary, but no, they don't trust the LLM that much
It's not "not trusting" the llm its that the llm has been undergoing reinforcement learning is on coding. Plus generating assembly is extremely token inefficient.
However, that would just make the difference in productivity between junior and senior developers even more pronounced! It’s really difficult to see how things will play out in the future without junior developers disappearing, causing a slow death of the profession. LLMs will probably never be good enough to do everything a developer needs to do: understand and improve or clean up requirements, consider future needs, test outside the box, evaluate performance and decide where and when to improve it…
aargh! haalp!
Which rock are you living under these days.
Nowadays everything is IR or MLIR ... or AIR ...
whoops, i may have skipped a few generations. hard to keep up with the dynamic pace these days. got a job to save. sorry suh.
mumble javascript mumble framework of the half-week ...
walks off muttering
I'll byte the bullet.
Hang on a bit while I register that in my memory.
>generate x86 and ARM
So that hardly anyone can review the machine language output, I guess.
HN users' minds be like:
87.654321 %: JS? yeah. mainhipsterstream. gotta be a part. heart.
smaller %: Rust? wannabe. donno how, u c.
much smaller %: C? oh no ... numeric underflow.
Congrats on moving over to the light side.
bobby tables, for another.
https://imgs.xkcd.com/comics/exploits_of_a_mom.png
No, people do advocate for this. It may simply not be as portable however as something that is high level able to be compiled to assembly for many machines.
Why review it at all? The trend is to vibe code everything with agent harnesses and tokenmaxxxing.
Not all software is mission critical. But some software is.
Thirdly, compilers also do type checking and other static analysis and dynamic checks (array length etc). So it's not only got more guardrails against "mistakes" by the LLM, but it's also most likely "easier" for the LLM to "reason" about (in the sense that LLMs can reason).
And I'm not saying this as some sort of AI maximalist. If progress keeps up, I seriously doubt software engineering and development will, as we know it today, will be a thing in the next 5-10 years. Maybe humans will be left with designing the UI, but everything else will be abstracted away and AI will be doing all the actual work behind the scenes.
& I think it’s fairly demonstrated that the industry isn’t profitable for training ever increasingly huge models, which get exponentially more expensive each iteration
And maybe we'll get something like a Mad Cow Disease, when AI "eats its own brains". To avoid that from happening we will need continued human inputs, and review.
The job of the software engineer increasingly becomes to make himself unnecessary: to empower the nontechnical business users to do as much as reasonably possible, without his/her intervention.
This has, of course, been the dream of computing, since its inception! And the true aim of every "high level" or "beginner friendly" (looking at you javascript!) language.
But finally, now that the computer actually speaks English (and is beginning to stop making completely insane errors), it gradually becomes feasible.
Freeing the masses from the tyranny of the nerds!
A specification detailed enough to control every aspect of the resulting product is called a program. Compilers are AI. The prevalence of compilers hasn't harmed the programming industry at all, quite the opposite.
Code. It’s called code.”
- CommitStrip (https://www.reddit.com/r/ProgrammerHumor/comments/1p70bk8/sp...)
I think if you’re doing it right, the core of your code should be the simplest expression of the underlying business logic. Of course there’s always going to be supporting layers, and maybe those don’t need to be reviewed. But if you haven’t read the code, there’s an extent to which you don’t know the business logic.
It’s ok to talk to the agent in code. Or create examples for it to follow.
https://softwaredoug.com/blog/2026/07/04/write-code-not-spec...
If you're doing this, then why not just write the effing code?
Code is executable. Specs are not.
"Please print 'hello world'"
It's IRP.
https://esolangs.org/wiki/IRP
First you write a programming language in which the language primatives are the business logic primatives, then you write a trivial program that describes what the business does in the new language.
So I took over an open source project called Omnivore. It's a reading app in the vein of Pocket. The hosted version used pdf-lib to inject some functionality into the pdf viewer. Namely, highlighting, note taking, and storing location. pdf-lib is a licensed application, so when taking it to fully self-hosted this needed to change.
I migrated it over to pdf.js. And I went through the entire process. I added all the functionality bit by bit. It didn't take exceptionally long, maybe 1-3 days. But that process was really satisfying. I found a bug, fixed it, and then found a stackoverflow issue where someone was also experiencing the same issue and suggested the fix. https://stackoverflow.com/questions/59151218/pdfjs-error-on-...
I'm pretty sure an ai could have done all of this. And therein lies my fear and my upset with AI. Not only would it have robbed me of that experience, but it shows that I have in a way been devalued. Because I do think that took a level of skill. And now that's gone...
I’ll be very curious how / if the Bun port to Rust works out.
My brain feels equally as exercised (in fact more so as I am not as good at agentic coding as I was at real coding)
But now I'm making highly polished Mac OS apps and I really like that move from JS.
I feel... conflicted.
In my personal life, I cannot justify more than a $20 sub per month. I only use the Web Chat anyway. Shelling out $100-$200 a month for a sub in which I would get little to no ROI is a poor choice. Besides, I've never hit the limit on my $20 a month plan either.
The day I am forced to prompt LLMs all day, every day is the day I am cashing out of programming as a career. Though to be clear, I have no opposition towards anyone that uses LLMs, and think they are fantastic tools when used appropriately. (I love them as a StackOverflow replacement, and have learned a lot from going back and forth with LLMs).
And then the whole article shows tangible reasons where the agents are truly worse at code than humans. Code never is just the text. If intelligence you have is not truly general, you cannot expect things like clarifying wider context, hierarchically ordering knowledge based on criteria and producing consistent results despite transfer learning and retraining.
And no, we are not even close to the multimodal capabilities of human brain to hierarchy encode and reproduce knowledge. Otherwise the correct "reasonable" economic action would be genociding all humans, and I'm pretty sure that this is what billionaires effectively want out of AI.
If the tools are making you worse, don't use the tools.
Also, if you use AI to write your code, you are not a developer either.
Let's say AI completely disappears right now, many of the so called "developers" are unable to write code, are unable to fix code, they cannot code.
There are two kind of developers:
1. Non-developers: Use AI for everything, to write code, to test the code, you name it.
2. Real developers: Search engines are broken right now, they use AI as a tool, as replacement for Google to ASSIST you, not to do the task for you.
As AI is falling apart and companies are hiring people back, these non-developers will find themselves out of work.
I feel this statement these days during code reviews. I know some amazing engineers whose output lately just isn't the same.
Why write code in 2026? Because it’s fun.
It was a great read.
Recent HN Discussion: https://news.ycombinator.com/item?id=48873855
Most code out there isn't all that great. I've been in this industry since the nineties. There are a lot of not so great software engineers doing mediocre work. People are romanticizing how great and magnificent their code is (or used to be). The reality of manually crafted code is of course a lot less flattering. Many code bases become hard to maintain over time and are riddled with bugs. And it's not like sloppy code is a new thing. Poorly executed software projects have been very common for a long time. That's not going to go away.
Hopefully companies in the industries where software quality matters and is regulated, e.g.: medicine, aviation, nuclear, etc.
Although this market is relatively small.
I actually think AI based automation is going to be a key enabler in those kinds of strict environments as well. Recent work on identifying e.g. security bugs seems to be resulting in a lot of improvement that has somehow escaped decades of human scrutiny. With good quality harnesses (manual or automated), I don't see any big objection against using generated code here.
Writing some code with the whole context in your head is the human advantage.
I’m not precious about that code. Maybe it needs to be rewritten by an agent. Or we could build good abstractions so it’s trivial to see the system. We could also use systems that by their design force us + agents away from security, performance, etc
Spending a day manually reworking the architecture in my experience can save you $1000s in tokens and weeks of headaches.
We’re trying to build a software factory with hands tied behind our back