It still feels like gambling to me when I use AI code assistants to generate large chunks of code. Sometimes, it will surprise me with how well it does. Other times, it infuriatingly doesn't follow very precise instructions for small changes. This is even when I use it in the way that I often ask for multiple options for solutions and implementations and then choose between them after the AI tool does the course rating.

There are many instances where I get to the final part of the feature and realize I spent far more time coercing AI to do the right thing than it would have taken me to do it myself.

It is also sometimes really enjoyable and sometimes a horrible experience. Programming prior to it could also be frustrating at times, but not in the same way. Maybe it is the expectation of increased efficiency that is now demanded in the face of AI tools.

I do think AI tools are consistently great for small POCs or where very standard simple patterns are used. Outside of that, it is a crapshoot or slot machine.

Claude Code slOpus user. No surprise this is their conclusion.

Looking for solo devs testing AI continuation tool - DM me

Good luck finding an employer that lets you do this moving forward. The new reality is that no one can give the estimates they previously gave for tasks. \

"Amazingly, I’m faster, more accurate, more creative, more productive, and more efficient than AI, when you price everything in, and not just code tokens per hour."

For 99.99% of developers this just won't be true.

AI can be good under the right circumstances but only if reviewed 100% of the time by a human.

Homelab is my hobby where I run Proxmox, Debian VM, DNS, K8s, etc, all managed via Ansible.

For what it is worth, I hate docker :)

I wanted to setup a private tracker torrent that should include:

1) Jackett: For the authentication

2) Radarr: The inhouse browser

3) qBitorrent: which receives the torrent files automatically from Radarr

4) Jellyfin: Of course :)

I used ChatGPT to assist me into getting the above done as simple as possible and all done via Ansible:

1) Ansible playbook to setup a Debian LXC Proxmox container

2) Jackett + Radarr + qBitorrent all in one for simplicity

3) Wireguard VPN + Proton VPN: If the VPN ever go down, the entire container network must stop (IPTables) so my home IP isn't leaked.

After 3 nights I got everything working and running 24/7, but it required a lot of review so it can be managed 10 years down the road instead of WTF is this???

There were silly mistakes that make you question "Why am I even using this tool??" but then I remember, Google and search engines are dead. It would have taken me weeks to get this done otherwise, AI tools speed that process by fetching the info I need so I can put them together.

I use AI purely to replace the broken state of search engines, even Brave and DuckDuckGo, I know what I am asking it, not just copy/paste and hope it works.

I have colleagues also into IT field whose the company where they work are fully AI, full access to their environment, they no longer do the thinking, they just press the button. These people are cooked, not just because of the state of AI, if they ever go look for another job, all they did for years was press a button!!

I am still fascinated by how convincing the AI slop can be. I saw way too much code and documentation which made no sense. But it's often not obvious. I read it, I don't get it, I read it again, am I just stupid? I can grab some threads from it, but overall, it just doesn't make sense, it doesn't click for me. And that's when I often realize, it doesn't click, because it's a slop. It's obvious in pictures (e.g., generate a picture of a bike with labels). But in code? It requires more time to look at it than to actually write it. So it just slips reviews, it sometimes even works as it should, but it's damn hard to understand and fix it in the future. Until eventually, nothing can fix it.

For the record, I use AI to generate code but not for "vibecoding". I don't believe when people tell me "you just prompt it badly". I saw enough to lose faith.

I read that people just allow Claude Code free rein but after using it for a few months and seeing what it does I wonder how much of that is in front of users. CC is incredible as much as it is frustrating and a lot of what it churns out is utter rubbish.

I also keep seeing that writing more detailed specs is the answer and retorts from those saying we’re back to waterfall.

That isn’t true. I think more of the iteration has moved to the spec. Writing the code is so quick now so can make spec changes you wouldn’t dare before.

You also need gates like tests and you need very regular commits.

I’m gradually moving towards more detailed specs in the form of use cases and scenarios along with solid tests and a constantly tuned agent file + guidelines.

Through this I’m slowly moving back to letting Claude lose on implementation knowing I can do scan of the git diffs versus dealing with a thousand ask before edits and slowing things down.

When this works you start to see the magic.

The author makes it sound like such a binary choice, but there's a happy middle where you are having AI generate large blocks of code and then you closely supervise it. My experience so far with AI is to treat it like you're a low-level manager delegating drudgework. I will regularly rewrite or reorganize parts of the code and give it back to the AI to reset the baseline and expectations.

AI is far from perfect, but the same is true about any work you may have to entrust to another person. Shipping slop because someone never checked the code was literally something that happened several times at startups I have worked at - no AI necessary!

Vibecoding is an interesting dynamic for a lot of coders specifically because you can be good or bad at vibecoding - but the skill to determine your success isn't necessarily your coding knowledge but your management and delegation soft skills.

I wish more critics would start to showcase examples of code slop. I'm not saying this because I defend the use of AI-coding, but rather because many junior devs. that read these types articles/blog posts may not know what slop is, or what it looks like. Simply put, you don't know what you don't know.

You just give up before AI overpass human

Google Maps completely and utterly obliterated my ability to navigate. I no longer actively navigated. I passively navigated.

This is no different. And I'm not talking about vibe coding. I just mean having an llm browser window open.

When you're losing your abilities, it's easy to think you're getting smarter. You feel pretty smart when you're pasting that code

But you'll know when you start asking "do me that thingy again". You'll know from your own prompts. You'll know when you look at older code you wrote with fear and awe. That "coding" has shifted from an activity like weaving cloth to one more like watching YouTube.

Active coding vs passive coding

I vibe coded for a while (about a year) it was just so terrible for my ability to do anything, it started becoming recurring that I couldn't control my timelines because I would get into a loop where I would keep asking AI to "fix" things I didn't actually understand and had no mental capacity to actually read 50k lines of LLM generated code compared to if I had done it from scratch so I would keep and keep going.

Or how I would start spamming SQL scripts and randomly at some point nuke all my work (happened more than once)... luckily at least I had backups regularly but... yeah.

I'm sorry but no, LLMs can't replace software engineers.

You can do both. It's not binary.

You'll never find a programming language that frees you from the burden of clarifying your ideas.

Relevant xkcd: https://xkcd.com/568/

Even if we reach the point where it's as good as a good senior dev. We will still have to explain what we want it to do.

That's how I find it most helpful too. I give it a task and work out the spec based on the bad assumptions it makes and manually fix it.

The impression I get from the article is of a need to develop better prompts and/or break them down more

One thing that's consistent with AI negative/doesn't work/is slop posts: they don't tell you want models they are using.

On the one hand, I created vibe coded a large-ish (100k LOC) C#, Python, Powershell project over the holidays. The whole thing was more than I could ever complete on my own in the 5 days it took to vibe code using three agents. I wrote countless markdown 'spec' files, etc.

The result stunned everyone I work with. I would never in a million years put this code on Github for others. It's terrible code for a myriad reasons.

My lived experience was... the task was accomplished but not in a sustainable way over the course of perhaps 80 individual sessions with the longest being multiple solid 45 minute refactors...(codex-max)

About those. One of things I spotted fairly quickly was the tendency of models to duplicate effort or take convoluted approaches to patch in behaviors. To get around this, I would every so often take the entire codebase, send it to Gemini-3 Pro and ask it for improvements. Comically, every time, Gemini-3-Pro responds with "well this code is hot garbage, you need to refactor these 20 things". Meanwhile, I'm side-eying like.. dude you wrote this. Never fails to amuse me.

So, in the end, the project was delivered, was pretty cool, had 5x more features than I would have implemented myself and once I got into a groove -- I was able to reduce the garbage through constant refactors from large code reviews. Net Positive experience on a project that had zero commercial value and zero risk to customers.

But on the other hand...

