hckrnws

I build accounting automation tools and this resonates hard. The codebase has ~60 backend services handling things like pattern matching, VAT classification, invoice reconciliation - stuff where a subtle bug doesn't crash anything, it just silently posts the wrong number to someone's accounts.

Vibe coding would be catastrophic here. Not because the AI can't write the code - it usually can - but because the failure mode is invisible. A hallucinated edge case in a tax calculation doesn't throw an error. It just produces a slightly wrong number that gets posted to a real accounting platform and nobody notices until the accountant does their review.

Where I've found AI genuinely useful is as a sophisticated autocomplete. I write the architecture, define the interfaces, handle the domain logic myself. Then I'll use it to fill in boilerplate, write test scaffolding, or explore an API I'm not familiar with. The moment I hand it the steering wheel on anything domain-specific, things go sideways fast.

The article's point about understanding your codebase is spot on. When something breaks at 2am in production, "the AI wrote that part" isn't an answer. You need to be able to trace through the logic yourself.

I have zero issues with things going sideways on even the most complicated task. I don't understand why people struggle so much, it's easy to get it to do the right thing without having to hand hold you just need to be better at what you're asking for.

If the failure mode is invisible, that is a huge risk with human developers too.

Where vibecoding is a risk, it generally is a risk because it exposes a systemic risk that was always there but has so far been successfully hidden, and reveals failing risk management.

i agree, and its strange that this failure mode continually gets lumped onto AI. The whole point of longer term software engineering was to make it so that the context within a particular persons head should not impact the ability of a new employee to contribute to a codebase. turns out everything we do to make sure that is the case for a human also works for an agent.

As far as i can tell, the only reason AI agents currently fail is because they dont have access to the undocumented context inside of peoples heads and if we can just properly put that in text somehwere there will be no problems.

The failure mode is getting lumped into AI because AI is a lot more likely to fail.

We've done this with Neural Networks v1, Expert Systems, Neural Networks v2, SVM, etc, etc. only a matter of time before we figured it out with deep neural networks. Clearly getting closer with every cycle, but no telling how many cycles we have left because there is no sound theoretical framework.

> Vibe coding would be catastrophic here. Not because the AI can't write the code - it usually can - but because the failure mode is invisible. A hallucinated edge case in a tax calculation doesn't throw an error. It just produces a slightly wrong number that gets posted to a real accounting platform and nobody notices until the accountant does their review.

How is that different from handwritten code ? Sounds like stuff you deal with architecturally (auditable/with review/rollback) and with tests.

It’s shocking to me that people even ask this type of question. How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human that will logic through things and find the correct answer.

Because I've seen the results ? Failure mode of LLMs are unintuitive, and the ability to grasp the big picture is limited (by context mostly I'd say), but I find CC to follow instructions better than 80% of people I've worked with. And the amount of mental stamina it would take to grok that much context even when you know the system vs. what these systems can do in minutes.

As for the hallucinations - you're there to keep the system grounded. Well the compiler is, then tests, then you. It works surprisingly well if you monitor the process and don't let LLM wander off when it gets confused.

Because humans also make stupid random mistakes, and if your test suite and defensive practices don't catch it, the only difference is the rate of errors.

It may be that you've done the risk management, and deemed the risk acceptable (accepting the risk, in risk management terms) with human developers and that vibecoding changes the maths.

But that is still an admission that your test suite has gaping holes. If that's been allowed to happen consciously, recorded in your risk register, and you all understand the consequences, that can be entirely fine.

But the problem then isn't reflecting a problem with vibe coding, but a risk management choice you made to paper over test suite holes with an assumed level of human dilligence.

> How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human...

Your claim here is that humans can't hallucinate something random. Clearly they can and do.

> ... that will logic through things and find the correct answer.

But humans do not find the correct answer 100% of the time.

The way that we address human fallibility is to create a system that does not accept the input of a single human as "truth". Even these systems only achieve "very high probability" but not 100% correctness. We can employ these same systems with AI.

> The way that we address human fallibility is to create a system that does not accept the input of a single human as "truth".

I think you just rejected all user requirement and design specs.

Not sure how things work at your company, but I’ve never seen a design spec that doesn’t have input from many humans on some form or another

We're agreeing, I think.

Almost all current software engineering practices and projects rely on humans doing ongoing "informal" verification. The engineers' knowledge is integral part of it and using LLMs exposes this "vulnerability" (if you want to call it that). Making LLMs usable would require such a degree of formalization (of which integration and end-to-end tests are a part), that entire software categories would become unviable. Nobody would pay for an accounting suite that cost 10-20x more.

I'd say more importantly, vs. human who on failing to find an acceptable answer, says so.

Humans who fail to do so find the list of tasks they’re allowed to do suddenly curtailed. I’m sure there is a degree of this with LLMs but the fanboys haven’t started admitting it yet.

> It’s shocking to me that people even ask this type of question. How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human that will logic through things and find the correct answer.

I would like to work with the humans you describe who, implicitly from your description, don't hallucinate something random when they don't know the answer.

I mean, I only recently finished dealing with around 18 months of an entire customer service department full of people who couldn't comprehend that they'd put a non-existent postal address and the wrong person on the bills they were sending, and this was therefore their own fault the bills weren't getting paid, and that other people in their own team had already admitted this, apologised to me, promised they'd fixed it, while actually still continuing to send letters to the same non-existent address.

Don't get me wrong, I'm not saying AI is magic (at best it's just one more pair of eyes no matter how many models you use), but humans are also not magic.

Humans are accountable to each other. Humans can be shamed in a code review and reprimanded and threatened with consequences for sloppy work. Most, humans once reprimanded , will not make the same kind of mistake twice.

> Humans can be shamed in a code review and reprimanded and threatened with consequences for sloppy work.

I had to not merely threaten to involve the Ombudsman, but actually involve the Ombudsman.

That was after I had already escalated several times and gotten as far as raising it with the Data Protection Officer of their parent company.

> Most, humans once reprimanded , will not make the same kind of mistake twice.

To quote myself:

  other people in their own team had already admitted this, apologised to me, promised they'd fixed it, while actually still continuing to send letters to the same non-existent address.

I know right, had this discussion last week and it's difficult to argue when people are blinded by the "magic" and hype of the slot machine.

Which interestingly is the meat of this article. The key points aren’t that “vibe coding is bad” but that the design and experience of these tools is actively blinding and seductive in a way that impairs ability to judge effectiveness.

Basically, instead of developers developing, they've been half-elevated to the management class where they manage really dumb but really fast interns (LLM's).

But they dont get the management pay, and they are 100% responsible for the LLMs under them. Whereas real managers get paid more and can lay blame and fire people under them.

It's shocking to me that people make this claim as if humans, especially in some legacy accounting system, would somehow be much better at (1) recognizing their mistakes, and (2) even when they don't, not fudge-fingering their implementation. Like the criticisms of agents are valid, but the incredulity that they will ever be used in production or high risk systems to me is just as incredible. Of course they will -- where is Opus 4.6 compared to Sonnet 4? We've hit an inflection point where replacing hand coding with an agent and interacting only via prompt is not only doable, highly skilled people are already routinely doing it. Companies are already _requiring_ that people do it. We will then hit an inflection point at some time soon where the incredulity at using agents even in the highest stakes application will age really really poorly. Let's see!

