I have gone from using Claude Code all day long since the day it was launched to only using the separate Claude app. In my mind that is a nice balance of using it, but not too much, not too fast.
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).
The reality is that you can't have AI do too much for you or else you completely lose track of what is happening. I find it useful to let it do small stupid things and use it for brainstorming.
I don't like it to do complete PR's that span multiple files.
I don't think the "complete PR spanning multiple files" is an issue actually.
I think the issue is if you don't yourself understand what it's doing. If all you do is to tell it what the outcome should be from a user's perspective, you check that that's what it does and then you just merge. Then you have a problem.
But if you just use it to be faster at getting the code you would've liked to write yourself, or make it write the code you'd have written if you had bothered to do that boring thing you know needs to be done but never bothered to do, then it's actually a great tool.
I think in that case it's like IDE based refactorings enabled by well typed languages. Way back in the day, there were refactorings that were a royal pain in the butt to do in our Perl code base. I did a lot of them but they weren't fun. Very simple renames or function extractions that help code readability just aren't done if you have to do them manually. If you can tell an IDE to do a rename and you're guaranteed that nothing breaks, it's simply a no brainer. Anyone not doing it is simply a bad developer if you ask me.
There's a lot of copy and paste coding going on in "business software". And that's fine. I engage in that too, all the time. You have a blueprint of how to do something in your code base. You just need to do something similar "over there". So you know where to find the thing to copy and paste and then adjust. The AI can do it for you even faster especially if you already know what to tell it to copy. And in some cases all you need to know is that there's something to copy and not from where exactly and it'll be able to copy it very nicely for you.
And the resulting PR that does span multiple files is totally fine. You just came up with it faster than you ever could've. Personally I skipped all the "Copilot being a better autocomplete" days and went straight into agentic workflows - with Claude Code to be specific. Using it from within IntelliJ in a monorepo that I know a lot about already. It's really awesome actually.
The funny thing is that at least in my experience, the people that are slower than you doing any of this manually are not gonna be good at this with AI either. You're still gonna be better and faster at using this new tool than they were at using the previously available tools.
> You just need to do something similar "over there". So you know where to find the thing to copy and paste and then adjust. The AI can do it for you even faster especially if you already know what to tell it to copy. And in some cases all you need to know is that there's something to copy and not from where exactly and it'll be able to copy it very nicely for you.
The issue with this approach is the mental load of verifying that the it did the thing you asked for correctly. And that it did not mess something like a condition expression.
My belief is that most developers don't interact with their code more than character on the screens. Their editing process is clicking, selecting, and moving character by character. Which make their whole experience painful for anything that involves a bit of refactoring.
When you exploit things like search based navigation (project or file based), indexing (LSP or IDE intellisense), compilers/linters/test runners report (going directly to the line mentioned), semantic navigation and manipulation (keyboard based), and the knowledge of few extra tools like (git, curl, jq,...) you'll have a far pleasant experience with coding. Editing is effortless in that case. You think about a solution and it's done.
Coding is literally the most enjoyable part of the job for me. What's not enjoyable is the many WTFs when dealing with low quality code and having to coax specifications from teammates.
The issue with this approach is the mental load of verifying that the it did the thing you asked for correctly. And that it did not mess something like a condition expression.
That's fair to an extent and what I've commented on before as well: AI can make the enjoyable part of coding "go away" and replace it with the menial and unfun part: Code review.
The "trick" would be to make it more like a pair programming session than code review.
Which make their whole experience painful for anything that involves a bit of refactoring.
Also agreed! So many times when pairing with others it's like that. It's very painful to see other people debug in many cases. Or write code / interact with their tooling. But then there are also some where it's a ray of light. People that know their tooling just as well as you do or maybe even better and you learn a thing or two.
I love it when I come out of a pairing session and I've learned something that I can incorporate.
And it pains me when I've used something, maybe even specifically called out how I do something, for the n-th time with someone and they still don't catch on. And it doesn't matter if they don't pick it up by themselves or whether it's something that's one of their improvements to work on because we literally talked about it in the last seven 1:1s or something. Some people "just don't get it" unfortunately. Some people really just aren't cut out to be devs. AI or not.
Editing is effortless in that case. You think about a solution and it's done.
Yes but ;) As in, agreed on effective tool use being awesome but unfortunately more rare than I would like. But there are other people "like you and me" out there. Sometimes we have the fortune to work with them. It's such a delight! I love working with them. I love just working with someone that's on the same level and we can pair on an equal level and get shit done. It's rare though.
It's not just done though. It's still work in many cases and some of that really can be improved with this new tool: AI. Just like we were able to replace a 30 minute Perl refactoring done manually with a few seconds IDE refactoring in Kotlin (or whatever language floats your boat/happens to be used where you are)
low quality code and having to coax specifications from teammates.
I'm not sure I understand this part to be honest. I don't usually coax specifications from teammates. I coax them from Product people or customers and while it's not really the most fun sometimes, personally, I do find joy in the fact that I am delivering something that helps the customer. I enjoy fixing a bug both because I like the hunt for the root cause (something AI really isn't great at doing by itself from my experience yet - but I do enjoy working with it) and because I like it when I can deliver the fix to the customer fast. Customer reported a bug this morning and by the end of the day they have a fix. That's just awesome. Cloud FTW. Gone are the days of getting assigned a bug someone triaged 6 months ago and it will go out with a release 3 months from now, ensuring the customer gets the fix installed a year plus from when they reported it (coz of course their admins don't install a new release the day it comes out, right?)
> I don't usually coax specifications from teammates. I coax them from Product people or customers and while it's not really the most fun sometimes, personally, I do find joy in the fact that I am delivering something that helps the customer.
It's when you're dependent on a service and there's no documentation. Even if you can read the code (and if you can't, you probably should learn), it's better to ask the person that worked on it (instead of making too many assumptions). And that's when the coaxing comes into play.
Losing the mental map is the number one issue for me. I wonder if there could be a way to keep track of it, even at a high level. Keeping the ability to dig in is crucial.
Spend time reviewing outputs like a tech lead does when managing multiple developers. That's the upgrade you hust got in your career, you are now bound to how many "team members" you can manage at a single time. I'm grateful to live in such a time.
The code is the mental map. Orchestra conductors read and follow the music sheet as well. They don't let random people comes in and mess with. Neither do film directors with their scripts and their plans.
> I have gone from using Claude Code all day long since the day it was launched to only using the separate Claude app. In my mind that is a nice balance of using it, but not too much, not too fast.
I’m on a similar journey - I never used it all day long but definitely a lot during a brief honeymoon period and now I’m back to using it very sparingly but I put questions to the Claude app all the time
For me the sweet spot for Claude code is when I have a very clear and well documented thing to set up that I really don’t want to do for the umpteenth time - like webhook signature verification - just paste the docs and let it rip - or setting up the most basic crud forms for an admin dashboard - ezpz
But otherwise I’ve gone back to mostly writing everything by hand
I think the whole AI vs non. AI debate is a bit besides the point. Engineers are stuck in the old paradigm of "perfect" algorithms.
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.
Hard disagree. We'll be able to use more expressive languages with better LLM support for understanding how to express ourselves and to understand compiler results. LLMs are only good at stuff that better languages don't require you to do. After that they fall off the cliff quickly.
LLMs are a communication technology, with a huge trained context of conversation. They have a long way to go before becoming anything intelligent.
LLMs lack intentionality, and they lack the ability to hold a series of precepts "in mind" and stick to those precepts. That is, if I say "I want code that satisfies properties A, B, C, D..." at some point the LLM just can't keep track of all the properties, which ones are satisfied, which ones aren't, what needs to be done or can be done to make them all satisfied.
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.
> LLMs ... lack the ability to hold a series of precepts "in mind" and stick to those precepts.
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.
> 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.
Or alternatively, we will build bigger and better things with the power of AI. Everyone talks about it replacing us, but we aren't running out of things to build. It's not like we're gonna run out of ways to improve the world, and compared to other things the digital world is unconstrained.
Depends on what you do, and what systems you develop for I would reckon. If it's another TODO app or some kind of table + form system that's been done to death - AI can probably have a go at creating a barebones minimal viable product. Targeting code that's outside the sweet spot of the training data ("blurry" area), you'll start to stumble. I've also found agents to be useless in large code bases with distributed logic where parts are in react, web back-end, service system). Slow and unreliable for large systems. Good for small tasks and scaffolding up proof of concepts.
Are you still going to have the skills to review it a year from now? Or 5 years from now when you’ve become accustomed to only writing <20% of the code? I’m already witnessing my coworkers skills degrading because of this, and it’s only going to get worse. Programming is a language, and when you don’t use it, it fades.
What will happen is that we as developers will move one layer up in the abstraction. In the future it would seem a bit nonsensical to focus on individual lines of code and syntax because AI can more or less deal with it.
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.
Anyone old enough to remember when UML promised the same thing? Never have to touch code again -- just draw boxes, charts, activity diagrams, etc. and right-click and generate code! Rational Rose is the future of programming!
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.
Yes, and in the enterprise space, many workflows are nowadays done with lowcode/no-code tooling, like PowerApps, Adobe Workfront Fusion, Outsystems, among others.
Many of these tools, have started to go one step further, and the traditional ways are supplanted with AI, reducing even further the amount of low code/no code scenarios that a human has to produce.
The only thing left are the few serverless deployments to call into some code that needs more complex integration logic, and that is about it.
I have seen enough of these projects, to realize it is going to happen, not everywhere maybe, but in specific industry sectors certainly, it already is.
Its not a binary - we will spend less time thinking about code and occasionally fix things and more time on higher level abstractions.
Just like I sometimes need to understand and dive into assembly but not always. Its a spectrum and the value in the spectrum changing has consequences for how we work.
That is wishful thinking. Every layer we added between humans and the machines (and even the ones in the machines themselves) take hordes of dedicated humans to maintain: IDEs, compilers/interpreters, linters, CI tools, assemblers, linkers, operating systems, firmware, microcode, circuitry, circuit elements (manufacturing processes).
Just about every time somebody on this site says “we developers”, you can assume they’re ignoring the (large majority of) developers that don’t work on the same things they do, in the same way.
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?
The point of abstraction is that it doesn’t leak. Most developers don’t need to understand compiler theory or assembly to be productive.
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.
if this is true we will have to trust committing prompts not code.
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.
If that’s a real effect, the best programmers absolutely will. You could spend 10% of your working time doing exercises, and still have double the productivity you used to have.
seriously! excuse me while I cry with the artists about the robot doing the fun part. automate my goddamned dishes, not the coding! I chose this field because I liked that part ;_;
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
This reminds me of the phenomenon of competence being inversely correlated with confidence until some inflection point is reached on the journey to mastery.
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.
The fear and pain of writing boring code gave us the processes and systems we have today. i.e. microservices, (I know they have their own problems) were born out of pain from maintaining monoliths. Agile (again, own problems) was born out of pain from waterfall.
What happens when all pain and boredom is taken away? Why do we need to invent new frameworks, systems, design patterns in that scenario?
What you shouldn't forget also is that, while AI may be good at coming up with a "first shot" solution, it may be much worse if you want to change/correct parts of it.
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.
> 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
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.
However, from my experience, the quality of code produced by developers in project we are working for the last 3+ years gone south. Amount of bugs now literally tripled year on year. I bet the reason is extensive use of AI tools, as the developers are the same.
Its because most people don't have the discipline and obsession of attention to detail to know when one should use an LLM and when one shouldn't.
I highly doubt the best of the best folks are even touching LLMs (barely) because they can see the flaws and the tradeoffs that are not-so-visible to others until they are 50 levels deep, with sunk investments, unwilling to go back to how they used to do things.
> Engineers are stuck in the old paradigm of "perfect" algorithms.
Reminds me of a misinterpretation of Knuth.
> Premature optimization is the root of all evil.
He was definitely knocking engineers for wanting to write "perfect" algorithms, but this quote also got bastardized to mean something different from what he said (happens to many clichés). All he said was "grab a fucking profiler before you optimize."
But now, I'm not sure a lot of programmers even know what a profiler is. When was the last time you saw someone profile their code?
Problem is we've taken the idea of "minimum viable product" too far. People are saying "Doesn't have to be perfect, just has to work." I think most people agree. But with the current state of things? I disagree that things even work. We're so far away from the question of optimization. It's bad enough that there are apps that require several gigs to just edit a 30kb document but FFS we're living in a world where Windows Hello crashes Microsoft Outlook. It's not the programs are ugly babies that could be better, they are monstrosities begging to be put to death.
I WISH we could talk about optimization. I WISH our problem was perfectionism. But right now our problem is that everything is a steaming pile of garbage and most people are just shrugging their arms like "it is the way it is". Just because you don't clean up that steaming pile of garbage doesn't mean someone else doesn't. So stop passing the buck.
> When was the last time you saw someone profile their code?
A year ago. I heavily relied on one to optimize a complex data import that took an hour for a million line Excel file. The algorithm translated it to a graph according to a user-specified definition and would update an existing graph in neo4j, keeping the whole thing consistent.
The only other guy who understood the algorithm (a math PhD) thought it was as optimal as it could get. I used the profiler to find all the bottlenecks, which were all DB checks for the existence of nodes, and implemented custom indices to reduce import time from an hour to 3 minutes.
It did introduce a bunch of bugs that I had to fix, but I also discovered some bugs in the original algorithm.
It was one of my best programming experiences ever. Especially the payoff at the end when it went down from an hour to 3 minutes is a dopamine rush like never before. Now I want to optimize more code.
I don't think users cared, though; originally this work would take days by hand, so an hour was already pretty good. Now I made something fiendishly complex look trivial.
I sure bet that the users cared. Yeah, starting from a few days an hour feels great but you also get accustomed to it.
> It did introduce a bunch of bugs that I had to fix, but I also discovered some bugs in the original algorithm.
I find this is extremely common when I profile code. It is just so easy to miss bugs. People get lulled into a false sense of security because tests pass but test just aren't enough. But for some reason when I say "tests aren't enough" people hear "I don't write tests."
Seeing those big improvements and knowing you did more than make it faster is always really rewarding. I hope you do do more optimization :) Just remember Knuth's advice. Because IO is a common problem and Big O isn't going to tell you about that one haha
> Problem is we've taken the idea of "minimum viable product" too far. People are saying "Doesn't have to be perfect, just has to work." I think most people agree. But with the current state of things? I disagree that things even work. We're so far away from the question of optimization. It's bad enough that there are apps that require several gigs to just edit a 30kb document but FFS we're living in a world where Windows Hello crashes Microsoft Outlook. It's not the programs are ugly babies that could be better, they are monstrosities begging to be put to death.
LOL. OMG that was beautiful. It almost feels like we are de-evolving software to a state where shit is going to stop working bad. I know this is not full of facts, but this take reminds me of Jonathan Blow's video "Preventing the Collapse of Civilization"[0] Where he talks about how code runs worse than it ever has and I think he was arguing that civilization is collapsing before our eyes in slow time.
Good talk. I did something similar to him and all that happened is everyone was just saying I'm making a lot out of nothing. They're right that each thing was "nothing" but the problem is that this is a non-trivial number of "nothings" happening every day...
Honestly, I think the problem is that it's a Lemon Market[0]. Lemon markets thrive when there is asymmetric information. When a customer cannot tell the difference between a good product (peach) and a bad product (lemon). All it takes is a bunch of tech illiterate people... not sure where we'll find those...
On your video, funny thing. When I was in my PhD I had a very hard time publishing because I was building models that were much smaller, required less data, but got similar performance. Reviewers just looked at the benchmark like "not SOTA? lol". I've seen tons of great papers solving similar problems constantly get rejected. As a reviewer I frequently defended works like that as well as works that had good ideas but just didn't have enough GPU power. It was really telling...
[P.S.] A nice solution I found for the pasting problem he mentioned (and in various forms) is that I first paste the text into the url bad or search bar then copy that and then paste. {<c-k>,<c-l>}<c-v><c-a><c-c>. Works 98% of the time every time.
I invite your attention to the StatsD telemetry protocol, where:
1. Every single measurement in a timeseries is encoded as a utf-8 string having (roughly) the following format:
"${name}:${value}|${type}|${tags}"
where name is like "my.long.namespace.and.metric.name", value is a string formatted number, god only knows what type is, and tags is some gigantic comma separated key:value monstrosity.
2. Each and every one of these things is fired off into the ether in the form of a UDP datagram.
3. Whenever the server receives these presumably it gets around sometime to assigning them timestamps and inserts them into a database, not necessarily in that or any other particular order.
Engineering isn't stuck on perfect algorithms. Management is. There's lip service for AI code gen, but if my name is on a module, I still have to vouch for its correctness. If it's wrong, that might become my problem. I don't always write perfect code, but I aspire to. If I see evidence that these tools are writing more correct and reliable code than I do, then I will start to take it more seriously. For some code, it matters whether it's robust basically.
Another hard disagree. The crux here is that if u are not an expert in the given domain you do not know where that missing 25% is wrong. You think you do but you dont.
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.
<< you do not know where that missing 25% is wrong
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.
Exactly. I use ai tools daily and they bite me. Not enough to stop but enough to know. Recently was building a ws merger of sorts based on another libs sub protocol. I wasnt familiar with the language or protocol but ai sure was. However the ai used a wrong id when repacking messages. Unless i knew the spec (which i didnt) i never would have known. Eventually, i did read the spec and figured it out.
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.
The analogy seems to fall apart because the quality of an assembly line produced car is higher than the hand crafted one. Fords lose out because they engineer to a price point, a Ferrari doesn't have that "problem" - arguably, the more expensive the better.
Yeah, I'm trying to branch out to build things outside my comfort zone. AI already is helpful in my normal day-to-day (backend engineer, mostly Python w/ PyCharm/Datagrip working in monorepo style), but Claude Code helped me graft on a Typescript/Javascript UI ecosystem with an independent Webstorm IDE setup that will integrate well, along with all the presumably latest build tools and package management. The research and self-education I would have needed to do this without Claude would have been extensive, and would have been nowhere as complete. I don't see any point in going back to pre-AI. And I don't generally use AI results blindly, I go back and review and set some breakpoints in an IDE and watch it do its thing.
Why are you assuming the cases where humans can code better than AI still exists after three years say -- I think in some industries today artisanal products are also not higher quality than machine made ones.
Extraordinary claims require extraordinary evidence and if there's one thing we've learned is that progress in AI is not linear nor predictable. We've been a few years away from fully self-driving cars for a really long time now.
IMO LLMs have demonstrated how uncomplicated the man behind the curtain really is. If we do happen to achieve AGI it will likely have many of the problems associated with the real thing which often fails in spectacular fashion.
Yeah, it's definitely shifting how we work. Feels like an upgrade from high-level languages, but we're still guiding the process. The performance boost is real, but once everyone adopts it, we'll probably just be building more complex things at a similar pace.
You are describing accurately where AI is now. But it wasn't there two years ago and it won't be there in two years. You still have 25% of your job today, but this will most likely gonna halve evey x-number of months.
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.
It would be good if there were a mode where AI trained the human operator as it worked, to reduce future reliance. Instead of just writing a document or editing a document, it would explain in a good amount of detail what it was doing, and tailor the information to the understanding level of the operator. It might even quiz the operator to assure understanding.
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.
Can you describe how to access this feature? I can't find anything about this online, and I asked Claude on command line and nothing comes up for "learning mode"
Ah, cool. Is this meant to be used for learning specifically, or just something that can be toggled whenever you're using Claude to help you with anything?
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.
> some people are going to be rendered completely helpless,
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!"
I think what we see is the final struggle between the Anglo-Saxon concept of Education ( Locke, Dewy) and the German concept of “Bildung” (Humboldt, Herder).
The former puts more emphasis on the pragmatic transmission of knowledge and socialisation, while the latter focuses on self formation via the gaining of knowledge.
People will always be educated, acquiring skills and being part of a society does not go out of fashion.
I am not sure the ideal of the “gebildeter Mensch” will survive. Self discovery through deep engagement with intellectual tasks requires exactly those skills AI tries to automatise.
The thing is, this is already occurring and seems to be OK as long as there exists a class of individuals who provide the intellectual horsepower to keep society moving forward.
But I feel very uncomfortable in the fact that people (who for whatever reason) can't make rational and responsible choices, are not being protected and free to exploitation.
> 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.
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.
Rome wasn't built in a day, as they say. It takes time for the information to disseminate. Perhaps tools like this will be the watershed moment that speeds up the flow. Like the time back ~1990 when I received GFA BASIC on a magazine cover disk and it unlocked the knowledge that I could make anything I wanted to. It took me 33 years from then to get a Game Of The Year. Good things take time. Hopefully less in future :)
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.
This sounds great in theory but my my experience is that non tech people make horrible SE's. Even if they don't do the coding only participating in the spec. They simply don't even know what they don't know. Which is why SE exists and why these type of projects always fail to gain traction.
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)
Tools like Claude Code and OpenAI’s Codex CLI have boosted my productivity massively. They already handle about 90% of the coding work, and I just step in to finish the last 10%. Every month they get better, maybe in a year it’s 95%, in two years 97%, in three years 98%. We can all see where this is going.
You're an early adopter, so you're seeing massive gains. But eventually everyone gets the same productivity boost and that becomes the new baseline expectation.
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.
You are fortunate to have the pre-AI background experience to know how to recognize the 10%. People graduating college right now may never be so fortunate.
This doesn't just apply to software development - it applies across the board in any form of knowledge.
An example would be economics - an LLM can spit out a bunch of words about an economic model. But if you don't take the time to learn, visualise and understand it for yourself - it means nothing to you. And in that case, if you already possess mastery why would you waste your resources playing around with an inferior tool to you?
Absolutely agreed. Thinking anything else is nothing but cope, and these comments are FULL of it. it would be laughable if they weren't so gate keepy and disengenuous about it.
AI can churn out code that works, but usable, secure code is written for humans first; clear, predictable, and safe by design. Until AI can reason like a team lead and think like an attacker, it’s still just guessing. Usability and security aren’t side effects, they’re intentions, and AI doesn’t have those yet. Code without security is useless[0].
[0] https://www.npr.org/2025/08/02/nx-s1-5483886/tea-app-breach-...
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.
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 think we’ll need to rethink what it means to be “skilled.” Fewer people will write every line of code themselves, but more will need to understand systems end-to-end, ask the right questions, and guide AIs to meaningful outcomes.
AI isn’t replacing thinking, it’s changing what we think about. Coding skill won’t disappear; it’ll just evolve.
This is the direction it was (and should be) heading in anyways. We're pumping out so many CS grads that pure technical skill is less valued than everything surrounding it.
The argument against relying on AI for everything is that the humans who curate and architect systems learned what they did through their experience at lower levels.
Overutilization of AI is pulling the ladder up and preventing the next generation of software architects and engineers from learning through experience.
Yes, it will replace human thinking. Thats quite literally the explicit goal of every AI company.
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
It used to be reading and writing were skills. People would strive to get better, usually by steeping themselves in the work of better writers so some rubs off.
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.
Well I am not talking specifically about reading and writing. I am talking about the concept in general.
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.
You are saying people who took shortcuts and fell behind because of it never learned a lesson from that? Not saying everyone would, but definitely some people do.
The replacement of reading books and writing letters with television/video streaming and phone/texting has done far more to depress average human cognitive skills than LLM code and text generation could ever hope to achieve.
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.
AI is using the well known Embrace Extend Extinguish strategy, coined by Microsoft. Today corporations push us to embrace AI by all means possible, and use where it's useful and where it's not useful. Tomorrow AI will extend our ways of thinking and working in such a ways that we'll have to rely on it, like a medicine that you'd rather not use, but got dependent on. And then AI will extinguish us, for its main selling point is it replaces employees, makes them unnecessary. That's the plan, at least.
I have gone from using Claude Code all day long since the day it was launched to only using the separate Claude app. In my mind that is a nice balance of using it, but not too much, not too fast.
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).
The reality is that you can't have AI do too much for you or else you completely lose track of what is happening. I find it useful to let it do small stupid things and use it for brainstorming.
I don't like it to do complete PR's that span multiple files.
I don't think the "complete PR spanning multiple files" is an issue actually.
I think the issue is if you don't yourself understand what it's doing. If all you do is to tell it what the outcome should be from a user's perspective, you check that that's what it does and then you just merge. Then you have a problem.
But if you just use it to be faster at getting the code you would've liked to write yourself, or make it write the code you'd have written if you had bothered to do that boring thing you know needs to be done but never bothered to do, then it's actually a great tool.
I think in that case it's like IDE based refactorings enabled by well typed languages. Way back in the day, there were refactorings that were a royal pain in the butt to do in our Perl code base. I did a lot of them but they weren't fun. Very simple renames or function extractions that help code readability just aren't done if you have to do them manually. If you can tell an IDE to do a rename and you're guaranteed that nothing breaks, it's simply a no brainer. Anyone not doing it is simply a bad developer if you ask me.
There's a lot of copy and paste coding going on in "business software". And that's fine. I engage in that too, all the time. You have a blueprint of how to do something in your code base. You just need to do something similar "over there". So you know where to find the thing to copy and paste and then adjust. The AI can do it for you even faster especially if you already know what to tell it to copy. And in some cases all you need to know is that there's something to copy and not from where exactly and it'll be able to copy it very nicely for you.
And the resulting PR that does span multiple files is totally fine. You just came up with it faster than you ever could've. Personally I skipped all the "Copilot being a better autocomplete" days and went straight into agentic workflows - with Claude Code to be specific. Using it from within IntelliJ in a monorepo that I know a lot about already. It's really awesome actually.
The funny thing is that at least in my experience, the people that are slower than you doing any of this manually are not gonna be good at this with AI either. You're still gonna be better and faster at using this new tool than they were at using the previously available tools.
> You just need to do something similar "over there". So you know where to find the thing to copy and paste and then adjust. The AI can do it for you even faster especially if you already know what to tell it to copy. And in some cases all you need to know is that there's something to copy and not from where exactly and it'll be able to copy it very nicely for you.
The issue with this approach is the mental load of verifying that the it did the thing you asked for correctly. And that it did not mess something like a condition expression.
My belief is that most developers don't interact with their code more than character on the screens. Their editing process is clicking, selecting, and moving character by character. Which make their whole experience painful for anything that involves a bit of refactoring.
When you exploit things like search based navigation (project or file based), indexing (LSP or IDE intellisense), compilers/linters/test runners report (going directly to the line mentioned), semantic navigation and manipulation (keyboard based), and the knowledge of few extra tools like (git, curl, jq,...) you'll have a far pleasant experience with coding. Editing is effortless in that case. You think about a solution and it's done.
Coding is literally the most enjoyable part of the job for me. What's not enjoyable is the many WTFs when dealing with low quality code and having to coax specifications from teammates.
The "trick" would be to make it more like a pair programming session than code review.
Also agreed! So many times when pairing with others it's like that. It's very painful to see other people debug in many cases. Or write code / interact with their tooling. But then there are also some where it's a ray of light. People that know their tooling just as well as you do or maybe even better and you learn a thing or two.I love it when I come out of a pairing session and I've learned something that I can incorporate.
And it pains me when I've used something, maybe even specifically called out how I do something, for the n-th time with someone and they still don't catch on. And it doesn't matter if they don't pick it up by themselves or whether it's something that's one of their improvements to work on because we literally talked about it in the last seven 1:1s or something. Some people "just don't get it" unfortunately. Some people really just aren't cut out to be devs. AI or not.
Yes but ;) As in, agreed on effective tool use being awesome but unfortunately more rare than I would like. But there are other people "like you and me" out there. Sometimes we have the fortune to work with them. It's such a delight! I love working with them. I love just working with someone that's on the same level and we can pair on an equal level and get shit done. It's rare though.It's not just done though. It's still work in many cases and some of that really can be improved with this new tool: AI. Just like we were able to replace a 30 minute Perl refactoring done manually with a few seconds IDE refactoring in Kotlin (or whatever language floats your boat/happens to be used where you are)
I'm not sure I understand this part to be honest. I don't usually coax specifications from teammates. I coax them from Product people or customers and while it's not really the most fun sometimes, personally, I do find joy in the fact that I am delivering something that helps the customer. I enjoy fixing a bug both because I like the hunt for the root cause (something AI really isn't great at doing by itself from my experience yet - but I do enjoy working with it) and because I like it when I can deliver the fix to the customer fast. Customer reported a bug this morning and by the end of the day they have a fix. That's just awesome. Cloud FTW. Gone are the days of getting assigned a bug someone triaged 6 months ago and it will go out with a release 3 months from now, ensuring the customer gets the fix installed a year plus from when they reported it (coz of course their admins don't install a new release the day it comes out, right?)> I don't usually coax specifications from teammates. I coax them from Product people or customers and while it's not really the most fun sometimes, personally, I do find joy in the fact that I am delivering something that helps the customer.
It's when you're dependent on a service and there's no documentation. Even if you can read the code (and if you can't, you probably should learn), it's better to ask the person that worked on it (instead of making too many assumptions). And that's when the coaxing comes into play.
Losing the mental map is the number one issue for me. I wonder if there could be a way to keep track of it, even at a high level. Keeping the ability to dig in is crucial.
Spend time reviewing outputs like a tech lead does when managing multiple developers. That's the upgrade you hust got in your career, you are now bound to how many "team members" you can manage at a single time. I'm grateful to live in such a time.
The code is the mental map. Orchestra conductors read and follow the music sheet as well. They don't let random people comes in and mess with. Neither do film directors with their scripts and their plans.
> I have gone from using Claude Code all day long since the day it was launched to only using the separate Claude app. In my mind that is a nice balance of using it, but not too much, not too fast.
I’m on a similar journey - I never used it all day long but definitely a lot during a brief honeymoon period and now I’m back to using it very sparingly but I put questions to the Claude app all the time
For me the sweet spot for Claude code is when I have a very clear and well documented thing to set up that I really don’t want to do for the umpteenth time - like webhook signature verification - just paste the docs and let it rip - or setting up the most basic crud forms for an admin dashboard - ezpz
But otherwise I’ve gone back to mostly writing everything by hand
You need to spend more time in Plan mode. Ask it to make diagrams or pseudocode of whats and hows, iterate on that and then Accept Edits.
I think the whole AI vs non. AI debate is a bit besides the point. Engineers are stuck in the old paradigm of "perfect" algorithms.
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.
Hard disagree. We'll be able to use more expressive languages with better LLM support for understanding how to express ourselves and to understand compiler results. LLMs are only good at stuff that better languages don't require you to do. After that they fall off the cliff quickly.
LLMs are a communication technology, with a huge trained context of conversation. They have a long way to go before becoming anything intelligent.
LLMs lack intentionality, and they lack the ability to hold a series of precepts "in mind" and stick to those precepts. That is, if I say "I want code that satisfies properties A, B, C, D..." at some point the LLM just can't keep track of all the properties, which ones are satisfied, which ones aren't, what needs to be done or can be done to make them all satisfied.
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.
> LLMs ... lack the ability to hold a series of precepts "in mind" and stick to those precepts.
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.
> 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.
Or alternatively, we will build bigger and better things with the power of AI. Everyone talks about it replacing us, but we aren't running out of things to build. It's not like we're gonna run out of ways to improve the world, and compared to other things the digital world is unconstrained.
Depends on what you do, and what systems you develop for I would reckon. If it's another TODO app or some kind of table + form system that's been done to death - AI can probably have a go at creating a barebones minimal viable product. Targeting code that's outside the sweet spot of the training data ("blurry" area), you'll start to stumble. I've also found agents to be useless in large code bases with distributed logic where parts are in react, web back-end, service system). Slow and unreliable for large systems. Good for small tasks and scaffolding up proof of concepts.
This comment captures it.
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?
Are you still going to have the skills to review it a year from now? Or 5 years from now when you’ve become accustomed to only writing <20% of the code? I’m already witnessing my coworkers skills degrading because of this, and it’s only going to get worse. Programming is a language, and when you don’t use it, it fades.
What will happen is that we as developers will move one layer up in the abstraction. In the future it would seem a bit nonsensical to focus on individual lines of code and syntax because AI can more or less deal with it.
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.
Anyone old enough to remember when UML promised the same thing? Never have to touch code again -- just draw boxes, charts, activity diagrams, etc. and right-click and generate code! Rational Rose is the future of programming!
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.
Yes, and in the enterprise space, many workflows are nowadays done with lowcode/no-code tooling, like PowerApps, Adobe Workfront Fusion, Outsystems, among others.
Many of these tools, have started to go one step further, and the traditional ways are supplanted with AI, reducing even further the amount of low code/no code scenarios that a human has to produce.
The only thing left are the few serverless deployments to call into some code that needs more complex integration logic, and that is about it.
I have seen enough of these projects, to realize it is going to happen, not everywhere maybe, but in specific industry sectors certainly, it already is.
It's almost as if we write code because it is a very precise language... a feature that natural languages don't have.
I'm just going to leave this here...
You still communicate in code and fix the errors.
> You still communicate in code and fix the errors.
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?
I just said its not that important. Your time won't be spent coding but rather fixing stuff here and there.
... so how are you supposed to fix things without coding, given that you admitted you need to dive into the code to fix things?
Its not a binary - we will spend less time thinking about code and occasionally fix things and more time on higher level abstractions.
Just like I sometimes need to understand and dive into assembly but not always. Its a spectrum and the value in the spectrum changing has consequences for how we work.
That is wishful thinking. Every layer we added between humans and the machines (and even the ones in the machines themselves) take hordes of dedicated humans to maintain: IDEs, compilers/interpreters, linters, CI tools, assemblers, linkers, operating systems, firmware, microcode, circuitry, circuit elements (manufacturing processes).
Just about every time somebody on this site says “we developers”, you can assume they’re ignoring the (large majority of) developers that don’t work on the same things they do, in the same way.
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?
The point of abstraction is that it doesn’t leak. Most developers don’t need to understand compiler theory or assembly to be productive.
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.
I agree with you. But not many people work with or understand the abstraction at OS or circuitry level.
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.
if this is true we will have to trust committing prompts not code.
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)
> individual lines of code and syntax because AI can more or less deal with it
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.
If that’s a real effect, the best programmers absolutely will. You could spend 10% of your working time doing exercises, and still have double the productivity you used to have.
> Why do I need to waste time writing boring code?
Some people actually enjoy that, believe it or not.
seriously! excuse me while I cry with the artists about the robot doing the fun part. automate my goddamned dishes, not the coding! I chose this field because I liked that part ;_;
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 :(
I can highly recommend gardening. Even before LLM's I found it much more satisfying than coding as a hobby.
> Why do I need to waste time writing boring code?
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.
Yes who needs logging :)
This reminds me of the phenomenon of competence being inversely correlated with confidence until some inflection point is reached on the journey to mastery.
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.
The fear and pain of writing boring code gave us the processes and systems we have today. i.e. microservices, (I know they have their own problems) were born out of pain from maintaining monoliths. Agile (again, own problems) was born out of pain from waterfall.
What happens when all pain and boredom is taken away? Why do we need to invent new frameworks, systems, design patterns in that scenario?
What you shouldn't forget also is that, while AI may be good at coming up with a "first shot" solution, it may be much worse if you want to change/correct parts of it.
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.
This comment captures it: https://news.ycombinator.com/item?id=44906987
> 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
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.
However, from my experience, the quality of code produced by developers in project we are working for the last 3+ years gone south. Amount of bugs now literally tripled year on year. I bet the reason is extensive use of AI tools, as the developers are the same.
Its because most people don't have the discipline and obsession of attention to detail to know when one should use an LLM and when one shouldn't.
I highly doubt the best of the best folks are even touching LLMs (barely) because they can see the flaws and the tradeoffs that are not-so-visible to others until they are 50 levels deep, with sunk investments, unwilling to go back to how they used to do things.
But now, I'm not sure a lot of programmers even know what a profiler is. When was the last time you saw someone profile their code?
Problem is we've taken the idea of "minimum viable product" too far. People are saying "Doesn't have to be perfect, just has to work." I think most people agree. But with the current state of things? I disagree that things even work. We're so far away from the question of optimization. It's bad enough that there are apps that require several gigs to just edit a 30kb document but FFS we're living in a world where Windows Hello crashes Microsoft Outlook. It's not the programs are ugly babies that could be better, they are monstrosities begging to be put to death.
I WISH we could talk about optimization. I WISH our problem was perfectionism. But right now our problem is that everything is a steaming pile of garbage and most people are just shrugging their arms like "it is the way it is". Just because you don't clean up that steaming pile of garbage doesn't mean someone else doesn't. So stop passing the buck.
> When was the last time you saw someone profile their code?
A year ago. I heavily relied on one to optimize a complex data import that took an hour for a million line Excel file. The algorithm translated it to a graph according to a user-specified definition and would update an existing graph in neo4j, keeping the whole thing consistent.
The only other guy who understood the algorithm (a math PhD) thought it was as optimal as it could get. I used the profiler to find all the bottlenecks, which were all DB checks for the existence of nodes, and implemented custom indices to reduce import time from an hour to 3 minutes.
It did introduce a bunch of bugs that I had to fix, but I also discovered some bugs in the original algorithm.
It was one of my best programming experiences ever. Especially the payoff at the end when it went down from an hour to 3 minutes is a dopamine rush like never before. Now I want to optimize more code.
I don't think users cared, though; originally this work would take days by hand, so an hour was already pretty good. Now I made something fiendishly complex look trivial.
Seeing those big improvements and knowing you did more than make it faster is always really rewarding. I hope you do do more optimization :) Just remember Knuth's advice. Because IO is a common problem and Big O isn't going to tell you about that one haha
> Problem is we've taken the idea of "minimum viable product" too far. People are saying "Doesn't have to be perfect, just has to work." I think most people agree. But with the current state of things? I disagree that things even work. We're so far away from the question of optimization. It's bad enough that there are apps that require several gigs to just edit a 30kb document but FFS we're living in a world where Windows Hello crashes Microsoft Outlook. It's not the programs are ugly babies that could be better, they are monstrosities begging to be put to death.
LOL. OMG that was beautiful. It almost feels like we are de-evolving software to a state where shit is going to stop working bad. I know this is not full of facts, but this take reminds me of Jonathan Blow's video "Preventing the Collapse of Civilization"[0] Where he talks about how code runs worse than it ever has and I think he was arguing that civilization is collapsing before our eyes in slow time.
[0]: https://youtu.be/pW-SOdj4Kkk?si=LToItJb1Cv-GgB4q&t=1089
Good talk. I did something similar to him and all that happened is everyone was just saying I'm making a lot out of nothing. They're right that each thing was "nothing" but the problem is that this is a non-trivial number of "nothings" happening every day...
Honestly, I think the problem is that it's a Lemon Market[0]. Lemon markets thrive when there is asymmetric information. When a customer cannot tell the difference between a good product (peach) and a bad product (lemon). All it takes is a bunch of tech illiterate people... not sure where we'll find those...
On your video, funny thing. When I was in my PhD I had a very hard time publishing because I was building models that were much smaller, required less data, but got similar performance. Reviewers just looked at the benchmark like "not SOTA? lol". I've seen tons of great papers solving similar problems constantly get rejected. As a reviewer I frequently defended works like that as well as works that had good ideas but just didn't have enough GPU power. It was really telling...
[0] https://en.wikipedia.org/wiki/The_Market_for_Lemons
[P.S.] A nice solution I found for the pasting problem he mentioned (and in various forms) is that I first paste the text into the url bad or search bar then copy that and then paste. {<c-k>,<c-l>}<c-v><c-a><c-c>. Works 98% of the time every time.
I invite your attention to the StatsD telemetry protocol, where:
1. Every single measurement in a timeseries is encoded as a utf-8 string having (roughly) the following format:
where name is like "my.long.namespace.and.metric.name", value is a string formatted number, god only knows what type is, and tags is some gigantic comma separated key:value monstrosity.2. Each and every one of these things is fired off into the ether in the form of a UDP datagram.
3. Whenever the server receives these presumably it gets around sometime to assigning them timestamps and inserts them into a database, not necessarily in that or any other particular order.
"it is the way it is[1]."
[1] https://github.com/statsd/statsd?tab=readme-ov-file#usage
I think NodeJS goes against the idea of writing good and efficient software... JS just creates unnecessary complexity
Engineering isn't stuck on perfect algorithms. Management is. There's lip service for AI code gen, but if my name is on a module, I still have to vouch for its correctness. If it's wrong, that might become my problem. I don't always write perfect code, but I aspire to. If I see evidence that these tools are writing more correct and reliable code than I do, then I will start to take it more seriously. For some code, it matters whether it's robust basically.
Yep, I don't think you'll ever see AI code near the payment system. Or the code managing the store and the cart systems.
Another hard disagree. The crux here is that if u are not an expert in the given domain you do not know where that missing 25% is wrong. You think you do but you dont.
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.
<< you do not know where that missing 25% is wrong
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.
Exactly. I use ai tools daily and they bite me. Not enough to stop but enough to know. Recently was building a ws merger of sorts based on another libs sub protocol. I wasnt familiar with the language or protocol but ai sure was. However the ai used a wrong id when repacking messages. Unless i knew the spec (which i didnt) i never would have known. Eventually, i did read the spec and figured it out.
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.
The analogy seems to fall apart because the quality of an assembly line produced car is higher than the hand crafted one. Fords lose out because they engineer to a price point, a Ferrari doesn't have that "problem" - arguably, the more expensive the better.
>The analogy falls apart because the quality of an assembly line produced car is higher than the hand crafted one.
What? So Your Jeep Compass is higher quality than a 458?
try driving a ferrari 80,000 miles without taking it into the shop...
Yeah, I'm trying to branch out to build things outside my comfort zone. AI already is helpful in my normal day-to-day (backend engineer, mostly Python w/ PyCharm/Datagrip working in monorepo style), but Claude Code helped me graft on a Typescript/Javascript UI ecosystem with an independent Webstorm IDE setup that will integrate well, along with all the presumably latest build tools and package management. The research and self-education I would have needed to do this without Claude would have been extensive, and would have been nowhere as complete. I don't see any point in going back to pre-AI. And I don't generally use AI results blindly, I go back and review and set some breakpoints in an IDE and watch it do its thing.
Why are you assuming the cases where humans can code better than AI still exists after three years say -- I think in some industries today artisanal products are also not higher quality than machine made ones.
Progress under current paradigms has gotten much slower
Extraordinary claims require extraordinary evidence and if there's one thing we've learned is that progress in AI is not linear nor predictable. We've been a few years away from fully self-driving cars for a really long time now.
IMO LLMs have demonstrated how uncomplicated the man behind the curtain really is. If we do happen to achieve AGI it will likely have many of the problems associated with the real thing which often fails in spectacular fashion.
> ChatGPT also knows more idioms and useful libraries than I do so I generally end up with cleaner code this way ...
... and can now measure my productivity in dependencies added per day! :)
Yeah, it's definitely shifting how we work. Feels like an upgrade from high-level languages, but we're still guiding the process. The performance boost is real, but once everyone adopts it, we'll probably just be building more complex things at a similar pace.
You are describing accurately where AI is now. But it wasn't there two years ago and it won't be there in two years. You still have 25% of your job today, but this will most likely gonna halve evey x-number of months.
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.
It would be good if there were a mode where AI trained the human operator as it worked, to reduce future reliance. Instead of just writing a document or editing a document, it would explain in a good amount of detail what it was doing, and tailor the information to the understanding level of the operator. It might even quiz the operator to assure understanding.
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.
Claude cli has this, called learning mode, and you can make custom modes to tweak it more
Can you describe how to access this feature? I can't find anything about this online, and I asked Claude on command line and nothing comes up for "learning mode"
Seems very cool.
update: perhaps it is the verbose flag, e.g. `claude --verbose` you were talking about?
I like this a lot...
Ah, cool. Is this meant to be used for learning specifically, or just something that can be toggled whenever you're using Claude to help you with anything?
https://openai.com/index/chatgpt-study-mode/
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.
> some people are going to be rendered completely helpless,
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!"
I think what we see is the final struggle between the Anglo-Saxon concept of Education ( Locke, Dewy) and the German concept of “Bildung” (Humboldt, Herder).
The former puts more emphasis on the pragmatic transmission of knowledge and socialisation, while the latter focuses on self formation via the gaining of knowledge.
People will always be educated, acquiring skills and being part of a society does not go out of fashion.
I am not sure the ideal of the “gebildeter Mensch” will survive. Self discovery through deep engagement with intellectual tasks requires exactly those skills AI tries to automatise.
The thing is, this is already occurring and seems to be OK as long as there exists a class of individuals who provide the intellectual horsepower to keep society moving forward.
But I feel very uncomfortable in the fact that people (who for whatever reason) can't make rational and responsible choices, are not being protected and free to exploitation.
I find that all of these discussions are rendered somewhat goofy by our very binary view of "programming" and "not programming."
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.
> 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.
Everyone who wants to. Right now the barrier is too high for some people who want to.
> Everyone who wants to.
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.
Rome wasn't built in a day, as they say. It takes time for the information to disseminate. Perhaps tools like this will be the watershed moment that speeds up the flow. Like the time back ~1990 when I received GFA BASIC on a magazine cover disk and it unlocked the knowledge that I could make anything I wanted to. It took me 33 years from then to get a Game Of The Year. Good things take time. Hopefully less in future :)
Congrats on your game of the year.
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.
"many people don't want to do this, no matter how easy it is --"
Lol lets get real. Most people want to live life and switch off their brain.
Absolutely nothing wrong with that - you can't fight what the body wants instinctively.
Oh sure. But it doesn't need to be everyone; my go-to analogy is how we used to do "cars" vs a lot of them now?
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.
This sounds great in theory but my my experience is that non tech people make horrible SE's. Even if they don't do the coding only participating in the spec. They simply don't even know what they don't know. Which is why SE exists and why these type of projects always fail to gain traction.
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)
Tools like Claude Code and OpenAI’s Codex CLI have boosted my productivity massively. They already handle about 90% of the coding work, and I just step in to finish the last 10%. Every month they get better, maybe in a year it’s 95%, in two years 97%, in three years 98%. We can all see where this is going.
You're an early adopter, so you're seeing massive gains. But eventually everyone gets the same productivity boost and that becomes the new baseline expectation.
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.
You are fortunate to have the pre-AI background experience to know how to recognize the 10%. People graduating college right now may never be so fortunate.
This doesn't just apply to software development - it applies across the board in any form of knowledge.
An example would be economics - an LLM can spit out a bunch of words about an economic model. But if you don't take the time to learn, visualise and understand it for yourself - it means nothing to you. And in that case, if you already possess mastery why would you waste your resources playing around with an inferior tool to you?
You wouldn't.
> They already handle about 90% of the coding work, and I just step in to finish the last 10%
So how many hours off work that 90% equates to?
Absolutely agreed. Thinking anything else is nothing but cope, and these comments are FULL of it. it would be laughable if they weren't so gate keepy and disengenuous about it.
AI can churn out code that works, but usable, secure code is written for humans first; clear, predictable, and safe by design. Until AI can reason like a team lead and think like an attacker, it’s still just guessing. Usability and security aren’t side effects, they’re intentions, and AI doesn’t have those yet. Code without security is useless[0]. [0] https://www.npr.org/2025/08/02/nx-s1-5483886/tea-app-breach-...
[dead]
> The case for writing and coding manually
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.
Yes.
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 think we’ll need to rethink what it means to be “skilled.” Fewer people will write every line of code themselves, but more will need to understand systems end-to-end, ask the right questions, and guide AIs to meaningful outcomes.
AI isn’t replacing thinking, it’s changing what we think about. Coding skill won’t disappear; it’ll just evolve.
This is the direction it was (and should be) heading in anyways. We're pumping out so many CS grads that pure technical skill is less valued than everything surrounding it.
And get off my lawn.
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?
The argument against relying on AI for everything is that the humans who curate and architect systems learned what they did through their experience at lower levels.
Overutilization of AI is pulling the ladder up and preventing the next generation of software architects and engineers from learning through experience.
well said
Yes, it will replace human thinking. Thats quite literally the explicit goal of every AI company.
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
At best it churns out mediocre to poor code so it’ll produce mediocre to poor thinking.
I wonder if some of the proponents know where the line is in the art. I suspect not.
ai gen code is slow, tedious to review, generally shit, and a waste of time.
if you need gen ai to be an efficient dev then you are bad at your job.
It used to be reading and writing were skills. People would strive to get better, usually by steeping themselves in the work of better writers so some rubs off.
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.
The people who do this will probably fall behind, and will maybe learn from that lesson in the long run.
Most people have only one chance to learn reading and writing, when they are kids. After that it gets exponentially harder.
Well I am not talking specifically about reading and writing. I am talking about the concept in general.
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.
When has that ever happened?
You are saying people who took shortcuts and fell behind because of it never learned a lesson from that? Not saying everyone would, but definitely some people do.
on an individual level it happens all the time, but I'm not sure it's ever happened broadly on a societal level?
No reason to feel sorry for others. Follow your path, don't look behind.
“I say ‘your civilization’ because once we started thinking for you it really became our civilization.”
The replacement of reading books and writing letters with television/video streaming and phone/texting has done far more to depress average human cognitive skills than LLM code and text generation could ever hope to achieve.
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.
"instead think of it as a politely-adversarial low-trust relationship."
Lol... this sounds terrible.
AI is using the well known Embrace Extend Extinguish strategy, coined by Microsoft. Today corporations push us to embrace AI by all means possible, and use where it's useful and where it's not useful. Tomorrow AI will extend our ways of thinking and working in such a ways that we'll have to rely on it, like a medicine that you'd rather not use, but got dependent on. And then AI will extinguish us, for its main selling point is it replaces employees, makes them unnecessary. That's the plan, at least.