I spend a week troubleshooting a subtle resource leak (C#) on a commercial project that was introduced during a vibe-coding session where a new animation system was added and somehow added a bug that caused a hard crash on re-entering a planet scene.

The bug caused an all-stop and a week of lost effort. Countless AI Agent sessions circularly trying to review and resolve it. Countless human hours of testing and banging heads against monitors.

In the end, on the maybe random 10th pass using Gemini-3-Pro it provided a hint that was enough to find the issue.

This was a monumental fail and if game studios are using LLMs, good god, the future of buggy mess releases is only going to get worse.

I would summarize this experience as lots of amazement and new feature velocity. A little too loose with commits (too much entanglement to easily unwind later) and ultimately a negative experience.

A classic Agentic AI experience. 50% Amazing, 50% WTF.

The title alone reads like the "digging for diamonds" meme.

He might be coding by hand again, but the article itself is AI slop

Good luck. I haven't written a single line of code since 6 month ago

This bubble is going to crash so much harder than any other bubble in history. It's almost impossible to overstate the level of hype. LLMs are functionally useless in any context. It's a total and absolute scam.

k

Everything the OP says can be true, but there’s a tipping point where you learn to break through the cruft and generate good code at scale.

It requires refactoring at scale, but GenAI is fast so hitting the same code 25 times isn’t a dealbreaker.

Eventually the refactoring is targeted at smaller and smaller bits until the entire project is in excellent shape.

I’m still working on Sharpee, an interactive fiction authoring platform, but it’s fairly well-baked at this point and 99% coded by Claude and 100% managed by me.

Sharpee is a complex system and a lot of the inner-workings (stdlib) were like coats of paint. It didn’t shine until it was refactored at least a dozen times.

It has over a thousand unit tests, which I’ve read through and refactored by hand in some cases.

The results speak for themselves.

https://sharpee.net/ https://github.com/chicagodave/sharpee/

It’s still in beta, but not far from release status.

+1, ive lost the mental model of most projects. I also added disclaimers to my projects that part of it was generated to not fool anyone

Interacting with LLMs like Copilot has been most interesting for me when I treat it like a rubber duck.

I will have a conversation with the agent. I will present it with a context, an observed behavior, and a question... often tinged with frustration.

What I get out of this interaction at the end of it is usually a revised context that leads me figure out a better outcome. The AI doesn't give me the outcome. It gives me alternative contexts.

On the other hand, when I just have AI write code for me, I lose my mental model of the project and ultimately just feel like I'm delaying some kind of execution.

I've gone through this cycle too, and what I realized is that as a developer a large part of your job is making sure the code you write works, is maintainable, and you can explain how it works.

I like to use AI to write code for me, but I like to take it one step at a time, looking at what it puts out and thinking about if it puts out what I want it to put out.

As a PRODUCT person, it writes code 100x faster than I can, and I treat anything it writes as a "throwaway" prototype. I've never been able to treat my own code as throwaway, because I can't just throw away multiple weeks of work.

It doesn't aid in my learning to code, but it does aid in me putting out much better, much more polished work that I'm excited to use.

As people get more comfortable with AI. I think what everyone is noticing is that AI is terrible at solving problems that don't have large amounts of readily available training data. So, basically if there isn't already an open-source solution available online, it can't do it.

If what you're doing is proprietary, or even a little bit novel. There is a really good chance that AI will screw it up. After all, how can it possibly know how to solve a problem it has never seen before?

I use ai to develop, but at every code review I find stuff to be corrected, which motivates me to continuing the reviews. It's still a win I think though. I've incrementally increased my use of ai in development [1], but I'm at a plateau now I think. I don't plan to go over to complete vibe coding for anything serious or to be maintained.

1: https://asfaload.com/blog/ai_use/

The funniest thing I've seen GPT do was a while back when I had it try to implement ORCA (Optimal Reciprocal Collision Avoidance). It is a human made algorithm for entities where they just use their own and N neighbours' current radii along with their velocity to calculate mathematical lines into the future, so that they can avoid walking into each other.

It came very close to success, but there were 2 or 3 big show-stopping bugs such as it forgetting to update the spatial partitioning when the entities moved, so it would work at the start but then degrade over time.

It believed and got stuck on thinking that it must be the algorithm itself that was the problem, so at some point it just stuck a generic boids solution into the middle of the rest. To make it worse, it didn't even bother to use the spatial partitioning and they were just brute force looking at their neighbours.

Had this been a real system it might have made its way into production, which makes one think about the value of the AI code out there. As it was I pointed out that bit and asked about it, at which point it admitted that it was definitely a mistake and then it removed it.

I had previously implement my own version of the algorithm and it took me quite a bit of time, but during that I built up the mental code model and understood both the problem and solution by the end. In comparison it easily implemented it 10-30x faster than I did but would never have managed to complete the project on its own. Also if I hadn't previously implemented it myself and had just tried to have it do the heavy lifting then I wouldn't have understood enough of what it was doing to overcome its issues and get the code working properly.

There is certainly some truth to this, but why does it have to be black-and-white?

Nobody forces you to completely let go of the code and do pure vibe coding. You can also do small iterations.

I actually haven't come across situation 1 2 or 3 mentioned in the attached video. Generally I iterate on the code by starting a new prompt with the code provided, with enhancements, or provide the errors and it repairs the errors. Generally it gets it within 1-2 iterations. No emotions. Make sure your prompts do not contain fluff, and are straight what you want the code to accomplish and how you want it to accomplish it. I've gone back to code months later and have not had what you described as being shocked about bad code, it was quite easy to understand. Are you prompting the AI to also write variables and function names logically and utilize a common coding standard for whichever type of code you are having it write, such as wordpress coding standards or similar? Perhaps claude isn't the best, I have been experimenting with grok 4.1 thinking and grok expert at the mid-level paid tier. I'll take it a step further and adjust the code myself, start a new prompt and provide that updated code along with my further requests as well. I haven't hit the road blocks mentioned.

I think what many people do no understand is that software development is communication. Communication from the customers/stake holders to the developer and communication from with the developer to the machine. At some fundamental level there needs to be some precision about what you want and someone/something needs to translate that into a system to provide that solution. Software can help check if there are errors, check constraints, and execute instructions precisely, but they cannot replace the fact that someone needs to tell the machine what to do (precise intent).

What AI (LLMs) do is raises the level of abstraction to human language via translation. The problem is human language is imprecise in general. You can see this with legal or science writing. Legalese is almost illegible to laypeople because there are precise things you need to specify and you need be precise in how you specify it. Unfortunately the tech community is misleading the public and telling laypeople they can just sit back and casually tell AI what you want and it is going to give you exactly what you wanted. Users are just lying to themself, because most-likely they did not take the time to think through what they wanted and they are rationalizing (after the fact) that the AI is giving them exactly what they wanted.

In my experience it's great a writing sample code or solving obscure problems that would have been hard to google a solution for. However it fails sometimes and it can't get past some block, but neither can I unless I work hard at it.

Examples.

Thanks to Claude I've finally been able to disable the ssh subsystem of the GNOME keyring infrastructure that opens a modal window asking for ssh passhprases. What happened is that I always had to cancel the modal, look for the passhprase in my password manager, restart what made the modal open. What I have now is either a password prompt inside a terminal or a non modal dialog. Both ssh-add to a ssh agent.

However my new emacs windows still open in an about 100x100 px window on my new Debian 13 install, nothing suggested by Claude works. I'll have to dig into it but I'm not sure that's important enough. I usually don't create new windows after emacs starts with the saved desktop configuration.

One use case that I'm beginning to find useful is to go into a specific directory of code that I have written and am working on, and ask the AI agent (Claude Code in my case) "Please find and list possible bugs in the code in this directory."

Then, I can reason through the AI agent's responses and decide what if anything I need to do about them.

I just did this for one project so far, but got surprisingly useful results.

It turns out that the possible bugs identified by the AI tool were not bugs based on the larger context of the code as it exists right now. For example, it found a function that returns a pointer, and it may return NULL. Call sites were not checking for a NULL return value. The code in its current state could never in fact return a NULL value. However, future-proofing this code, it would be good practice to check for this case in the call sites.

It'd be easy to simply say "skill issue" and dismiss this, but I think it's interesting to look at the possible outcomes here:

Option 1: The cost/benefit delta of agentic engineering never improves past net-zero, and bespoke hand-written code stays as valuable as ever.

Option 2: The cost/benefit becomes net positive, and economics of scale forever tie the cost of code production directly to the cost of inference tokens.

Given that many are saying option #2 is already upon us, I'm gonna keep challenging myself to engineer a way past the hurdles I run into with agent-oriented programming.

The deeper I get, the more articles like this feel like the modern equivalent of saying "internet connections are too slow to do real work" or "computers are too expensive to be useful for regular people".

This will sound arrogant, but I can't shake the impression that agent programming is most appealing to amateurs, where the kind of software they build is really just glorified UIs and data plumbing.

I work on game engines which do some pretty heavy lifting, and I'd be loath to let these agents write the code for me.

They'd simply screw too much of it up and create a mess that I'm going to have to go through by hand later anyway, not just to ensure correctness but also performance.

I want to know what the code is doing, I want control over the fine details, and I want to have as much of the codebase within my mental understanding as possible.

Not saying they're not useful - obviously they are - just that something smells fishy about the success stories.

It took me about two weeks to realise this. I still use LLMs, but it's just a tool. Sometimes it's the right tool, but often it isn't. I don't use an SDS drill to smooth down a wall. I use sandpaper and do it by hand.

Good for the author. Me, never going back to hands-only coding. I am producing more higher quality code that I understand and feel confident in. I tell AI to not just “write tests”, I tell it exactly what to test as well. Then I’ll often prompt it “hey did you check for the xyz edge cases?” You need code reviews. You need to intervene. You will need frequent code rewrites and refactors. But AI is the best pair-coding partner you could hope for (at this time) and one that never gets tired.

So while there’s no free lunch, if you are willing to pay - your lunch will be a delicious unlimited buffet for a fraction of the cost.

Maybe I'm "vibecoding" wrong but to me at least this misses a clear step which is reviewing the code.

I think coding with an AI changes our role from code writer to code reviewer, and you have to treat it as a comprehensive review where you comment not just on code "correctness" but these other aspects the author mentions, how functions fits together, codebase patterns, architectural implications. While I feel like using AI might have made me a lazier coder, it's made me a me a significantly more active reviewer which I think at least helps to bridge the gap the author is referencing.

The tale of the coder, who finds a legacy codebase (sometimes of their own making) and looks at it with bewilderment is not new. It's a curious one, to a degree, but I don't think it has much to do with vibe coding.

Accurate and sane take! Current models are extremely good for very specific kinds of tasks. But beyond that, it is a coin toss. Gets worse as the context window goes beyond a few ten thousand tokens. If you have only vibe-coded toy projects (even with the latest fad - Ralph whatever) for anything serious, you can see how quickly it all falls apart.

It is quite scary that junior devs/college kids are more into vibe coding than putting in the effort to actually learn the fundamentals properly. This will create at least 2-3 generations of bad programmers down the line.

Beware the two extremes - AI out of the box with no additional config, or writing code entirely by hand.

In order to get high accuracy PRs with AI (small, tested commits that follow existing patterns efficiently), you need to spend time adding agents (claude.md, agents.md), skills, hooks, and tools specific to your setup.

This is why so much development is happening at the plugin layer right now, especially with Claude code.

The juice is worth the squeeze. Once accuracy gets high enough you don't need to edit and babysit what is generated, you can horizontally scale your output.

Rants like this are - entirely correct in describing frustration - reasonable in their conclusions with respect to how and when to work with contemporary tools - entirely incorrect in intuition about whether "writing by hand" is a viable path or career going forward

Like it not, as a friend observed, we are N months away a world where most engineers never looks at source code; and the spectrum of reasons one would want to will inexorably narrow.

It will never be zero.

But people who haven't yet typed a word of code never will.

I feel like the vast majority of articles on this are little more than the following:

"AI can be good -- very good -- at building parts. For now, it's very bad at the big picture."

I've never used an AI in agent mode (and have no particular plans to), but I do think they're nice for things like "okay, I have moved five fields from this struct into a new struct which I construct in the global setup function. go through and fix all the code that uses those fields". (deciding to move those fields into a new struct is something I do want to be doing myself though, as opposed to saying "refactor this code for me")

After reading the article (and watching the video), I think the author makes very clear points that comments here are skipping over.

The opener is 100% true. Our current approach with AI code is "draft a design in 15mins" and have AI implement it. The contrasts with the thoughtful approach a human would take with other human engineers. Plan something, pitch the design, get some feedback, take some time thinking through pros and cons. Begin implementing, pivot, realizations, improvements, design morphs.

The current vibe coding methodology is so eager to fire and forget and is passing incomplete knowledge unto an AI model with limited context, awareness and 1% of your mental model and intent at the moment you wrote the quick spec.

This is clearly not a recipe for reliable and resilient long-lasting code or even efficient code. Spec-driven development doesn't work when the spec is frozen and the builder cannot renegotiate intent mid-flight..

The second point made clearer in the video is the kind of learned patterns that can delude a coder, who is effectively 'doing the hard part', into thinking that the AI is the smart one. Or into thinking that the AI is more capable than it actually is.

I say this as someone who uses Claude Code and Codex daily. The claims of the article (and video) aren't strawman.

Can we progress past them? Perhaps, if we find ways to have agents iteratively improve designs on the fly rather than sticking with the original spec that, let's be honest, wasn't given the rigor relative to what we've asked the LLMs to accomplish. If our workflows somehow make the spec a living artifact again -- then agents can continuously re-check assumptions, surface tradeoffs, and refactor toward coherence instead of clinging to the first draft.

> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not.

That's exactly why this whole (nowadays popular) notion of AI replacing senior devs who are capable of understanding large codebases is nonsense and will never become reality.

after+30 years writing code in a dozen languages building systems from scratch I love vibe coding ... it's drinking from a fire hose ... in two months I vibe coded a container orchestration system which I call my kubernetes replacement project all in go with a controller deciding which VM to deploy containers onto, agents on each host polling etcd for requests created by the controller ... it's simple understandable maintainable extendable ... also vibe coded go cdk to deploy AWS RDS clusters, API gateway, handful of golang lambda functions, valkey elasticache and a full feature data service library which handles transactions and save points, cache ... I love building systems ... sure I could write all this from scratch by hand and I have but vibe coding quickly exposes me to the broad architecture decisions earlier giving me options to experiment on various alternatives ... google gemini in antigravity rocks and yes I've tried them all ... new devs should not be vibe coding for the first 5 years or more but I lucked into having decades of doing it by hand

I still cannot make AI do anything with quality higher than the function level. I've been using it a lot to write some more complex functions and SQL with a quality level that I find good, but anything higher order and it's a complete clusterfuck. Cannot comprehend this world where people say they are building entire companies and whole products with it.

False dichotomy. There is a happy medium where you can orchestrate the agent to give you the code you want even when the spec changes

May be we will have at last the AI to do literate programming. So it can properly reread and connect big chunks of code it wrote magically in isolation. From that perspective, the AI is following the path of a experienced programmer: specs and docs maintained in parallel of the code will save your .ss in the long run.

Great engagement-building post for the author’s startup, blog, etc. Contrarian and just plausible enough.

I disagree though. There’s no good reason that careful use of this new form of tooling can’t fully respect the whole, respect structural integrity, and respect neighboring patterns.

As always, it’s not the tool.

Process and plumbing become very important when using ai for coding. Yes, you need good prompts. But as the code base gets more complex, you also need to spend significant time developing test guides, standardization documents, custom linters, etc, to manage the agents over time.

unless someone shows their threads of prompts or an unedited stream of them working, it's pointless to put any weight into their opinions.

this is such an individualized technology that two people at the same starting point two years ago, could've developed wildly different workflows.

I don't get what everyone sees in this post. It is just a sloppy rant. It just talks in generalities. There is no coherent argument, there are no examples, and we don't even know the problem space in which the author had bad coding assistant experience.

I hear a lot of "I am not a good enough coder..." "It has all the sum of human knowledge..."

That's a very bad way to look at these tools. They legit know nothing, they hallucinate APIs all the time.

The only value they have at least in my book is they type super fast.

I haven't been vibe coding for more than a few months.

It's just a tool with a high level of automation. That becomes clear when you have to guide it to use more sane practices, simple things like don't overuse HTTP headers when you don't need them.

I don't know whether I would go that extreme, but I also often find myself faster writing code manually; for some tasks though and contextually, AI-assisted coding is pretty useful, but you still must be in the driving seat, at all times.

Good take though.

2006: "If I can just write the specs so that the engineer understands them it will write me code that works."

2026: "If I can just write the specs so that the machine understands them it will write me code that works."

AI is a good tutor, helping you understand what's going on with the codebase, and also helps with minor autocomplete tasks.

You should never just let AI "figure it out." It's the assistant, not the driver.

The part that most resonates with me is the lingering feeling of “oh but it must be my fault for underspecifying” which blocks the outright belief that models are just still sloppy at certain things

Previous discussion on the video: https://news.ycombinator.com/item?id=46744572

This is not my experience at all. Claude will ask me follow up questions if it has some. The claim that it goes full steam ahead on its original plan is false.

two years of vibecoding experience already?

his points about why he stopped using AI: these are the things us reluctant AI adopters have been saying since this all started.

An excellent example of the political utility of AI, and how long it takes to figure out that it isn't as useful as the hype might make you think.

Opus 4.5 is maybe 10% better than GPT 3.5. It's a total joke and these AI lab CEOs should literally be put in prison with Bernie Maddoff

Taking crazy pills here too.

I just bootstrapped a 500k loc MVP with AI Generator, Community and Zapier integration.

www.clases.community

And is my 3rd project that size, fully vibe coded

Little to no evidence was presented.

This is vibe argumenting.

a lot of AI assisted development goes into project management and system design.

I have been tolerably successful. However, I have almost 30 years of coding experience, and have the judgement on how big a component should be - when I push that myself _or_ with AI, things go hairy.

ymmv.

OK. Top AI labs have people using llms for 100% of their code. Enjoy writing by hand tho

I feel vindicated by this article, but I shouldn't. I have to admit that I never developed the optimism to do this for two years, but have increasingly been trying to view this as a personal failing of closed-mindedness, brought on by an increasing number of commentators and colleagues coming around to "vibe-coding" as each "next big thing" in it dropped.

I think the most I can say I've dove in was in the last week. I wrangled some resources to build myself a setup with a completely self-hosted and agentic workflow and used several open-weight models that people around me had specifically recommended, and I had a work project that was self-contained and small enough to work from scratch. There were a few moving pieces but the models gave me what looked like a working solution within a few iterations, and I was duly impressed until I realized that it wasn't quite working as expected.

As I reviewed and iterated on it more with the agents, eventually this rube-goldberg machine started filling in gaps with print statements designed to trick me and sneaky block comments that mentioned that it was placeholder code not meant for production in oblique terms three lines into a boring description of what the output was supposed to be. This should have been obvious, but even at this point four days in I was finding myself missing more things, not understanding the code because I wasn't writing it. This is basically the automation blindness I feared from proprietary workflows that could be changed or taken away at any time, but much faster than I had assumed, and the promise of being able to work through it at this higher level, this new way of working, seemed less and less plausible the more I iterated, even starting over with chunks of the problem in new contexts as many suggest didn't really help.

I had deadlines, so I gave up and spent about half of my weekend fixing this by hand, and found it incredibly satisfying when it worked, but all-in this took more time and effort and perhaps more importantly caused more stress than just writing it in the first place probably would have

My background is in ML research, and this makes it perhaps easier to predict the failure modes of these things (though surprisingly many don't seem to), but also makes me want to be optimistic, to believe this can work, but I also have done a lot of work as a software engineer and I think my intuition remains that doing precision knowledge work of any kind at scale with a generative model remains A Very Suspect Idea that comes more from the dreams of the wealthy executive class than a real grounding in what generative models are capable of and how they're best employed.

I do remain optimistic that LLMs will continue to find use cases that better fit a niche of state-of-the-art natural language processing that is nonetheless probabilistic in nature. Many such use cases exist. Taking human job descriptions and trying to pretend they can do them entirely seems like a poorly-thought-out one, and we've to my mind poured enough money and effort into it that I think we can say it at the very least needs radically new breakthroughs to stand a chance of working as (optimistically) advertised

> It was pure, unadulterated slop. I was bewildered. Had I not reviewed every line of code before admitting it? Where did all this...gunk..come from?

I chuckled at this. This describes pretty much every large piece of software I've ever worked on. You don't need an LLM to create a giant piece of slop. To avoid it takes tons of planning, refinement, and diligence whether it's LLM's or humans writing it.

Yup, checks out, you're definitely the type of person the AI companies are marketing to.

Yes! You are best served by learning what a tool is doing for you by doing it yourself or carefully studying what it uses and obfuscates from you before using the tool. You don't need to construct an entire functioning processor in an HDL, but understanding the basics of digital logic and computer architecture matters if you're EE/CompE. You don't have to write an OS in asm, but understanding assembly and how it gets translated into binary and understanding the basics of resource management, IPC, file systems, etc. is essential if you will ever work in something lower level. If you're a CS major, algorithms and data structures are essential. If you're just learning front end development on your own or in a boot camp, you need to learn HTML and the DOM, events, how CSS works, and some of the core concepts of JS, not just React. You'll be better for it when the tools fail you or a new tool comes along.

But what has changed? Students never had a natural reason to learn how to write fizz buzz. It's been done before and its not even useful. There has always been a arbitrary nature to these exercises.

I actually fear more for the middle-of-career dev who has shunned AI as worthless. It's easier than ever for juniors to learn and be productive.

Lots of interesting ways to spin this. I was in a computer science course in the late 90s and we were not allowed to use the C++ standard library because it made you a "lazy programmer" according to the instructor. I'm not sure if I agree with that, but the way that I look at it is that computer science all about abstraction, and it seems to me that AI, generative pair programming, vibe coding or what ever you want to call it is just another level of abstraction. I think what is probably more important is to learn what are and are not good programming and project structures and use AI to abstract the boilerplate,. scaffolding, etc so that you can avoid foot guns early on in your development cycle.

Sure (knowing the underlying ideas and having proficiency in their application) - but producing software by conducting(?) LLMs is rapidly becoming a wide, deep and must-have skill and the lack thereof will be a weakness in any student entering the workplace.

Agreed. I think the divide is between code-as-thinking and code-as-implementation. Trivial assignments and toy projects and geeking out over implementation details are necessary to learn what code is, and what can be done with it. Otherwise your ideas are too vague to guide AI to an implementation.

Without the clarity that comes from thinking with code, a programmer using AI is the blind leading the blind.

The social aspect of a dialogue is relaxing, but very little improvement is happening. It's like a study group where one (relatively) incompetent student tries to advise another, and then test day comes and they're outperformed by the weirdo that worked alone.

I was so lucky to land in a CS class where we were writing C++ by hand. I don't think that exists anymore, but it is where I would go in terms of teaching CS from first principles

I'm not so sure. I spent A LOT of time writing sorting algo code by hand in university. I spent so much time writing assembly code by hand. So much more time writing instructions for MIPS by hand. (To be fair I did study EE not CS)

I learned more about programming in a weekend badly copying hack modules for Minecraft than I learned in 5+ years in university.

All that stuff I did by hand back then I haven't used it a single time after.

Similarly, it's always been the case that copy-pasting code out of a tutorial doesn't teach you as much much as manually typing it out, even if you don't change it. That part of the problem isn't even new.

AI does have an incredibly powerful influence on learning. It can absolutely be used as a detriment, but it can also be just as powerful of a learning tool. It all comes down to keeping the student in the zone of proximal development.

If AI is used by the student to get the task done as fast as possible the student will miss out on all the learning (too easy).

If no AI is used at all, students can get stuck for long periods of time on either due to mismatches between instructional design and the specific learning context (missing prereq) or by mistakes in instructional design.

AI has the potential to keep all learners within an ideal difficulty for optimal rate of learning so that students learn faster. We just shouldn't be using AI tools for productivity in the learning context, and we need more AI tools designed for optimizing learning ramps.

The problem is: now they also need to learn to code with an LLM assistant. That goes beyond "coding it by yourself". Well, it's different, anyway. Another skill to teach.

Part of the issue here is that you can look at something and think "oh yeah I understand that, it makes perfect sense!", but then completely fail to reproduce it yourself.

It doesn't PREVENT them from learning anything - said properly, it lets developers become lazy and miss important learning opportunities. That's not AIs fault.

Yea, I doubt I could learn to program today if I started today.

It feels like coding agents have just abstracted the old programming problem of "computers do what you tell them, not what you mean to tell them"

As a teacher, do you have any techniques to make sure students learn to write the code?

I just think it's like hitting the snooze button.

> You CAN'T let the machines write the code

People said this about compilers. It depends what layer you care to learn/focus on. AI at least gives us the option to move up another level.

Yes, exactly. I'm having a frustrating time reminding senior teachers of this, people with authority who should really know better. There seems to be some delusion that this technology will somehow change how people learn in a fundamental way.

Completely disagree. It’s like telling typists that they need to hand write to truly understand their craft. Syntax is just a way of communicating a concept to the machine. We now have a new (and admitidly imperfect) way of doing that. New skills are going to be required. Computer science is going to have to adapt.

I'm an external examiner for CS students in Denmark and I disagree with you. What we need in the industry is software engineers who can think for themselves, can interact with the business and understand it's needs, and, they need to know how computers work. What we get are mass produced coders who have been taught some outdated way of designing and building software that we need to hammer out of them. I don't particularily care if people can write code like they work at the assembly line. I care that they can identify bottlenecks and solve them. That they can deliver business value quickly. That they will know when to do abstractions (which is almost never). Hell, I'd even like developers who will know when the code quality doesn't matter because shitty code will cost $2 a year but every hour they spend on it is $100-200.

Your curriculum may be different than it is around here, but here it's frankly the same stuff I was taught 30 years ago. Except most of the actual computer science parts are gone, replaced with even more OOP, design pattern bullshit.

That being said. I have no idea how you'd actually go about teaching students CS these days, considering a lot of them will probably use ChatGPT or Claude regardless of what you do. That is what I see in the statistic for grades around here. For the first 9 years I was a well calibrated grader, but these past 1,5ish years it's usually either top marks or bottom marks with nothing in between. Which puts me outside where I should be, but it matches the statistical calibration for everyone here. I obviously only see the product of CS educations, but even though I'm old, I can imagine how many corners I would have cut myself if I had LLM's available back then. Not to mention all the distractions the internet has brought.

The same reason we give beginner math students addition and subtraction problems, not Fermat’s last theorem?

There has to be a base of knowledge available before the student can even comprehend many/most open research questions, let alone begin to solve them. And if they were understandable to a beginner, then I’d posit the LLM models available today would also be capable of doing meaningful work.

No, because AI is not deterministic. All those other tools are intentionally isomorphic with machine code, even if there's a lot of optimization going on under the hood. AI may generate code that's isomorphic with your prompt, but it also may not. And you have no way of telling the difference besides reading and understanding the code.

There's a quote I love from Feynman

  > The first principle is that you must not fool yourself and you are the easiest person to fool.

I have no doubt he'd be repeating it loudly now, given we live in a time where we developed machines that are optimized to fool ourselves.

It's probably also worth reading Feynman's Cargo Cult Science: https://sites.cs.ucsb.edu/~ravenben/cargocult.html

Same reason to still memorize basic math in the time of calculators. gotta learn the fundamentals and you're not always going to have one.

Hey, I guess that means there's less competition for me. I don't mind.

If I'm understandinf correctly, I don't think what you're saying is quite right. They had a mental model of the algorithms, and then the code they "produced" was completely generated by AI, and they had no knowledge of how the code actually modeled the algorithm.

Knowing the complexity of bubble sort is one skill, being able to write code that performs bubble sort is a second, and being able to look at a function with the signature `void do_thing(int[] items)`and determine that it's bubble sort and the time complexity of it in terms of the input array is a third. It sounds like they had the first skill, used an AI to fake the second, but had no way of doing the third.

> These days most programmers don't know assembler, and increasingly don't know languaes as low level as C either. And the world didn't fall apart.

Maybe the world didn't fall apart, but user interactions on a desktop pc feel slower than ever. So perhaps they should.

> And the world didn't fall apart.

Software got significantly worse in that time period, though

If you are concerned that embedding "from first-principles" reasoning in widely-available LLM's may create future generations that cannot, then I share your concern. I also think it may be overrated. Plenty of people "do division" without quite understanding how it all works (unfortunately).

And plenty of people will still come along who love to code despite AI's excelling at it. In fact, calling out the AI on bad design or errors seems to be the new "code golf".

I wasn't an early adopter of Copilot, but now the VSCode plugin can use Claude models in Agent mode. I've had success with this.

I don't "vibecode" though, if I don't understand what it's doing I don't use it. And of course, like all LLMs, sometimes it goes on a useless tangent and must be reigned in.

I don’t believe everyone find vibecoding as draining as you. You have to be a true artisan for that and most people aren’t. In fact, in this transition state folks are more than happy to finish off their assigned tickets and spend the rest of the sprint working on personal projects or slacking off.

gpt-3 afaik

I just round robin them until I run out on whatever subscription level I'm on. I only use claude api, so I pay per token there... I consider using claude as "bringing out the big guns" because I also think it's the top-level coder.

A version of this does happen with regard to fitness.

There are enthusiasts who will spend an absolute fortune to get a bike that is few grams lighter and then use it to ride up hills for the exercise.

Presumably a much cheaper bike would mean you could use a smaller hill for the same effect.

But if your goal is to get from A to B, car is more efficient.

It's the whole "journey vs destination" thing.

Currently AI seems to be the rocket you strap to your back as you put on VR glasses and enjoy the entertainment. You'll get there fast or blow up in the middle.

The True Artisanal Coders are the ones running the whole way, enjoying the scenery and the physical conditioning they get.

And there are people in between with bikes, cars etc. (different stages of AI use)

Analogies are fun =)

That's why it's so important to teach how to use them properly instead of demonizing them. Let's be realistic, they are not going to disappear and students and workers are not stopping using them.

Hmmm, I think we're more likely to face an Idiocracy outcome. We need more Geordi La Forges out there, but we've got a lot of Fritos out here vibe coding the next Carl's Jr. locating app instead

we would be lucky to have idiocracy. president camacho had a huge problem and he found the smartest person in the country and got him working on it. if only we can do that

Star Trek illustrated the issue nicely in the scene where Scotty, who we should remember is an engineer, tries to talk to a computer mouse in the 20th century: https://www.youtube.com/watch?v=hShY6xZWVGE

I agree with you in part, you can’t expect to learn something like coding without the doing.

The brave new world is that you no longer have to do “coding” in our sense of the word. The doing, and what exercises you should learn with have both changed.

Now students should build whole systems, not worry about simple Boolean logic and program flow. The last programmer to ever need to write an if statement may already be in studies.

More like using a calculator but not being able to explain how to do the calculation by hand. A probabilistic calculator which is sometimes wrong at that. The "lots of theory but no practice" has always been true for a majority of graduates in my experience.

I guess there's a reason why you don't spend most of your time at school in class with a professor.

They have not said that. They've only said that most of their code is written by Claude. That is different than "vibe coding". If competent engineers review the code then it is little different than any coding.

> Misusing a forklift might injure the driver and a few others; but it is unlikely to bring down an entire electric grid

That's the job of the backhoe.

(this is a joke about how diggers have caused quite a lot of local internet outages by hitting cables, sometimes supposedly "redundant" cables that were routed in the same conduit. Hitting power infrastructure is rare but does happen)

> but it is unlikely to bring down an entire electric grid

Unless you happen to drive a forklift in a power plant.

> expose millions to fraud and theft

You can if you drive forklift in a bank.

> put innocent people in prison

You can use forklift to put several innocent people in prison with one trip, they have pretty high capacity.

> jeopardize the institutions of government.

It's pretty easy with a forklift, just try driving through main gate.

> There is more than one kind of leverage at play here.

Forklifts typically have several axes of travel.

That's the koolaid, but seriously I don't really believe it anymore.

I only had to do this leg work during university to prove that I can be allowed to try and write code for a living. The grounding as you call it is not required for that at all,since im a dozen levels of abstraction removed from it. It might be useful if I was a researcher or would work on optimizing complex cutting edge stuff, but 99% of what I do is CRUD apps and REST Apis. That stuff can safely be done by anyone, no need for a degree. Tbf I'm from Germany so in other places they might allow you to do this job without a degree

I think we very often confuse engineers with scientists in this field. Think of the old joke: “anyone can build a bridge, it takes an Engineer to build one that barely stands”. Business value and the goal of engineering is to make a bridge that is fast to build, cheap to make, and stays standing exactly as long as it needs to. This is very different from the goals of science which are to test the absolute limits of known performance.

What I read from GP is that they’re looking for engineering innovation, not new science. I don’t see it as contradictory at all.

You should worry about code quality, but you should also worry about the return on investment.

That includes understanding risk management and knowing what the risks and costs are of failures vs. the costs of delivering higher quality.

Engineering is about making the right tradeoffs given the constraints set, not about building the best possible product separate from the constraints.

Sometimes those constraints requires extreme quality, because it includes things like "this should never, ever fail", but most of the time it does not.

> You want initiative, and you also don't want initiative. I presume you want it when it's good and don't want it when it's bad, and if possible the people should be clairvoyant and see the future so they can tell which is which.

The word you’re looking for is skill. He wants devs to be skilled. I wouldn’t thought that to be controversial but hn never ceases to amaze

Some of our code is of high quality. Other can be of any quality as it'll never need to be altered in it's lifecycle. If we have 20000 financial reports which needs to be uploaded once, and then it'll never happen again, it really doesn't matter how terrible the code is as long as it only uses vetted external dependencies. The only reason you'd even use developer time on that task is because it's less errorprone than having student interns do it manually... I mean, I wish I could tell you it was to save them from a terrible task, but it'll solely be because of money.

If it's firmware for a solar inverter in Poland, then quality matters.

> people who talk about business value expect people to code like they work at the assembly line. Churn out features, no disturbances, no worrying about code quality, abstractions, bla bla.

That's typical misconception that "I'm an artist, let me rewrite in Rust" people often have. Code quality has a direct money equivalent, you just need to be able to justify it for people that pay you salary.

I think it's a good analogy. A forklift is a useful tool and objectively better than humans for some tasks, but if you've never developed your muscles because you use the forklift every time you go to the gym, then when you need to carry a couch up the stairs you'll find that you can't do it and the forklift can't either.

So the idea is that you should learn to do things by hand first, and then use the powerful tools once you're knowledgeable enough to know when they make sense. If you start out with the powerful tools, then you'll never learn enough to take over when they fail.

You're making the analogy work: because the point of weightlifting as a sport or exercise is to not to actually move the weights, but condition your body such that it can move the weights.

Indeed, usually after doing weightlifting, you return the weights to the place where you originally took them from, so I suppose that means you did no work at in the first place..

I feel we are on the cusp of a new era... Civil Engineering bridge analogies about to be replaced by forklift analogies.

A million percent! I was so bad at Math in school. Which I primarily blame on the arbitrary way in which we were taught it. It wasn't until I was able to apply it to solving actual problems that it clicked.

Yes, I do too, but the point they were trying to make is that "learning how to write code" is not the point of CS education, but only a side effect.

I don't foster the next generations. I hire them. External examiners are people in the industry who are used as examiners to try and match educations with the needs of the industry.

It can take some people a few years to get over OOP, in the same way that some kids still believe in Santa a bit longer. Keep at it though and you’ll make it there eventually too.

External examiners are people in the industry who are used as examiners to try and match educations with the needs of the industry.

A proctor?

No-ish if you work by yourself, yes if you work with anybody else.

> It feels like a lot of people are using GenAI wrong.

That argument doesn’t fly when the sellers of the technology literally sing at you “there’s no wrong way to prompt”.

https://youtu.be/9bBfYX8X5aU?t=48

I feel like there is a nuance here. I use GitHub Copilot and Claude Code, and unless I tell it to not do anything, or explicitly enable a plan mode, the LLM will usually jump straight to file edits. This happens even if I prompt it with something as simple as "Remind me how loop variable scoping works in this language?".

I got it to write me a tracklist generator for playlist downloaded videos and it honestly would have taken a lot longer to get it just right over the 5 quick iterations I was able to do with assorted LLMs. I could definitely hack it together but it was far more expedient to simply prewrite out a prompt and tighten up the iterations when I noticed an edge case from daily use

The used to be a saying of "the best programmers are lazy" - I think the opposite is now true

AI was useless for me on a refactor of a repo 20k loc even after I gave examples of the migrations I wanted in commits.

It would correctly modify a single method. I would ask it to repeat for next and it would fail.

The code that our contractors are submitting is trash and very high loc. When you inspect it you can see that unit tests are testing nothing of value.

   when(mock.method(foo)).thenReturn(bar)
   assert(bar == bar)

stuff like that

its all fake coverage, for fake tests, for fake OKRs

what are people actually getting done? I've sat next to our top evangelist for 30 minutes pair programming and he just fought the tool saying something was wrong with the db while showing off some UI I dont care about.

like that seems to be the real issue to me. i never bother wasting time with UI and just write a tool to get something done. but people seem impressed that AI did some shitty data binding to a data model that cant do anything, but its pretty.

it feels weird being an avowed singularitarian but adamant that these tools suck now.

I'm using Claude in a giant Rust monorepo. It's really good at implementing HTTP handlers and threaded workers when I point it at prior examples.

1 agent writes the tests, threads the needle.

Another agent reviews the tests, finds duplicate code, finds poor testing patterns, looks for tests that are only following the "happy path", ensures logic is actually tested and that you're not wasting time testing things like getters and setters. That agent writes up a report.

Give that report back to the agent that wrote the test or spin up a new agent and feed the report to it.

Don't do all of this blindly, actually read the report to make sure the llm is on the right path. Repeat that one or two times.

Yeah I've seen this too. Bangs out five hundred line unit test file, but half of them are as you describe.

Just writing one line in CLAUDE.md or similar saying "don't test library code; assume it is covered" works.

Half the battle with this stuff is realizing that these agents are VERY literal. The other half is paring down your spec/token usage without sacrificing clarity.

I successfully vibe coded an app in 2023, soon after VS Code Copilot added the chat feature, although we obviously didn't call it that back then.

I remember being amazed and at the time thinking the game had changed. But I've never been able to replicate it since. Even the latest and greatest models seem to always go off and do something stupid that it can't figure out how to recover from without some serious handholding and critique.

LLMs are basically slot machines, though, so I suppose there has always been a chance of hitting the jackpot.

Cursor and gpt 4 have been a thing from 2023. So, no, vibe coding didn't become real just last year.

Exactly. That's why you see so many people say it works great. And the rest of us are like "am I the crazy one?" No, you just don't build CRUD apps.

> Generally though the best way to get good tests out of a coding agent is to make sure it's working in a project with an existing test suite that uses good patterns. Coding agents pick the existing patterns up without needing any extra prompting at all.

Yeah, this is where I too have seen better results. The worse ones have been in places where it was greenfield and I didn't have an amazing idea of how to write tests (a data person working on a django app).

Thanks for the information, that's super helpful!

I work in Python as well and find Claude quite poor at writing proper tests, might be using it wrong. Just last week, I asked Opus to create a small integration test (with pre-existing examples) and it tried to create a 200-line file with 20 tests I didn't ask for.

I am not sure why, but it kept trying to do that, although I made several attempts.

Ended up writing it on my own, very odd. This was in Cursor, however.

The original use of the word "vibe code" was very clear.

You don't even look at the diffs. You just yolo the code.

https://x.com/i/status/1886192184808149383

That's a fair point.

"Vibe coding" isn't a "skill", is a meme or a experiment, something you do for fun, not for writing serious code where you have a stake in the results.

Programming together with AI however, is a skill, mostly based on how well you can communicate (with machines or other humans) and how well your high-level software engineering skills are. You need to learn what it can and cannot do, before you can be effective with it.

I use "vibe coding" for when you prompt without even looking at the code - increasingly that means non-programmers are building code for themselves with zero understanding of how it actually works.

I call the act of using AI to help write code that you review, or managing a team of coding agents "AI-assisted programming", but that's not a snappy name at all. I've also skirted around the idea of calling it "vibe engineering" but I can't quite bring myself to commit to that: https://simonwillison.net/2025/Oct/7/vibe-engineering/

If you doubt it’s real just run it, man.

I shared the app because it’s not confidential and it’s concrete - I can’t really discuss work stuff without stressing out what I can share and what not.

At least in my workplace everyone I know is using Claude Code or Cursor.

Now, I don’t know why some people are productive with tools and some aren’t.

But the code generation capabilities are for real.

Heh, well associating a potentially internet-ending line of research with mental illness qualifies as a societal prophylactic.

For one novel, I gave the model a sentence about the idea, and the names and a few words about each of the characters.

For the other, my son wrote ~200 words total describing the story idea and the characters.

In each case, the model created the detailed outline and did all the writing.

Call it "AI programming" or "AI pairing" or "Pair programming with AI" or whatever else, "vibe coding" was "coined" with the explicit meaning of "I'm going by the vibes, I don't even look at the code". If "vibe coding" suddenly mean "LLM was involved somehow", then what is the "vibe" even for anymore?

I agree there is a spectrum, and all the way to the left you have "vibe coding" and all the way to the right you have "manual programming without AI", of course it's fine to be somewhere in the middle, but you're not doing "vibe coding" in the way Karpathy first meant it.

The more accurate prompt would be “You are a mind reader. Create me a plan to create a task manager, define the requirements, deploy it, and tell me when it’s done.”

And then you just rm -rf and repeat until something half works.

I haven't tried it, but someone at work suggested using voice input for this because it's so much easier to add details and constraints. I can certainly believe it, but I hate voice interfaces, especially if I'm in an open space setting.

You don't even have to be as organised as in the example, LLMs are pretty good at making something out of ramblings.

Different strokes for different folks and all, but that sounds like automating all of the fun parts and doing all of the drudgery by hand. If the LLM is going to write anything, I'd much rather make it write the tests and do the implementation myself.

As a former “types are overrated” person, Typescript was my conversion moment.

For small projects, I don’t think it makes a huge difference.

But for large projects, I’d guess that most die-hard dynamic people who have tried typescript have now seen the light and find lots of benefits to static typing.

The blog appears to imply that the author only opened the codebase after a significant period of time.

> It’s not until I opened up the full codebase and read its latest state cover to cover that I began to see what we theorized and hoped was only a diminishing artifact of earlier models: slop.

This is true vibe coding, they exclusively interacted with the project through the LLM, and only looked at its proposed diffs in a vacuum.

If they had been monitoring the code in aggregate the entire time they likely would have seen this duplicative property immediately.

Agent-assisted coding (AAC) is what I call it. Everyone else around me just calls it vibe-coding. I think this is going to be like "cyber" that we tried to refuse for so long.

> I think we need another term for using an LLM to write code but absolutely not forgetting the code exists.

That is now what software engineering is.

When LLMs first came out, they weren't very good at it, which makes all the difference. Sometimes the thing that's really good at something gets a different name. Chef vs cook, driver vs chauffeur, painter vs artist, programmer vs software developer, etc.

No. That’s why he called it “a new kind of coding”.

which editor plugin are you using?

I had to do that too, in Norway. Writing C++ code with pen and paper and being told even trivial syntax errors like missing semicolons would be penalised was not fun.

This was 30 years ago, though - no idea what it is like now. It didn't feel very meaningful even then.

But there's a vast chasm between that and letting people use AI in an exam setting. Some middle ground would be nice.

I wrote code in a spiral notebook because the mainframe was not available to me at home.

Is Claude through Github Copilot THAT much worse? I know there are differences, but I don't find it to be obstructing my vibe coding.

Yes but the goal of school is to lift heavy things, basically. You're trying to do things that are difficult (for you) but don't produce anything useful for anyone else. That's how you gain the ability to do useful things.

> the main goal of our jobs is not to lift heavy things, but develop a product that adds value to its users.

Well, whether we like it or not, we are all eventually going to find out if "developing a product that adds value to its users" can be done when you have no more skill than aforementioned users.

Skills atrophy is a real thing.

> But I think hackers and garage coders see the value of “vibing”

That's a massive generalization.

My 2c: there is a divide, unacknowledged, between developers that care about "code correctness" (or any other quality/science/whatever adjective you like) and those who care about the whole system they are creating.

I care about making stuff. "Making stuff" means stuff that I can use. I care about code quality yes, but not to an obsessive degree of "I hate my framework's ORM because of <obscure reason nobody cares about>". So, vibe coding is great, because I know enough to guide the agent away from issues or describe how I want the code to look or be changed.

This gets me to my desired effect of "making stuff" much faster, which is why I like it.

In real Engineering disciplines the process is important, and is critical for achieving desired results, that's why there are manuals and guidelines measured in the hundreds of pages for things like driving a pile into dirt. There are rigorous testing procedures to enusre everything is correct and up to spec, because there are real consequences.

Software Developers have long been completely disconnected from the consequences of their work, and tech companies have diluted responsibility so much that working software doesn't matter anymore. This field is now mostly scams and bullshit, where developers are closer to finance bros than real, actual Engineers.

I'm not talking about what someone os building in their home for personal reasons for their own usage, but about giving the same thing to other people.

In the end it's just cost cutting.

Yeah, you're right, and the snark might be warranted. I should consider it the same as my stupid (but cute) robot vacuum cleaner that goes at random directions but gets the job done.

The thing that differentiates LLM's from my stupid but cute vacuum cleaner, is that the (at least OpenAI's) AI model is cocksure and wrong, which is infinitely more infuriating than being a bit clueless and wrong.