Your point is the speculative one, though. We know humans can and have built incredibly complex and reliable systems. We do not have the same level of proof for LLMs.

Claims like your should wait at least 2-3 years, if not 5.

That is also speculative. Well let's just wait and see :) but the writing is on the wall. If your criticism is where we're at _now_ and whether or not _today_ you should be vibe coding in highly complex systems I would say: why not? as long as you hold that code to the same standard as human written code, what is the problem? If you say "well reviews don't catch everything" ok but the same is true for humans. Yes large teams of people (and maybe smaller teams of highly skilled people) have built wonderfully complex systems far out of reach of today's coding agents. But your median programmer is not going to be able to do that.

bored at the weekend, are you sama?

I unfortunately am not the droid you are looking for, I don't know a sama

Your comment is shocking to me. AI coding works. I have seen it with my own eyes last week and today.

I can therefore only assume that you have not coded with the latest models. If you experiences are with GPT 4o or earlier all you have only used the mini or light models, then I can totally understand where you’re coming from. Those models can do a lot, but they aren’t good enough to run on their own.

The latest models absolutely are I have seen it with my own eyes. Ai moves fast.

[dead]

One major difference is the code has an owner who might consider what needs a test or ask questions if they don't understand.

To argue that all work is fungible because perfection cannot be achieved is actually a pretty out there take.

Replace your thought experiment with "Is one shot consultant code different from expert code?" Yes. They are different.

Code review is good and needed for human code, right? But if its "vibe coded", suddenly its not important? The differences are clear.

>perfection cannot be achieved

That's not what I get out of the comment you are replying to.

In the case being discussed here, one of code matching the tax code, perfection is likely possible; perfection is defined by the tax code. The SME on this should be writing the tests that demonstrate adhering with the tax code. Once they do that, then it doesn't matter if they, or the AI, or a one shot consultant write it, as far as correctness goes.

If the resulting AI code has subtle bugs in it that pass the test, the SME likely didn't understand the corner cases of this part of the tax code as well as they thought, and quite possibly could have run into the same bugs.

That's what I get out of what you are replying to.

Humans make such mistakes slowly. It's much harder to catch the "drift" introduced by LLM because it happens so quickly and silently. By the time you notice something is wrong, it has already become the foundation for more code. You are then looking at a full rewrite.

The rate of the mistakes versus the rate of consumers and testers finding them was a ratio we could deal with and we don’t have the facilities to deal with the new ratio.

It is likely over time that AI code will necessitate the use of more elaborate canary systems that increase the cost per feature quite considerably. Particularly for small and mid sized orgs where those costs are difficult to amortize.

Or maybe this is a SaaS opportunity for someone.

>>How is that different from handwritten code ?

I think the point he is trying to make is that you can't outsource your thinking to a automated process and also trust it to make the right decisions at the same time.

In places where a number, fraction, or a non binary outcome is involved there is an aspect of growing the code base with time and human knowledge/failure.

You could argue that speed of writing code isn't everything, many times being correct and stable likely is more important. For eg- A banking app, doesn't have be written and shipped fast. But it has to be done right. ECG machines, money, meat space safety automation all come under this.

With handwritten code, the humans know what they don’t know. If you want some constants or some formula, you don’t invent or guess it, you ask the domain expert.

> With handwritten code, the humans know what they don’t know.

I find this often not to be the case at all.

Let's put it this way: the human author is capable of doing so. The LLM is not. You can cultivate the human to learn to think in this way. You can for a brief period coerce an LLM to do so.

>the failure mode is invisible

Only if you are missing tests for what counts for you. And that's true for both dev-written code, and for vibed code.

Who writes the tests?

the right person is the tax accountant

It doesn't seem obvious that it's a problem for LLM coders to write their own tests (if we assume that their coding/testing abilities are up to snuff), given human coders do so routinely.

This thread is talking about vibe coding, not LLM-assisted human coding.

The defining feature of vibe coding is that the human prompter doesn't know or care what the actual code looks like. They don't even try to understand it.

You might instruct the LLM to add test cases, and even tell it what behavior to test. And it will very likely add something that passes, but you have to take the LLM's word that it properly tests what you want it to.

The issue I have with using LLM's is the test code review. Often the LLM will make a 30 or 40 line change to the application code. I can easily review and comprehend this. Then I have to look at the 400 lines of generated test code. While it may be easy to understand there's a lot of it. Go through this cycle several times a day and I'm not convinced I'm doing a good review of the test code do to mental fatigue, who knows what I may be missing in the tests six hours into the work day?

> This thread is talking about vibe coding, not LLM-assisted human coding.

I was writing about vibe-coding. It seems these guys are vibe-coding (https://factory.strongdm.ai/) and their LLM coders write the tests.

I've seen this in action, though to dubious results: the coding (sub)agent writes tests, runs them (they fail), writes the implementation, runs tests (repeat this step and last until tests pass), then says it's done. Next, the reviewer agent looks at everything and says "this is bad and stupid and won't work, fix all of these things", and the coding agent tries again with the reviewer's feedback in mind.

Models are getting good enough that this seems to "compound correctness", per the post I linked. It is reasonable to think this is going somewhere. The hard parts seem to be specification and creativity.

Maybe it’s just the people I’m around but assuming you write good tests is a big assumption. It’s very easy to just test what you know works. It’s the human version of context collapse, becoming myopic around just what you’re doing in the moment, so I’d expect LLMs to suffer from it as well.

> the human version of context collapse, becoming myopic around just what you’re doing in the moment

The setups I've seen use subagents to handle coding and review, separately from each other and from the "parent" agent which is tasked with implementing the thing. The parent agent just hands a task off to a coding agent whose only purpose is to do the task, the review agent reviews and goes back and forth with the coding agent until the review agent is satisfied. Coding agents don't seem likely to suffer from this particular failure mode.

[dead]

> A hallucinated edge case in a tax calculation doesn't throw an error.

Would double entry book keeping not catch this?

Not necessarily. Double entry bookkeeping catches errors in cases where an amount posted to one account does not have an equally offsetting post in another account or accounts (i.e., it catches errors when the books do not balance). It would not on its own catch errors where the original posted amount is incorrect due to a mistaken assumption, or if the offset balances but is allocated incorrectly.

Sounds like you need to add more tests to your code. The AI is pretty good at that.

Do you by any chance work on open source accounting?

[dead]

I think it all boils down to, which is higher risk, using AI too much, or using AI too little?

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.

It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?

A good analogy might be synthesized music.

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.

I have been a lead engineer for a few decades now, responsible for training teams and architecting projects. And I've been working heavily with AI.

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.

That's been my experience, too.

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.

What I've found out is that a lot of people don't actually care. They see it work and that's that. It's impossible to convince them otherwise. The code can be absolutely awful but it doesn't matter because it works today.

[dead]

I like the analogy but I think you are underestimating how much random knob twiddling there is in all art.

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.

I think this is very well stated. I’m gonna say something that’s far more trite, but what I’ve noticed is that in an effort to get a better result while assisting AI coding, I have to throw away any concept I previously held about good code hygiene and style. I want it to be incredibly verbose. I want to have everything explicitly asserted. I want to have tests and hooks for every single thing. I want it to be incredibly hard for the human to work directly on it …

Synths don't generate music, they generate tones. The analogy would be a program that generates really good programming languages.

I think we are. I'm helping somebody who has a non-technical background and taught himself how to vibe code and built a thing. The code is split into two GitHub repos when it should have been one, and one of the repos is named hetzner-something because that's what he's using and he "doesn't really understand tech shit"

That sounds a lot like “twiddling knobs at random,” to me.

Exactly. The fact that an LLM isn't very good at helping you fix basic organizational issues like this is emblematic. Quoting the article: "We have automated coding, but not software engineering."

> Sometimes, they would have a hit, but they wasted a lot of energy on dead ends.

We'll see which one it is in a few months.

Common sense.

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.

It's hilarious. The whole point of "vibe coding" is that you don't need to learn or know anything.

It's like saying if you don't learn to use a smartphone you'll be left behind. Even babies can use it now.

That's another dumb thing that unfortunately some people can be led to believe. There have been parents who genuinely thought that screen time would make their kids digitally savvy and prepared for the future.

It has worked out quite well for some of them, but there's a lot of devil in the details of the implementation of that screentime that led to eg Mark Zuckerberg vs Markiplier.

Leave them with an old Toshiba and an Ubuntu cd. Good luck kid.

Nah, a pile of PC parts and DOS and Doom floppies.

I do think there's value in trying out fully vibe coding some toy projects today (probably nothing real or security sensitive haha).

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

Even if that were true you'd still need to be good at UX

The new claude/opus, esp, with additional skills is actually pretty decent with UX.

I think so, that's why I think that the risk of pretty much ignoring the space is close to zero. If I happen to be catastrophically wrong about everything then any AI skills I would've learned today will be completely useless 5 years from now anyway, just like skills from early days of ChatGPT are completely useless today.

I do think that there's some meta-skills involved here that are useful, in the same way that some people have good "Google-fu". Some of it is portable, some of it isn't.

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.

> in the same way that some people have good "Google-fu"

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.

Are the early tricks for LLMs still useful today?

I think the AI-coding skill that is likely to remain useful is the ability (and discipline) to review and genuinely understand the code produced by the AI before committing it.

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 think the AI-coding skill that is likely to remain useful is the ability (and discipline) to review and genuinely understand the code produced by the AI before committing it.

> 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.

I've had reasonable results from using AI to analyse code ("convert this code into a method call graph in graphml format" or similar). Apart from hallucinating one of the edges, this worked reasonably well to throw this into yED and give me a view on the code.

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 :)

