Breaking the spell of vibe coding(fast.ai) |
Breaking the spell of vibe coding(fast.ai) |
https://fortune.com/2026/01/29/100-percent-of-code-at-anthro...
Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via the products they are now giving almost entirely to coding agents.
If you had midas touch would you rent it out?
https://sequoiacap.com/podcast/training-data-openai-imo/
The thing however is the labs are all in competition with each other. Even if OpenAI had some special model that could give them the ability to make their own Saas and products, it is more worth it for them to sell access to the API and use the profit to scale, because otherwise their competitors will pocket that money and scale faster.
This holds as long as the money from API access to the models is worth more than the comparative advantage a lab retains from not sharing it. Because there are multiple competing labs, the comparative advantage is small (if OpenAI kept GPT-5.X to themselves, people would just use Claude and Anthropic would become bigger, same with Google).
This however may not hold forever, it is just a phenomena of labs focusing more on heavily on their models with marginal product efforts.
Of course at a certain point, you have to wonder if it would be faster to just type it than to type the prompt.
Anyways, if this was true in the sense they are trying to imply, why does Boris still have a job? If the agents are already doing 100% of the work, just have the product manager run the agents. Why are they actively hiring software developers??
And people claiming it's a lie are in for a rough awakening. I'm sure we will see a lot of posters on HN simply being too embarrassed to ever post again when they realize how off they were.
It’s not. It’s either 33% slower than perceived or perception overestimates speed by 50%. I don’t know how to trust the author if stuff like this is wrong.
Likewise those people are guaranteeing "AI"s obsolesence. The parrots need humans to feed them.
When someone vibe-codes a project, they typically pin whatever dependency versions the LLM happened to know about during training. Six months later, those pinned versions have known CVEs, are approaching end-of-life, or have breaking changes queued up. The person who built it doesn't understand the dependency tree because they never chose those dependencies deliberately — the LLM did. Now upgrading is harder than building from scratch because nobody understands why specific libraries were chosen or what assumptions the code makes about their behavior.
This is already happening at scale. I work on tooling that tracks version health across ecosystems and the pattern is unmistakable: projects with high AI-generation signals (cookie-cutter structure, inconsistent coding style within the same file, dependencies that were trendy 6 months ago but have since been superseded) correlate strongly with stale dependency trees and unpatched vulnerabilities.
The "flow" part makes it worse — the developer feels productive because they shipped features fast. But they're building on a foundation they can't maintain, and the real cost shows up on a delay. It's technical debt with an unusually long fuse.
I wonder if there's something similar going on here.
By not going through this process, you loose intent, familiarity, and opinions.
It's the exact same as vibe-coding.
Sure. But the converse is true as well: consider the case where you don't learn the AI tooling and AI does improve apace.
That is also gambling your career. Are you ready for pointed questions being asked about why you spent 2 days working on something that AI can do in 15 minutes, so be prepared with some answers for that.
What is there to learn, honestly? People act like it's learning to write a Linux driver.
The maximum knowledge you need how to write a plan or text file. Maybe throw in a "Plz no mistakes"
There's no specific model, a better one comes out every month, everything is stochastic.
With all due respect, that answer shows that you don't know enough about agentic coding to form an opinion on this.
Things to learn:
- What agent are you going to use?
- What skills are you going to use?
- What MCPs are you going to use?
- What artifacts are you going to provide beyond the prompt?
- How are you going to structure it so the tooling can succeed without human interaction?
- Are you going to use agent orchestration and if so which?
- Are you going to have it "ultrathink" or not?
- Are you going to use a PRD or a checklist or the toolings own planning?
- Which model or combination of models are you going to use today? (Yes, that changes)
- Do you have the basic English (or whatever) skills to communicate with the model, or do you need to develop them? (I'm seeing some correlations between people with poor communication skills and those struggling with AI)
Was this actually a failed prediction? A article claiming with 0 proof that it failed is not good enough for me. With so many people generating 100% of their code using AI. It seems true to me.
The current Claude Code setup with Opus 4.6 and their Max subscription (the 100 USD one was enough for me, don't need the 200 USD one) was enough for me to do large scale refactoring across 3 codebases in parallel. Maybe not the most innovative or complex tasks in absolute terms, but it successfully did in one day what would have taken regular developers somewhere between 1 and 2 weeks in total.
I hate to be the anecdote guy, but with the current state of things, I have to call bullshit on the METR study, there is no world in which I work slower with AI than without. Maybe with the Cerebras Code subscription where it fucked some code up and I had to go back to it and fix it twice, but that's also because Vue had some component wrapping and SFC/TypeScript bullshit going on which was honestly disgusting to work on, but that's because you really need the SOTA models. The current ones are good enough for me even if they never improved further.
I never want to go back to soul sucking boilerplate or manual refactoring. It works better than I can alone. It works better than my colleagues can. I think I might just suck, maybe I'm cooked because at this point I mostly just guide and check it and sometimes do small code examples for what I want and explore problems instead of writing all of it myself, but honestly a lot of work was done in JetBrains IDEs previously where there's also lots of helpful snippets, autocomplete, code inspections and so on, so who knows - maybe it doesn't matter that I write everything line by line myself.
Which frankly describes pretty much all real world commercial software projects I've been on, too.
Software engineering hasn't happened yet. Agents produce big balls of mud because we do, too.
Maybe they need to start handing out copies of the mythical man month again because people seem to be oblivious to insights we already had a few decades ago
Note: the study used sonnet-3.5 and sonnet-3.7; there weren’t any agents, deep research or similar tools available. I’d like to see this study done again with:
1. juniors ans mid-level engineers
2. opus-4.6 high and codex-5.2 xhigh
3. Tasks that require upfront research
4. Tasks that require stakeholder communication, which can be facilitated by AI
I’d be thrilled if that AI could finally make one of our most annoying stakeholders test the changes they were so eager to fast track, but hey, I might be surprised.
Of course, all of that can be done by humans, too. But this discussion is about average speed of a developer, and there’s a reason many companies employ product owners for the stakeholder communication.
HN often bring up that quote pretty quickly whenever author of an article is perceived to be bias one way or another. I’m surprised it hasn’t been mentioned in the comments here.
She's not wrong.
A good way to do this calculation is with the log-ratio, a centered measure of proportional difference. It's symmetric, and widely used in economics and statistics for exactly this reason. I.e:
ln(1.2/0.81) = ln(1.2)-ln(0.81) ≈ 0.393
That's nearly 40%, as the post says.
It’s more obvious if you take more extreme numbers, say: they estimated to take 99% less time with AI, but it took 99% more time - the difference is not 198%, but 19900%. Suddenly you’re off by two orders of magnitude.
Still an interesting observation. It was also on brown field open source projects which imo explains a bit why people building new stuff have vastly different experiences than this.
But personally: yes and to an immense degree. The excuse “we don’t have the time for this” has pretty much evaporated when it comes to me. I do more than colleagues do and have gotten enough automation working that the AI will be made to iterate and fix its code to my desires before I ever see a line of it. I’ve added tests to entire systems thanks to it, fixed bugs across the codebase, added a bunch of additional quality control scripts and tools, improved CI, built and shipped not only entire features but systems. I can now work on about 3 projects in parallel, even if it can be super tiring.
But hey, I’m also working more on side projects outside of work and nice utilities I never had time for. I don’t really build in public sadly, but it very much is a force multiplier and makes me hate my job less sometimes (everyone has a horrible brownfield codebase or two).
I find that satisfying.
you still need good swes to distinguish if the generated code is good or bad and adjust the agent and plan the system
ime opus is smart enough to oneshot medium to small features by learning the existing codebase provided you give it the business context
I use codex almost everyday, none of that is necessary unless you're trying to flatten up your resume.
It's micro services all over again, a concept useful for some very select organisations, that should've been used carefully turned into a fad every engineer had to try shoe horn into their stack.
This is a perfect example of what I'm saying. You'd bet that, because you don't have enough experience with the tooling to know when you need more than a "standard instance of existing tool"
Here's a real-world case: Take some 20 year old Python code and have it convert "% format" strings to "f strings". Give that problem to a generic Claude Code setup and it will produce some subtle bugs. Now set up a "skill" that understands how to set up and test the resulting f-string against the %-format, and it will be able to detect and correct errors it introduces, automatically. And it can do that without inflating the main context.
Many of those items I mention are at their core about managing context. If you are finding Claude Code ends up "off in the weeds", this can often be due to you not managing the context windows correctly.
Just knowing when to clear context, when to compact context, and when to preserve context is a core component of successfully using the AI tooling.
A pretty basic Claude Code or Codex setup and being mindful of context handling goes a long way. Definitely long enough to be able to use AI productively while not spending much time on configuring the setup.
Staying on top of all details is not necessary but in fact counter productive, trust me.
Using skills, multiple models, MCPs and agent teams is significantly improving the results I'm seeing in real world problems.
You haven't really given me any reason why I should trust you, but I'll tell you it's going to be hard for me to trust advice that contradicts my test results.
Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astounding that CEOs haven't made that connection yet).
The latter, you may be less productive than optimal, but might the hands-on training and fundamental understanding of the codebase make up for it in the long run?
Additionally, I personally find my best ideas often happen when knee deep in some codebase, hitting some weird edge case that doesn't fit, that would probably never come up if I was just reviewing an already-completed PR.
In the early days, the interfaces were so complex and technical, that only engineers could use them.
Some of these early musicians were truly amazing individuals; real renaissance people. They understood the theory, and had true artistic vision. The knew how to ride the tiger, and could develop great music, fairly efficiently.
A lot of others, not so much. They twiddled knobs at random, and spent a lot of effort, panning for gold dust. Sometimes, they would have a hit, but they wasted a lot of energy on dead ends.
Once the UI improved (like the release of the Korg M1 sampler), then real artists could enter the fray, and that’s when the hockey stick bent.
Not exactly sure what AI’s Korg M1 will be, but I don’t think we’re there, yet.
It's like saying if you don't learn to use a smartphone you'll be left behind. Even babies can use it now.
I think if you orient your experimentation right you can think of some good tactics that are helpful even when you're not using AI assistance. "Making this easier for the robot" can often align with "making this easier for the humans" as well. It's a decent forcing function
Though I agree with the sentiment. People who have been doing this for less than a year convinced that they have some permanent lead over everyone.
I think a lot about my years being self taught programming. Years spent spinning my wheels. I know people who after 3 months of a coding bootcamp were much further than me after like ... 6 years of me struggling through material.
I don't have that skill; I find that if I'm using AI, I'm strongly drawn toward the lazy approach. At the moment, the only way for me to actually understand the code I'm producing is to write it all myself. (That puts my brain into an active coding/puzzle solving state, rather than a passive energy-saving state.)
If I could have the best of both worlds, that would be a genuine win, and I don't think it's impossible. It won't save as much time as pure vibe coding promises to, of course.
I can confidently say that being able to prompt and train LoRAs for Stable Diffusion makes zero difference for your ability to prompt Nano Banana.
There's a dissonance I see where people talk about using AI tools leading to an atrophy of their abilities to work with code, but then expecting that they need no mastery to be able to use the AI tooling.
Will the AI tooling become so much better that you need little to no mastery to use it? Maybe. Will those who have a lot of fundamentals developed over years of using the tooling still be better with that tooling than the "newbs"? Maybe.
Until then, I keep up and add my voice to the growing number who oppose this clear threat on worker rights. And when the bubble pops or when work mandates it, I can catch up in a week or two easy peasy. This shit is not hard, it is literally designed to be easy. In fact, everything I learn the old way between now and then will only add to the things I can leverage when I find myself using these things in the future.
People write long prompts primarily to convince themselves that they're casting some advanced spell. As long as the system prompt is good you should start very simply and only expand if results are unsatisfactory.
It is strange because the tech now moves much faster than the development of human expertise. Nobody on earth achieved Sonnet 3.5 mastery, in the 10k hours sense, because the model didn't exist long enough.
Prior intuitions about skill development, and indeed prior scientifically based best practices, do not cleanly apply.
Oooh, let me dive in with an analogy:
Screwdriver.
Metal screws needed inventing first - they augment or replace dowels, nails, glue, "joints" (think tenon/dovetail etc), nuts and bolts and many more fixings. Early screws were simply slotted. PH (Philips cross head) and PZ (Pozidrive) came rather later.
All of these require quite a lot of wrist effort. If you have ever screwed a few 100 screws in a session then you know it is quite an effort.
Drill driver.
I'm not talking about one of those electric screw driver thingies but say a De W or Maq or whatever jobbies. They will have a Li-ion battery and have a chuck capable of holding something like a 10mm shank, round or hex. It'll have around 15 torque settings, two or three speed settings, drill and hammer drill settings. Usually you have two - one to drill and one to drive. I have one that will seriously wrench your wrist if you allow it to. You need to know how to use your legs or whatever to block the handle from spinning when the torque gets a bit much.
...
You can use a modern drill driver to deploy a small screw (PZ1, 2.5mm) to a PZ3 20+cm effort. It can also drill with a long auger bit or hammer drill up to around 20mm and 400mm deep. All jolly exciting.
I still use an "old school" screwdriver or twenty. There are times when you need to feel the screw (without deploying an inadvertent double entendre).
I do find the new search engines very useful. I will always put up with some mild hallucinations to avoid social.microsoft and nerd.linux.bollocks and the like.
This framing is exactly how lots of people in the industry are thinking about AI right now, but I think it's wrong.
The way to adopt new science, new technology, new anything really, has always been that you validate it for small use cases, then expand usage from there. Test on mice, test in clinical trials, then go to market. There's no need to speculate about "too much" or "too little" usage. The right amount of usage is knowable - it's the amount which you've validated will actually work for your use case, in your industry, for your product and business.
The fact that AI discourse has devolved into a Pascal's Wager is saddening to see. And when people frame it this way in earnest, 100% of the time they're trying to sell me something.
My theory is that executives must be so focused on the future that they develop a (hopefully) rational FOMO. After all, missing some industry shaking phenomenon could mean death. If that FOMO is justified then they've saved the company. If it's not, then maybe the budget suffers but the company survives. Unless of course they bet too hard on a fad, and the company may go down in flames or be eclipsed by competitors.
Ideally there is a healthy tension between future looking bets and on-the-ground performance of new tools, techniques, etc.
Testing medical drugs is doing science. They test on mice because it's dangerous to test on humans, not to restrict scope to small increments. In doing science, you don't always want to be extremely cautious and incremental.
Trying to build a browser with 100 parallel agents is, in my view, doing science, more than adopting science. If they figure out that it can be done, then people will adopt it.
Trying to become a more productive engineer is adopting science, and your advice seems pretty solid here.
This is fair. And what I've been doing it. I still mostly code the way I've always coded. The AI stuff is mostly for fun. I haven't seen it transformatively speed me up or improve things.
So I make that assessment, cool. But then my CEO lightly insists every engineer should be doing AI coding because it's the future and manual coding is a dead end towards obsolescence. Uh oh now I gotta AI-signal for the big guy up top!
You're neglecting the cost of testing and validation. This is the part that's quite famous for being extremely expensive and a major barrier to developing new therapies.
I notice that I get into this automatically during AI-assisted coding sessions if I don't lower my standards for the code. Eventually, I need to interact very closely with both the AI and the code, which feels similar to what you describe when coding manually.
I also notice I'm fresher because I'm not using many brainscycles to do legwork- so maybe I'm actually getting into more situations where I'm getting good ideas because I'm tackling hard problems.
So maybe the key to using AI and staying sharp is to refuse to sacrifice your good taste.
That said, maybe it's not a big deal. Kind of like way back when I moved from C++ to GC code, I remember I missed memory leaks, because having it all automatically taken care of for free felt like giving up control and encouraging of lazy practices and loose ends. Turns out it wasn't really a big deal at all.
When people talk about this stuff they usually mean very different techniques. And last months way of doing it goes away in favor of a new technique.
I think the best you can do now is try lots of different new ways of working keep an open mind
Note, if staying on the bleeding edge is what excites you, by all means do. I'm just saying for people who don't feel that urge, there's probably no harm just waiting for stuff to standardize and slow down. Either approach is fine so long as you're pragmatic about it.
Using LLMs to generate documentation for the code that I write, explaining data sheets to me, and writing boilerplate code does save me a lot of time, though.
Another good alike wager I remember is: “What if climate change is a hoax, and we invested in all this clean energy infrastructure for nothing”.
There is zero evidence that LLM's improve software developer productivity.
Any data-driven attempts to measure this give ambivalent results at best.
It's both. It's using the AI too much to code, and too little to write detailed plans of what you're going to code. The planning stage is by far the easiest to fix if the AI goes off track (it's just writing some notes in plain English) so there is a slot-machine-like intermittent reinforcement to it ("will it get everything right with one shot?") but it's quite benign by comparison with trying to audit and fix slop code.
How's that? If it ever gets good, it seems rather implausible that today's tool-of-the-month will turn out to be the winner.
that's nowhere near guaranteed
You think it's going to get harder to use as time goes on?
I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled, Domain-Driven Design, Implementing Domain-Driven Design, Design Patterns, The Art of Agile Software Development, 2nd Edition, Clean Architecture, Smalltalk Best Practice Patterns, and Tidy First?. I'm a far better software engineer than I was in 2024. I've also vibe coded [1] a whole lot of software [2], some good and some bad [3].
You can choose to grow in both areas.
[0]: https://kerrick.blog/articles/2025/kerricks-wager/
[1]: As defined in Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond by Gene Kim and Steve Yegge, wherein you still take responsibility for the code you deliver.
The initial speed is exactly what the article describes, a Loss Disguised as a Win.
Thank you for not using an LLM.
It helps formalise your plan, then creates some code, you review, talk about what you believe to be wrong or asking it why it took that approach, or even telling it to take the approach that you want.
The end result a world of difference, and I feel I have a better grasp of what is going on in the whole application.
I would have thought sanity checking the output to be the most elementary next step.
A lot of the time the issue isn't actually the code itself but larger architectural patterns. But realizing this takes a lot of mental work. Checking out and just accepting what exists, is a lot easier but misses subtleties that are important.
So vibers may be assuming the AI is as reliable, or at least can be with enough specs and attempts.
"Fixing defects down the road during testing costs 15x as much as fixing them during design, according to research from the IBM System Science Institute."
The workflow that seems more perilous is the one where the developer fires up gas town with a vague prompt like "here's my crypto wallet please make me more money". We should be wielding these tools like high end anime mech suits. Serialized execution and human fully in the loop can be so much faster even if it consumes tokens more slowly.
I have like 15 personalized apps now, mostly chrome extensions
I use AI for the mundane parts, for brainstorming bugs. It is actually more consistent than me in covering corner cases, making sure guard conditions exist etc. So I now focus more on design/architecture and what to build and not minutea.
The technology is accelerating. Hard projects from early last year are now trivial for me. Even AI related tools we are using internally are being made redundant from open source models and new frameworks (eg. OpenClaw).
It feels like we are in the AI version of "Don't look up". Everyone is on borrowed time, you should be looking at how to position yourself in an AI world before everyone realises.
People seem to think that just because it produces a bunch of code you therefore don’t need to read it or be responsible for the output. Sure you can do that, but then you are also justifying throwing away all the process and thinking that has gone into productive and safe software engineering over the last 50 years.
Have tests, do code reviews, get better at spec’ing so the agent doesn’t wing it, verify the output, actively curate your guardrails. Do this and your leverage will multiply.
- AI creating un-opinionated summaries of PRs to help me get started reviewing
- AI being an interactive tutor while I’ll still do the hard work of learning something new [1]
- AI challenging my design proposal QA style, making me defend it
- boilerplate and clear refactorings, while I’ll build the abstractions
[1] https://www.dev-log.me/jokes_on_you_ai_llms_for_learning/
But I think this only works is because I have a decade of experience in basically every field in the programming space and I had to learn it all without AI. I know exactly what I want from AI where opus 4.6 and codex 5.3 understands that and executes on it faster than I could ever write.
But yes, I usually constrain my plans to one function, or one feature. Too much and it goes haywire.
I think a side benefit is that I think more about the problem itself, rather than the mechanisms of coding.
Not sure why we'd want a tool that generates so much of this for us.
idk what ya'll are doing with AI, and i dont really care. i can finally - fiiinally - stay focused on the problem im trying to solve for more than 5 minutes.
Like I don’t remember syntax or linting or typos being a problem since I was in high school doing Turbo Pascal or Visual Basic.
I've never had problems with any of those things after I learned what a code editor was.
If you keep some for yourself, there’s a possibility that you might not churn out as much code as quickly as someone delegating all programming to AI. But maybe shipping 45,000 lines a day instead of 50,000 isn’t that bad.
The people on the start of the curve are the ones who swear against LLMs for engineering, and are the loudest in the comments.
The people on the end of the curve are the ones who spam about only vibing, not looking at code and are attempting to build this new expectation for the new interaction layer for software to be LLM exclusively. These ones are the loudest on posts/blogs.
The ones in the middle are people who accept using LLMs as a tool, and like with all tools they exercise restraint and caution. Because waiting 5 to 10 seconds each time for an LLM to change the color of your font, and getting it wrong is slower than just changing it yourself. You might as well just go in and do these tiny adjustments yourself.
It's the engineers at both ends that have made me lose my will to live.
The real value isn't in "vibe coding" everything from scratch - it's in having the right architecture and patterns that AI can work within. That's why I built VCSK (Vibe Coding Starter Kit) - it gives you a solid NextJS foundation with proven patterns, then you can vibe code features on top of that foundation.
The difference is architectural discipline. When you start with proper auth, DB setup, deployment pipeline, and component structure, AI becomes incredibly productive for building features. When you ask AI to architect everything from scratch, you get the dead-end architectures you mentioned.
I still write the critical business logic by hand, still review every PR, and still understand the codebase deeply. But for UI components, API endpoints that follow established patterns, and data transformations? AI is genuinely faster than manual coding now.
The key insight: "vibe coding" isn't a replacement for engineering judgment - it's a force multiplier when you have the foundation right.
Fortunately, I've retired so I'm going focus on flooding the zone with my crazy ideas made manifest in books.
Back in 2020, GPT-3 could code functional HTML from a text description, however it's only around now that AI can one-shot functional websites. Likewise, AI can one-shot a functional demo of a saas product, but they are far from being able to one-shot the entire engineering effort of a company like slack.
However, I don't see why the rate of improvement will not continue as it has. The current generation of LLM's haven't been event trained yet on NVidia's latest Blackwell chips.
I do agree that vibe-coding is like gambling, however that is besides the point that AI coding models are getting smarter at a rate that is not slowing down. Many people believe they will hit a sigmoid somewhere before they reach human intelligence, but there is no reason to believe that besides wishful thinking.
That's the nature of all tech, it keeps not being good enough, until it is, and then everything changes.
Like if the only possible issues were property damage, I kind of think it would be here. You just insure the edge cases.
The differences are subtle but those of us who are fully bought in (like myself) are working and thinking in a new way to develop effectively with LLMs. Is it perfect? Of course not - but is it dramatically more efficient than the previous era? 1000%. Some of the things I’ve done in the past month I really didn’t think were possible. I was skeptical but I think a new era is upon us and everyone should be hustling to adapt.
My favorite analogy at the moment is that for awhile now we’ve been bowling and been responsible for knocking down the pins ourselves. In this new world we are no longer the bowlers, rather we are the builders of bumper rails that keep the new bowlers from landing in the gutter.
Going straight into dev mode with an LLM pretty much always goes wrong - a lot more time is spent in planning and in setting up constraints for how an agent can operate before letting it loose so that once you set it free it can run.
She unfortunately lost me at the first sentence. I cannot get business value out of that, so I don't do that at work.
What I can do is design a situation where I can get business value out of having the AI agent do one thing where the details are too annoying/boring for me to do. Then I read the PR and I decide if the parts about where the data comes from, how it is massaged, etc are right. Then I scan over the HTML and CSS templating garbage I have no interest in and then I post the PR for review.
This is exactly the opposite of what she's talking about, and it's working great for me and my colleagues.
Not everyone who plays slot machines is worse off — some people hit the jackpot, and it changes their life. Also, the people who make the slot machines benefit greatly.
I think there are a ton of people just pulling the lever over and over, instead of stepping back and considering how they should pull the lever. When you step back and consider this, you are for sure going to end up falling deeper into the engineering, architecture realm. Ensuring that continually pulling the lever doesn't result in potential future headaches.
I think a ton of people in this community are struggling with the lose of flow state, and attempting to still somehow enter it through prompting. The game in my view has just changed, its more about just generating the code, and being thoughtful about what comes next, its rapid usage of a junior to design your system, and if you overdue the rapidness the junior will give you headaches.
No, it's different from other skills in several ways.
For one, the difficulty of this skill is largely overstated. All it requires is basic natural language reading and writing, the ability to organize work and issue clear instructions, and some relatively simple technical knowledge about managing context effectively, knowing which tool to use for which task, and other minor details. This pales in comparison with the difficulty of learning a programming language and classical programming. After all, the entire point of these tools is to lower the required skill ceiling of tasks that were previously inaccessible to many people. The fact that millions of people are now using them, with varying degrees of success for various reasons, is a testament of this.
I would argue that the results depend far more on the user's familiarity with the domain than their skill level. Domain experts know how to ask the right questions, provide useful guidance, and can tell when the output is of poor quality or inaccurate. No amount of technical expertise will help you make these judgments if you're not familiar with the domain to begin with, which can only lead to poor results.
> might be useful now or in the future
How will this skill be useful in the future? Isn't the goal of the companies producing these tools to make them accessible to as many people as possible? If the technology continues to improve, won't it become easier to use, and be able to produce better output with less guidance?
It's amusing to me that people think this technology is another layer of abstraction, and that they can focus on "important" things while the machine works on the tedious details. Don't you see that this is simply a transition period, and that whatever work you're doing now, could eventually be done better/faster/cheaper by the same technology? The goal is to replace all cognitive work. Just because this is not entirely possible today, doesn't mean that it won't be tomorrow.
I'm of the opinion that this goal is unachievable with the current tech generation, and that the bubble will burst soon unless another breakthrough is reached. In the meantime, your own skills will continue to atrophy the more you rely on this tech, instead of on your own intellect.
You'll probably be forming some counter-arguments in your head.
Skip them, throw the DDD books in the bin, and do your co-workers a favour.
But it should be a philosophy, not a directive. There are always tradeoffs to be made, and DDD may be the one to be sacrificed in order to get things done.
And it seemed pretty clear to me that they would have to do with the sort of evergreen, software engineering and architecture concepts that you still need a human to design and think through carefully today, because LLMs don't have the judgment and a high-level view for that, not the specific API surface area or syntax, etc., of particular frameworks, libraries, or languages, which LLMs, IDE completion, and online documentation mostly handle.
Especially since well-designed software systems, with deep and narrow module interface, maintainable and scalable architectures, well chosen underlying technologies, clear data flow, and so on, are all things that can vastly increase the effectiveness of an AI coding agent, because they mean that it needs less context to understand things, can reason more locally, etc.
To be clear, this is not about not understanding the paradigms, capabilities, or affordances of the tech stack you choose, either! The next books I plan to get are things like Modern Operating Systems, Data-Oriented Design, Communicating Sequential Processes, and The Go Programming Language, because low level concepts, too, are things you can direct an LLM to optimize, if you give it the algorithm, but which they won't do themselves very well, and are generally also evergreen and not subsumed in the "platform minutea" described above.
Likewise, stretching your brain with new paradigms — actor oriented, Smalltalk OOP, Haskell FP, Clojure FP, Lisp, etc — gives you new ways to conceptualize and express your algorithms and architectures, and to judge and refine the code your LLM produces, and ideas like BDD, PBT, lightweight formal methods (like model checking), etc, all provide direct tools for modeling your domain, specifying behavior, and testing it far better, which then allow you to use agentic coding tools with more safety or confidence (and a better feedback loop for them) — at the limit almost creating a way to program declaratively in executible specifications, and then convert those to code via LLM, and then test the latter against the former!
https://www.amazon.com/Learning-Domain-Driven-Design-Alignin...
It presents the main concepts like a good lecture and a more modern take than the blue book. Then you can read the blue book.
But DDD should be taken as a philosophy rather than a pattern. Trying to follow it religiously tends to results in good software, but it’s very hard to nail the domain well. If refactoring is no longer an option, you will be stuck with a non optimal system. It’s more something you want to converge to in the long term rather than getting it right early. Always start with a simpler design.
That's most code when you're still working on it, no?
> Also, multiple agents can run at once, which is a workflow for many developers. The work essentially doesn't come to a pausing point.
Yeah the agent swarm approach sounds unsurvivably stressful to me lol
Thanks for the recommendation!
There are deeper considerations like why pull the lever, or is it the correct lever? So many api usages is either seeing someone using a forklift to go the gym (bypassing the point), using it to lift a cereal box (overpowered), or using it to do watchmaking (very much the wrong tool).
Programming languages are languages, yes. But we only use them for two reasons. They can be mapped down to hardware ISA and they’re human shaped. The computer doesn’t care about the wrong formula as long as they can compute it. So it falls on us to ensure that the correct formula is being computed. And a lot of AI proponents is trying to get rid of that part.
Addiction occurs because as humans we bond with people but we also bond with things. It could be an activity, a subject, anything. We get addicted because we're bonded to it. Usually this happens because we're not in fertile grounds to bond with what we need to bond with (usually a good group of friends).
When I look at addicted people a lot of them bond with people that have not so great values (big house, fast cars, designer clothing, etc.), adopt those values themselves and get addicted to drugs. This drugs is usually supplied by the people they bond with. However, they bond with those people in the first place because of being aimless and receiving little guidance in their upbringing.
I'm just saying all that to make it more concrete with what I mean about "good people".
Back to LLMs. A lot of us are bonding with it, even if we still perceive it as an AI. We're bonding with it because when it comes to certain emotional needs, they're not being fulfilled. Enter a computer that will listen endlessly to you and is intellectually smarter than most humans, albeit it makes very very dumb mistakes at times (like ordering +1000 drinks when you ask for a few).
That's where we're at right now.
I've noticed I'm bonded with it.
Oh, and to some who feel this opinion is a bit strong, it is. But consider that we used to joke that "Google is your best friend" when it just came out and long thereafter. I think there's something to this take but it's not fully in the right direction I think.
> I don't have that skill; I find that if I'm using AI, I'm strongly drawn toward the lazy approach. At the moment, the only way for me to actually understand the code I'm producing is to write it all myself. (That puts my brain into an active coding/puzzle solving state, rather than a passive energy-saving state.)
When I review code, I try to genuinely understand it, but it's a huge mental drain. It's just a slog, and I'm tired at the end. Very little flow state.
Writing code can get me into a flow state.
That's why I pretty much only use LLMs to vibecode one-off scripts and do code reviews (after my own manual review, to see if it can catch something I missed). Anything more would be too exhausting.
An alternative that occurred to me the other day is, could a PR be broken down into separate changes? As in, break it into a) a commit renaming a variable b) another commit making the functional change c) ...
Feel like there are PR analysis tools out there already for this :)
https://m.youtube.com/watch?v=Ra25c8-3I6w
It's a bit unusual to describe a disk utility's UI as absolute kino, but it fits for X-Copy. To understand X-Copy is to understand the Amiga.
or, perhaps, in the same way that google-fu over time became devalued as a skill as Google became less useful for power users in order to cater to the needs of the unskilled, it will not really be a portable skill at all, because it is in the end a transitory or perhaps easily attainable skill once the technology is evenly distributed.
Everything is temporary to some extent.
But... I guess nowadays you can be vague and it'll get the gist of it.
Everything slows down eventually. What makes you think this won't?
The closest parallel I can think of is javascript frameworks. The 2010s had a new framework out every week. Lots of people (somewhat including myself) wasted a ton of time trying to keep up with the churn, imagining that constantly being on the bleeding edge was somehow important. The smart ones just picked something reasonably mature and stuck with it. Eventually things coalesced around React. All that time trying to keep up with the churn added essentially no value.
I have noticed a troubling skill atrophy in some people who heavily use LLMs (this is particularly concerning because it renders them incompetent to review ‘their own’ PRs prior to submission). I’m… not keen to sign up for that for no reason, tbh.
Using nano banana does not require arcane prompt engineering.
People who have not learnt image prompt engineering probably didn't miss anything.
The irony of prompt engineering is that models are good at generating prompts.
Future tools will almost certainly simply “improve” you naive prompt before passing it to the model.
Claude already does this for code. Id be amazed if nano banana doesnt.
People who invested in learning prompt engineering probably picked up useful skills for building ai tools but not for using next gen ai tools other people make.
Its not wasted effort; its just increasingly irrelevant to people doing day-to-day BAU work.
If the api prevents you from passing a raw prompt to the model, prompt engineering at that level isnt just unnecessary; its irrelevant. Your prompt will be transformed into an unknown internal prompt before hitting the model.
Nano Banana is actually a reasoning model so yeah it kinda does, but not in the way one might assume. If you use the api you can dump the text part and it's usually huge (and therefore expensive, which is one drawback of it. It can even have "imagery thinking" process...!)
They're focused no the short-term future, not the long-term future. So if everyone else adopts AI but you don't and the stock price suffers because of that (merely because of the "perception" that your company has fallen behind affecting market value), then that is an issue. There's no true long-term planning at play, otherwise you wouldn't have obvious copypcat behavior amongst CEOs such as pandemic overhiring.
The real profits are the companies selling them chips, fiber, and power.
Thats staying power, suddenly that lease isnt a lease, its an ongoing cost for as long as that system exists. its gas.
A simple plan -> task breakdown + test plan -> execute -> review -> revise (w/optional loops) pipeline of agents will drastically cut down on the amount of manual intervention needed, but most people jump straight to the execute step, and do that step manually, task by task while babysitting their agent.
Boot time.
Understandability. A Z80 processor was a lot more understandable than today's modern CPUs. That's worse.
Complexity. It's great that I can run python on a microcontroller and all, but boring old c was a lot easier to reason about.
Wtf is a typescript. CSS is the fucking worst. Native GUI libraries are so much better but we decided those aren't cool anymore.
Touchscreens. I want physical buttons that my muscle memory can take over and get ingrained in and on. Like an old stick shift car that you have mechanical empathy with. Smartphones are convenient as all hell, but I can't drive mine after a decade like you can a car you know and feel, that has physical levers and knobs and buttons.
Jabber/Pidgin/XMPP. There was a brief moment around 2010? when you didn't have to care what platform someone else was using, you could just text with them on one app. Now I've got a dozen different apps I need to use to talk to all of my friends. Beeper gets it, but they're hamstrung. This is a thing that got worse with computers!
Ever hear of wirths law? https://en.wikipedia.org/wiki/Wirth%27s_law
Computers are stupid fast these days! why does it take so long to do everything on my laptop? my mac's spotlight index is broken, so it takes it roughly 4 seconds to query the SQLite database or whatever just so I can open preview.app. I can open a terminal and open it myself in that time!
And yes, these are personal problems, but I have these problems. How did the software get into such a state that it's possible for me to have this problem?
A godsend.
> Native GUI libraries are so much better but we decided those aren't cool anymore.
Lolno.
CPU vulnerability mitigations make my computer slower than when I bought it.
Computers and laptops are increasingly not repairable. So much ewaste is forced on us for profit.
The internet is a corporate controlled prison now. Political actors create fake online accounts to astroturf, manipulate, and influence us.
The increasing cost of memory and GPU make computers no longer affordable.
There's a good reason that most successful examples of those tools like openspec are to-do apps etc. As soon as the project grows to 'relevant' size of complexity, maintaining specs is just as hard as whatever other methodology offers. Also from my brief attempts - similar to human based coding, we actually do quite well with incomplete specs. So do agents, but they'll shrug at all the implicit things much more than humans do. So you'll see more flip-flopped things you did not specify, and if you nail everything down hard, the specs get unwieldy - large and overly detailed.
That's a rather short-sighted way of putting it. There's no way that the spec is anywhere as unwieldly as the actual code, and the more details, the better. If it gets too large, work on splitting a self-contained subset of it to a separate document.
I disagree - the spec is more unwieldy, simply by the fact of using ambiguous language without even the benefit of a type checker or compiler to verify that the language has no ambiguities.
But also, you don't have to upgrade every iteration. I think it's absolutely worthwhile to step off the hamster wheel every now and then, just work with you head down for a while and come back after a few weeks. One notices that even though the world didn't stop spinning, you didn't get the whiplash of every rotation.
At the end of the day, it doesn’t matter if a cat is black or white so long as it catches mice.
——
Ive also found that picking something and learning about it helps me with mental models for picking up other paradigms later, similar to how learning Java doesn’t actually prevent you from say picking up Python or Javascript
The AI will get better at compensating, but I think some of it's weaknesses are fundamental, and are going to be showing up in some form or another for a while yet
Ex, the AI doesn't know about what you don't tell it. There's a LOT of context we take for granted while programming (especially in a corporate environment). Recognizing what sort of context is useful to give the AI without distracting it (and under what conditions it should load/forget context), I think is going to be a very valuable skill over the next few years. That's a skill you can start building now
I know how to get Claude multi-agent mode to write 2,500 lines of deeply gnarly code in 40 minutes, and I know how to get that code solid. But doing this absolutely pulls on decades on engineering skill. I read all the core code. I design key architectural constraints. I invest heavily in getting Claude to build extensive automated verification.
If I left Claude to its own devices, it would still build stuff! But with me actively in the loop, I can diagnose bad trends. I can force strategic investments in the right places at the right times. I can update policy for the agents.
If we're going to have "software factories", let's at least remember all the lessons from Toyota about continual process improvement, about quality, about andon cords and poke-yoke devices, and all the rest.
Could I build faster if I stopped reading code? Probably, for a while. But I would lose the ability to fight entropy, and entropy is the death of software. And Claude doesn't fight entropy especially well yet, not all by itself.
I have been able to write some pretty damn ambitious code, quickly, with the help of LLMs, but I am still really only using it for developing functions, as opposed to architectures.
But just this morning, I had it break up an obese class into components. It did really well. I still need to finish testing everything, but it looks like it nailed it.
Francis Bacon and The Brutality of Fact is a wonderful documentary that goes over this. Bacon's process was that he painted every day for a long time, kept the stuff he liked and destroyed the crap. You are just not seeing the bad random knob twiddling he did.
Picasso is even better. Picasso had some 100,000 works. If you look at a book that really gets deep to the more obscure stuff, so much of Picasso is half finished random knob twiddling garbage. Stuff that would be hard to guess is even by Picasso. There is this myth of the genius artist with all the great works being this translation of the fully formed vision to the medium.
In contrast, even the best music from musical programming languages is not that great. The actual good stuff is so very thin because it is just so much effort involved in the creation.
I would take the analogy further that vibe coding in the long run probably develops into the modern DAW while writing c by hand is like playing Paganini on the violin. Seeing someone playing Paganini in person makes it laughable that the DAW can replace a human playing the violin at a high level. The problem though is the DAW over time changes music itself and people's relation to music to the point it makes playing Paganini in person on the violin a very niche art form with almost no audience.
I read the argument on here ad nauseam about how playing the violin won't be replaced and that argument is not wrong. It is just completely missing the forest for the trees.
We'll see which one it is in a few months.
I do agree with you that by design this new tool lowers the bar to entry etc.
But I just want to state the obvious: billions of kids are playing with a ball; it's not that hard. Yet far less people are good soccer players.
> The goal is to replace all cognitive work. Just because this is not entirely possible today, doesn't mean that it won't be tomorrow. > [..] > I'm of the opinion that this goal is unachievable with the current tech generatiom > [..] > In the meantime, your own skills will continue to atrophy the more you rely on this tech [..]
Here I don't quite follow.
I agree that if this tech is ready to completely replace you, you won't need to use your brain. But provided it is not there yet (like, at all), your intellect is needed quite a lot to get out of it anything more than toys.
The question is: do you benefit from using it or not? can you build faster or better by applying these tools in the appropriate way or should you just ignore it and keep doing things the way things used to be done up until a few months ago?
This is a legit question.
My point is: in order to anwswer this question I cannot base my intuition only on some vague first principles on what this tech stack ought to be able to do, or what other people say it's able to do, or what I suspect it will never be able to do: I need to touch it, to learn how to use it, just like every other tool. That's the only way I can truly get a sensible answer. And like any other skill, I'm fully aware that I can't devote just a few minutes trying it out and then reaching any conclusion.
EDIT: I do share a general concern about how new generations are going to achieve the full-picture understanding if they get exposed to these tools as the main approach towards software production. I come to this after a long career in system programming, so I don't personally see this as a threat to atrophy my own skills; but I do share a quite undefined sense of concern about where this is going
I agree, but I don't see how that negates what I said.
Following your analogy, what's currently happening is that kids playing with a ball are now allowed to play in the major leagues. Good soccer players still exist, and their performance has arguably improved as well, but kids are now entering spaces that were previously inaccessible to them. This can be seen as both a good or a bad thing, but I would argue that it will mostly have bad consequences for everyone involved, including the kids.
> The question is: do you benefit from using it or not? can you build faster or better by applying these tools in the appropriate way or should you just ignore it and keep doing things the way things used to be done up until a few months ago?
That's a false dichotomy. I would say that the answer is somewhere in the middle.
These new tools can assist with many tasks, but I'm still undecided whether they're a net long-term benefit. On one hand, sure, they enable me to get to the end result quicker. On the other, I have less understanding of the end result, hence I can't troubleshoot any issues, fix any bugs, or implement new features without also relying on the tool for this work. This ultimately leads to an atrophy of my skills, and a reliance on tools that are out of my control. Even worse: since the tools are far from reliable yet, they provide a false sense of security.
But I also don't think it's wise to completely ignore this technology, and continue working as it didn't exist.
So at this point, the smartest approach to me is conservative adoption. Use vibe coding for things that you don't care about, that won't be published, and will only be used by yourself. Use assisted coding in projects that might be published and have other users, but take time and effort to guide the tool, and understand and review the generated code. Use classical programming for projects you care about, critical software, or when you want to actually learn and improve your skills.
I doubt this approach will be adopted by many, and that's the concerning part, since the software they produce will inevitably be forced on the rest of us.
What's really surprising to me is how many experienced programmers are singing the praises of this new way of working. How what they really enjoy is "building", but find the classical process of "building" tedious. This goes against most of the reasons I got into and enjoy working in this industry to begin with. Delivering working software is, of course, the end goal. But the process itself, pushing electrons to arrange bits in a useful configuration, in a way that is interesting, performant, elegant, or even poetic, learning new ways of doing that and collaborating with like-minded people... all of that is why I enjoy doing this. A tool that replaces that with natural language interactions, that produces the end result by regurgitating stolen data patterns in configurations that are sometimes useful, and that robs me from the process of learning, is far removed from what I enjoy doing.
You’re right. I’m going back to writing assembly. These compilers have totally atrophied my ability to write machine code!
If you can use an imperfect tool, perfectly, you’ll beat people using them imperfectly. As long as the tool is imperfect, you won’t have much competition.
That’s where we are, right now. Good engineers are learning how to use klunky LLMs. They will beat out the Dunning-Kruger crew.
Once the tool becomes perfect, then that allows less-technical users into the tent, which means a much larger pool of creativity.
Put another way, the ability to use AI became an important factor in overall software engineering ability this year, and as the year goes on the gap between the best and worst users or AI will widen faster because the models will outpace the harnesses
Is it, lol? Know any case where those “the best users of AI” get salary bumps or promotions? Outside of switching to the dedicated AI role that is? So far I see clowns doing triple the work for the same salary.
If you just mean, "hey you should learn to use the latest version of Claude Code", sure.
Until coding systems are truly at human-replacement level, I think I'd always prefer to hire an engineer with strong manual coding skills than one who specializes in vibe coding. It's far easier to teach AI tools to a good coder than to teach coding discipline to a vibe coder.
The person who understands how lower levels of abstraction work, will always run circles technically around those who don't. Besides, "AI" tools are not a higher level of abstraction, and can't be compared to compilers. Their goal is to replace all cognitive work done by humans. If you think programming is obsolete, the same will eventually happen to whatever work you're doing today with agents. In the meantime, programmers will be in demand to fix issues caused by vibe coders.
> In the meantime, programmers will be in demand to fix issues caused by vibe coders.
Yes, I agree. They’ll be lower on the totem pole than the vibe coders, too. Because the best vibe coders have the same skill set as you - years of classical engineering background. So how can one differentiate themself in the new world? I aspire to move up the totem pole, not down, and leaning into AI is the #1 way to do that. Staying a “bug fixer” only is what will push you out of employment.
This is the nonsense management and CTOs are pushing. Use it now if you want, I do. Wait for things to cool down if you want. You'll be fine either way. The comical view that it'll be a "winner takes all" subset of developers who some how would have figured out secret AI techniques that make them 10Kx more productive and every other developer will be SOL is laughable.