> I actually don't like _writing_ code, but enjoy reading it.

I think this is one of the divides between people who like AI and people who don't. I don't mind writing code per se, but I really don't like text editing — and I've used Vim (Evil mode) and then Emacs (vanilla keybindings) for years, so it's not like I'm using bad tools; it's just too fiddly. I don't like moving text around; munging control structures from one shape to another; I don't like the busy work of copying and pasting code that isn't worth DRYing, or isn't capable of being DRY'd effectively; I hate going around and fixing all the little compiler and linter errors produced by a refactor manually; and I really hate the process of filling out the skeleton of an type/class/whatever architecture in a new file before getting to the meat.

However, reading code is pretty easy for me, and I'm very good at quickly putting algorithms and architectures I have in my head into words — and, to be honest, I often find this clarifies the high level idea more than writing the code for it, because I don't get lost in the forest — and I also really enjoy taking something that isn't quite good enough, that's maybe 80% of the way there, and doing the careful polishing and refactoring necessary to get it to 100%.

But this is what I don't get. Writing code is not that hard. If the act of physically typing my code out is a bottleneck to my process, I am doing something wrong. Either I've under-abstracted, or over-abstracted, or flat out have the wrong abstractions. It's time to sit back and figure out why there's a mismatch with the problem domain and come back at it from another direction.