Don't you think automated evaluation and testing of code is likely to improve at an equally breakneck pace? It doesn't seem very far-fetched to soon have a simulated human that understands software from a user perspective.

Yup, this is why even though I like ai coding a lot, and am pretty enthusiastic about it, and have fun tinkering with it, and think it will stick around and become part of everyday proper software development practice (with guardrails in place), I at least don't go telling people they need to learn it now or they'll be obsolete or whatever. Sitting back and seeing how this all works out — nobody really knows imo, I could be wrong too! — is a valid choice and if ai does stick around you can just hop in when the landscape is clearer!

The image generation side of the story is the prophecy.

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.

And most artists using the tools are still training LoRAs for Flux, Qwen, ZIT/ZIB, etc. Nano Banana is a useful tool, but not for the best work.

This is irrelevant to the point.

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.

> Claude already does this for code. Id be amazed if nano banana doesnt.

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...!)

There is a huge amount of superstition around prompting. I've copied and pasted elaborate paragraph long results and then gotten. Same or better results with only a few words.

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.

>if you don't learn how to vibecode now you'll never ever be able to catch up

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.

And if you can never catch up, how would someone new to the game ever be a meaningful player?

If you’ve never driven a model T, how would you ever drive a corolla? If you never did angular 1, how would you ever learn react? If you never used UNIX 4, you’ll be behind in Linux today. /s

I think there's something to this, but I also there there's something to the notion that it'll get easier and easier to do mass-market work with them, but at the same time they'll become greater and greater force multipliers for more and more nuanced power users.

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.

FOMO is hell of a drug.

Exactly. If it’s so easy (which is the point) then there’s no risk at all. Just pick it up if/when it’s definitely useful.

knowing how to properly use AI is a skill, there are new tools, new patterns, new primitives etc. you will be unpracticed.

That's my take. I know LLMs arent going away even if the bubble pops. I refuse to become a KPI in some PM's promotion to justify pushing this tech even further, so for now I don't use it (unless work mandates it).

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.

Model improvement. But certainly also the cli tool itself. That's where all the planning takes place

Wait around five years and then prompt: "Vibe me Windows" and then install your smart new double glazed floor. There is definitely something useful happening in LLM land but it is not and will never be AGI.

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.

> I think it all boils down to, which is higher risk, using AI too much, or using AI too little?

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.

Those of us working from the bottom, looking up, do tend to take the clinical progressive approach. Our focus is on the next ticket.

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.

>must be so focused on the future

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.

Every company should have hired over the pandemic due to there being a higher EV than not hiring. It's like if someone offered an opportunity to pay $1000 for a 50% chance to make $8000, where the outcome is the same between everyone taking the offer. If you are maximizing for the long term everyone should take the offer even if it does result in a reality where everyone loses $1000.

Where did they get the notion that the EV of overhiring was high by any measure?

There is a reality where the COVID boost tech companies had would persist after COVID is over. The small chance of such a future raised the EV.

> 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.

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!

To be fair, that's what I have done. I try to use AI every now and then for small, easy things. It isn't yet reliable for those things, and always makes mistakes I have to clean up. Therefore I'm not going to trust it with anything more complicated yet.

We should separate doing science from adopting science.

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.

There is also opportunity cost. Most people ignore most things because there are simply not enough hours in a day.

> Test on mice, test in clinical trials, then go to market.

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.

> my best ideas often happen when knee deep in some codebase

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.

Coaxed into dead-end architecture is the exact issue I have had when trying agentic coding. I find that I have the greatest success when I plan everything out and document the implementation plan as precisely as possible before handing it off to the agent. At which point, the hard part is already done. Generating the code was not really the bottleneck.

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.

Even within AI coding how people use this varies wildly from one people trying to one shot apps to people being barely above tab completers.

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

Or just wait for things to settle. As fast as the field is moving, staying ahead of the game is probably high investment with little return, as the things you spend a ton of time honing today may be obsolete tomorrow, or simply built into existing products with much lower learning cost.

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.

Interesting - what makes you think things will slow down?

Settle. Not necessarily slow down. We'll see people gravitate towards a few things, and those will become the standards. It's already started, with claude and codex, compared to the wild west situation a year ago.

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.

> Interesting - what makes you think things will slow down?

Everything slows down eventually. What makes you think this won't?

What makes you think they won’t? And even if they won’t, not wasting energy going through the churn is a winning strategy if eventually AI reads your mind to know what you want to do.

Yeah, it's frustrating that it seems most AI conversations devolve into straw men of either zero AI or one shot apps. There's a huge middle ground where I, and it seems like many others, have found AI very useful. We're still at the stage where it's somewhat unique for each person where AI can work for them (or not).

Very reasonable take. The fact that this is being downvoted really shows how poor HN's collective critical thinking has become. Silicon Valley is cannibalizing itself and it's pretty funny to watch from the outside with a clear head.

I think it's like the California gold rush. Anybody and their brother can go out and dig, but the real money is in selling the shovels.

