Using it well requires a competent team, working together with trust and transparency, to build processes that are designed to effectively balance human guidance/expertise with what LLM's are good at. Small teams are doing very big things with it.
Most organizations, especially large organizations, are so far away from a healthy culture that AI is amplifying the impact of that toxicity.
Executives who interpret "Story Points" as "how much time is that going to take" are asking why everything isn't half a point now. They're so far removed from the process of building maintainable and effective software that they're simply looking for AI to serve as a simple pass through to the bottom line.
The recent study showing that 95% of AI pilots failed to deliver ROI is a case study in the ineffectiveness of modern management to actually do their jobs.
besides just weird or broken code, anything exposed to user input is usually severly lacking sanity checks etc.
llms are not useless for coding. but imho letting llms do the coding will not yield production grade code.
Move hand this way and a human will give a banana.
LLMs have no understanding at all of the underlying language, they've just seen that a billion times a task looks like such and such, so have these tokens after them.
It's a model. It either predicts usefully or not. How it works is mostly irrelevant.
all i know about these LLMs is that even if they understand language or can create it, they know nothing of the subjects they speak of.
copilot told me to cast an int to str to get rid of an error.
thanks copilot, it was on kernel code.
glad i didnt do it :/. just closed browser and opened man pages. i get nowhere with these things. it feels u need to understand so much its likely less typing to write the code. code is concise and clear after all, mostly unambiguous. language on the other hand...
i do like it as a bit of a glorified google, but looking at what code it outputs my confidence it its findings lessens every prompt
("But it works - when it works" is a tautology, not a useful model)
edit: Not a programmer. Just a guy who needs some stuff done for some of the things I need to work on.
https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vib...
Is there any example of successful companies created mostly/entirely by "vibe coding" that isn't itself a company in the AI hype? I haven't seen any, all examples so far are similar to yours.
I'm in a tiny team of 3 writing b2b software in the energy space and claude code is a godsend for the fiddly-but-brain-dead parts of the job (config stuff, managing cloud infra, one-and-done scripts, little single page dashboards, etc).
We've had much less success with the more complex things like maintaining various linear programming/neural net models we've written. It's really good at breaking stuff in subtle ways (like removing L2 regularisation from a VAE while visually it still looks like it's implemented). But personally I still think the juice is worth the squeeze, mainly I find it saves me mental energy I can use elsewhere.
We'll see how well they scale.
Instruments are not inculpable as you think they are.
A demise that in the case of a modern dysfunctional organisation would otherwise often be arriving a few years later as a results of complete and utter bureaucratic failure.
My experience is that all attempts to elevate technology to a "pivotal force" for the worse is always missing the underlying social and moral failure of the majority (or a small, but important, managerial minority) to act for the common good rather than egotistic self-interest.
aside, but I have yet to meet a single person (dev, qa, pm, exec) who doesn't do this.
It didn't help that the LLM was confidently incorrect.
The smallest things can throw off an LLM, such as a difference in naming between configuration and implementation.
In the human world, you can with legacy stuff get in a situation where "everyone knows" that the foo setting is actually the setting for Frob, but with an LLM it'll happily try to configure Frob or worse, try to implement Foo from scratch.
I'd always rather deal with bad human code than bad LLM code, because you can get into the mind of the person who wrote the bad human code. You can try to understand their misunderstanding. You can reason their faulty reasoning.
With bad LLM code, you're dealing with a soul-crushing machine that cannot (yet) and will not (yet) learn from its mistakes, because it does not believe it makes mistakes ( no matter how apologetic it gets ).
It got me thinking that in general, people with options will probably sort themselves out of those situations and into organizations with like-minded people who use AI as a tool to multiply their impact (and I flatter myself to think that it will be high ability people who have those options), leaving those more reliant on AI to operate at the limit of what they get from OpenAI et al.
Has anyone else ever dealt with a somewhat charismatic know-it-all who knows just enough to give authoritative answers? LLM output often reminds me of such people.
At first glance, it’s easy to compare them to a charismatic “know-it-all” who sounds confident while being only half-right. After all, both can produce fluent, authoritative-sounding answers that sometimes miss the mark. But here’s where the comparison falls short — and where LLMs really shine:
(...ok ok, I can't go on.)
What's next—the interrobang‽
[1] https://dictionary.cambridge.org/us/dictionary/english/bulls...
The bullshitter doesn't care whether what he says is correct or not, as long as it's convincing.
The use of 'pretty sure' disqualifies you. I appreciate your humility.
Bad human code to me is at least more understandable in what it was trying to do. There's a goal you can figure out and fix it. It generally operates within the context of larger code to some extant.
Bad LLM code can be broken from start to finish in ways that make zero sense. Even worse when it re-invents the wheel and replaces massive amounts of code. Human aren't likely just make up a function or methods that don't exist and deploy it. That's not the best example as you'd likely find that out fast, but it's the kind of screw up that indicates the entire chunk of LLM code you're examining may in fact be fundamentally flawed beyond normal experience. In some cases you almost need to re-learn the entire codebase to truly realize "oh this is THAT bad and none of this code is of any value".
I'm working with a fairly arcane technical spec that I don't really understand so well so I ask Claude to evaluate one of our internal proposals on this spec for conformance. It highlights a bunch of mistakes in our internal proposal.
I send those off to someone in our company that's supposed to be an authority on the arcane spec with the warning that it was LLM generated so it might be nonsense.
He feeds my message to his LLM and asks it to evaluate the criticisms. He then messages me back with the response from his LLM and asks me what I think.
We are functionally administrative assistants for our AIs.
If this is the future of software development, I don't like it.
Making the implicit explicit is a task for your documentation team, who should also be helping prep inputs for your LLMs. If foo and Frob are the same, have the common decency to tell the LLM...
The amount of absolutely shit LLM code I've reviewed at work is so sad, especially because I know the LLM could've written much better code if the prompter did a better job. The user needs to know when the solution is viable for an LLM to do or not, and a user will often need to make some manual changes anyway. When we pretend an LLM can do it all, it creates slop.
I just had a coworker a few weeks ago produce a simple function that wrapped a DB query in a function (normal so far), but wrote 250 lines of tests for it. All the code was clearly LLM generated (the comments explaining the most mundane of code was the biggest give away). The tests tested nothing. It mocked the ORM and then tested the return of the mock. We were testing that the mocking framework worked? I told him that I don't think the tests added much value since the function was so simple and that we could remove them. He said he thought they provided value, with no explanation, and merged the code.
Now fast forward to the other day and I run into the rest of the code again and now it's sinking in how bad the other LLM code was. Not that it's wrong, but it's poorly designed and full of bloat.
I have no issue with the LLM - they can do some incredible things and they're a powerful tool in the tool belt, but they are to be used in conjunction with a human that knows what they're doing (at least in the context of programming).
Kind of a rant, but I absolutely see a future where some code bases are well maintained and properly built, while others have tacked on years of vibe-coded trash that now only an LLM can even understand. And the thing that will decide which direction a code base goes in will be the engineers involved.
this offshoring all over again. At first, every dev in the US was going to be out of a job because of how expensive they were compared to offshore devs. Then the results started coming back and there was some very good work done offshore but there was tons and tons of stuff that had to be unwound and fixed with onshore teams. Entire companies/careers were made dedicated to just fixing stuff coming back from offshore dev teams. In the end, it took a mix of both to realize more value per dev $
Technical debt at a payday loan interest rate.
Windsurfing (the real activity) requires multiple understandings:
1) How to sail in the first place
2) How to balance on the windsurfer while the wind is blowing on you
If you can do both of those things, you can go VERY fast and it is VERY fun.
The analogy to the first thing is "understanding software engineering" (to some extent). The analogy to the second thing is "understanding good prompting while the heat of deadlines is on you". Without both, you are just creating slop (falling in the water repeatedly and NOT going faster than either surfing or sailing alone). Junior devs that are leaning too hard on LLM assistance right off the bat are basically falling in the water repeatedly (and worse, without realizing it).
I would at minimum have a policy of "if you do not completely understand the code written by an LLM, you will not commit it." (This would be right after "you will not commit code without it being tested and the tests all passing.")
Kinda funny example: The other day I asked Grok what a "grandparent" comment is on HN. It said it's the "initial comment" in a thread. Not coincidentally, that was the same answer I found in a reddit post that was the first result when I searched for the same thing on DuckDuckGo, but I was pretty sure that was wrong.
So I gave Grok an example: "If A is the initial comment, and B is a reply to A, and C a reply to B, and D a reply to C, and E a reply to D, which is the grandparent of C?" Then it got it right without any trouble. So then I asked: But you just said it's the initial comment, which is A. What's the deal? And then it went into the usual song and dance about how it misunderstood and was super-sorry, and then ran through the whole explanation again of how it's really C and I was very smart for catching that.
I'd rather it just said, "Oops, I got it wrong the first time because I crapped out the first thing that matched in my training data, and that happened to be bad data. That's just how I work; don't take anything for granted."
Maybe I'm just misreading your comment, but it has me confused enough to reset my password, login, and make this child comment.
Yes, but why would it? "Oops, I got it wrong the first time because I crapped out the first thing that matched in my training data" isn't in the training data. Yet.
So it can't come out of the LLM: There's no actual introspection going on, on any of these rounds. Just using training data.
I would ask them for an apple pie recipe and report to HR
There are a lot of people reading replies from more knowledgeable teammates, feeding those replies into LLMs, and pasting the response back to their teammates. It plays out in public on open source issue threads.
It's a big mess, and it's wasting so much of everyone's time.
i do this sometimes except i reply asking them to rephrase their comment in the form of a poem. Then screenshot the response and add it as an attachment before the actual human deletes the comment.
And it's unfortunate that many people would start associating long texts as generated by default. Related XKCD: https://xkcd.com/3126/
In my case, yes, but I think I use it differently from the way that most do.
First, for context, I'm a pretty senior developer, and I've been doing code since 1983, but I'm currently retired, and most of my work is alone (I've found that most young folks don't want to work with people my age, so I've calibrated my workflow to account for that).
I have tried a number of tools, and have settled on basically just using ChatGPT and Perplexity. I don't let them write code directly, but I often take the code they give me, and use it as a starting point for implementation. Sometimes, I use it wholesale, but usually, I do a lot of modification (often completely rewriting).
I have found that they can get into "death spirals," where their suggestions keep getting worse and worse. I've learned to just walk away, and try something else, when that happens. I shudder to think of junior engineers, implementing the code that comes from these.
The biggest value, to me, is that I can use them as an "instant turnaround" StackOverflow, without the demeaning sneers. I can ask the "stupidest" question; one that I could easily look up, myself, but it's faster to use ChatGPT, and I'll usually get a serviceable answer, almost instantly. That's extremely valuable, to me.
I recently spent a few weeks, learning about implementing PassKeys in iOS. I started off "cold," with very little knowledge of PKs, in general, and used what ChatGPT gave me (server and client) verbatim, then walked through the code, as I learned. That's usually how I learn new tech. It's messy, but I come out of it, with a really solid understanding. The code I have now, is almost unrecognizable, from what I started with.
- Fragile interaction. There's popups on VSCode everywhere, and they are clickable. Too often I try to hover on a particular place and end up clicking on one of those. The AI autocomplete also feels way too intrusive, press the wrong key combination and BAM I get a huge amount of code I didn't intend to get.
- Train of thought disruption. Since some times the AI long auto-complete is useful (~1/3th of times), I do end up reading it and getting distracted from my original "building up" thinking and now change to "explore thinking", which kind of dismantles the abstraction castle.
I haven't seen either of those issues on Zed. It really brought me back the joy of programming on my free time. I also think both of these issues are about the implementation more than the actual feature.
Get something stood up quickly to react to.
It's not complete, it's not correct, it's not maintainable. But it's literal minutes to go from a blank page to seeing something clickable-ish.
We do that for a few rounds, set a direction and then throw it in the trash and start building.
In that sense, AI can be incredibly powerful, useful and has saved tons of time developing the wrong thing.
I can't see the future, but it's definitely not generating useful applications out of whole cloth at this point in time.
They’re insanely useful. I don’t get why people pretend otherwise, just because they aren't fulfilling the prophesies of blowhards and salesmen
Unfortunately PMs tend to forget the throw-it-in-the-trash part, so the prototype still ends up in prod.
But good for you, if you found a way to make it work.
From there it's the important part: discussing, documenting, and making sure you're on the same page about what to actually build. Ideally, get input from your actual customers on the mockup (or multiple mockups) so you know what resonates and what doesn't.
I've been fighting this battle for years in my org and every time we start to make progress we go through yet another crisis and have to let some of our junior staff go. Then when we need to hire again it's an emergency and we can only hire more senior staff because we need to get things done and nobody is there to fill the gaps.
It's been a vicious cycle to break.
There's a glut of junior dev talent and not enough real problems out there which a junior can apply themselves to.
This means that most of them simply arent able to get the kind of experience which will push them into the next skill bracket.
It used to be that you could use them to build cheap proofs of concept or self contained scripting but those are things AI doesnt actually suck too badly at. Even back then there were too many juniors and not enough roles though.
Though cleaning up garbage fires isn't exactly fun. Gonna need to raise my rates.
Having AI write code for me (other than maybe simple boilerplate stuff) goes entirely against why I write code in the first place which is the joy of problem solving, building things, and learning.
Edit: Typo
But, much of what I spend my time on are already solved problems (building retro video game clones) so AI has a LOT of high-quality content to draw upon. I'm not trying to create new, original products.
It's been a couple weeks, but I am still irritated.
I am asking you, the person who supposedly wrote this, what it does. When you submit your code for review, that's among the most basic questions you should be prepared to answer.
When he gets back and don't understand the feedback, then you can conveniently ask him to ask an LLM and not waste your time.
Development is moving towards quality assurance. Because that's what matter eventually. You have a product that works reliably and fast, and you can quickly get it to the market. You don't really care how the code is written.
Of course some people will continue to write "better software" than AI, more readable, or more elegant, bringing some diminishing marginal value to the table, the market doesn't really care about.
I don't think AI is there yet, but realistically speaking, it's gonna get there in 5 to 10 years. Some of us will adjust, some not. Reaction is real.
I wonder if at some point we will have an LLM that basically understands English and say, Java bytecode or V8 bytecode. So in goes English descriptions and comments and out goes program bytecode implementing the required functionality.
Also for LRMs.. why use English for the reasoning part? Could there be a more succinct representation? Like Prolog?
Prior to computers, processes were completed by human to human communication. Hard to scale, impossible to automate. So then we had applications, which force fairly strict processes into a funnel.
But they're extremely restrictive and hard to make.
If you already have God AI, you just don't need an application. I don't go to an airlines website and book a flight. No, I ask my assistant to book me a flight, and then I have a flight.
The assistant might talk to the airline, or maybe hundreds of other AI. But it gets it done instantly, and I don't have to interface with a webpage. The AI have a standard language amongst themselves. It might be English, it might not be.
Is creating a giant wobbly world of unreliable AIs all talking to each other in effort to get their own tasks accomplished, is that leaving us much better off than humans doing everything themselves?
Better yet, if you have an application that does exactly what you want, why would you (or an AI representing you) want to do anything other than use that application? Sure you could execute this binary and get what you want, OR you could reach to the AI-net and make some other AI do it from scratch every time. With inherently less reliable results.
The world right now is pretty strict just because of how software has to be, which has a lot of upsides and downsides. But there's some wobblyness because of bugs, which break contracts.
But I think then in the future you have AI which doesn't make mistakes and you also have contracts.
Like the airline agent booking your flight (human or AI) has a contract - they can only do certain things. They can't sell you a ticket for one dollar. Before applications we just wrote these contracts as processes, human processes. Human often break processes. Perfect AI won't.
And to us, humans, this might even be completely transparent.
Like in the future I go to a website because I want to see fancy flight plans or whatever and choose something.
Okay, my AI goes to the airline and gets the data, then it arranges it into a UI on the fly. Maybe I can give it rules for how I typically like those UI presented.
So there's no application. It works like an executive assistant at a job. Like if I want market research, I don't use an application for that. I ask my executive assistant. And then, one week later, I have a presentation and report with that research.
That takes a week though, perfect AI can do it instantly.
And for companies, they don't make software or applications anymore. They make business processes, and they might have a formal way for specifying them. Which is similar to programming in a way. But it's much higher level. I identify the business flow and what my people (or AI) are allowed to do, and when, and why.
It’s not just engineering folks that are being asked to do more vibe-coding with AI. Designers, product folks, project managers, marketers, content writers are all being asked to vibe code prototypes, marketing websites, internal tools, repros, etc. I’m seeing it first hand at the company I work at and many others. Normal expectations of job responsibilities have been thrown out of the window.
Teams are stretched thin as a result, because every company is thinking that if you’re not sprinting towards AI you’ll be left behind. And the truth is that these folks actually deliver impact through their AI usage.
It's trashing whole departments. The come-down from this high (which high is being experienced pretty much only by the C-suite and investors) is gonna be rough.
I don't know from where you are but I am from India, exactly same as your age and exactly dealing with problem! Its really, annoying!
- DevOps role
- Technical test involves logging into a server (via sadservers.com who are awesome)
- We tell the candidates: "The goal is to see if you can work through a problem on a Linux based system. It's expected you'll see some things you may never have seen before. Using Google and ChatGPT etc is fine if you get stuck. We just ask that you share your screen so we can see your search and thought processes."
- Candidate proceeds to just use ChatGPT for EVERY SINGLE STEP. "How do I list running processes?", "How do I see hidden files?", copy and pasted every error message into ChatGPT etc
Now, I had several thought about this:
1. Is this common?
2. As one coworker joked "I knew the robots were coming, just not today"
3. We got essentially zero signal on his Linux related debugging skills
4. What signal was he trying to send by doing this? e.g. I would assume he would realize "oh, they are hiring for people who are well versed in Linux and troubleshooting"
5. I know some people might say "well, he probably eventually got to the answer" but the point is that ChatGPT doesn't always have the answer.
People that spend their lives trying to get the LLMs to actually write the code will find it initially exhilarating, but in the long run they will hate it, learn nothing, and end up doing something stupid like outputting thousands of different output targets when you only need about 30.
If you use them wisely though they really can act as multipliers. People persist in the madness because of the management dream of making all the humans replaceable.
[1] All that had happened was the devs had learned how to recognize very simple patterns in the esoteric error messages and how to correct them. It was nearly trivial to write a program that outperformed them at this.
Can any program be broken down into functions and functions of functions that have inputs and outputs so that they can be verified if they are working?
The hard bit is knowing which functions to write, and what "valid" means for inputs and outputs. Sometimes you'll get a specification that tells you this, but the moment you try to implement it you'll find out that whoever was writing that spec didn't really think it through to its conclusion. There will be a host of edge cases that probably don't matter, and will probably never be hit in the real world anyway, but someone needs to make that call and decide what to do when (not if) they get hit anyway.
Even if you can formally verify individual methods, what you're actually looking for is if we can verify systems. Because systems, even ones made of of pieces that are individually understood, have interactions and emergent behaviors which are not expected.
...then a bit flips because of a stray high energy particle or someone trips over the metaphorical power cord and it all crashes anyway.
Outside of functional code, there's a lot out there which requires mutable state. This is much harder to test which is why user interface testing on native apps is always more painful and most people still run manual QA or use an entirely different testing approach.
Long story: yes, but it'd take centuries to verify all possible inputs, at least for any non-trivial programs.
Can a function be "verified", this can mean "tested", "reviewed", "proved to be correct". What does correct even mean?
Functions in code are often more complex than just having input and output, unlike mathematical functions. Very often, they have side effects, like sending packets on network or modifying things in their environment. This makes it difficult to understand what they do in isolation.
Any non-trivial piece of software is almost impossible to fully understand or test. These things work empirically and require constant maintenance and tweaking.
If a program is built with strong software architecture, then a lot of it will fit that definition. As an analogy, electricity in your home is delivered by electrical outlets that are standardized -- you can have high confidence that when you buy a new electrical appliance, it can plug into those outlets and work. But someone had to design that standard and apply it universally to the outlets and the appliances. Software architecture within a program is about creating those standards on how things work and applying them universally. If you do this well, then yes, you can have a lot of code that is testable and verifiable.
But you'll always have side-effects. Programs do things -- they create files, they open network connections, they communicate with other programs, they display things on the screen. Some of those side-effects create "state" -- once a file is created, it's still present. These things are much harder to test because they're not just a function with an input and an output -- their behavior changes between the first run and the second run.
Even when it’s been vetted by another engineer via actual tests, there is something that in my flesh not me want to read that output?
Sooner or later, this will be akin to asking people to stop be able to do their job, the same way how I might not recall how to work with a Java enterprise codebase purely through the CLI, because all of the run profiles in JetBrains IDEs have rotten my own brain, except apply it to developing any software at all.
Maybe not the best analogy because running things isn't too hard when you can reference a Dockerfile, but definitely stuff around running tests and passing the plethora of parameters that are needed to just stand the damned thing up correctly with the right profiles and so on.
That's also like asking people to stop using Google for a while, upon which I bet most of us are reliant to a pretty large degree. Or StackOverflow, for finding things that people wouldn't be able to discover themselves (whether due to a lack of skills, or enough time).
I think the reliance on AI tools will only go upwards.
Here's my own little rant about it from a bit back: https://blog.kronis.dev/blog/ai-artisans-and-brainrot
The only thing LLMs are doing here is surfacing the fact that your company hired really bad talent.
And no, basing your team in Arkansas or Tbilisi or whatever, not doing Leetcode interviews, and pinky-promising you're the Good Guys™ (unlike evil Meta and Google *hmmphh*) doesn't exempt you from the competitive forces of the labor market that drive SWE salaries well into the mid six figures, because tbh most people don't really mind grinding Leetcode, and most people don't really mind moving to the Bay Area, and most people don't really mind driving in to work 5 days a week, and they definitely don't give a shit whether their company's mission is to harvest every newborn's DNA to serve them retina-projected cigarette ads from the age of 10, or if it's singing privacy-respecting kumbaya around the FOSS bonfire.
You only get what you pay for, not a lick more.
LLMs are going to put these shitty companies in a really bad state while the spade-sellers laugh their way to the bank. I predict within 24 months you're going to see at least one company say they're enforcing a total ban on LLM-generated code within their codebase.
That said, I wonder how many dormant bugs get introduced at this moment by the less talented. Just a matter of time…
The positions of both evangelists and luddites seems mad to me, there's too much emotion involved in those positions for what amounts to another tool in the toolbox that should only be used in appropriate situations.
But our discipline has been through similar disruptions in the past. I think give it a few years then maybe we’ll settle on something sane again.
I do think the shift is permanent though. Either you adapt to use these LLMs well or you will struggle to be competitive (in general)
That certainly isn't true if what this article suggests is true.
In my mind, anyone willing to opt out of providing value is welcome to do so.
Let's say that happens, how would it actually help? What's the mechanism?
But we're in the mega hype phase still (1998/1999) and haven't quite crested over to the reality phase.
Let's just all call it LLM models, which they are. It's just a tool, that increase your productivity when used right.
But it's a natural part of the cycle i think. Assembly language, compilers, scripting languages, application development frameworks... All lead to a new generation of programmers that "dont' understand anything!" and "it's just useful for the lazy!"..
I call BS. This is 100% a culture and management problem. I'd even go so far as to say, it is our responsibility as seniors to coach this new generation into producing quality and value with the tools they have. Don't get me wrong, I love shouting at clouds; i even mumble angrily at people in the streets sometimes and managers are mostly idiots; but we are the only ones that can guide them to the light so to speak.
Don't blame the tool, fix the people.
I don't want to move again and it's a terrible time to try, partly because of this nonsense. So where we are.
Over the decades I have seen many of these things, this iteration seems to me a push on steroids. I stopped paying attention around the mid 90s and did things "my way". The sad thing is, seems these days a developer cannot hide in the shadows.
> Championing their “success”, a senior manager goaded them into bragging about their use of “AI” tools to which they responded “This is four thousand lines of code written by Claude”. Applause all around.
this is no different to applauding yourself for outsourcing your own role to a low cost location
wonder if they'll still be clapping come layoffs
If you want to be well-paid, you need to be able to distinguish yourself in some economically-useful manner from other people. That was true before AI and AI isn't going to make it go away. It may even in some sense sharpen it.
In another few years there's going to be large numbers of people who can be plopped down in front of a code base and just start firing prompts at an AI. If you're just another one of the crowd, you're going to get mediocre career results, potentially including not having a career at all.
However, here in 2025 I'm not sure what that "standing out in the crowd" will be. It could well be "exceptional skill in prompting". It could be that deeper understanding of what the code is really doing. It could be the ability to debug deeply yourself with an old-school debugger when something goes wrong and the AI just can't work. It could be non-coding skills entirely. In reality it'll be more than just one thing anyhow and the results will vary. I don't know what to tell you juniors except to keep your eyes peeled for whatever this will be, and when you think you have an idea, don't let the cognitively-lazy appeal of just letting the AI do everything stop you from pursuing it. I don't know specifically what this will be, but you don't have to be right the first time, you have time to get several licks at this.
But I do know that we aren't going to need very many people who are only capable of firing prompts at an AI and blindly saying "yes" to whatever it says, not because of the level of utility that may or may not have, but because that's not going to distinguish you at all.
If all you are is a proxy to AI, I don't need you. I've got an AI of my own, and I've got lower latency and higher bandwidth to it.
Correspondingly, if you detect that you are falling into the pattern of being on the junior programmer end of what this article is complaining about, where you interact with your coworkers as nothing but an AI proxy, you need to course correct and you need to course correct now. Unfortunately, again, I don't have a recipe for that correction. Ask me in 2030.
"Just a proxy to an AI" may lead to great things for the AI but it isn't going to lead you anywhere good!
People probably said the same things when the first steam shovels came around. I for one like things that make me have to shovel less shit. But you'd also have the same problems if you put every person in the company behind the controls of a steam shovel.
So I'm reading the article which initially appears to be a story about an engineering organization and I'm wondering where they came up with someone silly enough to trust an LLM with people's lives.
Then it dawned on me that it wasn't an engineering organization at all, just a bunch of programmers with title inflation. It follows as a consequence that since they and their management don't respect the title and skillset of an Engineer, they likely wouldn't respect or appreciate their programming staff either.
The meta of this is that an audience comfortable with giving the title Engineer to programmers shouldn't really be surprised by this outcome.
>We can say our prayers that Moore’s Law will come back from the dead and save us.
I'm working on that very problem. I expect results with 2 years.
So what good are these tools? Do they have any value whatsoever?
Objectively, it would seem the answer is no.
I could have written it myself in a few hours, with the Python standard docs open on one monitor and coding and debugging on the other etc, but my project was "organize my photos" not "write a photo organizing app". However, often I do side projects to improve my skills, and using an AI is antithetical to that goal.
I reached for claude code to just vibe a basic android ux to drive some rest apis for an art project as the existing web UI would be a PITA to use under the conditions I had. Worked well enough and I could spend my time finishing other parts of the project. It would not have been worth the time to write the app myself and I would have just suffered with the mobile web UI instead. Would I have distributed that Android app? God no, but it did certainly solve the problem I had in that moment.
Outside of work though it's been great to have LLMs to dive into stuff I don't work with, which would take me months of learning to start from scratch. Mostly programming microcontrollers for toy projects, or helping some artists I know to bring their vision to life.
It's absurdly fun to get kickstarted into a new domain without having to learn the nitty-gritty first but I eventually need to learn it, it just lowers the timeframe to when the project becomes fun to work with (aka: it barely works but does something that can be expanded upon).
Just another old-man-shouting-at-cloud blog post. you company culture sucks and the juniors need to be managed better. Don't blame the tools.
It seems to me that the limitations of this particular tool make it suitable only in cases where it doesn't matter if the result is wrong and dangerous as long as it's convincing. This seems to be exclusively various forms of forgery and fraud, e.g. spam, phishing, cheating on homework, falsifying research data, lying about current events, etc.
I think that as software/data people, we tend to underestimate the number of business processes that are repetitive but require natural language parsing to be done. Examples would include supply chain (basically run on excels and email). Traditionally, these were basically impossible to automate because reading free text emails and updating some system based on that was incredibly hard. LLMs make this much, much easier. This is a big opportunity for lots of companies in normal industries (there's lots of it in tech too).
More generally, LLMs are pretty good at document summarisation and question answering, so with some guardrails (proper context, maybe multiple LLM calls involved) this can save people a bunch of time.
Finally, they can be helpful for broad search queries, but this is much much trickier as you'd need to build decent context offline and use that, which (to put it mildly) is a non-trivial problem.
In the tech world, they are really helpful in writing one to throw away. If you have a few ideas, you can now spec them out and get sortof working code from an LLM which lowers the bar to getting feedback and seeing if the idea works. You really do have to throw it away though, which is now much, much cheaper with LLM technology.
I do think that if we could figure out context management better (which is basically decent internal search for a company) then there's a bunch of useful stuff that could be built, but context management is a really, really hard problem so that's not gonna happen any time soon.
How do you fix that, when the process is literally "we throw an illegible blob at it and data comes out"? This is not even GIGO, this is "anything in, synthetic garbage out"
You gotta watch for that for sure but no that's not a issue we worry about anymore, at least not for how we're using it for here. The text that's being extracted from is not a "BLOB". It's plain text at that point and of a certain, expected kind so that makes it easier. In general, the more isolated and specific the use case, the bigger the chances of the whole thing working end to end. Open ended chat is just a disaster. Operating on a narrow set of expectations. Much more successful.
I mean, this is much less common than people make it out to be. Assuming that the context is there it's doable to run a bunch of calls and take the majority vote. It's not trivial but this is definitely doable.
I’m a mostly self taught hobbyist programmer, so take this with a grain of salt, but It’s also been great for giving me a small snippet of code to use as a starting point for my projects. I wouldn’t just check whatever it generates directly into version control without testing it and figuring out how it works first. It’s not a replacement for my coding skills, but an augmentation of them.
What about 20 minuets ago when I threw a 20-line Typescript error in and it explained it in English to me? What definition of "objective" would that fall under?
Or get this, I'm building off of an existing state machine library and asked it to find any potential performance issues and guess what? It actually did. What universe do you live in where that doesn't have objective value?
Am I going to need to just start sharing my Claude chat history to prove to people who live under a rock that a super-advanced pattern matcher that can compose results can be useful???
Go ahead, ask it to write some regex and then tell me how "objectively" useless it is?
I think we'll all need at least 3 of your anecdotes before we change our minds and can blissfully ignore the slow-motion train wreck that we all see heading our way. Sometime later in your life when you're in the hospital hooked up to a machine the firmware of which was vibe-coded and the FDA oversight was ChatGPT-checked, you may have misgivings but try not to be alarmed, that's just the naysayers getting to you.
This sentence is proof you guys are some of the most absurd people on this planet.
I am OK with the author using AI heavily. But if I continue to see slop, I will continue to review less and send it back.
In the end, if the engineer is fiddling around for too long, they don't get any work in, which is a performance issue.
I am always available to help out the colleague to write understand the system and write code.
For me, the key is to not accept to review AI slop just like I do not accept reviewing other types of slop.
If something is recognized as slop, it is not ready to be reviews.
This puts an upwards pressure on developers to deliver better code.
I don't think my LLM-assisted programming is much faster than my unassisted programming but I think I write higher quality code.
What I find is that my assistant sometimes sees a simple solution that I miss. Going back and forth with an assistant I am likely to think things through in more detail than I would otherwise. I like to load projects I depend on into IntelliJ IDEA and use Junie to have a conversation with the code that helps me get a more thorough and complete understanding of it than I would get looking at it myself more quickly.
As a pro maintenance programmer there is always a certain amount of "let sleeping dogs lie", if something works but you don't understand it you may decide to leave it alone. With an assistant I feel empowered to put more effort into really understanding things that I can get away without understanding, fix minor problems I wouldn't have fixed otherwise, etc.
One bit of advice is that as the context grows assistants seem to break bad. Often I ask Junie to write something, then give it some feedback about things it got wrong, and early in the session I'm blown away. You might think you should keep the session going so it will remember the history but actually it doesn't have the ability to realize some of the history is stale because it is about the way the code was before [1] and the result is eventually it starts going in loops. It makes sense then to start a new session and possibly feed it some documentation about the last session that tells it what it needs to know going forward.
[1] a huge problem with "the old AI", ordinary propositional logic sees the world from a "god's eye" point of view where everything happens at once, in our temporal world we need temporal if not bitemporal logic -- which is a whole can of worms. On top of that there is modal logic ("it is possible that X is true", "it is necessary that X is true") and modeling other people's belief "John thinks that Mary thinks that X is true") It's possible to create a logic which can solve specific problems but a general-purpose commonsense logic is still beyond state of the art.
I did that, now I have at least 2-3 days a week where I dont use any AI, and its much better
there is something very strange when using AI a lot, and it is affecting me a lot and I cant quite put my finger on it
I wrote https://punkx.org/jackdoe/misery.html some time ago to try to explain it, but honestly recently I relized that I really hate reading tokens.
These juniors you're complaining about are going to get better in making these requests of AI and blow right past all the seniors who yell at clouds running AI.
I've been coding for 25 years and what I feel reading posts & comments like in this thread is what I felt in the first few days of that black-blue/white-gold dress thing. I legitimately felt like half the people were trolling.
It's the same with LLM assisted coding. I can't possibly be getting such good results when all the rest are getting garbage, right? Impostor syndrome? Are they trolling?
But yeah, I agree fully with you. You need to actively try everything yourself, and this is what I recommend to my colleagues and friends. Try it out. See what works and what doesn't. Focus on what works, and put it in markdown files. Avoid what doesn't work today, but be ready because tomorrow it might work. Use flows. Use plan / act accordingly. Use the correct tools (context7 is a big one). Use search before planning. Search, write it to md files, add it in the repo. READ the plans carefully. Edit before you start a task. Edit, edit edit. Use git trees, use tools that you'd be using anyway in your pipelines. Pay attention to the output. Don't argue, go back to step1, plan better. See what works for context, what doesn't work. Add things, remove things. Have examples ready. Use examples properly. There's sooo much to learn here.
I don’t use Claude code for everything. I’ve fallen off the bike enough times to know when I’ll be better off writing the changes myself. Even in these cases, though, I still plan with Claude, rubber duck, have it review, have it brainstorm ideas (“I need to do x, I’m thinking about doing it such and such way, can you brainstorm a few more options?”)
I agree with your comment up to a point, but this is pretty similar to pilots and autopilots. At the end of the day you still need a pilot to figure out non standard issues and make judgement calls.
The junior blowing past is as good as how long he will take to fix this issue that all the credits/prompts in the world are not solving. If the impact is long and costs enough your vibe coders will have good instantaneous speed but never reach the end.
I am optimist about AI usage as a tool to enhance productivity, but the workflows are still being worked out. It currently is neither fire all devs, nor No LLM allowed. It is definitely an exciting time to be a senior though :)
It sounds like the author's company doesn't have this setup well.
If you use AI wrong you get AI slop :)
Congratulations everyone, you finally got what you deserve instead of what you need.
This is not what companies want. Companies want "value" that customers will pay for as quickly and cheaply as possible. As entities they don't care about craftsmanship or anything like that. Just deliver the value quickly and cheaply. Its this fundamental mismatch between what engineers want to do (build elegant, well functioning tools) and what businesses want to do (the bare minimum to get someone to give them as much money as possible) that is driving this sort of pulling-our-hair-out sentiment on the engineering side.
Maybe spaghetti code delivers value as quickly as possible in the short term, but there is a risk that it will catch up in the long term - hard to add features, slow iterations - ultimately losing customers, revenue and growth.
If i manage to vibecode something alone that takes off, even without technical expertise, then you validated the AI usecase...
Before Claude i had to make a paper prototype or a figma, now i can make Slop that looks and somehow functions the way i want. i can make preliminary tests, and even get to some proof of concept. in some cases even 1million $ annual revenue...
you're making an assumption these devs you hire actually know what they're doing and not just a proxy back to an LLM.
VB? VBA macros in Excel? Delphi? Uhh... Wordpress? Python as a language?
Well you see these are just for prototypes. These are just for making an MVP. They're not the real product.
But they are the real product. I've almost never seen these been successfully used as just for prototyping or MVPs. It always becomes the real codebase and it's a hot fucking mess 99% of the time.
What ends up happening is that humans get "woven" into the architecture/processes, so that people with pagers keep that mess going even though it really should not be running at that scale.
"Throw one away" rarely happens.
You don't have to feature pack if you are making a custom app for your custom use case, and LLMs are great with slim narrow purpose apps.
I don't think LLMs will replace developers, but I am almost certain they will radically change how end users use computers, even if the tech plateaus right now.
Everyone can do their own plumbing and electrical work in their homes too. For some people it works out, for others it's still better to pay someone else to do it for them.
I'm pretty comfortable letting my mom vibecode a plant watering tracker. Not so much wiring up a distribution box.
This assumes a pool of available devs who haven't already drunk the Koolaid.
To put it another way: the 2nd wave of devs will also vibe code. Or 'focus on the happy path'. Or the 'MVP', whatever it's called these days.
From their point of view, it will be faster and cheaper to get v2 out sooner, and 'polish' it later.
Does anyone in charge actually know what 'building it right' actually means? Is it in their vocabulary to say those words?
They don't care about losing customers 10 years later because they're optimizing for next quarter. But they do that every quarter.
Does this eventually blow up? Uh, yeah, big time. Look at GE, Intel, Xerox, IBM, you name it.
But you can get shockingly far only thinking about tomorrow over and over again. Sometimes, like, 100 years far. Well by then we're all dead anyway so who cares.
I don't think the chasm is unbridgable, because ultimately everybody wants the same thing (for the company to prosper) but they fail to entirely appreciate the perspective of the other. Its up to a healthy company organisation to productively address the conflict between the two perspectives. However, I have yet to encounter such a culture of mutal respect and resource allocation.
I fear that agentic AI could erase all the progress we've made on culture in the past 25 years (e.g. agile) and drag us back towards 80s tech culture.
MVPs exist to force business into better defining their requirements. Prior to Agile we'd spend years building something and then we'd deliver it, only for business to then "change their mind", because they've now just realised (now that they have it), that what they asked for was stupid.
AI isn't good enough yet to generate the same quality of software as human engineers. But since AI is cheaper we'll gladly lower the quality bar so long as the user is still willing to put up with it. Soon all our digital products will be cheap AI slop that's barely fit for purpose, it's a future I dread.
The software I have vibecoded for myself totally obliterates anything available on the market. Imagine a program that operates without any lag or hicupps. Opens and runs instantly. A program that can run without an internet connection, without making an account, without somehow being 12GB in size, without totally unintuitive UI, without having to pay $20/mo for static capabilities, without persistent bugs that are ignored for years, without any ability to customize anything.
I know you are incredulous reading this is, but hear me out
Bespoke narrow scope custom software is incredibly powerful, and well within the wheelhouse of LLMs. Modern software is written to be the 110-tool swiss army knife feature pack to capture as large of an audience as possible. But if I am just using 3 of those tools, an LLM can write a piece of software that is better for me in every single way. And that's exactly what my experience has been so far, and exactly the direction I see software moving in the future.
The problem space of average people problems that can be addressed with <5K LOC is massive. The only real barrier is having to go through an IDE, but that will almost certainly be solved in the near future, it already sort of is with Canvas features.
Any startup that can come to the table saying “All human engineers; SOC 2 Type 2 certified; dedicated Q/A department” will inherit the earth.
It’s not what I want… but at the same time, how many of our jobs do what we want? I could easily end up being the garbage man. I’m doing what I’m paid to do and I’m paid well to do it.
I usually avoid this, but what a snowflake.
So many people get their knickers in a twist over nothing.
Here’s a simple flowchart:
Junior gives you ai slop and ignores your remarks? a) ignore them b) send their manager a message
If neither works -> leave.
Also, get a life.
The TRUE takeaway here is that as of about 12 months ago, spending time investing in becoming a god-mode dev is not the optimal path for the next phase of whatever we're moving into.
And LLM assisted coding apparently makes this knowledge even less useful.
I explained it a few times. He just couldn't wrap his head around that there were files on his computer and also on a different computer over the internet.
Now, I will admit distributed VCS can be tricky if you've never seen it before. But I'm not kidding - he legitimately did not understand the division of local vs the internet. That was just a concept that he never considered before.
He also didn't know anything about filesystems but that's a different story.
My kid struggles with this. She can't intuitively grasp why one app needs the Internet and another app does not. I try to explain it but it all goes over her head. The idea that you need the Internet when your app needs to communicate with something outside of the phone is just foreign to her: In her mind, "the app" just exists, and there's no distinction between stuff on the phone and stuff on the network.
If anything, I always consider it a good question to assert whether someone knows when to stop talking.
This phase has been going on for decades now. It's a shame, really.
Is the answer you're looking for along the lines of "the browser makes a GET request to the specified URL," or something lower-level than that?
Bitcoin didn't replace cash, Blockchain didn't replace databases and NoSQL didn't make SQL obsolete. And while I have been wrong before, I'm optimistic that AI will only replace programmers the same way copy-pasting from StackOverflow replaced programmers back in the day.
larger != more complex
The widespread adoption of cheap agentic AI will absolutely be an economic revolution. Millions of customer support jobs will be completely eliminated in the next few years, and that's just the beginning.
Soon it'll be easy to give an AI all the same things you give a new employee: an email address, a slack username, a web browser, access to the company intranet, a GitHub account, a virtual machine with mouse and keyboard control, etc. and you'll be able to swap it out one-for-one with pretty much any low-level employee.
> Objectively, it would seem the answer is no. But at least they make a lot of money, right?
Wait, what? Does the author know what the word "objectively" means?
I'd kill for someone to tell me how feeding a pdf into Claude and asking it to provide a print-friendly version for a templating language has "objectively" no value?
What about yesterday when I asked Claude to look write some reflection-heavy code for me to traverse a bunch of classes and register them in DI?
Or the hundreds (maybe thousands) of times I've thrown a TS error and it explained it in English to me?
I'm so over devs thinking they can categorically tell everyone else what is and isn't helpful in a field as big as this.
Also, and this really, really needs repeated: When you say "AI" and don't specify exactly what you mean you sound like a moron. "AI", that insanely general phrase, happens to cover a wide, wide array of different things you personally use day to day. Anytime you do speech-to-text you're relying on "AI".
If someone told me that their Tesla's autopilot swerved them into a brick wall and they nearly died, I'm not going to say, "your newfound luddite bias is preventing you from seeking sensible middle ground. Surely there is no serious issue here." I'm going to say, "wow, that's fucked up. Maybe there's something deeply wrong with Tesla autopilot."
Sure, and that's very different from "the idea of self-driving cars is a giant scam that will never work".
What a horrible metaphor for a tool that can translate pdfs to text. lol. The anti-AI arguments are just as, if not more, absurd than the "AI can do everything" arguments.
I'm gonna need you to know that just because some random dev who wrote a blog said something doesn't make it true. You know that, right?
> Don't pretend that there are no negative consequences to the proliferation of AI tools.
Wait, what? Who said otherwise?
I love how you compare this tool to a Tesla's Autopilot mode, then get called out on it, and are like "Are you saying these tools are perfect" lol.
> What a horrible metaphor for a tool that can translate pdfs to text. lol.
You didn't say otherwise explicitly, but you're definitely downplaying the issues discussed in the blog post.
> I'm gonna need you to know that just because some random dev who wrote a blog said something doesn't make it true.
That's not really a satisfying response. If you disagree with the post, you'll have to mount a more substantial rebuttal than, "well what if he's wrong, huh? Have you considered that?"