> Many people have tried to come up with a better name for this to differentiate it from vibe coding, personally my current favorite "agentic engineering"

Andrej posted that on 4th of February. I first saw the term "agentic engineering" used by OpenClaw creator Peter Steinberger in October 2025 (a month before he wrote the first line of code for OpenClaw) https://steipete.me/posts/just-talk-to-it

And AI generated code should be different than human code. AI has infinite memory for details. AI doesn’t need organizational patterns like classes. Potentially AI can write code that is more performant than any human.

Will it look like garbage? Sure. Will the code be more suited to the task? Yes.

I don't buy this argument at all. I think if we could pay $20/month to a service that would send over a junior plumber/carpenter/electrician with an encyclopedic knowledge of the craft, did the right thing the majority of the time, and we could observe and direct them, we'd all sign up for that in a heartbeat. Worst case, you have to hire an experienced, expensive person to fix the mess. Yes, I can hear everyone now, "worst case is they burn your house down." Sure, but as we're reminded _constantly_ when we read stories about AI agent catastrophes -- a human could wipe your prod database too. wHy ArE yOu HoLdInG iT tO a DiFfErEnT sTaNdArD???

The business side of the house is getting to live that scenario out right now as far as software goes. Sure you've got years of expertise that an LLM doesn't have _yet_. What makes you think it can't replace that part of your job as well?

Claude Code in particular seems really uninterested in this aspect of the problem and I've stopped using entirely because of this.

I believe this is a common fault of not being able to zoom out and look at what trade offs are being made. There’s always trade-offs, the question is whether you can define them and then do the analysis to determine whether the result leaves you in a net benefit state.

If you want to build a project, you can never shorten the actual time it takes to write it out, you are stuck at that 50 words per minute limit

LLMs, agents, call it how you want, they allow us to remove that bottleneck

Agentic Engineer does not make much sense to be applied to a developer.

It is weird and confusing to call a web designer that uses AI assisted coding tools "agentic engineer".

But building software still requires domain knowledge, understanding data structures, architecture, which services to use. We probably have 2-5 years before thats fully automated.

Just piggy backing on this post since I'm early:

Would love to see your take on how the AI and Django worlds will collide.

Without pre-defined definitions and locked procedures, it's extremely easy to mistake iterative adaptation for genuine signal.

> Claude Code does not have a professional reputation!

how come?

So the number of bugs to find remains constant but the amount of code to review scales with the capability of the agent.

There are certain codebases and pieces of code we definitely want every line to be reasoned and understood. But like his API endpoint example, no reason to fuss with the boilerplate.

This has definitely been my shift over the past few months, and the advantage is I can spend much more time and energy on getting the code architecture just right, which automatically prevents most of the subtle bugs that has people wringing their hands. The new bar is architecting code to be defined as well as an API endpoint->service structure so you can rely on LLMs to paint by numbers for new features/logic.

[1] https://github.com/mohsen1/tsz

My dad (now retired) was always super practical about stuff. He'd tell me pretty nonchalantly things like "yeah we're dealing with xyz constraint, we may have to cut a corner over here, but that's ok", when I asked him about it he gave me a little spiel that you can be thoughtful about how you do things, including when you can cut a corner and more importantly, what corners are ok to cut.

I really took that to heart - especially the "be thoughtful about the corners you cut"

If an LLM has consistently one shotted certain tasks and they are rote/mechanical - not reviewing that code is probably ok.

Are you getting lazy and not reviewing stuff that should be reviewed even if a human wrote it? That's probably not ok

I can live with some basic code that broke because it used outdated syntax somewhere (provided the code isn't part of a mission critical application), but I can't live with it fucking JWT signing etc

To me it’s a spectrum with varying levels of structure provided, review etc.

Basically oneshot vibes on one side, fully hand coded on other.

Nothing about this should be disturbing unless you want to dig your heels in, cross your arms and refuse to adapt.

AI is a massive opportunity. But if people focus on the issue of the 'change' they simply waste time they could (and should) be spending on integrating it correctly.

I believe that this form of resistance is far more stagnating and dangerous than any of the issues that come with the general onslaught of ai integration.

If you mean 'passes tests', that can be tackled by AI. Although AI writing its own tests and then implementing its own code is definitely not a foolproof strategy.

But using an agentic LLM to complete boilerplate is attractive simply because we've created a mountain of accidental and intentional complexity in building software. It's more of a regression to the mean of going back to the cognitive load we had when we simply built desktop applications.

> But I’m not reviewing that code. And now I’ve got that feeling of guilt: if I haven’t reviewed the code, is it really responsible for me to use this in production?

Answer: it wholly depends upon what management has dictated be the goal for GenAI use at the time.

There seems to be a trend of people outside of engineering organizations thinking that the "iron triangle" of software (and really, all) engineering no longer holds. Fast, cheap, good: now we can pick all three, and there's no limit to the first one in particular. They don't see why you can't crank out 10x productivity. They've been financially incentivized to think that way, and really, they can't lose if they look at it from an "engineer headcount" standpoint. The outcomes are:

1) The GenAI-augmented engineer cranks out 10x productivity without any quality consequences down the line, and keeps them from having to pay other people