More like they’re leasing away deeply discounted steam shovels at below market rates and somehow expecting to turn a profit doing so.

The real profits are the companies selling them chips, fiber, and power.

Impossible to say right now... consider just the idea of reactive agentic workflows: test fails, agent is instantly triggered and response is passed off for review, or whatever, something along those lines.

Thats staying power, suddenly that lease isnt a lease, its an ongoing cost for as long as that system exists. its gas.

A handful of start ups will find genuine use cases for these models with real business demand. It just won’t be another AI travel agent chat bot.

But the companies selling them chips are also their shareholders, so those are on the hook as well.

If it's below market rates, the people using the shovels are the ones making a profit.

Shovels still have a defined cost, even if there's absolutely no gold there for one to find.

I don't think this is the case, because the AI companies are all just shuffling around the same 300 million or trillion to each other.

using ai too little is never wrong I think

It definitely comes up if you're just reviewing an already-"completed" PR. Even if you're not going to ship AI-generated code to prod (and I think that's a reasonable choice), it's often informative to give a high-level description of what you want to accomplish to a coding agent and see what it does in your codebase. You might find that the AI covered a particular edge case that you would have missed. You might find that even if the PR as a whole is slop.

This is basically Pascal’s wager. However, unlike the original Pascal’s wager, yours actually sounds sound.

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”.

Interesting analogy, but I'd say it's kind of the opposite. In the two you mentioned, the cost of inaction is extremely high, so they reach one conclusion, whereas here the argument is that the cost of inaction is pretty low, and reaches the opposite conclusion.

Indeed, another key difference with the climate change wager is that both the action and the consequences are global, whereas the OG wager and the AI wager are both about personal choice.

> I think it all boils down to, which is higher risk, using AI too much, or using AI too little?

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.

> you may be less productive than optimal

There is zero evidence that LLM's improve software developer productivity.

Any data-driven attempts to measure this give ambivalent results at best.

Even if you believe that many are too far on one side now, you have to account for the fact that AI will get better rapidly. If you're not using it now you may end up lacking preparation when it becomes more valuable

But as it gets better, it'll also get easier, be built into existing products you already use, etc. So I wouldn't worry too much about that aspect. If you enjoy tinkering, or really want to dive deep into fundamentals, that's one thing, but I wouldn't worry too much about "learning to use some tool", as fast as things are changing.

I don't think so. That's a good point but the capability has been outpacing people's ability to use it for a while and that will continue.

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

That’s the comical understanding being pushed by management in software companies yes. The people who never actually use the tools themselves, but the concept of it. It’s the same AGI nonesense, but dumped down to something they think they can control.

why does every AI skeptic assume that everyone is lying to them. theres millions of developers using AI to be more productive and you just keep plugging your ears and screaming, claiming its only dumb managers, meanwhile Linus Torvalds is vibe coding stuff.

Who said anything about that? The argument was "if you're not using AI RIGHT NOW, you will fall behind forever"

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.

> 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.

have fun keeping a job doing 1/3 the work of people getting paid the same as you :)

I’m from Europe, so I’ll do just that. Thankfully labor laws are strong enough here to withstand this absurdity.

I mean, right now "bleeding edge" is an autonomous agents system that spends a million dollars making an unbelievably bad browser prototype in a week. Very high effort and the results are jibberish. By the time these sorts of things are actually reliable, they'll be productized single-click installer apps on your network server, with a simple web interface to manage them.

If you just mean, "hey you should learn to use the latest version of Claude Code", sure.

I mean that you should stay up to date and practiced on how to get the most out of models. Using harnesses like Claude code sure, but also knowing their strengths and weaknesses so you can learn when and how to delegate and take on more scope

Okay yeah that's a good middle ground, and I'd even say I agree. It's not about being on the bleeding edge or being a first adopter or anything, but the fact that if you commit to a tool, it's almost always worth spending some time learning how to use it most effectively.

I mean if the capacity has outpaced people's ability to use it, to me that's a good sign that a lot of the future improvements will be making it easier to use.

The baseline, out-of-the-box basic tool level will lift, but so will the more obscure esoteric high-level tools that the better programmers will learn to control, further separating themselves in ability from the people who wait for the lowest common denominator to do their job for them.

Maybe. But so far ime most of the esoteric tools in the AI space are esoteric because they're not very good. When something gets good, it's quickly commoditized.

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.

I wonder if psychology plays a role here. An engineer with strong manual coding skills might be hesitant to admit that a tool has become good enough to warrant less involvement.

> If you're not using it now you may end up lacking preparation when it becomes more valuable

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.

It won’t, the state of the art is changing so quickly it is near impossible to stay on top of. Right now claude code is doing stuff for our team that was impossible with ai coding six month ago. Probably a year from now it will be something else. I think that if you are not staying on top of things though, you will discover that you should have stayed more on top of things the day you get fired.

We’ll see.

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.

> If you're not using it now you may end up lacking preparation when it becomes more valuable

You think it's going to get harder to use as time goes on?

> you have to account for the fact that AI will get better rapidly

that's nowhere near guaranteed

Even if the models stopped getting better today, we'd still see many years of improvements from improving harnesses and understanding of how to use them. Most people just talk to their agent, and don't e.g. use sub-agents to make the agent iterate and cross-check outcomes for example. Most people who use AI would see a drastic improvement in outcomes just by experimenting with the "/agents" command in Claude Code (and equivalent elsewhere). Much more so with a well thought out agent framework.

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.

Nothing gets worse in computers. Name me one thing. And if the current output quality of LLM stays the same but speed goes up 1000, quality of the generated code can be higher.

Software has gotten considerably worse with time. Windows and MacOS are basically in senescence from my point of view. Haven't added a feature I've wanted in years, but manages to make my experience worse year to year anyways.

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.

Windows

Hot keys. Used to be, you could drive a program from the keyboard with hotkeys and macros. No mouse. The function keys did functions. You could drive the interface blindfolded, once you learned it. Speed is another one. Why does VSCode take so long to open? and use so much memory and CPU? it's got a lot of features for a text editor, but it's worse than vim/emacs in a lot of ways.

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?

> Wtf is a typescript.

A godsend.

> Native GUI libraries are so much better but we decided those aren't cool anymore.

Lolno.

Why should I worry about lacking preparation in the future? Why can't I just learn this as any other skill at any other time?

You'll be behind by a few months at least, and that could be anywhere from slightly harmful to devasting to your career

How so? Why would a couple of months break in employment (worst case, if I truly become unemployable for some reason until I learn the tools) harm or destroy my career?

Lmao, this is your brain on brainrot LLM FOMO. Better not waste time on HN, you’re wasting precious minutes getting ahead of (imaginary) competition!

The bit about "we have automated coding, but not software engineering" matches my experience. LLMs are good at writing individual functions but terrible at deciding which functions should exist.

My project has a C++ matching engine, Node.js orchestration, Python for ML inference, and a JS frontend. No LLM suggested that architecture - it came from hitting real bottlenecks. The LLMs helped write a lot of the implementation once I knew what shape it needed to be.

Where I've found AI most dangerous is the "dark flow" the article describes. I caught myself approving a generated function that looked correct but had a subtle fallback to rate-matching instead of explicit code mapping. Two different tax codes both had an effective rate of 0, so the rate-match picked the wrong one every time. That kind of domain bug won't get caught by an LLM because it doesn't understand your data model.