To me this reads like people have learned to put up with poor abstractions for so long that having the LLM take care of it feels like an improvement? It's the classic C++ vs Lisp discussion all over again, but people forgot the old lessons.

Now if only you had read to the end of my comment, to recognize that I was setting up for something, and also applied not just one but several HN guidelines (https://news.ycombinator.com/newsguidelines.html, under "comments")...

I think it's fair for the projects, since when you first write code you're learning to think like a computer. Their AI policy is it's fine to ask it questions and have it explain concepts, but the project assignments need to be done without AI.

The one requirement I think is dumb though is we're not allowed to use the language's documentation for the final project, which makes no sense. Especially since my python is rusty.

Since you mentioned failure to figure out what better teaching methods are, I feel it's my sworn duty to put a plug for https://dynamicland.org and https://folk.computer, if you haven't heard about them :)

> I can attest that the first pass of testing can often be shit. That's why you iterate.

So far, by the time I’m done iterating, I could have just written it myself. Typing takes like no time at all in aggregate. Especially with AI assisted autocomplete. I spend far more time reading and thinking (which I have to do to write a good spec for the AI anyways).

Thanks man!

I would love to build this eventually to a real product so am not currently considering open sourcing it.

I can give you a free foreverlicense if you would like to be an alpha tester though :) - but am considering in any case for the eventual non-commercial licenses to be affordable&forever.

