I had stumbled upon Kidlin’s Law—“If you can write down the problem clearly, you’re halfway to solving it”.
This is a powerful guiding principle in today’s AI-driven world. As natural language becomes our primary interface with technology, clearly articulating challenges not only enhances our communication but also maximizes the potential of AI.
The async approach to coding has been most fascinating, too.
I will add, I've been using Repl.it *a lot*, and it takes everything to another level. Getting to focus on problem solving, and less futzing with hosting (granted it is easy in the early journey of a product) - is an absolute game changer. Sparking joy.
I personally use the analogy of mario kart mushroom or star; that's how I feel using these tools. It's funny though, because when it goes off the rails, it really goes off the rails lol. It's also sometimes necessary to intercept decisions it will take.. babysitting can take a toll (because of the speed of execution). Having to deal with 1 stack was something.. now we're dealing with potential infinite stacks.
Because I can never focus on just one thing, I have a philosophy degree. I’ve worked with product teams and spent lots of time with stakeholders. I’ve written tons of docs because I was the only one on the team who enjoyed it.
I’ve always bemoaned my distractibility as an impediment to deep expertise, but at least it taught me to write well, for all kinds of audiences.
I think about this a lot. Early on, as a self taught engineer, I spent a lot of time simply learning the vernacular of the software engineering world so that I could explain what it was that I wanted to do.
Repl.it is so hit or miss for me, and that's that is so frustrating. Like, it can knock out something in minutes that would have taken me an afternoon. That's amazing.
Then other times, I go to create something that is suggested _by them below the prompt box_ and it can't do it properly.
The fact that you think it was suggested _by_ them is I think where your mental model is misleading you.
LLMs can be thought of metaphorically as a process of decompression, if you can give it a compressed form for your scenario 1 it'll go great - you're actually doing a lot of mental work to arrive at that 'compressed' request, checking technical feasibility, thinking about interactions, hinting at solutions.
If you feed it back it's own suggestion it's no so guaranteed to work.
I don't think that the suggestions in the prompt box are being automatically generated on the fly for everyone. At least I don't see why they would be. Why not just have some engineers come up with 100 prompts, test them to make sure they work, and then hard-code those?
I would hope the suggestions in the prompt box are not being automatically generated by everyone else's inputs, I know what matters most is not the idea but execution but in the off hand you do have a really great and somewhat unique idea you probably wouldn't want it to be sent out to everyone who likes to take great ideas and implement it while you yourself are working on it.
You're misunderstanding me. Underneath the prompt box on the main page are suggestions of types of apps you can build. These are, presumably, chosen by people at the company. I'm not talking about things suggested within the chat.
The challenge is that clearly stating things is and always has been the hard part. It’s awesome that we have tools which can translate clear natural language instructions into code but even if we get AGI you’ll still have to do that. Maybe you can save some time in the process by not having to fight with code as much but you’re still going to have to create really clear specs which, again, is the hard part.
Many years ago, in another millennium, before I even went to university but still was an apprentice (the German system, in a large factory), I wrote my first professional software, in assembler. I got stuck on a hard part. Fortunately there was another quite intelligent apprentice colleague with me (now a hard-science Ph.D.), and I delegated that task to him.
He still needed an explanation since he didn't have any of my context, so I bit the bullet and explained the task to him as well as I could. When I was done I noticed that I had just created exactly the algorithm that I needed. I just wrote it down easily myself in less than half an hour after that.
in my experience only a limited part of software can be done with just really clear specs, also at times in my career I have worked on things that became more "clear" what was really needed as time went on the more we worked on it, and in those cases really clear specs would have produced worse outcomes.
Which is the real reason agile is so much more effective than waterfall. The beginning of the project is when you know least about your project, so naturally you should be able to evolve the specification.
Maybe it is that LLM coding makes it easier to loop back with little regard for development cost. When you can spend an hour to fix what would have been hampered severely by technical debt late in the process - are we starting to omit optimizing for proper SDLC?
Generally I find that agile works because getting a really clear spec is so hard. You’re slowly iterating towards a clear spec. What is a finished piece of software if not a completed spec?
100% agree AI based dev is at odds with agile. You’re basically going to use the AI to fully rewrite the software over and over until the spec becomes clear which just isn’t very efficient. Plus it doesn’t help that natural language cannot be as clear a spec as code.
I've found LLMs to be a key tool in helping me articulate something clearly. I write down a few half-vague notes, maybe some hard rules, and my overall intent and ask it to articulate a spec, and then ask to for suggestions, feedback, questions to clarify from a variety of perspectives. This gives me enough material to clarify my actual requirements and then ask for that be broken down into a task list. All along the way I'm both refining my mental model and written material to more clearly communicate my intent to both machines and humans.
Increasingly I've also just ben YOLOing single shot throw-away systems to explore the design space - it is easier to refine the ideas with partially working systems than just abstract prose.
I'm loving the new programming. I don't know where it goes either, but I like it for now.
I'm actually producing code right this moment, where I would normally just relax and do something else. Instead, I'm relaxing and coding.
It's great for a senior guy who has been in the business for a long time. Most of my edits nowadays are tedious. If I look at the code and decide I used the wrong pattern originally, I have to change a bunch of things to test my new idea. I can skim my code and see a bunch of things that would normally take me ages to fiddle. The fiddling is frustrating, because I feel like I know what the end result should be, but there's some minor BS in the way, which takes a few minutes each time. It used to take a whole stackoverflow search + think, recently it became a copilot hint, and now... Claude simply does it.
For instance, I wrote a mock stock exchange. It's the kind of thing you always want to have, but because the pressure is on to connect to the actual exchange, it is often a leftover task that nobody has done. Now, Claude has done it while I've been reading HN.
Now that I have that, I can implement a strategy against it. This is super tedious. I know how it works, but when I implement it, it takes me a lot of time that isn't really fulfilling. Stuff like making a typo, or forgetting to add the dependency. Not big brain stuff, but it takes time.
Now I know what you're all thinking. How does it not end up with spaghetti all over the place? Well. I actually do critique the changes. I actually do have discussions with Claude about what to do. The benefit here is he's a dev who knows where all the relevant code is. If I ask him whether there's a lock in a bad place, he finds it super fast. I guess you need experience, but I can smell when he's gone off track.
So for me, career-wise, it has come at the exact right time. A few years after I reached a level where the little things were getting tedious, a time when all the architectural elements had come together and been investigated manually.
What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.
> What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.
Exactly my thinking, nearly 50, more than 30 years of experience in early every kind of programming, like you do, I can easily architect/control/adjust the agent to help me produce great code with a very robust architecture. By I do that out of my experience, both in modelling (science) and programming, I wonder how the junior devs will be able to build experience if everything comes cooked by the agent. Time will tell us.
I feel like we've been here before, and there was a time when if you're going to be an engineer, you needed to know core equations, take a lot of derivatives, perform mathematical analysis on paper, get results in an understandable form, and come up with solutions. That process may be analogous to what we used to think of as beginning with core data structures and algorithms, design patterns, architecture and infrastructure patterns, and analyzing them all together to create something nice. Yet today, much of the lower-level mathematics that were previously required no longer are. And although people are trained in their availability and where they are used, they form the backbone of systems that automate the vast majority of the engineering process.
It might be as simple as creating awareness about how everything works underneath and creating graduates that understand how these things should work in a similar vein.
Exactly right now, I am helping a big oil and gas company have a process simulation software to correctly converge on a big simulation. Full access to the source code, need to improve the Newton method in use with the right line search, validate the derivatives, etc.
I do think that for most of the people, you are right, you do not need to know a lot, but my philosophy was to always understand how the tool you use work (one level deeper), but now the tool is creating a new tool. How do you understand the tool which has been created by your Agent/AI tool?
I find this problem interesting, this is new to me and I will happily look at how our society and the engineering community evolve with these new capacities.
I don’t know how seniors will cope. You seem to have a solid understanding that you can make use of AI. But most seniors on HN struggle with basic tasks using AI. Juniors are likely to out pace them quickly. But potentially without the experience or understanding.
They cope just fine. If you’re thinking about stubborn ‘AI is just a statical parrot’ folks, IME it takes just one interaction where it clicks and nothing is the same afterwards. Perhaps we need GPT-5 or Gemini 3 for some of those people, but that’s what, a year out? Or a month?
Juniors need experience to know if the machine is going in the right direction or guide it. That experience is now nigh impossible to get, nobody has the time for apprentices now. It’ll take some brave management to pave a way forward, we don’t know what it’ll be exactly yet.
Really well said, it's a large amount of directing in additoin to anything else.
To continue this thought - what could have been different in the last 10-15 years to encourage junior developers to listen more where they might not have to those who were slightly ahead of them?
I also am enjoying LLMs, but I get no joy out of just prompting them again and again. I get so incredibly bored, with a little side of anxiety that I don’t really know how my program works.
I’ll probably get over it, but I’ve been realizing how much fun I get out building something as opposed to just having be built. I used to think all I cared about was results, and now I know that’s not true, so that’s fun!
Of course for the monotonous stuff that I’ve done before or don’t care a lick about, hell yeah I let em run wild. Boilerplate, crud, shell scripts, CSS. Had claude make me a terminal based version of snake. So sick
This is interesting. Maybe slow it down a bit? What I've found is I really need to be extremely involved. I approve every change (claude-code). I'm basically micromanaging an AI developer. I'm constantly reading and correcting. Sometimes I tell it to wait while I help it make some change it's hung up on.
There's no way I could hire someone who'd want me hovering over their shoulder like this.
This sounds tedious I guess, but it's actually quite zen, and faster than solo coding most of the time. It gives me a ton of confidence to try new things and new libraries, because I can ask it to explain why it's suggesting the changes or for an overview of an approach. At no point am I not aware of what it's doing. This isn't even close to what people think of as vibe coding. It's very involved.
I'm really looking forward to increasing context sizes. Sometimes it can spin it's wheels during a refactor and want to start undoing changes it made earlier in the process, and I have to hard correct it. Even twice the context size will be a game changer for me.
I've always felt building something was close to artistry. You create something out of your thoughts, you shape it how you want and you understand how it works to the most minute detail. The amount of times I've shown something seemingly simple to someone and went "but wait this is what is actually happening in the background!" and started explaining something I thought was cool or clever are great memories to me. AI is turning renaissance paintings into mass-market printing. There's no pride, no joy, just productivity. It's precisely those repetitive, annoying tasks that lead you to create a faster alternative, or to think outside the box and find different ways. I just don't get the hype.
This is exactly what bothers me about the present moment. Not that the pride of craftsmanship is everything, but dialing it down to zero with extreme pressure to stay that way is a bit sad.
But we’ve clearly gone through this with other mediums before, perhaps someday people will appreciate hand written code the way we appreciate hand carved wood. Or perhaps we were all wasting time in this weird middle ground in the march of progress. I guess we’ll find out in 5-15 years.
Not every project one does will be or should be considered art or a source of joy and pride.
The boring CRUD apps that put the “bread on the table” are just that, a means to an end, they will not be your main source of pride or fulfillment. But somewhere in between there will be projects where you can put all your heart in and turn off that LLM.
Think of the countless boring weddings playlists a DJ has to do or the boring “give me the cheapest” single family homes an architect has to design.
Well, that's a good example. Why would you get a DJ when you can say "Siri, play Weddings Classics"? There's no humanity involved, no skills to read the room or cater to audiences. So you get a DJ; what if your DJ thinks his job or your event is boring and generates the same playlist you could have done yourself? You need passion, you need interest, you need to be involved. Otherwise every job becomes tedious, and humanity dies.
My biggest problem with working LLMs is that they don't understand negatives and they also fail to remember their previous instructions somehow.
For example:
If I tell it to not use X, it will do X.
When I point it out, it fixes it.
Then a few prompts later, it will use X again.
Another issue is the hallucinations. Even if you provide it the entire schema (I did this for a toy app I was working with), it kept on making up "columns" that don't exist. My Invoice model has no STATUS column, why do you keep assuming it's there in the code?
I found them useful for generating the initial version of a new simple feature, but they are not very good for making changes to an existing ones.
I've tried many models, Sonnet is the better one at coding, 3.7 at least, I am not impressed with 4.
I've tried many models, Sonnet is the better one at coding, 3.7 at least, I am not impressed with 4.
If Sonnet 3.7 is the best you've found, then no, you haven't tried many models. At least not lately.
For coding, I'd suggest Gemini 2.5 Pro, o3-mini-high, or Opus 4. I've heard good things about Grok 4 as well, so if you're OK with that whole scene and the guy who runs it, maybe give it a shot.
If you have already done so and still think Sonnet 3.7 is better than any of them, then the most likely explanation is that you got incredibly lucky with Claude and incredibly unlucky with the others. LLMs aren't parrots, but they are definitely stochastic.
> Now that I have that, I can implement a strategy against it. This is super tedious. I know how it works, but when I implement it, it takes me a lot of time that isn't really fulfilling. Stuff like making a typo, or forgetting to add the dependency. Not big brain stuff, but it takes time.
Are people implementing stuff from start to finish in one go? For me, it's always been iterative. Start from scaffolding, get one thing right,then the next. It's like drawing. You start with a few shapes, then connect them. After you sketch on top, then do a line art, and then you finish with values (this step is also iterative refinements). With each step, you become more certain of what you want to do, while also investing the minimum possible effort.
So for me coding is more about refactoring. I always type the minimal amount of code to get something to work. And it usually means shortcuts which I annotate with a TODO comment. Then I iterate over, making it more flexible, adds more flexibility, makes the code more clean.
so i guess that's a good argument for replacing employees with a bespoke LLM for your business-they will never leave after they're trained. and they never ask for a raise. and they dont need benefits or carry other human risks.
> I would normally just relax and do something else. Instead, I'm relaxing and coding.
So more work gets to penetrate a part of your life that it formerly wouldn't. What's the value of “productivity gains”, when they don't improve your quality of life?
Right, I’ve been using it recently for writing a message queue -> database bridge with checkpointing and all kinds of stuff (I work for a timeseries database company).
I saw this as a chance to embrace AI, after a while of exploring I found Claude Code, and ended up with a pretty solid workflow.
But I say this as someone who has worked with distributed systems / data engineering for almost 2 decades, and spend most of my time reviewing PRs and writing specs anyway.
The trick is to embrace AI on all levels: learn how to use prompts. learn how to use system prompts. learn how to use AI to optimize these prompts. learn how to first write a spec, and use a second AI (“adversarial critic”) to poke holes in that plan. find incompletenesses. delegate the implementation to a cheaper model. learn how to teach AI how to debug problems properly, rather than trying to one-shot fixes in the hope it fixes things. etc
It’s an entirely different way of working.
I think juniors can learn this as well, but need to work within very well-defined frameworks and probably needs to be part of college curriculum as well.
> So for me, career-wise, it has come at the exact right time. A few years after I reached a level where the little things were getting tedious, a time when all the architectural elements had come together and been investigated manually.
Wish I had your confidence in this. I can easily see how this nullifies my hard earned experience and basically puts me in the same sport as a more mid level or even junior engineer.
Have you had the realization that you could never go back to dealing with all the minutia again?
LLMs have changed me. I want to go outside while they are working and I am jealous of all the young engineers that won’t lose the years I did sitting in front of a screen for 12 hours a day while sometimes making no progress on connecting two black boxes.
Serious question: have you considered that dealing with all that minutiae and working through all that pain has made you capable to have the LLM write code?
Those young engineers, in 10 years, won't be able to fix what the LLM gave them,because they have not learned anything about programming.
They have all learned how to.micromanage an LLM instead.
> Those young engineers, in 10 years, won't be able to fix what the LLM gave them,because they have not learned anything about programming.
I have heard a version of this plenty of times, and it was never correct. In the early 90s it was the "electronics" people that were saying "I come from an electronics background, these young'uns will look at a computer and don't know what to do if it breaks". Well, bob, we did, the whole field moved to color coded anti-stupid design, and we figured it out.
Then I heard it about IDEs. Oh, you young people are so spoiled with your IDEs and whatnot, real men code in a text editor.
Then it was about frameworks. BBbbut what if your framework breaks, what do you do then, if you don't know the underlying whatever?
Every single finance person uses a calculator. How effective do you think a person in any aspect of finance would be if they had never learned what multiplication is? Would they perform their job adequately if they don't know that `X * Y` is `X repeated Y times`?
IOW, if you gave a finance person (accountant, asset manager, whatever) a non-deterministic calculator for multiplication, would you trust the person's output if they never learned what multiplication is?
This is the situation I am asking about; we aren't talking about whether deterministically automating something that the user already knows how to do is valuable, we're talking about whether non-deterministically generating something that the user is unable to do themselves, even if given all the time in the world, is valuable.
All those examples you give are examples of deterministic automation that the user could inspect for accuracy. I'm asking about a near-future where people managing your money have never learned multiplication because "Multiplication has been abstracted away to a tool that gets it right 90% of the time"
If I may play the devil's advocate, nothing is deterministic. A neutrino could cause a bit flip in your calculator. More commonly, the lower abstractions we build upon without knowing their innards can have bugs. Even the most popular compilers (say, g++) have bugs, for instance. I am personally incapable of fixing a bug within gcc, despite the tool being a vital requirement of my work.
IMO the dichotomy should not be deterministic/stochastic, but proved/unproved reliable. gcc has been shown reliable, for instance, so I don't need to know whether it was built by deterministic (clever engineers) or stochastic (typewriting monkeys) processes. I'm certain the former are more efficient, but this is ultimately not what makes the tool valuable.
As a bit of an artificial example, there's stochastic processes that can be proved to converge to a desired result (say, a stochastic gradient descent, or Monte-Carlo integration), in the same way that deterministic methods can (say a classic gradient descent or quadrature rules).
In practical cases, the only proof that matters is empirical. I write (deterministic) mathematical algorithms for a living, yet they very rarely come out correct on first iteration. The fact there is a mathematical proof that a certain algorithm yields certain results lets me arrive at a working program much faster than if I left it to typewriting monkeys, but it is ultimately not what guarantees a valid program. I could just as well, given enough time, let a random text file generator write the programs, and do the same testing I do currently, it would just be very inefficient (an understatement).
Yup, my mom used to say "you need to be able to do it without a calculator, because in life you won't always have a calculator with you"... Well, guess what mom :)
But on a serious note, what I'm trying to say (perhaps poorly worded) is that this is a typical thing older generations say about younger ones. They'll be lost without x and y. They won't be able to do x because they haven't learned about y. They need to go through the tough stuff we went through, otherwise they'll be spoiled brats.
And that's always been wrong, on many levels. The younger generations always made it work. Just like we did. And just like the ones before us did.
There's this thing that parents often do, trying to prepare their children for the things they think will be relevant, from the parent's perspective. And that often backfires, because uhhh the times are achanging. Or something. You get what I'm trying to say. It's a fallacy to presuppose that you know what's coming, or that somehow an entire generation won't figure things out if they have a shortcut to x and y. They'll be fine. We're talking about millions / billions of people eventually. They'll figure it out.
Junior engineers will be lost if they don't take the time to read the code generated by the LLM and really understand it. This is an objective truth. It has nothing to do with boomer takes.
Funny, that's what I said, as an experienced assembly hacker, when somebody first showed me a C compiler.
People who "take the time to really understand the code" will rapidly be outcompeted by people who don't. You don't like that, I don't like that, but guess what: nobody cares.
I suppose we'll get over it, eventually, just like last time.
An unhealthy attachment to determinism will turn out to be a career-limiting hangup, I suspect. You already lack insight into how 100% of the code in your project works, unless you only work on trivial projects. Did you think that state of affairs was going to get better with time? As usual, TDD covers a multitude of sins.
As for "autocorrect," let us know when your "autocorrect" takes gold at the International Math Olympiad, with or without steroids.
I might offload multiplying some numbers to a calculator, but Kids These Days™ are trying to offload executive function, like "what should I do next" or "is there anything I've forgotten".
Developers throwing huge amounts of money (in cloud resources) at performance problems that would’ve been prevented if they had some understanding of how their tech stack actually worked.
> In the early 90s it was the "electronics" people that were saying "I come from an electronics background, these young'uns will look at a computer and don't know what to do if it breaks".
...and today, Nvidia ships self-immolating graphics cards because nobody wanted to figure out how to design a safe electric connector.
> Oh, you young people are so spoiled with your IDEs and whatnot, real men code in a text editor.
...and today, a lot of so-called programmers are trapped in AbstractHellFactorySingletonFactories that they cannot and never will understand, because generations of code monkeys have abused IDE assistance to dig themselves deeper into their hole.
And as a user, you'll know, because the software they write is garbage and never works reliably.
> Then it was about frameworks. BBbbut what if your framework breaks, what do you do then, if you don't know the underlying whatever?
Going by software like Teams, or Slack: They just ignore it, because consumers can't fight back against the the enshittification of increasingly useless software nobody understands.
That's a pretty good take. I was actually looking for a good analogy recently
I think if I was just starting out learning to program, I would find something fun to build and pick a very correct, typed, and compiled language like Haskell or Purescript or Elm, and have the agent explaining what it's doing and why and go very slow.
Hot take: Junior devs are going to be the ones who "know how to build with AI" better than current seniors.
They are entering the job market with sensibilities for a higher-level of abstraction. They will be the first generation of devs that went through high-school + college building with AI.
Where did they learn sensibility for higher-level of abstraction? AI is the opposite, it will do what you prompt and never stop to tell you its a terrible idea, you will have to learn yourself all the way down into the details that the big picture it chose for you was faulty from the start. Convert some convoluted bash script to run on Windows because thats what the office people run? Get strapped in for the AI PowerShell ride of your life.
The self-taught programmer's idea was coded by someone who is no smarter than they are. It will never confuse them, because they understand how it was written. They will develop along with the projects they attempt.
The junior dev who has agents write a program for them may not understand the code well enough to really touch it at all. They will make the wrong suggestions to fix problems caused by inexperienced assumptions, and will make the problems worse.
i.e. it's because they're junior and not qualified to manage anybody yet.
The LLMs are being thought of as something to replace juniors, not to assist them. It makes sense to me.
AI is the opposite, it will do what you prompt and never stop to tell you its a terrible idea
That's not true at all, and hasn't been for a while. When using LLMs to tackle an unfamiliar problem, I always start by asking for a comparative review of possible strategies.
In other words, I don't tell it, "Provide a C++ class that implements a 12-layer ABC model that does XYZ," I ask it, "What ML techniques are considered most effective for tasks similar to XYZ?" and drill down from there. I very frequently see answers like, "That's not a good fit for your requirements for reasons 1, 2, and 3. Consider UVW instead." Usually it's good advice.
At the same time I will typically carry on the same conversation with other competing models, and that can really help avoid wasting time on faulty assumptions and terrible ideas.
Do you think that kids growing up now will be better artists than people who spent time learning how to paint because they can prompt an LLM to create a painting for them?
Do you think humanity will be better off because we'll have humans who don't know how to do anything themselves, but they're really good at asking the magical AI to do it for them?
I think the argument is that growing up with something doesn't necessarily make you good at it. I think it rings especially true with higher level abstractions. The upcoming generation is bad with tech because tech has become more abstract, more of a product and less something to tinker with and learn about. Tech just works now and requires little in assistance from the user, so little is learned.
Yeah, I have a particular rant about this with respect to older generations believing "kids these days know computers." (In this context, probably people under 18.)
The short version is that they mistake confidence for competence, and the younger consumers are more confident poking around because they grew up with superior idiot-proofing. The better results are because they dare to fiddle until it works, not because they know what's wrong.
I think this disregards the costs associated with using AI.
It used to be you could learn to program with a cheap old computer a majority of families can afford. It might have run slower, but you still had all the same tooling that's found on a professional's computer.
To use LLMs for coding, you either have to pay a third party for compute power (and access to models), or you have to provide it yourself (and use freely available ones). Both are (and IMO will remain) expensive.
I'm afraid this builds a moat around programming that will make it less accessible as a discipline. Kids won't just tinker they way into a programming career as they used to, if it takes asking for mom's credit card from minute 0.
As for HS + college providing a CS education using LLMs, spare me. They already don't do that when all it takes is a computer room with free software on it. And I'm not advocating for public funds to be diverted to LLM providers either.
At one hand you get insane productivity boost, something that could take maybe days, weeks or months to do now you can do in significantly shorter amount of time, but how much are you learning if you are at a junior level and not consciously being careful about how you use it, feels like it can be dangerous without a critical mindset, where you eventually rely too much on it that you can't survive without it. Or maybe this is ok? Perhaps the way of programming in the future should be like this, since we have this technology now, why not use it?
Like there's a mindset where you just want to get the job done, ok cool just let the llm do it for me (and it's not perfect atm), and ill stitch everything together fix small stuff that it gets wrong etc, saves alot of time and sure I might learn something in the process as well.
And then the other way of working is the traditional way, you google, look up on stackoverflow, read documentations, you sit down try to find out what you need and understand the problem, code a solution iteratively and eventually you get it right and you get a learning experience out of it. Downside is this can take 100 years, at the very least much longer than using an llm in general. And you could argue that if you prompt the llm in a certain way, it would be equivalent to doing all of this but in a faster way, without taking away from you learning.
For seniors it might be another story, it's like they have the critical thinking, experience and creativity already, through years of training, so they don't loose as much compared to a junior. It will be closer for them to treat this as a smarter tool than google.
Personally, I look at it like you now have a smarter tool, a very different one as well, if you use it wisely you can definitely do better than traditional googling and stackoverflow. It will depend on what you are after, and you should be able to adapt to that need. If you just want the job done, then who cares, let the llm do it, if you want to learn you can prompt it in certain way to achieve that, so it shouldn't be a problem. But this sort of way of working requires a conscious effort on how you are using it and an awareness of what downsides there could be if you choose to work with the llm in a certain way to be able to change the way you interact with the llm. In reality I think most people don't go through the hoops of "limiting" the llm so that you can get a better learning experience. But also, what is a better learning experience? Perhaps you could argue that being able to see the solution, or a draft of it, can be a way of speeding up learning experience, because you have a quicker starting point to build upon a solution. I dunno. My only gripe with using LLM, is that deep thinking and creativity can take a dip, you know back in the day when you stumbled upon a really difficult problem, and you had to sit down with it for hours, days, weeks, months until you could solve that. I feel like there are some steps there that are important to internalize, that LLM nowdays makes you skip.
What also would be so interesting to me is to compare a senior that got their training prior to LLM, and then compare them to a senior now that gets their training in the new era of programming with AI, and see what kinds of differences one might find
I would guess that the senior prior to LLM era, would be way better at coding by hand in general, but critical thinking and creativity, given that they both are good seniors, maybe shouldn't be too different honestly
but it just depends on how that other senior, who are used to working with LLMs, interacts with them.
Also I don't like how LLM sometimes can influence your approach to solving something, like perhaps you would have thought about a better way or different way of solving a problem if you didn't first ask the LLM. I think this could be true to a higher degree for juniors than seniors due to gap in experience
when you are senior, you sort of have seen alot of things already, so you are aware of alot of ways to solve something, whereas for a junior that "capability" is more limited than a senior.
What you miss is the constant need to refine and understand the bigger picture. AI makes everyone a lead architect. A non-coder can't do this or will definitely get lost in the weeds eventually.
It doesn’t make everyone a lead architect, it just makes everyone think they’re a lead architect. What makes people a lead architect is a decade or two of experience in designing software and learning what works and doesn’t.
Right, but a lead architect can be a lead architect on multiple projects at the same time, and the world doesn't need as many lead architects as it has programmers.
This kind of working is relaxing and enjoyable until capitalism discovers that it is, and then you have to do it on five projects simultaneously.
I'm using AI assistants as an interactive search and coding assistant. I'm still driving the development and implementing the code.
Where I use it for is:
1. Remembering what something is called -- in my case the bootstrap pills class -- so I could locate it in the bootstrap docs. Google search didn't help as I couldn't recall the right name to enter into it. For the AI I described what I wanted to do and it gave the answer.
2. Working with a language/framework that I'm familiar with but don't know the specifics in what I'm trying to do. For example:
- In C#/.NET 8.0 how do I parse a JSON string?
- I have a C# application where I'm using `JsonSerializer.Deserialize` to convert a JSON string to a `record` class. The issue is that the names of the variables are capitalized -- e.g. `record Lorem(int Ipsum)` -- but the fields in the JSON are lowercase -- e.g. `{"ipsum": 123}`. How do I map the JSON fields to record properties?
- In C# how do I convert a `JsonNode` to a `JsonElement`?
3. Understanding specific exceptions and how to solve them.
In each case I'm describing things in general terms, not "here's the code, please fix it" or "write the entire code for me". I'm doing the work of applying the answers to the code I'm working on.
1. I usually just pull up the docs for the CSS framework, give it a quick look over to know what it offers and the nomenclature and then keep it open for all the code examples.
2. I've serialized json in enough languages to know the pain points, so what I usually do is locate the module/library responsible for that in that language. And then give the docs/code sample a quick lookover to know where things are.
3. With nice IDEs, you launch the debugger and you have a nice stack frame to go through. In languages with not so great tooling, you hope for a trace.
It's not that your workflow won't yield result. But I prefer to be able to answer 5 successive why's about the code I'm working on. With PRs taking hours and days to be merged, it's not like I'm in an hurry.
For 1 I tried looking through the bootstrap documentation but couldn't find it because they called it "Pills" and not what I was thinking. So I then tried google to search for it but that didn't work.
For 3 -- Sure, that can help. But sometimes it is difficult to follow what is going on. Especially if that comes from a library/framework you are unfamiliar with such as AWS.
I've also used it to help with build errors such as "Bar.csproj: Error NU1604 : Warning As Error: Project dependency Foo does not contain an inclusive lower bound. Include a lower bound in the dependency version to ensure consistent restore results." -- That was because it was using a fixed version of the module via the "[1.0]" syntax, but my version of NuGet and/or Rider didn't like that so once I new that and the range syntax specifying "[1.0, 1.0]" worked. I was able to understand that from the LLM response to the error message and telling it the specific `<PackageReference>`.
He's still telling the AI what to code. Prompting, i.e. deciding the right thing to build then clearly specifying and communicating it in English, is a skill in itself. People who spend time developing that skill are going to be more employable than people who just devote all their time to coding, the thing at which LLMs are more cost effective.
My theory on AI is it's the next iteration of google search, a better more conversational, base layer over all the information that exists on the internet.
Of course some people will lose jobs just like what happened to several industries when search became ubiquitous. (newspapers, phone books, encyclopedias, travel agents)
But IMHO this isn't the existential crisis people think it is.
It's just a tool. Smart, clever people can do lots of cool stuff with tools.
But you still have to use it,
Search has just become Chat.
You used to have to search, now you chat and it does the searching, and more!
Yeah; there's still a massive chasm between "I spent hours precisely defining my requirements for this greenfield application with no users and the AI one-shot it" and "million line twenty team enterprise SaaS hellscale with ninety-seven stakeholders per line of code".
The fact that AI can actually handle the former case is, to be clear, awesome; but not surprising. Low-code tools have been doing it for years. Retool, even back in 2018, was way more productive than any LLMs I've seen today, at the things Retool could do. But its relative skill at these things, to me, does not conclusively determine that it is on the path toward being able to autonomously handle the latter.
The english language is simply a less formal programming language. Its informality means it requires less skill to master, but also means it may require more volume to achieve desired outcomes. At some level of granularity, it is necessarily the case that programming in english begins to look like programming in javascript; just with capital letters, exclamation points, and threats to fire the AI instead of asserts and conditionals. Are we really saving time, and thus generating higher levels of productivity? Or, is its true benefit that it enables foray into languages and domains you might be unfamiliar with; unlocking software development for a wider range of people who couldn't muster it before? Its probably a bit of both.
Dario Amodei says we'll have the first billion dollar solo-company by 2026 [1]. I lean toward this not happening. I would put money on even $100M not happening, barring some level of hyperinflation which changes our established understanding of what a dollar even is. But, here's what I will say: hitting levels of revenue like this, with a human count so low that the input of the AI has to overwhelm the input from the humans, is the only way to prove to me that, actually, these things might be more than freakin awesome tools. Blog posts from people making greenfield apps named after a furrsona DJ isn't moving the needle for me on this issue.
AI is still in an experimental phase for many teams, especially when it comes to handling complex, long-term projects. For PMs and EMs, the cost-benefit analysis of AI credits vs. manual tasks is a big concern before fully committing to AI adoption. Some teams have seen great success, particularly in areas where speed and flexibility are key, but others are still waiting for clearer ROI before diving in. It’ll be interesting to see how the balance of risk and reward evolves as AI tools mature.
Reason 1: Because any company with one individual who leverages AI to achieve a billion dollar valuation would trivially & obviously be more valuable and be able to achieve more if they had two people leveraging AI. And, at a billion dollar valuation; why not pay that extra salary? Why not add a third? There's a huge difference in potential output by building with a founder team of 2 or 3 people versus 1; with not that much difference in cost.
Reason 2: The most capital efficient valuations in history are B2C companies (Instagram & Whatsapp are maybe the two best examples) during the VC boom era of the 2010s. B2C is naturally very capital efficient; you can do inbound marketing, no sales teams, just build. But, B2C success stories are more-and-more rare; the name of the game in the 2020s era has generally been B2B. Cursor might be the fastest company to reach $500M in revenue, and it got there on B2B, Notion isn't building its AI tools to sell to its consumer customers, etc. B2B is a lot harder; it requires outbound marketing & sales, as well as customer-led product development that usually requires interacting with people. AI will absorb some of those roles, but to suggest it can widdle down to one person per billion dollars in valuation in a year feels too accelerated to me. The world is complex, old, and crusty.
Just look at the YC batches for 2025 [1]: Of the 375 companies in the three batches, 20 are Consumer tech (~5%).
Reason 3: Weaker, but something I think about: AI is weirdly non-differentiating/egalitarian. You see some people try to differentiate it with crazy prompts or context engineering, but then next month Cursor ships an update and suddenly those aren't differentiating anymore. If you're an investor in a single-person unicorn-moonshot, you have to ask: Why can't some other company just come in and do the same thing you're doing? If that much can be automated through off-the-shelf systems. My feeling is that this concern would lead to lower revenue multiples on the valuation, which just makes it that much harder to hit unicorn status.
There is certainly much innovation to come in this area.
I'm thinking about Personal Knowledge Systems and their innovative ideas regarding visual representations of data (mind maps, website of interconnected notes, things like that). That could be useful for AI search. What elements are doing in a sense is building concept web, which would naturally fit quite well into visualization.
The ChatBot paradigm is quite centered around short easily digestible narratives, and will humans are certainly narrative generating and absorbing creatures to a large degree, things like having a visually mapped out counter argument can also be surprisingly useful. It's just not something that humans naturally do without effort outside of, say, a philosophy degree.
There is still the specter of the megacorp feed algo monster lurking though, in that there is a tendency to reduce the consumer facing tools to black-box algorithms that are optimized to boost engagement. Many of the more innovative approaches may involve giving users more control, like dynamic sliders for results, that sort of thing.
English and other languages come with lots of ambiguity and assumptions. A significant benefit of programming languages is they have explicit rules for how they will be converted into a running program. An LLM can take many paths from the same starting prompt and deliver vastly different output.
I do agree… perhaps the thing to do is write fragments of the program, like the start and end, asking it to complete the middle. If you have precisely described how the output will be printed, for example, then you have essentially formally specified how the data should be organized…
Famously complicated interface with a million buttons and menus.
Now there's more buttons for the AI tools.
Because at the end of the day, using a "brush" tool to paint over the area containing the thing you want it to remove or change in an image is MUCH simpler than trying to tell it that through chat. Some sort of prompt like "please remove the fifth person from the left standing on the brick path under the bus stop" vs "just explicitly select something with the GUI." The former could have a lot of value for casual amateur use; it's not going to replace the precise, high-functionality tool for professional use.
In software - would you rather chat with an LLM to see the contents of a proposed code change, or use a visual diff tool? "Let the agent run and then treat it's stuff as a PR from a junior dev" has been said so many times recently - which is not suggesting just chatting with it to do the PR instead of using the GUI. I would imagine that this would get extended to something like the input not just being less of a free-form chat, but more of a submission of a Figma mockup + a link to a ticket with specs.
> Famously complicated interface with a million buttons and menus.
Photoshop is quite nice for an expert tool. Blender is the complicated one where you have to get a full-sized keyboard and know a handful of shortcuts to have a normal pace.
> The former could have a lot of value for casual amateur use; it's not going to replace the precise, high-functionality tool for professional use.
I was just discussing that in another thread. Most expert works are routine, and they will build workflows, checklists, and processes to get them to be done with the minimum cognitive load. And for that you need reliability. Their focus are on the high leverage decision points. Take any digital artist's photoshop settings, They will have a specific layout, a few document templates, their tweaked brushes. And most importantly, they know the shortcuts because clicking on the tiny icons takes too much times.
The trick is not about being able to compute, it's knowing the formula and just give the parameters to a computer that will do the menial work. It's also not about generating a formula that may or may not be what we want.
There’s an efficient way to serve the results, and there’s an efficient way for a human to consume them, and I find LLMs to be much more efficient in terms of cognitive work done to explore and understand something than a google search. The next thing will have to beat that level of personal mental effort, and I can’t imagine what that next step would look like yet.
I find a well-written human article or guide to be far more efficient when it exists. But if AI rehash them... then the market for those may disappear, and in the process, the AI won't be very good either without the source to summarise.
I don’t disagree with that at all, but that’s not what I’m talking about. The market for serving information goes where the people want to consume it. The old portals of the 90s gave way to search because it was easier for people to find what they wanted. LLMs give people an even easier way to find information. The downstream effects don’t factor into most people’s decision to use an LLM over source material.
Search wasn't just "search". It was "put a prompt in a form and then spend minutes/hours going through various websites until I get my answer". LLMs change that. I don't have to go through 20 different people's blog posts on "Which 12v 100Ah LifePO4 battery tests for the highest watt hours", the LLM simply just gives me answer that is most relevant across those 20 blog posts. It just distilled what I would have taken an hour to do down to seconds or 2 minutes.
Yup. Now you get a quick reply and have to then do the same job as before to validate it. Except all websites are deploying crawler countermeasures so it takes even longer now.
A lot of modern entry-level jobs were filled by people who knew how to use google and follow instructions.
I imagine the next generation will have a similar relationship with AI. What might seem "common sense" with the younger, more tech-saavy crowd, will be difficult for older generations whose default behavior isn't to open up chatgpt or gemini and find the solution quickly.
I was a bit wary of trusting the AI summaries Google has been including in search results… but after a few checks it seems like it’s not crap at all, it’s pretty good!
I think their point is that all of the content out there is turning in to AI Slop so it won't matter if search changes because the results themselves have already been changed.
I have systemic concerns with how Google is changing roles from "knowledge bridging" to "knowledge translating", but in terms of information: I find it very useful.
Always check the sources. I've personally found it;
- Using a source to claim the opposite of what the source says.
- Point to irrelevant sources.
- Use a very untrustworthy source.
- Give our sources that do not have anything to do with what it says.
- Make up additional things like any other LLM without source or internet search capability, despite reading sources.
I've specifically found Gemeni (the one Google puts at the top of searches) is hallucination-prone, and I've had far better results with other agents with search capability.
So... presenting a false or made-up answer to a person searching the web on a topic they don't understand... I'd really like to see a massive lawsuit cooked up about this when someone inevitably burns their house down or loses their life.
I’ve had to report AI summaries to Google several times for telling me restaurant items don’t contain ingredients I'm allergic to, when the cited “source” allergen menu says otherwise. They’re gonna kill someone.
As search gives the answer rather than the path to it, the job of finding things out properly and writing it down for others is lost. If we let that be lost, then we will all be lost.
If we cannot find a way to redirect income from AI back to the creators of the information they rehash (such as good and honest journalism), a critical load-bearing pillar of democratic society will collapse.
The news industry has been in grave danger for years, and we've seen the consequences it brings (distrust, division, misinformation, foreign manipulation). AI may drive the last stake in its back.
It's not about some jobs being replaced; that is not even remotely the issue. The path we are on currently is a dark one, and dismissing it as "just some jobs being lost" is a naive dismissal of the danger we're in.
The economic viability to do proper journalism was already destroyed by the ad supported click and attention based internet. (and particular the way people consume news through algorithmic social media)
I believe most independent news sites have been economically forced into sensationalism and extremism to survive. Its not what they wilfully created.
Personally, i find that any news organisations that is still somewhat reputable have source of income beyond page visits and ads; Be it a senior demorgaphic that still subscribe to the paper, loyal reader base that pay for the paywall, or government sponsoring its existence as public service.
Now what if you cut out the last piece of income journalists rely on to stay afloat? We simply fire the humans and tell an AI to summarise the other articles instead, and phrase it how people want to hear it.
My take is that journalists, was fighting enshittification as long as they could one looming bankruptcy leading to consolidation or closed shop at a time.
I agree that people are using it for things they would've googled, but I doubt that it's a good replacement.
To me it mostly comes with a feeling of uncertainty. As if someone tells you something he got told on a party. I need to Google it, to find a trustful source for verification, else it's just a hint.
So I use it if I want a quick hint. Not if I really want to have information worth remembering. So it's certainly not a replacement for me. It actually makes things worse for me because of all that AI slop atm.
I tend to generally think the same as you, as I work in the same field. A long time ago I thought to myself, if AI adoption increases exponentially, there is a chance that the amount of security vulnerabilities introduced by it also increases at the same rate.
However, what we are maybe not considering enough is that general AI adoption could and almost certainly will affect the standards for cybersecurity as well. If everyone uses AI and everyone gets used to its quirks and mistakes and is also forgiving about someone else using it since they themselves use it too, the standards for robust and secure systems could decrease to adjust to that. Now, your services as a cybersecurity consultant are no longer in need as much, as whatever company would need them can easily point to all the other companies also caring less and not doing anything about the security issues introduced by the AI that everyone uses. The legal/regulation body would also have to adjust to this, as it is not possible to enforce certain standards if no one can adhere to them.
I don’t follow. Cybersecurity has always been about reducing the risk of costly cyber attacks. That hasn’t changed. It’s not like suddenly companies will stop caring that their software has been locked down by ransomware, or that their database leaked and now they have to pay a nine-figure fine. It’s not standards for standards’ sake (though it can feel that way). It’s loss prevention.
Sure, in the case of ransomware, phishing the ceo, etc. you are right. But for most other cases that AI would affect, it's not like companies would care if there weren't regulatory consequences forcing them to.
Why are we counting the number of documents? It doesn't matter. What matters is putting together a plan and being able to articulate what you want. Then review and adjust and prompt again.
You have to know how software gets built and works. You can't just expect to get it right without a decent understanding of software architecture and product design.
This is something that's actually very hard. I'm coming to grips with that slowly, because it's always been part of my process. I'm both a programmer and a graphic designer. It took me a long while to recognize not everyone has spent a great deal of time doing both. Fewer yet decide to learn good software design patterns, study frameworks and open-source projects to understand the problems each of them are solving. It takes a LOT of time. It too me probably 10-15 years just to learn all of this. I've been building software for over 20 years. So it just takes time and that's ok.
The most wonderful thing I see about AI is that it should help people focus on these things. It should free people from getting too far into the weeds and too focused on the code itself. We need more people who can apply critical thinking and design from a bird's eye perspective. We need people who can see the big picture.
Knowing is at least half the battle. Doesn't matter what kind of tools you intend to use if you don't even know where the job site is located.
I've been around the block a few times on ideas like a B2B/SaaS requirements gathering product that other B2B/SaaS vendors could use to collect detailed, structured requirements from their customers. Something like an open-world Turbo Tax style workflow experience where the user is eventually cornered into providing all of the needed information before the implementation effort begins.
> The most wonderful thing I see about AI is that it should help people focus on these things.
Unfortunately I’ve been around this industry long enough to know that this is not in fact what is going to happen. We will be driven by greedy people with small minds to produce faster rather build correct systems, and the people who will pay will be users and consumers.
I seem to have missed the part where he successfully prompted for security, internationalizability, localizability, accessibility, usability, etc., etc.
This is a core problem with amateurs pretending to be software producers. There are others, but this one is fundamental to acceptable commercial software and will absolutely derail vibe coded products from widespread adoption.
And if you think these aspects of quality software are easily reduced to prompts, you've probably never done serious work in those spaces.
what makes you think that the writer omitted these? Any good developer would include these parts of the requirements. That's why we make the money we do. We know what is involved. That is orthogonal to the use of LLMs for coding.
two years ago it didn’t do anything that made me want to use it during work.
The data wall idea of needing 10 more internets is like the peak oil theory of the 2000s, imho. I don’t think 10 more internets are required, and all those tasks like proper security and i18n, none of these require creativity of any kind. These are ideal candidates for LLMs to solve quite soon.
But to talk about the data wall more:
Current SOTA LLMs are trained on circa 30-50T tokens. First, that is not a full internet‘s worth; it is estimated that Meta owns more like 200T tokens of user data etc.
Second, the work in optimizing for data efficiency is just beginning.
>My four-document system? Spaghetti that happened to land in a pattern I could recognize. Tomorrow it might slide off the wall. That's fine. I'll throw more spaghetti.
Amazing that in July 2025 people still think you can scale development this way.
A bit part of this that people are not understanding is that a major part of the author's success is due to the fact that he clearly does not care at all how anything is implemented, mostly because he doesn't need to.
You get way farther when you have the AI drop in Tailwind templates or Shadcn for you and then just let it use those components. There is so much software outside that web domain though.
A lot of people just stop working on their AI projects because they don't realize how much work it's going to take to get the AI to do exactly what they want in the way that they want, and that it's basically going to be either you accept some sort of randomized variant of what you're thinking of, or you get a thing that doesn't work at all.
The input to output ratio is interesting. We are usually optimizing for volume of output, but now it’s inverted. I actually don’t want maximum output, I want the work split up into concrete, verifiable steps and that’s difficult to achieve consistently.
Ive taken to co-writing a plan with requirements with cursor and it works really well at first. But as it makes mistakes and we use those mistakes to refine the document eventually we are ready to “go” and suddenly it’s generating a large volume of code that directly contradicts something in the plan. Small annoyances like its inability to add an empty line after markdown headings have to be explicitly re added and re-reminded.
I almost wish I had more control over how it was iterating. Especially when it comes to quality and consistency.
When I/we can write a test and it can grind on that is when AI is at its best. It’s a closed problem. I need the tools to help me, help it, turn the open problem I’m trying to solve into a set of discrete closed problems.
>I've been coding for long enough to remember when we carved HTML tables by hand. When CSS was a suggestion, not a lifestyle. When JavaScript was for mouseover effects and nothing else.
Cringe. The tech is half baked and the author is already fully committed to this is the future, I am living in the future, I bake cookies while Claude codes.
Pure cringe. This confirms my earlier theories that everyone just wants to be a manager. You don't need to manage humans. You just want to be a manager.
The whole article could be summed down to I always wanted to be a manager and now I am a manager of bots.
I've been experimenting with model-based development lately, and this resonated strongly with me.
The section "What Even Is Programming Anymore?" hit on a lot of the thoughts and feels I've been going through. I'm using all my 25+ years of experience and CS training, but it's _not_ programming per se.
I feel like we're entering an era where we're piloting a set of tools, not hand crafting code. I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse. We'll still need to craft things by hand, but we're opening some doors to new methodologies.
And, right now, those methodologies are being discovered, and most of us are pretty bad at them. But that doesn't mean they're not going to be part of the industry.
> I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse.
I think you're spot on. It was once necessary to acquire knowledge in order to acquire productivity. This made knowledge valuable and worth attaining. Now, with LLMs, we we can skip the middle man and go straight to the acquisition of productivity. I'd call it the democratisation of knowledge, but it's something more than that — knowledge just isn't needed anymore.
This kind of makes sense. I love acquiring knowledge, just for knowledges sake. That’s why I got into math and programming in the first place. I just like learning stuff. It was a happy accident that the stuff I like doing happens to also be lucrative. Kind of sucks that all that stuff I spent my life doing is losing value by the day. I love programming because there are an endless amount of things to learn. I actually care very little about the productivity.
I would argue we still need the knowledge: the principles aren't changing, and they are needed to be truly productive in certain things. But the application of those principles _are_ changing.
Which makes me wonder: why shouldn't AI use be a core part of technical interviews now? If we're trading "knowledge of how to code" for "knowledge of how to use LLMs" and treating Claude like a much more productive junior engineer, do we still need to filter candidates on their ability to write a doubly linked list? And if we are still asking those sorts of interview questions, why shouldn't candidates be able to use LLMs in the process? After all, like others have said elsewhere in this thread, you still need some core technical capabilities to effectively manage the AI. It's just a tool and we can judge how well someone knows how to use it or not.
There's a fundamental problem with your question, which is the suggestion that technical interviews are still needed at all. Technical roles can be replaced with roles that are more akin to production managers, and we should absolutely be testing those candidates for LLM competency.
I don’t know which models you guys are working with, but all of the SOTA ones I’ve tried in different configurations ended up producing mostly garbage.
I find myself having to spend more time guiding the model in the right direction and fixing its mistakes than I would’ve spent building it all myself.
Every time I read one of these stories I feel like maybe you guys have models from 2035, because the ones we have today seem to be useless outside of creating greenfield, simple React apps that just sort of work.
One thing I’ll say is that it’s been a real time saver for debugging. For coding, a huge waste of time. Even for tasks that are menial, repetitive, require no thinking etc. I find that it’s mostly crap.
this isn’t vibe coding. This is something completely new. I call it “flex coding.”
heck I built a full app in an afternoon AND I was a good dad?
> I'd wander into my office, check what Claude had built, test it real quick. If it worked, great! Commit and push. "Now build the server connection UI," I'd say, and wander back out.
Made breakfast. Claude coded.
Played with my son. Claude coded.
Watched some TV. Claude coded.
Every hour or so, I'd pop back in. Five minutes of testing. One minute of feedback.
This is all very emotive and I'm sure is a dream many of us would love to live.
But does Claude's code work? Does it work to the level where you'd depend on it yourself; where you'd bill customers for it; where you'd put your reputation behind it?
I say no. And it's because I use Claude. Two events changed how I use Claude: now it's an advisor, and I mostly type the code myself. Because I don't trust it.
First, I caught it copying one of my TypeScript interfaces and modifying it. So now we have User which looks like my actual user, that I defined, and UserAgain which does not, and which Claude is now using and proudly proclaiming that my type checks all pass. Well of course they do!
Second, I was told that the best way to catch this sort of thing is to get it to write tests. So it wrote some tests, and they failed, and it kept going, and it eventually wrote an un-failable test. The test mocked itself.
So, sure, enjoy time with your kids. Please don't ask me to use your app for anything important.
It's interesting reading comments on both sides of this. Some people are answering no, and others are answering yes to your question and succeeding at it... so far.
I've experienced the exact issues you've described. I've also drastically reduced these issues via good instructions and automated followup passes that eliminate code that was created from ignored instructions.
It all feels like a hack, but the more I choose to trust it and treat it like it's the correct path and that it's just a different set of problems that need to be solved, the more success I have.
I had Claude, as an agent, get into an infinite loop trying to resolve a diagnostic in Java test that any human would easily figured out and fixed in a second.
I feel that it is a commom thing. You just have to "keep an eye on it". There are several failure modes with Claude. Maybe the most annoying is that it often uses kind of defensive programming, so it is harder to detect that there is a fatal mistake somewhere. It can hide those really well. And it loves to fix linter issues with any type in typescript.
Im using it regardless. Ive just learnt to deal with these and keep an eye on them. When it creates a duplicate interface I roll back to earlier prompt and be more explicit that this type already exists.
I try to not argue whether something it does is wrong or right. There is not point. I will simply rollback and try with another prompt. Claude is not a human.
Because you can't do this yourself. You don't have the decades of experience to know how to ask the questions and when to steer the tool into a different direction.
Why not? As the AI people say "you can just do things". If there is little consequence to getting it wrong as a parent poster puts it why not? You can learn over time like any other skill.
I want to be wrong (it will affect me and my family personally) - but there is a reason every AI proponent talks about coding and making "coding redundant". For most jobs/industries software is a compliment (e.g. Product Owner, BA, etc) unless that is your main skill in which case it is your main service you are selling. Most roles want to turn software into a commodity or the typical business PM word "resource" that they can acquire as they need - the dream of most business roles (e.g. Project Managers, BA's, etc). It sadly also seems to be low hanging fruit of LLM's; doesn't mean there isn't other aspects to the job of course but coding is becoming "less special" with these technologies especially with common tech and use cases.
That's the real question IMO. Especially when everything that isn't deflationary with AI for the most part is getting much more expensive due to inflation globally. Save money on software, buy more blue collar goods.
If its an easy skill to learn, with little consequences if you get it wrong especially for small scale apps why pay for it? Don't know why seniors (of which I'm one) think they are immune to this.
consider it like this: you are not paying the amount of worked hours but for the expertise to judge, coach and guide the AI and its output according to your wishes. so if the result is good and within time and budget, why would you care?
Congratulations, you just passed project management class.
What you describe is exactly what a project manager does. Refines the technical, stories, organizes the development towards a goal.
This doesn’t feel like programming because it isn’t. It doesn’t NOT feel like programming because you’re supervising. In the end, you are now a project manager.
To me it feels like I’m in the camp of people who has already figured it out. And I have now learned the hard way that it’s almost impossible to teach others (I organized several meetups on the topic).
The ability seems like pure magic. I know that there are others who have it very easy now building even complex software with AI and delivering project after project to clients at record speed at no less of quality as they did before. But the majority of devs who won’t even believe that it’s remotely possible to do so is also not helping this style of building/programming mature.
I wouldn’t even call it vibe coding anymore. I think the term hurts what it actually is. For me it’s just a huge force multiplier, maybe 10-20x of my ability to deliver with my own knowledge and skills on a web dev basis.
I’ll try my hand at some guidelines: the prime directive would be “use the right ai tool for the right task”. Followed by “use a statically typed language”. Followed by “express yourself precisely in English. You need to be able to write like a good technical lead and a good product manager.”
With those out of the way:
Completions work when you’re doing lots of rote moderately difficult work within established patterns. Otherwise, turn them off, they’ll get in the way. When they do work, their entire point is to extend your stamina.
Coding agents work when at-worst a moderately novel vertical needs implementation. New architecture and patterns need to be described exhaustively with accurate technical language. Split up the agents work into the same sort of chunks that you would do between coffee breaks. Understand that while the agent will make you 5x faster, you’ll still need to put in real work. Get it right the first time. Misuse the agent and straightening out the mistakes will cost more time than if you hadn’t used the agent at all.
If novelty or complexity is high, use an advanced reasoning model as interactive documentation, a sparring partner, and then write the code by hand. Then ask the reasoning model to critique your code viciously. Have the reasoning model configured for this role beforehand.
These things together have added up to the biggest force multiplier I’ve encountered in my career.
> If novelty or complexity is high, use an advanced reasoning model as interactive documentation, a sparring partner, and then write the code by hand. Then ask the reasoning model to critique your code viciously. Have the reasoning model configured for this role beforehand.
Does this mean basically "Opus"? What goes into "Have the reasoning model configured for this role beforehand."?
Just record yourself doing it and post online. If the projects are indeed complex and you’ve found a way to be 20x more productive people will learn from it.
The problem is not having any evidence or basis on which to compare claims. Alchemists claimed for centuries to synthesize gold, if they only had video we could’ve ruled that out fast.
The spec, or prompts system, whatever you call it, is more like a recipe than code.
It doesn't automatically generate the dishes; a good cook is still needed.
I disagree with the OP that AI coding can't be taught. My answer to why so many people have trouble would be that they refuse to learn. I see tons of people who are insanely biased against AI and then when they try and use it they give up after the first go (having tried a horrible application of AI like making a functioning production app with 1 single prompt, no one using AI for work is using it like that). They also don't take any suggestions on using it better because "I've tried it before and it sucked."
If you asked me months ago whether "prompt engineering" was a skill I'd have said absolutely not, it's no different than using stack overflow and writing tickets, but having watched otherwise skilled devs flounder I might have to admit there is some sort of skill needed.
I fully expect that in 1-2 years that SWE curriculum will have AI coding as a major feature. The question I have is will students be required to do their first year or first assignments in a given course without AI.
My ex teaches UX. We were talking about AI in academia last week. She said that she requires students to not use AI on their first assignment but on subsequent ones they are permitted to.
I work in a large corpo eco system of products across languages that talk to a mess of micro and not so micro services.
Ai tools are rarely useful out of the box in this context. Mostly because they can't fit the ecosystem into their context. I think i would need 10 agents or more for the task.
We have good documentation, but just fitting the documentation into context alongside a microservice is a tight fit. Most services would need one agent for the code (and even then it'd only fit 10% in context), and one for the docs.
Trying to use them without sufficient context, or trying to cram the right 10% into context, takes more effort than just coding the feature, and produces worse results with the worst kind of bugs, subtle ones borne from incorrect assumptions.
I've noticed a great deal programmers, very good programmers at that, that completely underestimate how fast things are moving. They're natural skeptics, and checked out ChatGPT when it was released. Then they maybe checked out some other models a year after. But eventually wrote it off as hype, and continue to do things their way. You know, artisanal code and all that.
I think that if you willfully ignore the development, you might be left in the dust. As you say, it is a force multiplier. Even average programmers can become extremely productive, if they know how to use the AI.
> For me it’s just a huge force multiplier, maybe 10-20x of my ability to deliver with my own knowledge and skills on a web dev basis.
I can tell you that this claim is where a lot of engineers are getting hung up. People keep saying that they are 10, 20 and sometimes even 100x more productive but it's this hyperbole that is harming that building style more than anything.
If you anyone could get 10 to 20 years worth of work done in 1 year, it would be so obvious that you wouldn't even have to tell anyone. Everyone would just see how much work you got done and be like "How did you do 2 decades worth of work this year?!"
What sort of code are you writing? I find a lot of my stuff requires careful design, refactoring an existing system to work in a new way.
If the code I was writing was, say, small websites all the time for different clients, I can see it being a big improvement. But iterating on a complex existing platform, I’m not so sure that AI will keep the system designed in a maintainable and good way.
But if your experience is with the same sort of code as me, then I may have to re evaluate my judgments.
There's a weird insecurity I've noticed cropping up. I want to design the codebase 'my way'. I want to decide on the fundamental data structures. But there's this worry that my preferred architecture is not massively better than whatever the machine comes up with. So by insisting on 'my way' I'm robbing everyone productivity.
I know most true programmers will vouch for me and my need to understand. But clients and project managers and bosses? Are they really gonna keep accepting a refrain like this from their engineers?
"either it gets done in a day and I understand none of it, or it gets done in a month and I fully understand it and like it"
Until an LLM or some new form of AI can manage an entire architecture itself, I say we need a middle ground. Something will always go wrong, and understanding of the system is necessary to troubleshoot.
Not sure if a developer would ever say that to their manager. Agreed on the need to 100% fully understand what's going on. Otherwise the "AI can get it done in a day" is extremely high risk to the business. Junior may not be able to recognize a half-baked solution that doesn't follow existing patterns, poor security, poor performance, etc.
- when I ask models to do defined that I know how to do and can tell them about that method but can't remember the details off off hand and then I check the answers things work.
- when I attempt to specify things that I don't understand fully the model creates rubbish 7 out of 10 times, and those episodes are irretrievable. About 30% of the time I get a hint of what I should do and can make some progress.
Probably down to a combination of LLMs on average having a harder time with tasks that humans typically find difficult, and the task of prompting being easier the more you know about the problem.
Maybe it's just semantics, but it doesn't feel so wrong to me.
The main nuance is that this statement needs to be true over time as the spec changes.
Developers try to write maintainable code so that their code will still work/adapt to spec when the spec changes.
Maintainable code feels less important in a world where AI can rewrite a growing portion of your code quickly.
I find myself accepting a much lower bar for non-critical parts of my projects with the knowledge that claude can rewrite it quickly if needs change.
But disclaimer: I haven't yet used this technique in teams. The norms on usage aren't there yet.
Not sure what the complaint is about. If the coding work has to be thrown away, we need to do that and move on. We did that many times earlier. We have thrown away hunting, farming, calculations by hand, cameras and so on. Coding work might get extinct for some use cases. Nothing wrong with it. Learn how to use your tools, assistants and godzillas.
The bigger issue, would there be a need for coding and software? Who would use them? Why are they using it? Are they buying something? searching for info? The usecase will see a revolution. The new usecases won't need the traditonal kind software. But AI can only produce traditional software.
Can I ask Claude to code up its clone for local use?
The "time dialation" is real. I mostly manage these days, yet my fun projects progress faster than they ever have, because I can prompt in the 2 minutes between meetings, and come back to significant progress.
Yes, it's not faster to develop with AI if you watch it work. It's faster to develop with AI if you parallelize. Typing was never the bottleneck, but is is a now-parallelizeable part of the pipeline.
That’s always true in my experience, but that doesn’t necessarily mean you need to. The trick I’m working towards is refining the workflow such that i can reliably produce maybe 90% as “good” as what I’d personally produce but much, much faster.
All sorts of side work I was avoiding before also becomes much easier, less tedious refactors and large test coverage and etc.
It can type much faster than I can, the trick is if we can constrain the thinking enough to make it useful. Keeping it as an autocomplete is as productive as it is difficult imo.
Indeed, I hit the stop button quite a bit when Claude goes off course. Then make a note of the right choice so maybe it won't do that again, revert and proceed. I have the feeling there is an optimal size of project proportional to the context size, where you can fit the critical design points into the context and/or there are enough examples in the code of how things should be done.
It can still be faster to develop with AI watching it work. It can legitimately introduce an entire simple fullstack change across multiple projects in my monorepo including graphql queries/mutations, typeorm repository, a service layer, and a reactnative frontend using apollo client, etc. It can do that in about 10 minutes in my local. I can't. If I turned it into a speed run event and practiced, maybe I could get it done in 10 minutes but honestly, it's a machine and I'm John Henry. Since it's using my IDE, it's using my meticulously setup and maintained local and I'm able to quickly stop it and fix any mistake it makes. Level 2 driving assist.
I have enjoyed the github copilot agent style development where someone elses computer is running everything, and I can make a request and just come back half an hour later and check on it. But this level 5 driver gets the wrong destination basically every time, and then it's another 10, 20 or even 30 minutes for it to make a minor adjustment. It doesnt understand my `yarn` scripts, it runs my tests wrong, it can't do codegen, it doesn't format or lint files, etc. I asked copilot yesterday to lint and format a PR and it took 25 minutes of agentic work lol.
For me, one of the new superpowers is the ability to interactively do multiple drafts following different design principles and see which works better.
I just started an embedded project where two different people had implemented subsystems independently, and I asked Claude to merge the code into a single project and convert the existing synchronous code into asynchronous state machines called from a single main loop. It wrote three drafts with me giving it different stylistic principles to follow. I don't know if I would have had the patience to do that myself!
> I'm able to quickly stop it and fix any mistake it makes
I would think that's the process too, but according to the article the dude is almost completely hands off:
> You come back to ten thousand lines of code. You spend 5 minutes reading. One sentence of feedback. Another ten thousand lines appear while you're making lunch.
You can't humanly review 10 thousand lines of code in 5 minutes. This is either complete bullshit or it really writes flawless code for them and never makes any mistakes.
I feel increasingly tired of reading excuse after excuse when you bring up that AI tools simply cannot solve anything beyond extremely basic problems.
It's always a mix of:
1. "Wait for the next models", despite models having all but plateaued for the past 3 years,
2. "It's so good for boilerplate code", despite libraries and frameworks being much better suited for this task, and boilerplate code being actually rare to write in the normal lifecycle of a project,
3. "You need to prompt it differently", glossing over the fact that to prompt it so it can do what you want it to do accurately it would take longer than not to use AI at all,
4. And the worst: "We don't know how to use those models yet"
Maybe the real reason it doesn't work is because IT JUST DOESN'T FUCKING WORK.
Why is it so unfathomable that a next token generator is gonna suck at solving complex problems? It is blindingly obvious.
> I'd wander into my office, check what Claude had built, test it real quick. If it worked, great! Commit and push.
Do people read the code? Or just test if it work and push?
To me, code is like a map that has to be clear enough so other humans can read it to navigate the territory (codebase). Even if it's just two – me and AI agent – working on the codebase, it's not much different from "me and another programmer". We both want to have updated mental model of how exactly code structured and how it works and why.
Using AI for coding and not reading the code sounds more like stopping being developer and self-promoting yourself to the manager of AI-programmers who trusts their craft completely.
"You’re using it wrong" arguments/hype articles showing up. Speculators love it. But in reality if you need to extol the benefits of AI, then is it really the user or the technology?
Honestly reminds me of the digital currency mania that busted a couple of years ago. Same types of articles popping up too.
Look I understand the benefits of AI but it’s clear ai is limited by the compute power of today. Maybe the dream this author has will be realized some day. But it won’t be today or in current generations lifespan.
The entire premise of using AI to build stuff is founded on the idea that building faster is somehow automatically better.
I’m starting to believe that’s not necessarily true. And if some study finds out later that stuff built slowly by hand is actually better in every way except time-to-market, then it means AI is not really a competitive edge, it’s just a Quality of Life improvement that allows software engineers to be even lazier. And at future price points of $200, $400, even $1000 a month per head, that becomes a hard sell for most companies. Might be easier to have engineers pay for their own AI if they want to be lazy. And of course whether they use AI or not, you can still measure productivity under the assumption that every engineer does…
> With enough AI assistants building enough single-purpose tools, every problem becomes shallow. Every weird edge case already has seventeen solutions. Every 2am frustration has been felt, solved, and uploaded.
> We're not drowning in software. We're wading in it. And the water's warm
Just sounds like GPT style writing. I’m not saying this blog is all written by GPT, but it sounds like it is. I wonder if those of us who are constantly exposed to AI writing are starting to adopt some of that signature fluffy, use-a-lot-of-words-without-saying-much kinda style.
Life imitates art. Does intelligence imitate artificial intelligence?? Or maybe there’s more AI written content out there than I’m willing to imagine.
(Those snippets are from another post in this blog)
It depends on how the AI is used; there's a huge difference in productivity between a structured workflow with repeated automated feedback to the AI, and just ad-hoc prompting. For instance, Gemini 2.5 coding up a spec-compliant HTTP2.0 server in two weeks: https://outervationai.substack.com/p/building-a-100-llm-writ... . 15k lines of code and 30k lines of tests; no human coder could produce something like that so fast.
The are around three Golang HTTP2.0 servers on Github, but it wasn't just regurgitating the application from memory, as if it was then it would have been mostly correct first try, and it wouldn't have needed to spend 80%+ of the development time in a code-compile-test cycle of fixing bugs identified by integration tests and spec conformance tests.
I would not say that is ”how the AI is used”. That problem space is one where humans have spent unusually much time defining a spec and writing a test suite.
A million monkeys randomly typing could actually complete that task as well.
Im going to be overly picky about the subheading (which is an incidental aspect of TFA): “The future of software development might just be jazz. Everyone improvising. Nobody following the sheet music.”
That’s not jazz. Jazz being what it is, a lot of people in 2025 think it’s “everyone improvising,” but (outside of some free jazz) it’s quite structured and full of shared conventions.
Analogies work when you and your audience both understand the things being compared. In this case, the author doesn’t, and maybe some of the audience shares the same misperception, and so the analogy only works based on shared misunderstanding.
The analogy to jazz actually works better the more you know about it. But that’s accidental.
Software jazz is when you and your teammate are working hard on a project and you both land big PRs at the same time without a merge conflict, then integrate before the build system even has time to realize what happened.
Based on how easy it is to trigger cool-down or throttle on Claude Code, I think people know how to build with AI. Or they’re trying really hard to figure it out. The race is on and it’s wide open.
There are a lot gotchas with these new models. They get incredibly lazy if you let them. For example, I asked it to do a simple tally by year. I just assumed it’s simple enough I don’t need to ask to write a code. It counted first couple of years and just “guessed” the rest based on pattern it noticed.
Sometimes, it feels like having a lazy coworker that you have to double check constantly and email with repeated details. Other times, I just sit there in awe of how smart it is in my weekly AGI moment and how it’s going to replace me soon.
I’m feeling limited by the tools right now. The software for using LLMs is an incongruent mess. For example, how can I have a global system prompt shared across all the apps I use my OpenRouter key with? I can’t, I have to set it in each application. How can I carry a conversation over from one app to another? How can I give all my apps access to the same set of MCP tools? Most of the apps I use don’t even properly support MCP yet.
It sounds like Claude Code is the best UX right now but I don’t want to be locked into a Claude subscription, I want to bring my own key and tap into whatever provider I want.
Eh, idk. First of all, the article is really wordy to say very few things. That just frustrated me a bit.
Second of all, it's easy to fart out some program in a few days vibe coding. How will that fare as more and more features need to be added on? We all used to say "Dropbox that's just FTP wrapped in a nice UI anyone can make that". This protocollie project seems to be a documentation viewer / postman for MCP. Which is cool, but is it something that would have taken a competent dev months to build? Probably not. And eventually the actual value of such things is the extensibility and integrations with various things like corporate SAML etc.
Will the vibe code projects of today be extensible like that, enough to grab market share vs the several similar versions and open source versions anyone can make in a few days, as the author suggests? It can be hard to extend a codebase you don't understand because you didn't write...
You prompt. You go live your life. You come back to ten thousand lines of code. You spend 5 minutes reading. One sentence of feedback. Another ten thousand lines appear while you're making lunch.
Yeah, it strikes me the author writes prose the same way they're generating code. 20k lines? That's enough code for a whole compiler or an operating system kernel. I'd love to see what those 20k lines actually do -- notably, in these articles about AI, people tend to not link the actual code when they easily could, which is curious. I mean, my macro expander can also write 20k lines of code while I eat lunch, but no one is pretending it's sentient and about to replace devs.
I definitely did a double take when I got to this section. I am neither an AI optimist nor an AI pessimist (probably slightly on the optimistic side of the midpoint) but this sounds insane to me for any software that people might truly depend on. Five minutes of review for 10,000 lines, happening multiple times per day?
You look at the PRs... there are 786(!) AI generated pull requests and an associated AI generated code review for each one. Each PR is about ~20-100 lines of Ruby (including comments) that implements an "action" for the sublayer system as a Ruby class. So probably something that could be handled by a macro expander. Or at least it's AI used as a fancy macro expander.
But yeah, there's about 20k lines of code right there easily. Although, because it's Ruby, it's not (much) of an exaggeration to say ~50% of the generated lines are a single "end" keyword.
The author is someone who before AI, would publish ~300 commits a year to Github. This year they are on track for 3000 commits using AI. But the result seems to be that PRs are accumulating in their repo, implementing hundreds of features. I'm wondering why the PRs are accumulating and not getting merged if the code is good? Is the bottleneck now review? What would happen if AI took over PR merging as well as PR creation?
> First of all, the article is really wordy to say very few things.
A clickbaity title in opposition with the content isn't helpful either. I would've recommended their "The Great Experiment Nobody's Running the Same Way" heading as a better choice, even thought it might not perform as well from a content marketing POV.
> And eventually the actual value of such things is the extensibility and integrations with various things like corporate SAML etc.
I could make a Dropbox clone by hand in a weekend. I could make one with AI in a few hours. Neither will be valuable like Dropbox because the value is the hard stuff that I have yet to see proof AI can do
The idea is to track all of the context of a project using git. It’s a CLI and MCP tool, the human guides it but the LLM contributes back to it as the project evolves
I used it to bootstrap the library itself, and have been using it more and more for context management of all sorts of things I care about
Reminds me of Sussman’s “We don’t know how to compute” which is essentially maligning that we haven’t gone full Smalltalk with some Lisp sprinkled on top to get “soft computers.”
None of that is actually what makes my favorite tools work. It’s usually some nerds that never stopped using C/C++ and really know hardware.
> There's this moment in every new technology where everyone pretends they know what they're doing.
Perhaps that is true, but without any examples I was immediately suspicious of this line.
> Either way, we're in this delicious middle ground where nobody can pretend expertise because the whole thing keeps changing under our feet.
Upon reflection this does in fact remind me of the early days of rocketry when we were just reaching into the upper atmosphere and then orbit. Wild things were being tried because there was not yet any handrails. Exploding a huge tank of water in the ionosphere just because, launching giant mylar balloons into orbit to try and bounce radar signals off of them, etc.
So, is Protocollie actually any good? I don't have any means of evaluating the final product, but I feel like evaluating what ultimately stuck to the wall is a pretty important part of the tale.
How buggy is it? How long would it have taken to build something similar by hand?
We are expecting a moment like when sublime was born. Sidebar map, concurrent cursors, blazing speed.
Right now its all monetization at gravity. As if companies are ready to pour software developer salaries in tools.
I imagine beginners will not have gpu rich environments and AI will not reach mainstream as traditional development did, unless something happens, idk what.
Right now, seniors love the complexity and entry barrier to it, so they can occupy the top of the food chain. History has proven that that does not last long.
In some scenarios as airtable, AI is replacing docs and customer support, eleminating the learning curve.
Instead of walking away, I have worked on multiple projects at the same time. Prompt one project, let it run, prompt another project, let it run and go back to the first.
Yep! I work on multiple client projects. And while one agent is running in one project, I’m reviewing and writing down the task for another. Generally I just do this 2-3 hours per day; trying to block this time. And then go outside and enjoy free time.
At what point does LLM output become more expensive than search? For example, the author made protocollie. Could the LLM gather all similar apps that are already written to solve the prompt that birthed it,, and then simply provide THOSE apps iinstead of figuring out how to code it anew? Sounds like this could be a moat that only hyperscalars could implement and woould reduce their energy requirements drastically.
I like to use other parts of the codebase (or other codebases) as an example which helps a lot to maintain standards and consistency (though adds cost).
I am a bit disillusioned - I find mentoring humans satisfying but I don't get the same satisfaction mentoring AI. I also think it's a probably going to backfire by hamstringing the next generation and 'draining the competence' from the current.
> The Story Breakdown - Everything in 15-30 minute chunks. Why? Because that's roughly how long before Claude starts forgetting what we discussed ten minutes ago. Like a goldfish with a PhD.
This is interesting. Does Claude have a memory? Is this just a limit on the number of input tokens? It sounds like a fundamental misappropriation of cause, but maybe I just don't understand the latest whizbang feature of Claude. Can anyone clarify?
Building with LLMs is a bit like driving with GPS. You ever get that feeling the GPS is wrong or leading you along a difficult route? But for some reason you follow the GPS anyway? Maybe there's a name for the phenomenon. I notice it more and more.
The decision making parts of people's brains will atrophy. It will be interesting to see what will happen.
How wonderful for all of us to be thrown back into “what are we doing” mode. Like when you were a teenager, hacking stuff you were just excited to build, with none of the “here’s how you should do this” we’ve burdened ourselves with over the years.
I want claude code on my phone running in a cloud vm so I can give feedback out on a trail somewhere and continue my three hour hike or bike ride with my family.
I find its all about the joy of building with the subset you can be an expert in and the AI telling you where the typo is and why it still wont work after fixing it.
Nobody knows how to build with AI yet, and the corollary (which TFA concludes with) is that everybody should figure out for themselves how to best work with AI.
I've said it before and I'll say it again: there likely isn't a "golden workflow" or "generally accepted best practices" on how to code with AI. The new models and agentic capabilities seem to be very powerful, and they will conform to whatever methodologies you currently use with whatever project you're working on, but that may still be under-utilizing what they are truly capable of.
A true optimum may even require you to adjust the way you work, down to structuring your code and projects differently. In fact you may need to figure out different approaches based on the project, the language, the coding style, the model, the specific task at hand, even your personality. I am convinced this aspect is what's causing the bimodal nature of AI coding discussions: people who stuck at it and figured it out, or just got lucky with the right mix of model / project / task / methodology, are amazed at their newfound superpowers -- whereas people who didn't, are befuddled by the hype.
This may seem like a lot of work, but it makes sense if you stop thinking of this as just a tool and more like working with a new team-mate.
Reading articles like this feels like being in a different reality.
I don't work like this, I don't want to work like this and maybe most importantly I don't want to work with somebody who works like this.
Also I am scared that any library that I am using through the myriad of dependencies is written like this.
On the other hand... if I look at this as some alternate universe where I don't need to directly or indirectly touch any of this... I am happy that it works for these people? I guess? Just keep it away from me
I've been working on AI dev tools for a bit over a year and I don't love using AI this way either. I mostly use it for boilerplate, ideas, or to ask questions about error messages. But I've had a very open mind about it ever since I saw it oneshotting what I saw as typical Google Cloud Functions tasks (glue together some APIs, light http stuff) a year ago.
I think in the last month we've entered an inflection point with terminal "agents" and new generations of LLMs trained on their previously spotty ability to actually do the thing. It's not "there" yet and results depend on so many factors like the size of your codebase, how well-represented that kinda stuff is in its training data, etc but you really can feed these things junior-sized tickets and send them off expecting a PR to hit your tray pretty quickly.
Do I want the parts of my codebase with the tricky, important secret sauce to be written that way? Of course not, but I wouldn't give them to most other engineers either. A 5-20 person army of ~interns-newgrads is something I can leverage for a lot of the other work I do. And of course I still have to review the generated code, because it's ultimately my responsibility, but I prefer that over having to think about http response codes for my CRUD APIs. It gives me more time to focus on L7 load balancing and cluster discovery and orchestration engines.
I'm reminded of teaching bootcamp software engineering, when every day #1 we go through simple git workflows and it seems very intimidating to students and they don't understand the value. Which fair enough because git has a steep learning curve and you need to use it practically to start picking it up.
I think this might be analogous to the shift going on with ai-generated and agent-generated coding, where you're introducing an unfamiliar tool with a steep learning curve, and many people haven't seen the why? for its value.
Anyways, I'm 150 commits into a vibe coding project that still standing strong, if you're curious as to how this can work, you can see all the prompts and the solutions in this handy markdown I've created: https://github.com/sutt/agro/blob/master/docs/dev-summary-v1...
To the article's point, I built my own version of your agro tool that I use to manage my own git worktrees. Even if I had known about your project, I still would have built my own, because if I build it (with LLM assistance, obvs) then I get to design it for myself.
Looking at other industries, music production is probably the one to look at. What was once the purview of record labels with recording studios that cost a million dollars to outfit, is now a used MacBook and, like, $1,000 of hardware/software. The music industry has changed, dramatically, as a result of the march of technology, and thus so will software. So writing software will go the way of the musician. What used to be a middle class job as a trumpet player in NYC before the advent of records, is now only a hobby except for the truely elite level practicioners.
But you also can't not swim with the tide. If you drove a horse-buggy 100 years ago, it was probably worth your while to keep your eye on whether motor-cars went anywhere.
I was super skeptical about a year ago. Copilot was making nice predictions, that was it. This agent stuff is truly impressive.
An I the only one who has to constantly tell Claude and Gemini to stop making edits to my codebase because they keep messing things up and breaking the build like ten times in a row, duplicating logic everywhere, etc? I keep hearing about how impressive agents are. I wish they could automate me out of my job faster
Are you paying for the higher end models? Do you have proper system prompts and guidance in place for proper prompt engineering? Have you started to practice any auxiliary forms of context engineering?
This isn't a magic code genie, it's a very complicated and very powerful new tool that you need to practice using over time in order to get good results from.
It ain’t a magic code genie. And developers don’t spend most of their day typing lines of code. Lots of it is designing, figuring out what to build, understanding the code, maintenance considerations, and adhering to the style of whatever file you’re in. All these agents needing local context and still
spit junk.
> it's a very complicated and very powerful new tool that you need to practice using over time in order to get good results from.
Of course this is and would be expected to be true. Yet adoption of this mindset has been orders of magnitude slower than the increase in AI features and capabilities.
guy 1: I put money in the slot machine everyone says wins all the time and I lose
you: HAVE YOU PUT MORE TOKENS IN???? ARE YOU PUTTING THEM IN THE EXPENSIVE MACHINES???
super compelling argument /s
if you want to provide working examples of "prompt engineering" or "context engineering" please do but "just keep paying until the behavior is impressive" isn't winning me as a customer
it's like putting out a demo program that absolutely sucks and promising that if I pay, it'll get good. why put out the shit demo and give me this impression, then, if it sucks?
The way I ended up paying for Claude max was that I started on the cheap plan, it went well, then it wanted more money, and I paid because things were going well.
Then it ran out of money again, and I gave it even more money.
I'm in the low 4 figures a year now, and it's worth it. For a day's pay each year, I've got a junior dev who is super fast, makes good suggestions, and makes working code.
For anyone trying to back of the napkin at $1000 as 4-figures per year, averaged as a day salary, the baseline salary where this makes sense is about ~$260,000/yr? Is that about right lordnacho?
Yeah I thought that was a reasonable number in the ballpark. I mean, it probably makes sense to pay a lot more for it. A grand is probably well within the range where you shouldn't care about it, even if you only get a basic salary and it's a terrible year with no bonus.
And that's not saying AI tools are the real deal, either. It can be a lot less than a fully self driving dev and still be worth a significant fraction of an entry level dev.
I'm really baffled why the coding interfaces have not implemented a locking feature for some code. It seems like an obvious feature to be able to select a section of your code and tell the agent not to modify it. This could remove a whole class of problems where the agent tries to change tests to match the code or removes key functionality.
One could even imagine going a step further and having a confidence level associated with different parts of the code, that would help the LLM concentrate changes on the areas that you're less sure about.
Why are engineers so obstinate about this stuff? You really need a GUI built for you in order to do this? You can't take the time to just type up this instruction to the LLM? Do you realize that's possible? You can just write instructions "Don't modify XYZ.ts file under any circumstances". Not to mention all the tools have simple hotkeys to dismiss changes for an entire file with the press of a button if you really want to ignore changes to a file or whatever. In Cursor you can literally select a block of text and press a hotkey to "highlight" that code to the LLM in the chat, and you could absolutely tell it "READ BUT DON'T TOUCH THIS CODE" or something, directly tied to specific lines of code, literally the feature you are describing. BUT, you have to work with the LLM and tooling, it's not just going to be a button for you or something.
You can also literally do exactly what you said with "going a step further".
Open Claude Code, run `/init`. Download Superwhisper, open a new file at project root called BRAIN_DUMP.md, put your cursor in the file, activate Superwhisper, talk in stream of consciousness-style about all the parts of the code and your own confidence level, with any details you want to include. Go to your LLM chat, tell it to "Read file @BRAIN_DUMP.md" and organize all the contents into your own new file CODE_CONFIDENCE.md. Tell it to list the parts of the code base and give it's best assessment of the developer's confidence in that part of the code, given the details and tone in the brain dump for each part. Delete the brain dump file if you want. Now you literally have what you asked for, an "index" of sorts for your LLM that tells it the parts of the codebase and developer confidence/stability/etc. Now you can just refer to that file in your project prompting.
Please, everyone, for the love of god, just start prompting. Instead of posting on hacker news or reddit about your skepticism, literally talk to the LLM about it and ask it questions, it can help you work through almost any of this stuff people rant about.
_all_ models I’ve tried continuously, and still, have problems ignoring rules. I’m actually quite shocked someone would write this if you have experience in the area, as it so clearly contrasts with my own experience.
Despite explicit instructions in all sorts of rules and .md’s, the models still make changes where they should not. When caught they innocently say ”you’re right I shouldn’t have done that as it directly goes against your rule of <x>”.
Just to be clear, are you suggesting that currently, with your existing setup, the AI’s always follow your instructions in your rules and prompts? If so, I want your rules please. If not, I don’t understand why you would diss a solution which aims to hardcode away some of the llm prompt interpretation problems that exist
I am by no means an AI skeptic. It is possible to encode all sorts of things into instructions, but I don’t think the future of programming is every individual constructing and managing artisan prompts. There are surely some new paradigms to be discovered here. A code locking interface seems like an interesting one to explore. I’m sure there are others.
They need "context engineering" which what I'll describe best as "railing" them in. If you give them a bit of a loose space, they'll massacre your code base. You can use their freedom for exploration but not for implementation.
In essence, you have to do the "engineering" part of the app and they can write the code pretty fast for you. They can help you in the engineering part, but you still need to be able to weigh in whatever crap they recommend and adjust accordingly.
This is way even as a paid user I stick to the browser tab llms. I am a context control freak and constantly just grabbing a new sessions and starting over. I don't try and fix a session and the incentives of a subscription vs api token payment model has inverse incentives.
More like people telling us there will be no more professional drivers on the road in 5-10 years 10 years ago. Agents are like lane assist, not even up to the current self driving levels.
Not sure the analogy is the same. A driverless car if it does something wrong can cause death - the cost of failure is very high. If my code doesn't come out right, as other posts here have said, I can just "re-roll the slot machine" until it does come out as acceptable - the cost is extremely low. Most of the "reasoning" models just increase the probability that the "re-run" will more likely be to preference of most people with RL to make it viable - tools like new agents know how to run tools, etc to give more data for the probability to be viable within a good timeframe and not run into an endless loop most of the time. Software until it is running after all is just text on a page.
Sure I have to be sure what I'm committing and running is good, especially in critical domains. The cheap cost of iteration before actual commit IMO is the one reason why LLM's are disruptive in software and other "generative" domains in the digital world. Conversely real-time requirements, software that needs to be relied on (e.g. a life support system?), things that post opinions in my name online etc will probably, even if written by a LLM, will need someone accountable and verifying the output.
Again as per many other posts "I want to be wrong" given I'm a senior in my career and would find it hard to change now given age. I don't like how our career is concentrating to the big AI labs/companies rather than our own intelligence/creativity. But rationally its hard to see how software continues to be the same career going forward and if I don't adapt I might die. I will most likely going forward, similar to what I do with my current team, just define and verify.
it's exactly like this. we're 3 years into being told all white collar jobs are going to be gone next year, just like we're ten years into being told we'll have self driving cars next year
AI's superpower is doing mediocre work at high speed. That's okay. Great, even. There's lots of mediocre work to do. And mediocre still clears below average.
But! There's still room for expertise. And this is where I disagree about swimming with the tide. There will be those who are uninterested in using the AI. They will struggle. They will hone their craft. They will have muscle memory for the tasks everyone else forgot how to do. And they will be able to perform work that the AI users cannot.
My ongoing concern is that most of us probably got to being able to do good work via several years of doing mediocre work. We put in the hours and along the way learned what good looks like, and various patterns that allow us to see the path to solving a given problem.
What does the next generation do when we’ve automated away that work? How do they learn to recognise what good looks like, and when their LLM has got stuck on a dead end and is just spewing out nonsense?
I think the agent stuff is impressive because we are giving the AI scaffold and tools and things to do. And that is why it is impressive because it has some directive. But it is obvious if you don't give it good directives it doesn't know what to do. So for me, I think a lot of jobs will be making agents do things, but a lot won't. i think its really strange that people are all so against all this stuff. it's cool new computer tools, does nobody actually like computers anymore?
A lot of people join this profession because they like building stuff. They enjoy thinking about a problem and coming up with a solution and then implementing and testing it. Prompting is not the same thing and it doesn't scratch the same itch and at the end of the day it's important to enjoy your job, not only be efficient at it.
I have heard the take that "writing code is not what makes you an engineer, solving problems and providing value is what makes you an engineer" and while that's cool and all and super important for advancing in your career and delivering results, I very much also like writing code. So there's that.
Rick Beato posted a video recently where he created a fictitious artist and a couple of songs based on a few prompts. The results were somewhat passable, generic indie/pop music but as he said (I'm paraphrasing) "I didn't create anything here. I prompted a computer to put together a bunch of words and melodies that it knew from what other people had written."
There is code which is interesting to write, even if it isn't the area with clever algorithms or big architecture decisions or something.
But there is also the area of boilerplate, where non-LLM-AI-based IDEs for a few decades already help a lot with templates and "smart" completion. Current AI systems widen that area.
The trouble with AI is when you are reaching the boundary of its capabilities. The trivial stuff it does well. For the complex stuff it fails spectacularly. In the in between you got to review carefully, which easily becomes less fun than simply writing by oneself.
> But there is also the area of boilerplate, where non-LLM-AI-based IDEs for a few decades already help a lot with templates and "smart" completion.
The thing for me is that AI writing the boilerplate feels like the brute force solution, compared to investing in better language and tooling design that may obviate the need for such boilerplate in the first place.
Yeah, but building tooling is a hard sell considering the ability of contemporary AI.
The energy cost is absurdly high for the result, but in current economics, where it's paid by investors not users, it's hidden. Will be interesting to see when AI companies got to the level where they have to make profits and how much optimisation there is to come ...
That's an interesting take - that you like the act of writing code. I think a lot of builders across a variety of areas feel this way. I like writing code too.
I've been experimenting with a toolchain in which I speak to text to agents, navigate the files with vim and autocomplete, and have Grok think through some math for me. It's pretty fun. I wonder if that will change to tuning agents to write code that go through that process in a semi-supervised manner will be fun? I don't know, but I'm open to the idea that as we progress I will find toolchains that bring me into flow as I build.
Most people don't enjoy their jobs and go to work for one reason only - to support themselves and their families. The itch is to get paid. This is as true in software as it is in other fields.
That's not to say there aren't vocations, or people in software who feel the way you do, but it's a tiny minority.
Yeah but I write the code that is interesting to solve and let the LLM solve the problems that are not so important. Like making yet another webscraper tool is not the most exciting part of the process when you are trying to make some kind of real time inference tool for what people post on the internet.
Ah yes, that "is that 6 spaces or 8" in a yaml file itch that just has to be scratched. Programming has a lot of doldrums. LLMs still get stuck at places, and that's just where the new itch to scratch is. Yeah, it's not the same as code golfing an algorithm really neatly into a few lines of really expressive C++, but things change and life goes on. Programming isn't the same as when it was on punch cards either.
People are afraid that instead of skilled craft guild members they will become assembly line workers like Charlie Chaplin in Modern Times. And in 10 years unemployed like people in the Rust Belt.
This, and no one will understand the software that is created. Then you are beholden to AI companies who can charge you whatever they want to maintain the AI code. Will this be cheaper than paying software engineers? Maybe, but I could also see it costing much more.
There's a kind of karmic comedy in this. Programmers' jobs has always been to automate other people's jobs. The panic of programmers about their own jobs now is immensely funny to me.
As has been the case for all those jobs changed by programmers, the people who keep an open mind and are willing to learn new ways of working will be fine or even thrive. The people rusted to their seat, who are barely adding value as is, will be forced to choose between changing or struggling.
I think this is a really interesting question and an insight into part of the divide.
Places like HN get a lot of attention from two distinct crowds: people who like computers and related tech and people who like to build. And the latter is split into "people who like to build software to help others get stuff done" and "people who like to build software for themselves" too. Even in the professional-developer-world that's a lot of the split between those with "cool" side projects and those with either only-day-job software or "boring" day-job-related side projects.
I used to be in the first group, liking computer tech for its own sake. The longer I work in the profession of "using computer tools to build things for people" the less I like the computer industry, because of how much the marketing/press/hype/fandom elements go overboard. Building-for-money often exposes, very directly, the difference between "cool tools" and "useful and reliable tools" - all the bugs I have to work around, all the popular much-hyped projects that run into the wall in various places when thrown into production, all the times simple and boring beats cool when it comes to winning customers. So I understand when it makes others jaded about the hype too. Especially if you don't have the intrinsic "cool software is what I want to tinker with" drive.
So the split in reactions to articles like this falls on those lines, I think.
If you like cool computer stuff, it's a cool article, with someone doing something neat.
If you are a dev enthusiast who likes side projects and such (regardless of if it's your day job too or not), it's a cool article, with someone doing something neat.
If you are in the "I want to build stuff that helps other people get shit done" crowd then it's probably still cool - who doesn't like POCs and greenfield work? - but it also seems scary for your day to day work, if it promises a flood of "adequate", not-well-tested software that you're going to be expected to use and work with and integrate for less-technical people who don't understand what goes into reliable software quality. And that's not most people's favorite part of the job.)
(Then there's a third crowd which is the "people who like making money" crowd, which loves LLMs because they look like "future lower costs of labor." But that's generally not what the split reaction to this particular sort of article is about, but is part of another common split between the "yay this will let me make more profit" and "oh no this will make people stop paying me" crowds in the biz-oriented articles.)
This doesn't make aaaaany sense: IF this actually worked, then why would all the biggest companies in the world be firing people? They would be forcing them all to DO THE TIDE and multiple their 10 billion dollar dominance to 100 billion dollar or more dominance.
The truth is something like: for this to work, there is huge requirements in tooling/infrastructure/security/simulation/refinement/optimization/cost-saving that just could never be figured out by the big companies. So they are just like... well lets trick as many investors and plebs to try to use this as possible, maybe one of them will come up with some breakthrough we can steal
Sometimes it's a good thing to not swim with the tide. Enshittification comes from every single dipshit corporation racing to the bottom, and right now said tide is increasingly filling with sewage.
There's a huge disconnect I notice where experienced software engineers rage about how shitty things are nowadays while diving directly into using AI garbage, where they cannot explain what their code is doing if their lives depended on it.
It does sound horrible. No more getting in the flow, no more thinking about anything, no more understanding anything. Just touch it with a ten-foot pole every few hours, then get distracted again.
I guess if all you do is write React To-Do apps all day, it might even work for a bit.
Unfortunately, I think the evolution of LLMs is going to put more areas of programming within this "React Todo app" envelope of capability that you suggest, and to have it work for longer, rather than going away.
This has to be someone working solely on personal projects right? Because I don't know anyone who actually works like this and frequently the code that AI will spit out is actually quite bad.
Scary part is: what if it’s inevitable? We don’t get to choose our environment, and toss one is forming around us.
A friend’s dad only knows assembly. He’s the ceo of his company and they do hardware, and he’s close to retirement now, but he finds this newfangled C and C++ stuff a little too abstract. He sadly needs to trust “these people” but really he prefers being on the metal.
> and maybe most importantly I don't want to work with somebody who works like this.
Which, of course, is your perogative, but in what other ways do we, as fellow programmers, judge software libraries and dependencies so harshly? As a Vim user, do I care that Django was written with a lot of emacs? Or that Linus used emacs to write git? Or maybe being judgemental about programming languages; ugh, that's "just" a scripting language, it's not "real" programming unless you use a magnet up against a hard drive to program in ones and zeros. As a user, do I care that Calibre is written in Python, and not something "better"? Or that curl is written in good ole C. Or how about being opinionated as to whether or not the programmer used GDB or printf debugging to make the library?
The market for utility software like this predates the internet, we used to pass them around on floppies. It was never subject to particularly high QA or scrutiny. It just has to be "adequate."
But it's never displaced the market for highly-produced, highly-planned, "central" software pieces that the utilities glue together and help you work with, etc.
The growth of that software-as-big-business has only enlarged the need for utilities, really, to integrate everything, but it's a tough space to work in - "it's hard to compete with free." One classic move is selling support, etc.
Might be tough to do non-LLM-driven software development there - the selling support for your LLM-created-products model is still viable, but if there's an increase in velocity in useful utility creation or maintenance, possibly the dev headcount needs are lower.
But does anyone know how to use LLMs to make those giant ones yet? Or to make those central core underlying libraries you mention? Doesn't seem like it. Time will tell if there's a meaningful path that is truly different from "an even higher level programming language." Even on the edges - "we outgrew the library and we have to fork it because of [features/perf/bugs]" is a pretty common pattern when working on those larger projects already, and the more specific the exact changes you need are, the less the LLM might be able to do it for you (e.g. the "it kept assuming this function existed because it exists in a lot of similar things" problem).
What I hope is that we can find good ways to leverage these for quality control and testing and validation. (Though this is the opposite of the sort of greenfield dev demos that get the most press right now.)
Testing/validation is hard and expensive enough that basically nobody does a thorough job of it right now, especially in the consumer space. It would be wonderful if we could find ways to release higher quality software without teams of thousands doing manual validation.
>I don't want to work with somebody who works like this.
You will most likely get your wish but not in the way you want. In a few years when this is fully matured there will be little reason to hire devs with their inflated salaries (especially in the US) when all you need is someone with some technical know-how and a keen eye on how to work with AI agents. There will be plenty of those people all over the globe who will demand much less than you will.
Hate to break it to you but this is the future of writing software and will be a reckoning for the entire software industry and the inflated salaries it contains. It won't happen overnight but it'll happen sooner than many devs are willing to admit.
Genuinely this is what it sounds like to accept obsolescence and I just can’t understand it.
What are you attached to and identify with that you’re rejecting new ways to work?
Change is the only constant and tools now look like superhuman tools created for babies compared to the sota at bell or NASA in the 1960s when they were literally trying to create superhuman computing.
We have more access to powerful compute and it’s never been easier to build your own everything.
I think it's a great technology but if people's ability to put food on the table is compromised what's their incentive not to ventilate people working for AI labs?
If people have shown anything recently it’s the unwillingness to actually do what you just said.
If anyone cared enough to do anything, they would be burning everything down already
It’s a lot of impotent rage because the only virtue people have is consumption, they don’t actually believe in anything. The ones who do believe in fairy tales are part of a dwindling population (religion) that is rightfully crashing.
And that's fine, it's your choice.
But everything, driven by multiple forces (from hype, to marketing, to real progress, to early adopters) is pointing to that future.
Yes, another web3, crypto and nft "inevitable" futures. Just give Sama a couple more trillion and AGI is juuuust behind the corner.
It's a fact models aren't getting as cost efficient nor better with the same rate that the costs increases of training and running them. It's also a fact that they are so unprofitable that Anthropic feels like they gotta rug-pull your Claude tokens (https://news.ycombinator.com/item?id=44598254#44602695) without telling you, let's just ignore those facts and fanboy with wide-closed about that future.
A future framed as "inevitable" by a bunch of people whose job/wealth depends on framing it as such. Nah, hard pass.
Imagine a future where creating software is about the designing the UX, overseeing the architecture and quality assurance. Implementation is farmed out.
I don’t think that was his argument. It would be one thing if we reach a point where humans trust a higher AI intelligence to create/keep software systems predictably meeting requirements. We aren’t there yet. So, it’s important to make sure any AI code is reviewed and approved by humans.
I have a local LLM router app with profiles that set up the right system prompts and the right MCPs so I can swap between toolsets as I work.
This would take time to write if I’m doing it myself so I decided to vibe code it entirely. I had this idea that a compiled language is less likely to have errors (on account of the compiler giving the LLM quicker feedback than me) and so I chose Tauri with TS (I think).
The experience has been both wonderful and strange. The app was built by Claude Code with me intermittently prompting it between actual work sessions.
What’s funny is the bugs.
If you ever played Minecraft during the Alpha days you know that Notch would be like “Just fixed lighting” in one release. And you’d get that release and it’d be weird like rain would now fall through glass.
Essentially the bugs are strange. At least in the MC case you could hypothesize (transparency bit perhaps was used for multiple purposes) but this app is strange. If the LLM configuration modal is fixed, suddenly the MCP/tool tree view will stop expanding. What the heck, why are these two related? I don’t know. I could never know because I have never seen the code.
The compile time case did catch some iterations (I let Claude compile and run the program). But to be honest, the promise of correctness never landed.
Some people have been systematic and documented the prompts they use but I just free flowed it. The results are outstanding. There’s no way I could have had this built for the $50 in Claude credits. But also there’s no way I could interpret the code.
Yawn. I wish HN would just ban AI skip articles until someone writes about an actual product that provides actual value to paying customers.
In fact what I really want to see is a successful product that no one realizes was built by AI vibes until after it was successful. Customers don’t give a shit how something was built.
I don't think it's either "vibe coding or nothing" choice you have to make with AI. I am part of a team working on a complex Kotlin backend. I have been experimenting with Claude recently and I have been amazed how well it can pick up the existing patterns used in the project and create new code if given reasonable instructions. And it writes great tests too (something that would take me a lot of time and kill my motivation). It has been a great productivity boost for me. Of course we review the code in PRs, we test it but in the end it does the job in less time and saves me from doing tedious work.
> Maybe all methodology is just mutually agreed-upon fiction that happens to produce results?
Good news! *All of computer science is this way.* There’s nothing universally fundamental about transistors, or Turing machines, or OOP, or the HTTP protocol. They’re all just abstractions that fit, because they worked.
———
When should I stop learning and start building? My coworker wrote absolutely ATROCIOUS code, alone, for the past decade. But he was BUILDING that whole time. He’s not up to date on modern web practices, but who cared? He built.
I know it's an analogy that's probably been done to death already, but it truly feels like Bitcoin 2.0.
Back in the Bitcoin hype days, there were new posts here every single day about the latest and greatest Bitcoin thing. Everyone was using it. It was going to take over the world. Remember all the people on this very site that sincerely thought fiat currency was going away and we'd be doing all of our transactions with Bitcoin? How'd that work out?
It feels exactly the same. Now the big claims are that coding jobs are going away, or if you at least don't use it you'll be left behind. People are posting AI stories every day. Everyone is using it. People say it's going to transform the industry.
Back then there was greater motivation to evangelize Bitcoin, as you could get rich by convincing people to buy in, and it's just to a lesser degree now. People who work for AI companies (like the author), posting AI stuff, trying to drum up more people to give them views/clicks, buy their products.
And of course you'll have people replying to this trying to make the case for why AI coding is already a thing, when in reality those posts are once again going to be carbon copies of similar comments from the Bitcoin days "hey, you're wrong, I bought pizza with Bitcoin last night, it's already taking over, bud!"
My feelings exactly. For a while I thought I was missing out and then I started learning how(and why) it works and I thought it was interesting but greatly over-hyped, exactly like bitcoin was.
I tried to follow the hype and generate an application but it took a lot of time and it did generate something but not something that works with many subtle bugs. Now it may be that I needed to prompt it better, but that response also feels similar to how Scrum is always "done wrong" when it doesn't work. The result started getting better when I got more and more detailed with my prompts and then I realized that I am about to start writing code as a prompt and I may as well write the code myself.
So I still think it's an interesting tool, and it will automate away certain industries but no where near what the advertising is implying.
Dismissing any new technology because of Bitcoin makes exactly as much sense as dismissing any new medical advancements because of Theranos. Ok, some people said Bitcoin would change the world, and they were wrong. Some people also said the PC, Internet, and smartphones would change the world, and they were right.
And of course you'll have people replying to this trying to make the case for why AI coding is already a thing, when in reality those posts are once again going to be carbon copies of similar comments from the Bitcoin days
What is the actual argument here? Anyone claiming that AI has been useful for them is a lying shill?
The difference is that Bitcoin was an overhyped solution looking for a problem.
Whereas AI is as big as life, eukaryotes, multi-cellularity, human intelligence, agriculture and the industrial revolution. It will certainly change everything (and make humans go extinct unless we are very careful).
peeThe difference is Bitcoin is a networked system. Bitcoin is useless if I use it and you/my landlord/stores/the taxman doesn't. If my pizza store doesn't take Bitcoin, I can't use my Bitcoin. Meanwhile, LLM assisted programming has value to its adherents without needing you/my landlord/stores/the taxman to even have heard of it. My time machine is just as good as yours, so I have no idea if OpenAI, specifically is going to be around in 10 years, but I can tell you that I'll still have deepseek-r1.ggml
It’s amazing to me all the Luddite developers who are “against” all this.
Completely new ways of programming are forming, completely new ways of computing and the best the luddites can do is be “against it”.
A revolution came along, a change in history and instead of being excited by the possibilities, joining in, learning, discovering, creating …… the luddites are just “against it all”.
I feel sorry for them. Why be in computing at all if you don’t like new technology?
There is a fundamentally unfortunate reality here which is quite problematic.
Namely, you don’t deserve to be paid for working 8 hours if you only worked for 30 minutes over an eight hour period.
I don’t care if you personally agree with that or not, the reality is that businesses believe it.
That means, sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.
It’s fun for home projects; but the somewhat depressing reality is that there is no chance in hell this (sitting around for 7 hours a day reading reddit while Claude codes) will fly in corporate environments; instead, you’re looking at mass layoffs.
So. Enjoy it while you can folks.
In the future you’ll be spending that 8 hours struggling to juggle the context and review 20 different tasks, not playing with your kids.
> That means, sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.
If human productivity and unemployment increases at the same time the obvious solution for regulators will be to decrease the work week from 5 to 4 days or even further
Man you struck a nerve with this one. All these devs want to believe they are still going to get paid $200k a year working 30mins a day. The reality is we will be spending the same 8 hours a day, be paid less, but now we need to work on 16 projects at the same time.
> sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.
this already started in 2022-23 with all the layoffs and "downsizing"
Twas always such. Until we build a system where necessities are cheap (housing scarcity is a self-imposed own goal for one) we will be in constant competition with our peers so the value we produce can be extracted by casual owners.
You are living in a fantasy land if you think any technology (besides maybe a replicator) will lead to less work. If that were the case we'd all be on a 10 hour work week already.
This article is spot on.
I had stumbled upon Kidlin’s Law—“If you can write down the problem clearly, you’re halfway to solving it”.
This is a powerful guiding principle in today’s AI-driven world. As natural language becomes our primary interface with technology, clearly articulating challenges not only enhances our communication but also maximizes the potential of AI.
The async approach to coding has been most fascinating, too.
I will add, I've been using Repl.it *a lot*, and it takes everything to another level. Getting to focus on problem solving, and less futzing with hosting (granted it is easy in the early journey of a product) - is an absolute game changer. Sparking joy.
I personally use the analogy of mario kart mushroom or star; that's how I feel using these tools. It's funny though, because when it goes off the rails, it really goes off the rails lol. It's also sometimes necessary to intercept decisions it will take.. babysitting can take a toll (because of the speed of execution). Having to deal with 1 stack was something.. now we're dealing with potential infinite stacks.
Because I can never focus on just one thing, I have a philosophy degree. I’ve worked with product teams and spent lots of time with stakeholders. I’ve written tons of docs because I was the only one on the team who enjoyed it.
I’ve always bemoaned my distractibility as an impediment to deep expertise, but at least it taught me to write well, for all kinds of audiences.
Boy do I feel lucky now.
I have a philosophy degree, have worked in product teams, and have had very similar observations. I could've written this comment!
I think about this a lot. Early on, as a self taught engineer, I spent a lot of time simply learning the vernacular of the software engineering world so that I could explain what it was that I wanted to do.
Repl.it is so hit or miss for me, and that's that is so frustrating. Like, it can knock out something in minutes that would have taken me an afternoon. That's amazing.
Then other times, I go to create something that is suggested _by them below the prompt box_ and it can't do it properly.
The fact that you think it was suggested _by_ them is I think where your mental model is misleading you.
LLMs can be thought of metaphorically as a process of decompression, if you can give it a compressed form for your scenario 1 it'll go great - you're actually doing a lot of mental work to arrive at that 'compressed' request, checking technical feasibility, thinking about interactions, hinting at solutions.
If you feed it back it's own suggestion it's no so guaranteed to work.
I don't think that the suggestions in the prompt box are being automatically generated on the fly for everyone. At least I don't see why they would be. Why not just have some engineers come up with 100 prompts, test them to make sure they work, and then hard-code those?
I would hope the suggestions in the prompt box are not being automatically generated by everyone else's inputs, I know what matters most is not the idea but execution but in the off hand you do have a really great and somewhat unique idea you probably wouldn't want it to be sent out to everyone who likes to take great ideas and implement it while you yourself are working on it.
Why do that when you can be lazy and get ‘AI’ to do the work.
You're misunderstanding me. Underneath the prompt box on the main page are suggestions of types of apps you can build. These are, presumably, chosen by people at the company. I'm not talking about things suggested within the chat.
The challenge is that clearly stating things is and always has been the hard part. It’s awesome that we have tools which can translate clear natural language instructions into code but even if we get AGI you’ll still have to do that. Maybe you can save some time in the process by not having to fight with code as much but you’re still going to have to create really clear specs which, again, is the hard part.
Anecdote
Many years ago, in another millennium, before I even went to university but still was an apprentice (the German system, in a large factory), I wrote my first professional software, in assembler. I got stuck on a hard part. Fortunately there was another quite intelligent apprentice colleague with me (now a hard-science Ph.D.), and I delegated that task to him.
He still needed an explanation since he didn't have any of my context, so I bit the bullet and explained the task to him as well as I could. When I was done I noticed that I had just created exactly the algorithm that I needed. I just wrote it down easily myself in less than half an hour after that.
in my experience only a limited part of software can be done with just really clear specs, also at times in my career I have worked on things that became more "clear" what was really needed as time went on the more we worked on it, and in those cases really clear specs would have produced worse outcomes.
Which is the real reason agile is so much more effective than waterfall. The beginning of the project is when you know least about your project, so naturally you should be able to evolve the specification.
You are confusing waterfall with BDUF.
hmm right, in some ways could argue that AI based development is going against Agile development practices.
Maybe it is that LLM coding makes it easier to loop back with little regard for development cost. When you can spend an hour to fix what would have been hampered severely by technical debt late in the process - are we starting to omit optimizing for proper SDLC?
Generally I find that agile works because getting a really clear spec is so hard. You’re slowly iterating towards a clear spec. What is a finished piece of software if not a completed spec?
100% agree AI based dev is at odds with agile. You’re basically going to use the AI to fully rewrite the software over and over until the spec becomes clear which just isn’t very efficient. Plus it doesn’t help that natural language cannot be as clear a spec as code.
>The challenge is that clearly stating things is and always has been the hard part.
I state things crystal clear in real life on the internets. Seems like most of the time, nobody has any idea what I'm saying. My direct reports too.
Anyway, my point is, if human confusion and lack of clarity is the training set for these things, what do you expect
Excellent. That’s what we should be doing, with or without AI. It’s hard, but it’s critical.
I've found LLMs to be a key tool in helping me articulate something clearly. I write down a few half-vague notes, maybe some hard rules, and my overall intent and ask it to articulate a spec, and then ask to for suggestions, feedback, questions to clarify from a variety of perspectives. This gives me enough material to clarify my actual requirements and then ask for that be broken down into a task list. All along the way I'm both refining my mental model and written material to more clearly communicate my intent to both machines and humans.
Increasingly I've also just ben YOLOing single shot throw-away systems to explore the design space - it is easier to refine the ideas with partially working systems than just abstract prose.
I'm loving the new programming. I don't know where it goes either, but I like it for now.
I'm actually producing code right this moment, where I would normally just relax and do something else. Instead, I'm relaxing and coding.
It's great for a senior guy who has been in the business for a long time. Most of my edits nowadays are tedious. If I look at the code and decide I used the wrong pattern originally, I have to change a bunch of things to test my new idea. I can skim my code and see a bunch of things that would normally take me ages to fiddle. The fiddling is frustrating, because I feel like I know what the end result should be, but there's some minor BS in the way, which takes a few minutes each time. It used to take a whole stackoverflow search + think, recently it became a copilot hint, and now... Claude simply does it.
For instance, I wrote a mock stock exchange. It's the kind of thing you always want to have, but because the pressure is on to connect to the actual exchange, it is often a leftover task that nobody has done. Now, Claude has done it while I've been reading HN.
Now that I have that, I can implement a strategy against it. This is super tedious. I know how it works, but when I implement it, it takes me a lot of time that isn't really fulfilling. Stuff like making a typo, or forgetting to add the dependency. Not big brain stuff, but it takes time.
Now I know what you're all thinking. How does it not end up with spaghetti all over the place? Well. I actually do critique the changes. I actually do have discussions with Claude about what to do. The benefit here is he's a dev who knows where all the relevant code is. If I ask him whether there's a lock in a bad place, he finds it super fast. I guess you need experience, but I can smell when he's gone off track.
So for me, career-wise, it has come at the exact right time. A few years after I reached a level where the little things were getting tedious, a time when all the architectural elements had come together and been investigated manually.
What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.
> What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.
Exactly my thinking, nearly 50, more than 30 years of experience in early every kind of programming, like you do, I can easily architect/control/adjust the agent to help me produce great code with a very robust architecture. By I do that out of my experience, both in modelling (science) and programming, I wonder how the junior devs will be able to build experience if everything comes cooked by the agent. Time will tell us.
I feel like we've been here before, and there was a time when if you're going to be an engineer, you needed to know core equations, take a lot of derivatives, perform mathematical analysis on paper, get results in an understandable form, and come up with solutions. That process may be analogous to what we used to think of as beginning with core data structures and algorithms, design patterns, architecture and infrastructure patterns, and analyzing them all together to create something nice. Yet today, much of the lower-level mathematics that were previously required no longer are. And although people are trained in their availability and where they are used, they form the backbone of systems that automate the vast majority of the engineering process.
It might be as simple as creating awareness about how everything works underneath and creating graduates that understand how these things should work in a similar vein.
Exactly right now, I am helping a big oil and gas company have a process simulation software to correctly converge on a big simulation. Full access to the source code, need to improve the Newton method in use with the right line search, validate the derivatives, etc.
I do think that for most of the people, you are right, you do not need to know a lot, but my philosophy was to always understand how the tool you use work (one level deeper), but now the tool is creating a new tool. How do you understand the tool which has been created by your Agent/AI tool?
I find this problem interesting, this is new to me and I will happily look at how our society and the engineering community evolve with these new capacities.
I don’t know how seniors will cope. You seem to have a solid understanding that you can make use of AI. But most seniors on HN struggle with basic tasks using AI. Juniors are likely to out pace them quickly. But potentially without the experience or understanding.
They cope just fine. If you’re thinking about stubborn ‘AI is just a statical parrot’ folks, IME it takes just one interaction where it clicks and nothing is the same afterwards. Perhaps we need GPT-5 or Gemini 3 for some of those people, but that’s what, a year out? Or a month?
Juniors need experience to know if the machine is going in the right direction or guide it. That experience is now nigh impossible to get, nobody has the time for apprentices now. It’ll take some brave management to pave a way forward, we don’t know what it’ll be exactly yet.
Really well said, it's a large amount of directing in additoin to anything else.
To continue this thought - what could have been different in the last 10-15 years to encourage junior developers to listen more where they might not have to those who were slightly ahead of them?
I also am enjoying LLMs, but I get no joy out of just prompting them again and again. I get so incredibly bored, with a little side of anxiety that I don’t really know how my program works.
I’ll probably get over it, but I’ve been realizing how much fun I get out building something as opposed to just having be built. I used to think all I cared about was results, and now I know that’s not true, so that’s fun!
Of course for the monotonous stuff that I’ve done before or don’t care a lick about, hell yeah I let em run wild. Boilerplate, crud, shell scripts, CSS. Had claude make me a terminal based version of snake. So sick
This is interesting. Maybe slow it down a bit? What I've found is I really need to be extremely involved. I approve every change (claude-code). I'm basically micromanaging an AI developer. I'm constantly reading and correcting. Sometimes I tell it to wait while I help it make some change it's hung up on.
There's no way I could hire someone who'd want me hovering over their shoulder like this.
This sounds tedious I guess, but it's actually quite zen, and faster than solo coding most of the time. It gives me a ton of confidence to try new things and new libraries, because I can ask it to explain why it's suggesting the changes or for an overview of an approach. At no point am I not aware of what it's doing. This isn't even close to what people think of as vibe coding. It's very involved.
I'm really looking forward to increasing context sizes. Sometimes it can spin it's wheels during a refactor and want to start undoing changes it made earlier in the process, and I have to hard correct it. Even twice the context size will be a game changer for me.
I've always felt building something was close to artistry. You create something out of your thoughts, you shape it how you want and you understand how it works to the most minute detail. The amount of times I've shown something seemingly simple to someone and went "but wait this is what is actually happening in the background!" and started explaining something I thought was cool or clever are great memories to me. AI is turning renaissance paintings into mass-market printing. There's no pride, no joy, just productivity. It's precisely those repetitive, annoying tasks that lead you to create a faster alternative, or to think outside the box and find different ways. I just don't get the hype.
> There's no pride, no joy, just productivity.
This is exactly what bothers me about the present moment. Not that the pride of craftsmanship is everything, but dialing it down to zero with extreme pressure to stay that way is a bit sad.
But we’ve clearly gone through this with other mediums before, perhaps someday people will appreciate hand written code the way we appreciate hand carved wood. Or perhaps we were all wasting time in this weird middle ground in the march of progress. I guess we’ll find out in 5-15 years.
I think the audience who can appreciate handcrafted code will be vastly smaller than the audience who appreciates hand carved wood.
> There's no pride, no joy, just productivity.
I think it’s more nuanced than that.
Not every project one does will be or should be considered art or a source of joy and pride.
The boring CRUD apps that put the “bread on the table” are just that, a means to an end, they will not be your main source of pride or fulfillment. But somewhere in between there will be projects where you can put all your heart in and turn off that LLM.
Think of the countless boring weddings playlists a DJ has to do or the boring “give me the cheapest” single family homes an architect has to design.
Well, that's a good example. Why would you get a DJ when you can say "Siri, play Weddings Classics"? There's no humanity involved, no skills to read the room or cater to audiences. So you get a DJ; what if your DJ thinks his job or your event is boring and generates the same playlist you could have done yourself? You need passion, you need interest, you need to be involved. Otherwise every job becomes tedious, and humanity dies.
My biggest problem with working LLMs is that they don't understand negatives and they also fail to remember their previous instructions somehow.
For example:
If I tell it to not use X, it will do X.
When I point it out, it fixes it.
Then a few prompts later, it will use X again.
Another issue is the hallucinations. Even if you provide it the entire schema (I did this for a toy app I was working with), it kept on making up "columns" that don't exist. My Invoice model has no STATUS column, why do you keep assuming it's there in the code?
I found them useful for generating the initial version of a new simple feature, but they are not very good for making changes to an existing ones.
I've tried many models, Sonnet is the better one at coding, 3.7 at least, I am not impressed with 4.
I've tried many models, Sonnet is the better one at coding, 3.7 at least, I am not impressed with 4.
If Sonnet 3.7 is the best you've found, then no, you haven't tried many models. At least not lately.
For coding, I'd suggest Gemini 2.5 Pro, o3-mini-high, or Opus 4. I've heard good things about Grok 4 as well, so if you're OK with that whole scene and the guy who runs it, maybe give it a shot.
If you have already done so and still think Sonnet 3.7 is better than any of them, then the most likely explanation is that you got incredibly lucky with Claude and incredibly unlucky with the others. LLMs aren't parrots, but they are definitely stochastic.
> Now that I have that, I can implement a strategy against it. This is super tedious. I know how it works, but when I implement it, it takes me a lot of time that isn't really fulfilling. Stuff like making a typo, or forgetting to add the dependency. Not big brain stuff, but it takes time.
Are people implementing stuff from start to finish in one go? For me, it's always been iterative. Start from scaffolding, get one thing right,then the next. It's like drawing. You start with a few shapes, then connect them. After you sketch on top, then do a line art, and then you finish with values (this step is also iterative refinements). With each step, you become more certain of what you want to do, while also investing the minimum possible effort.
So for me coding is more about refactoring. I always type the minimal amount of code to get something to work. And it usually means shortcuts which I annotate with a TODO comment. Then I iterate over, making it more flexible, adds more flexibility, makes the code more clean.
this is how I interact with the coding assistant.
one thing at a time. slowly adding features and fighting against bug regressions, same as when I was writting the code myself.
> What junior devs will do, I'm not so sure
I see it as a worrying extension of a pre-LLM problem: No employer wants to train, they just want to hire employees after someone else trains them.
so i guess that's a good argument for replacing employees with a bespoke LLM for your business-they will never leave after they're trained. and they never ask for a raise. and they dont need benefits or carry other human risks.
> I would normally just relax and do something else. Instead, I'm relaxing and coding.
So more work gets to penetrate a part of your life that it formerly wouldn't. What's the value of “productivity gains”, when they don't improve your quality of life?
Right, I’ve been using it recently for writing a message queue -> database bridge with checkpointing and all kinds of stuff (I work for a timeseries database company).
I saw this as a chance to embrace AI, after a while of exploring I found Claude Code, and ended up with a pretty solid workflow.
But I say this as someone who has worked with distributed systems / data engineering for almost 2 decades, and spend most of my time reviewing PRs and writing specs anyway.
The trick is to embrace AI on all levels: learn how to use prompts. learn how to use system prompts. learn how to use AI to optimize these prompts. learn how to first write a spec, and use a second AI (“adversarial critic”) to poke holes in that plan. find incompletenesses. delegate the implementation to a cheaper model. learn how to teach AI how to debug problems properly, rather than trying to one-shot fixes in the hope it fixes things. etc
It’s an entirely different way of working.
I think juniors can learn this as well, but need to work within very well-defined frameworks and probably needs to be part of college curriculum as well.
> So for me, career-wise, it has come at the exact right time. A few years after I reached a level where the little things were getting tedious, a time when all the architectural elements had come together and been investigated manually.
Wish I had your confidence in this. I can easily see how this nullifies my hard earned experience and basically puts me in the same sport as a more mid level or even junior engineer.
Have you had the realization that you could never go back to dealing with all the minutia again?
LLMs have changed me. I want to go outside while they are working and I am jealous of all the young engineers that won’t lose the years I did sitting in front of a screen for 12 hours a day while sometimes making no progress on connecting two black boxes.
Serious question: have you considered that dealing with all that minutiae and working through all that pain has made you capable to have the LLM write code?
Those young engineers, in 10 years, won't be able to fix what the LLM gave them,because they have not learned anything about programming.
They have all learned how to.micromanage an LLM instead.
> Those young engineers, in 10 years, won't be able to fix what the LLM gave them,because they have not learned anything about programming.
I have heard a version of this plenty of times, and it was never correct. In the early 90s it was the "electronics" people that were saying "I come from an electronics background, these young'uns will look at a computer and don't know what to do if it breaks". Well, bob, we did, the whole field moved to color coded anti-stupid design, and we figured it out.
Then I heard it about IDEs. Oh, you young people are so spoiled with your IDEs and whatnot, real men code in a text editor.
Then it was about frameworks. BBbbut what if your framework breaks, what do you do then, if you don't know the underlying whatever?
... same old, same old.
Have you also heard about calculators?
Every single finance person uses a calculator. How effective do you think a person in any aspect of finance would be if they had never learned what multiplication is? Would they perform their job adequately if they don't know that `X * Y` is `X repeated Y times`?
IOW, if you gave a finance person (accountant, asset manager, whatever) a non-deterministic calculator for multiplication, would you trust the person's output if they never learned what multiplication is?
This is the situation I am asking about; we aren't talking about whether deterministically automating something that the user already knows how to do is valuable, we're talking about whether non-deterministically generating something that the user is unable to do themselves, even if given all the time in the world, is valuable.
All those examples you give are examples of deterministic automation that the user could inspect for accuracy. I'm asking about a near-future where people managing your money have never learned multiplication because "Multiplication has been abstracted away to a tool that gets it right 90% of the time"
If I may play the devil's advocate, nothing is deterministic. A neutrino could cause a bit flip in your calculator. More commonly, the lower abstractions we build upon without knowing their innards can have bugs. Even the most popular compilers (say, g++) have bugs, for instance. I am personally incapable of fixing a bug within gcc, despite the tool being a vital requirement of my work.
IMO the dichotomy should not be deterministic/stochastic, but proved/unproved reliable. gcc has been shown reliable, for instance, so I don't need to know whether it was built by deterministic (clever engineers) or stochastic (typewriting monkeys) processes. I'm certain the former are more efficient, but this is ultimately not what makes the tool valuable.
As a bit of an artificial example, there's stochastic processes that can be proved to converge to a desired result (say, a stochastic gradient descent, or Monte-Carlo integration), in the same way that deterministic methods can (say a classic gradient descent or quadrature rules).
In practical cases, the only proof that matters is empirical. I write (deterministic) mathematical algorithms for a living, yet they very rarely come out correct on first iteration. The fact there is a mathematical proof that a certain algorithm yields certain results lets me arrive at a working program much faster than if I left it to typewriting monkeys, but it is ultimately not what guarantees a valid program. I could just as well, given enough time, let a random text file generator write the programs, and do the same testing I do currently, it would just be very inefficient (an understatement).
> Have you also heard about calculators?
Yup, my mom used to say "you need to be able to do it without a calculator, because in life you won't always have a calculator with you"... Well, guess what mom :)
But on a serious note, what I'm trying to say (perhaps poorly worded) is that this is a typical thing older generations say about younger ones. They'll be lost without x and y. They won't be able to do x because they haven't learned about y. They need to go through the tough stuff we went through, otherwise they'll be spoiled brats.
And that's always been wrong, on many levels. The younger generations always made it work. Just like we did. And just like the ones before us did.
There's this thing that parents often do, trying to prepare their children for the things they think will be relevant, from the parent's perspective. And that often backfires, because uhhh the times are achanging. Or something. You get what I'm trying to say. It's a fallacy to presuppose that you know what's coming, or that somehow an entire generation won't figure things out if they have a shortcut to x and y. They'll be fine. We're talking about millions / billions of people eventually. They'll figure it out.
You didn't even come close to addressing his points about non-deterministic outcomes? Aka the crux of the issue...
Junior engineers will be lost if they don't take the time to read the code generated by the LLM and really understand it. This is an objective truth. It has nothing to do with boomer takes.
Funny, that's what I said, as an experienced assembly hacker, when somebody first showed me a C compiler.
People who "take the time to really understand the code" will rapidly be outcompeted by people who don't. You don't like that, I don't like that, but guess what: nobody cares.
I suppose we'll get over it, eventually, just like last time.
LLMs are not compilers. They can't be deterministic. A better comparison is an autocorrect on steroids.
And I don't think there's anything to get over about them. They are useful but people elevate their significance too much over what they actually are.
An unhealthy attachment to determinism will turn out to be a career-limiting hangup, I suspect. You already lack insight into how 100% of the code in your project works, unless you only work on trivial projects. Did you think that state of affairs was going to get better with time? As usual, TDD covers a multitude of sins.
As for "autocorrect," let us know when your "autocorrect" takes gold at the International Math Olympiad, with or without steroids.
Talk is cheap. Give your LLM/agent your badge and let it turn in 100% of your job.
That'd be awesome. Not going to happen this week or this year, but it will.
Enjoy being unemployed then, I guess?
Yeah, there are qualitative differences.
I might offload multiplying some numbers to a calculator, but Kids These Days™ are trying to offload executive function, like "what should I do next" or "is there anything I've forgotten".
I see a version of this every day.
Developers throwing huge amounts of money (in cloud resources) at performance problems that would’ve been prevented if they had some understanding of how their tech stack actually worked.
> In the early 90s it was the "electronics" people that were saying "I come from an electronics background, these young'uns will look at a computer and don't know what to do if it breaks".
...and today, Nvidia ships self-immolating graphics cards because nobody wanted to figure out how to design a safe electric connector.
> Oh, you young people are so spoiled with your IDEs and whatnot, real men code in a text editor.
...and today, a lot of so-called programmers are trapped in AbstractHellFactorySingletonFactories that they cannot and never will understand, because generations of code monkeys have abused IDE assistance to dig themselves deeper into their hole.
And as a user, you'll know, because the software they write is garbage and never works reliably.
> Then it was about frameworks. BBbbut what if your framework breaks, what do you do then, if you don't know the underlying whatever?
Going by software like Teams, or Slack: They just ignore it, because consumers can't fight back against the the enshittification of increasingly useless software nobody understands.
Losing first principles will have some kind of an unexpected result.
Like, this is how we've always done it.
Finding a way to better learn first principles compared to sitting in front of a screen for 12 hours a days is important.
This is exactly what makes me excited as well. It really does replace the tedious parts of coding I’ve done thousands of times at this point.
What junior devs will do, I'm not so sure. They somehow have to jump to the top of the mountain, but the stairs are gone.
"That's OK, I found a jetpack."
Chess is probably a good analogue to how the juniors will learn. You will have to learn for the sake of it even though the space is solved.
That's a pretty good take. I was actually looking for a good analogy recently
I think if I was just starting out learning to program, I would find something fun to build and pick a very correct, typed, and compiled language like Haskell or Purescript or Elm, and have the agent explaining what it's doing and why and go very slow.
Hot take: Junior devs are going to be the ones who "know how to build with AI" better than current seniors.
They are entering the job market with sensibilities for a higher-level of abstraction. They will be the first generation of devs that went through high-school + college building with AI.
Where did they learn sensibility for higher-level of abstraction? AI is the opposite, it will do what you prompt and never stop to tell you its a terrible idea, you will have to learn yourself all the way down into the details that the big picture it chose for you was faulty from the start. Convert some convoluted bash script to run on Windows because thats what the office people run? Get strapped in for the AI PowerShell ride of your life.
How is that different than how any self-taught programmer learns? Dive into a too-big idea, try to make it work and learn from that experience.
Repeat that a few hundred times and you'll have some strong intuitions and sensibilities.
The self-taught programmer's idea was coded by someone who is no smarter than they are. It will never confuse them, because they understand how it was written. They will develop along with the projects they attempt.
The junior dev who has agents write a program for them may not understand the code well enough to really touch it at all. They will make the wrong suggestions to fix problems caused by inexperienced assumptions, and will make the problems worse.
i.e. it's because they're junior and not qualified to manage anybody yet.
The LLMs are being thought of as something to replace juniors, not to assist them. It makes sense to me.
> Dive into a too-big idea, try to make it work and learn from that experience.
Or... just pick up that book, watch a couple of videos on Youtube and avoid all that trying.
AI is the opposite, it will do what you prompt and never stop to tell you its a terrible idea
That's not true at all, and hasn't been for a while. When using LLMs to tackle an unfamiliar problem, I always start by asking for a comparative review of possible strategies.
In other words, I don't tell it, "Provide a C++ class that implements a 12-layer ABC model that does XYZ," I ask it, "What ML techniques are considered most effective for tasks similar to XYZ?" and drill down from there. I very frequently see answers like, "That's not a good fit for your requirements for reasons 1, 2, and 3. Consider UVW instead." Usually it's good advice.
At the same time I will typically carry on the same conversation with other competing models, and that can really help avoid wasting time on faulty assumptions and terrible ideas.
Do you think that kids growing up now will be better artists than people who spent time learning how to paint because they can prompt an LLM to create a painting for them?
Do you think humanity will be better off because we'll have humans who don't know how to do anything themselves, but they're really good at asking the magical AI to do it for them?
What a sad future we're going to have.
more reasons for humans not to birth more humans
Like the iPad babies and digital natives myth? I don’t think that really went anywhere. So a new generation of… native prompters? Ehhh.
This is the same generation that falls for online scams more than their grandparents do[1].
[1] https://www.vox.com/technology/23882304/gen-z-vs-boomers-sca...
It may be the same generation, but it's probably not the same people.
I think the argument is that growing up with something doesn't necessarily make you good at it. I think it rings especially true with higher level abstractions. The upcoming generation is bad with tech because tech has become more abstract, more of a product and less something to tinker with and learn about. Tech just works now and requires little in assistance from the user, so little is learned.
Yeah, I have a particular rant about this with respect to older generations believing "kids these days know computers." (In this context, probably people under 18.)
The short version is that they mistake confidence for competence, and the younger consumers are more confident poking around because they grew up with superior idiot-proofing. The better results are because they dare to fiddle until it works, not because they know what's wrong.
I think this disregards the costs associated with using AI.
It used to be you could learn to program with a cheap old computer a majority of families can afford. It might have run slower, but you still had all the same tooling that's found on a professional's computer.
To use LLMs for coding, you either have to pay a third party for compute power (and access to models), or you have to provide it yourself (and use freely available ones). Both are (and IMO will remain) expensive.
I'm afraid this builds a moat around programming that will make it less accessible as a discipline. Kids won't just tinker they way into a programming career as they used to, if it takes asking for mom's credit card from minute 0.
As for HS + college providing a CS education using LLMs, spare me. They already don't do that when all it takes is a computer room with free software on it. And I'm not advocating for public funds to be diverted to LLM providers either.
It is known team size and speed are not linear.
Many times adding a new junior to a team makes it slower.
How does using llms as junior makes you more productive?
At one hand you get insane productivity boost, something that could take maybe days, weeks or months to do now you can do in significantly shorter amount of time, but how much are you learning if you are at a junior level and not consciously being careful about how you use it, feels like it can be dangerous without a critical mindset, where you eventually rely too much on it that you can't survive without it. Or maybe this is ok? Perhaps the way of programming in the future should be like this, since we have this technology now, why not use it?
Like there's a mindset where you just want to get the job done, ok cool just let the llm do it for me (and it's not perfect atm), and ill stitch everything together fix small stuff that it gets wrong etc, saves alot of time and sure I might learn something in the process as well. And then the other way of working is the traditional way, you google, look up on stackoverflow, read documentations, you sit down try to find out what you need and understand the problem, code a solution iteratively and eventually you get it right and you get a learning experience out of it. Downside is this can take 100 years, at the very least much longer than using an llm in general. And you could argue that if you prompt the llm in a certain way, it would be equivalent to doing all of this but in a faster way, without taking away from you learning.
For seniors it might be another story, it's like they have the critical thinking, experience and creativity already, through years of training, so they don't loose as much compared to a junior. It will be closer for them to treat this as a smarter tool than google.
Personally, I look at it like you now have a smarter tool, a very different one as well, if you use it wisely you can definitely do better than traditional googling and stackoverflow. It will depend on what you are after, and you should be able to adapt to that need. If you just want the job done, then who cares, let the llm do it, if you want to learn you can prompt it in certain way to achieve that, so it shouldn't be a problem. But this sort of way of working requires a conscious effort on how you are using it and an awareness of what downsides there could be if you choose to work with the llm in a certain way to be able to change the way you interact with the llm. In reality I think most people don't go through the hoops of "limiting" the llm so that you can get a better learning experience. But also, what is a better learning experience? Perhaps you could argue that being able to see the solution, or a draft of it, can be a way of speeding up learning experience, because you have a quicker starting point to build upon a solution. I dunno. My only gripe with using LLM, is that deep thinking and creativity can take a dip, you know back in the day when you stumbled upon a really difficult problem, and you had to sit down with it for hours, days, weeks, months until you could solve that. I feel like there are some steps there that are important to internalize, that LLM nowdays makes you skip. What also would be so interesting to me is to compare a senior that got their training prior to LLM, and then compare them to a senior now that gets their training in the new era of programming with AI, and see what kinds of differences one might find I would guess that the senior prior to LLM era, would be way better at coding by hand in general, but critical thinking and creativity, given that they both are good seniors, maybe shouldn't be too different honestly but it just depends on how that other senior, who are used to working with LLMs, interacts with them.
Also I don't like how LLM sometimes can influence your approach to solving something, like perhaps you would have thought about a better way or different way of solving a problem if you didn't first ask the LLM. I think this could be true to a higher degree for juniors than seniors due to gap in experience when you are senior, you sort of have seen alot of things already, so you are aware of alot of ways to solve something, whereas for a junior that "capability" is more limited than a senior.
So you are relaxing and the AI is coding? Neat! Way to replace yourself, hope you won't cry after your job once it is gone.
What you miss is the constant need to refine and understand the bigger picture. AI makes everyone a lead architect. A non-coder can't do this or will definitely get lost in the weeds eventually.
It doesn’t make everyone a lead architect, it just makes everyone think they’re a lead architect. What makes people a lead architect is a decade or two of experience in designing software and learning what works and doesn’t.
What makes people a lead architect in my experience is an abnormal amount of arrogance and no capability to admit mistakes.
That just gives the title. To be really successful, they need to let someone else, knowledgeable, actually make the architecture decisions.
Yeah that's the actual senior developers who just ignore everything the architect architects.
Right, but a lead architect can be a lead architect on multiple projects at the same time, and the world doesn't need as many lead architects as it has programmers.
This kind of working is relaxing and enjoyable until capitalism discovers that it is, and then you have to do it on five projects simultaneously.
I'm using AI assistants as an interactive search and coding assistant. I'm still driving the development and implementing the code.
Where I use it for is:
1. Remembering what something is called -- in my case the bootstrap pills class -- so I could locate it in the bootstrap docs. Google search didn't help as I couldn't recall the right name to enter into it. For the AI I described what I wanted to do and it gave the answer.
2. Working with a language/framework that I'm familiar with but don't know the specifics in what I'm trying to do. For example:
- In C#/.NET 8.0 how do I parse a JSON string?
- I have a C# application where I'm using `JsonSerializer.Deserialize` to convert a JSON string to a `record` class. The issue is that the names of the variables are capitalized -- e.g. `record Lorem(int Ipsum)` -- but the fields in the JSON are lowercase -- e.g. `{"ipsum": 123}`. How do I map the JSON fields to record properties?
- In C# how do I convert a `JsonNode` to a `JsonElement`?
3. Understanding specific exceptions and how to solve them.
In each case I'm describing things in general terms, not "here's the code, please fix it" or "write the entire code for me". I'm doing the work of applying the answers to the code I'm working on.
Why I don't bother with LLMs for the above is:
1. I usually just pull up the docs for the CSS framework, give it a quick look over to know what it offers and the nomenclature and then keep it open for all the code examples.
2. I've serialized json in enough languages to know the pain points, so what I usually do is locate the module/library responsible for that in that language. And then give the docs/code sample a quick lookover to know where things are.
3. With nice IDEs, you launch the debugger and you have a nice stack frame to go through. In languages with not so great tooling, you hope for a trace.
It's not that your workflow won't yield result. But I prefer to be able to answer 5 successive why's about the code I'm working on. With PRs taking hours and days to be merged, it's not like I'm in an hurry.
For 1 I tried looking through the bootstrap documentation but couldn't find it because they called it "Pills" and not what I was thinking. So I then tried google to search for it but that didn't work.
For 3 -- Sure, that can help. But sometimes it is difficult to follow what is going on. Especially if that comes from a library/framework you are unfamiliar with such as AWS.
I've also used it to help with build errors such as "Bar.csproj: Error NU1604 : Warning As Error: Project dependency Foo does not contain an inclusive lower bound. Include a lower bound in the dependency version to ensure consistent restore results." -- That was because it was using a fixed version of the module via the "[1.0]" syntax, but my version of NuGet and/or Rider didn't like that so once I new that and the range syntax specifying "[1.0, 1.0]" worked. I was able to understand that from the LLM response to the error message and telling it the specific `<PackageReference>`.
He's still telling the AI what to code. Prompting, i.e. deciding the right thing to build then clearly specifying and communicating it in English, is a skill in itself. People who spend time developing that skill are going to be more employable than people who just devote all their time to coding, the thing at which LLMs are more cost effective.
My theory on AI is it's the next iteration of google search, a better more conversational, base layer over all the information that exists on the internet.
Of course some people will lose jobs just like what happened to several industries when search became ubiquitous. (newspapers, phone books, encyclopedias, travel agents)
But IMHO this isn't the existential crisis people think it is.
It's just a tool. Smart, clever people can do lots of cool stuff with tools.
But you still have to use it,
Search has just become Chat.
You used to have to search, now you chat and it does the searching, and more!
Yeah; there's still a massive chasm between "I spent hours precisely defining my requirements for this greenfield application with no users and the AI one-shot it" and "million line twenty team enterprise SaaS hellscale with ninety-seven stakeholders per line of code".
The fact that AI can actually handle the former case is, to be clear, awesome; but not surprising. Low-code tools have been doing it for years. Retool, even back in 2018, was way more productive than any LLMs I've seen today, at the things Retool could do. But its relative skill at these things, to me, does not conclusively determine that it is on the path toward being able to autonomously handle the latter.
The english language is simply a less formal programming language. Its informality means it requires less skill to master, but also means it may require more volume to achieve desired outcomes. At some level of granularity, it is necessarily the case that programming in english begins to look like programming in javascript; just with capital letters, exclamation points, and threats to fire the AI instead of asserts and conditionals. Are we really saving time, and thus generating higher levels of productivity? Or, is its true benefit that it enables foray into languages and domains you might be unfamiliar with; unlocking software development for a wider range of people who couldn't muster it before? Its probably a bit of both.
Dario Amodei says we'll have the first billion dollar solo-company by 2026 [1]. I lean toward this not happening. I would put money on even $100M not happening, barring some level of hyperinflation which changes our established understanding of what a dollar even is. But, here's what I will say: hitting levels of revenue like this, with a human count so low that the input of the AI has to overwhelm the input from the humans, is the only way to prove to me that, actually, these things might be more than freakin awesome tools. Blog posts from people making greenfield apps named after a furrsona DJ isn't moving the needle for me on this issue.
[1] https://www.inc.com/ben-sherry/anthropic-ceo-dario-amodei-pr...
AI is still in an experimental phase for many teams, especially when it comes to handling complex, long-term projects. For PMs and EMs, the cost-benefit analysis of AI credits vs. manual tasks is a big concern before fully committing to AI adoption. Some teams have seen great success, particularly in areas where speed and flexibility are key, but others are still waiting for clearer ROI before diving in. It’ll be interesting to see how the balance of risk and reward evolves as AI tools mature.
> Dario Amodei says we'll have the first billion dollar solo-company by 2026 [1]. I lean toward this not happening.
Why not? Not like companies have to actually do anything beyond marketing to get insane evaluations… remember theranos?
Theranos peaked at ~800 employees, FYI.
Reason 1: Because any company with one individual who leverages AI to achieve a billion dollar valuation would trivially & obviously be more valuable and be able to achieve more if they had two people leveraging AI. And, at a billion dollar valuation; why not pay that extra salary? Why not add a third? There's a huge difference in potential output by building with a founder team of 2 or 3 people versus 1; with not that much difference in cost.
Reason 2: The most capital efficient valuations in history are B2C companies (Instagram & Whatsapp are maybe the two best examples) during the VC boom era of the 2010s. B2C is naturally very capital efficient; you can do inbound marketing, no sales teams, just build. But, B2C success stories are more-and-more rare; the name of the game in the 2020s era has generally been B2B. Cursor might be the fastest company to reach $500M in revenue, and it got there on B2B, Notion isn't building its AI tools to sell to its consumer customers, etc. B2B is a lot harder; it requires outbound marketing & sales, as well as customer-led product development that usually requires interacting with people. AI will absorb some of those roles, but to suggest it can widdle down to one person per billion dollars in valuation in a year feels too accelerated to me. The world is complex, old, and crusty.
Just look at the YC batches for 2025 [1]: Of the 375 companies in the three batches, 20 are Consumer tech (~5%).
Reason 3: Weaker, but something I think about: AI is weirdly non-differentiating/egalitarian. You see some people try to differentiate it with crazy prompts or context engineering, but then next month Cursor ships an update and suddenly those aren't differentiating anymore. If you're an investor in a single-person unicorn-moonshot, you have to ask: Why can't some other company just come in and do the same thing you're doing? If that much can be automated through off-the-shelf systems. My feeling is that this concern would lead to lower revenue multiples on the valuation, which just makes it that much harder to hit unicorn status.
[1] https://www.ycombinator.com/companies?batch=Summer%202025&ba...
> Search has just become Chat
I think chat-like LLM interfacing is not the most efficient way. There has to be a smarter way.
There is certainly much innovation to come in this area.
I'm thinking about Personal Knowledge Systems and their innovative ideas regarding visual representations of data (mind maps, website of interconnected notes, things like that). That could be useful for AI search. What elements are doing in a sense is building concept web, which would naturally fit quite well into visualization.
The ChatBot paradigm is quite centered around short easily digestible narratives, and will humans are certainly narrative generating and absorbing creatures to a large degree, things like having a visually mapped out counter argument can also be surprisingly useful. It's just not something that humans naturally do without effort outside of, say, a philosophy degree.
There is still the specter of the megacorp feed algo monster lurking though, in that there is a tendency to reduce the consumer facing tools to black-box algorithms that are optimized to boost engagement. Many of the more innovative approaches may involve giving users more control, like dynamic sliders for results, that sort of thing.
English and other languages come with lots of ambiguity and assumptions. A significant benefit of programming languages is they have explicit rules for how they will be converted into a running program. An LLM can take many paths from the same starting prompt and deliver vastly different output.
I do agree… perhaps the thing to do is write fragments of the program, like the start and end, asking it to complete the middle. If you have precisely described how the output will be printed, for example, then you have essentially formally specified how the data should be organized…
I think Photoshop is a good guide here.
Famously complicated interface with a million buttons and menus.
Now there's more buttons for the AI tools.
Because at the end of the day, using a "brush" tool to paint over the area containing the thing you want it to remove or change in an image is MUCH simpler than trying to tell it that through chat. Some sort of prompt like "please remove the fifth person from the left standing on the brick path under the bus stop" vs "just explicitly select something with the GUI." The former could have a lot of value for casual amateur use; it's not going to replace the precise, high-functionality tool for professional use.
In software - would you rather chat with an LLM to see the contents of a proposed code change, or use a visual diff tool? "Let the agent run and then treat it's stuff as a PR from a junior dev" has been said so many times recently - which is not suggesting just chatting with it to do the PR instead of using the GUI. I would imagine that this would get extended to something like the input not just being less of a free-form chat, but more of a submission of a Figma mockup + a link to a ticket with specs.
> Famously complicated interface with a million buttons and menus.
Photoshop is quite nice for an expert tool. Blender is the complicated one where you have to get a full-sized keyboard and know a handful of shortcuts to have a normal pace.
> The former could have a lot of value for casual amateur use; it's not going to replace the precise, high-functionality tool for professional use.
I was just discussing that in another thread. Most expert works are routine, and they will build workflows, checklists, and processes to get them to be done with the minimum cognitive load. And for that you need reliability. Their focus are on the high leverage decision points. Take any digital artist's photoshop settings, They will have a specific layout, a few document templates, their tweaked brushes. And most importantly, they know the shortcuts because clicking on the tiny icons takes too much times.
The trick is not about being able to compute, it's knowing the formula and just give the parameters to a computer that will do the menial work. It's also not about generating a formula that may or may not be what we want.
There’s an efficient way to serve the results, and there’s an efficient way for a human to consume them, and I find LLMs to be much more efficient in terms of cognitive work done to explore and understand something than a google search. The next thing will have to beat that level of personal mental effort, and I can’t imagine what that next step would look like yet.
I find a well-written human article or guide to be far more efficient when it exists. But if AI rehash them... then the market for those may disappear, and in the process, the AI won't be very good either without the source to summarise.
I don’t disagree with that at all, but that’s not what I’m talking about. The market for serving information goes where the people want to consume it. The old portals of the 90s gave way to search because it was easier for people to find what they wanted. LLMs give people an even easier way to find information. The downstream effects don’t factor into most people’s decision to use an LLM over source material.
Search wasn't just "search". It was "put a prompt in a form and then spend minutes/hours going through various websites until I get my answer". LLMs change that. I don't have to go through 20 different people's blog posts on "Which 12v 100Ah LifePO4 battery tests for the highest watt hours", the LLM simply just gives me answer that is most relevant across those 20 blog posts. It just distilled what I would have taken an hour to do down to seconds or 2 minutes.
> LLMs change that
Yup. Now you get a quick reply and have to then do the same job as before to validate it. Except all websites are deploying crawler countermeasures so it takes even longer now.
Unlike peak google, this reduces signal to noise and obfuscates the source data its pulling against.
Creation of source data has been disincentivized
A lot of modern entry-level jobs were filled by people who knew how to use google and follow instructions.
I imagine the next generation will have a similar relationship with AI. What might seem "common sense" with the younger, more tech-saavy crowd, will be difficult for older generations whose default behavior isn't to open up chatgpt or gemini and find the solution quickly.
Google doesn’t have to change search. It already returns AI generated crap before anything useful.
To be fair, Google also returns a lot of useless crap that wasn't generated by AI.
wasn't generated by their AI, more like
Append -ai to your query to omit AI results.
I appended changing my search engine
I was a bit wary of trusting the AI summaries Google has been including in search results… but after a few checks it seems like it’s not crap at all, it’s pretty good!
I think their point is that all of the content out there is turning in to AI Slop so it won't matter if search changes because the results themselves have already been changed.
I like the way DuckDuckGo does it - it offers a button to generate a response if you want to, but it doesn't shove it down your throat.
It's handy when I just need the quick syntax of a command I rarely need, etc.
I have systemic concerns with how Google is changing roles from "knowledge bridging" to "knowledge translating", but in terms of information: I find it very useful.
You find it gives you poor information?
Always check the sources. I've personally found it;
- Using a source to claim the opposite of what the source says.
- Point to irrelevant sources.
- Use a very untrustworthy source.
- Give our sources that do not have anything to do with what it says.
- Make up additional things like any other LLM without source or internet search capability, despite reading sources.
I've specifically found Gemeni (the one Google puts at the top of searches) is hallucination-prone, and I've had far better results with other agents with search capability.
So... presenting a false or made-up answer to a person searching the web on a topic they don't understand... I'd really like to see a massive lawsuit cooked up about this when someone inevitably burns their house down or loses their life.
I’ve had to report AI summaries to Google several times for telling me restaurant items don’t contain ingredients I'm allergic to, when the cited “source” allergen menu says otherwise. They’re gonna kill someone.
> - Using a source to claim the opposite of what the source says.
That's because a lot of people do that all the time when arguing online. Cite something without bothering to read it.
As search gives the answer rather than the path to it, the job of finding things out properly and writing it down for others is lost. If we let that be lost, then we will all be lost.
If we cannot find a way to redirect income from AI back to the creators of the information they rehash (such as good and honest journalism), a critical load-bearing pillar of democratic society will collapse.
The news industry has been in grave danger for years, and we've seen the consequences it brings (distrust, division, misinformation, foreign manipulation). AI may drive the last stake in its back.
It's not about some jobs being replaced; that is not even remotely the issue. The path we are on currently is a dark one, and dismissing it as "just some jobs being lost" is a naive dismissal of the danger we're in.
I am looking forward to the "news industry" breathing its last breath. They're the ones primarily responsible for the distrust and division.
The news industry of the future will be Joe Rogan and friends. Arguably it already is. Hard to see how that’s an improvement on what came before.
No, i fully disagree.
The economic viability to do proper journalism was already destroyed by the ad supported click and attention based internet. (and particular the way people consume news through algorithmic social media)
I believe most independent news sites have been economically forced into sensationalism and extremism to survive. Its not what they wilfully created.
Personally, i find that any news organisations that is still somewhat reputable have source of income beyond page visits and ads; Be it a senior demorgaphic that still subscribe to the paper, loyal reader base that pay for the paywall, or government sponsoring its existence as public service.
Now what if you cut out the last piece of income journalists rely on to stay afloat? We simply fire the humans and tell an AI to summarise the other articles instead, and phrase it how people want to hear it.
And thats a frightening world.
My take is that journalists, was fighting enshittification as long as they could one looming bankruptcy leading to consolidation or closed shop at a time.
It's clearly useful for many things other than search.
I agree that people are using it for things they would've googled, but I doubt that it's a good replacement.
To me it mostly comes with a feeling of uncertainty. As if someone tells you something he got told on a party. I need to Google it, to find a trustful source for verification, else it's just a hint.
So I use it if I want a quick hint. Not if I really want to have information worth remembering. So it's certainly not a replacement for me. It actually makes things worse for me because of all that AI slop atm.
This comment makes no sense here. Did you read the article? The author built an entire SaaS app in a few days with an agent. That isn't "just search"
"I'd wander into my office, check what Claude had built, test it real quick. If it worked, great! Commit and push."
Man, I'm going to make so much money as a Cybersecurity Consultant!
The MBA hears ya. The MBA don't care.
I tend to generally think the same as you, as I work in the same field. A long time ago I thought to myself, if AI adoption increases exponentially, there is a chance that the amount of security vulnerabilities introduced by it also increases at the same rate.
However, what we are maybe not considering enough is that general AI adoption could and almost certainly will affect the standards for cybersecurity as well. If everyone uses AI and everyone gets used to its quirks and mistakes and is also forgiving about someone else using it since they themselves use it too, the standards for robust and secure systems could decrease to adjust to that. Now, your services as a cybersecurity consultant are no longer in need as much, as whatever company would need them can easily point to all the other companies also caring less and not doing anything about the security issues introduced by the AI that everyone uses. The legal/regulation body would also have to adjust to this, as it is not possible to enforce certain standards if no one can adhere to them.
I don’t follow. Cybersecurity has always been about reducing the risk of costly cyber attacks. That hasn’t changed. It’s not like suddenly companies will stop caring that their software has been locked down by ransomware, or that their database leaked and now they have to pay a nine-figure fine. It’s not standards for standards’ sake (though it can feel that way). It’s loss prevention.
Sure, in the case of ransomware, phishing the ceo, etc. you are right. But for most other cases that AI would affect, it's not like companies would care if there weren't regulatory consequences forcing them to.
Potentially. But also remember what they say about self-driving cars, that it'd make fewer and fewer mistakes than a real driver.
Yeah, when I'm building side projects that sometimes have more traction than anticipated I build them taking many shortcuts.
I've found LLM's add lots of standard protections to api endponts, or database constraints etc than I would do on a lazy Saturday.
Tesla drivers are involved in more accidents than drivers of any other brand.
Real drivers would also do fewer mistakes if they only drove in the limited and ideal conditions the self driving cars are limited to.
Waymos are in many cities and doing really well.
Why are we counting the number of documents? It doesn't matter. What matters is putting together a plan and being able to articulate what you want. Then review and adjust and prompt again.
You have to know how software gets built and works. You can't just expect to get it right without a decent understanding of software architecture and product design.
This is something that's actually very hard. I'm coming to grips with that slowly, because it's always been part of my process. I'm both a programmer and a graphic designer. It took me a long while to recognize not everyone has spent a great deal of time doing both. Fewer yet decide to learn good software design patterns, study frameworks and open-source projects to understand the problems each of them are solving. It takes a LOT of time. It too me probably 10-15 years just to learn all of this. I've been building software for over 20 years. So it just takes time and that's ok.
The most wonderful thing I see about AI is that it should help people focus on these things. It should free people from getting too far into the weeds and too focused on the code itself. We need more people who can apply critical thinking and design from a bird's eye perspective. We need people who can see the big picture.
Knowing is at least half the battle. Doesn't matter what kind of tools you intend to use if you don't even know where the job site is located.
I've been around the block a few times on ideas like a B2B/SaaS requirements gathering product that other B2B/SaaS vendors could use to collect detailed, structured requirements from their customers. Something like an open-world Turbo Tax style workflow experience where the user is eventually cornered into providing all of the needed information before the implementation effort begins.
> The most wonderful thing I see about AI is that it should help people focus on these things.
Unfortunately I’ve been around this industry long enough to know that this is not in fact what is going to happen. We will be driven by greedy people with small minds to produce faster rather build correct systems, and the people who will pay will be users and consumers.
I seem to have missed the part where he successfully prompted for security, internationalizability, localizability, accessibility, usability, etc., etc.
This is a core problem with amateurs pretending to be software producers. There are others, but this one is fundamental to acceptable commercial software and will absolutely derail vibe coded products from widespread adoption.
And if you think these aspects of quality software are easily reduced to prompts, you've probably never done serious work in those spaces.
> And if you think these aspects .. , you've probably never done serious work in those spaces.
To be fair, a lot of commercial software clearly hasn't, either.
what makes you think that the writer omitted these? Any good developer would include these parts of the requirements. That's why we make the money we do. We know what is involved. That is orthogonal to the use of LLMs for coding.
I'm skeptical too, but at least accessibility and usability do show up in those four documents they link to.
I didn't see internationalization and localization, but I don't see anything fundamental about those that would be different.
Security, on the other hand, does feel like a different beast.
Isn’t that like „the dog speaks English, but makes occasional grammar mistakes“?
Give it two years.
It’s been two more years for the past three years. What’s going to happen in those two years? Are we going to find 10 more internets to train on?
two years ago it didn’t do anything that made me want to use it during work.
The data wall idea of needing 10 more internets is like the peak oil theory of the 2000s, imho. I don’t think 10 more internets are required, and all those tasks like proper security and i18n, none of these require creativity of any kind. These are ideal candidates for LLMs to solve quite soon.
But to talk about the data wall more: Current SOTA LLMs are trained on circa 30-50T tokens. First, that is not a full internet‘s worth; it is estimated that Meta owns more like 200T tokens of user data etc. Second, the work in optimizing for data efficiency is just beginning.
Exactly.
>My four-document system? Spaghetti that happened to land in a pattern I could recognize. Tomorrow it might slide off the wall. That's fine. I'll throw more spaghetti.
Amazing that in July 2025 people still think you can scale development this way.
A bit part of this that people are not understanding is that a major part of the author's success is due to the fact that he clearly does not care at all how anything is implemented, mostly because he doesn't need to.
You get way farther when you have the AI drop in Tailwind templates or Shadcn for you and then just let it use those components. There is so much software outside that web domain though.
A lot of people just stop working on their AI projects because they don't realize how much work it's going to take to get the AI to do exactly what they want in the way that they want, and that it's basically going to be either you accept some sort of randomized variant of what you're thinking of, or you get a thing that doesn't work at all.
The input to output ratio is interesting. We are usually optimizing for volume of output, but now it’s inverted. I actually don’t want maximum output, I want the work split up into concrete, verifiable steps and that’s difficult to achieve consistently.
Ive taken to co-writing a plan with requirements with cursor and it works really well at first. But as it makes mistakes and we use those mistakes to refine the document eventually we are ready to “go” and suddenly it’s generating a large volume of code that directly contradicts something in the plan. Small annoyances like its inability to add an empty line after markdown headings have to be explicitly re added and re-reminded.
I almost wish I had more control over how it was iterating. Especially when it comes to quality and consistency.
When I/we can write a test and it can grind on that is when AI is at its best. It’s a closed problem. I need the tools to help me, help it, turn the open problem I’m trying to solve into a set of discrete closed problems.
>I've been coding for long enough to remember when we carved HTML tables by hand. When CSS was a suggestion, not a lifestyle. When JavaScript was for mouseover effects and nothing else.
Cringe. The tech is half baked and the author is already fully committed to this is the future, I am living in the future, I bake cookies while Claude codes.
Pure cringe. This confirms my earlier theories that everyone just wants to be a manager. You don't need to manage humans. You just want to be a manager.
The whole article could be summed down to I always wanted to be a manager and now I am a manager of bots.
I've been experimenting with model-based development lately, and this resonated strongly with me.
The section "What Even Is Programming Anymore?" hit on a lot of the thoughts and feels I've been going through. I'm using all my 25+ years of experience and CS training, but it's _not_ programming per se.
I feel like we're entering an era where we're piloting a set of tools, not hand crafting code. I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse. We'll still need to craft things by hand, but we're opening some doors to new methodologies.
And, right now, those methodologies are being discovered, and most of us are pretty bad at them. But that doesn't mean they're not going to be part of the industry.
> I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse.
I think you're spot on. It was once necessary to acquire knowledge in order to acquire productivity. This made knowledge valuable and worth attaining. Now, with LLMs, we we can skip the middle man and go straight to the acquisition of productivity. I'd call it the democratisation of knowledge, but it's something more than that — knowledge just isn't needed anymore.
This kind of makes sense. I love acquiring knowledge, just for knowledges sake. That’s why I got into math and programming in the first place. I just like learning stuff. It was a happy accident that the stuff I like doing happens to also be lucrative. Kind of sucks that all that stuff I spent my life doing is losing value by the day. I love programming because there are an endless amount of things to learn. I actually care very little about the productivity.
> knowledge just isn't needed anymore
I would argue we still need the knowledge: the principles aren't changing, and they are needed to be truly productive in certain things. But the application of those principles _are_ changing.
Which makes me wonder: why shouldn't AI use be a core part of technical interviews now? If we're trading "knowledge of how to code" for "knowledge of how to use LLMs" and treating Claude like a much more productive junior engineer, do we still need to filter candidates on their ability to write a doubly linked list? And if we are still asking those sorts of interview questions, why shouldn't candidates be able to use LLMs in the process? After all, like others have said elsewhere in this thread, you still need some core technical capabilities to effectively manage the AI. It's just a tool and we can judge how well someone knows how to use it or not.
There's a fundamental problem with your question, which is the suggestion that technical interviews are still needed at all. Technical roles can be replaced with roles that are more akin to production managers, and we should absolutely be testing those candidates for LLM competency.
I don’t know which models you guys are working with, but all of the SOTA ones I’ve tried in different configurations ended up producing mostly garbage.
I find myself having to spend more time guiding the model in the right direction and fixing its mistakes than I would’ve spent building it all myself.
Every time I read one of these stories I feel like maybe you guys have models from 2035, because the ones we have today seem to be useless outside of creating greenfield, simple React apps that just sort of work.
One thing I’ll say is that it’s been a real time saver for debugging. For coding, a huge waste of time. Even for tasks that are menial, repetitive, require no thinking etc. I find that it’s mostly crap.
this isn’t vibe coding. This is something completely new. I call it “flex coding.”
heck I built a full app in an afternoon AND I was a good dad?
> I'd wander into my office, check what Claude had built, test it real quick. If it worked, great! Commit and push. "Now build the server connection UI," I'd say, and wander back out.
Made breakfast. Claude coded.
Played with my son. Claude coded.
Watched some TV. Claude coded.
Every hour or so, I'd pop back in. Five minutes of testing. One minute of feedback.
This is all very emotive and I'm sure is a dream many of us would love to live.
But does Claude's code work? Does it work to the level where you'd depend on it yourself; where you'd bill customers for it; where you'd put your reputation behind it?
I say no. And it's because I use Claude. Two events changed how I use Claude: now it's an advisor, and I mostly type the code myself. Because I don't trust it.
First, I caught it copying one of my TypeScript interfaces and modifying it. So now we have User which looks like my actual user, that I defined, and UserAgain which does not, and which Claude is now using and proudly proclaiming that my type checks all pass. Well of course they do!
Second, I was told that the best way to catch this sort of thing is to get it to write tests. So it wrote some tests, and they failed, and it kept going, and it eventually wrote an un-failable test. The test mocked itself.
So, sure, enjoy time with your kids. Please don't ask me to use your app for anything important.
It's interesting reading comments on both sides of this. Some people are answering no, and others are answering yes to your question and succeeding at it... so far.
I've experienced the exact issues you've described. I've also drastically reduced these issues via good instructions and automated followup passes that eliminate code that was created from ignored instructions.
It all feels like a hack, but the more I choose to trust it and treat it like it's the correct path and that it's just a different set of problems that need to be solved, the more success I have.
I had Claude, as an agent, get into an infinite loop trying to resolve a diagnostic in Java test that any human would easily figured out and fixed in a second.
I feel that it is a commom thing. You just have to "keep an eye on it". There are several failure modes with Claude. Maybe the most annoying is that it often uses kind of defensive programming, so it is harder to detect that there is a fatal mistake somewhere. It can hide those really well. And it loves to fix linter issues with any type in typescript.
Im using it regardless. Ive just learnt to deal with these and keep an eye on them. When it creates a duplicate interface I roll back to earlier prompt and be more explicit that this type already exists.
I try to not argue whether something it does is wrong or right. There is not point. I will simply rollback and try with another prompt. Claude is not a human.
So like, why would I pay someone to work like this? Or why would I pay for software at all when I could just do this myself?
Because you can't do this yourself. You don't have the decades of experience to know how to ask the questions and when to steer the tool into a different direction.
Why not? As the AI people say "you can just do things". If there is little consequence to getting it wrong as a parent poster puts it why not? You can learn over time like any other skill.
I want to be wrong (it will affect me and my family personally) - but there is a reason every AI proponent talks about coding and making "coding redundant". For most jobs/industries software is a compliment (e.g. Product Owner, BA, etc) unless that is your main skill in which case it is your main service you are selling. Most roles want to turn software into a commodity or the typical business PM word "resource" that they can acquire as they need - the dream of most business roles (e.g. Project Managers, BA's, etc). It sadly also seems to be low hanging fruit of LLM's; doesn't mean there isn't other aspects to the job of course but coding is becoming "less special" with these technologies especially with common tech and use cases.
This is something I've been thinking about. What should students do? How do they build experience? Do they swear off all forms of LLM assisted coding?
That's the real question IMO. Especially when everything that isn't deflationary with AI for the most part is getting much more expensive due to inflation globally. Save money on software, buy more blue collar goods.
If its an easy skill to learn, with little consequences if you get it wrong especially for small scale apps why pay for it? Don't know why seniors (of which I'm one) think they are immune to this.
consider it like this: you are not paying the amount of worked hours but for the expertise to judge, coach and guide the AI and its output according to your wishes. so if the result is good and within time and budget, why would you care?
careful, Claude might soon start complaining you're not pulling your weight and refuse to work
Let’s see this app.
Congratulations, you just passed project management class.
What you describe is exactly what a project manager does. Refines the technical, stories, organizes the development towards a goal.
This doesn’t feel like programming because it isn’t. It doesn’t NOT feel like programming because you’re supervising. In the end, you are now a project manager.
To me it feels like I’m in the camp of people who has already figured it out. And I have now learned the hard way that it’s almost impossible to teach others (I organized several meetups on the topic).
The ability seems like pure magic. I know that there are others who have it very easy now building even complex software with AI and delivering project after project to clients at record speed at no less of quality as they did before. But the majority of devs who won’t even believe that it’s remotely possible to do so is also not helping this style of building/programming mature.
I wouldn’t even call it vibe coding anymore. I think the term hurts what it actually is. For me it’s just a huge force multiplier, maybe 10-20x of my ability to deliver with my own knowledge and skills on a web dev basis.
I feel like I’m in your camp, to my own surprise.
I’ll try my hand at some guidelines: the prime directive would be “use the right ai tool for the right task”. Followed by “use a statically typed language”. Followed by “express yourself precisely in English. You need to be able to write like a good technical lead and a good product manager.”
With those out of the way:
Completions work when you’re doing lots of rote moderately difficult work within established patterns. Otherwise, turn them off, they’ll get in the way. When they do work, their entire point is to extend your stamina.
Coding agents work when at-worst a moderately novel vertical needs implementation. New architecture and patterns need to be described exhaustively with accurate technical language. Split up the agents work into the same sort of chunks that you would do between coffee breaks. Understand that while the agent will make you 5x faster, you’ll still need to put in real work. Get it right the first time. Misuse the agent and straightening out the mistakes will cost more time than if you hadn’t used the agent at all.
If novelty or complexity is high, use an advanced reasoning model as interactive documentation, a sparring partner, and then write the code by hand. Then ask the reasoning model to critique your code viciously. Have the reasoning model configured for this role beforehand.
These things together have added up to the biggest force multiplier I’ve encountered in my career.
I’m very much open to other heuristics.
> If novelty or complexity is high, use an advanced reasoning model as interactive documentation, a sparring partner, and then write the code by hand. Then ask the reasoning model to critique your code viciously. Have the reasoning model configured for this role beforehand.
Does this mean basically "Opus"? What goes into "Have the reasoning model configured for this role beforehand."?
Just record yourself doing it and post online. If the projects are indeed complex and you’ve found a way to be 20x more productive people will learn from it.
The problem is not having any evidence or basis on which to compare claims. Alchemists claimed for centuries to synthesize gold, if they only had video we could’ve ruled that out fast.
It's just hard to believe something is real when it's not reproducible.
The spec, or prompts system, whatever you call it, is more like a recipe than code. It doesn't automatically generate the dishes; a good cook is still needed.
Yes and culinary schools exist and create new cooks in a reproducible way. Why can't coding with ai be taught?
I disagree with the OP that AI coding can't be taught. My answer to why so many people have trouble would be that they refuse to learn. I see tons of people who are insanely biased against AI and then when they try and use it they give up after the first go (having tried a horrible application of AI like making a functioning production app with 1 single prompt, no one using AI for work is using it like that). They also don't take any suggestions on using it better because "I've tried it before and it sucked."
If you asked me months ago whether "prompt engineering" was a skill I'd have said absolutely not, it's no different than using stack overflow and writing tickets, but having watched otherwise skilled devs flounder I might have to admit there is some sort of skill needed.
FWIW, some people need training on using stack overflow and writing good tickets
Because LLMs arent calculators. Theyre non deterministic. Recipes and dishes are predictably reproducible, ai output isnt.
I fully expect that in 1-2 years that SWE curriculum will have AI coding as a major feature. The question I have is will students be required to do their first year or first assignments in a given course without AI.
My ex teaches UX. We were talking about AI in academia last week. She said that she requires students to not use AI on their first assignment but on subsequent ones they are permitted to.
your problem domain is greenfield freelancing if i am reading you correctly?
The tarpit of AI discussion is that everybody assumes that their local perspective is globally applicable. It is not.
This.
I work in a large corpo eco system of products across languages that talk to a mess of micro and not so micro services.
Ai tools are rarely useful out of the box in this context. Mostly because they can't fit the ecosystem into their context. I think i would need 10 agents or more for the task.
We have good documentation, but just fitting the documentation into context alongside a microservice is a tight fit. Most services would need one agent for the code (and even then it'd only fit 10% in context), and one for the docs.
Trying to use them without sufficient context, or trying to cram the right 10% into context, takes more effort than just coding the feature, and produces worse results with the worst kind of bugs, subtle ones borne from incorrect assumptions.
I've noticed a great deal programmers, very good programmers at that, that completely underestimate how fast things are moving. They're natural skeptics, and checked out ChatGPT when it was released. Then they maybe checked out some other models a year after. But eventually wrote it off as hype, and continue to do things their way. You know, artisanal code and all that.
I think that if you willfully ignore the development, you might be left in the dust. As you say, it is a force multiplier. Even average programmers can become extremely productive, if they know how to use the AI.
> For me it’s just a huge force multiplier, maybe 10-20x of my ability to deliver with my own knowledge and skills on a web dev basis.
I can tell you that this claim is where a lot of engineers are getting hung up. People keep saying that they are 10, 20 and sometimes even 100x more productive but it's this hyperbole that is harming that building style more than anything.
If you anyone could get 10 to 20 years worth of work done in 1 year, it would be so obvious that you wouldn't even have to tell anyone. Everyone would just see how much work you got done and be like "How did you do 2 decades worth of work this year?!"
I agree. I'd say it's simply that 20 years of software development isn't bottle necked by the ability to churn out code.
yep plus all these companies going all in on AI would have already laid off 95% of their software engineers.
What sort of code are you writing? I find a lot of my stuff requires careful design, refactoring an existing system to work in a new way.
If the code I was writing was, say, small websites all the time for different clients, I can see it being a big improvement. But iterating on a complex existing platform, I’m not so sure that AI will keep the system designed in a maintainable and good way.
But if your experience is with the same sort of code as me, then I may have to re evaluate my judgments.
There's a weird insecurity I've noticed cropping up. I want to design the codebase 'my way'. I want to decide on the fundamental data structures. But there's this worry that my preferred architecture is not massively better than whatever the machine comes up with. So by insisting on 'my way' I'm robbing everyone productivity.
I know most true programmers will vouch for me and my need to understand. But clients and project managers and bosses? Are they really gonna keep accepting a refrain like this from their engineers?
"either it gets done in a day and I understand none of it, or it gets done in a month and I fully understand it and like it"
Until an LLM or some new form of AI can manage an entire architecture itself, I say we need a middle ground. Something will always go wrong, and understanding of the system is necessary to troubleshoot.
Not sure if a developer would ever say that to their manager. Agreed on the need to 100% fully understand what's going on. Otherwise the "AI can get it done in a day" is extremely high risk to the business. Junior may not be able to recognize a half-baked solution that doesn't follow existing patterns, poor security, poor performance, etc.
So far:
- when I ask models to do defined that I know how to do and can tell them about that method but can't remember the details off off hand and then I check the answers things work.
- when I attempt to specify things that I don't understand fully the model creates rubbish 7 out of 10 times, and those episodes are irretrievable. About 30% of the time I get a hint of what I should do and can make some progress.
Probably down to a combination of LLMs on average having a harder time with tasks that humans typically find difficult, and the task of prompting being easier the more you know about the problem.
The only thing that should matter in software development is: does it work to spec?
Why are these chatbots that mangle data 1/3 to 1/2 of the time getting their budgets 10x over and over again?
This is irrational. If the code mangles data this bad, it's garbage.
> The only thing that should matter in software development is: does it work to spec?
Unless you've never written code outside of a classroom you should know how unbelievably wrong this is.
Maybe it's just semantics, but it doesn't feel so wrong to me. The main nuance is that this statement needs to be true over time as the spec changes. Developers try to write maintainable code so that their code will still work/adapt to spec when the spec changes. Maintainable code feels less important in a world where AI can rewrite a growing portion of your code quickly. I find myself accepting a much lower bar for non-critical parts of my projects with the knowledge that claude can rewrite it quickly if needs change. But disclaimer: I haven't yet used this technique in teams. The norms on usage aren't there yet.
Not sure what the complaint is about. If the coding work has to be thrown away, we need to do that and move on. We did that many times earlier. We have thrown away hunting, farming, calculations by hand, cameras and so on. Coding work might get extinct for some use cases. Nothing wrong with it. Learn how to use your tools, assistants and godzillas.
The bigger issue, would there be a need for coding and software? Who would use them? Why are they using it? Are they buying something? searching for info? The usecase will see a revolution. The new usecases won't need the traditonal kind software. But AI can only produce traditional software.
Can I ask Claude to code up its clone for local use?
The "time dialation" is real. I mostly manage these days, yet my fun projects progress faster than they ever have, because I can prompt in the 2 minutes between meetings, and come back to significant progress.
Yes, it's not faster to develop with AI if you watch it work. It's faster to develop with AI if you parallelize. Typing was never the bottleneck, but is is a now-parallelizeable part of the pipeline.
> Yes, it's not faster to develop with AI if you watch it work.
It’s actually a lot faster. You read the diffs as soon as they start coming in, and immediately course correct or re-prompt when you see bad mistakes.
I don't have this experience. Watching and course correcting like this makes me realize I could have done a better job myself
That’s always true in my experience, but that doesn’t necessarily mean you need to. The trick I’m working towards is refining the workflow such that i can reliably produce maybe 90% as “good” as what I’d personally produce but much, much faster. All sorts of side work I was avoiding before also becomes much easier, less tedious refactors and large test coverage and etc. It can type much faster than I can, the trick is if we can constrain the thinking enough to make it useful. Keeping it as an autocomplete is as productive as it is difficult imo.
Indeed, I hit the stop button quite a bit when Claude goes off course. Then make a note of the right choice so maybe it won't do that again, revert and proceed. I have the feeling there is an optimal size of project proportional to the context size, where you can fit the critical design points into the context and/or there are enough examples in the code of how things should be done.
presumably you've done the work enough pre-AI to notice those mistakes?
It can still be faster to develop with AI watching it work. It can legitimately introduce an entire simple fullstack change across multiple projects in my monorepo including graphql queries/mutations, typeorm repository, a service layer, and a reactnative frontend using apollo client, etc. It can do that in about 10 minutes in my local. I can't. If I turned it into a speed run event and practiced, maybe I could get it done in 10 minutes but honestly, it's a machine and I'm John Henry. Since it's using my IDE, it's using my meticulously setup and maintained local and I'm able to quickly stop it and fix any mistake it makes. Level 2 driving assist.
I have enjoyed the github copilot agent style development where someone elses computer is running everything, and I can make a request and just come back half an hour later and check on it. But this level 5 driver gets the wrong destination basically every time, and then it's another 10, 20 or even 30 minutes for it to make a minor adjustment. It doesnt understand my `yarn` scripts, it runs my tests wrong, it can't do codegen, it doesn't format or lint files, etc. I asked copilot yesterday to lint and format a PR and it took 25 minutes of agentic work lol.
For me, one of the new superpowers is the ability to interactively do multiple drafts following different design principles and see which works better.
I just started an embedded project where two different people had implemented subsystems independently, and I asked Claude to merge the code into a single project and convert the existing synchronous code into asynchronous state machines called from a single main loop. It wrote three drafts with me giving it different stylistic principles to follow. I don't know if I would have had the patience to do that myself!
> I'm able to quickly stop it and fix any mistake it makes
I would think that's the process too, but according to the article the dude is almost completely hands off:
> You come back to ten thousand lines of code. You spend 5 minutes reading. One sentence of feedback. Another ten thousand lines appear while you're making lunch.
You can't humanly review 10 thousand lines of code in 5 minutes. This is either complete bullshit or it really writes flawless code for them and never makes any mistakes.
I feel increasingly tired of reading excuse after excuse when you bring up that AI tools simply cannot solve anything beyond extremely basic problems.
It's always a mix of:
1. "Wait for the next models", despite models having all but plateaued for the past 3 years,
2. "It's so good for boilerplate code", despite libraries and frameworks being much better suited for this task, and boilerplate code being actually rare to write in the normal lifecycle of a project,
3. "You need to prompt it differently", glossing over the fact that to prompt it so it can do what you want it to do accurately it would take longer than not to use AI at all,
4. And the worst: "We don't know how to use those models yet"
Maybe the real reason it doesn't work is because IT JUST DOESN'T FUCKING WORK.
Why is it so unfathomable that a next token generator is gonna suck at solving complex problems? It is blindingly obvious.
There’s about half a trillion reasons that it’s unfathomable to some.
> I'd wander into my office, check what Claude had built, test it real quick. If it worked, great! Commit and push.
Do people read the code? Or just test if it work and push?
To me, code is like a map that has to be clear enough so other humans can read it to navigate the territory (codebase). Even if it's just two – me and AI agent – working on the codebase, it's not much different from "me and another programmer". We both want to have updated mental model of how exactly code structured and how it works and why.
Using AI for coding and not reading the code sounds more like stopping being developer and self-promoting yourself to the manager of AI-programmers who trusts their craft completely.
Stefan Munz called this “YOLO vs tight-leash” at a very entertaining agentic coding meetup in Hamburg recently.
https://bsky.app/profile/stefanmunz.bsky.social
https://www.meetup.com/de-DE/de-DE/agentic-coding-meetup-ham...
"You’re using it wrong" arguments/hype articles showing up. Speculators love it. But in reality if you need to extol the benefits of AI, then is it really the user or the technology?
Honestly reminds me of the digital currency mania that busted a couple of years ago. Same types of articles popping up too.
Look I understand the benefits of AI but it’s clear ai is limited by the compute power of today. Maybe the dream this author has will be realized some day. But it won’t be today or in current generations lifespan.
The entire premise of using AI to build stuff is founded on the idea that building faster is somehow automatically better.
I’m starting to believe that’s not necessarily true. And if some study finds out later that stuff built slowly by hand is actually better in every way except time-to-market, then it means AI is not really a competitive edge, it’s just a Quality of Life improvement that allows software engineers to be even lazier. And at future price points of $200, $400, even $1000 a month per head, that becomes a hard sell for most companies. Might be easier to have engineers pay for their own AI if they want to be lazy. And of course whether they use AI or not, you can still measure productivity under the assumption that every engineer does…
I don’t mean to be a dick, but stuff like this
> With enough AI assistants building enough single-purpose tools, every problem becomes shallow. Every weird edge case already has seventeen solutions. Every 2am frustration has been felt, solved, and uploaded.
> We're not drowning in software. We're wading in it. And the water's warm
Just sounds like GPT style writing. I’m not saying this blog is all written by GPT, but it sounds like it is. I wonder if those of us who are constantly exposed to AI writing are starting to adopt some of that signature fluffy, use-a-lot-of-words-without-saying-much kinda style.
Life imitates art. Does intelligence imitate artificial intelligence?? Or maybe there’s more AI written content out there than I’m willing to imagine.
(Those snippets are from another post in this blog)
> "coherent desire" or "precise imagination" or "structured wishing."
the most precise way to express your desire is by giving computer commands, or you may call it programming.
That time dilation feels a bit like what METR reported:
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
Developers believe they complete tasks 25% faster with AI but when measured they are 19% slower when using AI.
This was the study with a population size of 16?
16 developers doing hundreds of tasks. And the effect size was big enough for the result to be statistically significant.
Do you have any better research we can read?
This was the only study that's been done so far?
That’s reminiscent of how when people are “in the flow”, they feel productive but also tend to not notice how quickly time passes.
It depends on how the AI is used; there's a huge difference in productivity between a structured workflow with repeated automated feedback to the AI, and just ad-hoc prompting. For instance, Gemini 2.5 coding up a spec-compliant HTTP2.0 server in two weeks: https://outervationai.substack.com/p/building-a-100-llm-writ... . 15k lines of code and 30k lines of tests; no human coder could produce something like that so fast.
Would that application not exist in the training data already?
The are around three Golang HTTP2.0 servers on Github, but it wasn't just regurgitating the application from memory, as if it was then it would have been mostly correct first try, and it wouldn't have needed to spend 80%+ of the development time in a code-compile-test cycle of fixing bugs identified by integration tests and spec conformance tests.
So you are saying that LLMs have no capacity to re-use existing work, and will just burn hours and money re-inventing wheels?
If you tell it to reinvent the wheel, it will.
If you tell it to use existing libraries (and they are in its training data) it will do that instead.
If you tell it about libraries it hasn't encountered before it can use those instead.
Welcome to The Future™!
It's cool that it made something that works, but that code is pretty bad. Trial and error is not the way to develop something like that.
I would not say that is ”how the AI is used”. That problem space is one where humans have spent unusually much time defining a spec and writing a test suite.
A million monkeys randomly typing could actually complete that task as well.
Reminds me of that quaalude scene from the movie The Wolf of Wall Street.
Im going to be overly picky about the subheading (which is an incidental aspect of TFA): “The future of software development might just be jazz. Everyone improvising. Nobody following the sheet music.”
That’s not jazz. Jazz being what it is, a lot of people in 2025 think it’s “everyone improvising,” but (outside of some free jazz) it’s quite structured and full of shared conventions.
Analogies work when you and your audience both understand the things being compared. In this case, the author doesn’t, and maybe some of the audience shares the same misperception, and so the analogy only works based on shared misunderstanding.
The analogy to jazz actually works better the more you know about it. But that’s accidental.
Software jazz is when you and your teammate are working hard on a project and you both land big PRs at the same time without a merge conflict, then integrate before the build system even has time to realize what happened.
Based on how easy it is to trigger cool-down or throttle on Claude Code, I think people know how to build with AI. Or they’re trying really hard to figure it out. The race is on and it’s wide open.
There are a lot gotchas with these new models. They get incredibly lazy if you let them. For example, I asked it to do a simple tally by year. I just assumed it’s simple enough I don’t need to ask to write a code. It counted first couple of years and just “guessed” the rest based on pattern it noticed.
Sometimes, it feels like having a lazy coworker that you have to double check constantly and email with repeated details. Other times, I just sit there in awe of how smart it is in my weekly AGI moment and how it’s going to replace me soon.
I’m feeling limited by the tools right now. The software for using LLMs is an incongruent mess. For example, how can I have a global system prompt shared across all the apps I use my OpenRouter key with? I can’t, I have to set it in each application. How can I carry a conversation over from one app to another? How can I give all my apps access to the same set of MCP tools? Most of the apps I use don’t even properly support MCP yet.
It sounds like Claude Code is the best UX right now but I don’t want to be locked into a Claude subscription, I want to bring my own key and tap into whatever provider I want.
I have this small project that lets you use Claude code (because their terminal UI is really smart) with any OpenRouter model:
https://github.com/terhechte/CCORP
Works fine on macOS / Linux, untested on Windows. Still working on improving it.
Thanks, interested in trying this.
Excuse me, you can't build software that fast, and definitely not while making pancakes. Please return to your regularly scheduled struggling.
Eh, idk. First of all, the article is really wordy to say very few things. That just frustrated me a bit.
Second of all, it's easy to fart out some program in a few days vibe coding. How will that fare as more and more features need to be added on? We all used to say "Dropbox that's just FTP wrapped in a nice UI anyone can make that". This protocollie project seems to be a documentation viewer / postman for MCP. Which is cool, but is it something that would have taken a competent dev months to build? Probably not. And eventually the actual value of such things is the extensibility and integrations with various things like corporate SAML etc.
Will the vibe code projects of today be extensible like that, enough to grab market share vs the several similar versions and open source versions anyone can make in a few days, as the author suggests? It can be hard to extend a codebase you don't understand because you didn't write...
I definitely did a double take when I got to this section. I am neither an AI optimist nor an AI pessimist (probably slightly on the optimistic side of the midpoint) but this sounds insane to me for any software that people might truly depend on. Five minutes of review for 10,000 lines, happening multiple times per day?
I did some digging, and this seems to be the project the author is using AI to work on: https://github.com/sublayerapp/sublayer
You look at the PRs... there are 786(!) AI generated pull requests and an associated AI generated code review for each one. Each PR is about ~20-100 lines of Ruby (including comments) that implements an "action" for the sublayer system as a Ruby class. So probably something that could be handled by a macro expander. Or at least it's AI used as a fancy macro expander.
But yeah, there's about 20k lines of code right there easily. Although, because it's Ruby, it's not (much) of an exaggeration to say ~50% of the generated lines are a single "end" keyword.
The author is someone who before AI, would publish ~300 commits a year to Github. This year they are on track for 3000 commits using AI. But the result seems to be that PRs are accumulating in their repo, implementing hundreds of features. I'm wondering why the PRs are accumulating and not getting merged if the code is good? Is the bottleneck now review? What would happen if AI took over PR merging as well as PR creation?
He deleted the PRs? Struck a nerve
> First of all, the article is really wordy to say very few things.
A clickbaity title in opposition with the content isn't helpful either. I would've recommended their "The Great Experiment Nobody's Running the Same Way" heading as a better choice, even thought it might not perform as well from a content marketing POV.
>Which is cool, but is it something that would have taken a competent dev months to build? Probably not.
Right...but it exists today. The days of wondering "should I spend time building this" are gone.
The very next sentence of mine
> And eventually the actual value of such things is the extensibility and integrations with various things like corporate SAML etc.
I could make a Dropbox clone by hand in a weekend. I could make one with AI in a few hours. Neither will be valuable like Dropbox because the value is the hard stuff that I have yet to see proof AI can do
Funny enough, I’m building a tool that does basically what the author describes, but with a bit more software engineering driving it (context-llemur)
https://github.com/jerpint/context-llemur
The idea is to track all of the context of a project using git. It’s a CLI and MCP tool, the human guides it but the LLM contributes back to it as the project evolves
I used it to bootstrap the library itself, and have been using it more and more for context management of all sorts of things I care about
Reminds me of Sussman’s “We don’t know how to compute” which is essentially maligning that we haven’t gone full Smalltalk with some Lisp sprinkled on top to get “soft computers.”
None of that is actually what makes my favorite tools work. It’s usually some nerds that never stopped using C/C++ and really know hardware.
> There's this moment in every new technology where everyone pretends they know what they're doing.
Perhaps that is true, but without any examples I was immediately suspicious of this line.
> Either way, we're in this delicious middle ground where nobody can pretend expertise because the whole thing keeps changing under our feet.
Upon reflection this does in fact remind me of the early days of rocketry when we were just reaching into the upper atmosphere and then orbit. Wild things were being tried because there was not yet any handrails. Exploding a huge tank of water in the ionosphere just because, launching giant mylar balloons into orbit to try and bounce radar signals off of them, etc.
So, is Protocollie actually any good? I don't have any means of evaluating the final product, but I feel like evaluating what ultimately stuck to the wall is a pretty important part of the tale.
How buggy is it? How long would it have taken to build something similar by hand?
We are expecting a moment like when sublime was born. Sidebar map, concurrent cursors, blazing speed.
Right now its all monetization at gravity. As if companies are ready to pour software developer salaries in tools.
I imagine beginners will not have gpu rich environments and AI will not reach mainstream as traditional development did, unless something happens, idk what.
Right now, seniors love the complexity and entry barrier to it, so they can occupy the top of the food chain. History has proven that that does not last long.
In some scenarios as airtable, AI is replacing docs and customer support, eleminating the learning curve.
I like to use it to generate python and react Ui components with tailwind css
And also to help me troubleshoot my old yacht, it taught me to be an amateur marine electrician
I do not let it into my entire codebase tho. Keep the context small and if I dont get what I want in one or two prompt I dont use it
Instead of walking away, I have worked on multiple projects at the same time. Prompt one project, let it run, prompt another project, let it run and go back to the first.
Maybe walking away is a better choice hah.
Yep! I work on multiple client projects. And while one agent is running in one project, I’m reviewing and writing down the task for another. Generally I just do this 2-3 hours per day; trying to block this time. And then go outside and enjoy free time.
Enjoy it while it lasts. Once this becomes the norm, the free time will diminish.
At what point does LLM output become more expensive than search? For example, the author made protocollie. Could the LLM gather all similar apps that are already written to solve the prompt that birthed it,, and then simply provide THOSE apps iinstead of figuring out how to code it anew? Sounds like this could be a moat that only hyperscalars could implement and woould reduce their energy requirements drastically.
Takes me more time to define what I want than to make the thing
I like to use other parts of the codebase (or other codebases) as an example which helps a lot to maintain standards and consistency (though adds cost).
I am a bit disillusioned - I find mentoring humans satisfying but I don't get the same satisfaction mentoring AI. I also think it's a probably going to backfire by hamstringing the next generation and 'draining the competence' from the current.
> The Story Breakdown - Everything in 15-30 minute chunks. Why? Because that's roughly how long before Claude starts forgetting what we discussed ten minutes ago. Like a goldfish with a PhD.
This is interesting. Does Claude have a memory? Is this just a limit on the number of input tokens? It sounds like a fundamental misappropriation of cause, but maybe I just don't understand the latest whizbang feature of Claude. Can anyone clarify?
I was hoping this would be about building products with AI.
Building with LLMs is a bit like driving with GPS. You ever get that feeling the GPS is wrong or leading you along a difficult route? But for some reason you follow the GPS anyway? Maybe there's a name for the phenomenon. I notice it more and more.
The decision making parts of people's brains will atrophy. It will be interesting to see what will happen.
Impossible to read this. Very wordy and full of tangents.
How wonderful for all of us to be thrown back into “what are we doing” mode. Like when you were a teenager, hacking stuff you were just excited to build, with none of the “here’s how you should do this” we’ve burdened ourselves with over the years.
This isn’t about replacing developers. It’s about redefining them. Developers are becoming system choreographers, not syntax specialists.
I want claude code on my phone running in a cloud vm so I can give feedback out on a trail somewhere and continue my three hour hike or bike ride with my family.
Just enjoy the hike and bike ride and keep the coding at home (:
I am working on something for that at https://automa.app. Let me know if you are interested in trying it out.
I think you can already kind of do that with something like vibetunnel :)
https://vibetunnel.sh
Screen+SSH. 90s technology. An LLM probably could have told you this.
I find its all about the joy of building with the subset you can be an expert in and the AI telling you where the typo is and why it still wont work after fixing it.
The market value of software diminishes as it becomes significantly easier to write.
Nobody knows how to build with AI yet, and the corollary (which TFA concludes with) is that everybody should figure out for themselves how to best work with AI.
I've said it before and I'll say it again: there likely isn't a "golden workflow" or "generally accepted best practices" on how to code with AI. The new models and agentic capabilities seem to be very powerful, and they will conform to whatever methodologies you currently use with whatever project you're working on, but that may still be under-utilizing what they are truly capable of.
A true optimum may even require you to adjust the way you work, down to structuring your code and projects differently. In fact you may need to figure out different approaches based on the project, the language, the coding style, the model, the specific task at hand, even your personality. I am convinced this aspect is what's causing the bimodal nature of AI coding discussions: people who stuck at it and figured it out, or just got lucky with the right mix of model / project / task / methodology, are amazed at their newfound superpowers -- whereas people who didn't, are befuddled by the hype.
This may seem like a lot of work, but it makes sense if you stop thinking of this as just a tool and more like working with a new team-mate.
Reading articles like this feels like being in a different reality.
I don't work like this, I don't want to work like this and maybe most importantly I don't want to work with somebody who works like this.
Also I am scared that any library that I am using through the myriad of dependencies is written like this.
On the other hand... if I look at this as some alternate universe where I don't need to directly or indirectly touch any of this... I am happy that it works for these people? I guess? Just keep it away from me
I've been working on AI dev tools for a bit over a year and I don't love using AI this way either. I mostly use it for boilerplate, ideas, or to ask questions about error messages. But I've had a very open mind about it ever since I saw it oneshotting what I saw as typical Google Cloud Functions tasks (glue together some APIs, light http stuff) a year ago.
I think in the last month we've entered an inflection point with terminal "agents" and new generations of LLMs trained on their previously spotty ability to actually do the thing. It's not "there" yet and results depend on so many factors like the size of your codebase, how well-represented that kinda stuff is in its training data, etc but you really can feed these things junior-sized tickets and send them off expecting a PR to hit your tray pretty quickly.
Do I want the parts of my codebase with the tricky, important secret sauce to be written that way? Of course not, but I wouldn't give them to most other engineers either. A 5-20 person army of ~interns-newgrads is something I can leverage for a lot of the other work I do. And of course I still have to review the generated code, because it's ultimately my responsibility, but I prefer that over having to think about http response codes for my CRUD APIs. It gives me more time to focus on L7 load balancing and cluster discovery and orchestration engines.
> but you really can feed these things junior-sized tickets and send them off expecting a PR to hit your tray pretty quickly
This really hasn't been my experience
Maybe I just expect more out of juniors than most people, though
> Just keep it away from me
I'm reminded of teaching bootcamp software engineering, when every day #1 we go through simple git workflows and it seems very intimidating to students and they don't understand the value. Which fair enough because git has a steep learning curve and you need to use it practically to start picking it up.
I think this might be analogous to the shift going on with ai-generated and agent-generated coding, where you're introducing an unfamiliar tool with a steep learning curve, and many people haven't seen the why? for its value.
Anyways, I'm 150 commits into a vibe coding project that still standing strong, if you're curious as to how this can work, you can see all the prompts and the solutions in this handy markdown I've created: https://github.com/sutt/agro/blob/master/docs/dev-summary-v1...
To the article's point, I built my own version of your agro tool that I use to manage my own git worktrees. Even if I had known about your project, I still would have built my own, because if I build it (with LLM assistance, obvs) then I get to design it for myself.
Looking at other industries, music production is probably the one to look at. What was once the purview of record labels with recording studios that cost a million dollars to outfit, is now a used MacBook and, like, $1,000 of hardware/software. The music industry has changed, dramatically, as a result of the march of technology, and thus so will software. So writing software will go the way of the musician. What used to be a middle class job as a trumpet player in NYC before the advent of records, is now only a hobby except for the truely elite level practicioners.
But you also can't not swim with the tide. If you drove a horse-buggy 100 years ago, it was probably worth your while to keep your eye on whether motor-cars went anywhere.
I was super skeptical about a year ago. Copilot was making nice predictions, that was it. This agent stuff is truly impressive.
An I the only one who has to constantly tell Claude and Gemini to stop making edits to my codebase because they keep messing things up and breaking the build like ten times in a row, duplicating logic everywhere, etc? I keep hearing about how impressive agents are. I wish they could automate me out of my job faster
Are you paying for the higher end models? Do you have proper system prompts and guidance in place for proper prompt engineering? Have you started to practice any auxiliary forms of context engineering?
This isn't a magic code genie, it's a very complicated and very powerful new tool that you need to practice using over time in order to get good results from.
That's the beauty of the hype: Anyone who cannot replicate it, is “holding it wrong”.
Or maybe it works well in some cases and not others?
It ain’t a magic code genie. And developers don’t spend most of their day typing lines of code. Lots of it is designing, figuring out what to build, understanding the code, maintenance considerations, and adhering to the style of whatever file you’re in. All these agents needing local context and still spit junk.
guy 1: I put money in the slot machine everyone says wins all the time and I lose
you: HAVE YOU PUT MORE TOKENS IN???? ARE YOU PUTTING THEM IN THE EXPENSIVE MACHINES???
super compelling argument /s
if you want to provide working examples of "prompt engineering" or "context engineering" please do but "just keep paying until the behavior is impressive" isn't winning me as a customer
it's like putting out a demo program that absolutely sucks and promising that if I pay, it'll get good. why put out the shit demo and give me this impression, then, if it sucks?
The way I ended up paying for Claude max was that I started on the cheap plan, it went well, then it wanted more money, and I paid because things were going well.
Then it ran out of money again, and I gave it even more money.
I'm in the low 4 figures a year now, and it's worth it. For a day's pay each year, I've got a junior dev who is super fast, makes good suggestions, and makes working code.
> For a day's pay each year
For anyone trying to back of the napkin at $1000 as 4-figures per year, averaged as a day salary, the baseline salary where this makes sense is about ~$260,000/yr? Is that about right lordnacho?
Yeah I thought that was a reasonable number in the ballpark. I mean, it probably makes sense to pay a lot more for it. A grand is probably well within the range where you shouldn't care about it, even if you only get a basic salary and it's a terrible year with no bonus.
And that's not saying AI tools are the real deal, either. It can be a lot less than a fully self driving dev and still be worth a significant fraction of an entry level dev.
I assume it's after tax too..
Create and point them to an agent.md file http://agent.md/
I'm really baffled why the coding interfaces have not implemented a locking feature for some code. It seems like an obvious feature to be able to select a section of your code and tell the agent not to modify it. This could remove a whole class of problems where the agent tries to change tests to match the code or removes key functionality.
One could even imagine going a step further and having a confidence level associated with different parts of the code, that would help the LLM concentrate changes on the areas that you're less sure about.
Why are engineers so obstinate about this stuff? You really need a GUI built for you in order to do this? You can't take the time to just type up this instruction to the LLM? Do you realize that's possible? You can just write instructions "Don't modify XYZ.ts file under any circumstances". Not to mention all the tools have simple hotkeys to dismiss changes for an entire file with the press of a button if you really want to ignore changes to a file or whatever. In Cursor you can literally select a block of text and press a hotkey to "highlight" that code to the LLM in the chat, and you could absolutely tell it "READ BUT DON'T TOUCH THIS CODE" or something, directly tied to specific lines of code, literally the feature you are describing. BUT, you have to work with the LLM and tooling, it's not just going to be a button for you or something.
You can also literally do exactly what you said with "going a step further".
Open Claude Code, run `/init`. Download Superwhisper, open a new file at project root called BRAIN_DUMP.md, put your cursor in the file, activate Superwhisper, talk in stream of consciousness-style about all the parts of the code and your own confidence level, with any details you want to include. Go to your LLM chat, tell it to "Read file @BRAIN_DUMP.md" and organize all the contents into your own new file CODE_CONFIDENCE.md. Tell it to list the parts of the code base and give it's best assessment of the developer's confidence in that part of the code, given the details and tone in the brain dump for each part. Delete the brain dump file if you want. Now you literally have what you asked for, an "index" of sorts for your LLM that tells it the parts of the codebase and developer confidence/stability/etc. Now you can just refer to that file in your project prompting.
Please, everyone, for the love of god, just start prompting. Instead of posting on hacker news or reddit about your skepticism, literally talk to the LLM about it and ask it questions, it can help you work through almost any of this stuff people rant about.
_all_ models I’ve tried continuously, and still, have problems ignoring rules. I’m actually quite shocked someone would write this if you have experience in the area, as it so clearly contrasts with my own experience.
Despite explicit instructions in all sorts of rules and .md’s, the models still make changes where they should not. When caught they innocently say ”you’re right I shouldn’t have done that as it directly goes against your rule of <x>”.
Just to be clear, are you suggesting that currently, with your existing setup, the AI’s always follow your instructions in your rules and prompts? If so, I want your rules please. If not, I don’t understand why you would diss a solution which aims to hardcode away some of the llm prompt interpretation problems that exist
I am by no means an AI skeptic. It is possible to encode all sorts of things into instructions, but I don’t think the future of programming is every individual constructing and managing artisan prompts. There are surely some new paradigms to be discovered here. A code locking interface seems like an interesting one to explore. I’m sure there are others.
Or, you know, chmod -w XYZ.ts
They need "context engineering" which what I'll describe best as "railing" them in. If you give them a bit of a loose space, they'll massacre your code base. You can use their freedom for exploration but not for implementation.
In essence, you have to do the "engineering" part of the app and they can write the code pretty fast for you. They can help you in the engineering part, but you still need to be able to weigh in whatever crap they recommend and adjust accordingly.
This is way even as a paid user I stick to the browser tab llms. I am a context control freak and constantly just grabbing a new sessions and starting over. I don't try and fix a session and the incentives of a subscription vs api token payment model has inverse incentives.
It happens to me, yes. Sometimes they get stuck in the process. I learned how to go around certain issues but it's very annoying.
Duplicate logic is definitely a thing. That and littering comments all over the place.
Worth it to me as I can fix all the above after the fact.
Just annoying haha
Ask for no comments. Or extremely infrequent ones for complex sections only. Agreeing with https://news.ycombinator.com/item?id=44619462 here.
Did you tell them to not duplicate code?
More like people telling us there will be no more professional drivers on the road in 5-10 years 10 years ago. Agents are like lane assist, not even up to the current self driving levels.
Not sure the analogy is the same. A driverless car if it does something wrong can cause death - the cost of failure is very high. If my code doesn't come out right, as other posts here have said, I can just "re-roll the slot machine" until it does come out as acceptable - the cost is extremely low. Most of the "reasoning" models just increase the probability that the "re-run" will more likely be to preference of most people with RL to make it viable - tools like new agents know how to run tools, etc to give more data for the probability to be viable within a good timeframe and not run into an endless loop most of the time. Software until it is running after all is just text on a page.
Sure I have to be sure what I'm committing and running is good, especially in critical domains. The cheap cost of iteration before actual commit IMO is the one reason why LLM's are disruptive in software and other "generative" domains in the digital world. Conversely real-time requirements, software that needs to be relied on (e.g. a life support system?), things that post opinions in my name online etc will probably, even if written by a LLM, will need someone accountable and verifying the output.
Again as per many other posts "I want to be wrong" given I'm a senior in my career and would find it hard to change now given age. I don't like how our career is concentrating to the big AI labs/companies rather than our own intelligence/creativity. But rationally its hard to see how software continues to be the same career going forward and if I don't adapt I might die. I will most likely going forward, similar to what I do with my current team, just define and verify.
So many people are hyping AI like it's Musk's FSD, with the same fraudulance in overestimating its capabilities.
it's exactly like this. we're 3 years into being told all white collar jobs are going to be gone next year, just like we're ten years into being told we'll have self driving cars next year
15 years into bitcoin replacing the USD too
I'm not trying to discount it the analogy, but I'd much rather live without cars (or a lot less).
AI's superpower is doing mediocre work at high speed. That's okay. Great, even. There's lots of mediocre work to do. And mediocre still clears below average.
But! There's still room for expertise. And this is where I disagree about swimming with the tide. There will be those who are uninterested in using the AI. They will struggle. They will hone their craft. They will have muscle memory for the tasks everyone else forgot how to do. And they will be able to perform work that the AI users cannot.
The future needs both types.
My ongoing concern is that most of us probably got to being able to do good work via several years of doing mediocre work. We put in the hours and along the way learned what good looks like, and various patterns that allow us to see the path to solving a given problem.
What does the next generation do when we’ve automated away that work? How do they learn to recognise what good looks like, and when their LLM has got stuck on a dead end and is just spewing out nonsense?
they will be judging the merit of work in much broader context.
they don't!
I think the agent stuff is impressive because we are giving the AI scaffold and tools and things to do. And that is why it is impressive because it has some directive. But it is obvious if you don't give it good directives it doesn't know what to do. So for me, I think a lot of jobs will be making agents do things, but a lot won't. i think its really strange that people are all so against all this stuff. it's cool new computer tools, does nobody actually like computers anymore?
A lot of people join this profession because they like building stuff. They enjoy thinking about a problem and coming up with a solution and then implementing and testing it. Prompting is not the same thing and it doesn't scratch the same itch and at the end of the day it's important to enjoy your job, not only be efficient at it.
I have heard the take that "writing code is not what makes you an engineer, solving problems and providing value is what makes you an engineer" and while that's cool and all and super important for advancing in your career and delivering results, I very much also like writing code. So there's that.
Rick Beato posted a video recently where he created a fictitious artist and a couple of songs based on a few prompts. The results were somewhat passable, generic indie/pop music but as he said (I'm paraphrasing) "I didn't create anything here. I prompted a computer to put together a bunch of words and melodies that it knew from what other people had written."
There is code which is interesting to write, even if it isn't the area with clever algorithms or big architecture decisions or something.
But there is also the area of boilerplate, where non-LLM-AI-based IDEs for a few decades already help a lot with templates and "smart" completion. Current AI systems widen that area.
The trouble with AI is when you are reaching the boundary of its capabilities. The trivial stuff it does well. For the complex stuff it fails spectacularly. In the in between you got to review carefully, which easily becomes less fun than simply writing by oneself.
> But there is also the area of boilerplate, where non-LLM-AI-based IDEs for a few decades already help a lot with templates and "smart" completion.
The thing for me is that AI writing the boilerplate feels like the brute force solution, compared to investing in better language and tooling design that may obviate the need for such boilerplate in the first place.
Yeah, but building tooling is a hard sell considering the ability of contemporary AI.
The energy cost is absurdly high for the result, but in current economics, where it's paid by investors not users, it's hidden. Will be interesting to see when AI companies got to the level where they have to make profits and how much optimisation there is to come ...
That's an interesting take - that you like the act of writing code. I think a lot of builders across a variety of areas feel this way. I like writing code too.
I've been experimenting with a toolchain in which I speak to text to agents, navigate the files with vim and autocomplete, and have Grok think through some math for me. It's pretty fun. I wonder if that will change to tuning agents to write code that go through that process in a semi-supervised manner will be fun? I don't know, but I'm open to the idea that as we progress I will find toolchains that bring me into flow as I build.
Most people don't enjoy their jobs and go to work for one reason only - to support themselves and their families. The itch is to get paid. This is as true in software as it is in other fields.
That's not to say there aren't vocations, or people in software who feel the way you do, but it's a tiny minority.
Yeah but I write the code that is interesting to solve and let the LLM solve the problems that are not so important. Like making yet another webscraper tool is not the most exciting part of the process when you are trying to make some kind of real time inference tool for what people post on the internet.
Ah yes, that "is that 6 spaces or 8" in a yaml file itch that just has to be scratched. Programming has a lot of doldrums. LLMs still get stuck at places, and that's just where the new itch to scratch is. Yeah, it's not the same as code golfing an algorithm really neatly into a few lines of really expressive C++, but things change and life goes on. Programming isn't the same as when it was on punch cards either.
People are afraid that instead of skilled craft guild members they will become assembly line workers like Charlie Chaplin in Modern Times. And in 10 years unemployed like people in the Rust Belt.
This, and no one will understand the software that is created. Then you are beholden to AI companies who can charge you whatever they want to maintain the AI code. Will this be cheaper than paying software engineers? Maybe, but I could also see it costing much more.
There's a kind of karmic comedy in this. Programmers' jobs has always been to automate other people's jobs. The panic of programmers about their own jobs now is immensely funny to me.
As has been the case for all those jobs changed by programmers, the people who keep an open mind and are willing to learn new ways of working will be fine or even thrive. The people rusted to their seat, who are barely adding value as is, will be forced to choose between changing or struggling.
The problem is that these days we're talking about millions of people.
Those kinds of masses of people don't pivot on a dime.
I like computers quite a lot and the direction of the tech industry has been to destroy every single think I like or thought would be good about them.
> does nobody actually like computers anymore
I think this is a really interesting question and an insight into part of the divide.
Places like HN get a lot of attention from two distinct crowds: people who like computers and related tech and people who like to build. And the latter is split into "people who like to build software to help others get stuff done" and "people who like to build software for themselves" too. Even in the professional-developer-world that's a lot of the split between those with "cool" side projects and those with either only-day-job software or "boring" day-job-related side projects.
I used to be in the first group, liking computer tech for its own sake. The longer I work in the profession of "using computer tools to build things for people" the less I like the computer industry, because of how much the marketing/press/hype/fandom elements go overboard. Building-for-money often exposes, very directly, the difference between "cool tools" and "useful and reliable tools" - all the bugs I have to work around, all the popular much-hyped projects that run into the wall in various places when thrown into production, all the times simple and boring beats cool when it comes to winning customers. So I understand when it makes others jaded about the hype too. Especially if you don't have the intrinsic "cool software is what I want to tinker with" drive.
So the split in reactions to articles like this falls on those lines, I think.
If you like cool computer stuff, it's a cool article, with someone doing something neat.
If you are a dev enthusiast who likes side projects and such (regardless of if it's your day job too or not), it's a cool article, with someone doing something neat.
If you are in the "I want to build stuff that helps other people get shit done" crowd then it's probably still cool - who doesn't like POCs and greenfield work? - but it also seems scary for your day to day work, if it promises a flood of "adequate", not-well-tested software that you're going to be expected to use and work with and integrate for less-technical people who don't understand what goes into reliable software quality. And that's not most people's favorite part of the job.)
(Then there's a third crowd which is the "people who like making money" crowd, which loves LLMs because they look like "future lower costs of labor." But that's generally not what the split reaction to this particular sort of article is about, but is part of another common split between the "yay this will let me make more profit" and "oh no this will make people stop paying me" crowds in the biz-oriented articles.)
This doesn't make aaaaany sense: IF this actually worked, then why would all the biggest companies in the world be firing people? They would be forcing them all to DO THE TIDE and multiple their 10 billion dollar dominance to 100 billion dollar or more dominance.
The truth is something like: for this to work, there is huge requirements in tooling/infrastructure/security/simulation/refinement/optimization/cost-saving that just could never be figured out by the big companies. So they are just like... well lets trick as many investors and plebs to try to use this as possible, maybe one of them will come up with some breakthrough we can steal
> why would all the biggest companies in the world be firing people
Because of section 174, now hopefully repealed. Money makes the world go round, and the money people talk to the people with firing authority.
Sometimes it's a good thing to not swim with the tide. Enshittification comes from every single dipshit corporation racing to the bottom, and right now said tide is increasingly filling with sewage.
There's a huge disconnect I notice where experienced software engineers rage about how shitty things are nowadays while diving directly into using AI garbage, where they cannot explain what their code is doing if their lives depended on it.
It does sound horrible. No more getting in the flow, no more thinking about anything, no more understanding anything. Just touch it with a ten-foot pole every few hours, then get distracted again.
I guess if all you do is write React To-Do apps all day, it might even work for a bit.
Unfortunately, I think the evolution of LLMs is going to put more areas of programming within this "React Todo app" envelope of capability that you suggest, and to have it work for longer, rather than going away.
This has to be someone working solely on personal projects right? Because I don't know anyone who actually works like this and frequently the code that AI will spit out is actually quite bad.
Scary part is: what if it’s inevitable? We don’t get to choose our environment, and toss one is forming around us.
A friend’s dad only knows assembly. He’s the ceo of his company and they do hardware, and he’s close to retirement now, but he finds this newfangled C and C++ stuff a little too abstract. He sadly needs to trust “these people” but really he prefers being on the metal.
> and maybe most importantly I don't want to work with somebody who works like this.
Which, of course, is your perogative, but in what other ways do we, as fellow programmers, judge software libraries and dependencies so harshly? As a Vim user, do I care that Django was written with a lot of emacs? Or that Linus used emacs to write git? Or maybe being judgemental about programming languages; ugh, that's "just" a scripting language, it's not "real" programming unless you use a magnet up against a hard drive to program in ones and zeros. As a user, do I care that Calibre is written in Python, and not something "better"? Or that curl is written in good ole C. Or how about being opinionated as to whether or not the programmer used GDB or printf debugging to make the library?
The market for utility software like this predates the internet, we used to pass them around on floppies. It was never subject to particularly high QA or scrutiny. It just has to be "adequate."
But it's never displaced the market for highly-produced, highly-planned, "central" software pieces that the utilities glue together and help you work with, etc.
The growth of that software-as-big-business has only enlarged the need for utilities, really, to integrate everything, but it's a tough space to work in - "it's hard to compete with free." One classic move is selling support, etc.
Might be tough to do non-LLM-driven software development there - the selling support for your LLM-created-products model is still viable, but if there's an increase in velocity in useful utility creation or maintenance, possibly the dev headcount needs are lower.
But does anyone know how to use LLMs to make those giant ones yet? Or to make those central core underlying libraries you mention? Doesn't seem like it. Time will tell if there's a meaningful path that is truly different from "an even higher level programming language." Even on the edges - "we outgrew the library and we have to fork it because of [features/perf/bugs]" is a pretty common pattern when working on those larger projects already, and the more specific the exact changes you need are, the less the LLM might be able to do it for you (e.g. the "it kept assuming this function existed because it exists in a lot of similar things" problem).
What I hope is that we can find good ways to leverage these for quality control and testing and validation. (Though this is the opposite of the sort of greenfield dev demos that get the most press right now.)
Testing/validation is hard and expensive enough that basically nobody does a thorough job of it right now, especially in the consumer space. It would be wonderful if we could find ways to release higher quality software without teams of thousands doing manual validation.
I promise everyone one thing - there ain’t no such thing as a free lunch.
A lot of what is “working” in the article is closer to “jugaad”/prototyping.
Something the author acknowledges in their opening- it’s a way to prototype and get something off the ground.
Technically debt will matter for those products that get off the ground.
>I don't want to work with somebody who works like this.
You will most likely get your wish but not in the way you want. In a few years when this is fully matured there will be little reason to hire devs with their inflated salaries (especially in the US) when all you need is someone with some technical know-how and a keen eye on how to work with AI agents. There will be plenty of those people all over the globe who will demand much less than you will.
Hate to break it to you but this is the future of writing software and will be a reckoning for the entire software industry and the inflated salaries it contains. It won't happen overnight but it'll happen sooner than many devs are willing to admit.
> some technical know-how
how do they develop the technical know-how? how will you review the AI agents when you understand nothing?
How do you review the machine code generated by the compiler?
surely you can appreciate the difference between a compiler and a non-deterministic natural language interface?
yes yes the chainsaw made lumberjacks obsolete
Genuinely this is what it sounds like to accept obsolescence and I just can’t understand it.
What are you attached to and identify with that you’re rejecting new ways to work?
Change is the only constant and tools now look like superhuman tools created for babies compared to the sota at bell or NASA in the 1960s when they were literally trying to create superhuman computing.
We have more access to powerful compute and it’s never been easier to build your own everything.
What’s the big complaint?
I think it's a great technology but if people's ability to put food on the table is compromised what's their incentive not to ventilate people working for AI labs?
If people have shown anything recently it’s the unwillingness to actually do what you just said.
If anyone cared enough to do anything, they would be burning everything down already
It’s a lot of impotent rage because the only virtue people have is consumption, they don’t actually believe in anything. The ones who do believe in fairy tales are part of a dwindling population (religion) that is rightfully crashing.
Welcome to the wasteland of the real
I know, it's scary. But I guess it's the direction we are aiming for.
Just to clarify, I'm not a member of that "we".
And that's fine, it's your choice. But everything, driven by multiple forces (from hype, to marketing, to real progress, to early adopters) is pointing to that future.
Yes, another web3, crypto and nft "inevitable" futures. Just give Sama a couple more trillion and AGI is juuuust behind the corner.
It's a fact models aren't getting as cost efficient nor better with the same rate that the costs increases of training and running them. It's also a fact that they are so unprofitable that Anthropic feels like they gotta rug-pull your Claude tokens (https://news.ycombinator.com/item?id=44598254#44602695) without telling you, let's just ignore those facts and fanboy with wide-closed about that future.
A future framed as "inevitable" by a bunch of people whose job/wealth depends on framing it as such. Nah, hard pass.
> A future framed as "inevitable" by a bunch of people whose job/wealth depends on framing it as such. Nah, hard pass.
I agree with you! I'm not saying that I like it; this is the perfect example of turbo capitalism applied to innovation.
I also like to code and to build software, and the joy that comes from the act of creation. Only, I'm quite sure it's not going to last.
Imagine a future where creating software is about the designing the UX, overseeing the architecture and quality assurance. Implementation is farmed out.
But the architecture is the important (and hard) part!!! Not the UX!
Does it matter if the computer can do it? Can you calculate the cube root of 4?
Users see and care about the UX; the product. They only notice the engineering when it goes wrong.
A customer doesn't care about architecture. They want a good UX.
The customer wants a working product!
> in a different reality.
It is. And one reality is getting bigger each day and the other is shrinking.
>I don't work like this, I don't want to work like this and maybe most importantly I don't want to work with somebody who works like this.
It suggests you've had very positive life experiences, that you trust human developers so much more than computers.
I don’t think that was his argument. It would be one thing if we reach a point where humans trust a higher AI intelligence to create/keep software systems predictably meeting requirements. We aren’t there yet. So, it’s important to make sure any AI code is reviewed and approved by humans.
I have a local LLM router app with profiles that set up the right system prompts and the right MCPs so I can swap between toolsets as I work.
This would take time to write if I’m doing it myself so I decided to vibe code it entirely. I had this idea that a compiled language is less likely to have errors (on account of the compiler giving the LLM quicker feedback than me) and so I chose Tauri with TS (I think).
The experience has been both wonderful and strange. The app was built by Claude Code with me intermittently prompting it between actual work sessions.
What’s funny is the bugs. If you ever played Minecraft during the Alpha days you know that Notch would be like “Just fixed lighting” in one release. And you’d get that release and it’d be weird like rain would now fall through glass.
Essentially the bugs are strange. At least in the MC case you could hypothesize (transparency bit perhaps was used for multiple purposes) but this app is strange. If the LLM configuration modal is fixed, suddenly the MCP/tool tree view will stop expanding. What the heck, why are these two related? I don’t know. I could never know because I have never seen the code.
The compile time case did catch some iterations (I let Claude compile and run the program). But to be honest, the promise of correctness never landed.
Some people have been systematic and documented the prompts they use but I just free flowed it. The results are outstanding. There’s no way I could have had this built for the $50 in Claude credits. But also there’s no way I could interpret the code.
Yawn. I wish HN would just ban AI skip articles until someone writes about an actual product that provides actual value to paying customers.
In fact what I really want to see is a successful product that no one realizes was built by AI vibes until after it was successful. Customers don’t give a shit how something was built.
I don't think it's either "vibe coding or nothing" choice you have to make with AI. I am part of a team working on a complex Kotlin backend. I have been experimenting with Claude recently and I have been amazed how well it can pick up the existing patterns used in the project and create new code if given reasonable instructions. And it writes great tests too (something that would take me a lot of time and kill my motivation). It has been a great productivity boost for me. Of course we review the code in PRs, we test it but in the end it does the job in less time and saves me from doing tedious work.
Why not use the mcp inspector instead of protocollie?
Beautiful read. Thank you.
———
> Maybe all methodology is just mutually agreed-upon fiction that happens to produce results?
Good news! *All of computer science is this way.* There’s nothing universally fundamental about transistors, or Turing machines, or OOP, or the HTTP protocol. They’re all just abstractions that fit, because they worked.
———
When should I stop learning and start building? My coworker wrote absolutely ATROCIOUS code, alone, for the past decade. But he was BUILDING that whole time. He’s not up to date on modern web practices, but who cared? He built.
I only call provider APIs and try to include only devDependancies in my project.
Really helped my understanding of how apps work.
The "AI" promotion articles are beginning to read like Jack Kerouac.
See also https://github.com/davidkimai/Context-Engineering
>we dont have a word for it yet
I call it 'Orchestratic Development'.
Edit: Seriously, down voted twice when just commenting on an article? God I hate this arrogant shithole.
Check out image boards like 4chan or more localized boards like Kohlchan for Germany. No votes, no accounts
I just came here to remark how exceptional the prose in this article is.
I know it's an analogy that's probably been done to death already, but it truly feels like Bitcoin 2.0.
Back in the Bitcoin hype days, there were new posts here every single day about the latest and greatest Bitcoin thing. Everyone was using it. It was going to take over the world. Remember all the people on this very site that sincerely thought fiat currency was going away and we'd be doing all of our transactions with Bitcoin? How'd that work out?
It feels exactly the same. Now the big claims are that coding jobs are going away, or if you at least don't use it you'll be left behind. People are posting AI stories every day. Everyone is using it. People say it's going to transform the industry.
Back then there was greater motivation to evangelize Bitcoin, as you could get rich by convincing people to buy in, and it's just to a lesser degree now. People who work for AI companies (like the author), posting AI stuff, trying to drum up more people to give them views/clicks, buy their products.
And of course you'll have people replying to this trying to make the case for why AI coding is already a thing, when in reality those posts are once again going to be carbon copies of similar comments from the Bitcoin days "hey, you're wrong, I bought pizza with Bitcoin last night, it's already taking over, bud!"
My feelings exactly. For a while I thought I was missing out and then I started learning how(and why) it works and I thought it was interesting but greatly over-hyped, exactly like bitcoin was.
I tried to follow the hype and generate an application but it took a lot of time and it did generate something but not something that works with many subtle bugs. Now it may be that I needed to prompt it better, but that response also feels similar to how Scrum is always "done wrong" when it doesn't work. The result started getting better when I got more and more detailed with my prompts and then I realized that I am about to start writing code as a prompt and I may as well write the code myself.
So I still think it's an interesting tool, and it will automate away certain industries but no where near what the advertising is implying.
Dismissing any new technology because of Bitcoin makes exactly as much sense as dismissing any new medical advancements because of Theranos. Ok, some people said Bitcoin would change the world, and they were wrong. Some people also said the PC, Internet, and smartphones would change the world, and they were right.
And of course you'll have people replying to this trying to make the case for why AI coding is already a thing, when in reality those posts are once again going to be carbon copies of similar comments from the Bitcoin days
What is the actual argument here? Anyone claiming that AI has been useful for them is a lying shill?
The difference is that Bitcoin was an overhyped solution looking for a problem.
Whereas AI is as big as life, eukaryotes, multi-cellularity, human intelligence, agriculture and the industrial revolution. It will certainly change everything (and make humans go extinct unless we are very careful).
peeThe difference is Bitcoin is a networked system. Bitcoin is useless if I use it and you/my landlord/stores/the taxman doesn't. If my pizza store doesn't take Bitcoin, I can't use my Bitcoin. Meanwhile, LLM assisted programming has value to its adherents without needing you/my landlord/stores/the taxman to even have heard of it. My time machine is just as good as yours, so I have no idea if OpenAI, specifically is going to be around in 10 years, but I can tell you that I'll still have deepseek-r1.ggml
It’s amazing to me all the Luddite developers who are “against” all this.
Completely new ways of programming are forming, completely new ways of computing and the best the luddites can do is be “against it”.
A revolution came along, a change in history and instead of being excited by the possibilities, joining in, learning, discovering, creating …… the luddites are just “against it all”.
I feel sorry for them. Why be in computing at all if you don’t like new technology?
> Why be in computing at all if you don’t like new technology?
Because computers can be used to run programs.
You feel sorry for them. I feel sorry for the future.
There is a fundamentally unfortunate reality here which is quite problematic.
Namely, you don’t deserve to be paid for working 8 hours if you only worked for 30 minutes over an eight hour period.
I don’t care if you personally agree with that or not, the reality is that businesses believe it.
That means, sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.
It’s fun for home projects; but the somewhat depressing reality is that there is no chance in hell this (sitting around for 7 hours a day reading reddit while Claude codes) will fly in corporate environments; instead, you’re looking at mass layoffs.
So. Enjoy it while you can folks.
In the future you’ll be spending that 8 hours struggling to juggle the context and review 20 different tasks, not playing with your kids.
> That means, sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.
Correct - covered here in my talk - https://ghuntley.com/six-month-recap/
AI isn't going to take anyone's jobs. Your co-worker who knows how to use multiple agents at a time and automates their job function will.
If human productivity and unemployment increases at the same time the obvious solution for regulators will be to decrease the work week from 5 to 4 days or even further
You only work 5 days?
Man you struck a nerve with this one. All these devs want to believe they are still going to get paid $200k a year working 30mins a day. The reality is we will be spending the same 8 hours a day, be paid less, but now we need to work on 16 projects at the same time.
> sooner or later there will be a great rebalancing where people will be required to do significantly more work; probably the work of other developers who will be fired.
this already started in 2022-23 with all the layoffs and "downsizing"
Twas always such. Until we build a system where necessities are cheap (housing scarcity is a self-imposed own goal for one) we will be in constant competition with our peers so the value we produce can be extracted by casual owners.
I am hopeful that AI leads to a future with mandatory 10 hour work weeks.
Why would that happen when they can have mandatory 50 hour work weeks?
Mass unemployment with some people working 50+ hours a week will have to lead to something changing. Capped work hours? UBI?
People keep thinking the Jetsons is going to happen.
Soylent Green is a lot closer to the reality of capitalism.
You are living in a fantasy land if you think any technology (besides maybe a replicator) will lead to less work. If that were the case we'd all be on a 10 hour work week already.
Playing with your kids, aka increasing their IQ and investing in the future.
It doesn’t matter what downtime task it is.
You won’t have time to do it; it’s naive and ridiculous to expect that businesses will just let people goof off for 7 hours a day.
Regardless of the output they generate.
Anyone who doesn’t believe this has never had to manage budgets and staff.
It’s the “AI utopia” people making vague hand wavey motions about post-scarcity.
"deserve" has nothing to do with it.