Architecture decisions and domain knowledge are still entirely on you. The typing is faster though.

> LLMs are good at writing individual functions but terrible at deciding which functions should exist.

Have you tried explicitly asking them about the latter? If you just tell them to code, they aren't going to work on figuring out the software engineering part: it's not part of the goal that was directly reinforced by the prompt. They aren't really all that smart.

Injecting bias into an already biased model doesn’t make decision smarter, it just makes them faster.

I think this continued anthropomorphism "Have you tried asking about..." is a real problem.

I get it. It quacks like a duck, so seems like if you feed it peas it should get bigger ". But it's not a duck.

There's a distinction between "I need to tell my LLM friend what I want" and "I need to adjust the context for my statistical LLM tool and provide guardrails in the form of linting etc".

It's not that adding prose description doesn't shift the context - but it assume a wrong model about what is going on, that I think is ultimately limiting.

The LLM doesn't really have that kind of agency.

> Architecture decisions and domain knowledge are still entirely on you. The typing is faster though.

Also, it prevents repetitive strain injury. At least, it does for me.

> However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO.

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.

[2]: https://news.ycombinator.com/item?id=46702093

[3]: https://news.ycombinator.com/item?id=46719500

I personally found out that knowing how to use ai coding assistants productively is a skill like any other and a) it requires a significant investment of time b) can be quite rewarding to learn just as any other skill c) might be useful now or in the future and d) doesn't negate the usefulness of any other skills acquired on the past nor diminishes the usefulness of learning new skills in the future

As much as i loved the relation of vibe coding to slots and their related flow states in this article, I also think what you are stating is the exact reason these tools are not the same as slots, the skill gap is there and its massive.

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.

> 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

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.

Agreed, my experience and code quality with claude code and agentic workflows has dramatically increased since investing in learning how to properly use these tools. Ralph Wiggum based approaches and HumanLayer's agents/commands (in their .claude/) have boosted my productivity the most. https://github.com/snwfdhmp/awesome-ralph https://github.com/humanlayer

On the using AI assistants I find that everything is moving so fast that I feel constantly like "I'm doing this wrong". Is the answer simply "dedicate time to experimenting? I keep hearing "spec driven design" or "Ralph" maybe I should learn those? Genuine thoughts and questions btw.

More specifically regarding spec-driven development:

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.

> 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.

> There's no way that the spec is anywhere as unwieldly as the actual code, and the more details, the better.

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.

People are keen to forget that programming languages are specs. And a good technique for coding is to build up you own set of symbols (variables, struct, and functions) so that the spec become easier to write and edit. Writing spec with natural language is playing russian roulette with the goals of the system, using AI as the gun.

Everybody feels like this, and I think nobody stays ahead of the curve for a prolonged time. There's just too many wrinkles.

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.

I think find what works for you, and everything else is kind of noise.

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

I don’t think Ralph is worthwhile, at least the few times I’ve tried to set it up I spent more time fighting to get the configuration right than if I had simply run the prompt. Coworkers had similar experiences, it’s better to set a good allowlist for Claude.

The addictive nature of the technology persists though. So even if we say certain skills are required to use it, then also it must come with a warning label and avoided by people with addictive personalities/substance abuse issues etc.

It's addictive because of a hypothesis I have about addiction. I have no data to back it up other than knowing a lot of addicted people and I have studied neuroscience, yet I still think there's something to it. It's definitely not fully true though.

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.

> knowing how to use ai coding assistants productively is a skill like any other

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.

> In the meantime, your own skills will continue to atrophy the more you rely on this tech, instead of on your own intellect

You’re right. I’m going back to writing assembly. These compilers have totally atrophied my ability to write machine code!

This is a very flawed analogy.

Good on you! Writing assembly is a good way to understand how computers work, which can help you further up the stack.

Assembly will not help you further up the stack which is working with agents, not writing code (obsolete skill). Apparently my /s was needed

I got your poor attempt at sarcasm. I just don't think it's a good argument.

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.

And I got your cheeky, dismissive attitude which completely misses the forest for the trees.

> 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.

I'm doing a similar thing. Recently, I got $100 to spend on books. The first two books I got were A Philosophy of Software Design, and Designing Data-Intensive Applications, because I asked myself, out of all the technical and software engineering related books that I might get, given agentic coding works quite well now, what are the most high impact ones?

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!

As someone with 20 years experience, DDD is a stupid idea, skip it and do yourself a favour.

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.

Agreed. I find most design patterns end up as a mess eventually, at least when followed religiously. DDD being one of the big offenders. They all seem to converge on the same type of "over engineered spaghetti" that LOOKS well factored at a glance, but is incredibly hard to understand or debug in practice.

DDD is quite nice as a philosophy. Like concatenate state based on behavioral similarity and keep mutation and query function close, model data structures from domain concepts and not the inverse, pay attention to domain boundary (an entity may be read only in some domain and have fewer state transition than in another).

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.

Of those 3 DDD books - which did you find the most valuable?

I was going to ask the same thing. I'm self taught but I've mainly gone the other way, more interested in learning about lower level things. Bang for buck I think I might have been better reading DDD type books.

Not GP, but the most impactful one I read was Learning DDD from O’Reilly

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.

Oh absolutely. It feels like a worthwhile architectural framing to understand and draw from as appropriate. To me I think - my end goal is being able to think more deeply about my domains and how to model them.

Thanks for the recommendation!

Twice I’ve used Claude Code for something important and complex. Stunning initial speed and time savings, all given back eventually as it became apparent that some fatally flawed assumptions were baked into the code right from the beginning.

The initial speed is exactly what the article describes, a Loss Disguised as a Win.

Your wording painted the picture of a drug high in my mind, probably an upper. Requiem for Dream style, amazing “Summer”, followed the brutal come down that is “Winter.”

Thank you for not using an LLM.

Just because you’re a good programmer / software engineer doesn’t mean you’re a good architect, or a good UI designer, or a good product manager. Yet in my experience, using LLMs to successfully produce software really works those architect, designer, and manager muscles, and thus requires them to be strong.

I really disagree with this. I don’t think you can be a good software engineer without being a good product manager and a good architect.

You can - but you have to work with a good product manager and a good architect. You have to actually listen to them and trust them.

The irony considering "good" ui to a ui designer is completely at odds with users. We got better ui when it was people who had no clue what they were doing just trying to make some sense out of it, vs the cult of dogmatic ui design we see today where everything follows the same crappy patterns and everyone is afraid to step out of line.

You're doing architect/designer/manager work while being treated, and paid, like a code monkey. This is by design.

It’s also much faster that way. We cut so many corners and make wise bets in what to test a lot and what not to bother with compared to spec-driven development with an LLM.

The #1 predictor of success here is being able to define what success looks like in an obnoxiously detailed manner. If you have a strong vision about the desired UI/UX and you constantly push for that outcome, it is very unlikely you will have a bad time with the current models.

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.

That's how I'm using it :)

I have like 15 personalized apps now, mostly chrome extensions

2017 GPT could generate text that looked factual and well written but was total garbage. Compare that to 2023.

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.

Everyone seems to have different ways to deal with AI for coding and have different experiences. But Armin's comment quoted in the article is spot on. I have seen a friend do exactly the same thing, vibe coded an entire product hooked to Cursor over three months. Filled with features no one uses, feeling very good about everything he built. Ultimately it's his time and money, but I would never want this in my company. While you can get very far with vibe coding, without the guiding hands and someone who understands what's really going on with the code, it ends up in a disaster.

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.