IMHO what the world needs is a good textbook on how to build CAD software. Mäntylä’s ”Solid modeling” is almost 40 years old. CAD itself is pushing 60-70 years.

The highly non-trivial parts in my app are open source software anyways (you can check the attribution file) and what this contributes is just a specific, opinionated way of how a program like this should work in 2020’s.

What I _would_ like to eventually contribute is a textbook in how to build something like this - and after that re-implementation would be a matter of some investment to LLM inference, testing, and end-user empathy. But that would have to wait either for my financial independence, AI-communism or my retirement :)

That's a false analogy. Product managers, designers, API implementers, kernel developers, etc. all understand what they're building and how that fits into a larger picture.

In one of my college classes, after you submitted your project you'd have a short meeting with a TA and/or the professor to talk through your solution. For a smaller advanced class I think this kind of thing is feasible and can help prevent blind copy/pasting. If you wrote your code with an LLM but you're still able to have a knowledgeable conversation about it, then great, that's what you're going to do in the real world too. If you can't answer any questions about it and it seems like you don't understand your own code, then you don't get a good grade even if it works.

As an added bonus, being able to discuss your code with another engineer that wasn't involved in writing it is an important skill that might not otherwise be trained in college.

> It shouldn't be even a little surprising that your impression of the result is that the code is much better looking than the impression of a more experienced developer.