or

2) The GenAI-augmented engineer cranks out 10x productivity with quality consequences down the line, at which point the engineer has given another exhibit in the case as to why they should no longer be employed at that organization. Let the lawyers and market inertia deal with the big issues that exist beyond the 90-day fiscal reporting period.

Either way, they have a route to the destination of not paying engineers, and that's the end goal.

If you don't like that way of running a software engineering organization, well, you're not alone, but if nothing else, you could use GenAI to make working for yourself less risky.

I work on database optimizers and other database related stuff, and I can assure Claude Code - with all the highest settings - does make mistakes. It will generate a test that does not actually test what it "thinks" it tests. It will confidently break stuff.

Do not get me wrong. It is still awesome! It takes much of grunt work off me. It can game out designs decisions even when that needs to refactor a lot of code. If you point out a mistake more often than not it can fix it itself.

It's just for a critical project I would never ship it without understanding every line of code - with the exception perhaps of some of the test code. Maybe in a year or two that will be different.

People have been running crappy code commercially for over half a century now. Not many companies successfully differentiate by running good code - it usually does not matter to the end consumer, other things are much more important. So now companies will pay less for code, and maybe it is a bit worse (though I personally can't believe AI can do worse than corporate software developers on average). Hobbyists will remain hobbyists, and precious few will be lucky enough to have someone pay them to handcraft stuff. Exactly what happened to woodworkers and other craftsmen.

The future is going to dynamically budget and route different parts of the SLDC through different models and subagents running on the cloud. Over time, more and more of that process will be owned by robots and a level of economic thinking will be incorporated into what is thought of today as "software engineering." At some point vibe coding _is_ coding and we're maybe closer to that point than popularly believed.

Engineering is always about a defined process. We follow it to produce predictable artifacts that meet the specifications. Even though code is somewhat "squishy" in that it is an art just as much as a science, it still has to meet the spec.

This has always been true, even before agents started writing code for us. We've all dealt with spaghetti code because of undisciplined practices. That's exactly why we came up with the standard SDLC process: plan, design, code, test, deploy. Repeat.

The part people seem to forget about when looking at this is the space between the steps: the gates. We review the artifacts produced at each stage. If the reviewer does not approve, the engineer has to fix it until it passes. True for human coders, doubly true for agentic coders.

Agentic engineering still follows the process. Artifacts are now cheap to produce, which means we have to adjust it so we don't overwhelm the humans in the loop. For me, this means augmenting my review step with agentic reviewers to catch the dumb stuff. It only escalates to me when either a) it passes clean or b) there is something that genuinely needs my experience.

This is agentic engineering, not vibe coding.

> The enterprise version of that is I don’t want a CRM unless at least two other giant enterprises have successfully used that CRM for six months. [...] You want solutions that are proven to work before you take a risk on them.

Perhaps not for every category of software and every company. But in practice, any SaaS app that is just CRUD with some business logic + workflows is, imo, absolutely vulnerable to losing customers because people within their customers' orgs vibe coded a replacement.

They are perhaps even more at risk because would-be new customers don't ever even bother searching to find them as an option because they just vibe code a competitor in-house.

The vulnerability lies primarily in the fact that most of these SaaS apps were talking about are _wrong_ to some meaningful degree. They don't fully fit how your company works, and they never did. There is something about them that you are forced to work around in some way. This is true because it is impossible to build a universally perfect product, to perfectly fit it to every business requirement of every user in every company.

But now it is relatively cheap to build the perfect version for your company in-house. Or maybe even just for YOU.

I think medium/long-term this will mean a redistribution of technical talent from SaaS companies to industry companies. Instead of paying millions for SaaS subscriptions, industry companies will spend fewer millions building precisely what they need in-house with the help of AI. Not every SaaS and not every company, but I already see this happening at my company right now.

I'm not checking the code since the code doesn't really matter anymore anyways - I just have the agent write passing tests for the changes or additions I make, and so even if something breaks I can just point to the tests.

Some days, the tickets are completed much faster than I expect and I don't hit my daily token expenditure goal, so I have my own custom harness that actually hooks up an agent to TikTok, basically it splits up the reel into 1 second increments and then feeds those frames to the LLM for it's own consumption. I can easily burn 10m tokens a day on this, and Claude seems to enjoy it.

Personally I want to thank you Simon for putting me onto this "vibe engineering" concept, I really didn't expect an archaeology major like myself to become a real engineer but thanks to AI now I can be! Truly gatekeeping in tech is now dead.

Disclaimer: I'm doing a CAD-like engineering desktop app, and I'm using VS 2026 Copilot, so YMMV.

When I get a Jira ticket, I will first diagnose the problem, and then ask AI to write a test case for it that will reproduce the problem, with guidance on what/how to do the test case (you will be surprised to know how many geometry, seemingly visual problems can be unit tested), and if necessary I provide clues (like which files to read, etc.) for AI to look at, and ask AI to just go and fix the test.

Often AI can do that; AI can make the test pass and make sure that adjacent tests also pass. If in doubt, I will check the output reasoning. I then verify that the fix is done properly via visual inspection (remember, this is a desktop app), and I ask for clarification if needed.

Then at night I'll let my automated test suites run... and oops! Regression found! Who broke it? AI or human? Who cares. I just tell AI that between these times one of the commits must have broken the code — can you please fix it for me? And AI can do that.

This works for small or medium feature implementation, trival bugfixes, or even annoying geometrical problems that require me to dig out the needle in the haystack. So the productivity gain is very real. But I haven't tried it on feature that requires weeks or months for implementation, maybe I should try it next time.

It's hard to describe the feeling. It's just that the AI is working like a very capable (junior?) programmer; both might not have full domain knowledge, but with strong test suites and senior guidance, both can go very far. And of course AI is cheaper and a lot more effective.

I took a rock carving course in school that really enlightened me about software engineering, and it still applies today, especially to AI. You can't just decide what you want to carve, hold the chisel in just the right spot, and whack it with a hammer just perfectly so all the rock you want falls away leaving a perfect statue behind.

"I saw the angel in the marble and carved until I set him free." -Michelangelo

It's a long drawn out iterative process of making millions of tiny little chips, and letting the statue inside find its way out, in its natural form, instead of trying to impose a pre-determined form onto it.

Vibe coding is hoping your first whack of the hammer is going to make a good statue, then not even looking at the statue before shipping it!

But AI assisted conscientious coding (or agentic engineering as Simon calls it) is the opposite of that, where you chip away quickly and relentlessly, but you still have to carefully control where you chisel and what you carve away, and have an idea in your mind what you want before you start.

I find the LLM as interactive tutor reviewing my work in a proof checker to be a really killer combo.

"I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it’s just going to do it right. It’s not going to mess that up. You have it add automated tests, you have it add documentation, you know it’s going to be good."

This really is Wordpress and early PHP all over again, but it's the seasoned folks rather than the amateurs that buy into it.

I believe these tools will be refined and locked down and eventually turn into RAD stuff used by certified enterprise consultants, much like SAP and Salesforce and IBM solutions and so on. From this I come to the conclusion that it is not a good idea to become dependent on them at this stage, which is corroborated by the pecuniary expense as well as excruciatingly fast change in available products.

My side project is 80% vibe code. Every now and then I look and see all the bad stuff, then I scold Codex a bit and it refactors it for me. So I do see the author's point.

How is producing more lines of code any good? How does quality assurance work with immeasurable code bloat? I want good software not slopware with 2000 different features. A good product does few things, but does these really well. There is no need to constantly add lines of code to a working product.

You have no clue what went into the training data or how much of the output is covered by someone else's copyright. To pretend this is "responsible" is ridiculous.

Then you go on to use lines of code per day as a meaningful metric without any evidence that it has any consequence whatsoever.

Finally you don't mention profitability once.

What are we even doing here? Pretending? Why?

Some of the usual suspects when people are getting bad results: * Overbloated claude.md, it should not contain everything, it should be a table of contents pointing to other files * Max effort - why? Overthinking on simpler tasks results in degraded quality, much like in humans. * You speak of your single session but with agents reviewing other agent outputs. Without knowing your goal and your prompt, and what the agents had access to, my first inclination is that the initial request was vague, a bunch of unnecessary info was returned, and your review step caught that extra jank.

I'm not gonna bother making the joke you allude to, but every single employee I've worked with in person has had glaring holes in their setups which, once solved, dramatically reduced stuff like what you're talking about.

No one is suggesting that.

Rather, I just feel like I have to constantly remind myself of the impermanence of all things. Like snow, from water come to water gone.

Perhaps I put too much of my identity in being a programmer. Sure, LLMs cannot replace most us in their current state, but what about 5 years, 10 years, ..., 50 years from now? I just cannot help be feel a sense of nihilism and existential dread.

Some might argue that we will always be needed, but I am not certain I want to be needed in such a way. Of course, no one is taking hand-coding away from me. I can hand-code all I want on my own time, but occupationally that may be difficult in the future. I have rambled enough, but all and all, I do not think I want to participate in this society anymore, but I do not know how to escape it either.

An ace software engineer is not an ace because of tooling.

It's not the plane, it's the pilot, or something like that.

Can agentic engineers adhere to a similar code of ethics that a professional engineer is sworn to uphold?

https://www.nspe.org/career-growth/nspe-code-ethics-engineer...

I'm working on a licensing system for a product I'm building. I've used Claude a little bit to help out with it, but it's also made a lot of very dumb decisions that would have large (security!) consequences if I didn't catch them. And a lot of them are braindead things, like I asked it to create a configurable limit on a certain resource for the trial version of the application. When I said configurable, I mostly meant: put the number in a constant so I can update it later. What Claude thought I asked was "make it so the user can modify the limits of the trial version in the settings panel" (which defeats the entire purpose of a free trial!). Another thing it messed up recently is I was setting up email-magic-link authentication. It defaulted to creating an account for anyone that typed in an email, which could allow a bad actor to both spam people with login requests (probably getting me kicked off Resend) or creating a lot of bogus accounts.

These things do not think. You cannnot outsource your thinking to them.

>I firmly staked out my belief that “vibe coding” is a very different beast from responsible use of AI to write code, which I’ve since started to call agentic engineering

Disturbing? Really? I admit I don't do agentic and am going only by vibes, but for me agentic engineering is basically vibe coding in a automated loop with some ornamentals. They both stem from the same LLM root and positioning them as significantly different is weird and unconvincing to me. There may be a merit to this article (I gave up after few sentences), but I reject this specific premise.

The most important part and why slop isn't the same as a code written by someone else. The model doesn't care, it just produces whatever it is asked to produce. It doesn't have pride, it doesn't have ego, it doesn't artisanal qualities, it doesn't have ownership.

Do this enough times, and I will have forgotten how to think.

Fast feedback loops and delegating tasks to sub-agents have been pretty common for vibers since well before they were canonicalized by agenteers. Same thing, different day, hardly even any difference in quality: they evolve together, though vibe tends to lead and agents follow and refine... which vibers then use too.

If you think of vibe coders as agentic alpha testers it makes a lot more sense.

Makes me want to just give up programming forever and never use a computer again.

Like many people I have used AI to generate crap I really don't care about. I need an image. Generate something like, whatever. Great hey a good looking image! No that's done I can do something I find more interesting to do.

But it's slop. The image does not fit the context. Its just off. And you can tell that no one really cared.

This isn't good.

That's the spirit, I always say - _others_ will deal with AI slop during code review. Eventually they will get tired and start 'reviewing' this AI stuff with AI - so it's a win win. Right?

Companies are shipping things and nobody understands what they're shipping.

Same thing happens in other fields. A rich country and a poor country might build equivalent roads, but they won't pay the same price for them.

What would normally be considered overengineered gold plating is "free" now.

Caring about the result, whether one "can tell the difference" or not.

Companies have been enforcing technology mandates since time immemorial. In the early 2000s there were definitely a lot of mandates to move away from commercial UNIX to Linux. Lots of companies began enforcing the switch to PHP, Ruby and Python for new projects.

If it is, the fall out will be way worse than if AI ends up living up to (reasonable) expectations.

If it doesn’t, we are going to see over a trillion dollars of capital leave the tech sector, which I think will have worse impacts on the livelihood of tech workers than if AI ends up panning out.

This is something the naysayers need to grapple with. We’ve crossed a line where this tech needs to work simply because of the amount of money depending on that fact.

Whether that happens or not is a different question, but I believe that's what they're suggesting.

What you're suggesting is a negative flywheel where quality spirals down, but I'm hoping it becomes a positive loop and the quality floor goes up. We had plenty of slop before LLMs, and not all LLM output is slop. Time will tell, but I think LLMs will continue to improve their coding abilities and push overall quality higher.

you can also execute larger tasks than this using subagents to divide the work so each segment doesn’t exceed the usable context window. i regular execute tasks that require hundreds of subagents, for example.

in practice the context window is effectively unlimited or at least exceptionally high — 100m+ tokens. it just requires you to structure the work so it can be done effectively — not so dissimilar to what you would do for a person

With such a low baseline, there is an optimistic perspective that LLMs could improve the situation. LLMs can produce excellent code when prompted or reviewed well. Unlike human employees, the model does not worry about getting a 'partially meets expectations' rating or avoid the drudgery of cleaning up other people's code.

It's not immediate, it still takes weeks if you want to actually do QA and roll out to prod, but it's definitely better than the pre-LLM alternatives.

It's like like if your context window with one agent is n, your context window with 10 agents is n/10. It is some skill, but that is also where a lot of the advances are coming in.

Write lots of code now and statistically look great, while the impact won’t be felt for a much larger range of time.

With the job search and whatnot then yeah, caring becomes a lot more important. That’s true.

AI will make this dynamic worse, and it's got the extra danger of the default banal way of applying the technology in fact encourages it's application to that end.

I could have learn all the frameworks to make it, but honestly I wouldn't have bothered.

> If you're at work and they really care about getting something out of the door, do whatever you think is best.

If you don’t mind being jobless, sure do whatever you think is best. Not all of us can simply switch companies easily. Folks need to realise that AI in a company setting works for the benefit of the company, not for the individual.

When it got dangerous to spend that kind of time without a bullet-point deliverable.

And no, this isn't playing what ifs.

I have seen it happening with offshoring, migration to cloud, serverless, SaaS and iPaaS products, and now AI powered automations via agents.

Less devops people, less backend devs , no translation team, no asset creation team,...

I have been layoff a few times, having to do competence transfer to offshoring teams, the quality of the output is something c suites don't care all.

Do you wanna bet what is behind Microslop, Apple Tahoe bugs and so forth?

When they start plateauing, then we can assume they're done progressing.

But the real trick isn't "number of personal projects", but how weird they are. There's no "rational" reason to do them, they don't increase the person's marketability / hireability. They are done purely for intrinsic reasons.

(On reflection, this also seems to be a pretty robust predictor of autism. :)

Now we have influx of people with not a single shred of technical knowledge thinking they can create something.

I have a co-worker in another team that write java endpoins we consume. I can tell him what I need and I trust the output. I don't need to know java to trust him, it doesn't mean I don't want to learn.

There are thousand examples like this across every stack and abstraction level. From ssh-handshakes to gps.

Sure my co-worker is fundamentally different from a compiler which is fundamentally different from an LLM.

My argument is that the chain-of-trust where you offload knowledge to an external source is identical. We do it all the time but somehow doing it with an LLM means we no longer want to learn?

This is true in macro, but I think we're specifically referring to LLM-generated /assisted code (vibe-coding). 'Getting something out the door' is not an necessarily in reference to an AI-infused product, just new code written by AI

> Of course you can ask your agent to try several different things and pick the best, or ask it to recommend architectural improvements that would make a given change easier

The ideal solution increasingly seems to be encoding everything that differentiates a good engineer from a bad engineer into your prompt.

But at that point the LLM isn’t really the model as much as the medium. And I have some doubts that LLMs are the ideal medium for encoding expertise.

The Pragmatic Programmer book has whole chapters about this. Ultimately, you either solve the problem analogously (whiteboard, deep thinking on a sofa). Or you got fast as trying out stuff AND keeping the good bits.

That's not my experience... mostly it's about first interrogating the actual problem with the customer and conditions under which it occurs. Maybe we even have appropriate logging in our production application? We usually do, because you know, we usually need to debug things that have already happened.

(If it's new/unreleased code, sure fine, let's find a debugger.)

The way you apply the expert loop is to be the expert. "Can we try this...", "have you checked that...", "but what about...".

To some degree you can try to get agents to work like this themselves, but it's also totally fine (good, actually) to be nudging the work actively.

Now that ratio is swinging way over towards the LLMs favor.

this incongruence pushes people back to using just GET and POST methods in flexible and overloaded ways

Agentic engineering knows all the best practices and ways to get around these limitations in the most compatible way and cranks out full APIs with all the verbs

I see a disconnect between these two camps that will probably cause a lot of chaos in the near future. Those that figure it out will thrive.

and the whole world suffers for it.

Isn’t this just because you have seen a lot of PRs from inexperienced engineers? People learn LLM behavior over time, too.

I swear I'm living through mass hysteria.

You instruct it to write the code you want to be written. You still have to know how to develop, it just makes you faster.

Although this requires you to take pride in your profession and what you do.

Good way of putting it.

So I’m pretty skeptical that reviewing 2000 lines of code won’t take any more time than reviewing 200 lines of code.

Furthermore how do you know the AI generated lines are the open highway lines of code and not the mountain road ones? There might be hallucinations that pattern match as perfectly reasonable with a hard to spot flaw.

I can with full confidence say that the code AI writes is more robust and safe than if I would have done it myself. The code definitely becomes more bloated though.

I think, and I recognize it is mostly against the 'agentic' push, I will stick with slow iteration.

I can generate a lot of tests amounting to assert(true). Yeah, LLM generated tests aren't quite that simplistic, but are you checking that all the tests actually make sense and test anything useful? If no, those tests are useless. If yes, I don't actually believe you.

It's the typical 10 line diff getting scrutinized to death, 1000 line diff: Instant LGTM.

Pay attention to YOUR OWN incentives.

I do this too, but then I sit and observe how agent gets very creative by going around all of these layers just to get to the finish line faster.

Say, for example, if I needlessly pass a mutable reference and the linter screams at me, I know it's either linter is wrong in this case, or I should listen to it and change the signature. If I make the lazy choice, I will be dissatisfied with myself, I might even get scolded, or even fired if I keep making lazy choices.

LLM doesn't get these feelings.

LLM will almost always go for silencing it because it prevents it from reaching the 'reward'. If you put guardrails so that LLM isn't allowed to silence anything, then you get things like 'ok, I'll just do foo.accessed = 1 to satisfy the linter'.

Same story with tests. Who decides when it's the test that should be changed/deleted or the implementation?

Good code for a business is robust code, that's functionally correct, efficient where it needs to be and does not cost too much.

I believe most developers who care about good code are trying to articulate this, they care about a strong system that delivers well, which comes from good architecture.

LLMs actually deliver pretty well on the more trivial code cleanlines stuff, or can be made to pretty trivially with linters, so I don't think devs working with it should be worried about that aspect.

What is changing fast is that last point I mentioned, "that doesn't cost too much" because if you can get 70% of the requirements for 10% of the perceived up front cost, that calculus has changed. But you are not going to be getting the same level of system architecture for that time/cost ratio. That can bite you later, as it does often enough with human coders too.

There are people who write software for hedge funds, quant firms, aviation and defense systems, data center providers, major telecom services used by hospitals and emergency services and semiconductor firms and the big oil and energy companies and that is NOT "almost no-one" and these companies see and make hundreds of billions of dollars a year on average.

This is even before me mentioning big tech.

Perhaps the work most here on this site are doing is not serious enough that can be totally vibe-coded and are toy projects and bring in close to $0 for the company to not care.

What I am talking about is the software that is responsible for being the core revenue driver of the business and it being also mission critical.

>> I think all coding will become vibe coding...

Nope. First of all, Let's get the true definition of "vibe coding" completely clear from the first mention of it from Karpathy. From [0]:

>> "There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." [0]

>> "I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away." [0]

So with the true definition, you are arguing that all coding will become "vibe-coding" and that includes in mission critical software. Not even Karpathy would go as far as that and he's not even sure that he even knows that it works..."mostly".

Responsibility is what cannot be vibe-coded. The major cloud providers and the tech companies that own them have contracts with their customers which is worth billions to their revenue. That is why they cannot afford to "vibe-code" infra that causes them to lose $100M+ a hour when a key part of their infra goes down or stops working.

So:

> Like, Claude Code as we all know is clearly vibe-coded and is already a 10-billion (and rapidly increasing!) dollar system.

That is not vibe-coded anymore and it is maintained by software engineers who look at the code at all times, daily before merging any changes; AI generated or not.

> Google Search and various Meta apps meet those criteria and people are already using LLMs on that code, and will soon be "vibe coding" as I described it.

Nope. As Karpathy described it, that would never happen and human software engineers will be reviewing the agents code all the times. But that would not be vibe-coding would it?

> AWS meets that criteria and has already had an LLM-caused outage!

Are they vibe coding now after that outage? I bet that they are not.

> After all, all the cloud providers have been having outages long before the age of LLMs.

That isn't the point. Someone was held to account for the outages and had to explain why it happened.

They will lose trust + billions of dollars if they admitted that they vibe-coded their entire infra and had 0 engineers who don't understand why it went wrong.

> The thing most people are missing is that code is cheap, and so automated validations are cheap, and you get more bang for the buck by throwing more code in the form of extensive tests and validations at it than human attention.

The risk is amplified with the companies reputation on the line and it's very expensive to lose. I'm talking in the hundreds of billions annually and a 10% loss of global revenues due to constant outages can cause the stock to fall.

So you do understand the contradiction you said earlier about AWS indeed strengthens my point on the limitations on vibe coding especially on mission critical software?

[0] https://x.com/karpathy/status/1886192184808149383

This means different things to different people, lot of people enjoy the process of engineering solutions with LLM agents, build out tailored skilled, custom approaches that make up their own flavour "agentic" workflow. There are also people who find joy in Javascript that other people cannot understand why. And other people again love system languages or even tinkering with assembly etc.

What I wanted to say is that LLM use does not automatically mean people just want to get results faster, there are still nerds enjoying the process of working with these new tools.

People used to like them and they used to be legends (even if not everyone liked them)

Notch, Woz, Linus and Geohot come to mind

The Metasploit creator Dean McNamee worked for me and he was just like that and a total monster at engineering hard tech products

Software developers get paid big money because they can speak alien, the only thing that is changing is the dialect.

Perhaps these “obstinate” engineers have good reason in their decision. And it should be their decision!

To be so confident in what is “the right way (TM)” and try to force it onto others is... revealing.

I have heard this statement every single day for 2 years and yet we still have no companies compressing 10 years into 1 year thus exploding past all the incumbents who don't "get it".

After 18 months the hard evidence is in place. And much like replacing bare-metal servers for many use cases where evidence shows that the burden of k8s or the substitution of shell scripts for Terraform, it's time to move on.

I don't really see a place for no AI usage in line-of-business software apps anymore.

The first line of code was written on November 25th. It achieved adoption in the "personal agents" space that far exceeded the other companies that had tried the same thing.

(Whether or not you trust the quality of the software you can't deny the impact it had in such a short time. It defined a new category of software.)

Why do I not see 5x as many interesting greenfield projects than before?

It's like I never wrote them, because I didn't. I've got the gist of them, but it's the same way I get the gist of something like Numpy: I know how it works theoretically, but certainly not specifically enough to jump in and write some working Fortran that fixes bugs or adds features.

I now have a bunch of stalled projects I'm not very familiar with. I no longer do solo green field projects that way.

That's a big if. I don't have numbers but most professional engineers are not working on such projects

> but effective agentic systems form when you first erase your preconceived notions of how intelligence works and actually study this non-human intelligence and find new ways to apply it.

There's no reason you can't make good use of them and learn how to do it more reliably and predictably, it's just chasing those gains through a human intelligence-like model because they use human language leads to more false starts and local maxima than trying to understand stand them as their owb systems.

I don't think it should even be a particularly contentious point: we humans think differently based on the languages we learn and grew up with, what would you expect when you remove the entire common denominator of a human brain?

We can't choose if the LLM is like us unless you want to go back 10-20 years in time and choose a new direction for AI/ML.

We stumbled upon an architecture with mostly superficial similarities to how we think and learn, and instead focused on being able to throw more compute and more data at our models.

You're talking about ergonomics that exist at a completely different layer: even if you want to make LLM based products for humans, around humans, you have to accept it's not a human and it won't make mistakes like a human (even if the mistakes look human) -

If anything you're going to make something that burns most people if you just blindly pretend it's human-like: a great example being products that give users a false impression of LLM memory to hide the nitty gritty details.

In the early days ChatGPT would silently truncate the context window at some point and bullshit its way through recalling earlier parts of the conversation.

With compaction it does better, but still degrades noticeably.

If they'd exposed the concept of a context window to the user through top level primitives (like being able to manage what's important for example), maybe it'd have been a bit less clean of a product interface... but way more laypeople today would have a much better understanding of an LLM's very un-human equivalent to memory.

Instead we still give users lossy incomplete pictures of this all with the backends silently deciding when to compact and what information to discard. Most people using the tools don't know this because they're not being given an active role in the process.

Sounds like a human? The ‘statistical’ part is arguable, I suppose.

Unfortunately, a lot of workplaces are ignoring this, believing their engineers are assembly line workers, and the ones who complete 10 widgets per minute are simply better than the ones who complete 5 widgets per minute.

To me, none of this feels like "going faster", it feels like "opening up possibilities to try more things, with a lot less tedious work".

My nonexistent backend isn’t going to be pwned if there is a bug in the thumbnail generation.

After the QA testing on my device, a quick scroll through of the code is enough.

Maybe prompt „are errors during thumbnail generation caught to prevent app crashes?“ if we‘re feeling extra cautious today.

And just like that it saved a day of work.

First of all, building a system that constrains the output of the AI sufficiently, whether that's typing, testing, external validation, or manual human review in extremis. That gets you the best result out of whatever harness or orchestration you're using.

Secondly, there's the level at which you're intervening, something along the hierarchy of "validate only usage from the customer perspective" to "review, edit, and validate every jot and tiddle of the codebase and environment". I think for relatively low importance things reviewing at the feature level (all code, but not interim diffs) is fine, but if you're doing network protocol you better at least validate everything carefully with fuzzing and prop testing or something like that.

And then you've got how you structure your feedback to the LLM itself - is it an in-the-loop chat process, an edit-and-retry spec loop, go-nogo on a feature branch, or what? How does the process improve itself, basically?

I agree with you entirely that the responsibility rests on the human, but there are a variety of ways to use these things that can increase or decrease the quality of code to time spent reviewing, and obviously different tasks have different levels of review scrutiny, as well.

It'll even suggest it

You want a single RPC websocket go for it

That would imply that either the person in question has infinite time, or has access to all software that could ever be of utility to them, which seems unlikely.

So yeah, I guess the value of doodles has shot up simply because of optics.

Somewhere else in this comment section someone tried to broaden the definition of nerd so much so that pretty much anybody who is a consummate professional is also a nerd. The hill I will die on is that people don't actually dislike all this new AI stuff but more so the attitude of people heavily invested in it.

And to add another data point regarding your hill my drawing/painting moment was NLP stuff. Now if I want to do (rudimentary) sentiment analysis or keyword extraction I can lean on a local LLM. Yet I don't go around yelling Snowball (I think?) is obsolete.

I expect we will start seeing the impact of the new coding agent enhanced development processes over the next few months.

https://www.reuters.com/technology/openclaw-enthusiasm-grips...

Some version of that happens in every big company or every long running app. Claude isn’t AGI and that prompt isn’t nearly specific enough for anything outside of greenfield.

- that you spend no amount of time looking things up, reorganising, or otherwise getting stuck

- that you have a solution to the problem ready to go at all times

- that your solution is better than the LLM's solution

I highly, highly doubt that all 3 of these are true. I doubt even 1 of them is true, I think you just don't know how to use LLMs in a focused way.

I've been trying to get into agentic coding and there are non-refactoring instances where I might reac for it (like any time I need to work on something using tailwind; I'm dyslexic and I'd get actual headaches, not exaggerating, trying to decipher Tailwind gibberish while juggling their docs before AIs came around)

  {x{x,sum -2#x}/0 1}

  def f(n):
      if n <= 1:
          return n
      else:
          return f(n-1) + f(n-2)

I started as a skeptic and have similarly drank the kool-aid. The reality is AI can read code faster than I can, including following code paths. It can build and keep more context than I can, and do it faster as well. And it can write code faster than I can type. So the effort to learn how to tell it what to do is worthwhile.

Video thumbnails are a different beast altogether. And you might want to double check your assumptions about security considerations. If any of your ffmpeg, opencv, pyscenedetect code is running on your server, it might well be exploitable.

Cryptocurrencies? Barely any other use than money laundering, buying drugs and betting on the outcome of battles in war. And NFTs? No use at all other than money laundering and setting money ablaze.

This assumes that shorter code is faster to write. To quote Blaise Pascal, "I would have written a shorter letter, but I did not have the time."

> Can you deliver value without lines of code?

No, but you can also depreciate value when you stuff a codebase full of bloated, bug-ridden code that no man or machine can hope to understand.

It took quite some time to figure out what works and what triggers it. However I don’t know it’s the same for RSI.

I’m grateful for the ability to use speaking as a second option, but utilizing both I can’t cope that speaking is even remotely close to typing :/

If you assume they are not idiots and analyze the FOMO incentives via a little game-theory, it becomes clear why.

Assuming the competition has adopted AI, leadership can ignore it, or pursue it. If they adopt it, then they are level with the completion whether AI actually succeeds or fails - they get to keep their executive job.

If leadership ignores AI, and it actually delivers the productivity gains to the competition, they will be fired. If they ignore AI and it's a bust, they gain nothing.

I think 3.5 would probably need more frequent intervention than a lot of harnesses give. But I bet 4 could do a simple JSON API one-shot with the right harness. Just back then I had to manually be the harness.

I'd have thought someone who's so enamoured with the tech would have at least a basic understanding of how it works.

There's a cycle that is needed for good system design. Start with a problem and an approach, and write some code. As you write the code, you reify the design and flesh out the edge cases, learning where you got the details wrong. As you learn the details, you go back to the drawing board and shuffle the puzzle pieces, and try again.

Polished, effective systems don't just fall out of an engineers head. They're learned as you shape them.

Good engineers won't continue to be good when vibe-coding, because the thing that made them good was the learning loop. They may be able to coast for a while, at best.

Good engineers are also capable of managing expectations. They can effectively communicate with stakeholders what compromises must be made in order to meet accelerated timelines, just as they always have.

We’ve already had conversations with overeager product people what the ramifications are for introducing their vibe coded monstrosities:

  - Have you considered X?
  - Have you considered Y?

If that’s not the situation where you work, then unfortunately it’s time to start playing politics or find a new place to work that knows how to properly assess risk.

- I've taken a controversial new pill that accelerates my brain.

-- So you're smart now?

- I'm stupid faster!

That being said, being stupid faster can work if validation is cheap (and exists in the first place).

Turns out "eh close enough" for AGI is just stupidity in an "until done" loop. (Technically referred to as Ralphing.)

I estimate that I'm now spending about 10 to 30 hours less time a week in the mechanical parts of writing and refactoring code, researching how to plumb components together, and doing "figure out how to do unfamiliar thing" research.

All of those hours are time that can now be spent doing "careful consideration" (or just being with my family or at the gym or reading a book, which is all cognitively valuable as well).

Now, I suppose I agree that if timelines accelerate ahead of that amount of regained time, then I'm net worse off, but that's not the current situation at the moment, in my experience.

Or at least, the limit is increasing by the day.

I’m not denying (at all) that unused skills languish. I take issue with AI being characterized as a magic eraser that mystically makes people forget what they have already learned. I’ve just done a study and concluded that dogs gets dumber when I throw a ball. What’s my evidence? They stop staring at me to chase it. The ball definitely made them forget who I was, so we shouldn’t allow dogs to have balls anymore.

Can AI make developers lazy in new ways? Of course! Why wouldn’t it? I don’t write things in ASM because I can be “lazy” and write 50x more useful instructions with a few lines of a modern language. I doubt I’d be able to write working ASM anymore without a serious refresher. Did newer languages erase my memory of ASM and make me “lazy”, or did my efforts evolve to make use of the newest technology regardless of “lost” skills?

2. There absolutely are cases where modifying code "manually" is unquestionably faster than prompting an LLM. There are trivial examples for this - eg only an insane person would ask an LLM to rename a variable rather than using an LSP for that. It would provably and consistently take more keystrokes. There are less trivial examples as well, like, you know, having an understanding of your codebase and using good abstractions/libraries within it that let you make large changes to the program's behavior with little boilerplate code.

One can argue that producing a lot of complex changes through an LLM is faster, which I would agree with, but then see point #1. Sustainable software development has up to this point relied on iterative discovery of the right small components that together form a complete, functional, stable system (see "Programming as Theory Building").

There's zero indication so far that LLMs are capable of speeding up the process of creating complete, functional, stable systems. What every org within my career and friend circle is seeing (and research into productivity impacts of LLMs on software development is showing) is the same story - fast prototypes that either turn into abandonware, personal tools, or maintenance nightmares.

And this isn't an excuse btw, but if you want to understand why, this is a good place to start.

Have you seen the quotes coming out of the richest/most powerful companies on the planet? These are very intentional impacts by companies more powerful than entire nations.

I don't think 'but your willpower' stands a chance if you want to be connected to the modern world.