What disaster befell your friend after those three months?

Several, but I can't quite say it here. And I meant it for the codebase, not the person themselves

It's astonishing to me that real software developers have considered it a good idea to generate code... and not even look at the code.

I would have thought sanity checking the output to be the most elementary next step.

I think people got fatigued by reviewing already. Most code is correct that AI produces so you end up checking out eventually.

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.

I suggest move the sanity check to the point of employing the parrot.

"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."

Those people aren't real software developers.

is your job to write code or develop software that works?

I wonder if this phenomenon comes from how reliable lower layers have become. For example, I never check the binary or ASM produced by my code, nor even intermediate byte code.

So vibers may be assuming the AI is as reliable, or at least can be with enough specs and attempts.

I have seen enough compiler (and even hardware) bugs to know that you do need to dig deeper to find out why something isn't working the way you thought it should. Of course I suspect there are many others who run into those bugs, then massage the code somehow and "fix" it that way.

Yeah, I know they exist in lower layers. Though layers being mostly deterministic (hardware glitches aside) I think they are relatively easy to rely on. Whereas LLMs seem to have an element of intentional randomness built into every prompt response.

I think right now a good approach can be using AI everywhere where it helps us in doing the hard work. Not taking the hard work over, but making the task easier in a supporting role. Few things that work really well for me:

- 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/

My little anecdote of breaking the spell. Really I might not been truly under the spell, but I had to go far in to my project to loose the "magic" of the code. The trick was simply going back to a slower way of using it with a regular chat window. Then really reading the code and interrogation everything that looks odd. In my case I saw a .partial_cmp(a).unwrap() in my rust code and went ahead an asked is there an alternative. The LLM returned .total_cmp(a) as an alternative. I continued on asking why it generated the "ugly" unwrap, LLM returned that it didn't become available later version of rust with only a tiny hint of that it .partial_cmp is more common in the original trainingsets. The final shattering was simply asking it why it used .partial_cmp and got back "A developer like me... ". No it is an LLM, there is somewhere in the system prompt to anthropomorphize the responses and that is the subtle trick beyond "skinner box" of pulling the lever hoping to get useful output. There are a bunch of subtle cues that hijacks the brain of treating the LLM like a human developer. So when going back to the agentic flow in my other projects I try to disabling these tricks in my prompts and the AGENTS file and the results are more useful and I'm more prone to realizing when the output has sometimes has outdated constructs and be more specific on what version of tooling I'm using. Occasionally scraping whole branches when I realize that it is just outdated practices or simply a bad way of doing things that are simply more common in the original training data, restarting with the more correct approaches. Is it a game changer... no but it makes it more like a tool that I use instead of a developer of shifting experience level.

The addiction aspect of this is real. I was skeptical at first, but this past week I built three apps and experienced issues with stepping away or getting enough sleep. Eventually my discipline kicked in to make this a more healthy habit, but I was surprised by how compelling it is to turn ideas into working prototypes instantly. Ironically, the rate limits on my Claude and Codex subscriptions helped me to pace myself.

Isn't struggling to get enough sleep or shower enough and so on because you're so involved with the process of, you know, programming, especially interactive, exploratory programming with an immediate feedback loop, kind of a known phenomenon for programmers since essentially the dawn of interactive computing?

Sort of, but the speed at which I can see results and the ability to quickly get unstuck does pull me in more than just coding. While I find both enjoyable, I'm more of a 'end result' person than a 'likes to the type in the code' person. There was a conversation about this a month or so ago referencing what types of people like LLMs and which do not.

I saw a conversation like that but, like here, I didn't always understand what they meant with "end result". Was it only the app GUI and they don't care about the code at all, or do they still care about the code quality, the architecture and planning.

I've written software that solved business problems in everything from Visual Basic to C++. The end result can include the things you list, but typing in the code to me is down the list of importance.

Personally, for me, the "end result" embraces the architecture, planning, algorithms, domain model, code quality, and documentation etc, as well as what the app does in the end. I care a lot about making well architected, reliable stuff

Using agents trigger different dopamine patterns, I'd compare it to a slot machine: did it execute it according to plan or did it make a fatal flaw? Also, multiple agents can run at once, which is a workflow for many developers. The work essentially doesn't come to a pausing point.

> did it execute it according to plan or did it [have] a fatal flaw?

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

I’ve learned the hard way that in coding, every line matters. While learning Go for a new job, I realised I had been struggling because I overused LLMs and that slowed my learning. Every line we write reflects a sense of 'taste' and needs to be fully controlled and understood. You need a solid mental model of how the code is evolving. Tech CEOs and 'AI researchers' lack the practical experience to understand this, and we should stop listening to them about how software is actually built.

Articles like this amount to a straw man.

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.

Of course people think that, because that is exactly how those agents are being sold. If you tell management that this speeds up the easy part, typing the code, they are convinced you are using it wrong. They want to save 90% of software development cost and you are telling them that’s not possible.

Thats exactly the thing what the term vibecoding describes.

I don't know this feels extremely wrong I've put out more things (including open source for the first time in a long time) that I still feel proud of since at the end of the way I manually review everything and fix whatever I don't like.

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.

There are different kinds of coding - web dev, low level coding, software, research, data science. There are some kinds of coding where carefully designing the architecture is important, and AI might not produce satisfactory code. Some kinds of coding, on the other hand, can benefit very strongly from AI. I suspect that many people who specialize in a particular area of coding form opinions based on how useful AI is in that area, and those opinions are perfectly valid for what coding means to them, but don't generalize to other people with different specializations.

Speaking just for myself, AI has allowed me to start doing projects that seemed daunting at first, as it automates much of the tedious act of actually typing code from the keyboard, and keeps me at a higher level.

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.

Actually, I wonder how they measured the 'speed' of coding, maybe I missed it. But if developers can spend more time thinking about the larger problems, that may be a cause of the slowdown. I guess it remains to be seen if the code quality or feature set improves.

i used to lose hours each day to typos, linting issues, bracket-instead-of-curly-bracket, 'was it the first parameter or the second parameter', looking up accumulator/anonymous function callback syntax AGAIN...

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.

idk what you’re doing but proper IDE was doing that for me for past 15 years or more.

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.

emacs-nox for 8 years :-)

With all due respect, but if you actually wasted hours (multiple) each (!) day on those issues, then yeah, I can fully believe that AI assisted coding 10 or even 100x'd you.

I uncharitably snarked that AI lets the 0.05X programmers become 0.2X ones, but reading this stuff makes me feel like I was too charitable.

I've never had problems with any of those things after I learned what a code editor was.

Yep, it may be an issue in notepad, which does not have helper like syntax highlighting, auto indent, and line numbers. But I started with IDLE which has all those things. So my next editor was notepad++ and codeblock.

How does AI help you here? Do you pass it a file and tell it to "fix syntax errors, no mistakes!" ??

I see AI coding as something like project management. You could delegate all of the tasks to an LLM, or you could assign some to yourself.

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.

You need to understand the frustration behind these kinds of posts.

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.

I can't believe we're back to using LoC as a metric for being productive again.