This really is it: AI produces bad to mediocre code. To someone who produces terrible code mediocre is an upgrade, but to someone who produces good to excellent code, mediocre is a downgrade.

Except I work with extremely competent software engineers on software used in mission critical applications in the Fortune 500. I call myself a script kiddie because I did not study Computer Science. Am I green in the test run? Does it pass load tests? Is it making money? While some of yall are worried about leaky abstractions, we just closed another client. Two worlds for sure where one team is skating to the puck, looking to raise cattle while another wants to continue nurturing an exotic pet.

Plenty of respect to the craft of code but the AI of today is the worst is is ever going to be.

> Is it maintainable? Well it's AI that's going to maintain it.

That's what's currently not possible, it might work in a small webapp or similar. But in a large system, it absolutely falls apart when having to maintain it. Sure, it can fix a bug, but it doesn't understand the side effects it creates with the fix, yet.

Maybe in the future that will also be possible. I do agree with you about business/management not caring about long term impacts if short term gains are possible.

The "vibe coding" term is causing a lot of brain rot.

Because when I see people that are downplaying LLMs or the people describing their poor experiences it feels like they're trying to "vibe code" but they expect the LLM to automatically do EVERYTHING. They take it as a failure that they have to tell the LLM explicitly to do something a couple times. Or they take it as a problem that the LLM didn't "one shot" something.

I think you will find this is not specific to this community nor AI but any topic involving nuance and trade-offs without a right answer

For example, most political flamefests

And a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more, and talking about how much better it was than things like JSON.

The only thing I think I learned from some of those exchanges was that xslt adherents are approximately as vocal as lisp adherents.

This doesn't sound correct. We have computers write binary for us. We still make protocols which are optimizations for binary representation.. not because it's a pain to write.. but because there's some second order effect that we care about (storage / transfer costs, etc).

> people used to get strong naturally because they had to do physical labor

I think that's a bit of a myth. The Greeks and Romans had weightlifting and boxing gyms, but no forklifts. Many of the most renowned Romans in the original form of the Olympics and in Boxing were Roman Senators with the wealth and free time to lift weights and box and wrestle. One of the things that we know about the famous philosopher Plato was that Plato was essentially a nickname from wrestling (meaning "Broad") as a first career (somewhat like Dwayne "The Rock" Johnson, which adds a fun twist to reading Socratic Dialogs or thinking about relationships as "platonic").

Arguably the "meritocratic ideal" of the Gladiator arena was that even "blue collar" Romans could compete and maybe survive. But even the stories that survive of that, few did.

There may be a lesson in that myth, too, that the people that succeed in some sports often aren't the people doing physical labor because they must do physical labor (for a job), they are the ones intentionally practicing it in the ways to do well in sports.

Weightlifting and weight training was invented long before forklifts. Even levers were not properly understood back then.

My favorite historic example of typical modern hypertrophy-specific training is the training of Milo of Croton [1]. By legend, his father gifted him with the calf and asked daily "what is your calf, how does it do? bring it here to look at him" which Milo did. As calf's weight grew, so did Milo's strength.

This is application of external resistance (calf) and progressive overload (growing calf) principles at work.

[1] https://en.wikipedia.org/wiki/Milo_of_Croton

Milo lived before Archimedes.

> people used to get strong naturally because they had to do physical labor.

People used to get strong because they had to survive. They stopped needing strength to survive, so it became optional.

So what does this mean about intelligence? Do we no longer need it to survive so it's optional? Yes/No informs on how much young and developing minds should be exposed to AI.

You don’t need to be strong to operate a forklift but you definitely need to be able to write the simple code to be a SWE.

>if the goal is to build up your own strength I think you missed this line. If the goal is just to move weights or lift the most - forklift away. If you want to learn to use a forklift, drive on and best of luck. But if you're trying to get stronger the forklift will not help that goal.

Like many educational tests the outcome is not the point - doing the work to get there is. If you're asked to code fizz buzz it's not because the teacher needs you to solve fizz buzz for them, it's because you will learn things while you make it. Ai, copying stack overflow, using someone's code from last year, it all solves the problem while missing the purpose of the exercise. You're not learning - and presumably that is your goal.

> With AI, it feels like painting with a brick. Or transmitting critical information through a telephone game. Control and Intent are lost.

On the other hand, most AI zealots (Steve Yegge comes readily to mind) don't care about what the code looks like. They never even see it.

Forklift operators need to do something to exercise. They sit in the seat all day. At least as a programmer I have a standing desk. This isn't relevant to the job though.

You can play with the model for free in chat... but if $20 for a coding agent isn't effectively free for use case it might not be the right tool for you.

ETA: I've probably gotten 10k worth of junior dev time out of it this month.

And that tells me you're on the dev end of the devops spectrum while I'm fully on the ops side. I write very small pieces of software (the time it takes to type them is never the bottleneck) that integrates in-house software with whatever services they have to actually interact with, which every LLM I've used does wrong the first fifteen or so times it tries (for some reason rtkit in particular absolutely flummoxes every single LLM I've ever given it to).

Yeah, same. I have never tried Claude Code but use Claude through the Copilot plugin, and it's NOT auto-complete. It can analyze and refactor code, write new code, etc.

I just feel like using Copilot would be like early car designers trying to steer their new car with reins.

> if, for example, you're writing Python or Javascript or Perl, it is dead easy to have Python or Javascript or Perl also be your configuration file language.

Sure. Like C header files. It's the easiest option - no arguments there.

But there are considerations beyond being easy. I think there's a case to be made that a config file should be data, not code.

