Overutilization of AI is pulling the ladder up and preventing the next generation of software architects and engineers from learning through experience.
I think the image you post at the beginning basically sums it up for me: ChatGPT o3/5 Thinking can one-shot 75% of most reasonably sized tasks I give it without breaking a sweat, but struggles with tweaks to get it to 100%. So I make those tweaks myself and I have cut my code writing task in half or one third of the time.
ChatGPT also knows more idioms and useful libraries than I do so I generally end up with cleaner code this way.
Ferrari's are still hand assembled but Ford's assembly line and machines help save up human labor even if the quality of a mass-produced item is less than a hand-crafted one. But if everything was hand-crafted, we would have no computers at all to program.
Programming and writing will become niche and humans will still be used where a quality higher than what AI can produce is needed. But most code will be done by minotaur human-ai teams, where the human has a minimal but necessary contribution to keep the AI on track... I mean, it already is.
AI can do 80% of the work. I can review it later. And I spend much less time reviewing than I would have typing up everything manually.
I recently used it to add some logging and exception handling. It had to be done in multiple places.
A simple 2 line prompt one shotted it. Why do I need to waste time writing boring code?
Some people actually enjoy that, believe it or not.
honestly I've largely stopped coding for fun since Claude Code got popular. It's too expensive to use for personal projects, and it does the fun part. I don't want to pay but if I'm not using it, all I can think about is how inefficient doing everything manually is
..
I'm going to get into gardening or something :(
We will be focusing more higher level design - which database, where the data flows, which service is used where and so on. So you will just need different skills. Coding as a skill won't be that important.
Yes, all those ever-growing layers of intricate abstraction that you take for granted and “don’t have to worry about” are conceived of, designed, built, and maintained by developers. Who do you think wrote the compiler for that syntax you don’t want to learn?
No one in my company writes assembly. very few developers work at that level of abstraction - this means those who made the compilers are doing a good job.
That’s kind of my point: most people will work on higher abstractions but there will be some who maintain lower ones.
I write C# but I barely care about memory, gc nor microcontrollers nor assembly. Vast majority of people work on higher abstractions.
It always turns out that when you have to make a computer execute a very precise set of operations, the absolute best way to communicate this is not English, not diagrams, but code.
It also turns out that the challenge is generally not writing that code, but figuring out that precise set of operations in the first place.
But you just said
> Coding as a skill won't be that important.
So coding is only important if you need to make your software actually work, I guess?
Individual lines of code can bring down an entire system.
> and syntax
I’ve never seen this be a real issue even for lower performing devs.
I don’t worry about assembly because the abstraction layer is reliable. I don’t worry about ISAs, ucode, transistors, etc. the abstraction layer is reliable.
The same is not true for LLMs today. Circumstantial evidence: people commit the lower layer. That’s not an abstraction any more than an IDEs tab complete or “new project template” is an abstraction.
When someone stops reading the output entirely and has a codebase that is only prompts, I’ll hear them out on skill obsolescence.
(Edit: changed to hypothetical)
In my experience, AI very often gets into a sort of sunk-cost fallacy (sunk prompt?) and then it is very hard to get it to make significant changes, especially architecturally.
I recently wrote an extension for a popular software product and gave AI the same task. It created a perfectly working version however it was 5x the lines of code of my version because it didn't know the extension API as well, even though I gave it the full documentation. It also hard coded some stuff/solutions to challenges that we totally don't want to be hard coded. A big reason why I arrived at a much better solution was that I used a debugger to step through the code and noted down just the API interactions I needed.
The AI also was convinced that some things were entirely impossible. By stepping through the code I saw that they would be possible by using parts of the internal API. I suggested a change to make the public API better for my use case in a GitHub issue and now it is totally not impossible.
At the end of the day I have to conclude that, the amount of time invested guiding and massaging the AI was too much and not really worth it. I would've been better off debugging the code right away and then creating my own version. The potential for AI to do the 80% is there. At this time though I personally can't accept its results yet but that may also be due to my personal flavour of perfectionism.
The better question is: should that boring code be written? Code should only be non-boring.
The boredom of writing the code is not the only problem. The subsequent continued indefinite existence of that code is also a problem.
Are you sure you're actually reviewing the code? Deeply, properly reviewing and understanding it? Because from what I've seen people that say they do, don't. That's why they 'speed up' from using LLM-generated code.
The old adage that it's far harder to review code than to write it still holds true.
I think the argument being put forward here is that writing that boring code is part of the journey to mastery. If you haven't crossed the inflection point, a backwards slide in skills will result in less competence and more confidence, which is a scary thought given how software runs the world.
What happens when all pain and boredom is taken away? Why do we need to invent new frameworks, systems, design patterns in that scenario?
LLMs are a communication technology, with a huge trained context of conversation. They have a long way to go before becoming anything intelligent.
But LLMs aren't "only good at stuff that better languages don't require you to do." In fact they are very good at taking a bad function definition and turning it into an idiomatic one that does what I wanted to do. That's very intelligent, there is no language that can take a bad spec and make it specific and fit for the specified task. LLMs can. (not perfectly mind you, but faster and often better than I can.) The problem is they just can't always figure out when what they've written is off-spec. But "always" isn't "never" and I've yet to meet an intelligence that is perfect.
That is perhaps the biggest weakness I've noticed lately, too. When I let Claude Code carry out long, complex tasks in YOLO mode, it often fails because it has stopped paying attention to some key requirement or condition. And this happens long before it has reached its context limit.
It seems that it should be possible to avoid that through better agent design. I don't know how to do it, though.
... and can now measure my productivity in dependencies added per day! :)
I have seen people bring in thousands of lines of opencv lut code in ai slop form because they didnt understand how to interpolate between two colors and didnt have the experience to know that is what they needed to do. This is the catch 20/20 of the ai expert narrative.
The other part is that improvement has massively stagnated in the space. It is painfully obvious too.
I think there is something to this line of thinking. I just finished a bigger project and without going into details, one person from team supposedly dedicated to providing viable data about data was producing odd results. Since the data was not making much sense, I asked for info on how the data was produced. I was given SQL script and 'and then we applied some regex' explanation.
Long story short, I dig in and find that applied regex apparently messed with dates in an unexpected way and I knew because I knew the 'shape' that data was expected to have. I corrected it, because we were right around the deadline, but.. I noted it.
Anyway, I still see llm as a tool, but I think there is some reckoning on the horizon as:
1. managers push for more use and speed given that new tool 2. getting there faster wronger, because people go with 1 and do not check the output ( or don't know how to check it or don't know when its wrong )
It won't end well, because the culture does not reward careful consideration.
To be clear here i give the spec to ai many times asking what was off and it never found the issue.
Once i did get it working, ai one shotted converting it from python to go with the exception of the above mistake being added back in again.
You dont know what you dont know. That final 25% or 5% or whatever is where the money is at, not the 80%. Almost doesnt count.
I mean I'm opposed to all work, but the transition to jobless society might be traumatic. I hope you didn't neglect to buy crypto because that's the only remaining way to spontaneously and easily tap into the wealth of the rich when the work is gone.
What? So Your Jeep Compass is higher quality than a 458?
This would take more time in the short run, but in the long run it would result in more well-rounded humans.
When there are power/internet/LLM outages, some people are going to be rendered completely helpless, and others will be more modestly impacted — but will still be able to get some work done.
We should aim to have more people in the latter camp.
Openai released study mode. I don't think it's anything special beyond a custom prompt that tells it to act as a teacher. But it's a good example of what these bots can do if you prompt them right.
The bots as they stand seem to be sycophantic and make a lot of assumptions (hallucinations) rather than asking for more clarification or instruction. This isn't really a core truth to bot behaviour, and is more based around adhering to American social norms for corporate communication - deference to authority etc. You can prompt the bots to behave more usefully for coding - one of my tricks is to tell the bot to ask me clarifying questions before writing any code. This prevents it from making assumptions around functionality that I haven't specified in the brief.
For non-coding use cases, I like exploring ideas with the bot, and then every now and then prompting it to steel-man the opposing view to make sure I'm not getting dragged down a rabbit hole. Then I can take the best of these ideas and form a conclusion - hegelian dialectics and all that.
Seems very cool.
I like this a lot...
This I don't have any hope about. Tech companies have been trying to make their customers ignorant (and terrified) of the functioning of their own computers as a moat to prevent them from touching anything, and to convince them to allow every violation or imposition. They've convinced many that their phones aren't even computers, and must operate by different, more intrusive and corporate-friendly guidelines. Now, they're being taught that their computers are actually phones, that mere customers aren't responsible enough to control those as well, and that the people who should have control are the noble tech CEOs and the government. The companies can not be shamed out of doing this, they genuinely think people are just crops to be harvested. You being dumber means that you have to pay them as a necessity rather than a convenience.
In 1985, they would teach children who could barely tie their shoes what files and directories were on computers, and we'd get to program in LOGO. These days? The panicked look I often see on normal people's faces when I ask them where they saved the file that their life depends on and is missing or broken makes me very sad. "Better to trick them into saving to OneDrive," the witches cackle. "Then if they miss a monthly payment, we can take their files away!"
there is the temptation to just let these things run in our codebases, which I think for some projects is totally fine. For most websites I think this would usually be fine. This is for two reasons: 1) these models have been trained on more websites than probably anything else and 2) if a div/text is off by a little bit then usually there will be no huge problems.
But if you're building something that is mission critical, unless you go super slowly, which again is hard to do because these agents are tempting to go super fast. That is sort of the allure of them: to be able to write sofware super fast.
But as we all know, in some programs you cannot have a single char wrong or the whole program may not work or have value. At least that is how the one I am working on is.
I found that I lost the mental map of the codebase I am working on. Claude Code had done too much too fast.
I found a function this morning to validate futures/stocks/FUT-OPT/STK-OPT symbols where the validation was super basic and terrible that it had written. We had implemented some very strong actual symbol data validation a week or two ago. But that wasn't fully implemented everywhere. So now I need to go back and do this.
Anyways, I think finding where certain code is written would be helpful for sure and suggesting various ways to solve problems. But the separate GUI apps can do that for us.
So for now I am going to keep just using the separate LLM apps. I will also save lots of money in the meantime (which I would gladly spend for a higher quality Claude Code ish setup).
I don't like it to do complete PR's that span multiple files.
Now, the llm summarizes the email, so you only have to be so literate to understand bullet points. The llm takes your bullet points and turns them into long form writing, because you can’t write. They say this is necessary because they aren’t good writers, but this creates a self fulfilling prophecy if they just avoid writing entirely.
A sad time when people are allowing their ability to read and write fall by the wayside. These used to be skills people valued and took pride in improving for themselves. Now people shut their brain off.
People who only and constantly use AI to take a shortcut to reach some outcome rather than learn to do it themselves will likely fall behind in the long run and perhaps learn a lesson from having chose that route, and then have to spend some time actually learning the thing if they want to catch back up.
Any clever prompting techniques that give you an edge today will evaporate quickly. People figure out the tricks, models absorb them, and tools automate them away.
There's no substitute for actually coding to learn software development. For new engineers, I'd strongly recommend limiting AI code generation on real work. Use it to explain concepts, not do the work for you. Otherwise you'll never develop the judgment to know what that 10% actually is.
It's like asking -- "will robots be good for building things?"
Sure, some things. What things?
Personally, I'm hoping for the revival of the idea that Hypercard was intended for; yes, let us enable EVERYONE to build little tools for themselves.
It will enable more people, but "everyone" is never, ever going to happen.
This is both because (1) many people don't want to do this, no matter how easy it is -- probably the primary reason and (2) many people won't have the ability to do this in a way that is net profitable for them, because their "tool ideas" just won't be good.
Yes, and that's a good thing.
Though I'd argue the bar has been on a downward trajectory for decades, is now plummeting with AI, and still we don't see a huge influx of the newly enabled. At the margins, yes. Some small business owners, some curious students, etc, are making things they wouldn't have before. But it doesn't feel like a revolution of self-made tools by the non-technical. And I don't think one is coming. And I don't think it's because it's still too hard.
I do agree it takes time for things to be fully absorbed into the culture, and the full impact of even the current state of AI has not been felt. But I stand by my claim that, basically, many many people have no interest in being makers, and no amount of friction-easing will change that. I think it's a hard thing to grasp for people with a natural interest in math/CS/etc. I came to my current position reluctantly, after teaching undergrads in both math and humanities, and after many conversations with non-technical (and often very smart) friends. Some people are just not interested in using their mind that way, just like some people like some games but not others.
50 years ago, you don't have to be a car guy, but if you know one, that's all you need to save a LOT of money and headache.
Today, that kind of works -- unless you own e.g. a Tesla.
In my life of the thousands of non tech people I've worked with I can count in the low double digits that were capable of working in SE without exp/edu in it. Even then they were all up and coming driven people that still often missed what to me were obvious things, because its not their area of expertise. (They were all brilliant in their own area)
As far as code generation, there are some intriguing workflows out there. Eg start by having the LLM generate a git repo for your project. Use the DAG for the repo as the guide for more code generation. Embed the code files into a vector database, differentianting between static and dynamic files and re-embed on commits. Use all those data structures in compilers: ASTs, call graphs, dependency graphs - as guides for the AI along with the git repo's DAG. Then if its proprietary code development, run an open source LLM locally to avoid leaking at the embedding and code generation stages. Now, run an 'overnight build' using your local LLM for code generation. Come in next day, review and test all the code the LLM generated. End of the day, commit all the changes that look good, rinse and repeat.
The thing here is you are actively involved at every stage - and the same strategies work for any non-coding writing task. Eg structure your prompts carefully like well-designed short essays. Read the LLM output with an eye out for errors and inconsistencies, copy and paste those into the next prompt and demand a critical review. Once the context window gets too big, boil it all down into a vector database for future reference, generate a new summary prompt from that database, rinse and repeat.
I'd suggest thinking of yourself as the conductor of an orchestra, but one who knows what the capabilities of every instrument is, so you're actually thinking harder and working harder than you were before you had access to these AI tools. That at least will keep your cognitive skills in tune.
P.S. I tend to get much better critical analysis from the LLM if I start all chats with:
> "Preliminary instructions: do not engage in flattery or enthusiastic validation or praise of any kind. Do not offer suggestions for improvement at the end of output. If this is clear, respond with "yes, this is clear"."
Don't let the LLM give you roses and lead you down the garden path, instead think of it as a politely-adversarial low-trust relationship.
That paper has far too many graphs which are totally made up.
It's been less than three years since ChatGPT launched. What's this going to be be like in a decade or two?
I've been learning how to build houses as my escape hatch. A lot of people like to talk about how AI isn't capable of this and that - the ONLY thing you will be complaining about in 5 years is the Basic Income programs needing to expand quickly and reform so we people can keep their 1.8M mortgages with $2000/mo taco bell income.
I share much of the same ideas about this as the author.
For a long time, to make coding more natural (before and after LLMs) and not having to think about certain keywords or syntax, I would create little Anki decks (10-20 cards) with basic exercises for a particular language or tool I was using. One to two weeks of 5-10 minutes/day of doing these exercises (like, how to redirect both stout and strrr into a file, how to read from a channel in go, etc) and I was working without having to pause.
Writing code became less disruptive and much easier to get my ideas into a text editor.
I’m also the creator of typequicker.com (disclaimer) and we added Code mode as a typing exercise.
At first I thought folks wouldn’t be interested. I was pleasantly surprised though; many people are using it specifically for the same reason that the author is talking about.
AI isn’t replacing thinking, it’s changing what we think about. Coding skill won’t disappear; it’ll just evolve.
Historically every technological recolution serves to replace some facet of human labor (usually with the incentive of squeezing profits as technology gets cheaper over time, but wages do not).
Industrial revolution == automate non dexterous manual labor
Information age == automate "computational"/numerical thinking
AI == automate thinking
Robotics + AI == automate dexterous manual labor
crinkly•8h ago
I wonder if some of the proponents know where the line is in the art. I suspect not.