The observation about "automated coding but not software engineering" maps directly to what we're seeing in production AI systems beyond code generation.

We hit this exact wall building voice AI agents. A single monolithic agent handling conversation, navigation, and intent recognition was the "vibe coded" approach - it worked for demos but fell apart in production. The fix was the same architectural discipline the article describes: decomposing into specialized agents with clear boundaries and explicit handoff protocols.

What's interesting is that the "dark flow" phenomenon shows up in agent design too. You get a conversational agent that sounds great in testing, handles 80% of cases smoothly, and you ship it. Then you discover the remaining 20% creates cascading failures because the agent confidently handles things it shouldn't. The invisible failure modes are identical to what the accounting automation commenter described - no crash, just subtly wrong behavior.

The meta-lesson: whether you're generating code or building AI-powered products, the bottleneck was never typing speed or token generation. It's the architectural thinking, domain modeling, and failure mode analysis that makes systems actually work. The engineers who understand this are the ones building reliable AI products, not just impressive demos.

> “People who go all in on AI agents now are guaranteeing their obsolescence. If you outsource all your thinking to computers, you stop upskilling, learning, and becoming more competent”

Likewise those people are guaranteeing "AI"s obsolesence. The parrots need humans to feed them.

Ive come to the realization after maxing the x20 plan that I have to set clear priorities.

Fortunately, I've retired so I'm going focus on flooding the zone with my crazy ideas made manifest in books.

I think most of the issues with "vibe coding" is trusting the current level of LLM's with too much, as writing a hacky demo of a specific functionality is 1/10 as difficult as making a fully-fledged, dependable, scalable version of it.

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.

Of course - and autonomous driving is 1 year away.

I have ridden in a Waymo dozens of times with no issues. I've also used Tesla's self-driving to similar efficacy.

That's the nature of all tech, it keeps not being good enough, until it is, and then everything changes.

As an aside, I wonder if automated driving would be one year away if we did not need to worry about it killing people.

Like if the only possible issues were property damage, I kind of think it would be here. You just insure the edge cases.

I think a big part of this discussion lost for a lot is a lot of people are trying to copy/paste how we’ve been developing software over the past twenty years into this new world which simply doesn’t work effectively.

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.

What are such new ways? You’re being very vague about them.

A post I saw the other day from someone in a similar situation who did share what changes were made: https://bsky.app/profile/abumirchi.com/post/3meoqzl5iec2o

>Should you gamble your career? [...] Consider the case where [you let your skills stagnate and AI falls flat].

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.

"Learn AI tooling"

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.

>What is there to learn, honestly?

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)

To me it seems you and many others are lost in the weeds of constantly evolving tooling and strategies.

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.

I can bet that a single standard instance of existing tool like codex and Claude Code to do whatever someone with a convoluted setup like that can. It could be marginally slower if you but it's all literally just English language text files.

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.

>I can bet that a single standard instance of existing tool like codex and Claude Code

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.

I agree completely.

I think tech journalism needs to reframe its view of slot machines if it's to have a productive conversation about AI.

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.

At the expense of other people. Slot machines is a negative sum game.

Not for the house

That AI would be writing 90% of the code at Anthropic was not a "failed prediction". If we take Anthropic's word for it, now their agents are writing 100% of the code:

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.

One thing I like to think about is: If these models were so powerful why would they ever sell access? They could just build endless products to sell, likely outcompeting anyone else who needs to employ humans. And if not building their own products they could be the highest value contractor ever.

If you had midas touch would you rent it out?

Well there are models that Anthropic, OpenAI and co. have access to that they haven't provided public API's for, due to both safety, and what you've cited as the competitive advantage factor. (like Openai's IMO model, though it's debatable if it represented an early version of GPT 5.1/2/3 or something else)

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.

They need to generate revenue to continue to raise money to continue to invest in compute. Even if they have the Midas Touch it needs to be continously improved because there are three other competing Midas Touch companies working on new and improved Midas Touch's that will make their's obsolete and worthless if they stay still even for a second.

But most of their funding comes from speculative investment, not selling their services. Also, wouldn't selling their own products/services generate revenue?

Making a profitable product is so much more than just building it. I've probably made 100+ side projects in my life and only a handful has ever generated any revenue.

Arguably because the parts the AI can't do (yet?) still need a lot of human attention. Stuff like developing business models, finding market fit, selling, interacting with prospects and customers, etc.

Exactly. The fact that people laugh at the prediction like it's a joke when I and many others have been at 90%+ for a long time makes me question a lot of the takes here. Anyone serious about using LLMs would know it's nothing controversial to have it write most of the code.

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 entirely surprising. You can prompt the AI to write code to pretty much any level of detail. You can tell it exactly what to output and it will copy character for character.

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??

https://job-boards.greenhouse.io/anthropic/jobs/4816198008

They probably still need to be able to read and distinguish good vs bad code, evaluate agent decisions, data structures, feasibility, architectural plans, etc, all of which require specific software engineering expertise, even if they don't end up touching the code directly.

But that doesn't make sense. They claim that AI is writing 100% of the code, yet if they need to be able to read and distinguish good vs bad code, evaluate agent decisions, data structures, feasibility, architectural plans, etc, that implies they are writing at least some of the code? Or else why would they ever need to do those things?

This is not the fantastic argument you think it is. 100% is only achievable if you have software engineers at the helm so there's no contradiction here.

If the AI is doing 100% of the work why would you need software engineers at the helm?

100% of the code, not 100% of the work.

what doesn't make sense? "writing" the code is implementation

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 wish one of those agents was smart enough to notice that their github-action which auto closes issues is broken: https://github.com/anthropics/claude-code/issues/16497. Then maybe we could get some of these bugs fixed.

Why do they have so many GitHub issues then?

Fuck vibe coding. If you want a system that actually stays stable, use OpenSpec (or something like it) to build a closed-loop rig where your requirements drive the code and the code proves it met the requirements. In one weekend, I built a system that processes OpenSpec requirements into IMGUI automatic testing scripts. It captures screenshots, compiles them into a report, and assigns each image a prompt—essentially a requirement snippet—that tells a multimodal LLM exactly what to look for. Claude is incredible at stitching these types of tools together. Once you have that closed loop, you can let an agent loose on features and just let the code it writes converge on the spec. The golden rule: If you don't like the results, change the spec. Don't shortcut or "vibe code" a bug away. This keeps the guardrails on. For every feature you add, you have to think about how to validate it automatically. Even a basic smoke test that raises a flag for human review is better than nothing. Think about the workflow: capture screenshots of all your app workflows and commit them to Git as a baseline. On the next commit, run fast smoke tests. If the images match, you’re good. If they differ, the LLM analyzes the diff against the requirements and proposes a fix for either the code or the spec. Rigs like this used to take teams years to build; now you can build them in a few days with a coding assistant. It’s simple, it’s stable, and it actually scales.

The part about "dark flow" resonates strongly. I've seen this pattern play out with a specific downstream cost that doesn't get discussed enough: maintenance debt.

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.

> A study from METR found that when developers used AI tools, they estimated that they were working 20% faster, yet in reality they worked 19% slower. That is nearly a 40% difference between perceived and actual times!

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.

> I don’t know how to trust the author if stuff like this is wrong.

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.