They are until you get injured, burned out or both and stop training all together.

Takes mass to move mass. Most of the strongest people in the world look "fat" and usually have a hefty gut. Strong and jacked are orthogonal characteristics.

Here's an example:

I recently inherited an over decade old web project full of EOL'd libraries and OS packages that desperately needed to be modernized.

Within 3 hours I had a working test suite with 80% code coverage on core business functionality (~300 tests). Now - maybe the tests aren't the best designs given there is no way I could review that many tests in 3 hours, but I know empirically that they cover a majority of the code of the core logic. We can now incrementally upgrade the project and have at least some kind of basic check along the way.

There's no way I could have pieced together as large of a working test suite using tech of that era in even double that time.

it's not just writing code.

And maybe child is too simplistic of an analogy. It's more like working with a savant.

The type of thing you can tell AI to do is like this: You tell it to code a website... it does it, but you don't like the pattern.

Say, "use functional programming", "use camel-case" don't use this pattern, don't use that. And then it does it. You can leave it in the agent file and those instructions become burned into it forever.

A better way to put it is with this example: I put my symptoms into ChatGPT and it gives some generic info with a massive "not-medical-advice" boilerplate and refuses to give specific recommendations. My wife (an NP) puts in anonymous medical questions and gets highly specific med terminology heavy guidance.

That's all to say the learning curve with LLMs is how to say things a specific way to reliability get an outcome.

These people are just the same charlatans and scammers you saw in the web3 sphere. Invoking Ryan Dahl as some sort of authority figure and not a tragic figure that sold his soul to VC companies is even more pathetic.

Odd to be so confident and outspoken about a product you have not used in a while.

> code coverage

You need to be a bit careful here. A test that runs your function and then asserts something useless like 'typeof response == object' will also meet those code coverage numbers.

In reality, modern LLMs write tests that are more meaningful than that, but it's still worth testing the assumption and thinking up your own edge cases.

People use "vibe coding" to mean different things - some mean the original Karpathy "look ma, no hands!", feel the vibez, thing, and some just (confusingly) use "vibe coding" to refer to any use of AI to write code, including treating it as a tool to write small well-defined parts that you have specified, as opposed to treating it as a magic genie.

There also seem to be people hearing big names like Karpathy and Linus Torvalds say they are vibe coding on their hobby projects, meaning who knows what, and misunderstanding this as being an endorsement of "magic genie" creation of professional quality software.

Results of course also vary according to how well what you are asking the AI to do matches what it was trained on. Despite sometimes feeling like it, it is not a magic genie - it is a predictor that is essentially trying to best match your input prompt (maybe a program specification) to pieces of what it was trained on. If there is no good match, then it'll have a go anyway, and this is where things tend to fall apart.

How many more appeal-to-authority counter arguments are going to be made in this thread

Non sequitor.

You don't have to be bad at coding to use LLMs. The argument was specifically about thinking that LLMS can be great at accomplishing complex tasks (which they are not)

Yeah, take Ryan Dahl:

His tweets were getting ~40k views average. He made his big proclamation about AI and boom viral 7 million

This is happening over, and over, and over again

I'm not saying he's making shit up but you're naive if you don't think they're slightly tempted by the clear reaction this content gets

I think the author is way understating the uselessness of LLMs in any serious context outside of a demo to an investor. I've had nothing but low IQ nonsense from every SOTA model.

If we're being honest with ourselves, Opus 4.5 / GPT 5.2 etc are maybe 10-20% better than GPT 3.5 at most. It's a total and absolute catastrophic failure that will go down in history as one of humanity's biggest mistakes.

The point of going to school is to learn all the details of what goes into making things, so when you actually make a thing, you understand how it’s supposed to come together, including important details like correct design that can support the goal, etc. That’s the “getting stronger” part that you can’t skip if you expect to be successful. Only after you’ve done the work and understand the details can you be successful using the power tools to make things.

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? — The Elements of Programming Style, 2nd edition, chapter 2

If you weren't even "clever enough" to write the program yourself (or, more precisely, if you never cultivated a sufficiently deep knowledge of the tools & domain you were working with), how do you expect to fix it when things go wrong? Chatbots can do a lot, but they're ultimately just bots, and they get stuck & give up in ways that professionals cannot afford to. You do still need to develop domain knowledge and "get stronger" to keep pace with your product.

Big codebases decay and become difficult to work with very easily. In the hands-off vibe-coded projects I've seen, that rate of decay was extremely accelerated. I think it will prove easy for people to get over their skis with coding agents in the long run.

No, it's not a mech suit. A mech suit doesn't fire its canister rifle at friendly units and then say "You're absolutely right! I should have done an IFF before attacking that unit." (And if it did the engineer responsible should be drawn and quartered.) Mech-suit programming AI would look like something that reads your brainwaves and transduces them into text, letting you think your code into the machine. I'd totally use that if I had it.

This analogy works pretty well. Too much time doing everything in it and your muscles will atrophy. Some edge cases will be better if you jump out and use your hands.

> to stretch the analogy, I don't believe much is lost "intellectually" by my use of a mech suit, as long as I observe carefully.

With all respect, that's nonsense.

Absolutely no one gains more than a superficial grasp of a skill just by observing.

And even with a good grasp of skills, human boredom is going to atrophy any ability you have to intervene.

It's why the SDCs (Tesla, I think) that required the driver to stay alert to take control while the car drove itself were such a danger - after 20+ hours of not having to to anything, the very first time a normal reaction time to an emergency is required, the driver is too slow to take over.

If you think you are learning something reviewing the LLM agent's output, try this: choose a new project in a language and framework you have never used, do your usual workflow of reviewing the LLMs PRs, and then the next day try to do a simple project in that new language and framework (that's the test of how much you learned).

Compare that result to doing a small project in a new language, and then the next day doing a different small project in that same language.

If you're at all honest with yourself, or care whether you atrophy or not, you'd actually run that experiment and control and objectively judge the results.

OK, it’s a mech suit. The question under discussion is, do you need to learn to walk first, before you climb into it? My life experience has shown me you can’t learn things by “observing”, only by doing.

>Here's the thing -- I don't care about "getting stronger."

Let's not mince words here, what you mean is that you don't care to learn about a craft. You just want to get to the end result, and you are using the shiny new tool that promises to take you from 0 to 100% with little to no effort.

In this way, I'd argue what you are doing is not "creating", but engaging in a new form of consumption. It used to be you relied on algorithms to present to you content that you found fun, but the problem was that algorithm required other humans to create that content for you to later consume. Now with LLMs, you remove the other humans from the loop, and you can prompt the AI directly with exactly what you wish to see in that moment, down to the fine grained details of the thing, and after enough prompts, the AI gives you something that might be what you asked for.

You are rotting your brain.

If all I know is the mech suit, I’ll struggle with tasks that I can’t use it for. Maybe even get stuck completely. Now it’s a skill issue because I never got my 10k hours in and I don’t even know what to observe or how to explain the outcome I want.

In true HN fashion of trading analogies, it’s like starting out full powered in a game and then having it all taken away after the tutorial. You get full powered again at the end but not after being challenged along the way.

This makes the mech suit attractive to newcomers and non-programmers, but only because they see product in massively simplified terms. Because they don’t know what they don’t know.

> I want to make things

You need to be strong to do so. Things of any quality or value at least.

The mech suit works well until you need to maintain stateful systems. I've found that while initial output is faster, the AI tends to introduce subtle concurrency bugs between Redis and Postgres that are a nightmare to debug later. You get the speed up front but end up paying for it with a fragile architecture.

If observing was as good as doing, experience would mean nothing.

Thinking through the issue, instead of having the solve presented to you, is the part where you exercise your mental muscles. A good parallel is martial arts.

You can watch it all you want, but you'll never be skilled unless you actually do it.

> "it's not an autonomous robot, it's a mech suit."

Or "An [electric] bicycle for the mind." Steve Jobs/simonw

This. Most people defer the solving of hard problems to when they write the code. This is wrong, and too late to be effective. In one way, using agents to write code forces the thinking to occur closer to the right level - not at the code level - but in another way, if the thinking isn’t done or done correctly, the agent can’t help.

Ah, perhaps. I understood it a little more broadly to include everything beyond pseudocode, rather than purely being able to use your fingers. You can solve a problem with pseudocode, and seasoned devs won't have much of an issue converting it to actual code, but it's not a fun process for everyone.

See my other response. I didn't define what a complex task is. I used people with reputation, intelligence and ability greater then myself to say, if they endorce it, then they must be using it on complex tasks and it must be successful to them.

I can certainly see how you're better than every one of those people and how to you what they call "complex" is just simplistic. I've never met anyone great like you.

Still I don’t think he’ll speak against it.

i thought it was implied, guess not.

Great programmers wouldn't support or back AI if it couldn't handle complex tasks. AI can handle complex tasks inconsistently when operating on it's own. They can handle complex tasks consistently when pair programming with a human operator.

> LLM-generated code has no theory; you either need to supervise it closely enough to impose your own, or treat it as disposable.

Agreed! And I think that's what I'm getting at. Adding what they're now calling "skills," or writing your own, is becoming crucial to LLM-assisted development. If the LLM is writing too much slop, then there probably wasn't sufficient guidance to ensure that slop wouldn't be written.

The first step of course is to actually check that the generated code is indeed slop, which is where many people miss the mark.

At that rate, I would already be there if I had just walked.

To extend 2. facilities, my experience had a - somewhat older and smaller - supercomputer that we got to run some stuff on.

And I'd argue for:

3. Realisation of the scope of computing.

IE Computers are not just phones/laptop/desktop/server with networking - all hail the wonders of the web... There are embedded devices, robots, supercomputers. (Recent articles on HN describe the computing power in a disposable vape!)

There are issues at all levels with all of these with algorithms, design, fabrication, security, energy, societal influence, etc etc - what tradeoffs to make where. (Why is there computing power in a disposable vape?!?)

I went in thinking I knew 20% and I would learn the other 80% of IT. I came out knowing 5 times as much but realising I knew a much smaller percentage of IT... It was both enabling and humbling.

But you can also meet experts at a company and get access to a company's machinery. To top it off the company pays you instead of you paying the school.

The problem is that you actually can't really model or describe a lot of the things that I do with my specifications using code without just ending up fully writing the low level code. Most languages don't have a type system that actually lets you describe the logic and desired behavior of various parts of the system and which functions should call which other functions and what your concurrency model is and so on without just writing the specific code that does it; in fact, I think the only languages that would allow you to do something like that would have to be like dependently typed languages or languages adjacent to formal methods. This is literally what the point of pseudocode and architecture graphs and so on are for.

