It's just a lot faster at hammering it out than me pound for pound, and I can quickly rattle off via voice-to-text exactly what I want much faster than I can type all of the code (especially when across a few different files), in a huge majority of tasks I perform. It's also especially good at debugging by brute force quickly and at scale meaning e.g. it can start desperately bisecting diffs to find the source of a bug 10000% faster than I can.
Disagree with so many assertions put forth here. You don't _have_ to turn you brain off when coding with an LLM. It's not some intelligence dementor. If your brain turned off while you were vibe coding thats honestly just a you problem and I wish everyone would stop boogeymanning an obvious improvement in the ability to better yourself just because a lot of people don't choose the betterment route.
I've never been more informed or understood more about my code, pipelines, and stack than now- and its 100% due to AI reasoning about my projects, and me making an effort to learn.
The people struggling with this most are also the ones that never got to grips with human delegation either.
At least in my circle it's the classic leads/seniors (that predate the scrum "everyone's the same" thing) that are managing to get the most real mileage out of this.
It's clear to me now that the lack of benchmarks for competence in this space means everyone thinks they're geniuses who don't need a better process, because apparently their workflow "works for them."
Not sure what to say to any of this, because it's not even really related to the article except to say the assumption is supposedly completely wrong. That doesn't make sense to me, because as soon as AWS or something important goes down everyone immediately blames vibe coding.
So which is it? Is process completely solved here ("just get gud"), or is coding with agents causing problems?
But when you lead there’s a level of trust in the people who are going to implement. You may still have a high level view of what’s going on, but that’s different from sweating the details. It also is different from bottoms up building those details where consequences become clear in thought.
I’ve noticed the pressure to keep velocity and move forward means I’m less sure of those details compared to before. LLMs are also inconsistent in the work they do - some of it is brilliant, other parts are idiotic. It’s totally different than what you’d get when leading humans.
> But when you lead there’s a level of trust in the people who are going to implement.
"Trust but verify". This is why you have QA processes, testing, checklists etc. All the sanity checks that got thrown away in the web tech rush pre-AI.
You state this as if the only way you personally would manage this would be to craft each line yourself after deep contemplation, which may be true for you.
But it's not a universal at all. You have to apply engineering thinking to human and LLM organization, and part of the damage caused by scrum has been to ignore this entirely. How can you produce a system where you can bound the output to be what is understood? It must be possible because managers all over the earth do it all the time.
> You don't _have_ to turn you brain off when coding with an LLM. It's not some intelligence dementor. If your brain turned off while you were vibe coding
You have too, because that's the definition of vibe coding. If you use an LLM to assist you, but still keep your brain on, that's not vibe coding.
That's the definition I am aware of, yes. It's also in the term, that you let a vibe (a force coming from the outside) decide what your work lead to, as opposed as to deciding where it should arrive at and leading into that direction.
> I've never been more informed or understood more about my code, pipelines, and stack than now...
Would you mind clarifying if this includes code, pipelines, stacks, etc... on which many other people are simultaneously working on in a group setting? Or are these all things that you alone are working on as an individual?
My experience has been that AI makes me tremendously more productive as an individual working alone. Put 20 people (all empowered by AI) on a project however, and it quickly falls to shit.
I've running local models; before having a coding harness, i'd basically do the same misteps the AI does; add the same logging lines, and trace with the errors are, etc. This was exhausting so no docs and tests were rarely if ever created.
Now, to actually get the AI to do anything complex, it's basically required to both write docs and write tests because solidifying behavior only works when there's AI tests it can run to verify some behavior I've verified once.
Then there's things I'm never going to remember the AI had to do; recenly it was "blitting" to /dev/fb0 and it was trying to remember which encoding was which and what order, etc. Things I simply do not want to have to get a detail account of nor is it something I need to remember above the statement "some video drivers have their own RGB, BGR encoding standards" and "an image has a bit depth and size" etc.
These things I would have learned doing it myself, but I would also had to learn where it all breaks and how to interoperate between pillow and video drivers, etc. If I ever do this again, i'll still point the LLM at it with or without this library, and it'll do the same abstract reasoning.
So my knowledge is compact because I don't need to know the implementation for this video display code; I just need the tests and docs and I'll point the LLM at it if I need to extend it.
I have not worked on a project with 20 AI-assisted contributors. I have worked on a team with 4. While smaller, I can already see that the code churn, and conflict resolution is more a kin to a larger team. However, we also have been introspective about how we can interoperate with these new disruptive tools -- ritualizing the LLM's ability to create and maintain documentation and perform code reviews has been indispensable. Perhaps 20 on a project is unsustainable, and even unnecessary.
This is like saying if you stop exercising just because you are driving everywhere then it is a you problem. On an individual level it may be useful advice, but on a societal level we see how it plays out — rising obesity rates and children shut in bedrooms with their screens. It turns out if you stop getting exercise from your daily routines, many people will just not get any exercise at all!
Of course you can make a conscious effort to keep using your brain while you vibe code. But if you have to consciously exercise your brain then it means the people, who are lazy on average, will just not do that and let their thinking deteriorate instead. We already see what happens if we let students "learn with AI." It turned out they would rather just let AI do their homework than become more informed about their course material. I don't see how software engineering will fair any better.
The thing is out of the bottle, can't stop it. I am neither pro or against, but it's here. Ducking uppercuts and rope-a-dope-ing is defeatist. Software engineering has been romanticized, it's not glamorous anymore it's not Halt & Catch Fire days. There is nothing new anymore, just a quicker way to CRUD. The next is elsewhere else.
Everything is happening quicker and we see it in real time.
You're not wrong, but there are levels to understanding.
For example, when studying maths or physics, it is very common to feel like you've understood everything, until you get to the exercises, and need to apply that understanding, and it's only then that you consolidate the knowledge and begin to truly understand in depth.
I like AI enhanced coding, but I do sometimes worry that we're not getting enough of that depth anymore.
Even at a basic level when asking the AI how to do something in a new language, sure it saves time, but I no longer have to manually scan documentation and get the incidental discovery of "oh, that function also exists, cool" which then sticks in my memory for later.
It's like using SparkNotes for classic novels, there's value in the friction of having to wrestle with the source material yourself. Whether that's more valuable than what the AI brings to the table I'm not sure yet.
You're technically right on your first point, but I think this is missing a broader issue... this entire technology incentivises its users to put as little effort (and cognitive effort, at that -- so, thought) as possible to go from a vague idea of something they want to a somewhat-working thing. That's how it's being sold, that's how it's being marketed, and that's how it's arguably being built from an interface point-of-view.
Is it possible to use it in a more involved way? Certainly. I try to do that. But it's challenging, because ultimately even taking a more collaborative approach, this thing puts out a lot of slop, and then I have to deal with going over the output and just spending most of my day in code review mode vs an author that doesn't ever learn from feedback.
The most frustrating thing for me beyond the feedback black hole is that when things do inevitably go wrong, trying to point out the concrete issue and instructing the LLM to do better around it is challenging; a lot of the time directives (even those in a global CLAUDE.md!) are just ignored either outright or as the context grows, or fail to be passed down to subagents; negative prompts are discouraged because of the pink elephant effect, so I have to jump through hoops to try and frame a "never do $thing" constraint as an affirmative prompt (which is then often ignored). That aside, english is a godawful language for specifying things compared to programming languages. It's just a really frustrating experience overall.
I agree, so many things to disagree in the article.
However, I think you are missing that people are lazy. We all are to some extent, some more than others. Putting effort in doing something, well, takes effort. In my experience most people given the opportunity to do a mediocre job turning their brain off or an excellent job at the expense of great brain effort, they would take the former. And this is happening left, right and center now with LLMs.
And the skill atrophy is real, or at least, I am witnessing it real time on a bunch of coworkers.
I agree with you, you don't HAVE to turn your brain off and produce slop, but people do. And at scale, it diminishes greatly the impact of the self-improvement that you, or a minimal subset of developers are doing.
> If your brain turned off while you were vibe coding thats honestly just a you problem
No. There are multiple studies showing that skills atrophy is an actual thing. If your brain does not turn off while you are vibe-coding, keep it up and it soon will.
I never said you have to turn your brain off to feel the limitations.
Actually, for more complex work I think it's pretty common to spend a long time crafting some elaborate prompt, and then arguing with the agent for 10-20 turns, getting a "passable" plan, accepting it then arguing with the agent every step of the way because it's doing it wrong. It's incredibly frustrating, even with models like Fable.
Even after that, I'll often find out during later sessions that some feature that was supposed to be deprecated was actually silently left in "because I wasn't sure you wanted it completely gone" or something.
I agree that exploring a codebase through prompts is actually quite nice! But the mental model you get from that is almost always warped - you have to supplement that with reading the code, where 9 times out of 10 you will find some kind of discrepancy that you're unhappy with.
Your experience is night-and-day from mine. Both myself and the AI correct and remove each other's gaps in understanding. There is never what I would call arguing. Disagreements are resolved by back and forth discussion and reaching consensus.
This sounds like not the best workflow. If your prompt is that long, you may not be spending your time very efficiently.
Splitting problems into smaller problems is huge. You want a concrete idea that you still own. Only tell an agent to do something you know it can nail - this will likely be one subsystem. The subsystems and how they talk is on you.
I agree, I tend to give a high-level concept for what I want done first, and then break it into smaller tasks. That said, there's almost always a misunderstanding within the smaller tasks anyway, which I have to test to find out about, then ask the agent to fix.
This does not match my experience at all. I use Fable as an orchestrator, and describe the end goal I want to achieve. It investigates the current state of affairs, and determines the smaller work units needed. We discuss each one, and eventually ticket it out in Linear. By that point, each ticket has all the relevant details, scope, decisions and acceptance criteria.
Then I have it write prompts for implementation agents based on the ticket. These agents are almost always Opus, except for the most complex issues. The prompts contain broader contextual details (like what other tickets might be worked on in parallel, the boundaries, operational/environment constraints, and so on). Each implementation agent starts in plan mode and uses a skill I created called "super plan". Super plan has the agent write the plan and then have it adversarially reviewed by three subagents, and hardened based on their feedback. I then read that plan and greelight it. Once the agent is done with the implementation, it then uses three subagents to do a code review of different aspects (like test quality, regression risk, security, etc.) and incorporate the changes. Then it does a live QA in the browser (if there are UI changes) to make sure the feature has good UX and the UI works as expected at different breakpoints and so on.
Then the Fable orchestrator does one last code review and gives a ship/no-ship verdict, along with a 1-10 rating.
This works incredibly well, and is almost completely hands off. I make all the major decisions and review the results. I never find myself "arguing" with the orchestrator. I might sometimes get frustrated at the implementation agent but that's mostly for UI fidelity issues and honestly pretty rare these days.
So like I get what you're saying but an LLM helping you code is just a personal search engine/autocomplete.
"Vibe coding" to me and others is just going "claude program me a wife that didn't leave with the kids and make no mistakes" and just rawdogging the output.
I agree- I'm currently trying to learn how I can embed a fine tuned tiny model into my c++ game so it can provide a narrative in prose of certain game-event logs. It needs to be as tiny as possible so it doesn't take resources away from the running game.
> I agree- I'm currently trying to learn how I can embed a fine tuned tiny model into my c++ game so it can provide a narrative in prose of certain game-event logs.
Unless your game states have combinatoral exlosion, would it not be better to generate all of that pre-build? If templated you can generate a few hundreds of thousands of templates to use for any circumstance, then instantiate and stitch together those templates during the game runtime.
There are a bunch of tutorials on how to use GRPO to fine tune a small Qwen. Depending what you're doing LoRA or even just prefix tuning can give pretty good results with no special hardware.
> How small a model are we talking? Don't even the smallest models which would work need gigabytes of memory?
I dunno, for game prose I expect that a tiny highly quantized model would be sufficient (generating no more than a paragraph), so 300MB - 500MB maybe? Running on CPU not GPU is feasible too, I think.
I was maintainer of the Chess app from the early 2000s to about 2015. We first noticed in 2004 that level 1 (which was then "Computer thinks for 1 second per move) was getting stronger with each hardware generation (and in fact stronger than myself).
So we introduced 3 new levels, with the Computer thinking 1, 2, or 3 moves ahead. This solved the problem of the engine getting stronger (though the jump from "3 moves ahead" to "1 second" got worse and worse).
A few years after I had handed off the project, somebody decided to meddle with the level setting code (I was not privy to that decision). The time based levels were entirely replaced with depth based levels (which eliminates the strength inflation problem, but unfortunately was not accompanied by UI changes). But for some reason, parsing of the depth setting was broken as well, so the engine now always plays at depth 40 (stronger than ever).
This should be an easy fix, if Apple gets around to make it (Chess was always a side project for the maintainers). I filed feedback report 21609379.
I found a used copy of Warcraft 3 at the store about ten years after it came out, proudly brought it home, fired it up and didn’t recall the graphics being quite that awful, but the first time I tried to scroll the map sideways it shot to the far end because they didn’t build a timing loop onto the animation and I shut it down, disappointed.
Unfortunately they never released a remastered version of it. They seem to have made some clone of it called “reforged” whatever the fuck that means.
Reforged was received poorly because it was a lazy half assed job that was a blatant cash grab. Not because culturally we have moved on and the game has aged beyond being fun
You probably knew this, but wanted to make sure others knew that the reason they ended the franchise is not because there was no market, but instead it was pure unadulterated greed that led to that situation. In an alternate reality they would have actually done the remake justice and there would be a lively competitive scene
There are various hacks and tools for games (especially DOS games, but for W3 there may exist the same) which delayloop various calls to slow things down enough "to work".
The Dolphin emulator has run into similar things; usually doing things "too fast" just gets you more FPS but sometimes it causes the game to go insane.
This is pretty much the experience of trying to play any game from the '90s on modern hardware. It always requires a bit of tinkering and usually a patch from the modding community. Funniest one I've found is Fallout Tactics. The random encounter frequency is somehow tied to clock speed so you'll basically get hit with random encounters during map travel about once every half second.
I've been enjoying Total Annihilation since 1997. Still works fine on fairly modern hardware with Windows 11. No modifications other than some additional maps that I downloaded decades ago.
Sorry if this is a dumb question but did you patch it to the latest version? I don't know if the in-game updater still works but from memory you could download some sort of patch exe file and update it that way.
The original Wing Commander was like that. Playable on 286s/386s, then Pentiums and beyond showed up and it was unplayable. The game started in the "simulator" to show you the controls, and you'd get blown out of space in about 0.5 seconds.
The original Wing Commander brings back memories! I remember being amazed by the graphics and the story.
These days I cannot stand games with cliched storyline and tend to skip the cutscenes, but back then it all seemed so amazing... like a cross between a movie and a game.
I remember playing it later and running into speed issues too, but usually there was a way to tweak the emulator in order to fix this.
> they didn’t build a timing loop onto the animation
Wow.
1984 (!!!) IBM PC (DOS) port of the game Alley Cat had timings built it. They actually used the system clock if I remember correctly, so it would always run at the correct pace no matter how fast the computer. Last I checked it, decades later, it still ran at the correct speed!
AFAIK the only reason Chess even ships at all anymore is as a burn utility. They'll set it to AI vs AI at max difficulty to stress the system and make sure the cooling/power management works.
Never heard that one (it may indeed be used that way, but if it were the only reason Apple would probably keep it in the Apple internal parts of their OS installs).
It would also be of limited use, as the engine is purely CPU based; it is single threaded and does not even use SIMD AFAIK, let alone GPU features or the neural engines.
GN is a well established, popular and independent consumer hardware reviewer that has only a few peers on par with them in the space. Hardly some "random tech influencer".
Yeah, Paris Hilton and others are also established and popular, hardly makes them a source of authority. If you publish clickbait on YouTube to add fuel to drama, you're unfortunately digging your own hole and it shouldn't come as a surprise others consider you "random influencers who peddle drama".
I wouldn't listen to Paris Hilton talk about computer hardware, and I wouldn't listen to Gamer Nexus talk about who has the hottest hair in Hollywood. Flip those around though, and that's different.
I gave it a 20 minutes try, since it seems not just one person is convinced this Gamer Nexus isn't just another influencer. They seem knowledgeable about hardware, I give you that. But then when they start going into markets, economies and geopolitics, that's when I start roll my eyes, and continuing listening to that is like taking hardware advice from Paris Hilton.
Again, don't let influencers give you the idea that just because they happen to know topic X well, they suddenly know all the areas and subjects that are slightly related to those areas well too.
Yeah, wasn’t impressed with GN’s theories about the politics/motivations/etc behind these big market shifts. It’s much simpler, there’s limited supply capacity and a more lucrative use of the hardware now. The market will find a new equilibrium.
I just spent a lot of yesterday tweaking a docker image with xfce and vs code so I can just let codex go full access mode without too much worry in a throwaway sandbox. The agent runs similarly-namespace-constrained and without sudo. I think it's a relatively safe middleground- do you really think container escape is still a big deal here?
Finally getting this setup also allowed me to very quickly troubleshoot what was breaking my build in the codex cloud hosted container which obviously has even less risk attached.
Now I'm juggling and strategizing branches like coding is an RTS game... and it feels like a super power. It's almost like unlocking an undiscovered tech tree.
I think that completely discounting the potential of new emergent capabilities at scale undermines this thesis significantly. We don't know until someone tries, and there is compelling evidence that there's still plenty of juice to squeeze out of both scale and engineering.
reply