so if the numbers were “99% slower than without AI but they thought they would be 99% fast”, you’d call that “they were 529% slower”, even though it doesn’t make sense to be more than 100% slower? And you’d not only expect everyone to understand that, but you really think it’s more likely a random person on the internet used a logarithmic scale than they just did bad math?

I get caught up personally in this math as well. Is a charitable interpretation of the throwaway line that they were off by that many “percentage points”?

That would be correct, but also useless. It matters if 50pp are 50% vs. 100%, 75% vs. 125% or 100% vs. 150%.

Can you elaborate? This seems like a simple mistake if they are incorrect, I'm not sure where 33% or 50% come from here.

Their math is 120%-80%=40% while the correct math is (80-120)/120=-33% or (120-80)/80=+50%

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.

It's not a mistake. It's correct, and is a excellent way to present this information.

Isn't the study a year old by now? Things have evolved very quickly in the last few months.

Yes and if was done with people using cursor at the time and already had a few caveats back then about who was actually experienced with the tool etc.

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.

The exact numbers certainly would be different today, but you would probably still see the effect that there’s an overestimation of productivity

Yes. No agents, no deep research, no tools, and just Sonnet-3.5 and 3.7 - I’d love to see the same study today with Opus-4.6 and Codex-5.3

Probably 38% slower now...

Please don’t project. :)

Agent assisted coding is just vibe-coding in disguise. You still only glance over the code "just so it won't be considered vibe-coding", but at the end of the day, if you invest a proper amount of time reading and reasoning with the generated code - than it would take the exact same time, as if you would have wrote it by hand.

By not going through this process, you loose intent, familiarity, and opinions.

It's the exact same as vibe-coding.

"Hell is other people's code"

Not sure why we'd want a tool that generates so much of this for us.

It can be told just as easily to delete code. It can generate instructions to remove lines.

> However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO. Consider the case where you don’t grow your software engineering or problem-solving skills, yet the forecasts of AI coding agents being able to handle ever expanding complexity don’t come to pass. Where does this leave you?

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.

Do you think your organisation as a whole is doing more ? Is the more being done actually useful ? i.e: is the outcome better ?

Not an org where everyone uses the tech to such a degree: also were late adopters of Docker for example, in large part got around to it due to my initiative (100-200 people org, so small).

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).

Step 1. Stop calling it "vibe coding."

>Anthropic CEO Dario Amodei predicted that by late 2025, AI would be writing 90% of all code

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.

> Vibe coding is the creation of large quantities of highly complex AI-generated code, often with the intention that the code will not be read by humans.

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.

tl;dr - author cites a study from early 2025 which measured developer speed of “experienced open source developers” to be ~20% slower when supported by AI, while they’ve estimated to be ~20% faster.

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

> 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.

It can facilitate that, certainly. Idk about the background of that stakeholder, but AI can help drafting communication with the right tone to show the necessity. It can help to write a guide on how to properly test the specific feature. It can write e2e tests that the stakeholder could execute from their environment.

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.

For most people, blackjack is gambling. There are non-gamblers who play it though. You can just count cards and eventually beat the odds with skill.

I wonder if there's something similar going on here.

this is quite literally just coping and seething

"they don’t produce useful layers of abstraction nor meaningful modularization. They don’t value conciseness or improving organization in a large code base. We have automated coding, but not software engineering"

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.

which is why the most famous book in the world of software development pointed out that the long term success of a software project is not defined by man hours or lines of code written but by documentation, clear interfaces and the capacity to manage the complexity of a project.

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

[dead]

Fascinating - I find the opposite is true. I think of edge cases more and direct the exploration of them. I’ve found my 35 years experience tells me where the gaps will be and I’m usually right. I’ve been able to build much more complex software than before not because I didn’t know how but because as one person I couldn’t possibly do it. The process isn’t any easier just faster.

I’ve found also AI assisted stuff is remarkable for algorithmically complex things to implement.

However one thing I definitely identify with is the trouble sleeping. I am finally able to do a plethora of things I couldn’t do before due to the limits of one man typing. But I don’t build tools I don’t need, I have too little time and too many needs.

> I’ve found also AI assisted stuff is remarkable for algorithmically complex things to implement.

AI is really good to rubber duck through a problem.

The LLM has heard of everything… but learned nothing. It also doesn't really care about your problem.

So, you can definitely learn from it. But the moment it creates something you don't understand, you've lost control.

You had one job.

> when I lean too heavily on LLM-generated code, I stop thinking about edge cases and error handling

I have the exact same experience... if you don't use it, you'll lose it

[dead]

[dead]

My gripe with "developer accepts bad code without reading it" is two fold.

1. It's turning the Engineering work into the worst form of QA. It's that quote about how I want AI to do my laundry and fold my clothes so I have time to practice art. In this scenario the LLM is doing all the art and all that's left is the doing laundry and folding it. No doubt at a severely reduced salary for all involved.

2. Where exactly is the skill to know good code from bad code supposed to come from? I hear this take a lot I don't know any serious engineer that can honestly say that they can recognize good code from bad code without spending time actually writing code. It's makes the people asking for this look like that meme comic about the dog demanding you play fetch but not take the ball away. "No code! Only review!" You don't get one without the other.

"Where exactly is the skill to know good code from bad code supposed to come from?"

Answer: Books. Two semesters of "Software Engineering" from a CS course. A CS course. CS classes: Theory of Computing. (Work. AKA Order(N) notation. Turing machines. Alphabets. Search algorithms and when/why to use them.) Data Structures. (Teaches you about RAM vs. Disk Storage.) Logic a.k.a. Discrete Math. (Hardware stuff = Logic. Also Teaches you how to convert procedures into analytic solutions into numerical solutions aka a single function that gives you an answer through determining the indeterminate of an inductive reasoning (converting a series, procedure or recursive function into an equation that gives you an answer instead of iterating and being dumb.) Networking. (error checking techniques, P2P stuff) Compilers. (Dragon book.) Math. Linear Algebra. (Rocket science) Abstract Algebra (Crypto stuff, compression) Theory of Equations (functional programming). Statistics (very helpful). Geometry. (Proofs).

Taking all these classes makes you smart and a good programmer. "Programming" without them means you're... well. Hard to talk to.

I don't think you need to write any code to be a good programmer. IMHO.

I feel like this answer is reductive. It's not just having a bunch of academic syntax. You need reps. You can't seriously be suggesting that reading about a skill is equal to practicing a skill. The skill was never about the syntax in the first place.

Also again, this logic only works on absolute greenfield project. If you write enterprise code in large organizations, you also have to consider the established architecture and patterns of the code-base. There's no book or usually cohesive documentation to that. There's a reason a lot of devs aren't considered fully on-boarded until after a year.

If you leverage the LLM to write the code for you. Then you never learn about your own codebase. Thus you cannot preform good code review. Which again is why I say reviewing code while never writing code is a paradox statement. You don't have the skills to do the former without doing the latter.

Even if you're take was that typing code into a keyboard was never the main part of your job then the question is ok what is it? And if the answer was being an architect then I ask you. How can you know what code patterns work for this specific business need when you don't write code?

Exactly. Programming skill, like most human skills, is acquired through practice and repitition. You can't become an excellent programmer by observing other people (or LLMs) doing it. That's like arguing you can become a master musician by reading sheet music or watching live performances by other musicians.

bait used to be believable

(i.e. I don't think that's your honest opinion and you're just trolling)

[dead]

[dead]

[dead]