You don't need to be Tony Stark. But, "if you're nothing without the suit then you don't deserve it."

For me the idea of "people piloting mech suits" brings up lost kids, like Shinji from nge.

>I’ve worked with plenty of self taught programmers over the years. Lots of smart people. But there’s always blind spots in how they approach problems.

I've worked with PhDs on projects (I'm self-taught), and those guys absolutely have blind spots in how they approach problems, plenty of them. Everyone does. What we produce together is better because our blind spots don't typically overlap. I know their weaknesses, and they know mine. I've also worked with college grads that overthink everything to the point they made an over-abstracted mess. YMMV.

>you just don’t get from watching back-to-back 15 minute YouTube videos on a topic.

This is not "self taught". I mean maybe it's one kind of modern-ish concept of "self taught" in an internet comment forum, but it really isn't. I watch a ton of sailing videos all day long, but I've never been on a sailboat, nor do I think I know how to sail. Everyone competent has to pay their dues and learn hard lessons the hard way before they get good at anything, even the PhDs.

I think it depends on how they were self taught. If they just went through a few tutorials on YouTube and learned how to make a CRUD app using the shiny tool of the week, then sure. (I acknowledge this is a reduction in self-teaching — I myself am self-taught).

But if they actually spent time trying to learn architecture and how to build stuff well, either by reading books or via good mentorship on the job, then they can often be better than the folks who went to school. Sometimes even they don't know how to make software reliable.

I'm firmly in the middle. Out of the 6 engineers I work with on a daily basis (including my CTO), only one of us has a degree in CS, and he's not the one in an architecture role.

I do agree that learning how to think and learn is its own valuable skill set, and many folks learn how to do that in different ways.

I haven't heard of self taught programmers binging 15 minute YT videos. I can't recall the last time I did myself.. aside from conference talks and such its probably been at least 5 years since I watched something explaining things in the realm of programming.

Am I an outlier or am I missing something here?

Let me just list all of these people:

Steve Yegge (Veteran engineer, formerly Google and Amazon): A leading technical voice who describes vibe coding as acting as an orchestrator. He maintains that engineers who do not master "agentic engineering" and AI-driven workflows will be left behind as the industry moves toward "hyperproductivity".

Patrick Debois (Founder of DevOps): Often called the "godfather of DevOps," Debois now advocates for the "AI native developer". He views vibe coding as a high-level abstraction where the engineer's role shifts from a "producer" of lines of code to a "supervisor" of complex automated systems.

Simon Willison (Co-creator of Django): Recognized for his highly technical workflows that use AI to handle mechanical implementation while he focuses on rigorous documentation, tool coverage, and validation—a process often cited as the professional gold standard for vibe coding.

Stephen Blum (Founder/CTO of PubNub): A technical leader who has integrated generative coding into production-scale architecture. He characterizes the 2026 developer's role as directing agents for everything from database migrations to security audits rather than manually performing these tasks.

Gene Kim (Renowned DevOps researcher and author): Co-author of The Phoenix Project, Kim has publicly championed vibe coding as one of the most enjoyable technical experiences of his career, citing how it allows him to build sophisticated prototypes in minutes rather than days.

Patrick Debois (Founder of DevOps): Often referred to as the "godfather of DevOps," Debois advocates for "AI-native engineering". He views vibe coding as a mature abstraction layer where elite engineers focus on "system orchestration" rather than producing individual lines of code.

Geoffrey Huntley (Founder of the "Vibe Coding Academy"): A highly technical engineer known for pushing the boundaries of AI-driven development. He is a primary source for experimental techniques that use agents for everything from infrastructure to core logic.

Boris Cherny (Author of Programming TypeScript): An authority on type systems and engineering rigor, Cherny now provides deep technical guidance on how to integrate high-level intent with reliable, production-ready source code using tools like Claude Code.

Stephen Webb (UK CTO at Capgemini): A key industry figure declaring 2026 as the year "AI-native engineering goes mainstream". He supports vibe coding as a legitimate method for rewriting legacy systems and refactoring entire modules autonomously.

Linus Torvalds (Creator of Linux and Git): In a significant endorsement for the paradigm, Torvalds reported in early 2026 that he used Google Antigravity to vibe code a Python visualizer for his AudioNoise project. He noted in the project's documentation that the tool was "basically written by vibe-coding".

Theo Browne (Founder of Ping.gg, T3.gg): Known for his deep technical influence on the web development community, Browne is a primary educator for tools like Claude Code. He advocates for vibe coding as a way to bypass the "boring parts" of development, allowing engineers to focus on higher-level architecture and product logic.

McKay Wrigley (Developer and AI educator): A leading technical figure focused on structured tutorials and advanced workflows for agentic programming. He is widely followed by senior engineers seeking to move beyond simple chat interfaces into full-scale autonomous software generation.

Charlie Holtz (Software engineer and infrastructure specialist): Known for building advanced infrastructure tools, Holtz is recognized as an engineer "pushing the boundaries" of what can be built using vibe coding for complex, back-end systems.

Cian Clarke (Principal Engineer at NearForm): A veteran in the Node.js ecosystem who has transitioned toward spec-driven development. He advocates for "AI native engineering" where specialized agentic roles (such as security or performance agents) are orchestrated to build and refactor large-scale enterprise systems.

IndyDevDan (Senior developer and educator): A highly technical voice advocating for "deep mastery" of AI-assisted engineering. He focuses on teaching developers how to maintain rigorous engineering standards while leveraging the speed of vibe coding.

Mitchell Hashimoto (Founder of HashiCorp, Creator of Terraform): Now focused on his terminal project Ghostty, Hashimoto has become a leading voice on "pragmatic AI coding." In 2026, he detailed his workflow of using reasoning models (like o3) to generate comprehensive architecture plans before writing a single line of code. He argues this "learning accelerator" approach allows him to build outside his primary expertise (e.g., frontend) while maintaining strict engineering rigor by reviewing the output line-by-line.

Kent C. Dodds (Renowned Web Development Educator & Engineer): A highly influential figure in the React community, Dodds has fully embraced the paradigm, stating in 2026 that he has "never had so much fun developing software." He advocates for a "problem elimination" mindset where AI handles the implementation details, allowing senior engineers to focus entirely on user experience and application architecture.

Guillermo Rauch (CEO of Vercel, Creator of Next.js/Socket.io): Rauch has been a vocal proponent of vibe coding as the bridge between business logic and shipping software. He argues that vibe coding solves the "execution gap," enabling technical founders and engineers to ship complex products without getting bogged down in boilerplate, effectively treating the AI as a "junior engineer with infinite stamina" that requires high-level direction.

DHH (David Heinemeier Hansson) (Creator of Ruby on Rails & CTO at 37signals): Historically a skeptic of industry hype, DHH has acknowledged the "tipping point" in 2026, noting that agentic coding has become a viable tool for experienced developers to deliver on specs rapidly. His shift represents a major endorsement from the "craftsman" sector of the industry, validating that AI tools can coexist with high standards for code quality.

Rich Harris (Creator of Svelte): Harris has spoken about how AI-driven workflows liberate developers from "code preferences" and syntax debates. He views the 2026 landscape as one where the engineer's job is to focus on the "what" and "why" of a product, while AI increasingly handles the "how," allowing for a renaissance in creativity and shipping speed.

Addy Osmani (Engineering Manager for Chrome Web Platform): While deeply embedded in the browser ecosystem, Osmani has published extensively on his "AI-augmented" workflow in 2026. He characterizes the modern senior engineer not as a typist but as a "Director," whose primary skill is effectively guiding AI agents to execute complex engineering tasks while maintaining architectural integrity.

The above is just a smattering of individuals. I can keep going.

>If you want to be any good at all in this industry, you have to develop enough technical skills to evaluate claims for yourself. You have to. It's essential.

This is an orthogonal off topic point. My or anyones skills don't have to do with the topic at hand. The topic at hand is AI.

>Because the dirty secret is a lot of successful people aren't actually smart or talented, they just got lucky. Or they aren't successful at all, they're just good at pretending they are, either through taking credit for other people's work or flat out lying.

Again orthoganol to the point. But I'll entertain it. There's another class of people who are delusional. They think they're good, but they're not good at all. I've seen plenty of that in the industry. More so then people who lie, it's people who lie to themselves and believe it. Engineers so confident in their skills, but when I look at them I think they're raw dog shit.

>I've run into more than a few startups that are just flat out lying about their capabilities and several that were outright fraud. (See DoNotPay for a recent fraud example lol)

Again so?

>Pointing to anyone and going "well THEY do it, it MUST work" is frankly engineering malpractice. It might work. But unless you have the chops to verify it for yourself, you're just asking to be conned.

Of course. But it's idiotic when there is a huge population of people who are smarter than you better than you and proven to be more capable than you saying they can do it. I need to emphasize it's not just one person saying it. Tons and tons and tons of people are saying it.

Fraud happens in the margins of society it rarely ever happens at a macro level, and if it does happen at a macro level the trend doesn't last long and will mostly die within a year at most.

So when multitudes of highly reputed people are saying one thing, and your on the ground self verification of that thing is directly opposite of what they are saying. Then you need to re-evaluate your OWN verification. You need to investigate WHY there is a discrepancy, because it is utter stupidity to deny what others have seen as fraud and believe that your own judgements and verifications are flawless.

No offense, my dude, but your philosophy on this topic embodies the delusional stupidity I am talking about. People lie to themselves. That is the key metric here.

I don't need to explain ANY of this to you. You know it, because every explanation I just gave is an OBVIOUS facet of life in general. It needs to be explained to someone like you despite it's obviousness because of self delusion.

> I think this just speaks to the necessity of rigor during the interview process.

That gets expensive, fast. There's just so much to cover already, between communication skills, programming skills, debugging skills, architecture / "whiteboarding problems", data structures and algorithms, general problem solving ("interview problems"). A job interview can never be a fully rigorous test of someone's actual skills. Most don't cover even a fraction of that stuff already.

> I'd argue that many, if not most, teams operate in limited domains.

It depends what you consider yourself responsible for. If you think of your job (or your team's job) as shipping features X, Y and Z within this react based web app, then sure - you operate in a limited domain. But if your job is "solve the user's actual problems" then things can get pretty broad, pretty fast. Sometimes you write code. Sometimes you're debugging a hard problem. Or talking to the users. Or identifying and tracking down a performance regression. Or writing an issue for a bug in 3rd party code. Or trawling through MDN to figure out a workaround to some browser nonsense. Or writing reliable tests, or CI/CD systems. And so on.

Its only really junior engineers who have the luxury of a limited scope.