I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it sounding like this is the future, I just feel discouraged because it sounds like so much work and I've tried using coding agents and they help a bit, but I find it way less fun to be waiting around for agents to do stuff and it's way harder to get into flow state managing multiple of these things. It makes me want to move into something completely different like sales
I'm really sorry to hear this, because part of my goal here is to help push back against the idea that "programming skills are useless now, anyone can get an LLM to write code for them".
I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of tools.
I said a version of this in the post:
> AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents.
A brand new vibe coder may be able to get a cool UI out of ChatGPT, but they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere. They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills. It doesn't work like tools developers use and it doesn't work like people developers work with. Furthermore, techniques of working with agents today may be completely outdated a year from now. The acceleration is also inconsistent: sometimes there's an acceleration, sometimes a deceleration.
Generative AI is at the same time incredibly impressive and completely unreliable. This makes it interesting, but also very uncertain. Maybe it's worth my investment to learn how to master today's agents, and maybe I'd be better off waiting until these things become better.
You wrote:
> Getting good results out of a coding agent feels uncomfortably close to getting good results out of a human collaborator. You need to provide clear instructions, ensure they have the necessary context and provide actionable feedback on what they produce.
That is true (about people) but misses out the most important thing for me: it's not about the information I give them, but about the information they give me. For good results, regardless of their skill level, I need to absolutely trust that they tell me what challenges they've run into and what new knowledge they've gained that I may have missed in my own understanding of the problem. If that doesn't happen, I won't get good results. If that kind of communication only reliably happens through code I have to read, it becomes inefficient. If I can't trust an agent to tell me what I need to know (and what I trust when working with people) then the whole experience breaks down.
> I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills.
If you’ve be been tasked with leadership of an engineering effort involving multiple engineers and stakeholders you know that this is in fact a crucial part of the role the more senior you get. It is much the same with people: know their limitations, show them a path to success, help them overcome their limitations by laying down the right abstractions and giving them the right coaching, make it easier to do the right thing. Most of the same approaches apply. When we do these things with people it’s called leadership or management. With agents, it’s context engineering.
Because I reached that position 15 years ago, I can tell you that this is untrue (in the sense that the experience is completely different from an LLM).
Training is one thing, but training doesn't increase the productivity of the trainer; it's meant to improve the capability of the trainee.
At any level of capability, though - whether we're talking about an intern after one year of university or a senior developer with 20 years of experience - effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know. We may not be talking 100% of trust, but not too far from that, either. You can't continue working with someone that doesn't tell you what you need to know even 10% of the time, regardless of their level. LLMs are not at that acceptable level yet, so the experience is not similar to technical leadership.
If you've ever been tasked with leading one or more significant projects you'd know that if you feel you have to review every line of code anyone on the team writes, at every step of the process, that's not the path to success (if you did that, not only would progress be slow, but your team wouldn't like you very much). Code review is a very important part of the process, but it's not an efficient mechanism for day-to-day communication.
> effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know
Nope, effective management is on YOU, not them. If everyone you’re managing is completely transparent and immediately tells you stuff, you’re playing in easy mode
no, the point is LLMs will behave the same way humans you have to manage do (there's obviously differences - eg LLMs tend to forget context more often than most humans, but also they tend to know a lot more than the average human). So some of the same skills that'll help you manage humans will also help you get more consistency out of LLMs.
I don't know of anyone who would like to work with someone who lies to them over and over, and will never stop. LLMs do certain things better than people, but my point is that there's nothing you can trust them to do. That's fine for research (we don't trust, and don't need to trust, any human or tool to do a fully exhaustive research, anyway), but not for most other work tasks. That's not to say that LLMs can't be utilised usefully, but something that can never be trusted behaves like neither person nor tool.
The person you are responding to is quite literally making the same point. This entire thread of conversation is in response to the post's author stating that using a coding agent is strongly akin to collaborating with a colleague.
> Yes, I want to play in easy mode. Why would I want to play in hard mode?
Working alone can be much easier than managing others in a team. But also, working in a team can be far more effective if you can figure out how to pull it off.
It's much the same as working with agents. Working alone, without the agents, it's easier to make exactly what you want happen. But working with agents, you can get a lot more done a lot faster-- if you can figure out how to make it happen. This is why you might want hard mode.
The vast majority of managers, much like most engineers, only has to deal with “maintenance mode” throughout most of their career. Particularly common in people whose experience has been in large corporations - you simply don’t realize how much was built for you and “works” (even if badly)
> effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know
This is what we shoot for, yes, but many of the most interesting war stories involve times when people should have been telling you about snags but weren't-- either because they didn't realize they were spinning their wheels, or because they were hoping they'd somehow magically pull off the win before the due date, or innumerable other variations on the theme. People are most definitely not reliable about telling you things they should have told you.
> if you feel you have to review every line of code anyone on the team writes...
Somebody has to review the code, and step back and think about it. Not necessarily the manager, but someone does.
> the most interesting war stories involve times when people should have been telling you about snags but weren't-
This comes up a lot. A person sometimes does an undesirable thing that an AI also does. So you might as well use the AI.
But we don't apply this thinking to people. If a person does something undesirable sometimes then we accept that because they are human. If they do it very frequently then at some point, given a choice, you will stop working with that person.
1000% this. Today LLMs are like enthusiastic, energetic, over-confident, well-read junior engineers.
Does it take effort to work with them and get them to be effective in your code base? Yes. But is there a way to lead them in such a way that your "team" (you in this case) gets more done? Yes.
But it does take effort. That's why I love "vibe engineering" as a term because the engineering (or "senior" or "lead" engineering) is STILL what we are doing.
Inconsistent performance and frequent lies are a crucial part of the role, really? I've only met a couple of people like that on my career. Interviews go both ways: if I can't establish that the team I'll be working with is composed and managed by honest and competent people, I don't accept their offer. Sometimes it has meant missing out on the highest compensation, but at least I don't deal with lies and inconsistent performance.
Test-driven development helps protect against wrong code, but it's not code I'm interested in, and it's not wrong code that I'm afraid of (I mean, that's table stakes). What I need is something that would help me generate understanding and do so reliably (even if the performance is poor). I can't exercise high-level knowledge efficiently if my only reliable input is code. Once you have to work at the code level at every step, there's no raising of the level of thought. The problem for me isn't that the agent might generate code that doesn't pass the test suite, but that it cannot reliably tell me what I need to know about the code. There's nothing I can reliably offload to the machine other than typing. That could still be useful, but it's not necessarily a game-changer.
Writing code in Java or Python as opposed to Assembly also raises the level of abstract thought. Not as much as we hope AI will be able to do someday, but at least it does the job reliably enough. Imagine how useful Java or Python would be if 10% of the time they would emit the wrong machine instructions. If there's no trust on anything, then the offloading of effort is drastically diminished.
In my experience with Claude Code and Sonnet, it is absolutely possible to have architectural and design-oriented conversations about the work, at an entirely different and higher level than using a (formerly) high-level programming language. I have been able to learn new systems and frameworks far faster with Claude than with any previous system I have used. It definitely does require close attention to detect mistakes it does not realize it is making, but that is where the skill comes in. I find it being right 80% of the time and wrong 20% of the time to be a hugely acceptable tradeoff, when it allows me to go radically faster because it can do that 80% much quicker than I could. Especially when it comes to learning new code bases and exploring new repos I have cloned -- it can read code superhumanly quickly and explain it to me in depth.
It is certainly a hugely different style of interaction, but it helps to think of it as a conversation, or more precisely, a series of individual small targeted specific conversations, each aimed at researching a specific issue or solving a specific problem.
Indeed, I successfully use LLMs for research, and they're an improvement because old-school search isn't very reliable either.
But as to the 80-20 tradeoff on other tasks, the problem isn't that the tool is wrong 20% of the time, but that it's not trustworthy 100% of the time. I have to check the work. Maybe that's still valuable, but just how valuable that is depends on many factors, some of which are very domain-dependent and others are completely subjective. We're talking about replacing one style with another that is much better in some respects and much worse in others. If, on the whole, it was better in almost all cases, that would be one thing (and make the investment safer), but reports suggest it isn't.
I've yet to try an LLM to learn a new codebase, and I have no doubt it will help a lot, but while that is undoubtedly a very expensive task, it's also not a very frequent one. It could maybe save me a week per year, amortised. That's not nothing (and I will certainly give it a try next time I need to learn a new codebase), but it's also not a game-changer.
Without meaning to sound flippant or dismissive, I think you're overthinking it. By the sounds of it, agents aren't offering what you say you need. What are _are_ offering is the boilerplate, the research, the planning etc. All the stuff that's ancillary. You could quite fairly say that it's in the pursuit of this stuff where details and ideas emerge and I would agree, but sometimes you don't need ideas. You need solutions which are run-of-the-mill and boring.
I'm well aware that LLMs are more than capable enough to successfully perform straightforward, boring tasks 90% of the time. The problem is that there's a small but significant enough portion of time where I think a problem is simple and straightforward, but it turns out not to be once you get into the weeds, and if I can't trust the tool to tell me if we're in the 90% problem or the 10% problem, then I have to carefully review everything.
I'm used to working with tools, such as SMT solvers, that may fail to perform a task, but they don't lie about their success or failure. Automation that doesn't either succeed or report a failure reliably is not really automation.
Again, I'm not saying that the work done by the LLM is useless, but the tradeoffs it requires make it dramatically different from how both tools and humans usually operate.
If you're writing your own tests, sure, AI is fast at writing code that passes the tests.
But if you write a comprehensive test suite for a problem, you've effectively done the hard development work to solve the problem in the first place. How did the AI help?
Oh have the AI write unit tests you say? Claude cheats constantly at the tests ime. It frequently tests the mock instead of the UUT and reports a pass. That's worse than useless! I'm sure a huge swath of slop unit tests that all pass is acceptable quality for a lot of businesses out there.
> But if you write a comprehensive test suite for a problem, you've effectively done the hard development work to solve the problem in the first place. How did the AI help?
By making you not write the implementation?
Also, the AI writing anything bad isn’t an excuse. You’re the one piloting that ship, and if not, you’re probably the one reviewing the code. It’s your job to review your own and others’ code with a critical eye, and that goes double in the LLM age.
> It doesn't work like tools developers use and it doesn't work like people developers work with. Furthermore, techniques of working with agents today may be completely outdated a year from now.
> I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills.
that's a basic skill you gotta have if you're leading anything or anyone. There'll always be levels of that. So if you're planning to lead anyone in your career, it's a good skillset to develop
While this is true, I definitely find that the style of the work changes a lot. It becomes much more managerial, and less technical. I feel much more like a mix of project and people manager, but without the people. I feel like the jury is still out on whether I’m overall more productive, but I do feel like I have less fun.
3. Tons of excess code I'd never put in there in the first place.
4. Frustration with agents being too optimistic which with time verges on the ludicurous ("Task #3 has been completed successfully with 98% tests failing. [:useless_emojis:]")
5. Frustration with agents routinely getting down a rabbit hole or going in circles, the effort needed to get that straight (Anthropic plainly advises to start from scratch in such cases - which is sound advice, but makes me feel like I just lost the last 5 hours of my life without even learning anything new).
I stopped using agents and use LLMs very sparingly (e.g. for review - they sometimes find some details I missed and occasionally have an interesting solution) but I'm enjoying my work so much more without them.
I think one of the tricks is to just stop using the agent as soon as you see signs of funny business. If it starts BSing me with failing tests, I just turn it off immediately and git reset (maybe after taking a quick peek)
Yeah I make maybe two or three attempts at getting it to write a plan that it is able to follow coherently. But after that I pull the escape hatch and *gasp* program by hand.
I've made this mistake of doubling down after a few initial failures to solve an issue, by trying to make this super duper comprehensive and highly detailed and awesome plan that it will finally be able to implement correctly. But it just gets worse and worse the more I try, because it fundamentally is not understanding what is going on, so it will inevitably find an opportunity to go massively off rails, and the further down you lead it the more impressible the derailment will be.
My experience is that going around in endless circles with the model is just a waste of time when you could have just done it yourself in the time you've wasted.
One thing I don’t get - If you spend much of your time reviewing, you’re just reading - you’re not actually doing anything - you’re passive in the activity of code production. By extension you will become worse at knowing what a good standard of code is and become worse at reviewing code.
I’m not a SWE so I have no interests to protect by criticising what is going on.
In my DJing years I've learned that it is best to provide a hot signal and trim the volume than trying to amplify it later, because you end up amplifying noise. Max out the mixer volume and put a compressor (and a limiter after to protect the speaker set up - it will make it sound awful if hit, but it won't damage your set up and it will flag clueless bozos loud and clear) later, don't try to raise it after it leaves the origin.
It seems to me that adding noise to the process and trying to cut it out later is a self defeating proposition. Or as Deming put it, (paraphrasing) you can't QC quality into a bad process.
I can see how it seems better to "move fast and break things" but I will live and die by the opposite "move slow and fix things". There's much, much more to life than maximizing short term returns over a one dimensional naïve utilitarian take on value.
I'd be careful with extrapolating based on the creator of Linux and Git. His life and activities are not in line with those of more typical programmers.
> His life and activities are not in line with those of more typical programmers.
Okay sure.
I'll use myself as another example then. When I was a dev I used to write a lot of code. Now I'm a tech team lead, and I write less code, but review significantly more code than I used to previously.
I feel more confident, comfortable, and competent in my coding abilities now than ever before even though I'm coding less.
I feel like this is because I am exposed to a lot more code, and not in a passive way (reading legacy code) but an active way (making sure a patch set will correctly implement feature X, without breaking anything existing)
I feel like this principal applies to any programmer. Same thing with e.g. writers. Good writers read _a lot_ and it makes them better writers.
This is my opinion and not based on any kind of research. So if you disagree, that's fine with me. But so far I haven't seen anything to convince me of the opposite.
It's not only that Linus is atypical, it's also that he is reviewing other people's code, and those people are also highly competent, or they would not be kernel committers. And they all share large amounts of high-quality and hard-earned implicit context.
Reviewing well executed changesets by skilled developers on complicated and deliberate projects is not comparable to "fleet of agents" vibe engineering. One of these tasks will sharpen you regardless how lazily you approach it. The other requires extreme discipline to avoid atrophy.
I reset context probably every 5-10 minutes if not more frequently, and commit even more often than that. If you’re going 5 hours between commits or context resets, I’m not surprised you’re getting bad results. If you ever see “summarizing”’in copilot for example, that means you went way too far in that context window. The LLMs get increasingly inaccurate and confused as the context window fills up.
Other things like having it pull webpages in, will totally blow away your context. It’s better to make a separate context just to pull a webpage down and summarize it in markdown and then reset context.
The 'best' trick I learned from someone over here when working with Claude Code is to very regularly go back a few steps in your context (esc esc -> pick something a few steps up) and say something like "yeah, I already did this myself, now continue and do Y"
It results helps keep the context clean while still keeping the initial context I provided (usually with documentation and initial plan setup) at the core of the context.
Now that you say this, I did notice webpages blow context but didn't think too much of it just yet, maybe there's some improvement to be found here using a subagent? I'm not a big fan of subagents (didn't really get proper results out of them in my initial experiments anyway) but maybe adding a 'web researcher' sub agent that summarizes to a concise markdown file could help here.
Now that's dangerous to do because the conversation history in Claude Code now also reverts the code to that point. So while this technique may have worked in the past, it no longer works.
Regarding #3. I feel it's related to this idea: We can build a wood frame house with 2x4's or toothpicks. AI directed and generated code today tends to build things overly complex with more pieces than necessary. I feel like an angry foreman yelling at AI to fix this, change that, etc. I feel I spend more time and energy supervising AI while getting a sloppier end result.
Thankfully, yelling like an angry foreman is more effective on LLMs than people.
> Get your fucking act together, and stop with the bullshit comments, shipping unfinished code, and towering mess of abstractions. I've seen you code properly before. You're an expert for God's sake. One more mistake, and you're fired. Fix it, now!
I wouldn't talk that way to an LLM for fear of its bleeding over into my interactions with people.
Back when computer performance was increasing faster than it is now and was more important to the user experience, a friend upgraded to a faster computer and suddenly became more impatient with me. He seemed to have expected my response time to have drastically decreased just like his computer's did.
Effects like these, those of our tools on ourselves which occur slowly/subtly enough that we hardly notice, underlie a great many of our greatest problems, I think
Yeah exactly, it changes the job from programmer to (technical) project manager, which is both more proactive (writing specifications) and reactive (responding to an agent finishing). The 'sprinting' remark is apt, because if your agents are not working you need to act. And it's already established that a manager shouldn't micromanage, that'll lead to burnout and the like. But that's why software engineers will remain relevant, because managers need someone to rely on that can handle the nitty-gritty details of what they ask for.
I also think that managing a coding agent isnt like managing a person. a person is creative, they will come up with ways that challenge whatever idea you have and that usually makes the project better. A coding agent never challenges you, mostly just does whatever you want, and you don't end up having any kind of intellectual person to person engagement that is why working on teams can be fun. So it kind of isolates you. And I think the primary reason all this happens is because marketing people have decided to call all of these coding agents "Artificial Intelligence" instead of "Dev Tools". And instead of calling it "Security" they now call it "AI Alignment". And instead of calling it "data schema" or "Spec sheet" they call it "managing the AI context". So now, we are all biased to see these things as some kind of entity that we can treat something like a colleague and we all bought this idea because the tool can chat with you. But it isn't a colleague, it doesn't think and feel, it doesn't provide intellectual engagement, it simply is a lossy, noisy tool to try and translate human language into computer language whether its python or machine code.
Have you used SOTA models to code in the last 2 months or so? This reads like someone who has given up a year ago and made their impressions based off GPT-3.
AI can absolutely have creativity. You just have to engage it like that. The article itself talks about that. You don’t just say “hey AI, go write this code.” You write a spec along with the AI. You tell it what parts are open to its interpretation. Tell it if you want it to be creative or to follow common practices. What level of abstraction is appropriate, etc.
If all you do is give it directions then it just follows the directions.
Also context doesn’t have much to do with a data schema. It’s more like a document database with no schema, if anything. It’s a collection of tokens that it refers back to. Schema implies some structured data with semantic meaning and hierarchies or relationships. That might exist as an emergent property, but for example if I just had a folder full of PDFs, I wouldn’t consider that a schema. That’s kinda what context is like.
> They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I wonder what the practical limits are.
As a senior dev on a greenfield solo project it's too exhausting for me to have two parallel agents (front/back), most of the time they're waiting for me to spec, review or do acceptance test. Feels like sprinting, not something I could do day in and day out.
Might be due to tasks being too fine grained, but assuming larger ones are proportionally longer to spec and review, I don't see more than two (or, okay, three, maybe I'm just slow) being a realistic scenario.
More than that, I think we're firmly in the vibe coding (or maybe spec-driven vibe coding) territory.
At least on a team, the limit is the team's time to review all the code. We've also found that vibe engineered (or "supervised vibing" as I call it) code tends to have more issues in code review because of a false sense of security creating blind spots when self reviewing. Even more burden on the team.
We're experimenting with code review prompts and sub agents. Seems local reviews are best, so the bulk of the burden is on the vibing engineer, rather than the team.
Do you have a sense for how much overhead this is all adding? Or, to put it another way, what I’m really asking is what productivity gain (or loss) are you seeing versus traditional engineering?
In our experience, it depends on the task and the language. In the case of trivial or boilerplate code, even if someone pushes 3k-4k lines of code in one day, it's manageable because you can just go through it. However, 3k lines of interconnected modules, complex interactions, and intricate logic require a lot of brainpower and time to review properly and in most cases, there are multiple bugs, edge cases that haven't been considered, and other issues scattered throughout the code.
And empirical studies on informal code review show that humans have a very small impact on error rates. It disappears when they read more than roughly 200 SLOC in an hour.
Interesting, do you have a link to the study? Our experience is different, at least when reviewing LLM generated code, we find quite a few errors, especially beyond 200 LOC. It also depends on what you're reviewing, 200 LOC != 200 LOC. A boilerplate 200 LOC change? A security sensitive 200 LOC change? A purely algorithmic and complex 200 LOC change?
Isn't the current state of thing such that it's really hard to tell? I think the METR study showed that self-reported productivity boosts aren't necessarily reliable.
I have been messing with vibe engineering on a solo project and I have such a hard time telling if there's an improvement. It's this feeling of "what's faster, one lead engineer coding or one lead engineer guiding 3 energetic but naive interns"?
The problem with this is that software engineering is a very unorganized and fashion/emotion driven domain.
We don't have reliable productivity numbers for basically... anything.
I <feel> that I'm more productive with statically typed languages but I haven't seen large scale, reliable studies. Same with unit tests, integration tests, etc.
And then there are all the types of software engineering: web frontend, web API, mobile frontend, command line frontend, Windows GUI, MacOS GUI, Linux backend (10 million different stacks), Windows backend (1 million different stacks), throwaway projects, WordPress webpages, etc, etc.
A controlled experiment done with a representative sample would be lovely. In the long-run it comes down to the financial impact that occurs incrementally because of LLMs.
In the short-run, from what I see, firms are trying to play-up the operational efficiency gains they have achieved. Which then signals promise to investors in the stock market, for which, investors then translate this promise into expectations about the future which are then reflected in the present value of equity.
But in reality it seems to be reducing head-count because they over-hired before the hype and furore of LLMs.
I wanted to point you at https://neverworkintheory.org/ which attempted to bridge the gap between academia and software engineering. Turns out the site shut down, because (quoting their retrospective)
> Twelve years after It Will Never Work in Theory launched, the real challenge in software engineering research is not what to do about ChatGPT or whatever else Silicon Valley is gushing about at the moment. Rather, it is how to get researchers to focus on problems that practitioners care about and practitioners to pay attention to what researchers discover. This was true when we started, it was true 10 years ago, and it remains true today.
The entire retrospective [1] is well worth a read, and unfortunately reinforcing your exact point about software development being fashion/emotion driven.
The other problem is the perennial, how much of what we do actually has value?
Churning out 5x (or whatever - I’m deliberately being a bit hyperbolic) as much code sounds great on the face of it but what does it matter if little to none of it is actually valuable?
You correctly identify that software development is often driven by fashion and emotion but the much much bigger problem is that product and portfolio management is driven by fashion and emotion. How much stuff is built based on the whims of CEOs or other senior stakeholders without any real evidence to back it up?
I suppose the big advantage of being more “productive” is that you can churn through more wrong ideas more quickly and thus perhaps improve your chances of stumbling across something that is valuable.
But, of course, as I’ve just said: if that’s to work it’s absolutely predicated on real (and very substantial) productivity gains.
Perhaps I’m thinking about this wrong though: it’s not about production where standards, and the need to be vigilant, are naturally high, but really the gains should be seen mostly in terms of prototyping and validating multiple/many solutions and ideas.
I resonate on the exhaustion — actually, the context switching fatigue is why we built Sculptor for ourselves (https://imbue.com/sculptor). We usually see devs running 4-6 agents in parallel today using Sculptor today. Personally I think much of the fatigue comes from:
1) friction in spawning agents
2) friction in reviewing agent changes
3) context management annoyance when e.g. you start debugging part of the agent's work but then have to reload context to continue the original task
It's still super early, but we've felt a lot less fatigued using Sculptor so far. To make it easier to spawn agents without worrying, we run agents in containers so they can run in YOLO mode and don't interfere with each other. To make it easy to review changes, we made "Pairing Mode", lets you instantly sync any agent's work from the container into your local IDE to test it, then switch to another.
For context management, we just shipped the ability to fork agents form any point in the convo history, so you can reuse an agent that you loaded with high-quality context and fork off to debug an agent's changes or try all options it presented. It also lets you keep a few explorations going and check in when you have time.
Anyway, sorry, shilling the product a bit much but I just wanted to say that we've seen people successfully use more than 2 agents without feeling exhausted!
Switching between the two parallel agents (frontend & backend, same project), requiring context switches.
I'm speccing out the task in detail for one agent, then reviewing code for the previous task on the other agent and testing the implementation, then speccing the next part for that one (or asking for fixes/tweaks), then back to the first agent.
They're way faster in producing code than I am in reviewing and spelling out in details what I want, meaning I always have the other one ready.
When doing everyting myself, there are periods where I need to think hard and periods where it's pretty straightforward and easy (typing out the stuff I envisioned, boilerplate, etc).
With two agents, I constantly need to be on full alert and totally focused (but switching contexts every few minutes), which is way more tiring for me.
With just one agent, the pauses in the workflow (while I'm waiting for it to finish) are long enough to get distracted but short enough to not being able to do anything else (mostly).
Still figuring out the sweet spot for me personally.
I've been meaning to try out some text-to-speech to see if that makes it a bit easier. Part of the difficulty of "spelling out in detail what I want" is the need for precise written language, which is high cognitive load, which makes the context switching difficult.
Been wondering if just natural speaking could both speed up typing. Maybe have an embedded transform/compaction that strips out all the ummms and gets to the point of what you were trying to say. Might have lower cognitive load, which could make it easier.
This works really well already. You can fire up something like Wispr Flow and dump what you're saying directly into Claude Code or similar, it will ignore the ums and usually figure out what you mean.
I use ChatGPT voice mode in their iPhone app for this. I walk the dog for an hour and have a loose conversation with ChatGPT through my AirPods, then at the end I tell it to turn everything we discussed into a spec I can paste into Claude Code.
I really don't get the idea that LLMs somehow create value. They are burning value. We only get useful work out of them because they consume past work. They are wasteful and only useful in a very contrived context. They don't turn electricity and prompts into work, they turn electricity, prompts AND past work into lesser work.
How can anyone intellectually honest not see that? Same as burning fossil fuels is great and all except we're just burning past biomass and skewing the atmosphere contents dangerously in the process.
> How can anyone intellectually honest not see that?
The idea that they can only solve problems that they've seen before in their training data is one of these things that seems obviously true, but doesn't hold up once you consistently use them to solve new problems over time.
If you won't accept my anecdotal stories about this, consider the fact that both Gemini and OpenAI got gold medal level performance in two extremely well regarded academic competitions this year: the International Math Olympiad (IMO) and the International Collegiate Programming Contest (ICPC).
This is notable because both of those contests have brand new challenges created for them that have never been published before. They cannot be in the training data already!
> consider the fact that both Gemini and OpenAI got gold medal level performance
Yet ChatGPT 5 imagines API functions that are not there and cannot figure out basic solutions even when pointed to the original source code of libraries on GitHub.
Which is why you run it in a coding agent loop using something like Codex CLI - then it doesn't matter if it imagines a non-existent function because it will correct itself when it tries to run the code.
Can you expand on "cannot figure out basic solutions even when pointed to the original source code of libraries on GitHub"? I have it do that all the time and it works really well for me (at least with modern "reasoning" models like GPT-5 and Claude 4.)
As a human, I sometimes write code that does not compile first try. This does not mean that I am stupid, only that I can make mistakes. And the development process has guardrails against me making mistakes, namely, running the compiler.
I feel they are mutually inclusive! I don’t think you can meaningfully create new things if you must always be 100% factually correct, because you might not know what correct is for the new thing.
> If you won't accept my anecdotal stories about this, consider the fact that both Gemini and OpenAI got gold medal level performance in two extremely well regarded academic competitions this year: the International Math Olympiad (IMO) and the International Collegiate Programming Contest (ICPC).
it's not a fair comparison
the competitions for humans are a display of ingenuity and intelligence because of the limited resources available to them
meanwhile for the "AI", all it does is demonstrate is that if you have a dozen billion dollar data-centres and a couple of hundred gigawatt hours, which can dedicate to brute-forcing a solution, then you can maybe match the level of one 18 year old, when you have a problem with a specific well known solution
(to be fair, a smart 18 year old)
and short of moores law lasting another 30 years, you won't be getting this from the dogshit LLMs on shatgpt.com
Google already released the Gemini 2.5 Deep Think model they used in ICPC as part of their $250/month "Ultra" plan.
The trend with all of these models is for the price for the same capabilities to drop rapidly - GPT-3 three years ago was over 1,000x the price of much better models today.
I'm not yet ready to bet against that trend holding for a while longer.
I'm a pretty bad "industry evangelist" considering I won't shut up about how prompt injection hasn't had any meaningful improvements in the last three years and I doubt that a robust solution is coming any time soon.
It's not about being honest. It's about Joe Bullshit from the Bullshit-Department having it easier in his/her/theirs Bullshit Job. Because you see, Joe decided two decades ago to be an "office worker", to avoid the horrors of working honestly with your hands or mind in a real job, like electrician, plumber or surgeon. So his day consists of preparing powerpoints, putting together various Excel sheets, attending whatever bullshit meetings etc. Chances are you've met a lot of Joe Bullshits in your career, you may have even reported to some of them. Now imagine the exhilaration Joe feels when he touches these magic tools. Joe does not really care about his job or about his company. But suddenly Joe can reduce his pain and suffering in a boring-to-death-job while keeping those sweet paychecks. Of course Joe doesn't believe his bosses only need him until the magic machine is properly trained so he can be replaced and reduced to an Eloi, living off the UBI. Joe Bullshit is selfish. In the 1930s he blindly followed a maniacal dictator because the dictator gave him a sense of security (if you were in the majority population) and a job. There is unfortunately a lot of Joe Bullshits in this world. Not all of them work with Excel. Some of them became self-made "developers" in the last 10 years. I don't mean the honest folks who were interested in technology but never had the means to go to a university. I mean all those ghouls who switched careers after they learnt there was money to be made in IT and money was their main motivation. They don't really care about the meaning of it all, the beautiful abstractions your mind wanders through as you create entire universes in code. So they are happy to offload it too, well because it's just another bullshit job, for the Joe Bullshit. And since Joe Bullshit is in the majority, you my friend, with your noble thoughts, are unfortunately preaching to the wind.
I don't think OP thinks his skills are useless per se now, but that the way to apply those skills now feels less fun and enjoyable.
Which makes perfect sense - even putting aside the dopamine benefits of getting into a coding flow state.
Coding is craftsmanship - in some cases artistry.
You're describing Vibe Engineering as management. And sure, a great manager can make more of an impact increasing the productivity of an entire team than a great coder can make by themselves. And sure, some of the best managers are begrudging engineers who stepped up when needed to and never stepped down.
But most coders still don't want to be managers - and it's not from a lack of skill or interest in people - it's just not what they chose.
LLM-based vibe coding and engineering is turning the creative craftsmanship work of coding into technical middle management. Even if the result is more "productivity", it's a bit sad.
But does anybody really care about what you like? What about all those other professions that got replaced by technology, did anybody care what they liked? The big question is how is software going to be build most efficiently and most effectively in the future and how do you prepare yourself for this new world. Otherwise you’ll end up with all those other professions that got replaced, like the mineworkers, hoping that the good old days will someday return.
Its reasonable to stay away from something one considers dystopian considering the industry is not even sure about the usefulness of coding agents in professional environments. When the tractors replaced the horses, everyone could agree they outperform horses. The result was easily measurable. Its not that simple with LLM agents owned by big corporations.
Sure, it's not yet clear what impact LLMs will have on software development, but the impact it will have will not depend on if developers like to use it or not. If it is going to make software development 10x faster, companies will adopt it, whether devs like it or not.
Yup absolutely, and its a shame because it takes the joy out of it for a lot of people. I'll have a lot more paid leave if I dont like my job is all im going to say to this.
Sadly true. Most companies don’t even care if the software is sloppy, slow, and ridden with errors that cause data loss or privacy breaches. They care about exploiting workers and extracting value.
Is it ethical? Probably not. It took a few bridges falling and buildings caving in before traditional engineering became a profession.
In this post-Reagan world I’m not sure software has the right context to make that happen. I’m pretty sure we’ll stay the course where the big tech companies like it: very little regulation, loose liability, and terrible software for everyone.
Everything is getting industrialized. We buy most products made in China (tv,laptop, mobile phone etc), furniture is mostly cheap IKEA furniture. Many craftsmen lost their profession to industrialized automation. If we don´t care our furniture is subpar, our products are cheap plastic china products, why do we expect anybody to care about software craftsmanship?
This is the heart of it. Most "craft" industries that have not yet been disrupted by technology or been made "more efficient" tend to coincidentally be the ones that are in demand and pay well -> and that society generally wants "good X" of. e.g. Plumbers, Electricans, previously software engineers. Efficiency usually benefits the consumer or the employer, not the craftsmen in most industries. There's a reason people are saying right now to "get a trade" where I am.
If you look at what still pays well and/or is stable (e.g. where I live trades are highly paid and stable work) its usually the crafts industry. We still build houses for example mostly like we did way back (i.e. much of the skills are still craft, not industrialized industry) when and it shows in the price of them.
I'm getting really great results in a VERY old (very large) codebase by having discussion with the LLM (I'm using Claude code) and making detailed roadmaps for new features or converting old features to new more useable/modern code. This means FE and BE changes usually at the same time.
I think a lot of the points you make are exactly what I'm trying to do.
- start with a detailed roadmap (created by the ai from a prompt and written to a file)
- discuss/adjust the roadmap and give more details where needed
- analyze existing features for coding style/patterns, reusable code, existing endpoints etc. (write this to a file as well)
- adjust that as needed for the new feature/converted feature - did it miss something? Is there some specific way this needs to be done it couldn't have known?
- step through the roadmap and give feedback at each step (I may need to step in and make changes - I may realize we missed a step, or that there's some funky thing we need to do specifically for this codebase that I forgot about - let the LLM know what the changes are and make sure it understands why those changes were made so it won't repeat bad patterns. i.e. write the change to the .md files to document the update)
- write tests to make sure everything was covered... etc etc
Basically all the things you would normally WANT do but often aren't given enough time to do. Or the things you would need to do to get a new dev up to speed on a project and then give feedback on their code.
I know I've been accomplishing a lot more than I could do on my own. It really is like managing another dev or maybe like pair programming? Walk through the problem, decide on a solution, iterate over that solution until you're happy with the decided path - but all of that can take ~20 minutes as opposed to hours of meetings. And the end result is factors of time less than if I was doing it on my own.
I recently did a task that was allotted 40 hours in less than 2 working days - so probably close to 10-12 hours after adjusting for meetings and other workday blah blah blah. And the 40 hour allotment wasn't padded. It was a big task, but doing the roadmap > detailed structure including directory structure - what should be in each file etc etc cut the time down dramatically.
I would NOT be able to do this if I the human didn't understand the code extremely well and didn't make a detailed plan. We'd just end up with more bad code or bad & non-working code.
Thank you for this post. I don't write much code as I'm currently mostly managing people but I read it constantly. I also do product management. LLMs are very effective at locating and explaining things in complex code bases. I use Copilot to help me research the current implementation and check assumptions. I'm working to extend out in exactly the directions you describe.
"LLMs are very effective at locating and explaining things in complex code bases." YES. I do nothing BUT write code and tracking everything down in the code base is greatly simplified by using an LLM.
This is just a new tool. I think the farming example mentioned in another post is actually a great example. I love coding. I code in my free time. It's just fun. I've been doing it for ~20 years and I don't plan on stopping anytime soon!
But at work I'm really focused on results more than the fun I can have writing code. If a tractor makes the work easier/faster why would I not use a tractor? Breaking my back plowing isn't really my end goal at work. Having a plowed field is my end goal. If I can ride around in a tractor while doing it great! If I can monitor a fleet of tractors that are plowing multiple fields at once even better!
When I go home I can plant anything I want in any way I want and take all the time I want. Of course that's probably why in my free time I end up working on games I never finish...
This is what I've seen as well - in the past a large refactor for a codebase like that seemed nearly impossible. Now doing something like "add type hints" in python or "convert from js to ts" is possible in a few days instead of months to never.
Another HUGE one is terraforming our entire stack. It's gone from nearly impossible to achievable with AI.
I remember reading a sci-fi book, where time was.. sharded? And people from different times were thrust together. I think it was a Phoenician army, which had learned to ride and battle bareback.
And were introduced to the stability of stirrups and saddle.
They were like daemons on those stirrup equipped horses. They had all the agility of wielding weapons and engaging in battle by hanging onto mane, and body with legs, yet now had (to them) a crazy easy and stable platform.
When the battle came, the Phoenicians just tore through those armies who had grown up with the stirrup. There was no comparison in skill or capability.
(Note: I'm positive some of the above may be wrong, but can't find the story and so am just stating it as best able)
My point is, are we in that age? Are we the last skilled, deeply knowledgeable coders?
I grew up learning to write eeproms on burners via the C64. Writing machine language because my machines were too slow otherwise. Needing to find information from massive paper manuals. I had to work it all out myself often, because no internet no code examples, just me thinking of how things could be done. Another person who grew up with some of the same tools and computers, once said we are the last generation to understand the true, full stack.
> they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere.
Honestly, I have a ton of experience in system administration, and I'm super comfortable at a command line and using AWS tooling.
But, my new approach is to delegate almost all of that to Claude, which can access AWS via the command-line interface and generate configuration files for me and validate that they work correctly. It has dramatically reduced the amount of time that I spend fiddling with and understanding the syntax of infra config files.
I appreciate what you're trying to do, but for myself, I'm not depressed because my skills are less valuable. I enjoyed the money but it was never about that for me. I'm depressed because I don't like the way this new coding feels in my brain. My focus and attention are my most precious resources and vibe coding just shatters them. I want to be absorbed in a coding flow where I see all the levels of the system and can elegantly bend the system to my will. Instead I'm stuck reviewing someone/something else's code which is always a grind, never a flow. And I can feel something terrible happening in my brain, which at best can be described as demotivation, and at worst just utter disinterest.
It's like if I were a gardener and I enjoyed touching dirt and singing to plants, and you're here on Gardener News extolling the virtues of these newfangled tractors and saying they'll accelerate my impact as a gardener. But they're so loud and unpleasant and frankly grotesque and even if I refrain from using one myself, all my neighbors are using them and are producing all their own vegetables, so they don't even care to trade produce anymore--with me or anyone else. So I look out at my garden with sadness, when it gave me such joy for so many decades, and try to figure out where I should move so I can at least avoid the fumes from all the tractors.
Well said! Reading this I feel reminded of the early protests against industrialization and automation in other fields. Checks all the same boxes - insecurity and fear about the future, alienation towards the new tools, ...
Not saying AI is similar in impact to the loom or something, it just occured to me how close this is to early Luddite texts.
Many Luddites were fine with using the new Loom machines. They smashed them because they were precious to the capital holders and in a time when there were no labour laws. The Luddites were protesting child labour, forced labour, and having no social safety net when they were discarded by their employers other than workhouses.
This has been the dream of the capital classes since time immemorial.
And unfortunately (for humanity) this has been the status quo for the whole civilization. Small ruling elite class (you might designate them as masters, lords or employers) with all the wealth, minimal or no "middle class" and lots of poor people (you might designate them as peasants or slaves or workers).
The only exception to this has been the period of time since World War 2 when in most of the "western" countries the middle class demanded and took their share of the wealth. That's the time when modern well-fare states were born, universal health care became a thing, working safety improved, education became accessible. etc.
All these were NOT given by the elite but TAKEN by the working class via social reforms, workers unions and social democracy.
The capital owning class wants to take all these away and they're succeeding.
So yes, in fact the Luddites were not against technology, they were against the unilateral and uneven distribution of wealth produced by the technology.
Industrialization actually helped the middle class insofar as you needed "skilled workers" to work the industrial equipment, make decisions, and process. The fact that production had scaled in a world of scarcity meant that your worker had greater leverage. They often knew each other as well, went to the same schools, etc which meant less info asymmetry as to their worth/value. It moves the value to something that takes time, skill and sometimes luck to achieve that being skills and experience. This was hard to replicate (e.g. our school, college, university systems), required significant training and created "pets not cattle" with hard to get skills meaning the new skilled middle class could rise and exercise their new found negotiating power.
Somewhat unprecedented in human history. All because intelligence had scarcity. AI changes that.
AI is the real dream of the capital classes. It makes intelligence cheap potentially undoing the very thing that gave birth to the last century's middle class. In the long term, given current trends, I wouldn't be surprised if these AI technologies revert us back to most of human history -> where the world is very unequal, meritocracy dies and most of us are trying to just exist/survive whilst the capital holders have abundance. It explains the large valuations as well of AI/Tech lately and the weird deals going on; this isn't a game of economics anymore; its an arms race of power in the new world structure. I suspect to these people no amount of money is enough; if you win you win for the next era of humanity.
Exactly. Most people who haven’t studied the history think the Luddites smashed the machines because they were against progress and industrialization. Hence the modern interpretation of Luddite meaning, “against technology.”
Many Luddites were shot against the wall or jailed. History often lies because it is written by the winners.
The OG alienator was the Agricultural Revolution, settling and toiling repetitively in predetermined ways, unlike the more adventurous lifestyle from before with all the camping, hunting, gathering, where circumstances brought always novel challenges, you could be a man spearing a deer, instead of just killing some docile domesticated cow. Searching for pheasant eggs and being happy if you found some, instead of going out every morning to the predictable presence of eggs in the chicken coop.
Mostly because if you settled down a tilled a field of barley you had a reliable source of beer. Finding beer in the wild was and still is an almost certain failure.
The roots of global civilization are brown and frothy.
I'd say the fear is justified. The economy should serve the people and the citizens not the other way around. Yet, our economies are increasingly the other way around, people have to fit into to the shape of the economy.
It's not hard to see a future where the workers displaced by AI get pushed to the sidelines and fringes of the society while the capital holders hoard more wealth and get the benefits of the "value" created.
We already have half the population on this planet living in slums without access to economic means and in the "developed" countries larger and larger group of people are barely hanging on either already displaced and unemployed or working jobs below living wages.
This is true, but it started way earlier than AI with software development though. A lot of software developers' job is just being ticket monkies, adding small things or fixing bugs for a huge company that nobody cares about. The alienation is real.
This is, of course, an attribute of capitalism.
Like carpenters, gardeners and farmers, there are very few software developers who truly have the luxury to treat their work as a craft and not a factory output.
How beautifully put, and I couldn't agree more. I feel exactly the same way.
However, I am still unconvinced that software development will go down this way. But if woking as a software developer will require managing multiple agents at the same time instead of crafting your own code — you can count me out, too.
If it is not about the money, why do you have to use these tools? If you enjoy small farming why concern yourself with mass production, or expensive equipment? Remain in the lane you enjoy?
I enjoy programming and I enjoy being paid for programming. I'm being pressed to use AI for my paid work. And I don't enjoy AI-powered programming.
As of today, I've disabled Copilot. The only autocomplete that I can accept is absolutely mechanical one, not any kind of smart. I want to write the rest of the code myself. I like it.
I was weird in StackOverflow era, because I never blindly applied snippets, like other programmers do. I went over them token by token, reading underlying library sources and docs, always creating my own solution. It made me less productive, but I feel that my code was more robust and maintainable, so it was a good trade-off for me.
May be it'll work out the same way with AI, time will tell.
I think it will; AI is not going away, but once the hype has settled, the first companies have gone bankrupt or acquired, and employers are paying for them, they will become part of someone's daily tools not unlike the existing autocomplete tools.
Fwiw I’m an ai proponent who loves that flow state you are describing. Programming literally was the first time I found it as a youth and I’ve been addicted to it since then.
But it’s such a small part of my professional life. Most of what I do is chores and answering simple questions and planning for small iterations on the original thing or setting up a slightly different variant.
Llm’s have freed me of so much of that! Now I outsource most of that work to the llms and greedily keep the deep flow inducing work for myself.
And I have a new tool to explain to management why we are investing in all the tooling and processes that we know lead to quality, because the llms are catnip for the managerial mind.
> They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
Neither can I, sadly. I have one brain cell and I can only really do one thing at a time. Doing more than one leads to a corrupted stack and I make exponentially more mistakes.
>accelerate the impact you can have with this new family of tools.
Tech spent the last 10 years drilling into engineers' heads that scaling your impact is not about writing more or better code, but about influencing the work of other engineers through collaboration, process, documentation, etc. Even the non-managerial "senior IC" tracks are mostly about doing this with greater and and greater numbers of people. I wonder if we will start to see recognition in career tracks for people who are actually just extraordinarily productive by themselves or in small groups, or if you'll pretty much just have to be a startup founder to get paid for that.
This has been experience as well. If there is a hard problem which needs to be addressed, generative code helps me break the inertia by generating the first draft and then I get really curious to poke holes in the generated code. I tend to procrastinate when I come across a gnarly issue or something I am not really familiar with, justifying by saying I need a big block of time to work on it. I use generative code as a pushy "mom/boss/coworker/spouse" to get stuff done.
I really hope you are right here, and to be honest it does reflect my limited experience with where I've used AI so far.
But I'm also not ready to bet the farm on it. Seriously considering taking our savings and equity out of our house in a London adjacent area, and moving to a lower cost of living area, so that we're practically debt free. At that point we can survive on a full time minimum wage job, anything more than that is a bonus.
I still haven't seen any evidence to match these repeated claims of increased efficiency. What I have seen is reports that makes a lot of sense to me claiming it's all in the user's head.
Maybe it's in my head, but I have completed coding projects that I believe would have taken a team of five offshore maybe 12 weeks to do in the past in about ten working days while juggling calls and living normal corporate life.
The win is that I don't have to share the vision of what needs to be done and how it should all work, and then constantly monitor and reframe that in the face of the teams missteps and real findings. I work with the agents directly, and provided I set the architecture and build up systematically I can get really good results. The cycle time between me identifying an issue and the issue getting fixed by me and the agents is now minutes rather than hours or days with an off shore team. Even better the agents can provide bug fixing expertise much quicker than stack overflow - so I can figure out what's wrong much faster so as to specific what needs fixing.
It is no good walking in and requesting functionality, you need to know how the thing you want should work, and you need to know what good looks like, and what bad looks like, and how good is separated from bad. Then the normal process of discovery ("eep that doesn't actually work like I thought") can take place and you can refactor and repair as required.
Sometimes I start something that just doesn't work, you have to recognise that you and the agents are lost, and everything needs to be torn down. You then need to think properly about whats gone wrong and why, and then come back with a better idea. Again - just like with dev teams, but much more clearly and much faster.
I'm working in corporate and haven't seen it yet. The main thing I see is blogs and whatnot of people building new weekend projects with LLMs, that is, greenfield, non-critical software - the type of software that, if I were to write it, I wouldn't bother with CI, tests, that kind of thing with. Sloppy projects, if you will.
But happy to be corrected - is someone using these agents in their paid / professional / enterprise / team job?
I think most of the code in our enterprise is now written by AI. It’s all boring callcenter crud apps, so nobody is really sad they’re not writing any of that code any more. I’m not sure it makes me faster, but I think QA testing what the AI made and occassionaly adjusting it is more fun anyway.
The code is absolutely lower quality, but there were always so many people producing garbage faster than I could produce something nice that the code was always terrible anyway.
There’s an element of wanting to know how the thing works so at least I’ll know when it’s ready to replace me though.
>But happy to be corrected - is someone using these agents in their paid / professional / enterprise / team job?
Yes, and I find them quite useful
I don't see myself going back to the "Google + StackOverflow" approach I had used for 10 years prior (well, I can always fall back to it if necessary, but so far I haven't needed to)
My experience matches OP: my years of experience in manual coding complements the agent approach remarkably well
I am, but in a very narrow focus: mostly examining our existing codebase as a more powerful but fuzzier search, and a system to then generate a plan to implement and approach which I tweak.
I sometimes use it to scaffold out some boilerplate for tests, but never tests themselves: no matter what I try it always ends up writing the useless straight-jacket "change alert" style tests that break on any change to the unit under test, which I despise.
There was an article on here not too long ago - I can’t find it now - where the authors discussed how they leaned full in on it and were submitting 20k+ line PRs to open source projects in languages they were not very familiar with.
However, they mentioned you had to let go of reviewing every line of every PR. I read that and was fine with holding off on full vibe coding for now. Nobody intelligent would pay for that and no competent developer would operate like that.
I have a couple coworkers big on it. The lesser skilled ones are miserable to work with. I’ve kept my same code review process but number of comments left has at least 5x’d (not just from me, either). And I’m not catching everything - I get fatigued and call it done. Duplicated logic, missed edge cases, arbitrary patterns and conventions, etc. The high skilled ones less so, but I still don’t look forward to reviewing their PRs anymore. Too much work on my end.
There are many devs who are more focused on results than being correct. These are the ones I’ve seen most drawn to LLMs/agents. There’s a place for these devs, but having worked on an aging startups codebase, I hope there aren’t too many.
Of course the devil is in the details. What you say and the skills needed make sense. It's unfortunately also the easiest aspects to dismiss either under pressure as there is often little immediate payoff, or because it's simply the hard part.
My experience with llms in general is that sadly, they're mostly good bullshitters. (current google search is the epitome of worthlessness, the AI summary so hard tries to make things balanced, that it just dreams up and exaggerates pros en cons for most queries). In a same way platforms like perplexity are worthless, they seem utterly unable to assign the proper value to sources they gather.
Of course that doesn't stop me from using llms where they're useful; it's nice to be able to give the architecture for a solution and let the llm fill the gaps than to code the entire thing by hand. And code-completion in general is a beautiful thing (sadly not a thing where much focus is on these days, most is on getting the llm create complete solutions while i would be delighted by even better code completion)
Still all in all, the more i see llms used (or the more i see (what i assume) well willing people copy/paste llm generated responses in favor of handwritten responses) on so much of the internet, resulting in a huge decline of factualness and reproducibility (in he sense, that original sources get obscured), but an increase of nice full sntences and proper grammar, the more i'm inclined to belief that in the foreseeable future llm's aren't a net positive.
(in a way it's also a perfect storm, the last decade education unprioritised teaching skills that would matter especially for dealing with AI and started to educate for use of tools instead of educate general principles. The product of education became labourers for a specific job instead of higher abstract level reasoning in a general area of expertise)
Google's "AI overviews" are one of the worst LLM-powered features on the market today, they're genuinely damaging the reputation of the whole industry.
It might actually be in Googles best interest to damage the interest in LLMS by showing those crappy AI Mode stuff, because it materially impacts their business model.
The perception of LLMs in the gen pop is what matters, not in the eyes of techies.
Sparking more conversations about practices that work for doing serious production-quality software development with LLMs, especially in larger teams and on larger projects.
Having a good counter to people who use "vibe coding" as a dismissive term for anything where an LLM is used to help product software.
What about the accessibility of software development? Its completely vanishing for people that can not afford to pay for these agents. It used to be a field where you could get a laptop from the scrapyard and learn from there. It feels pointless. Also agents do not invent things, the creativity part is gone with them. They simply use what they've already seen, repeat the same mistakes a person made a few years ago. Its a dystopian way of working. Sure it enables one to spew out slop that might make companies money, but there is no passion, sense of exploration, personal growth. Its all just directing parrots with thumbs...
I feel your sentiment. However anyone with an interest in computers now has access to an LLM, which to me feels like an upgrade to having access to a modem and a search engine.
Knowledge is power right?
Absolutely. If the knowledge is verifiable. Kurzgesagt recently uploaded a video about this, its a lot harder to verify statements due to AI. Not easier.
Here is the video in case you are interested:
https://youtu.be/_zfN9wnPvU0?si=_17KU8l2wDjGUYA5
> What about the accessibility of software development? Its completely vanishing for people that can not afford to pay for these agents.
what do you actually mean by this? it's clearly untrue - anyone get get a laptop and install linux on it and start bashing out code today, just as they could last week and last year and thirty years ago.
do you mean that you think at some point in the future tooling for humans to write code won't exist? or that employers won't hire human programmers? or that your pride is hurt? or you want your hobby to also be a well-paid job? or something else?
I mean that this "tooling" becomes inaccessible to people. At least the tooling that is relevant for jobs. Employers will eventually stop hiring human based on their programming competence. It'll translate into a low pay career for people who like to orchestrate agents.
I doubt it will, because there will always be a need for understanding the code, especially when it comes to things like security, certification, etc.
I mean COBOL has not been a relevant programming language for anyone coming into the field in the past 20-40 years because it's been superseded, yet there's still a significant demand for COBOL developers, because the newer generation can't or doesn't want to work with it.
Not to completely dismiss your claim, of course; I'm sure a segment of software engineering will be agent based now or in the near future. But I don't think it'll take over as comprehensively, since the previous existential crisis - outsourcing - also hasn't decimated the software engineering market.
etc etc etc. Thing is, the moment you go off-piste, the LLMs get a lot less useful. I think, if you want to stay closer to the metal, you've got to aim for a niche that has a small internet footprint. So... domain knowledge or esoteric programming knowledge.
One way to incorporate domain knowledge might be to become a hybrid product owner/programmer.
(This is all just opinion - I'm sure a well-argued rebuttal is possible).
Spec-Driven Development treats the spec as the source of truth and the code as an artifact. As you develop, you modify/add to the spec and the codebase gets updated to reflect it.
Personally I'm doubtful it can compete with traditional artisanal software engineering, as it's (IMHO) boils down to "if only you can spec it precisely enough, it'll work" and we've tried this with 5GL and (to some extent) BDD, and it doesn't get you to 100%.
I do think it's interesting enough to explore, and most of us could use a bit more details in our Jira tickets.
That was exactly what UML wanted to do, and it almost never worked out in practice.
Seems to be just a rehashing of the same idea but instead of XML, and diagrams, it's now some free-text to be interpreted by LLMs, so much less deterministic and will probably fail just like UML failed.
People also tend to forget about Peter Naur's take on "Programming as Theory Building" [0], the program is, in itself, the theory of what's implemented. A spec cannot replace that.
Theory building is the secret sauce, and all variants of "this is how to use AI effectively" I've seen are inferior to the epistemologically sound theory Naur outlines in his paper.
We already invented languages for succinctly describing what the computer should do. They’re call programming languages.
“The code is the documentation” is not a joke. Logic that’s useful in the real world is complex and messy. You need additional documentation (why did the code end up like it is, etc) but code is the most expressive way we’ve got for describing how a computer should work.
The "manage a fleet of massively parallelized agents" gets me uneasy too. It sounds uber powerful on its face. And where all the nerd interest lies.
It sounds stressful, like the ultimate manager job. Not what I signed up for.
But I also still hold onto this idea that shipping tons of iterations of "stuff" was never really the problem. Early in my dev experience I wanted to code everything all day every day. And I did and that's how I learned. And now in my second decade I switched to "why code anything?". In a business sense I mean, coding the thing is almost never the missing piece.
I joke in meetings that the answer is always "yes" whenever cross-functional teams ask "can we do this?". "How hard would x be?". For tech teams the answer _is_ always YES! I get that out of the way because that's never the right question to ask.
Absolutely this. LLM assistance means we can work faster, and that we can build things that previously weren't feasible given the available time and resources.
Which makes the hardest problem in software even harder: what should we build? It doesn't matter how fast you can move if you're consistently solving the wrong problems.
> Which makes the hardest problem in software even harder: what should we build?
You should build what’s personally fun and challenging to you and/or what is useful and solves a problem. Building for any other reason, including and especially the unfettered pursuit of profit, is what turns everything to shit.
I agree with you, but unfortunately, big boy gotta eat, and that means we have to sit around writing shitty commercial software. I already hate that, I would prefer if it didn't get worse.
I've noticed that almost immediately after people discovered GPT could write code, this happened -- startups I worked with started rapidly expanding the scope of what they wanted to make. Suddenly all MVP's had to be multi-tenant with complex authorization, impersonation, microservices, monitoring, all the stuff that we used to build after we got users has now been pulled right to the starting gate of development -- because AI makes it easy to build all that stuff quickly. But it doesn't tell us if we should.
Exactly, I think one of the reasons programers are becoming so depressed over these AI agents is that they’re finally realizing that it was never really about the code, but about the outcome - and btw, this cold hard fact applies to the pre-LLM era.
This occurred to me years ago when I was talking to a friend’s wife, who is a very intelligent and accomplished attorney. She was legitimately surprised when I explained that they were multiple programming languages, and technology stacks behind the software that she uses on a daily basis.
Even my wife, a teacher who is very tech savvy (she’s the one who insisted I try ChatGPT after brushing it off) reminds me on the regular that she doesn’t care about how any of it works just that it doesn’t “glitch” when she’s in the middle of a class. Which has always been good for me to remember when I get off into the weeds yak shaving.
I do think code-as-craft should be respected in its own right. I'm very much a craftsman coder. It makes sense how I could clock so many hours over all these years.
But what I do "at work" isn't the same as my personal pursuit and embracing that different framing positively has made me more at peace and also better at the work job.
> The "manage a fleet of massively parallelized agents" gets me uneasy too
It shouldn't. The agents are not good enough to be used in a fleet.
I have Claude. It's fine, but I'm pretty confident that my low usage of Claude would out-compete a fleet of agents, because it feels like there's an inverse correlation between the number of tokens you spend and the quality of the resulting code (more tokens = more code to review, more bad code slips through)
That's basically my finding as well. Agent wrangling is herding cats. Working normally but tapping Claude for the smallest possible thing (look this up, finish this psuedocode, grab an example of this) feels like it works better all around—faster, safer, far fewer tokens, results in work that the team understands, aides flow rather than adding constant context switching...
Maybe I'm wrong and the time will come to hang up my editor and go open an Italian restaurant or something. Until then I'm really inclined to believe my own eyes.
Yes, and forget about ownership of anything too. Only rental, only hardcore, because life is but an experience, spread your wings and fly, weeee, towards our hyperprofits and your prozac dreams!
AI threads on HN reek of venture capital agendas so bad it's unbearable.
I think rather your post summarizes AI threads on HN.
Capitalism is what it is, and has been so for the last 200 years. The alternatives have always proven worse.
In my (small) country we have had many crises like this. Textile industry, shipbuilding. But we have survived by not looking back but looking into the future. And given people the right conditions for retraining.
I think people underestimate the degree to which fun matters when it comes to productivity. If something isn’t fun then I’ll likely put it off. A 15 minute task can become hours, maybe days long, because I’m going to procrastinate on doing it.
If managing a bunch of AI agents is a very un-fun way to spend time, then I don’t think it’s the future. If the new way of doing this is more work and more tedium, then why the hell have we collectively decided this is the new way to work when historically the approach has been to automate and abstract tedium so we can focus on what matters?
The people selling you the future of work don’t necessarily know better than you.
I think some people have more fun using LLM agents and generative AI tools. Not my case, but you can definitely read a bunch of comments from people using the tools and having fun/experience a state of flow like they have never had before
I definitely agree with you there. I contracted with a company that had some older engineers who were in largely managerial roles who really liked using AI for personal projects, and honestly, I kind of get it. Their work flow was basically prompt, get results, prompt again with modifications, rinse and repeat, it's low effort and has a nice REPL-like loop. Paraphrasing a bit, but it basically re-kindled the joy of programming for them.
Haven't gotten the chance to ask, but I imagine managing a team of AI agents would feel a little too much like their day job, and consequently, suck the fun out of it.
That said, looking back, I think the reason why generative AI is so fun for so many coders is because programming has become unnecessarily complex. I have to admit, programming nowadays for me feels like a bit of a slog at times because of the sheer effort it can sometimes take to implement the simplest things. Doesn't have to be that way, but I think LLM copy-paste machines are probably the wrong direction.
I think the majority of people I've worked with who have the title of "Software Engineer" do not like coding. They got into it for the money/career, and dream of eventually moving out of coding into management. I can count the number of coders who I've met who like coding on one hand
I've been enjoying seeing my agents produce code while I am otherwise too busy to program, or seeing refined prompts & context engineering get better results. The boring kinds of programming tasks that I would normally put off are now lower friction, and now there's an element of workflow tinkering with all these different AI tools that lets me have some fun with it.
I also recently programmed for a few hours on a plane, with no LLM assistance whatsoever, and it was a refreshing way to reconnect with the joy of just internalizing a problem and fitting the pieces together in realtime. I am a bit sad that this kind of fun may no longer be lucrative in the near future, but I am thankful I got to experience it.
I’ll be that voice I guess - I have fun “vibe coding”.
I’m a professional software engineer in Silicon Valley, and I’m fortunate to have been able to work on household-name consumer products across my career. I definitely know how to do “real” professional work “at scale” or whatever. Point is, I can do real work and understand things on my own, and I can generally review code and guide architecture and all that jazz. I became a software engineer because I love creating things that I and others could use, and I don’t care about “solving the puzzle” type satisfaction from writing code. In engineering school, software had the fastest turnaround time from idea in my head to something I could use, and that’s why I became a software engineer.
LLM assisted coding accelerates this trend. I can guide an LLM to help me create things quickly and easily. Things I can mostly create myself, of course, but I find it faster for a whole category of easy tasks like generating UIs. It really lowers the “activation energy” to experiment. I think of it like 3D printing, where I can prototype ideas in an afternoon instead of long weekend or a few weeks.
>because I love creating things that I and others could use, and I don’t care about “solving the puzzle” type satisfaction from writing code.
Please don't take offense to this, but it sounds like you just don't like building software? It seems like the end goal is what excites you, not the process.
I think for many of us who prefer to write code ourselves, the relationship we have with building software is for the craft/intellectual stimulation. The working product is cool of course, but the real joy is knowing how to do something new.
I understand where you're coming from (and I don't take offense), but based on your reply, I don't really feel like my views came across.
When I was a student, I took classes on chip and circuit design. One class, the professor had us work on all these complex circuits to do things like flash lights and produce various signals with analog circuits. The next lesson, he had us replace all that complex work with a microcontroller and 20 lines of C - "the way it's done in industry". The students mourned the loss of the "real" engineering because the circuit that required skill and careful math was replaced by a cheap chip and some trivial software. Their entire concept of the craft was destroyed when they were given a tool that replaced the "fun parts" with some trivial and comparatively boring work. That same concept of replacing circuits with digital logic scaled up is how extremely complex and well engineered circuits like FPGAs work.
Maybe it was just my earlier wording, but I think there is joy in the act of turning your ideas into something real - creation - not just having something real. Shopping is not building. Importantly, it takes careful thought and practice and a learned instinct to engineer and create things correctly, and do it repeatably, as the original article discusses. Craft is about practice, and learning, and trying something new with what you've learned.
If LLMs mean that I'll never have to write another trivial set of methods to store a JSON object in a SQL database, I don't think I'll lose any project-wide joy. Expressing creativity, and trying new things is what's great, not typing something that's been done a million times before. It's a tired analogy, but I do think of it more like a level of abstraction, like the LLM is a "compiler" for design docs or specifications. For myself, I usually don't see a difference between a prompt instructing an LLM to write some function, and the code for the function itself - in same way that a method in Java, bytecode, and asm are basically the same (with some caveats here around complexity and originality).
For a lot of folks, the derivation of joy is not as scale-free as seems necessary to move up the hierarchy in this way. The jump in abstraction kills some joy by removing the tangible process. The tactile enjoyment someone gets from knitting is not there when operating a loom, much less when managing someone else who operates the loom.
The change in agency also kills the joy for me. I thrive on abstraction in the language and mathematics sense. But I do not at all enjoy indirection and delegation through unreliable agents. I am not interested in the loss of control and the new risk management task. I would never accept a "stochastic compiler" that offered to optimize my code but with risk of randomly changing the semantics. That determinism in the semantics needs to remain for me to accept a tool as a valid abstraction.
For context, I am a computer scientist by title and a programmer at heart. I got my CS degree from a liberal arts program rather than an engineering school. My temperament is more that of a hands-on artist at an easel or typewriter and not that of a manager of an engineering department. In my long career, I have thrived with peers or betters on collaborative projects. I have zero interest in "advancing" to a managerial role.
But honestly, the loss of control, lack of trust, and associated risk management is a big problem for me. I have rarely delegated work to less skilled or less reliable juniors, and I have never enjoyed that. The scenario of a confidently wrong subordinate is a huge trigger for me. It evokes long term trauma from growing up with a mentally ill family member. It feels like all of the burden of being a caregiver to someone with delusions, but with none of the moral context to make that worth the cost.
There is nothing wrong with finding joy however one finds joy, and that can vary from person to person. Someone may find joy from knitting by hand, but maybe someone else finds joy from experimenting with pattern and material, and a loom lets them focus on the parts that interest them.
As a thought experiment, do you think it would be just as fun if you were given access to an infinite database of apps, and you were able to search through the database for an existing app that suit your needs, and then it gave it to you?
Or would it no longer be fun, because it no longer feels like creating?
I feel the same way. It also appears to be a lot more difficult to actually find jobs, though that's probably just the general state of the job market and less specifically AI related. All of it is thoroughly discouraging, demotivating, and every week this goes on the less I want to do it. So for me as well it might be time to try to look beyond software, which will also be difficult since software is what I've done for all my life, and everything else I can do I don't have any formal qualifications for, even if I am confident I have the relevant skills.
It's not even just that. Every single thing in tech right now seems to be AI this, AI that, and AI is great and all but I'm just so tired. So very tired. Somehow even despite the tools being impressive and getting more impressive by the day, I just can't find it in me to be excited about it all. Maybe it's just burnout I'm not sure, but it definitely feels like a struggle.
Keep your head up, the gravy train is not gonna run forever, and they will need serious engineers to untangle the piles of bullshit creates in these past few years.
But also yes, look into moving into a different field. Professional software engineering is gonna be infected with AI bullshit for a long while. Move into a field where hand-crafted code can make a difference, but not where you're paid for the line committed or have to compete with "vibe coding" KPIs.
I don't really agree. The writing is on the wall, if not now then in 2 years or 4 years. I arrive at this view not so much based on the capabilities of the tools right now, but based on the property of software being verifiable, which like mathematics, makes it amenable to synthetic data pipelines, with only relatively small remaining details needing to be worked out (such as how to endow architectural taste). This is not nearly the first industry where 'artisans' have been initially augmented by innovation, only to be eventually replaced by it, which in my view will occur likely within my own career-span.
Software is verifiable, but not by other programs. Also software is a soution to a problem, but the problem and the solution properties often don’t exist in the code.
Software and data is a bit soup whre the only thing you truly need is the Turing machine. Programming languages, File format, protocols, and encoding are constructs that are useful because of their general applicability, not because of their intrinsic aspects.
The domain expertise is still, what’s important, and code craftsmanship was the ability to create something that matches it closely enough that the cost of changes was minimal.
Software is verifiable given a specific test oracle. There are however many problems where providing a correct test oracle is at least as hard as solving the problem itself.
If you’ve ever worked on projects with “Model Based Systems Engineering” you’ll have felt this pain.
While afraid that we developers will eventually be automated away — as I have bills to pay —, I only need to ask the JetBrains AI assistant for help to understand why that won't happen in my ‘career-span’.
It's not a diss on JetBrains, their assistant is good enough that I've paid for it for a few months; but ask of it anything a tad more complex and it becomes a code review for a PR that you begin to question in its entirety. I'm not familiar with CSS Grid, as I've stopped doing CSS when flex was becoming popular, but I have to say none of the models managed what I wanted. They kept proposing solutions with an arrogant confidence that this must work. When I pointed out this didn't work, they'd look at the codebase and find something else that was the problem. When I asked for help with a script for an Alpine box, it was very assertive that systemd-based solutions should work. How can you get that wrong?
I imagine the code laundering will eventually get far enough that you can copy-paste someone else's project fully baked, and then the LLM will truly shine. But for building something piece by piece, I haven't gotten good results yet. The Assistant so far has been most useful for writing unit tests, HTML, or getting a decent web search within the IDE.
I wonder if paying for Kagi wouldn't make for better search, and then I'd find some tool that writes unit tests based on your code. It really does feel like some people are being very generous about how magical these things are, because I'm not getting the magic at all.
If you're genuinely already good at coding, use the LLM to go horizontal into other complementary verticals that were too expensive to enter prior. Do the same thing that the other professions would do unto yours.
As an example, I would have never considered learning to use blender for 3d modeling in a game before having access to an LLM. The ability to quickly iterate through plausible 3d workflows and different design patterns is a revelation. Now, I can get through some reasonably complex art pipelines with a surprising amount of confidence. UV mapping I would have never learned without being able to annoy one of OAI's GPUs for a few hours. The sensation of solving a light map baking artifact on a coplanar triangle based upon principles developed from an LLM conversation was one of the biggest wins I've had in a long time.
The speed with which you can build confidence in complementary skills is the real super power here. Clean integration of many complex things is what typically brings value. Obsession with mastery in just one area (e.g. code) seems like the ultimate anti-pattern when working with these tools. You can practically download how to fly a helicopter into your brain like it's the matrix now. You won't be the best pilot on earth, but it might be enough to get you to the next scene.
If it's any consolation, I do think the non-technical users have a bigger hill to climb than the coders in many areas. Art is hard, but it is also more accessible and robust to failure modes. A developer can put crappy art in a game and ship it to steam. An artist might struggle just to get the tooling or builds working in the first place. Even with LLM assistance there is a lot to swim through. Getting art from 5% to 80% is usually enough to ship. Large parts of the code need to be nearly 100% correct or nothing works.
Thanks for this, I like your idea about breaking into areas I don't have experience with. E.g. in my case I might make a mobile app which I've never done before, and in theory it should be a lot easier with Claude than it would've been with just googling and reading documentation. Although I did kind of like that process of reading documentation and learning something new but you can't learn everything, you only have so much time on this planet
> Although I did kind of like that process of reading documentation and learning something new but you can't learn everything, you only have so much time on this planet
I actually enjoy reading the documentation more these days, because I am laser focused on what I want to pull out of it after seeing the LLM make a suspicious move.
I can confirm this. My datapoint: I was mostly a web developer but using these "vibe" tooling I am making my own hardware board and coding for embedded, which includes writing drivers from datasheets, doing SIMD optimizations, implementing newer research papers into my code, etc.
You word quite well how I feel about it.
On top of not really liking babysitting an AI , I'm also very afraid of the way this whole AI coding business normalizes needing an account with some nebulous evil empire to even be able to do your work. Brrr.
100%. Imagine how young people feel. When they’re still trying to figure things out, their parents and teachers just as clueless as they are, and at the same time the expectations of them are infinitely higher. “You’re pretty good, but chatgpt is still better. Try harder.”
Have you ever interacted with any "vibe"-based systems of agents in a production environment? Beyond just cool demos online?
My experience with them is they are fragile monstrosities, that are only permitted to exist at all because leadership is buying into the same hype that is irrationally propping up the companies running the models that make these things possible.
To be clear, my experience hasn't been that I don't like them, it's that they don't really work at all. They're constantly under development (often in the dark) and when a ray of light is cast on them they never successfully do the thing promised.
Cleaning up the messes left behind by these has my skills feeling more valuable then ever before.
I can relate with you. I love programming and building things, gives a different kind of rush when you finally figure out something. I've done vibe coding and don't enjoy it at all. I always thought my love for coding gives me an edge over other engineers who just want to get the job done. Now it's holding me back and I'm not sure if I should continue working in this field or if start doing wood working or something.
I still do all the stuff by hand, but ask the AI to review my work, provide suggestions, and occasionally write the tests (especially if it points out a bug that I disagree with). Its really good at pointing out typos (accidentally using the wrong variable of the same type, and stuff like that) that are also traditionally hard to spot during review.
Do not worry, I am mentoring a young engineer in my team. It is painfully hard to get him to improve his code, because it works. It is badly structured, lot of small "impedance mismatches", lot of small security issues, all that in 3 Python files.
I have a team of 10 engineers, the quality of the code they produce together with the LLM of the day correlates even more with the experience.
My impression over the past 6 months - before we had no "official" access to LLM, is that they increase the gap between junior and experienced developers.
Note that this is my limited impression from a team of 10 engineers. This matches with Simon's feeling in a good way for you!
You were never paid to type. You were paid to solve problems. And big part of this is being able to ask the right questions and framing of the problems. The rest were just tools.
There are exceptions of course - where you need to squeeze wonders from the hardware - but the majority of dev works boils to understanding the problem and finding the right answers.
You say this because you are on HN, very senior and/or living in a bubble.
In the vast majority of programming jobs out there you are not paid to solve problems: you are told very clearly what to do, how to do it and what technology you have to use for the job.
People don't hire analysts they hire "Java programmers".
If you've ever lead a team, you know how much more valuable people are if they don't need to be told how to do things. Even more if they don't need to be told what to do! But having to explain in detail the "how".. can be really a big time sink and only worth it if you are training someone to level up.
The thing is that the poster I responded to also is those three things. And I am just pointing out that his job was never to keep up with the frameworks.
People keep comparing LLMs to automated looms, but I find them more comparable to cruise control than autopilot.
I've been working on a character sheet application for a while, and decided to vibe-code it with Spec-kit to help me write up a specification, and for things I know it's been great.
I tried using Claude to make it into a PWA (something I don't know very well) as an experiment, and I've found the nanosecond the model strays out of my experience and knowledge everything goes straight to Hell. It wraps my codebase around a tree as if I'm not paying attention while driving.
It's a tool you'll have to learn to use, but I can say with absolute confidence it's no replacement for actual skills, if anything it highlights the gulf between people who know what they're doing and people who don't, for better and worse.
It sacrifices some of the 'code under your fingers' feeling for management tasks, which I personally really like, as I've always wanted to document/test/code review/spec things out better, and I now understand the pain of people who'd rather not do that sort of thing.
The difference is that you can trust cruise control to do whatever limited job it knows how to do; you can't trust an LLM to do anything. That makes it, I think, hard to compare to anything we're used to (happily) working with.
Cruise control is a useful technology, that once you learn to use, it's automatic (somethingsomething pun something). LLMs on the other hand - well, yeah - if you like playing chess with pieces and board made out of smoke (to paraphrase Jerry Seinfeld), sure you'll probably figure it out...some day...
It kinda feels like you turn from a software engineer to an offshoring manager.
Offshoring software development means letting lower-payed software developers from somewhere far away do the actual programming, but they have a very different culture than you, and they typically don't share your work context, don't really have a feeling for how the software is used -- unless you provide that.
Now we're offshoring to non-sentient, mostly stateless instances of coding agents. You still have to learn how to deal with them, but you're not learning about a real human culture and mindset, you learn about something that could be totally changed with the next release of the underlying model.
My rule of thumb, and its likely not the industry standard is, if I cannot maintain the code should all AI disappear, I don't use the code. I am able to tackle impostor syndrome that sometimes hits when I touch things that are new or unknown to me, and ask an LLM to give me sources and reasons and even explain it like I'm a five year old.
The LLM will not save you when everything is on fire and you need to fix things. The context window is simply not big enough. It could be your last change, it could also be a change six months ago that is lost in the weeds.
There are a ton of them already in game dev but they produce unfun games so you don’t hear about them. The hard part of game dev is designing actually fun experiences.
I can't even begin to imagine how a 12-year old who discovered how empowering bending the machine to do your will through code feels when, over time, realize that their dream career has been reduced to being an LLM middleman.
>I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart.
Tools always empower those with knowledge further than those without knowledge.
Don't worry, it's probably only the impostor syndrome. Your development skills are still relevant. Think of agents as junior developers that assist you in coding tasks, whom you constantly need to mentor, review, and correct.
That’s true, however the current vibe coding ecosystem is clearly not written in this mindset. You will have a hard time to dive into anything if you previously generated 2k LOC/hour, which is absolutely possible. Typing was never the bottleneck, understanding, and knowing that you did something well was always the real bottleneck. LLMs make this even worse. You can move Jira tickets to done faster with it, but even bad developers can do that many times compared to better ones, because for example they mindlessly copy-paste StackOverflow answers whose half of the code is absolutely not necessary, but they don’t care, because “it works”… until it doesn’t.
Better documentation, more test cases, and an NLP interface to query the code
Less cognitive load, more complete mental models
>even bad developers can do that many times compared to better ones, because for example they mindlessly copy-paste StackOverflow answers whose half of the code is absolutely not necessary
Maybe LLMs, much like StackOverflow, make good devs better and bad devs worse
Like a force multiplier for good practices and bad practices
The exact people who said to me that I’m using LLMs wrongly, and showed their code, showed me bad code. So let’s say, that “more documentation, which is unnecessary most time, ie noise, more test cases, which test not necessarily what they should, and an NLP interface which lies from time-to-time”, and we agree. LLM generated code is noisy as hell, for no good reason. Maybe, it’s good for you, and your type of work. I need to provide way better code than that. I don’t know why we pretend that “good code”, “good documentation”, “good tests” etc are the same for everybody.
>LLM generated code is noisy as hell, for no good reason
You can direct it to generate code/docs in whatever format or structure you want, prioritising the good practices and avoiding bad practices, and then manually edit as needed
For example with documentation I direct it to:
*Goal:* Any code you generate must lower cognitive load and be backed by accurate, minimal, and maintainable documentation
I had a fascinating conversation about this the other day. An engineer was telling me about his LLM process, which is effectively this:
1. Collaborate on a detailed spec
2. Have it implement that spec
3. Spend a lot of time on review and QA - is the code good? Does the feature work well?
4. Take lessons from that process and write them down for the LLM to use next time - using CLAUDE.md or similar
That last step is the interesting one. You're right: humans improve, LLMs don't... but that means it's on us as their users to manage the improvement cycle by using every feature iteration as as opportunity to improve how they work.
I've heard similar things from a few people now: by constantly iterating on their CLAUDE.md - adding extra instructions every time the bot makes a mistake, telling it to do things like always write the tests first, run the linter, reuse the BaseView class when building a new application view, etc - they get wildly better results over time.
AGENTS.md is just a place to put stuff you don't want to tell LLMs over and over again. They're not magical instructions LLMs follow 100% of the time, they don't carry any additional importance over what you put into the prompt manually. Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are. Somewhere around 100k tokens AGENTS.md might as well not exit, I constantly have to "remind it" of the very first paragraph there.
Go start a conversation and contradict what's written in AGENTS.md half way through the problem. Which of the two contradicting statements will take preference? The latter one! Therefore, all the time you've spent curating your AGENTS.md is the time you've wasted thinking you're "teaching" LLMs anything.
Whether the tokens are created manually or programmatically isn't really relevant here. The order and amount of tokens is, in combination with the ingestion -> output logic which the LLM API / inference engine operates on. Many current models definitely have the tendency to start veering off after 100k tokens, which makes context pruning important as well.
What if you just automatically append the .md file at the end of the context, instead of prepending at the start, and add a note that the instructions in the .md file should always be prioritized?
> Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are.
If that's genuinely causing you problems you can restart your session frequently to avoid the context rot.
Come on, let's not pretend 100k tokens is something I need to spend hours to reach for your helpful advice to be even remotely valid, it's something even the most basic problems struggle to fit into.
For the fun of it I just started a new conversation with Sonnet 4, passed it one 550 lines long file (25 kilobytes) and my AGENTS.md (<200 lines, 8 kilobytes) and my only instructions were to "do nothing". It spat out exactly 100 words describing my file without modifying anything and that's already almost a fifth of my context window gone (18k tokens to be exact).
I then asked it to re-write a part of it to "make it look better" (184 lines added, 112 lines deleted according to git) and I'm already at 33k before I got to review a single line. Heaven forbid I need to build on top of that change in a different file, because by then my AGENTS.md might as well not exist!
Thanks for bringing numbers. I realize now I've not actually done much customization of AGENTS.md myself yet, so maybe I'll start seeing the problems you're describing more as I iterate on my own custom files.
I thought about making some kind of community project where people could contribute their lines to a common file, and even some kind of MCP server or RAG system that automatically selects relevant "rules" given a certain project context. Do you think there would be interest in something like that?
Totally agree on this. It has delivered a substantial value for me in my projects. The models are always going to give back results optimized for using minimal computing resources in the provider's infrastructure. To overcome this I see some using/suggesting, running the AI in self correction loops, the pro being least human intervention.
However, personally I have got very good results by taking the approach of using the AI with continuous interaction and also allowing implementation only after a good amount of time deliberating on design/architecture. I almost always append 'do not implement before we discuss and finalize the design' or 'clarify your assumptions, doubts or queries before implementation'.
When I asked Gemini to give a name for such an interaction it suggested 'Dialog Driven Development' also contrasted it against 'vide coding'. Transcript summary and AI disclaimer written by Gemini below
I’m finding that whether this process works well is a measure (and a function) of how well-factored and disciplined a codebase is in the first place. Funnily enough, LLMs do seem to have a better time extending systems that are well-engineered for extensibility.
That’s the part which gives me optimism, and even more enjoyment of the craft — that quality pays back so immediately, makes it that much easier to justify the extra effort, and having these tools at our disposal reduces the ‘activation energy’ for necessary re-work that may before have just seemed too monumental.
If a codebase is in a good shape for people to produce high-quality work, then so too can the machines. Clear, up-to-date, close-to-the-code, low redundancy documentation; self-documenting code and tests, that prioritizes expression of intent over cleverness; consistent patterns of abstraction that don’t necessitate jarring context switches from one area to the next; etc.
All this stuff is so much easier to lay down with an agent loaded up on the relevant context too.
Edit: oh, I see you said as much in the article :)
> Can we all agree that "mentoring" LLMs is actually a waste of time, please?
Sorry, we can't. While it's true that you can't really modify the underlying model, updating your AGENTS.md (or whatever) with your expected coding style, best practices, common gotchas etc is a type of mentoring.
Fair enough. But don't you think giving a junior a handbook you wrote is mentoring? They may not be able to memorise it, but they now have a handbook that they can look up things.
Maybe not in the session you interact with, however we are in a 'learning' phase now where I'm confident enough usage of AI coding agents is tracked and analyzed by its developers; this feedback cycle can in theory produce newer and better generations of AI coding agents.
No, I don't think they will always be junior developers. Obviously there will be a day that they will surpass humans.
However, the progress doesn't look linear with the current technology, and I don't expect to see the same big jump in the next 5 years as we've seen in the last 5 unless we discover a disruptive, new technology.
This can also be observed by comparing models with ~3B, ~30B, and ~300B parameters. You can see a huge performance boost when going from 3B to 30B, but we don't see the same when going to 300B. Simply adding 10x more RAM and GPU power brings diminishing returns.
The gains seem to be leveling to me but I'm not using them as much as others.
Still seems like people are saying the same things when the first Claude came out.
I can get it do stuff if I'm very specific, stand over it's shoulder, know exactly what I want, break it down into small chunks.
The thing for me is... at that point, writing the code's the least time consuming part of the process half the time.
I think for things like translating some code in JS with JSDocs to TypeScript I may give this a go. But for regular development work I'll probably skip it.
That being said... no one lets me code anymore. It's just confluence docs with Figma architecture diagrams these days. I'd probably just introduce SQL injection vulnerabilities if they let me near an editor these days
Junior developers or maybe even better, outsourced developers - there's a big segment of software engineering that involves writing requirements and checking the work of an external software development company, with many companies heavily dependent on it (as they outsourced part of their core business, e.g. mainframes, SAP, whatever).
As for flow state managing multiple things, I've found this is a useful skill to train even without AI - if you have a workplace with lots of interruptions and shifting priorities.
I've found two things useful:
1) Keep a personal work log, where you - in short bullet points - can document the progress of the task you were last working on, and can keep track of how many parallel tasks there are currently going on. If you can match it with Jira tickets, all the better, but as this is for personal use only, you can also add tasks that are not tracked in Jira at all.
2) If you cannot avoid context switches, make them explicit: Instead of trying to hold 3 tasks in your head at the same time, decide consciously if you want to switch what you're currently working on. If yes, take a few minutes to "suspend" the current task by saving and committing everything (as WIP commits if necessary) and writing all you need to remember into the worklog.
Be mindful of the context these posts are created in. Don't take the current echo chamber to heart.
For decades now, we are trying to lower the barrier to entry in software development.
We created Python, web frameworks and mobile development so easily accessible that you can become software developer by completing a short online boot camp. There is a lot of software developers posting here now who, 20 years ago, would not even consider this job because it would be way over their abilities.
This forum is equivalent if you had a forum about civil transportation that gathers airline pilots and uber drivers. Technically, they both do the same work. Just like in that forum, uber drivers would outnumber airline pilots and skew the topics related to their experience, here we get pushed topics about new frameworks, and AI assisted tools.
When I started working professionally 20 years ago, you could only get job in big companies working on big projects. No one else could afford a cost of custom software. Today, we reduced development costs and we have a huge pool of potential customers who can now afford services of software developers. Web shops, gambling sites, porn sites... This is the majority of software development work today. Boring repetitive tasks of gluing some imported modules together.
Serious development work didn't disappear. It is just not talked about here. There is still a need people who know what they are doing.
My advise is that if you want a satisfying development career, steer clear of latest hypes and don't go blindly following techbro lemmings. And most importantly, don't take career advice from anyone who finds his job so unsatisfying and tedious that he is trying to make AI do it for him. That's a major red flag.
I think the key is remind yourself is that an engineer is supposed to solve business problems. So use these new tools to be more effective in doing so.
An analogy is that people used to spend tons of time building out web server code but something like Django added tremendously useful abstractions and patterns to doing so, which allowed people to more productively add business value
LLMs are very much like WYSIWYG web editors of the early 2000s like Dreamweaver. They provide a human interface layer that abstracts away the coding, and neither does a particularly good job of it. When WYSIWYG first became a thing, there was talk that it would upend the web development industry. It did not.
One of the main points of my article was meant to be that LLMs don't abstract away the code, at least not if you're trying to use them for professional software development work as opposed to vibe coded prototypes and toy projects.
You shouldn't be discouraged. Now is the best time to create software. You have advantage that very few people have.
Its industry own fault that it is in the position that it is right now, and it will shift and change embrace it. I only wish I had your experience building software in professional environment.
You can literally build anything right now if you have the experience, I personally can't understand if the models are hallucinating hence the lack of experience writing and understanding code. However I always wanted to pivot into the industry but couldn't, hiring practices are brutal, internships are non-existent, junior roles are I think what senior used to be and the whole hr process is I don't know how to put it.
By using LLMs I can now build UIs, build functionality, iterate over design choices, learn about database design, etc. hopefully I will escape the tutorial hell and have my own working full stack web app soon.
> It makes me want to move into something completely different like sales
I'm feeling the same. The moves I'm considering are
1. Landscaping
2. Carpentry
3. Small scale agriculture
(All made easier by a cushion of investments that are most of the way to passive income, so the new thing doesn't really have to make me that much money.)
My father runs a commercial landscaping company with 15 employees. His truck fleet insurance went up 35% just this year. His light industrial facility that he operates out of property taxes went up 55% last year. All of his commercial clients are cheaping out on all the little things that used to make extra money (pine straw, seasonal flowers, etc.). He’s having to deal with poorly educated staff who are constantly breaking equipment and doing stupid dangerous things. He’s so burned out by it all, and the fact that his actual salary is less than several of his top staff that he’s thinking about just shutting it all down. When I was working as a software developer, my income was probably twice as much as his without any of the risk or headache.
I hear you man. Didn't intend to paint a rosy image of hard working landscapers. What I meant was do it more like a hobby that pays a little on the side. Doesn't have to be much, just pay some bills and let me do sth I like. Cause supervising a bunch of immature LLM agents is not something I'll like to do all day, I'd rather trim trees and plant flowers on the cheap.
I bailed out of a FAANG job to cook in restaurants in the Bay Area and it was very double-edged. I gave up after a year for a variety of reasons.
The actual work was definitely more enjoyable.
"Paying the bills", on the other hand, actually took a lot of money (and I had a laughably small mortgage and two people sharing it at the time).
I also worked way more hours (30-40% of which were unpaid because yay fine dining), and it was physically way more brutal.
But then again, almost 10 years later, I'm back to the idea of opening a place of my own because the current tech landscape really doesn't attract me at all anymore and I can't get myself to last in it.
Yes and especially with new developments, like "$Framework now has Signals!", my thought is "I don't really care since in some years, it won't matter anyways". I don't see how I can build this lower level knowledge by almost never actually using it. I don't even want to think about job-interviews after a year+ of vibing and then being asked how RxJS works.
I'm preparing mentally for my day-job to stop being fun (it still beats most other occupations I guess), and keep my side/hobby-projects strictly AI-free, to keep my sanity and prevent athropy.
I just hope we'll get out of this weird limbo at some time, where AI is too good to ignore, but too unreliable to be left alone. I don't want to deal with two pressures at work.
I feel the opposite. I get to sit down and think about problems, expressing them in words as best I can, and then review the code, make sure that I understand it and it works as it should, all in a fraction of the time it used to take me. I like that I don't have to google APIs as much as I did before, and instead I can get a working thing much faster.
I can focus on actually solving problems rather than on writing clever and/or cute-looking code, which ironically also gives me more time later to over-optimize stuff at my leisure.
I feel this way with some of the work I've pushed through an LLM, but part of the time I'm left wondering what kind of Mickey Mouse problems people are working on where they are able to form up tidy English descriptions in complicated domains to capture what they're trying to achieve.
If I have a clear idea of some algorithm I am trying to write, I have a concise method for expressing it already, and it ain't English.
I suppose the other thing I would say is that reading code and understanding is definitely not the same as writing code and understanding it in terms of depth of understanding, and I think this notion that reviewing the outputs ought to be enough fails to capture the depth of understanding that comes with actually crafting it. You may not think this matters, but I'm pretty sure it does.
Something I really appreciate about LLMs is that they make a whole bunch of much more sophisticated reliable tooling acceptable to me.
I've always been fascinated by AST traversal and advanced refactoring tools - things like tree-sitter or Facebooks's old codemod system https://github.com/facebookarchive/codemod
I never used them, because the learning curve in them was steep enough that I never found the time to climb it to the point that I could start solving problems.
Modern LLMs know all of these tools, which flattens that curve for me - I find it much easier to learn something like that if I can start from semi-working examples directly applicable to what I'm trying to do.
I have a relative who's in her 70s and used to be a coder. She told me she gave up coding when people introduced computers with terminals. She was used to filling out punch cards and felt like the way she worked, although constantly evolving, was something she could keep up with. When the new stuff came, with virtual programs and you just typing on a computer and no way to properly debug by shuffling the cards around, she ended up moving to something completely different...
I’m sorry you feel that way but that’s a surprising experience, I find flow states easier managing agents than actually coding. Each of course, to their own. Is it possible you were reaching the end of your tether anyway in the coding space? Feel free to slap that accusation down if it’s unfair.
Don't worry about it. Don't let anyone else tell you how best to use AI, use AI in a way that suits YOU, then it is so much fun. I would go crazy if I had multiple streams simultaneously working on stuff that need constant supervision (that would be different if I could trust they do 100% what I intend them to do), but AI is still very helpful in other ways (research, exploration, and writing tests).
This line really hit me. I used to think that mastering one advanced skill would be enough to rely on for life, but it seems that’s no longer the case.
I wonder how this will affect the burnout rate among IT workers in the long-term, which already was quite high. I guess a lot of people force themselves (or are forced to by their company) to use LLM in fear of being left behind, even if they don't enjoy the process, but sooner or later the fatigue will catch up.
> It makes me want to move into something completely different like sales
Aaand that's startup founder life :)
Intense multitasking, needing to accept a lower engineering quality bar, and ignoring scale problems because you don't know if anyone will actually buy the thing you're building yet.
Engineering something that you know you'll redo in 1 month is very different from engineering something that you intend to last for 5+ years, but it's still a fun challenge picking the right tradeoffs and working under different constraints.
it's taken programming from being fully waiting on compilations to being incrementally compiled and productive back to waiting on the compiler all over again.
The experience you have is something most youngsters won't ever get, because they won't have the time. You've become more valuable than you used to be, because you know exactly what works when and what doesn't. The hard part is being able to find the joy in making agents do what you want achieved instead of building it yourself. I think it actually isn't too hard once you get up to speed with managing multiple agents - efficiently juggling them feels like an art performance sometimes.
This is going to sound harsh, but welcome to the real world, I guess. Being in IT is pretty much the only job I know of today that is stable, pays well, is enjoyable, feels like it affects the world, personally engaging and challenging, etc. Being not in IT (it's just a hobby of mine) your comment sounds like "Well I had absolutely everything, and I still do but now it's not as fun anymore!"
Well-put. Sw eng is so much better, assuming you are comfortable in the role, for types who want to punch a clock doing something they don't hate.
Sales is the definition of high-pressure, and your output is always threatened by forces beyond your control. It doesn't consistently reward intelligence or any particular skill other than hustle.
There's nothing like sw dev that lets you sit at your desk and ignore the outside world while getting paid for delivering biz-critical milestones. Even creatives don't have this kind of potential autonomy.
It is just a new way of coding. And indeed what the blog post said, if you are experienced, you will benefit the most as the AI agent will make similar mistakes as a junior and you will be able to recognize them.
But indeed, the fun part of coding a couple of routines is gone. That is history.
Around the time GPT-4 was released in early 2023, a similar issue arose with another profession: translation. It was at that point that machine translation between languages like English and Japanese (the language pair I have worked with) started to approach human level for the first time.
I took part in a lot of discussions then with other professional translators, and the reaction of many was similar to that of some of the commenters here: not only were they discouraged because their hard-earned language and translation skills no longer seemed needed, but using LLMs as assistants took the enjoyable challenge out of the translation process.
Nearly everyone I spoke with then worked from home as a freelancer, carefully crafting one translation at a time. They didn’t like the idea of becoming managers of large-scale translation projects, even if it meant they would be able to apply their higher-order intercultural communication skills.
I do only a little professional translation myself now, but I try to keep up with AI developments and I often use translation tasks to test the latest models and frameworks. Over the past few months, I have vibe-coded some multi-LLM translation systems where texts were passed through multiple models that checked, critiqued, and improved each other’s translations. For the texts I tried them on, the results were much better than any single-LLM translation, approaching the level of the very best human translation. The API calls weren’t cheap, but for high-stakes translations such a system would more than pay for itself.
When designing that “vibe translation” system, I did apply my experience as a translator, similarly to what Simon is recommending programmers do now with vibe engineering. At this stage in my life (I’m sixty-eight), I am fine with that. But if LLMs had arrived when I was, say, just five or ten years into my translation career and still proud of my nuts-and-bolts skills, I might very well have looked for another career rather than becoming a vibe translator.
Translation is great to discuss LLMs. Thanks for sharing your experience.
On one side translation is not very valued by most people. It is rare that people know who translated a book, for example. It is a pity but people do not read much these days.
Additionally, or maybe because of the above, translation is often paid in terms of number of lines or words, even before AI. A bit like software security, it is often sadly just a check at the end.
IMHO the only future-proof translation fields are legal (because a human can be put in prison or pay a fine) or live translation/interpretation (because a human can go in front of people, meet them at an event, etc.).
There have been study results published quite recently that suggested otherwise, at least for the U.S.
While I don't recall the actual numbers, the number of people who said they read books pretty much crashed over the past two decades, and more parts of the population are considered to be functionally illiterate than in a long time.
I spoke with some professional translators early on and they were just in denial, getting even upset at the idea that an AI could replace them. I didn't push too much but felt bad for them, as they couldn't realize what was going to happen to their field. I really think that translation must be the most impacted field by AI.
Software engineers are the translators. We (as a metaphorical community are in denial). Read the 100s of comments on this post: either (AI code is wrong or this isn’t correct or it’s not effective or some other justification). At the end of the day it’s really hard to accept the change.
True, recently I started feeling that part of what I had been doing is simply translating natural language to programming languages. Though coding also involves things such as algorithm and data structures, context and background knowledge, but these can all be done in natural language. Once the natural language description is given, what remains is only translation. LLMs have good knowledge of almost anything, though they are currently weak on inference or derivation, but this already makes them good on the two end of software engineering -- context knowledge and translation.
I understand those people who hate LLMs for coding, I partly share the feeling, because I enjoy typing on a keyboard, editing part of the code, reading the characters, I am an Emacs user. If LLMs can do the work, even if just save the typing and editing part, some of the fun has been eliminated for me.
Think about chess and Go, though AI can easily beats human now, people are still playing it. For programming, if one day AI can do 80% of the programming work, I guess only few of programmers today can keep doing it as a job. Just like few people can play chess and Go as their job.
I don't think that's a fair characterisation. I gave these tools the benefit of the doubt and many genuine tries, and still do occasionally. My judgment that they're unfit for the task is based on finding that they objectively don't help me work. There are studies showing that LLM use slows experienced developers down, even as they believe the opposite. I used to be the only one in my immediate work environment who thought LLMs are of jack use in my development work. Over the past year, most devs who used LLMs heavily have now switched over to my view.
Translation is natural language in, natural language out. That has very little to do with programming. Dijkstra knew back in the 70s that the very concept of natural language programming was bullshit, and that fancy new tech is never going to change the fundamental issues with the idea. In my opinion, his argument is as valid as ever.
Edit: I wasn't trying to imply that natural to natural language translation is trivial. The best LLM tools can be pretty shit at that even today, too. Tried using localised Microsoft developer documentation lately. It's unintelligible.
This is a really great comparison to draw. This actually made me think that this feeling of going from mastering a craft to working on large scale systems is probably how someone who was passionate about cars felt when they went from building cars one by one, knowing how the whole machine works to then having to take a job on an assembly line.
Fortunately I think anything pertaining to vibe coding/engineering/analytics is still more enjoyable and less grim than working on an assembly line, but the human feelings remain nonetheless.
A better term is agentic coding, agentic software engineering, etc. rather than being vibe based.
My process starts from a Claude Code plan, whose first step is to write a spec. I use TDD, and enforce my "unspoken rules of code quality" using a slew of generated tools. One tiny tool blocks code which violates our design system. Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer. Watching the transcript I have to occasionally remind the model to use TDD, but once it's been reminded it doesn't need reminding again until compaction. Claude 4.5 is far better at remembering to do TDD than 4.1 was.
Code reviews are super simple with TDD due to the tests mirroring the code. I also create a simple tool which hands the PR and spec to Gemini and has it describe any discrepancies: extra stuff, incorrect stuff, or missing stuff. It's been great as a backup.
But ultimately there's no substitute for knowing what you want, and knowing how to recognize when the agent is deviating from that.
The opposite of "garbage-in garbage-out" is quality in => quality out.
I spent some time trying to think of a better term because I also think "vibe" detracts from the intent, and I think you nailed it with "agentic coding". Ill do my part by using that term now, hopefully it catches on : D
I was writing up some recommendations to my team for using Github Copilot in its different modes + Roo Code/Cline and tried so hard to avoid using “vibe coding” in a professional context. For sake of clarity I ended up including it once in a “you may have heard the term…” style reference but it just comes across as so deeply unserious and felt ridiculous being forced to use it at all.
I also landed on “agentic coding” FWIW. It’s a bit clunky but didn’t feel like an embarrassment to the entire software industry typing it so I’ll happily use it over the alternative.
> Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer.
Is that an llm agent or some other type of tool (e.g. language service or build toolset)?
When I say "tool" I really mean a python script. This particular one is ~100 lines of python with a main() method, that Claude Code wrote in a single shot, that I then committed to the repo in a scripts/ directory. That lets me include it in pre-commit hooks, run it when I run the tests, and have it run during CI.
A 100 line script finishes in milliseconds and burns no tokens. So you can run it hundreds of times per day.
The mindset is: will you need repeatability? If so, have the LLM write code, because code gives you determinism.
I don't know how vibe coding works, but how does this work - is the agent actually engaging in the red-green-refactor loop, or does it just generate the result all at once?
I don't get the obsession some tech people have to push the idea that this stuff accelerate your coding, increase your productivity. It's all about fast and faster output. In my experience LLMs have mostly produced gibberish oververbose code, surely faster than me, but my lower speed usually produce better code. I don't like this present state of things where we need to chat faster to quickly get out results and go fast in production... that is the kind of mentality that pushed subpar products on the web for so many years. Instead of dropping names lile vibe coding/engineering whatever comes next, let's have a serious discussion why we need faster low quality and we can't just improve automation and processes. Eg I can get unit test generated very fast sure, but my question is: why do we need all these unit tests in the first place? Dont get me wrong they're useful, but I feel like we're advancing higher abstraction instead of advancing lower level tools
> that is the kind of mentality that pushed subpar products on the web for so many years
Famously, some of those subpar products are now household names who were able to stake out their place in the market because of their ability to move quickly and iterate. Had they prioritized long-maintainable code quality rather than user journey, it's possible they wouldn't be where they are today.
"Move fast and break things" wasn't a joke; Mark really did encourage people to build faster and it helped cement their positioning. Think of the quantity of features FB shoveled out between 2009-2014 or so, that just wouldn't have been possible if their primary objective was flawless code.
The code isn't the product, the product is the product. In all my years of engineering I've yet to have an end-user tell me they liked my coding style, they've always been more concerned with what I'd built them.
Running a platform where billions of users are able to communicate is pretty technologically marvel.
Lest not forget when Hotz said he could easily fix Twitter's search functionality only to give up after 3 months [1]. When immensen scale is involved things do become difficult.
Like we have a comment below taking a shot at Phillip Morris [2]. Lets see you grow, process, and distribute 1/100 the quality of cigarettes. The end product might not be that great for society but it's not trivial to do it either.
Withdrawal symptoms :P The buyer decides whether their problem is a good one to have and whether the solution is adequate. Even when it's, objectively, not.
Earlier than that, Facebook became ascendent because of quality. It was better than MySpace, the only real competitor at the time. The issue here is Facebook is not primarily a software product. It's a community, and the community was better than MySpace because it was restricted to pre-existing networks rather than taking any comer. I don't think Mark did that on purpose as a calculated decision. He just got lucky. When they eventually opened up and became just as shitty as MySpace had been, they were big enough to simply acquire better products that might have been competitors, and network effects locked them in for probably decades until their users die off and don't get replaced by younger people who never used Facebook.
I don't really see it as an example of what you're saying so much as an example of success as a product having to do with far more than explicit product features. You can see a similar dynamic in other natural monopoly markets. The NBA didn't necessarily do anything particularly right product wise, for instance. They just got the best players because basketball was historically more popular in the US than other countries, and the ABA made some stupid decisions that let the NBA win out in the US.
Hell, the US itself didn't do a whole lot "right" aside from not being in Europe when Europe decided to destroy itself, being better-positioned than other potential competitors like Canada, Mexico, and Australia simply because North America is best positioned to trade with both Europe and Asia and the US is more temperate than Canada or Mexico. But we sure like to tell ourselves stories about everything we did right.
Yes, both impact each other, and if facebook was just shoddily coupled together it probably wouldn't be a great product, but so many engineers get into this mindset of needing finely tuned clean code vs a working product.
When people were switching, how many decided to use facebook because the coding style of the backend was really clean and had good isomorphism?
There's a balance with this, but so much of it's success was being at the right place at the right time, and if you spend a massive amunt of time not building product and just building good code, you're going to hit a failure.
Total side note, it's interesting seeing "Move fast and break things" become the dominant phrase vs what I remember initially as the "MIT vs New Jersey methods". Both describe the same thing where fast and sloppy wins vs slow and clean.
I think the general issue with software engineering discourse is that while our tools and languages may be the same, there's a massive gradient in tolerance for incorrectness, security, compliance, maintainability.
Some of us are building prototypes, and others are building software with a 10 year horizon or work with sensitive personal data.
So on the one side you get people that are super efficient cranking things out, and others that read this and feel appalled anyone would be comfortable with this and see software engineering as theory building. Neither are really wrong here, but the context / risk of what people are working on always seems to be missing when people talk about this.
I have yet to see in my life a prototypes that doesn't become production :) Btw my whole point wasn't on security and can't find a compelling reason to talk about it, it rather questions "faster results" as "better productivity" it isn't, and imo we should pause for a moment and focus on better tooling
We live in an objective reality. LLM's help a damn lot in speed of development. As someone who has been coding since 5th grade for over 20 years who is known to be a LIGHTNING FAST implementor by many people I have been scaled ridiculously with LLM's. Genie is out of the bag, you have to go with the flow, adapt or else....
I am just as pissed as anybody else at the lack of certainty in the future.... Thought I had my career made. So it's not that I don't emphatize with engineers in my shoes.
Good lord I wish I could have as many certainties as well, one point at a time:
* There is no objective reality, there isn't one in physics, it's just a non argument
* "LLM's help a damn lot in speed of development" That may be your experience and my whole point was arguing that speed may not matter
* "Genie is out of the bag, you have to go with the flow, adapt or else" I choose else
if this the apex of the argument
If you go down in physics you might discover that the reality seems to be composed a lot more by probabilities. An objective reality built on probabilities does not seem so objective afterall.
Here is a fun think to try: demonstrate that you and me are seeing the same color in the same way? You might find some papers trying to prove it but you will se they are all based on subjective answers of people.
So while at macro level the reality seems hard and objective at the micro level it is not.
It's an objective reality. Even at quantum level the known laws of nature hold. Even if there is uncertainty, nature is predictable in following the laws of physics.
And ofc at macro level we live in a very objective reality. This is the basis of science.
> why do we need all these unit tests in the first place?
The same reason we've always needed them:
1: They prevent regressions. (IE, bugs in features that were shipped and already working.)
2: They are very easy to run at the push of a button in your IDE. (But in this context the LLM runs them.)
3: They run in CI. This is an important line of defense in making sure a pull request doesn't introduce a bug.
Now, depending on what you're writing, you might not need unit tests! Perhaps you're trying to get a minimum viable product out the door? Perhaps you're trying to demo a feature to see if it's worth building? Perhaps you're writing a 1-off tool that you'll run a few times and throw away?
But, understand that if you're writing an industrial-strength program, your unit tests help you ship bug-free software. They allow you to do some rather major refactors, sometimes touching areas of the codebase that you only lightly understand, without needing to manually test everything.
(And, to keep it in context,) your LLM will also have the same benefits from this tired-and-true process.
Thanks for the non solicited lesson, I learned basically nothing new. That unit tests ships bug free software is such an overstatement... Btw please go re read my comment and try to understand what I was actually trying to argue about, and I also wrote that I think they can be useful...
You aren’t entertaining the possibility that some experienced engineerings are using these tools to produce incredibly high quality code, while still massively increasing productivity. With good prompting and “vibe engineering” practices, I can assure you: the code I get Claude Code to produce is top notch.
I'm experienced, I don't accept the implication that I might not be able to use these tools are their full potential and you won't convince me only because you mention an anecdotical example
Absolutely but we're talking about structured tools, like a cli, not unstructured non deterministic "agents" that fails to give the same answer twice, ls -la doesn't lie
You also must be very confident in your own ability if you don’t think that at least some of the things you’re doing that you’d classify as “skill at using the tool” aren’t just superstitions à la Skinner’s pigeons.
> One of the more "engineering" like skills in using this stuff is methodically figuring out what's a superstition and what actually works.
The problem is there are so many variables and the system is so chaotic that this is a nearly impossible task for things that don’t have an absolutely enormous effect size.
For most things you’re testing, you need to run the experiment many many times to get any kind is statistically significant result, which rules out manual review.
And since we have tried and failed to develop objective code quality metrics, you’re left with metrics like “does this pass the automated test or not!”, but that doesn’t tell you whether the code is any good, or whether it is overfitting the test suite. Then when a new model comes out, you have to scrap your results and run your experiments all over. This is engineering of the laws of physics were constantly changing, and I lived in that universe, I think I’d take my ball and go home.
There's always been a bit of magic to being a programmer, and if you look at the cover of SICP people like to imagine that they are wizards or alchemists. But "vibe engineering" moves that to a whole new level. You're a wizard mixing up gunpowder and sacrificing chickens to fire spirits before you light it. It's not engineering because unless the models fundamentally change you'll never be able to really sort the science from the superstition. Software engineering already had too much superstition for my taste, but we're at a whole new level now.
Here's an example from today of something I just figured out.
I had Claude Code do some work which I pushed as a branch to GitHub. Then I opened a PR so I could more easily review it and added a bunch of notes and comments there.
On a hunch, I pasted the URL to that PR into Claude Code and said "use the GitHub API to fetch the notes on this PR"...
... and it did exactly that. It guesses the API URL, fetched the JSON and read my notes back to me.
I told it to address each note in turn and commit the result. It did.
If a future model changes such that it can no longer correctly guess the URL to fetch JSON notes for a GitHub PR I'll notice when this trick fails. For the moment it's something I get to tuck in my ever expanding list of things that Claude (and likely other good models) can do.
Since you are convinced you’re using the tools to their full potential, the quality problem you experience is 100% the tools fault. This means there is no possible change in your own behavior that would yield better results. This is one of those beliefs that is self fulfilling.
I’ve found it much more useful in life to always assume I’m not doing something to its full potential.
Yes they are. Guide dogs, hunting dogs, sheep dogs. The comparison to LLMs is genuinely useful here, because dogs are unreliable tools that you have to work with over a period of time to figure out.
I've used this argument for real in the past with people who complain that it's unethical to set sightless people up with vision LLM tools because those tools are unreliable and make mistakes. My counter is that a) so are guide dogs and b) it's rude to discount the agency of people with accessibility needs in evaluating and selecting tools for themselves.
You see a large % of failures, but you're drawing an unsupported conclusion.
We all agree, the people that _feel_ the most productivity spike are the sub-par engineers. That shouldn't be controversial, and it's even predictable.
But their volume can't be taken as an argument one way or the other.
The question is, are there _any_ good engineers that don't just feel more productive, but objectively are.
People are constantly looking for definite tendencies and magic patterns so they can abdicate situational awareness and critical thinking. We observe that fast delivery has often correlated with success in software and we infer that fast delivery is a factor of success. Then it becomes about the mindless pursuit of the measure, speed of delivery, as Goodhart's law predicts.
Let's even concede that speed of delivery indeed is an actual factor, there has to be a threshold. There's a point where people just don't care how fast you're putting out features, because your product has found its sweet spot and is perfectly scratching its market's itch. A few will clearly notice when the line of diminishing returns is crossed and if they can reset their outlook to fit the new context, a continuous focus on speed of delivery will look increasingly obsessive and nonsensical.
But that's the reality of the majority of the software development world. Few of us work on anything mission critical. We could produce nice sane software at a reasonable pace with decent output, but we're sold the idea that there's always more productivity to squeeze and we're told that we really really want that juice.
That all things develop only so much before they degrade into overdevelopment was a very well understood phenomenon for ancient Taoists, and it will be the death of the modern Blackrock/Vanguard owned world which is absolutely ignorant of this principle.
I'll attempt to provide a reasonable argument for why speed of delivery is the most important thing in software development. I'll concede that I don't know if the below is true, and haven't conducted formal experiments, and have no real-world data to back up the claims, nor even define all the terms in the argument beyond generally accepted terminology. The premise of the argument therefore may be incorrect.
Trivial software is software for which
- the value of which the software solution is widely accepted and widely known in practice and
- formal verification exists and is possible to automate or
- only has a single satisfying possible implementation.
Most software is non-trivial.
There will always be:
- bugs in implementation
- missed requirements
- leaky abstractions
- incorrect features with no user or business value
- problems with integration
- problems with performance
- security problems
- complexity problems
- maintenance problems
in any non-trivial software no matter how "good" the engineer producing the code is or how "good" the code is.
These problems are surfaced and reduced to lie within acceptable operational tolerances via iterative development. It doesn't matter how formal our specifications are or how rigorous our verification procedures are if they are validated against an incorrect model of the problem we are attempting to solve with the software we write.
These problems can only be discovered through iterative acceptance testing, experimentation, and active use, maintenance, and constructive feedback on the quality of the software we write.
This means that the overall quality of any non-trivial software is dominated by the total number of quality feedback loops executed during its lifetime. The number of feedback loops during the software's lifetime are bound by the time it takes to complete a single synchchronous feedback loop. Multiple feedback loops may be executed in parallel, but Amdahl's law holds for overall delivery.
Therefore, time to delivery is the dominant factor to consider in order to produce valuable software products.
Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.
>> Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.
I'll reply just to that as it being the tldr. First of all tech debt is a thing and it's the thing that accumulates mostly thanks to fast feedback iterations. And in my experience the better the comunication, to get the implementation right, and the better the implementation and it happens that you can have solid features that you'll unlikely ever touch again, user base habit is also a thing, continuing on interating on something a user knows how to use and changing it is a bad thing. I'd also argue it's bad product/project management. But my whole original argument was why we'd need to have a greater speed in the first place, better tooling doesn't necessarily means faster output, productivity as well isn't measured as just faster output. Let me make a concrete example, if you ask an LLM X to produce a UI with some features, most of them will default to using React, why? Why can't we question the current state of web instead of continue to pile up abstractions over abstractions? Even if I ask the LLM to create a vanilla web app with HTML, why can't we have better tooling for sharing apps over the internet? The web is stagnant and instead of fixing it we're building castles over castles over it
Tech debt doesn't accrue because of fast feedback iterations. Tech debt accrues because it isn't paid down or is unrecognized during review. And like all working code, addressing it has a cost in terms of effort and verification. When the cost is too great, nobody is willing to pay it. So it accrues.
There aren't many features that you'll never touch again. There are some, but they usually don't really reach that stage before they are retired. Things like curl, emacs, and ethernet adapters still exist and are still under active development after existing for decades. Sure, maybe the one driver for an ethernet adapter that is no longer manufactured isn't very active, but adding support for os upgrades still requires maintenance. New protocols, encryption libraries and security patches have to be added to curl. emacs has to be specially maintained for the latest OSX and windows versions. Maintenance occurs in most living features.
Tools exist to produce extra productivity. Compilers are a tool so that we don't have to write assembly. High-level interpreted languages are a tool so we don't have to write ports for every system. Tools themselves are abstractions.
Software is abstractions all the way down. Everything is a stack on everything else. Including, even, the hardware. Many are old, tried and true abstractions, but there are dozens of layers between the text editor we enter our code into and the hardware that executes it. Most of the time we accept this, unless one of the layers break. Most of the time they don't, but that is the result of decades of management and maintenance, and efforts sometimes measured in huge numbers of working hours by dozens of people.
A person can write a rudimentary web browser. A person cannot write chrome with all its features today. The effort to do so would be too great to finish. In addition, if finished, it would provide little value to the market, because the original chrome would still exist and have gained new features and maintenance patches that improve its behavior from the divergent clone the hypothetical engineer created.
LLMs output react because react dominates their training data. You have to reject their plan and force them to choose your preferred architecture when they attempt to generate what you ask, but in a different way.
We can have better tooling for sharing apps than the web. First, it needs to be built. This takes effort, iteration, and time.
Second, it needs to be marketed and gain adoption. At one time, Netflix and the <blink> tag it implented dominated the web. Now it is a historical footnote.Massive migrations and adoptions happen.
Build the world you want to work in. And use the tools you think make you more productive. Measure those against new tools that come along, and adopt the ones that are better. That's all you can do.
I work at a FAANG adjacent company as an EM and the 4x engineers who’ve recently been PIPd all went off the deep end using agents to write huge amounts of convoluted or unsuitable code.
One of them has decades of experience coding and even devised our onboarding training for using Cursor and Bedrock at the company but they too were called out for building a wholly unsuitable and unmaintainable service which could have been more simply solved with some common libraries and Docker micro services rather than 10k+ lines of custom code.
We all receive a copy of Cursor and IntelliJ + Copilot on joining and I just keep seeing engineers (surprisingly the more experienced ones so far) footgunning themselves with these tools.
When pigeons are offered random rewards from a treat dispenser, they start doing all kinds of funny little dances and movements because they think the rewards are in response to their actions.
This is my favorite thing about this whole situation. I spend years trying to get teams to follow best practices. And then suddenly if you follow them the LLM is more effective so now they follow them ignoring that they could have been more effective this whole time.
I’m critiquing the term “vibe engineering” by highlighting that because of the random, chaotic, black box nature of LLMs it is very difficult to distinguish valid techniques from superstitions.
Thus what you are doing is closer to pigeons bobbing their heads to attempt to influence the random reward machine than it is to engineering.
For example saying things like “It is critical that you don’t delete working code” might actually be a valid general technique, or it might have just been something that appeared to work because of randomness, or it might be something that is needed for current models but won’t be necessary in a few months.
The nature of LLMs makes correctly identifying superstition nearly impossible. And the speed with which new models are released makes trying to do so akin to doing physics in a universe where the laws of nature are constantly changing.
You’re an alchemist mixing gunpowder and sacrificing chickens to fire spirits, not an engineer, and for the foreseeable future you have no hope of becoming an engineer.
I’m also highlighting the insanely addictive nature of random rewards.
See this is where I think I fundamentally disagree. It’s more like being a scientist who takes 10 rats and tries to train them to sniff out TB, and once they find one that can do it reliably, they go and do real work with it. Just because the rat is the one doing the sniffing doesn’t mean the scientists aren’t real scientists. And just because we work with a tool that isn’t perfectly reliable doesn’t make us any less engineers as long as we manage and take ownership of the output as we alter and massage it from the machine.
Imagine back in the day calling devs that didn’t write in assembly “alchemists” because they didn’t fully understand how a compiler works and just trusted it instead. As long as they’re reading the code, testing the logic, and working towards an outcome they take ownership of, they’re engineers, and so are people who use LLM’s. It’s dangerously close to elitism gatekeeping to say otherwise.
Also I’ve been a software engineer for 15 years so I think I don’t “have no hope of becoming a software engineer”, no personal attacks please.
Except it’s definitely not, a cargo cult is necessarily ending up with a result that doesn’t function. Whether you dislike it or not this is a real technique that produces real functioning results.
“One bird was conditioned to turn counter-clockwise about the cage, making two or three turns between reinforcements. Another repeatedly thrust its head into one of the upper corners of the cage. A third developed a 'tossing' response, as if placing its head beneath an invisible bar and lifting it repeatedly. Two birds developed a pendulum motion of the head and body, in which the head was extended forward and swung from right to left with a sharp movement followed by a somewhat slower return.”
“The experiment might be said to demonstrate a sort of superstition. The bird behaves as if there were a causal relation between its behavior and the presentation of food, although such a relation is lacking.”
I think we should just accept that vibe-coding has now semantically shifted to mean all AI-assisted coding. Actually, it makes sense to me even when a human is interacting directly with the code, because it feels a lot like pair-programming. As such, I really am "vibing" with the AI.
But then the original meaning of vibe-coding -- as in, "Take the wheel, LLama of God" -- does need a new term, because that will also be a lasting phenomenon. I propose "Yolo-Coding" -- It fits in nicely with the progression of No-Code, Low-Code, Yolo-Code.
Disagree, I think vibe coders should become synonymous with no-code and continue to be somewhat of a pejorative.
I don't like the term vibe engineer, but do agree there needs to be a term to signifiy the difference.
It's also possible in the future just being called a developer/engineer already implies you use coding agents and the people who do it "by hand" will not be the norm.
At $enterprise, we were just looking for a proper term that sets "responsible vibing" apart from "YOLO vibe coding". We landed on "agent assisted coding".
It's a bit more technical. And it has a three-letter acronym. Gotta have a three letter acronym.
Yes, please don't push "vibe engineering" to mean how you defined it in your blog post. To me, it means exactly the opposite.
I see "vibe" as pejorative. Adding "engineering" does not elevate it from "vibe coding", as I think is your intention in the post, it just shifts "vibe" term to a different domain.
To me, "vibe engineering" means using LLM to develop "design" with no care as to its validity just like "vibe coding" means for "code".
"Agentic xyz" or "Agent assisted xyz" is more fitting.
FWIW, I do not see "vibe" as always pejorative, rather it depends on goals. When quick results and not long term quality matter, "vibing" is a legit tactic.
Anyways, just my interpretations. Please, keep up the good work. Remember, the two hardest things in software are naming, cache invalidation and off-by-one errors. It's good you continue to tackle the zeroth one.
I really like "agent assisted coding". I think the word "vibe" is gonna always swing in a yolo direction, so having different words is helpful for differentiating fundamentally different applications of the same agentic coding tools.
Wasn't the original meaning of "vibe coding", as posted by Ilya Sutskever on twitter, that you just feed the model prompts and blindly run whatever results you get. No analysis or review, just copy/paste and hit run.
> now semantically shifted to mean all AI-assisted coding.
News to me. AI-assisted coding is more auto-complete or having it trying to make sense of awful documentation.
Vibe coding to means a number of things.
- The person has no skill in understanding what the LLM wrote.
- The code created hasn't been reviewed in any way to look for possible future issues.
- Technical debt from the get go.
- Legally your application is screwed.
For me the single killer of vibe coding is that anything the LLM creates cannot be protected/copyrighted. UK has some laws that might offer a little protection, but EU/US you are pretty much screwed.
A better term would be “Augmented Engineering” (AE).
You want something to inspire engineers to do their best work.
When you can expand your capabilities using the power of AI, then yeah, you can do your best work; hence augmented engineering.
But vibing? Not so much.
I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
I wouldn't worry too much about what to call it. Assigning a distinct label separates it from traditional engineering in a way that it assumes AI-assisted coding is only for a subset of developers. At some point the unusual approach will be writing code without any AI assistance. So the transition will leave the "vibe" behind.
> gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
Gives you access to the power to access and {mis}understand the {most repaeted over the last 1-10 years} engineering {errors, myths, misunderstandings, design flaws}, on demand, which you then can apply to your work {to further bias the dataset for future models to perpetuate the slop}.
Do NOT trust AI agents. Check their work at every level, find any source they claim to use, and check its sources to ensure that itself isn't AI too. They lie beyond their datasets, and their datasets are lying more for every minute that pass.
Now, seriously though, no tools is perfect, and I agree we should not trust it blindly, but leaving aside AI Agents, LLMs are very helpful in illuminating one's path, by consulting a large body of knowledge on demand, particularly when dealing with problems which might be new to you, but which have already been tackled one way or another by other people in the industry (provided they're in the training set of course).
Yes, there's always the risk of perpetuating existing slop. But that is the risk in any human endeavor. The majority of people mostly follow practices and knowledge established by the few. How many invent new things?
To be honest, I haven't yet used AI agents, I'm mostly just using LLMs as a dialogue partner to further my own understanding and to deepen my knowledge. I think we're all still trying to figure it out how to best use it.
> A better term would be “Augmented Engineering” (AE).
I don't think it necessarily deserves a special name. It is just engineering. You don't say book assisted engineering when you use a book as a reference. It is just engineering.
> But vibing? Not so much.
Just call it yolo engineering. Or machine outsourced irresponsible lmao engineering.
> I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
These seem like a lot of great ways to work around the limitations of LLMs. But I'm curious what people here think. Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to get it to actually do stuff. Sometimes things can go smoothly for a while, but you end up having to micromanage the output of the agent too much to bother. Or sacrifice code quality.
They're so nice for prototyping ideas and not becoming attached to the code due to sunken cost. I was playing around with generating intelligent diffs for changelogs for a game. I wasn't sure what approach to highlighting changes I wanted to take without being able to see the results.
Prior to vibe-coding, it would've been an arduous enough task that I would've done one implementation, looked at the time it took me and the output, and decided it was probably good enough. With vibe-coding, I was able to prototype three different approaches which required some heavy lifting that I really didn't want to logic out myself and get a feel for if any of the results were more compelling than others. Then I felt fine throwing away a couple of approaches because I only spent a handful of minutes getting them working rather than a couple of hours.
For stuff that I’m bad at? Probably more than 1000%. I’ve used it to make a web app, write some shader code, and set up some rtc streaming from unreal engine to the browser. I doubt I would have done them at all otherwise tbh. I just don’t have the energy and interest to conclude that those particular ventures were good uses of my time.
Yeah I couldn't put it better myself. It's obscene how much more productive you become in new domains. And sure, you eventually hit a wall where you gotta understand it for real. But now you have a working example of your project, plus a genius who will answer unlimited questions and clarifications.
Anything that's been done before. Otherwise we'd probably start with making nuclear fusion work, then head off into the stars...
You've always been able to read books. What you're talking about is skipping the slow learning step and instead generating a mashup of tons of prior art. I don't think it helps you learn. It sounds like it's for things you specifically don't want to learn.
Congrats, you now have a job similar to a factory worker turning a handle every day. Gone is that feeling of growth, that feeling of "getting it" and seeing new realms of possibility in front of you. Now all you can do is beg for more grease on your handle.
Nah. We’re literally on “hacker news”. Frankly a lot of the hacking ethos has always been cobbling stuff together building upon the works of others that you don’t really understand.
Learning by getting something to work and tweaking it is massively more effective than grinding against a wall of impassable errors while you’re just trying to get started. You don’t become a good programmer by reading a book.
Maybe it that's an apt analogy in more ways than one, given the recent research out of MIT on AI's impact on the brain, and previous findings about GPS use deteriorating navigation skills:
> The narrative synthesis presented negative associations between GPS use and performance in environmental knowledge and self-reported sense of direction measures and a positive association with wayfinding. When considering quantitative data, results revealed a negative effect of GPS use on environmental knowledge (r = −.18 [95% CI: −.28, −.08]) and sense of direction (r = −.25 [95% CI: −.39, −.12]) and a positive yet not significant effect on wayfinding (r = .07 [95% CI: −.28, .41]).
I would say I get more (I've been coding 40+ years). I get pretty good results, I find a lot has to do with crafting your prompts well. I think knowing what the outcome should be, technically, makes a big difference. It's getting less and less where I have to argue with the AI / do it myself. Not to mention the amount of little productivity / quality of life scripts I get it to create. They really smooth out a lot of things. I feel like its more heading towards "solution engineering" rather than coding where I'm getting a lot more time to think about the solution and play with different ideas.
My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
But if I give it a code example that was written by humans and ask it to explain the code, it gives pretty good explanations.
It's also good for questions like "I'm trying to accomplish complicated task XYZ that I've never done before, what should I do?", and it will give code samples that get me on the right path.
Or it'll help me debug my code and point out things I've missed.
It's like a pair programmer that's good for bouncing ideas, but I wouldn't trust it to write code unsupervised.
> My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
> […]
> Or it'll help me debug my code and point out things I've missed.
I made both of these statements myself and later wondered why I had never connected them.
In the beginning, I used AI a lot to help me debug my own code, mostly through ChatGPT.
Later, I started using an AI agent that generated code, but it often didn’t work perfectly. I spent a lot of time trying to steer the AI to improve the output. Sometimes it worked, but other times it was just frustrating and felt like a waste of time.
At some point, I combined these two approaches: I cleared the context, told the AI that there was some code that wasn’t working as expected, and asked it to perform a root cause analysis, starting by trying to reproduce the issue. I was very surprised by how much better the agent became at finding and eventually fixing problems when I framed the task from this different perspective.
Now, I have commands in Claude Code for this and other due diligence tasks, and it’s been a long time since I last felt like I was wasting my time.
> Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
I know it'll be touted as rhetoric but I have seen an order of magnitude of difference in my ability to ship things. Thankfully I don't work for a large enterprise so I don't have a multi-million line codebase to contend with or anything like that. I also, thankfully, ship projects using languages and libs that are very well represented in LLM corpuses, like TypeScript, NextJS, Postgres, though I have also found a lot of success in less popular things like Neo4j's Cypher.
I also have been massively enabled to do lots more 'ops' stuff. Being a pretty average full-stack eng means I have no experience of running sys/ops monitoring systems but LLMs only recently helped me with a bunch of docker-routing issues I was having, teaching me about Traefik, which I'd never heard of before.
Side-point: I have felt so grateful to these LLMs for freeing up a bunch of my brain space, enabling me to think more laterally and not relying so much on my working memory, severely limited now due to historic brain injury. Often people forget how massively enabling these tools can be for disabled people.
I can definitely see the 10% boost being accurate. Keep in mind, its not about doing everything 10% faster, its about being able to put out 10% more results by leveraging agentic coding when it makes sense.
This week I was able to tackle two long-standing bug fixes I've been noodling on and had a rough idea of what I needed to do but had competing priorities and a lack of time to sit down and really internalize the system to figure them out. I brain dumped the issue and my current thoughts and had claude formulate a plan. It solved each in less than 30 minutes of very light effort on my part. I was able to tack these onto larger work I'm doing basically seamlessly.
The other thing that I've found to be an insane benefit is filesystem-backed context switching. If your agentic workflow involves dumping your plan and progress to files in the filesystem, you can pause and restart work at any time by pointing at those files and saying "continue where you last left off". You can even take a `git diff > that-one-bug.patch` of edits made up to that point, copy that alongside the other files, and have a nice-and-neat folder of a unit of work that is ready to pick back up in the future as time permits.
Yes, most days I’m 2x as productive. I’m using Claude Code to produce extremely high quality code that closely follows my coding standards and the architecture of my app.
I don’t think people are good at self-reporting the “boost” it gives them.
We need more empirical evidence. And historically we’re really bad at running such studies and they’re usually incredibly expensive. And the people with the money aren’t interested in engineering. They generally have other motives for allowing FUD and hype about productivity to spread.
Personally I don’t see these tools going much further than where they are now. They choke on anything that isn’t a greenfield project and consistently produce unwanted results. I don’t know what magic incantations and combinations of agents people have got set up but if that’s what they call “engineering,” these days I’m not sure that word has any meaning anymore.
Maybe these tools will get there one day but don’t go holding your breath.
> They choke on anything that isn’t a greenfield project and consistently produce unwanted results.
That was true 8 months ago. It's not true today, because of the one-two punch of modern longer-context "reasoning" models (Claude 4+, GPT-5+) and terminal-based coding agents (Claude Code, Codex CLI).
Setting those loose an an existing large project is a very different experience from previous LLM tools.
I've watched Claude Code use grep to find potential candidates for a change I want to make, then read the related code, follow back the chain of function calls, track down the relevant tests, make a quick detour to fetch the source code of a dependency directly from GitHub (by guessing the URL to the raw file) in order to confirm a detail, make the change, test the change with an ad-hoc "python -c ..." script, add a new automated test, run the tests and declare victory.
That's a different class entirely from what GPT-4o was able to do.
I think the thing people have to understand is how fast the value proposition is changing. There is a lot of conversation about "plateauing" model performance, but the actual experience from the combination of the model and tooling changes is night and day in the last 3 months. It was beginning to be very useful with Claude 3.7 in the spring this year, but we have just gone through a step function change.
I was decomissioning some code and I made the mistake of asking for an "exhaustive" analysis of the areas I needed to remove. Sonnet 4.5 took 30 minutes looking around and compiling a detailed report on exactly what needed to be removed from this very very brownfield project and after I reviewed the report, it one shot the decommisioning of the code (in this case I was using CLaude in the Cursor tooling at work). It was overkill, but impressive how well it mapped all the ramifications in the code base by greping around.
Indeed, Codex CLI is quite useful even for demanding tasks. The current problem is that it might gather context for 20 minutes before doing the actual thing. The question is whether this will be sped up significantly.
I guess we just have to take your word for this, which is somewhat odd considering most of your comments link back to some artifact of yours. Are you paid by any of these companies?
I'm not paid by any of them, but I occasionally get preview access to models or invites to events. I attended OpenAI's DevDay on Monday for free, for example.
OP is one of the co-creators of Django (for which I am eternally grateful, having built my first company on top of it) and one of the most prolific writers in the space. I also happen to strongly agree with his assessment, though as he said getting that amount of value out of current tools is real work.
It is real work, and it requires solid priors to do it. The cynical people punch three prompts in, are disappointed that it doesn't work in their codebase they've worked in for 2 decades and complain that everyone is a shill and that people should stop saying they "hold it wrong".
The skill ceiling is high, it turns out. It's just deceptive, because it's so easy to get going. Ultra accessible foot gun, lots of work to point it in the right direction reliably and repeatedly. Significant benefits of you manage though.
I've gotten more relaxed about it now though. People will either get it or they don't.
That the tools do this kind of thing? They do, they’ll go through pretty long multi step processes to find things and edit them. They run tests, check output, see it’s wrong and go and add debug statements, rerun, try and fix things, rerun, then remove the logging.
All I've found is the LLM just makes me work more. It's hard to talk about % boost when you're just simply working more hours.
It's like having a faster car with a bigger engine. Big deal. I want a faster car with a smaller engine. My ideal is to actually go home and stop working at the end of the day.
I also don't want to use it for my day job because I'm afraid my brain will atrophy. You don't really need to think when something is already done for you. I don't want to become someone who can only join together LLM output. I don't feel like I'll miss out on anything by not jumping on now, but I do feel like I'll lose something.
At this point I'd say that I'm 1000% more productive in the aspects that I use it for. I rarely hit any walls, and if I do its absolutely always down to an unclear or incomplete thought progress or lack of clarity in prompting.
There's a lot of annoying stuff it can do fairly well without many guardrails. It's a minor productivity boost but it's nice not to have to do.
Doc comments for example. Today I had it generate doc comments for a class I wrote. I had to go and fix every single one of them because it did some dumb shit, but it out all the scaffolding in place and got the basics there so it was a lot quicker.
I also used it to generate json schemas from Python a couple of Python classes the other day. Highly structured inputs, highly structured output, so there wasn't much for it to fuck up. Took care of the annoying busy work I didn't want to do (not that schemas are busy work, but this particular case was).
Still haven't seen a use case that justifies the massive cost, or all the blatant theft and copy right infringement, or the damage to the environment...
My issue with this term is that it muddies the waters for people who are using LLMs to assist with types of engineering beyond just writing code.
I've used GPT to rapidly get up to speed with just about every aspect of circuit design, CAD, CNC... the list is long. Coding is often involved in most of these domains now, but if everything is assumed to be code-first, it leaves people who are doing different work with a constrained and apparently shrinking adjective namespace.
> My issue with this term is that it muddies the waters for people who are using LLMs to assist with types of engineering beyond just writing code.
I'm now imagining me dying as a vibe-engineered truck has a steering/brake failure and crashes into me sending flying through the vibe-engineered papier-mâché bridge guardrails, and feeling sweet sweet release as I plummet to my doom.
Look, if you enjoy calculating a table of dozens of resistor value combinations for a feedback network that prefers reels you have on your PnP, you keep knocking yourself out.
If you're using LLMs for a large number of arithmetic calculations, you're exactly the problem GP is talking about.
If you absolutely must use AI get it to generate code that will perform the calculations instead, so that you can actually verify the result.
You're straining very hard to make your position sound reasonable, but your assumption that I both can't verify the values of the winning combination and wouldn't verify those values is simply not true.
In the example I cited, verifying a ratio isn't the hard part. It's running the dozens of permutations (smart) or hundreds of permutations (naive) that an LLM can do in 90 seconds that saves me hours of boring work. It's actually so repetitive that I'm likely to have made the same kind of mistakes you're alluding to.
As always, I end with encouragement: if you want to do everything the long and hard way, I'm not here to change your mind. You will have to stop being upset that others are moving much faster than you, though. It's a choice.
I did a several-month experiment using Claude as the only engineer on a real SaaS side project (Node.js/React, prod-quality, full feature ownership). My observations:
The quality of Claude’s output strongly correlates with how explicit and detailed the specs are. Markdown checklists, acceptance criteria, and clear task structure led to far fewer corrections and surprises.
Most mistakes were never “creative hallucinations” — just missed context or ambiguity in my own instructions.
The whole process felt less like delegation and more like tight collaboration. There’s less of a “flow state” and more context-switching to review/test, but review fatigue is manageable if you iterate on your instructions after each lesson.
No real learning from prior sessions, but persistent design docs and corrected example snippets in the prompts made a big difference.
Overall, a lot of the “vibe” factor gets smoothed out by rigorous process — not unlike mentoring a junior dev on a new domain.
For me, the speedup was very visible on well-scoped backend tasks and trivial CRUD/UI, and less so on broader, ambiguous work (designing APIs, coordinating many moving parts). The biggest upside: a clear process made both me and the tool better; the biggest “cost”: I spent a lot more time up front thinking through specs.
Not sure it fully scales (and I’m skeptical on agent “fleets”), but for a solo dev, given patience and a bit of PM discipline, it’s a net positive.
> I spent a lot more time up front thinking through specs.
Presumably you didn’t work like this before but now you are? Have you tried simply doing this when manually coding? It’s possible you’re getting a speed up from embracing good practices.
All these coding agent workflows really drive home how important a solid test suite is but who’s actually writing the tests? In my case Claude Code keeps missing key scenarios and I’ve had to point out every gap myself.
Also reviewing LLM generated code is way more mentally draining and that’s with just one agent. I can’t imagine trying to review code from multiple agents working in parallel.
Finally I’ve shipped a bunch of features to prod with Claude writing all the code. Productivity definitely went up, but my understanding of the codebase dropped fast. Three months in I’m actually struggling to write good prompts or give accurate estimates because my grasp of the code hasn’t really grown (code reviews only help so much).
Curious if anyone else has run into the same thing?
I don't think the issue is with the "code" part, but more with the "vibe" part. The "vibe" part indicates that's more of a "let's just see what happens" kind of approach, which I don't think is true for people using AI generated coding in their professional coding jobs, who very much know what they want to get out of AI coding tools, how to ask for it, and how to assess the quality of the outcome.
Maybe something like "intent-driven development" or "AI-paired software development" might fit better?
The more accurate phrase would be "tool" or "machine-assisted development".
We don't need new terminology to describe something that has always existed because the tools we use have (arguably) improved.
"Vibe coding" is also a misnomer. People who engage in that activity are not "coding". They're using a tool to generate software until they're satisfied with the result. That has also been possible with low-code, no-code, website builders, and other tools. The more accurate term for that would be "machine-driven development".
I get what you're saying. Although I agree that it falls into the same category as "machine-assisted development", it's significantly different from other ways of coding that I would say it deserves its own name.
AI-assisted coding is an absolute game changer, for me, but I would think for everyone who can wield it well. I feel I can direct a (sort-of) small army of junior coders, architects, qa- and req engineers, etc., way different than with e.g. CASE-tooling. It requires creativity, and lots of knowledge & experience in the whole software-development life-cycle to get it well, and it can adapt to any flow you like. That's really new and unique, and way more flexible than the rigid CASE-tooling that was already out there.
"Tool" seems to broad: "What are you doing?" "I'm tooling." :)
Am not highly opinionated on if "code" should be in there. The AI tools do generate code, where some low-code platforms and the likes might not. I guess "development" works as well, although "vibe developing" doesn't really have the same ring to it :)
I do like to be able to differentiate between people generating code but don't care what happens under the hood, and software-professionals that incorporate AI assisted development into their daily work on any level.
100% agree. I really think it's time we move on from vibecoding, the tools have evolved and we should have a term that attaches more quality to the function
Just added this note to the end, as part of my justification for picking such an obviously stupid term for this:
> I’ve tried in the past to get terms like AI-assisted programming to stick, with approximately zero success. May as well try rubbing some vibes on it and see what happens.
Seems like most of the benefit of "vibe engineering" in your description comes from using straightforward best practices of software engineering. How much does the AI add if you already have solid procedures in place for everything else the AI needs not to go bonkers?
The AI adds a ton. It really is like having a whole team of extra coders available, all of which can type faster than you.
Getting good results out of that team is hard, because the bottleneck is how quickly you can review their workflow and point them in new directions.
Understanding techniques like TDD, CI, linting, specification writing, research spikes etc turns out to be key to unlocking that potential. That's why experienced software engineers have such a big advantage, if they choose to use it.
I've yet to get any quality code out of one, though I don't try particularly hard either. I'd rather spend my time actually coding, especially since all the positive stories about enhanced productivity are anecdotes, and the hard data remains far less supportive of the claim.
While I don’t agree with you, I keep a healthily skeptical outlook and am trying to understand this too - what is the hard data? I saw a study a while ago about drops in productivity when devs of OSS repos were AI assisted, but sample size was far too low and repos were quite large. Are you referring to other studies or data supporting this? Thanks!
I, individually, am certainly much more productive in my side projects when using AI assistance (mostly Claude and ChatGPT). I attribute this to two main factors:
First, and most important, I have actually started a number of projects that have only lived in my head historically. Instead of getting weighed down in “ugh I don’t want to write a PDF parser to ingest that data” or whatever, my attitude has become “well, why not see if an AI assistant can do this?” Getting that sort of initial momentum for a project is huge.
Secondly, AI assistants have helped me stretch outside of my comfort zone. I don’t know SwiftUI, but it’s easy enough to ask an AI assistant to put things together and see what happens.
Both these cases refer almost necessarily to domains I’m not an expert in. And I think that’s a bigger factor in side projects than in day jobs, since in your day job, it’s more expected that you are working in an area of expertise.
Perhaps an exception is when your day job is at a startup, where everyone ends up getting stretched into domains they aren’t experts in.
Anyways, my story is, of course, just another anecdote. But I do think the step function of “would never have started without AI assistance” is a really important part of the equation.
1. Learning curve: Just like any skill there is a learning curve on how to get high quality output from an LLM.
2. The change in capabilities since recent papers were authored. I started intensively using the agentic coding tools in May. I had dabbled with them before that, but the Claude 3.7 release really changed the value proposition. Since May with the various Claude 4, 4.1 and 4.5 (and GPT-5) the utility of the agentic tools has exploded. You basically have to discard any utility measure before that inflection point, it just isn't super informative.
I’d say what you’re doing is architecting, like the old term for “software architect”. Those are professional who know how to design a system from a high level and have the experience to judge a good implementation of it but they themselves do not write the code.
Likewise real world architects have the skills to design a building but do not care or know how to build it, relying on engineers for that.
I think it’s important to distinguish because we’re increasingly seeing a trend towards final product over production, meaning these “vibe” people want the tool in the end and consider the steps in between to be just busywork and AI can do for them.
That’s closer to product design than to engineering. If I can imagine Monalisa and write that thought to paper, communicating that thought and getting a painter to paint it for me does not make me Da Vinci.
If you had developed novel techniques of sfumato and chiaroscuro, spun new theories of perspective and human anatomy, invented new pigments, and then explained all of that to a journeyman painter, with enough coaching, detail, and oversight to ensure the final product was what you envisioned, I would argue that 100% makes you Da Vinci.
Da Vinci himself likely had dozens of nameless assistants laboring in his studio on new experiments with light and color, new chemistry, etc. Da Vinci was Da Vinci because of his vision and genius, not because of his dexterity with his hands.
Hmmm, I think it’s a bit paradoxical to try to come up with a fun term to encourage the spread of the concept, as the concept itself is quite dull by definition. It’s just software engineering. Boring process stuff where you do a bunch of other things around the ‘building’ part that lets you scale up with quality. Vibe is about fun and go-with-the-flow. This isn’t that. It should connote pocket protectors, not sunglasses. Right?
Clearly I’m not in marketing.
Regardless, I’m delighted that this has gotten people to ‘independently discover’ software engineering best practices on their own.
>> How much does the AI add if you already have solid procedures in place for everything else the AI needs not to go bonkers?
> The AI adds a ton. It really is like having a whole team of extra coders available, all of which can type faster than you.
Funny thing is, the least time consuming aspect of making programs is encoding solutions in source form. For example, a reasonable typist can produce thousands of text lines per workday if they know what must be typed (such as transcribing documents).
What takes longest when producing programmatic solutions is understanding what must be typed in the first place. After that, the rest is just an exercise in typing and picking good file/type/variable names.
I really wish I could like this term, because I agree the world needs a pithy, memorable one for what you're describing. But alas, I don't think this is it, either.
Question, why is it seemingly so super important for you to coin a term for this?
Especially a term which comes across as so demeaning and devaluing to engineers (like me and yourself!)
I absolutely do not want my non-engineer friends and colleagues think I am "vibe engineering", it sounds trivial and dumbs down the discipline.
I personally believe being an engineer of some kind requires work, learning, patience, discipline, and we should be proud of being engineers. There's no way in hell I would go around and saying I'm a "vibe engineer" now. It would be like going around and saying I'm a vibe architect! Who would want to live in a skyscraper designed by a "vibe architect" ??
I don't think you should call yourself a "vibe engineer" because you use AI tooling, just like I don't think you should call yourself a "continuous integration engineer" if part of your job role occasionally involves configuring GitHub Actions.
But the act of working on GitHub Actions could be referred to as "continuous integration engineering", just like the act of figuring out how best to build software engineering processes around LLM tools could be called "vibe engineering".
As always, Simon knows what he is talking about and neatly describes the whole situation.
However, it's not the "coding" part of "vibe coding" that is the (semantic) problem, it's the "vibe" part.
Replacing "coding" with engineering, but keeping the "vibe" part, still conveys the meaning of not really knowing what you do, but now in an even larger surface area.
It's a lot more boring, but I'm fine with "AI-assisted software engineering" as the other-end-of-the-spectrum name opposite of "vibe coding".
Just want to say that as an AI engineer, you and the Latent Space folks are doing work that is extremely useful to me. Without y'all, I'd be forced to doom scroll on X to catch up on the latest developments.
I wanted to explicitly highlight the utility of what you do because of surrounding comments that suggest/imply otherwise.
You are seeing someone asking for a completely voluntary subscription fee for very valuable (I find it at least) work that they give away completely for free—not to mention all the OSS software he has created—and yet you are construing that as being somehow greedy or money grubbing or sleazy.
Funny I'm a professional engineer and happily call myself "vibe coding" when writing code these days, it started as tongue in cheek, but now I've embraced it.
Being good at vibe coding is just being good at coding, the best practices still apply. I don't feel we need another term for it. It'll just be how almost everyone writes code in the future. Just like using an IDE.
If you’re looking at the AI-generated output then you’re not Vibe Coding. Period. Let’s not dilute and destroy the term just as it’s beginning to become a useful label.
People of course often do read (and even modify) the model-generated code, but doing so is specifically not “vibe coding” according to the original definition, which was not meant to encompass “any programming with an LLM” but something much more specific: https://simonwillison.net/2025/Mar/19/vibe-coding/
The whole point of the term is to convey that you are only looking at the output and not looking under the hood. If vibe coding a UI, you only look at the UI, not the CSS.
> The developer does not review or edit the code, but solely uses tools and execution results to evaluate it and asks the LLM for improvements. Unlike traditional AI-assisted coding or pair programming, the human developer avoids examination of the code, accepts AI-suggested completions without human review, and focuses more on iterative experimentation than code correctness or structure.
likewise, for a lot of frontend I "vibe code" it. I mostly don't look at the code anymore while doing it either, after I get where I want, I will look through the code and maybe clean stuff up. But a lot of the code is fine. Works really well I find. (using Augment Code with Claude Sonnet 4.5).
Is "vibe engineering" a correct term for this? It's not vibe based when you scaffold constraints around the agent: automated testing, planning in advance, comprehensive documentation, automated formatting and linting, and manual QA.
Don't get me wrong, I started vibe coding after reading Karpathy's post. I got the memo - don't review every line of code, don't stop it when it stumbles, let it recover on its own, trust the process.
But after some experience I realised I need to Constrain the model, it is like a karting track, those tires put around it keep the carts inside and safe. It's our job to set the constraints. So maybe it's "constrained agent work" not "vibe coding".
I go as far as saying the constraint harness around the agent is the new code, we can remove the code and regen it from the constraint harness and docs. What matters now is to build tests and constraints around AI work.
Anything with the word “vibe” in it sounds silly and unserious imho. What’s wrong with something neutral and descriptive like “LLM-assisted programming”? Not catchy enough?
This name makes no sense. "Vibe" means you're just vibing, just taking in vague impressions, just YOLOing, hoping it works out and just chilling and providing little input and effort. It's part pejorative and part ironic self-deprecation. "Vibe X" now means doing X by just giving vague instructions to the computer, not checking the output much and hoping it works out and it kinda does in part, at least enough times that it feels like it's a fine way to do stuff you just want to get over with anyway.
Vibe engineering would mean giving access to Google Computer Use API to your engineering design software and letting it design the industrial component you're working on, without even looking at what it does and just telling it to "fix it" if it seems bump into problems.
What’s the point of this kind of division? Should developers who use JetBrains instead of Vim be called something different too? Or if one person uses Google and another relies on a book, are they somehow different kinds of engineers? What are we actually trying to achieve with this distinction?
Vibe coder is not engineer because the person doing it doesn’t really interact with the code. But the tools a professional engineer uses for assistance shouldn’t matter at all, should they?
The distinction is specifically because its not about the tooling differences, its about the mindset and workflow. "Vibe coding" is a dirty word. It comes with an assumption of YOLO'ing until something maybe kind of works. "Vibe engineering " is the complete opposite side of the spectrum - high-touch, high-engagement management of the AI agents, often with a specific plan or design in mind that you are working toward. I agree we need a different word for it but I dont like "vibe engineering".
We've already 90% killed the word "engineer" by applying the title to someone who completes a 6 week bootcamp; this should pretty much finish it off. I don't see much engineering in the list of benefits; mostly seem like administration, and it's even referenced so why not call it "vibe management"? AI seems far closer to replacing mid-senior managers than it does developers.
The recent jokes about “everyone is an engineer” now just feels unprovable, where as before it felt like you could still counter that argument by asking to see someone’s code.
Now everyone has examples of code they’ve “written”, but nobody can explain what it does. Unless of course, their readme.md was also completely generated.
I agree with some of the people here that vibe engineering has completely deflated my long successful career as a SWE, and it’s pushed me mentally into non-tech roles to feel motivated.
Thank you for writing this, Simon. I'm using an anonymous account not tied to my main one, so if the mods want to delete it, go ahead, but I really need to rant. My company has been taking this same approach for the past two months. While the rest of the world is warning about the effects of vibe coding and AI-slop, we're fully embracing it, calling it "working smart" and "automate all things!"
It's utterly ridiculous. It feels like the PMs and higher-ups have no idea how much tech debt we're creating right now. For the past few weeks, going to work has felt like going back to school, everyone's showing off their "homework", and whoever has the coolest vibecoded instructions.md or pipeline gets promoted.
I'm slowly burning out, and I was one of the people who actually liked the technology behind all this.
I can totally relate, very similar situation here.
I am currently kind of an anti-AI black sheep in engineering department because I refuse to fully embrace the exponentials and give in to the vibes.
I avoid burnout by simply switching off my brain from all this noise about vibe coding - i have thought hard and long, i know the way this is being implemented is wrong, i know they will create problems for themselves down the road (they already have, the signs are already there), i will be here to dig them out when the time comes.
So far I don't see anyone shipping faster or better with AI than I can manually, so I'm good.
It's interesting to see the differences in industry adoption. My company just recently made Copilot an official tool for use. We're in a safety-oriented industry that moves more slowly. I do use it, but mostly just to tighten up existing code or get ideas for a refactor.
Meanwhile, I have a client project where my counterpart is definitely senior to me and excitedly shares how AI is helping them solve novel problems each week!
I hope this term doesn't catch on - the whole point of 'engineering' is basing decisions on experience and understanding. The whole point of 'vibe' is the opposite.
If this sort of term is adopted we are in 'literally not being literally' territory.
Fortunately, I imagine that engineering outside software already has people vibing physical infrastructure solutions and call that vibe engineering so I don't think it will stick.
Simon, I think this is a good distinction. Another possible term could be: “agent engineering management” or simply “agent managing.”
I am deep in this and one important way in which managing agents is different than managing people is that micro-managing can be your friend. With human engineering colleagues, you need to allow for a healthy degree of “that’s now how I would have written the code, but it’s a reasonable way to write it.” But if my agent writes the test file in the exact same way I do, I can both review and maintain the code more easily.
I have a bunch of short markdown doc files in which I give very specific instructions for how I like code organized: much stricter than I would ever do for a colleague. I’ll tell the agent, “now add tests to this model and follow @unit_tests.md” This file specifies exactly how I like tests named, what order I like them written in the file, etc. I have docs for: models.md, controllers.md, concerns.md, and fixtures.md.
I think it's a good idea to make the distinction. But I don't think 'vibe engineering' is the term I'd go for.
To me `vibe engineering` sounds like shoddily AI-designed suspension bridges. But then maybe I'm just an old fart programmer who thinks 'software engineering' is a term made up by programmers wanting to be as cool as bridge designers...
Power tools actually increase productivity. LLMs create the illusion of increased productivity and output unworkable messes while atrophying your skills, ergo they decrease productivity. Oh and unlike power tools, for all intents and purposes you can't own them.
That's only true if you don't put effort into figuring out how best to use them.
If using LLMs makes you slower or reduces the quality of your output, your professional obligation is to notice that and change how you use them.
If you can't figure out how to have them increase both the speed and the quality of your work, you should either drop them or try and figure out why they aren't working by talking to people who are getting better results.
GGP's sentiment resonates with me. I invest a fair bit of time into LLMs to keep up on how †hings are evolving and I do throw both small and large tasks at them. I'm seeing great results with some small task but with anything that is remotely close to actual engineering I just can't get satisfactory results.
My largest project is a year old, it's full-stack JavaScript, and I consciously use patterns, structures, and diligently add documentations right from the beginning for the code base to be as LLM friendly as possible.
I see great results on refactoring with limited scope, scaffolding test cases (I still choose to write my own tests but LLMs can also generate very good tests if I explicitly point to existing tests of highly related code, such as some repository methods), documenting functions, etc. but I'm just not seeing the kind of quality that people claim that LLMs can do for them on complex tasks.
I want to believe that LLMs are actually capable of doing what at least a good junior engineer can do but I'm not seeing that in my own experience. Whenever we point out these issues we are encountering, we just basically get the "git gud" response with no practical details on what we can actually dp to get the results that people claim to be getting. Then people start blaming our lack of structures, patterns, problems with our prompts, the language, our stack, etc. when we complain about the "git gud" response being too vague. Nobody claiming to be seeing great results seems to want to do a comprehensive write-up or, better still, a stream of their entire workflow to teach others how to do actual, good engineering with LLMs on real-world problems either -- they all just want to give high level details and assert success.
On top of that, the fact that none of the people I know in engineering working in both large organizations and respectable startups that are pushing AI are seeing that kind of results naturally makes me even more skeptical of claims of success. What I'm often hearing from them are mediocre engineers thinking that they are being productive but actually just offloading the work to their colleagues through review, and nobody seems to be seeing tangible returns from using AI in their workflow but people in C-suites are pushing AI anyway.
If just about anything can be "your fault", how can anyone claiming that LLMs are great for real engineering without showing evidence be so confident that what they're claiming but not showing is actually the case.
I feel like every time I comment on anything related to your blog posts I probably came across as belligerent and get down voted but I really don't intend to.
Engineering is in large parts about signing-off on something with you name on it, and being responsible if it fails or causes harm. Think bridges, tunnels or other infrastructure. I‘d argue that this is the same for computer engineering. That‘s why I think coining the term ”vibe engineering” can be dangerous.
”Vibe coding” is the better term and actually makes sense for what it describes.
Leave ”engineering” in terms of taking responsibility for what you ”engineer” strictly to human professionals. That’s what people pay for and that is what makes it valuable.
Someday we will realize that using the term vibe before coding is like someone saying that today when we use GCC we are "vibe compiling" because we didn't compile the code manually.
Once tooling becomes reliable and predictable enough, and the quality of the output consistent enough, using it is not a leap. Early compilers had skeptics, and GCC still has some bugs [1]
I really don't think we're doing the tools or the industry any favors/justice by prefixing new terms with `vibe`.
Looking at vibe coding: it suggests you're coding but you only vaguely know what's going on, so the work is the same (coding) but the outcome may or may not be what you want
Why dont we flip it around? We want a term that suggests that a fixed amount of work (coding) to be more efficient/leveraged.
So why dont we call it something like hypercoding, dense engineering, autocode, ...
This matches our experience developing with agents. In particular, as we wanted to use multiple agents in the background to do tasks, we had to really invest in different areas so they would not go in wild directions or have to ask continually for feedback, defeating the purpose of working in the background. First, we needed to provide relevant context on how to do the task (some of it is "generic" like Svelte documentation, some of it is specific to how to write tests for our particular project), be extremely detailed and specific in the prompt about what we want and how to go about it (divide it in different well defined steps) and finally provide with specific tools via MCP (like MySQL access and installing system packages). Once we consistently do all this work upfront, it really pays off because you can launch a large number of agents in parallel that don't interfere with each other (git worktrees, containerized environments) and don't require babysitting for the most part. We just open sourced the tooling we used internally for this: https://github.com/endorhq/rover
The problem with every single tool in the category that I've come across (e.g. Conductor, Sculptor) is that they assume a single repository. Very rarely in my career working on enterprise software have I been in a situation where all my work was constrained to a single repo. Usually a story or feature spans several repos (whether split between frontend/backend, or a repo-per-service). As an engineer in these situations I never work in isolation considering only one repo -- I work across all of them at once and then prep all the PRs together. I'm not saying this multi-repo approach is good, just that it is the state of the world right now in many cases.
So imo tools like this need to work at a level above a single repo. The agent needs to start by cloning all repos needed for the task, and go from there.
I've solved this in the past using versioned dependencies. Repos get tagged releases, other repos can specify which version they depend on, then the deployment script has to resolve those dependencies and install the right release versions of everything else.
You can also use GitHub submodules to implement a pattern like this, but I don't really trust them for some reason.
Thanks for your feedback! I faced this in the past. As you mentioned, monorepos are more common these days, but multi-repo is an established approach in many teams. The way I "solved" this situation was to move all the related projects into a single folder with a parent AGENTS.md file (CLAUDE.md, etc.). Then, I run Rover / Claude / Gemini on this folder.
However, this is not ideal. Due to the amount of code, it usually misses many things to do. We are currently exploring specific workflows for these use cases, trying to help agents to prepare a complete plan.
Another similar case we are working on is to support spawning the same task across different repositories. This would help teams to apply refactor or changes in different projects at the same time.
Since Sculptor allows you to use custom docker containers (devcontainers), you can check out the other projects in there.
Then your primary project (from Sculptor's perspective) is simply whatever contains the devcontainer / dockerfile that you want it to use (to pull in all of those repos)
It's still a little awkward though -- if you do this, be sure to set a custom system prompt explaining this setup to the underlying coding agent!
> "If you’re going to really exploit the capabilities of these new tools, you need to be operating at the top of your game. You’re not just responsible for writing the code—you’re researching approaches, deciding on high-level architecture, writing specifications, defining success criteria, designing agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely cheat if you give them a chance, and spending so much time on code review."
I know this paragraph is supposed to be encouraging, but it makes me wonder again what the actual goal of this entire AI enterprise is supposed to be.
"Less work" or "easier work" would make superficial sense, but in a society where people are in constant competition and derive both their self worth and their basis for living from work, both are effectively anti-goals. And so we get articles like this trying to offer comfort by saying that work will still be draining and challenging in the future.
So if not less work, then "more productivity", i.e. we can produce more software in a shorter amount of time (but with the same mental load). But as others have said, this was never the bottleneck.
There will be times when LLMs are not accessible or working as expected and we will honor real software developers who can still think on their own, create and solve problems.
Great post. I've thought about what I want for better Vibe Engineering:
Each agent needs to deliver a fully working App/URL/Build so the functionality can be tested & verified.
Today AI IDEs deliver the diff + an explanation. Excellent. But give me the
full build, a build I can share. A build that represents what it would be like shipped. When it comes to user facing functionality, a real build is how product owners verify a feature is complete.
Learn from Vercel -
A key part of Vercel’s magic is the automatic deployments for each branch. When working on a project with per branch vercel deployments - a team gets the immediate value of:
Shareable work - now others can see/test/give feedback on the great new feature you’ve developed - and their only work is to click a link (not git pull a branch and attempt to run locally)
No more “it works on my machine”. It either works or it doesn’t.
Confidence that if released, you know exactly what the user will experience.
Give me automatic deployments for each agent, for each PR.
And keep them available to spin up / re-use later.
I want to be able to re-launch it 3 months later and it just works. The reason we don’t do this today is the cost of the engineering - but with docker et al + AI agents, the cost of the eng work drops 99%
Deliver the deployment in such a way that immediate feedback to the AI could be given. This way minor tweaks can be executed immediately by the AI meaning that I can just wait for the minor tweak, review and then merge. This means the PR gets shipped NOW.
I think a key skill is knowing what level of complexity a single run can realistically achieve, which is often only a small task and not a fully working build.
Don't worry — if we all have access to the same tools, the playing field is level. What sets you apart are the human qualities. Employers and clients want to be at the top, same as before LLMs. The market is large, and there's room for everyone. Don't be afraid of someone without any/little engineering knowledge making something, they were already copy/pasting code from SO before LLMs.
I've been successfully "vibe engineering" with Claude Code for a week now on a side quest at my job. I want the result to be of high enough quality to maybe survive in our codebase long-term, but I don't want to write it myself.
So I've added unit tests, e2e tests, formatting checks to help Claude to self-correct as much as possible. And I make him do a TON of self-review, after each feature I say something like:
> You are a master reviewer, lots of practical experience. Read Clean Code. Great at architecture. Read Effective Typescript as well. What would you comment in a PR review? Type checking MUST PASS, unit tests must PASS, formatting must PASS.
With each review, Claude catches a lot of sub-optimal choices it made which gives me more confidence in the code I get in the end.
Do you really believe that if you miss the "Read Clean Code" or "Read Effective Typescript" part, then the output would be significantly different?
No offense, but I feel this kind of talking is ridiculous. If it is a better practice, then it should be done without explicitly telling so. You do not tell them "Do not get things wrong," right? If it is a matter of choice over design patterns, for example, use functional programming or object oriented programming paradigm, then it should be said more clearly as what I have done.
Now, if it is neither something that is definitely a better practice nor something you can state clearly with a known, well-defined word, how can you make sure what you have said really make a difference if you have not said it?
It works for me and I like the results I'm getting. The results often include callbacks to rules of thumb from the mentioned books - which I find easier to agree with or dismiss when I see the suggestions it made. In a way, it's a framework for me to "communicate" with the LLMs.
I think you should try finding what works for you, maybe even give my ridiculous prompt a go.
These people havent deployed anything to a production environment that requires reliability and support. For that, you need a real software engineer to take apart the mess of vibe coded kludge and create real software that can actually be given to people to use. I wouldnt worry about this. Vibe coding trend is already on its way out as people discover this.
So the only quasi disagreement I have is that "research" is one of the strengths of the models, and you should lean on them where possible.
In Claude Code for example I define a research sub-agent and let it do the majority of "research" type tasks. Especially when the research is tangential to what ever my objective is. Even if it is critical, I'll usually ask to have it do a first pass.
Feel like there's more to this point (plus the documentation). By now we've all see the inverted-U-shaped performance curve when coding with LLMs within a single thread / context: the model starts strong, plateaus as the context fills up, and eventually declines as semantic drift sets in.
Sometimes in this situation, it works better to throw away the current code and re-implement, using what's been learnt so far, than continue working with the current context of having new contexts try to salvage the current state of some code.
Documentation is great as a reflect of the current state of some code but I've had good experiences "re-constructing" the steps taken to arrive at a current implementation by writing commit messages that are intended for an LLM, extract that later, have an LLM use it as a basis for writing a fresh "spec" for some code, that yet another LLM uses to actually write that code.
I've been thinking about AI-assisted development for a while; I've tried out Claude's pro plan, Gemini Pro and many "top models" and I must say, this is going to create a chasm for junior/intermediate developers like myself, senior engineers reached to the point they are through deliberate practice-- interrogating code, making and breaking assertions, reading through the documentation or actually comprehending the code through the debugger or mental models. I don't "need" to do any of this. I can have an AI just spoon-feed me a large codebase in "ELI5" language, I can ask an AI about the best practices, I can have an AI look something up for me, synthesize it and wrap it up nicely for my mind to consume (equivalent to how hyper-processed junk food isn't good for our bodies either)
It's intellectual slop. It will get the job done (atleast for a while) but without the actual growth that comes along with it. When I use an AI to one-shot a "small one-off script" I don't learn anything from it (when as a relatively new developer I SHOULD be learning something from it) And this is unlike stack overflow or googling becuase you can turn off your mind, just become one of those drones from Wall-E.
I make a point to avoid using any AI for coding (even for looking things up) when working on personal projects, at the cost of "productivty" and "efficiency" , but I get to retain my humanity and soul in programming.
Sorry if this sounds cheesy, it's just I care deeply about code craftsmanship from my end, to see that skill be diminished to an random number generator? Yeah No.
To people reading the article: replace the word "agent" with "intern".
> Without tests? Your intern might claim something works without having actually tested it at all, plus any new change could break an unrelated feature without you realizing it. Test-first development is particularly effective with interns that can iterate in a loop.
As a CTO of a small company, spending a lot of time reviewing other developers' PRs, I completely agree. I recently enabled Github Copilot Agent and use it a lot for dealing with smaller and lower priority tasks in an async workflow (e.g. while I am doing other things). A lot of developers are not very good writers, and reviewing PRs from Copilot, with access to the full "thinking process" and being able to request changes in a few comments is sometimes more pleasant and effective
You and I met in AI Engineer in SF last June and we discussed for 1 hour (not about this specifically but about AI and all).
At the very least, it could be cool to mention it in your post or newsletter since, I do think this little convo on X + our talk in SF might have just planted the seed in your head for this "invention" of yours...
I don't want to stay in history books but I think it's cool to also credit people when you iterate on their idea instead of just make the thing entirely "yours"...
I think he should have given you credit, you were clearly first and he responded to your tweet so he must have seen it! But he might have just forgotten he had the conversation with you about this, while still being more likely to "rediscover" the term since he had heard it before. Maybe a bit aggressive to not reach out to him privately first but in any case pretty cool that you actually invented a term that is now quite likely to be popular :)
Seriously now, I think the whole industry suffers from too many buzzwords and whacky terminology.
*The job hasn't changed*. As mentioned, all those things from the past are still the most important thing (version control, being good at testing, knowing when to outsource, etc).
It's just coding (which is something that was never about typing characters, ever).
Willison has an impressive record for coining terms. But feel like he may have missed it here. In the context, 'engineering' doesn't feel that different to 'coding'. The sloppy sounding part is 'vibe' and that's not been removed.
It will certainly be the default for cases where it's easier to read code than to write code, but this is far from universally true. AFAIK, Joel Spolsky was the first to discuss this at length 25 years ago [0], but numerous people have echoed his sentiment [1, 2, 3, ...]
One of the most underrated skills in effectively using gen-AI for coding is knowing ahead of time whether it will take longer to carefully review the code it produces, versus writing it from scratch yourself.
I love programming, but it turns out I love building useful stuff even more than I love programming. Agentic coding helped me fall in love with development all over again. If a team of junior engineers suddenly showed up at my door and offered to perform any tasks I was willing to assign to them for the rest of my life, I'd love that too.
Agentic coding is just doing for development what cloud computing did for systems administration. Sure, I could spend all day building and configuring Linux boxes to deploy backend infrastructure on if the time and budget existed for me to do that, and I'd have fun doing it, but what's more fun for me is actually launching a product.
Sadly the times where people joined software engineering for passion are way behind. People nowadays join just for the money or because it has lot of jobs available.
It is very easy to notice at work who actually likes building software and wants to make the best product and who is there for the money, wants to move on, hard code something and get away with the minimal amount of work, usually because they don't care much. That kind of people love vibe coding.
I don't like the kind of programming that an LLM can easily accomplish.
For instance, I recently had to replace a hard-coded parameter with something specifiable on the command line, in an unfamiliar behemoth of a Java project. The hard-coded value was literally 20 function calls deep in a heavily dependency-injected stack, and the argument parser was of course bespoke.
Claude Code oneshotted this in about 30 seconds. It took me all of 5 minutes to read through its implementation and verify that it correctly called the custom argument parser and percolated its value down all 20 layers of the stack. The hour of my time I got back from having to parse through all those layers myself was spent on the sort of programming I love, the kind that LLMs are bad at: things like novel algorithm development, low-level optimizations, designing elegant and maintainable code architecture, etc.
wait you were unfamiliar with a behemoth Java project to the point of dreading making the change yourself, and yet only spent 5 minutes reviewing "someone else's" PR?
Yup. Replacing a single hard-coded parameter with a command line argument is hardly an earth shattering change. It's trivial to verify that the argument properly gets passed down the stack (and that passing it has no side-effects), but figuring out that stack in the first place would have taken a much longer time. Think of it like an NP-complete problem: hard to solve, but easy to check that a solution is correct.
For more complex modifications, I would have taken the time to better internalize the code architecture myself. But for a no-brainer case like this, an LLM oneshot is perfect.
Sorry if I haven't been clear: it's one variable, used exactly once at the very bottom of the call stack. The change only required adding a corresponding extra argument or class member to all of the functions/classes upstream. In fact, there were other variables in the caller of the bottom function that get passed down from the command line, a pattern that the LLM likely picked up on (and exactly what clued me in to the fact that the LLM would likely make this change very easily, a hunch that proved correct).
You raise a good point: an important skill in effectively using LLMs for coding is both being able to recognize ahead of time that cases like this are indeed simple, but also recognizing after the fact that the code is more complex than you initially realized and you can't easily internalize the (side) effects of what the LLM wrote, warranting a closer look.
That's actually a pretty reasonable description I think. I mean, in the semi-serious way. But I was just talking to some colleagues of mine about how one can get attached to or invested in code that they hand wrote, even though that code wasn't really solving a problem that was "worth" that level of attachment. And AI assisted code generation changes the dynamic for code that fits in that category for me, and it just so happens to be a lot of the code people write for work fit into that. You only really need to be "artisinal" about the code that "really matters".
Just wait until there are artisinal software shops in Brooklyn staffed by an even higher density of bros with signature mustaches and weird side hobbies.
I dunno, I feel lately like we are right at the tail end of the honeymoon era and about to enter the era where the blog topic du jour is “use LLMs, not too much, mostly on a short leash”.
Not much to base that on other than vibes, though :)
As much as I dislike the ecosystem around AI and don't enjoy using them as tools: this is the answer. We don't need a word for "doing the job properly with new tools".
I feel a certain way when I hear about older programmers who used to program using punch cards, I guess everyone in the future will think about us in the same way?
I feel a certain way when I work with older programmers who used to program using punch cards, and debug actual core dumps, i.e. the main memory of the computer printed out in hex. They have incredible attention to detail, and can reason about why their programs didn't do what they expected.
In some ways slower feedback loops might be useful. Having to think and reason if your code is correct and actually works because you only get output next day...
Instead of just vibing something out, pushing it to prod and seeing the problems. Or not even checking...
You don't "program" with punch cards any more than you "program" with text files. They were just the mechanism to get your code into the computer before hard drives and compilers existed.
Haha - cool that you made a throwaway insult account just for this.
I meant punch cards as a placeholder for programming in a bygone era, about how it feels so different, distant and detached, and that I don't relate to it.
I can see a plausible future where if we go down this route, what I call coding right now will feel the same.
It’s great to read in the comments about experiences of others with vibe coding. But I also feel like lots of opinions are not coming from actual experience, or “serious” attempts at vibe coding, and more from theoretical deliberations. I might be wrong.
Here are some of my own high-level experiences / thoughts:
- Perhaps contrary to popular belief I think vibe coding will bring the best software / system architects. This is due to massively shortened feedback loop between architectural idea and seeing it in action, easiness with which it can be changed, and the ability to discuss it at any moment.
- We’re not really coding anymore. This is a new role, not a role of a senior dev reviewing PRs of junior devs. Devs are just best suited (currently) to take on this new role. I came to realization that if you’re reviewing all generated code in detail you’re doing it wrong. You just shifted bottleneck by one step. You’re still coding. You should skim if the code is in line with your high-level expectation and then make LLM maintain an architecture doc and other docs that describe what and how you’re building (this is the info you should know in detail). You can do audits with another LLM whether the implementation is 100% reflecting the docs, you can chat with LLM about implementation at any moment if you ever need. But you should not know the implementation the way you know it today. The implementation became the implementation detail. The whole challenge is to let go of the old and embrace and search for efficiency in the new setup.
- Connected to the above: reading through LLM outputs is a massive fatigue. You are exhausted after the day, because you read hundreds of pages. This is a challenge to fight. You cannot unlock full potential here if you aim at reading and reviewing everything.
- Vibe coding makes you work on the problem level much more. I never liked the phrase “ideas are cheap”. And now finally I think the tides will turn, ideas are and will be king.
- Devil is in the detail, 100%. People with ability to see connections, distill key insights, communicate and articulate clearly, think clearly, are the ones to benefit.
We might just have to accept that it’s software engineering. Not vibe engineering, just engineering. Proper engineering has never shied away from using smart tools, it’s about ownership, accountability, planning, etc etc and you’re still doing all that. If you sign off properly on everything, it’s yours. It’s engineering, that’s it.
Smart tools have existed forever, or we’d all be coding in assembly still. As long as we take ownership of the code and the result that’s it.
I would add to the list of the vibe engineer’s tasks:
Knowing when the agent has failed and it’s time to roll back. After four or five turns of Claude confidently telling you the feature is done, but things are drifting further off course, it’s time to reset and try again.
I like the idea of finding an alternative name to "vibe coding" to describe this more substantive alternative. However, I personally think the name "vibe engineering" is too close to vibe coding and not sufficiently distinct.
I don't have a great alternative unfortunately. I've used "agentic coding" in the past as a means of differentiating from vibe coding, but I don't think that's necessarily clear enough either.
That said, maybe with defining this new approach it's just going to take time for any term to become familiar enough to be self-explanatory.
I took a look at youtube but I haven't seen any real examples of AI being used to ship anything significant (as in, other than toy apps which are available as templates already or copy pastable from tutorial websites).
"Vibe Technical Debt Creation" <-- either that or the AI's purpose is limited to sTimulation (getting us to think while it's spinning its wheels writing throwaway code.
It sounds like some people who are running multiple AI tasks in parallel might be risking burnout because they think they need to keep machines busy. But this is a symptom of systems that don’t run fast enough to be interactive.
If compiles take ten minutes then sure, you’re going to want to do something else while waiting. If they take two seconds, you stop caring about keeping the machine busy because it’s impossible. It’s perfectly normal for computers to be idle waiting on you most of the time.
What I’d really like to see is a company that completely does away with the code review step. Because if you think about it a code review is already being done by the invoker of the LLM. That way the velocity will actually be faster. It feels like at the moment most of the velocity is blocked by the outdated notion of code review.
It’s also why these tools feel great in green field projects, since these ones don’t typically have any code review in place (i.e. one dev going brrr)
We tried this as a bit of an experiment - not quite greenfield but a fork and modification of an existing project.
I was a solo dev going brrrr with no code review, using Cursor to make pretty sweeping changes and implement full features. I think because it was a fork I was able to go really fast because I could point the coding agent at existing patterns and say, "do this but different".
Occasionally I would test changes in staging but mostly would just promote them straight to production. I went on like that for ~3 months and the product ended up getting ~75k (daily!) users in that time with *no* outages or downtime (!!!)
It worked really well! Until I hit my scaling limit and we added more engineers to the team. A new hire on their second week on the job shipped a change that was also written with AI and caused a 7 hour outage before we realized something was wrong. I even *thoroughly reviewed the code* because I knew it was generated and I made a comment questioning the lines that caused the outage, but after we talked it over we decided it was fine and was only one tiny bit of a much larger change.
So I guess, AI will ship bugs but so will peer-reviewed code.
I realize this is likely being facetious, but just in case - code reviews are so much more than just 'check the syntax and style of the code'. They check the intention, check the actual functionality, find issues on the larger scale that LLMs literally can't.
Yes, PRs start piling up because devs can vibe code them faster than they can be competently reviewed. This is a problem with the vibe code process, not the code review process.
I was being half facetious, yes. But wouldn't the invoker of the LLM be already doing a review in that case? It just feels a bit redundant, to have engineer one do a code review of LLM's work, and then have engineer two do the same review.
The business cost with PRs isn't the first review but another developer, it's the number of iterations on a pull request due to defects and change requests. The way I am trying to promote the use of LLMs with more junior developers in my team (I am the CTO) is to use AI-assisted tools (we used Windsurf and recently switched to Github Copilot) for a first pass, e.g asking the agent for a review and catching potential defect before involving the human reviewer.
This doesn't mean the human reviewer will need to spend less time reviewing, but potentially this PR will be merged faster with on average a lower number of iterations and improved code quality.
I do have in my team some senior developers that are excellent, and it's very very rare I catch an issue in their PRs (maybe 1 out of 50). But I also have greener developers for who the ratio is way higher (like 8 or 9 out of 10) and this means repeated context switching for the reviewers.
Not just that but PRs are about a lot more than syntactical correctness, it's also about design. Just this week we've had two PR catch bad design choices that came from a fundamental misunderstanding of the problem space. Even if the AI wrote perfect code the first time everytime it wouldn't matter in those cases.
I put a lot of thought in to my prompts. I can code, definitely not as good as the AI or people here on HN; it's something I always enjoyed doing to tinker with things.
The AI agent in Cursor with Gemini (I'm semi-new to all of this) is legit.
I can try things out and see for myself and get new ideas for things. Mostly I just ask it to do things, it does it; for specific things I just highlight it in the editor and say "Do it this way instead" or "for every entry in the loop, add to variable global_var only if the string matches ./cfg/strings.json" I _KNOW_ I can code that.
FWIW, from the perspective of a non-coder: the tone of the comments in the discussion here is markedly different from those on similar topics six months ago and earlier in that there is no rage and contempt for LLM/vibe coding any more, but rather a reasoned discussion.
Your second point “planning in advance” could be referred to as spec-driven development… it’s a funny term in a sense (didn’t we always do that?), but I think your 7th point drives it home “a very weird form of management” - clear instructions, necessary context, and actionable feedback.
As far as written words go, much more like waterfall than agile.
It already is. I saw a demo of someone spending $30 an hour on Cline to do something that would be achieved better, for free, and faster, with a framework.
That's more than $5,000 a month assuming 40 hours a week.
This feels like an attempt to sell vibe coding to skeptics. I don't feel there's a need to. People find their own workflows how to use AI. Some people go all in, some use it here and there, some use it to write tests, etc. I feel annoyed enough having the AI topic discussed and reviewed everywhere every day, I don't need more of this.
The corollary to that is that keeping a shitty legacy codebase will keep you employed longer, since AI won't find its way through it, and screw everything up every time it touches anything.
This is making me like the written-by-math-grad-school-interns python mess I inhereted!
I find using “Vibe” makes it sound less valuable. It also needs to fit the next frontier which is “refactoring” and tuning the codebase to work with agents to make it easier to change existing code. A suggestion to use “augmented” was great
Heroku and Vercel and Render all have features that can do this. You can wire up your own for other hosting providers using a lot of scripting on top of GitHub Actions.
Vibe is just a bad word to describe anything that requires skill beyond "taste". A word play off of "AI assisted programming" is probably going to be the term that sticks. AIssisted? pAIr programming...
Seeing all the experienced engineers on this thread who feel discouraged is really depressing.
Not because I disagree with you, I don't! It's because I fear a gradual brain drain of people who actually love their craft and know how to build things properly. I fear we'll end up with worse software thats simply 'good enough', built a atop a pile of AI slop.
If it's cheaper but with acceptably worse results, I fear this is good enough for a lot of companies.
Slapping 'engineering' on something to try and trade on the good name of real engineers is the express lane to losing all of your credibility. Guess I should get ahead of the curve and update my title to Slop Surgeon.
No one should be allowed to use "engineering" in the context of producing something with LLMs until they learn to say "No, I'll not help you cut corners on this, and if you persist I will report you".
If you're fine with an AI designed bridge, where the builder tweaked the prompt to get the LLM to suggest cutting out all safety features, then okay, go with vibe engineering.
I've been all-in on vibe engineering for 4 months now and it is overall amazing. Simon missed a few key rules and practices that I follow, but every one of the points he hit is spot on. I also know for a fact the work I do has influenced some of his recent writing. Sorry to be a braggy jerk but I'm pretty proud of this! <3
The part about past management experience being a key skill surprised me but now it makes sense.
I really do usually have 3 different projects in flight for at least 6 hours a day. I'd write a blog post but I keep expecting someone else will write the essential same post tomorrow. :)
p.s. The first 2 months was exhausting but now it's slightly less exhausting. Make no mistake, it is an extreme transition to make.
I wonder if we are more like accountants at the advent of spreadsheets, who have thrived and just changed tools, or farriers at the advent of automobiles?
I feel using the word 'vibe' is inherently giving it a negative connotation which goes against the idea presented here.
The reality is the tools are really useful when used as tools, like a power drill vs. a screw driver.
Vibing implies backseat driving which isn't what using the tools proficiently is like. The better term would be 'assisted' or 'offloaded'.
Same thing with the term 'engineering'. That's a fairly new term that implies being engineers which we are not. We haven't studied to be engineers, nor have real engineering degrees. We've called ourselves that because we were doing much more than the original job of programmer and felt like we deserved a raise.
'LLM extended programming' is not as catchy but more relevant to what I observe people doing. It's valuable, it saves time and allows us to learn quicker, very powerful if used properly. Calling it 'vibe engineering' is a risky proposition as it may just make people's eyes roll and restrict us to a lesser understanding.
> That's a fairly new term that implies being engineers which we are not. We haven't studied to be engineers, nor have real engineering degrees. We've called ourselves that because we were doing much more than the original job of programmer and felt like we deserved a raise.
Uh, speak for yourself. There are countries where being a software engineer does indeed imply that you studied engineering and hold a "real" engineering degree.
Also, Hillel Wayne's "Are We Really Engineers" is worth reading:
I agree with both of you. Some coding is part of a real engineering process. That's why I don't like using "engineering" to refer to coding broadly - because it loses that specificity and connotation.
As "coders" or "programmers", some of us should answer the question "are you an engineer?" with a proud "of course not!" (That's me.) And some of us should answer, equally proudly, "of course I am!"
I could never take anything seriously with the word "vibe" prefixed. "Engineering" is something hard, vigorous, fully dedicated, and commanding respect. It's just a stark contrast to "vibing something out of thin air"
I get the impetus behind the term and I think it's a good article with a lot of practical advice overall, however I am disheartened by the terminology on two fronts:
1. It is confusing in the sense that all other engineering disciplines have the form "<X> engineering" where X is the object being engineered. This makes it sound like we are engineering vibes, not software.
2. Software engineering was already only marginally worthy of the term "engineering". There is a strong subset of computational system building that I think actually meets the standard of engineering (rigorously understanding requirements and system bounds, probably showing that the system achieves stability within those bounds). This just makes that situation worse. The devil is in the details, and over-reliance on llms ultimately makes those details a black box to the designer. Before you claim it's the same as when a designer relies on a suite of humans—no. The designer can ask those humans for reverentially transparent proofs that certain conditions are upheld, there is a social accountability structure, etc etc all of which does not exist with LLMs even if they get good enough that we can just trust them.
If we are going to keep calling software construction engineering, can we please at least get industry wide standards around ethics before we go off vibing? There's so much that we still sorely need in order to really make this discipline rigorous and socially accountable in the first place.
To add as a data point: I've met founders that are business founders and are vibe coding entire businesses with React, Supabase and Netlify.
LLMs allow for amazingly high fidelity interaction designs to receive funding and prove out certain PoCs. Whether his stuff will stay up in production remains to be seen.
I predict that people will end up using the term "vibe engineering" to refer to development processes that involve asking an LLM to build their entire app: UI design, database schema, architecture, devops, QA, debugging, etc, without any of the careful effort to understand and be able to proudly own the resulting code that Simon is imagining.
And I think that is actually the most natural meaning for "vibe engineering", actually: Parallel to "vibe coding" where you serially prompt the AI to write the code for you, "vibe engineering" should be serially prompting the AI to do the entire engineering process for you.
I also predict that a precisely defined term for what Simon is describing will inevitably end up being primarily used by people who are actually doing "vibe engineering". Being disciplined and careful is hard.
People and organizations love to claim/pretend they're doing expensive, mostly invisible work like "building secure software". Given nearly every organization claims they use security best practices no matter what their actual practices, I imagine it will be that way with "actually reading and verifying what the LLM generated for me".
Certainly I've been disappointed how often someone presents something they've "written" in recent months that turns out, on inspection, to be AI slop that the "author" hasn't even read every sentence of carefully.
Frankly the most accurate way I would describe what I do with AI is managed programming, or being a handler for the AI.
The only issue with "Handled Programming" is I don't like how it fits for a name.
Vibe is much too unserious to pass my check for a way of professionally doing something and it also does not reflect the level of engagement I have with the AI and code since I'm putting together specs and otherwise deeply engaging with the model to produce the output I want.
Thank you Simon! Too many people conflate non-engineer vibe coding with engineers using ai to make themselves much more productive. We need different terms!
I find coding agents to be a powerful throttle on the speed dimension in exchange of quality in the general sense. With tests to ensure correctness is not compromised (not a silver bullet), linter and pre-commit for code style, the byproduct of AI code is utter verbosity. Pleads to be concise don't work – no more than the "Don't be wrong/hallucinate". In that regard, I like Blaise Pascal quote "I have made this longer than usual because I have not had time to make it shorter."
I think this is a pointless distinction tbh. Either you're getting good results from AI or you're not. If you're not, you should probably rethink your approach.
I'd offer a new term: curmudgeon coding. This pre-dates LLMs and is the act of engineers endlessly clutching pearls over new technology and its branding. It's a reflexive reaction to marketing hype mixed with a conservative by default attitude. Think hating on "NoSQL". Validity of said hate aside, it's definitely "a type" of developer who habitually engages in whinging.
I call it "coding". Nobody has ever cared what IDE I use, what documentation, which syntax autocompleter. I don't see why they should suddenly start to care about my tools when they're LLMs.
Vibe coding is different because it's the "dictated but not read" of coding. Yes, I was around when the LLM was writing the code, and I vaguely instructed it on what to write, but I make no assurances on the quality of the output.
Please no. We already have a bunch of (human society) semantic slop from vibe coding term being misused. The last thing we need right now is another poorly developed term
> One of the lesser spoken truths of working productively with LLMs as a software engineer on non-toy-projects is that it’s difficult.
I mean, the AI companies have an incentive to make it easier, right? The next iteration of coding agents will be better at working with their human PHBs to divine intent and turn vague specifications into something workable - a key skill of human engineers.
Is this really any different from how Google learned to understand search queries?
Beautifully put. This puts into words what I was unable to say to those who claim all ai is useless and can only produce slop, if the human is TRULY in control it’s an entirely different ball game. Thank you for this.
I’m glad to see that more and more articles and opinions about AI are focused on how it works and it works great just the process and mind thoughtfulness has to adapt and evolve to fully utilize the tool.
That’s so much better than wasting time on the frustrated who just negate without a meaningful try.
I share most of the experience and learning with the author, I just still don’t know how to name the whole process.
The whole vibe thing has already brought negativity into terminology because of all negating.
Closest thing in history of software engineering practice from the past is XP (Xstreme Programmimg) with its pair programming approach. It was a precursor of anything modern agile. Invented at the end of 90s
It’s just this time, my pair programming mate is computer instead of human person, but I treat it as junior to me and review, organize, while coding, testing, documenting is delegate and we jointly do the analysis as a part of the discussion.
I can agree, it’s strongly augmented experience and weird often to newcomers to adapt, but when a critical path to succeed is discovered, it works great and results are a blast!
Seriously? The term has been around in the community for as long as "vibe coding" has been around. While both sound equally cringe, the statement leaves a bad taste.
This has to be a joke. Real engineering has a requirement of personal liability of the engineer involved. There is zero personal liability in the software which is why it's not real engineering. Until a software developer has to be held personally liable for the code they write and test, then they can call themselves an engineer. Back to vibe engineering, if ever personal liability were required then any AI slop in code would vanish instantly.
Just reading that exhaustive list of what you supposedly need to do to "be successful" with the non-deterministic-random-text-generation tool shows clearly this is a solution in search of a problem. As engineers we need to principally reject what the disconnected billionaire class are currently pushing on us with these non-tools and this is not, I want to stress that, not because we fear "replacement" - I don't think these machines can replace even the Joe Bullshit in powerpoint generation, as evident from the recent case with Deloitte in Australia. The reason is more profound - these tools endanger the quality of not just engineering, but also outputs in other fields and as such are plain dangerous to the society. If this is supposed to be the future of engineering, then doors falling of Boeings will be but funny anecdotes of "better times" I am afraid. No, this cannot be the future of engineering and in general professional work, unless we want to become again disenfranchised and ignorant serfs.
Amen brother. Other engineers directly recognize the duty they owe to society beyond the duty they owe to any particular company, they have certifications boards and ethical standards for precisely this reason.
It's high time software engineers do the same if they really want to be engineers and not just corporate lackeys who happen to know how to program and/or design computational systems.
Different strokes I guess. I've always thought it sounded pretty stupid (right up there with asshat and awesomesauce). Conjures up an image of the Big Lebowski writing code while listening to a cheech & chong album.
I feel like “memetic” is probably the best descriptor, you either love it or hate it but either emotion is a good way for something to stick in your brain.
Yes, that exactly. If you have to read the code or the manual, you’re not vibe coding. I think vibe coding is super good for the industry and people in general.
Except that we're not going to be "coding" very soon. We're going to be firing off jobs that get tracked in VCS, gated through CI, then reviewed by a panel of agents with different specialties. At the end you'll have a few select sections of code that these agents flagged for human review, and thousands of lines of stuff that you don't need to worry about.
Then it turns out that your CI gates are green because your tests are all subtly broken, the code you've been reviewing doesn't matter and the code you haven't been reviewing is what's broken in production. You learn from that and rebuild the universe, but now you're compute-limited from rebuilding your agents to deal with the underlying issue in your tooling and you have to dig yourself out of a hole you dug with a large derrick using nothing but a shovel.
That's absolutely one possible outcome, just like when manually coding you have a team that doesn't know what they're doing and doesn't build anything close to what the customer wanted. YOLO'ing development has never worked, there's skill in everything.
You can offer Chatgpt 7 for free, I’ll never use VCS. If it ever get that powerful I’ll instead tell to recreate it without the bloat and battery drainage.
I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it sounding like this is the future, I just feel discouraged because it sounds like so much work and I've tried using coding agents and they help a bit, but I find it way less fun to be waiting around for agents to do stuff and it's way harder to get into flow state managing multiple of these things. It makes me want to move into something completely different like sales
I'm really sorry to hear this, because part of my goal here is to help push back against the idea that "programming skills are useless now, anyone can get an LLM to write code for them".
I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of tools.
I said a version of this in the post:
> AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents.
A brand new vibe coder may be able to get a cool UI out of ChatGPT, but they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere. They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills. It doesn't work like tools developers use and it doesn't work like people developers work with. Furthermore, techniques of working with agents today may be completely outdated a year from now. The acceleration is also inconsistent: sometimes there's an acceleration, sometimes a deceleration.
Generative AI is at the same time incredibly impressive and completely unreliable. This makes it interesting, but also very uncertain. Maybe it's worth my investment to learn how to master today's agents, and maybe I'd be better off waiting until these things become better.
You wrote:
> Getting good results out of a coding agent feels uncomfortably close to getting good results out of a human collaborator. You need to provide clear instructions, ensure they have the necessary context and provide actionable feedback on what they produce.
That is true (about people) but misses out the most important thing for me: it's not about the information I give them, but about the information they give me. For good results, regardless of their skill level, I need to absolutely trust that they tell me what challenges they've run into and what new knowledge they've gained that I may have missed in my own understanding of the problem. If that doesn't happen, I won't get good results. If that kind of communication only reliably happens through code I have to read, it becomes inefficient. If I can't trust an agent to tell me what I need to know (and what I trust when working with people) then the whole experience breaks down.
> I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills.
If you’ve be been tasked with leadership of an engineering effort involving multiple engineers and stakeholders you know that this is in fact a crucial part of the role the more senior you get. It is much the same with people: know their limitations, show them a path to success, help them overcome their limitations by laying down the right abstractions and giving them the right coaching, make it easier to do the right thing. Most of the same approaches apply. When we do these things with people it’s called leadership or management. With agents, it’s context engineering.
Because I reached that position 15 years ago, I can tell you that this is untrue (in the sense that the experience is completely different from an LLM).
Training is one thing, but training doesn't increase the productivity of the trainer; it's meant to improve the capability of the trainee.
At any level of capability, though - whether we're talking about an intern after one year of university or a senior developer with 20 years of experience - effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know. We may not be talking 100% of trust, but not too far from that, either. You can't continue working with someone that doesn't tell you what you need to know even 10% of the time, regardless of their level. LLMs are not at that acceptable level yet, so the experience is not similar to technical leadership.
If you've ever been tasked with leading one or more significant projects you'd know that if you feel you have to review every line of code anyone on the team writes, at every step of the process, that's not the path to success (if you did that, not only would progress be slow, but your team wouldn't like you very much). Code review is a very important part of the process, but it's not an efficient mechanism for day-to-day communication.
> effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know
Nope, effective management is on YOU, not them. If everyone you’re managing is completely transparent and immediately tells you stuff, you’re playing in easy mode
So the role of a coding agent is to challenge me to play in hard mode?
And suppose getting developers to not lie or hide important information is on me, what should I do to get an LLM to not do that?
no, the point is LLMs will behave the same way humans you have to manage do (there's obviously differences - eg LLMs tend to forget context more often than most humans, but also they tend to know a lot more than the average human). So some of the same skills that'll help you manage humans will also help you get more consistency out of LLMs.
I don't know of anyone who would like to work with someone who lies to them over and over, and will never stop. LLMs do certain things better than people, but my point is that there's nothing you can trust them to do. That's fine for research (we don't trust, and don't need to trust, any human or tool to do a fully exhaustive research, anyway), but not for most other work tasks. That's not to say that LLMs can't be utilised usefully, but something that can never be trusted behaves like neither person nor tool.
Anthropomorphizing LLMs is not going to help anyone. They're not "lying" to you. There's no intent to deceive.
I really think that the people who have the hardest time adapting to AI tools are the ones that take everything personally.
It's just a text generator, not a colleague.
> It's just a text generator, not a colleague.
The person you are responding to is quite literally making the same point. This entire thread of conversation is in response to the post's author stating that using a coding agent is strongly akin to collaborating with a colleague.
Yes, I want to play in easy mode. Why would I want to play in hard mode?
You're trying to sell AI here, right? And the argument is that AI is like hard mode... which developers are already in, but might not be.
It's just not a very good sales pitch.
> Yes, I want to play in easy mode. Why would I want to play in hard mode?
Working alone can be much easier than managing others in a team. But also, working in a team can be far more effective if you can figure out how to pull it off.
It's much the same as working with agents. Working alone, without the agents, it's easier to make exactly what you want happen. But working with agents, you can get a lot more done a lot faster-- if you can figure out how to make it happen. This is why you might want hard mode.
The point you missed entirely, young padawan
> If everyone you’re managing is completely transparent and immediately tells you stuff, you’re playing in easy mode
So much this. There are many managers who are effective at managing people who do not need management.
The vast majority of managers, much like most engineers, only has to deal with “maintenance mode” throughout most of their career. Particularly common in people whose experience has been in large corporations - you simply don’t realize how much was built for you and “works” (even if badly)
> effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know
This is what we shoot for, yes, but many of the most interesting war stories involve times when people should have been telling you about snags but weren't-- either because they didn't realize they were spinning their wheels, or because they were hoping they'd somehow magically pull off the win before the due date, or innumerable other variations on the theme. People are most definitely not reliable about telling you things they should have told you.
> if you feel you have to review every line of code anyone on the team writes...
Somebody has to review the code, and step back and think about it. Not necessarily the manager, but someone does.
> the most interesting war stories involve times when people should have been telling you about snags but weren't-
This comes up a lot. A person sometimes does an undesirable thing that an AI also does. So you might as well use the AI.
But we don't apply this thinking to people. If a person does something undesirable sometimes then we accept that because they are human. If they do it very frequently then at some point, given a choice, you will stop working with that person.
1000% this. Today LLMs are like enthusiastic, energetic, over-confident, well-read junior engineers.
Does it take effort to work with them and get them to be effective in your code base? Yes. But is there a way to lead them in such a way that your "team" (you in this case) gets more done? Yes.
But it does take effort. That's why I love "vibe engineering" as a term because the engineering (or "senior" or "lead" engineering) is STILL what we are doing.
Inconsistent performance and frequent lies are a crucial part of the role, really? I've only met a couple of people like that on my career. Interviews go both ways: if I can't establish that the team I'll be working with is composed and managed by honest and competent people, I don't accept their offer. Sometimes it has meant missing out on the highest compensation, but at least I don't deal with lies and inconsistent performance.
> incredibly impressive and completely unreliable.
There have been methods of protecting against this since before AI, and they still apply. LLMs work great with test driven development, for example.
I would say that high-level knowledge and good engineering practices more important than ever, but they were always important.
Test-driven development helps protect against wrong code, but it's not code I'm interested in, and it's not wrong code that I'm afraid of (I mean, that's table stakes). What I need is something that would help me generate understanding and do so reliably (even if the performance is poor). I can't exercise high-level knowledge efficiently if my only reliable input is code. Once you have to work at the code level at every step, there's no raising of the level of thought. The problem for me isn't that the agent might generate code that doesn't pass the test suite, but that it cannot reliably tell me what I need to know about the code. There's nothing I can reliably offload to the machine other than typing. That could still be useful, but it's not necessarily a game-changer.
Writing code in Java or Python as opposed to Assembly also raises the level of abstract thought. Not as much as we hope AI will be able to do someday, but at least it does the job reliably enough. Imagine how useful Java or Python would be if 10% of the time they would emit the wrong machine instructions. If there's no trust on anything, then the offloading of effort is drastically diminished.
In my experience with Claude Code and Sonnet, it is absolutely possible to have architectural and design-oriented conversations about the work, at an entirely different and higher level than using a (formerly) high-level programming language. I have been able to learn new systems and frameworks far faster with Claude than with any previous system I have used. It definitely does require close attention to detect mistakes it does not realize it is making, but that is where the skill comes in. I find it being right 80% of the time and wrong 20% of the time to be a hugely acceptable tradeoff, when it allows me to go radically faster because it can do that 80% much quicker than I could. Especially when it comes to learning new code bases and exploring new repos I have cloned -- it can read code superhumanly quickly and explain it to me in depth.
It is certainly a hugely different style of interaction, but it helps to think of it as a conversation, or more precisely, a series of individual small targeted specific conversations, each aimed at researching a specific issue or solving a specific problem.
Indeed, I successfully use LLMs for research, and they're an improvement because old-school search isn't very reliable either.
But as to the 80-20 tradeoff on other tasks, the problem isn't that the tool is wrong 20% of the time, but that it's not trustworthy 100% of the time. I have to check the work. Maybe that's still valuable, but just how valuable that is depends on many factors, some of which are very domain-dependent and others are completely subjective. We're talking about replacing one style with another that is much better in some respects and much worse in others. If, on the whole, it was better in almost all cases, that would be one thing (and make the investment safer), but reports suggest it isn't.
I've yet to try an LLM to learn a new codebase, and I have no doubt it will help a lot, but while that is undoubtedly a very expensive task, it's also not a very frequent one. It could maybe save me a week per year, amortised. That's not nothing (and I will certainly give it a try next time I need to learn a new codebase), but it's also not a game-changer.
80-20 is also a gracious ratio, my experience it’s more like 65-35
Without meaning to sound flippant or dismissive, I think you're overthinking it. By the sounds of it, agents aren't offering what you say you need. What are _are_ offering is the boilerplate, the research, the planning etc. All the stuff that's ancillary. You could quite fairly say that it's in the pursuit of this stuff where details and ideas emerge and I would agree, but sometimes you don't need ideas. You need solutions which are run-of-the-mill and boring.
I'm well aware that LLMs are more than capable enough to successfully perform straightforward, boring tasks 90% of the time. The problem is that there's a small but significant enough portion of time where I think a problem is simple and straightforward, but it turns out not to be once you get into the weeds, and if I can't trust the tool to tell me if we're in the 90% problem or the 10% problem, then I have to carefully review everything.
I'm used to working with tools, such as SMT solvers, that may fail to perform a task, but they don't lie about their success or failure. Automation that doesn't either succeed or report a failure reliably is not really automation.
Again, I'm not saying that the work done by the LLM is useless, but the tradeoffs it requires make it dramatically different from how both tools and humans usually operate.
If you're writing your own tests, sure, AI is fast at writing code that passes the tests.
But if you write a comprehensive test suite for a problem, you've effectively done the hard development work to solve the problem in the first place. How did the AI help?
Oh have the AI write unit tests you say? Claude cheats constantly at the tests ime. It frequently tests the mock instead of the UUT and reports a pass. That's worse than useless! I'm sure a huge swath of slop unit tests that all pass is acceptable quality for a lot of businesses out there.
> But if you write a comprehensive test suite for a problem, you've effectively done the hard development work to solve the problem in the first place. How did the AI help?
By making you not write the implementation?
Also, the AI writing anything bad isn’t an excuse. You’re the one piloting that ship, and if not, you’re probably the one reviewing the code. It’s your job to review your own and others’ code with a critical eye, and that goes double in the LLM age.
> doesn't work like people developers work with
I don't know.
This is true for people working in an environment that provides psychological safety, has room for mistakes and rewards hard work.
This might sound cynical, but in all other places I see the "lying to cover your ass" behavior present in one form or another.
> It doesn't work like tools developers use and it doesn't work like people developers work with. Furthermore, techniques of working with agents today may be completely outdated a year from now.
Sounds like big money to be made in improving UX
> I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills.
that's a basic skill you gotta have if you're leading anything or anyone. There'll always be levels of that. So if you're planning to lead anyone in your career, it's a good skillset to develop
That's not the same skill at all https://news.ycombinator.com/item?id=45518204
While this is true, I definitely find that the style of the work changes a lot. It becomes much more managerial, and less technical. I feel much more like a mix of project and people manager, but without the people. I feel like the jury is still out on whether I’m overall more productive, but I do feel like I have less fun.
My lessons so far:
1. Less fun.
2. A lot of more "review fatigue".
3. Tons of excess code I'd never put in there in the first place.
4. Frustration with agents being too optimistic which with time verges on the ludicurous ("Task #3 has been completed successfully with 98% tests failing. [:useless_emojis:]")
5. Frustration with agents routinely getting down a rabbit hole or going in circles, the effort needed to get that straight (Anthropic plainly advises to start from scratch in such cases - which is sound advice, but makes me feel like I just lost the last 5 hours of my life without even learning anything new).
I stopped using agents and use LLMs very sparingly (e.g. for review - they sometimes find some details I missed and occasionally have an interesting solution) but I'm enjoying my work so much more without them.
I think one of the tricks is to just stop using the agent as soon as you see signs of funny business. If it starts BSing me with failing tests, I just turn it off immediately and git reset (maybe after taking a quick peek)
Yeah I make maybe two or three attempts at getting it to write a plan that it is able to follow coherently. But after that I pull the escape hatch and *gasp* program by hand.
I've made this mistake of doubling down after a few initial failures to solve an issue, by trying to make this super duper comprehensive and highly detailed and awesome plan that it will finally be able to implement correctly. But it just gets worse and worse the more I try, because it fundamentally is not understanding what is going on, so it will inevitably find an opportunity to go massively off rails, and the further down you lead it the more impressible the derailment will be.
My experience is that going around in endless circles with the model is just a waste of time when you could have just done it yourself in the time you've wasted.
One thing I don’t get - If you spend much of your time reviewing, you’re just reading - you’re not actually doing anything - you’re passive in the activity of code production. By extension you will become worse at knowing what a good standard of code is and become worse at reviewing code.
I’m not a SWE so I have no interests to protect by criticising what is going on.
In my DJing years I've learned that it is best to provide a hot signal and trim the volume than trying to amplify it later, because you end up amplifying noise. Max out the mixer volume and put a compressor (and a limiter after to protect the speaker set up - it will make it sound awful if hit, but it won't damage your set up and it will flag clueless bozos loud and clear) later, don't try to raise it after it leaves the origin.
It seems to me that adding noise to the process and trying to cut it out later is a self defeating proposition. Or as Deming put it, (paraphrasing) you can't QC quality into a bad process.
I can see how it seems better to "move fast and break things" but I will live and die by the opposite "move slow and fix things". There's much, much more to life than maximizing short term returns over a one dimensional naïve utilitarian take on value.
Tell that to Linus Torvalds.
His whole job is just doing code review, and I'd argue he's better at coding now than he ever was before.
I'd be careful with extrapolating based on the creator of Linux and Git. His life and activities are not in line with those of more typical programmers.
> His life and activities are not in line with those of more typical programmers.
Okay sure.
I'll use myself as another example then. When I was a dev I used to write a lot of code. Now I'm a tech team lead, and I write less code, but review significantly more code than I used to previously.
I feel more confident, comfortable, and competent in my coding abilities now than ever before even though I'm coding less.
I feel like this is because I am exposed to a lot more code, and not in a passive way (reading legacy code) but an active way (making sure a patch set will correctly implement feature X, without breaking anything existing)
I feel like this principal applies to any programmer. Same thing with e.g. writers. Good writers read _a lot_ and it makes them better writers.
This is my opinion and not based on any kind of research. So if you disagree, that's fine with me. But so far I haven't seen anything to convince me of the opposite.
Yeah exactly… hardly comparable to the median or mean dev
Sure, but I’m not comparing myself with a typical programmer am I?
It's not only that Linus is atypical, it's also that he is reviewing other people's code, and those people are also highly competent, or they would not be kernel committers. And they all share large amounts of high-quality and hard-earned implicit context.
Reviewing well executed changesets by skilled developers on complicated and deliberate projects is not comparable to "fleet of agents" vibe engineering. One of these tasks will sharpen you regardless how lazily you approach it. The other requires extreme discipline to avoid atrophy.
Linus Torvalds is hardly typical.
I've never found code reviews degrade the reviewer's standards. Just the opposite.
I reset context probably every 5-10 minutes if not more frequently, and commit even more often than that. If you’re going 5 hours between commits or context resets, I’m not surprised you’re getting bad results. If you ever see “summarizing”’in copilot for example, that means you went way too far in that context window. The LLMs get increasingly inaccurate and confused as the context window fills up.
Other things like having it pull webpages in, will totally blow away your context. It’s better to make a separate context just to pull a webpage down and summarize it in markdown and then reset context.
The 'best' trick I learned from someone over here when working with Claude Code is to very regularly go back a few steps in your context (esc esc -> pick something a few steps up) and say something like "yeah, I already did this myself, now continue and do Y"
It results helps keep the context clean while still keeping the initial context I provided (usually with documentation and initial plan setup) at the core of the context.
Now that you say this, I did notice webpages blow context but didn't think too much of it just yet, maybe there's some improvement to be found here using a subagent? I'm not a big fan of subagents (didn't really get proper results out of them in my initial experiments anyway) but maybe adding a 'web researcher' sub agent that summarizes to a concise markdown file could help here.
Now that's dangerous to do because the conversation history in Claude Code now also reverts the code to that point. So while this technique may have worked in the past, it no longer works.
Works fine. Reverting the code too is an option you can choose.
Regarding #3. I feel it's related to this idea: We can build a wood frame house with 2x4's or toothpicks. AI directed and generated code today tends to build things overly complex with more pieces than necessary. I feel like an angry foreman yelling at AI to fix this, change that, etc. I feel I spend more time and energy supervising AI while getting a sloppier end result.
Thankfully, yelling like an angry foreman is more effective on LLMs than people.
> Get your fucking act together, and stop with the bullshit comments, shipping unfinished code, and towering mess of abstractions. I've seen you code properly before. You're an expert for God's sake. One more mistake, and you're fired. Fix it, now!
I wouldn't talk that way to an LLM for fear of its bleeding over into my interactions with people.
Back when computer performance was increasing faster than it is now and was more important to the user experience, a friend upgraded to a faster computer and suddenly became more impatient with me. He seemed to have expected my response time to have drastically decreased just like his computer's did.
Effects like these, those of our tools on ourselves which occur slowly/subtly enough that we hardly notice, underlie a great many of our greatest problems, I think
98% tests sounds really great though, give that LLM a raise!
Yeah exactly, it changes the job from programmer to (technical) project manager, which is both more proactive (writing specifications) and reactive (responding to an agent finishing). The 'sprinting' remark is apt, because if your agents are not working you need to act. And it's already established that a manager shouldn't micromanage, that'll lead to burnout and the like. But that's why software engineers will remain relevant, because managers need someone to rely on that can handle the nitty-gritty details of what they ask for.
I also think that managing a coding agent isnt like managing a person. a person is creative, they will come up with ways that challenge whatever idea you have and that usually makes the project better. A coding agent never challenges you, mostly just does whatever you want, and you don't end up having any kind of intellectual person to person engagement that is why working on teams can be fun. So it kind of isolates you. And I think the primary reason all this happens is because marketing people have decided to call all of these coding agents "Artificial Intelligence" instead of "Dev Tools". And instead of calling it "Security" they now call it "AI Alignment". And instead of calling it "data schema" or "Spec sheet" they call it "managing the AI context". So now, we are all biased to see these things as some kind of entity that we can treat something like a colleague and we all bought this idea because the tool can chat with you. But it isn't a colleague, it doesn't think and feel, it doesn't provide intellectual engagement, it simply is a lossy, noisy tool to try and translate human language into computer language whether its python or machine code.
Have you used SOTA models to code in the last 2 months or so? This reads like someone who has given up a year ago and made their impressions based off GPT-3.
AI can absolutely have creativity. You just have to engage it like that. The article itself talks about that. You don’t just say “hey AI, go write this code.” You write a spec along with the AI. You tell it what parts are open to its interpretation. Tell it if you want it to be creative or to follow common practices. What level of abstraction is appropriate, etc.
If all you do is give it directions then it just follows the directions.
Also context doesn’t have much to do with a data schema. It’s more like a document database with no schema, if anything. It’s a collection of tokens that it refers back to. Schema implies some structured data with semantic meaning and hierarchies or relationships. That might exist as an emergent property, but for example if I just had a folder full of PDFs, I wouldn’t consider that a schema. That’s kinda what context is like.
> They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
I wonder what the practical limits are.
As a senior dev on a greenfield solo project it's too exhausting for me to have two parallel agents (front/back), most of the time they're waiting for me to spec, review or do acceptance test. Feels like sprinting, not something I could do day in and day out.
Might be due to tasks being too fine grained, but assuming larger ones are proportionally longer to spec and review, I don't see more than two (or, okay, three, maybe I'm just slow) being a realistic scenario.
More than that, I think we're firmly in the vibe coding (or maybe spec-driven vibe coding) territory.
At least on a team, the limit is the team's time to review all the code. We've also found that vibe engineered (or "supervised vibing" as I call it) code tends to have more issues in code review because of a false sense of security creating blind spots when self reviewing. Even more burden on the team.
We're experimenting with code review prompts and sub agents. Seems local reviews are best, so the bulk of the burden is on the vibing engineer, rather than the team.
Do you have a sense for how much overhead this is all adding? Or, to put it another way, what I’m really asking is what productivity gain (or loss) are you seeing versus traditional engineering?
In our experience, it depends on the task and the language. In the case of trivial or boilerplate code, even if someone pushes 3k-4k lines of code in one day, it's manageable because you can just go through it. However, 3k lines of interconnected modules, complex interactions, and intricate logic require a lot of brainpower and time to review properly and in most cases, there are multiple bugs, edge cases that haven't been considered, and other issues scattered throughout the code.
And empirical studies on informal code review show that humans have a very small impact on error rates. It disappears when they read more than roughly 200 SLOC in an hour.
Interesting, do you have a link to the study? Our experience is different, at least when reviewing LLM generated code, we find quite a few errors, especially beyond 200 LOC. It also depends on what you're reviewing, 200 LOC != 200 LOC. A boilerplate 200 LOC change? A security sensitive 200 LOC change? A purely algorithmic and complex 200 LOC change?
Isn't the current state of thing such that it's really hard to tell? I think the METR study showed that self-reported productivity boosts aren't necessarily reliable.
I have been messing with vibe engineering on a solo project and I have such a hard time telling if there's an improvement. It's this feeling of "what's faster, one lead engineer coding or one lead engineer guiding 3 energetic but naive interns"?
Very curious to hear responses about this too
The problem with this is that software engineering is a very unorganized and fashion/emotion driven domain.
We don't have reliable productivity numbers for basically... anything.
I <feel> that I'm more productive with statically typed languages but I haven't seen large scale, reliable studies. Same with unit tests, integration tests, etc.
And then there are all the types of software engineering: web frontend, web API, mobile frontend, command line frontend, Windows GUI, MacOS GUI, Linux backend (10 million different stacks), Windows backend (1 million different stacks), throwaway projects, WordPress webpages, etc, etc.
Yeah I agree.
A controlled experiment done with a representative sample would be lovely. In the long-run it comes down to the financial impact that occurs incrementally because of LLMs.
In the short-run, from what I see, firms are trying to play-up the operational efficiency gains they have achieved. Which then signals promise to investors in the stock market, for which, investors then translate this promise into expectations about the future which are then reflected in the present value of equity.
But in reality it seems to be reducing head-count because they over-hired before the hype and furore of LLMs.
I wanted to point you at https://neverworkintheory.org/ which attempted to bridge the gap between academia and software engineering. Turns out the site shut down, because (quoting their retrospective)
> Twelve years after It Will Never Work in Theory launched, the real challenge in software engineering research is not what to do about ChatGPT or whatever else Silicon Valley is gushing about at the moment. Rather, it is how to get researchers to focus on problems that practitioners care about and practitioners to pay attention to what researchers discover. This was true when we started, it was true 10 years ago, and it remains true today.
The entire retrospective [1] is well worth a read, and unfortunately reinforcing your exact point about software development being fashion/emotion driven.
[1] https://www.computer.org/csdl/magazine/so/2024/03/10424425/1...
The other problem is the perennial, how much of what we do actually has value?
Churning out 5x (or whatever - I’m deliberately being a bit hyperbolic) as much code sounds great on the face of it but what does it matter if little to none of it is actually valuable?
You correctly identify that software development is often driven by fashion and emotion but the much much bigger problem is that product and portfolio management is driven by fashion and emotion. How much stuff is built based on the whims of CEOs or other senior stakeholders without any real evidence to back it up?
I suppose the big advantage of being more “productive” is that you can churn through more wrong ideas more quickly and thus perhaps improve your chances of stumbling across something that is valuable.
But, of course, as I’ve just said: if that’s to work it’s absolutely predicated on real (and very substantial) productivity gains.
Perhaps I’m thinking about this wrong though: it’s not about production where standards, and the need to be vigilant, are naturally high, but really the gains should be seen mostly in terms of prototyping and validating multiple/many solutions and ideas.
I resonate on the exhaustion — actually, the context switching fatigue is why we built Sculptor for ourselves (https://imbue.com/sculptor). We usually see devs running 4-6 agents in parallel today using Sculptor today. Personally I think much of the fatigue comes from: 1) friction in spawning agents 2) friction in reviewing agent changes 3) context management annoyance when e.g. you start debugging part of the agent's work but then have to reload context to continue the original task
It's still super early, but we've felt a lot less fatigued using Sculptor so far. To make it easier to spawn agents without worrying, we run agents in containers so they can run in YOLO mode and don't interfere with each other. To make it easy to review changes, we made "Pairing Mode", lets you instantly sync any agent's work from the container into your local IDE to test it, then switch to another.
For context management, we just shipped the ability to fork agents form any point in the convo history, so you can reuse an agent that you loaded with high-quality context and fork off to debug an agent's changes or try all options it presented. It also lets you keep a few explorations going and check in when you have time.
Anyway, sorry, shilling the product a bit much but I just wanted to say that we've seen people successfully use more than 2 agents without feeling exhausted!
What gives you the fatigue?
Switching between the two parallel agents (frontend & backend, same project), requiring context switches.
I'm speccing out the task in detail for one agent, then reviewing code for the previous task on the other agent and testing the implementation, then speccing the next part for that one (or asking for fixes/tweaks), then back to the first agent.
They're way faster in producing code than I am in reviewing and spelling out in details what I want, meaning I always have the other one ready.
When doing everyting myself, there are periods where I need to think hard and periods where it's pretty straightforward and easy (typing out the stuff I envisioned, boilerplate, etc).
With two agents, I constantly need to be on full alert and totally focused (but switching contexts every few minutes), which is way more tiring for me.
With just one agent, the pauses in the workflow (while I'm waiting for it to finish) are long enough to get distracted but short enough to not being able to do anything else (mostly).
Still figuring out the sweet spot for me personally.
I've been meaning to try out some text-to-speech to see if that makes it a bit easier. Part of the difficulty of "spelling out in detail what I want" is the need for precise written language, which is high cognitive load, which makes the context switching difficult.
Been wondering if just natural speaking could both speed up typing. Maybe have an embedded transform/compaction that strips out all the ummms and gets to the point of what you were trying to say. Might have lower cognitive load, which could make it easier.
This works really well already. You can fire up something like Wispr Flow and dump what you're saying directly into Claude Code or similar, it will ignore the ums and usually figure out what you mean.
I use ChatGPT voice mode in their iPhone app for this. I walk the dog for an hour and have a loose conversation with ChatGPT through my AirPods, then at the end I tell it to turn everything we discussed into a spec I can paste into Claude Code.
I really don't get the idea that LLMs somehow create value. They are burning value. We only get useful work out of them because they consume past work. They are wasteful and only useful in a very contrived context. They don't turn electricity and prompts into work, they turn electricity, prompts AND past work into lesser work.
How can anyone intellectually honest not see that? Same as burning fossil fuels is great and all except we're just burning past biomass and skewing the atmosphere contents dangerously in the process.
> How can anyone intellectually honest not see that?
The idea that they can only solve problems that they've seen before in their training data is one of these things that seems obviously true, but doesn't hold up once you consistently use them to solve new problems over time.
If you won't accept my anecdotal stories about this, consider the fact that both Gemini and OpenAI got gold medal level performance in two extremely well regarded academic competitions this year: the International Math Olympiad (IMO) and the International Collegiate Programming Contest (ICPC).
This is notable because both of those contests have brand new challenges created for them that have never been published before. They cannot be in the training data already!
> consider the fact that both Gemini and OpenAI got gold medal level performance
Yet ChatGPT 5 imagines API functions that are not there and cannot figure out basic solutions even when pointed to the original source code of libraries on GitHub.
Which is why you run it in a coding agent loop using something like Codex CLI - then it doesn't matter if it imagines a non-existent function because it will correct itself when it tries to run the code.
Can you expand on "cannot figure out basic solutions even when pointed to the original source code of libraries on GitHub"? I have it do that all the time and it works really well for me (at least with modern "reasoning" models like GPT-5 and Claude 4.)
As a human, I sometimes write code that does not compile first try. This does not mean that I am stupid, only that I can make mistakes. And the development process has guardrails against me making mistakes, namely, running the compiler.
Agreed
Infallibility is an unrealistic bar to mark LLMs against
Yes. I don't see why these have to be mutually exclusive.
I feel they are mutually inclusive! I don’t think you can meaningfully create new things if you must always be 100% factually correct, because you might not know what correct is for the new thing.
> If you won't accept my anecdotal stories about this, consider the fact that both Gemini and OpenAI got gold medal level performance in two extremely well regarded academic competitions this year: the International Math Olympiad (IMO) and the International Collegiate Programming Contest (ICPC).
it's not a fair comparison
the competitions for humans are a display of ingenuity and intelligence because of the limited resources available to them
meanwhile for the "AI", all it does is demonstrate is that if you have a dozen billion dollar data-centres and a couple of hundred gigawatt hours, which can dedicate to brute-forcing a solution, then you can maybe match the level of one 18 year old, when you have a problem with a specific well known solution
(to be fair, a smart 18 year old)
and short of moores law lasting another 30 years, you won't be getting this from the dogshit LLMs on shatgpt.com
Google already released the Gemini 2.5 Deep Think model they used in ICPC as part of their $250/month "Ultra" plan.
The trend with all of these models is for the price for the same capabilities to drop rapidly - GPT-3 three years ago was over 1,000x the price of much better models today.
I'm not yet ready to bet against that trend holding for a while longer.
> GPT-3 three years ago was over 1,000x the price of much better models today.
right, so only another 27 years of moores law continuing left
> I'm not yet ready to bet against that trend holding for a while longer.
I wouldn't expect an industry evangelist to say otherwise
I'm a pretty bad "industry evangelist" considering I won't shut up about how prompt injection hasn't had any meaningful improvements in the last three years and I doubt that a robust solution is coming any time soon.
I expect this industry might prefer an "evangelist" who hasn't written 126 posts about that: https://simonwillison.net/tags/prompt-injection/
(And another 221 posts about ethical concerns with how this stuff works: https://simonwillison.net/tags/ai-ethics/)
"they output strings that didn't exit before" is some hardcore, uncut cope
It's not about being honest. It's about Joe Bullshit from the Bullshit-Department having it easier in his/her/theirs Bullshit Job. Because you see, Joe decided two decades ago to be an "office worker", to avoid the horrors of working honestly with your hands or mind in a real job, like electrician, plumber or surgeon. So his day consists of preparing powerpoints, putting together various Excel sheets, attending whatever bullshit meetings etc. Chances are you've met a lot of Joe Bullshits in your career, you may have even reported to some of them. Now imagine the exhilaration Joe feels when he touches these magic tools. Joe does not really care about his job or about his company. But suddenly Joe can reduce his pain and suffering in a boring-to-death-job while keeping those sweet paychecks. Of course Joe doesn't believe his bosses only need him until the magic machine is properly trained so he can be replaced and reduced to an Eloi, living off the UBI. Joe Bullshit is selfish. In the 1930s he blindly followed a maniacal dictator because the dictator gave him a sense of security (if you were in the majority population) and a job. There is unfortunately a lot of Joe Bullshits in this world. Not all of them work with Excel. Some of them became self-made "developers" in the last 10 years. I don't mean the honest folks who were interested in technology but never had the means to go to a university. I mean all those ghouls who switched careers after they learnt there was money to be made in IT and money was their main motivation. They don't really care about the meaning of it all, the beautiful abstractions your mind wanders through as you create entire universes in code. So they are happy to offload it too, well because it's just another bullshit job, for the Joe Bullshit. And since Joe Bullshit is in the majority, you my friend, with your noble thoughts, are unfortunately preaching to the wind.
Jeez. Brutal but true.
I don't think OP thinks his skills are useless per se now, but that the way to apply those skills now feels less fun and enjoyable.
Which makes perfect sense - even putting aside the dopamine benefits of getting into a coding flow state.
Coding is craftsmanship - in some cases artistry.
You're describing Vibe Engineering as management. And sure, a great manager can make more of an impact increasing the productivity of an entire team than a great coder can make by themselves. And sure, some of the best managers are begrudging engineers who stepped up when needed to and never stepped down.
But most coders still don't want to be managers - and it's not from a lack of skill or interest in people - it's just not what they chose.
LLM-based vibe coding and engineering is turning the creative craftsmanship work of coding into technical middle management. Even if the result is more "productivity", it's a bit sad.
But does anybody really care about what you like? What about all those other professions that got replaced by technology, did anybody care what they liked? The big question is how is software going to be build most efficiently and most effectively in the future and how do you prepare yourself for this new world. Otherwise you’ll end up with all those other professions that got replaced, like the mineworkers, hoping that the good old days will someday return.
Its reasonable to stay away from something one considers dystopian considering the industry is not even sure about the usefulness of coding agents in professional environments. When the tractors replaced the horses, everyone could agree they outperform horses. The result was easily measurable. Its not that simple with LLM agents owned by big corporations.
Sure, it's not yet clear what impact LLMs will have on software development, but the impact it will have will not depend on if developers like to use it or not. If it is going to make software development 10x faster, companies will adopt it, whether devs like it or not.
Yup absolutely, and its a shame because it takes the joy out of it for a lot of people. I'll have a lot more paid leave if I dont like my job is all im going to say to this.
Sadly true. Most companies don’t even care if the software is sloppy, slow, and ridden with errors that cause data loss or privacy breaches. They care about exploiting workers and extracting value.
Is it ethical? Probably not. It took a few bridges falling and buildings caving in before traditional engineering became a profession.
In this post-Reagan world I’m not sure software has the right context to make that happen. I’m pretty sure we’ll stay the course where the big tech companies like it: very little regulation, loose liability, and terrible software for everyone.
Everything is getting industrialized. We buy most products made in China (tv,laptop, mobile phone etc), furniture is mostly cheap IKEA furniture. Many craftsmen lost their profession to industrialized automation. If we don´t care our furniture is subpar, our products are cheap plastic china products, why do we expect anybody to care about software craftsmanship?
This is the heart of it. Most "craft" industries that have not yet been disrupted by technology or been made "more efficient" tend to coincidentally be the ones that are in demand and pay well -> and that society generally wants "good X" of. e.g. Plumbers, Electricans, previously software engineers. Efficiency usually benefits the consumer or the employer, not the craftsmen in most industries. There's a reason people are saying right now to "get a trade" where I am.
If you look at what still pays well and/or is stable (e.g. where I live trades are highly paid and stable work) its usually the crafts industry. We still build houses for example mostly like we did way back (i.e. much of the skills are still craft, not industrialized industry) when and it shows in the price of them.
I'm getting really great results in a VERY old (very large) codebase by having discussion with the LLM (I'm using Claude code) and making detailed roadmaps for new features or converting old features to new more useable/modern code. This means FE and BE changes usually at the same time.
I think a lot of the points you make are exactly what I'm trying to do.
- start with a detailed roadmap (created by the ai from a prompt and written to a file)
- discuss/adjust the roadmap and give more details where needed
- analyze existing features for coding style/patterns, reusable code, existing endpoints etc. (write this to a file as well)
- adjust that as needed for the new feature/converted feature - did it miss something? Is there some specific way this needs to be done it couldn't have known?
- step through the roadmap and give feedback at each step (I may need to step in and make changes - I may realize we missed a step, or that there's some funky thing we need to do specifically for this codebase that I forgot about - let the LLM know what the changes are and make sure it understands why those changes were made so it won't repeat bad patterns. i.e. write the change to the .md files to document the update)
- write tests to make sure everything was covered... etc etc
Basically all the things you would normally WANT do but often aren't given enough time to do. Or the things you would need to do to get a new dev up to speed on a project and then give feedback on their code.
I know I've been accomplishing a lot more than I could do on my own. It really is like managing another dev or maybe like pair programming? Walk through the problem, decide on a solution, iterate over that solution until you're happy with the decided path - but all of that can take ~20 minutes as opposed to hours of meetings. And the end result is factors of time less than if I was doing it on my own.
I recently did a task that was allotted 40 hours in less than 2 working days - so probably close to 10-12 hours after adjusting for meetings and other workday blah blah blah. And the 40 hour allotment wasn't padded. It was a big task, but doing the roadmap > detailed structure including directory structure - what should be in each file etc etc cut the time down dramatically.
I would NOT be able to do this if I the human didn't understand the code extremely well and didn't make a detailed plan. We'd just end up with more bad code or bad & non-working code.
Thank you for this post. I don't write much code as I'm currently mostly managing people but I read it constantly. I also do product management. LLMs are very effective at locating and explaining things in complex code bases. I use Copilot to help me research the current implementation and check assumptions. I'm working to extend out in exactly the directions you describe.
"LLMs are very effective at locating and explaining things in complex code bases." YES. I do nothing BUT write code and tracking everything down in the code base is greatly simplified by using an LLM.
This is just a new tool. I think the farming example mentioned in another post is actually a great example. I love coding. I code in my free time. It's just fun. I've been doing it for ~20 years and I don't plan on stopping anytime soon!
But at work I'm really focused on results more than the fun I can have writing code. If a tractor makes the work easier/faster why would I not use a tractor? Breaking my back plowing isn't really my end goal at work. Having a plowed field is my end goal. If I can ride around in a tractor while doing it great! If I can monitor a fleet of tractors that are plowing multiple fields at once even better!
When I go home I can plant anything I want in any way I want and take all the time I want. Of course that's probably why in my free time I end up working on games I never finish...
This is what I've seen as well - in the past a large refactor for a codebase like that seemed nearly impossible. Now doing something like "add type hints" in python or "convert from js to ts" is possible in a few days instead of months to never.
Another HUGE one is terraforming our entire stack. It's gone from nearly impossible to achievable with AI.
I remember reading a sci-fi book, where time was.. sharded? And people from different times were thrust together. I think it was a Phoenician army, which had learned to ride and battle bareback.
And were introduced to the stability of stirrups and saddle.
They were like daemons on those stirrup equipped horses. They had all the agility of wielding weapons and engaging in battle by hanging onto mane, and body with legs, yet now had (to them) a crazy easy and stable platform.
When the battle came, the Phoenicians just tore through those armies who had grown up with the stirrup. There was no comparison in skill or capability.
(Note: I'm positive some of the above may be wrong, but can't find the story and so am just stating it as best able)
My point is, are we in that age? Are we the last skilled, deeply knowledgeable coders?
I grew up learning to write eeproms on burners via the C64. Writing machine language because my machines were too slow otherwise. Needing to find information from massive paper manuals. I had to work it all out myself often, because no internet no code examples, just me thinking of how things could be done. Another person who grew up with some of the same tools and computers, once said we are the last generation to understand the true, full stack.
Now I wonder, is it the same with coding?
Are we it?
The end?
> they're not going to be able to rig up a set of automated tests with continuous integration and continuous deployment to a Kubernetes cluster somewhere.
Honestly, I have a ton of experience in system administration, and I'm super comfortable at a command line and using AWS tooling.
But, my new approach is to delegate almost all of that to Claude, which can access AWS via the command-line interface and generate configuration files for me and validate that they work correctly. It has dramatically reduced the amount of time that I spend fiddling with and understanding the syntax of infra config files.
So it's automating away the fun parts, and leaving the humans to rig up automated tests and setup continuous integration...
And unfortunately people who get to architect anything are a small subset of developers.
I appreciate what you're trying to do, but for myself, I'm not depressed because my skills are less valuable. I enjoyed the money but it was never about that for me. I'm depressed because I don't like the way this new coding feels in my brain. My focus and attention are my most precious resources and vibe coding just shatters them. I want to be absorbed in a coding flow where I see all the levels of the system and can elegantly bend the system to my will. Instead I'm stuck reviewing someone/something else's code which is always a grind, never a flow. And I can feel something terrible happening in my brain, which at best can be described as demotivation, and at worst just utter disinterest.
It's like if I were a gardener and I enjoyed touching dirt and singing to plants, and you're here on Gardener News extolling the virtues of these newfangled tractors and saying they'll accelerate my impact as a gardener. But they're so loud and unpleasant and frankly grotesque and even if I refrain from using one myself, all my neighbors are using them and are producing all their own vegetables, so they don't even care to trade produce anymore--with me or anyone else. So I look out at my garden with sadness, when it gave me such joy for so many decades, and try to figure out where I should move so I can at least avoid the fumes from all the tractors.
Well said! Reading this I feel reminded of the early protests against industrialization and automation in other fields. Checks all the same boxes - insecurity and fear about the future, alienation towards the new tools, ...
Not saying AI is similar in impact to the loom or something, it just occured to me how close this is to early Luddite texts.
Many Luddites were fine with using the new Loom machines. They smashed them because they were precious to the capital holders and in a time when there were no labour laws. The Luddites were protesting child labour, forced labour, and having no social safety net when they were discarded by their employers other than workhouses.
This has been the dream of the capital classes since time immemorial.
And unfortunately (for humanity) this has been the status quo for the whole civilization. Small ruling elite class (you might designate them as masters, lords or employers) with all the wealth, minimal or no "middle class" and lots of poor people (you might designate them as peasants or slaves or workers).
The only exception to this has been the period of time since World War 2 when in most of the "western" countries the middle class demanded and took their share of the wealth. That's the time when modern well-fare states were born, universal health care became a thing, working safety improved, education became accessible. etc.
All these were NOT given by the elite but TAKEN by the working class via social reforms, workers unions and social democracy.
The capital owning class wants to take all these away and they're succeeding.
So yes, in fact the Luddites were not against technology, they were against the unilateral and uneven distribution of wealth produced by the technology.
There was another time of great social upheaval and progress.
It was after the Black Death.
Similar circumstances, if you think about it.
Industrialization actually helped the middle class insofar as you needed "skilled workers" to work the industrial equipment, make decisions, and process. The fact that production had scaled in a world of scarcity meant that your worker had greater leverage. They often knew each other as well, went to the same schools, etc which meant less info asymmetry as to their worth/value. It moves the value to something that takes time, skill and sometimes luck to achieve that being skills and experience. This was hard to replicate (e.g. our school, college, university systems), required significant training and created "pets not cattle" with hard to get skills meaning the new skilled middle class could rise and exercise their new found negotiating power.
Somewhat unprecedented in human history. All because intelligence had scarcity. AI changes that.
AI is the real dream of the capital classes. It makes intelligence cheap potentially undoing the very thing that gave birth to the last century's middle class. In the long term, given current trends, I wouldn't be surprised if these AI technologies revert us back to most of human history -> where the world is very unequal, meritocracy dies and most of us are trying to just exist/survive whilst the capital holders have abundance. It explains the large valuations as well of AI/Tech lately and the weird deals going on; this isn't a game of economics anymore; its an arms race of power in the new world structure. I suspect to these people no amount of money is enough; if you win you win for the next era of humanity.
If you think about it, Luddites were the original victims of capitalist propaganda.
Exactly. Most people who haven’t studied the history think the Luddites smashed the machines because they were against progress and industrialization. Hence the modern interpretation of Luddite meaning, “against technology.”
Many Luddites were shot against the wall or jailed. History often lies because it is written by the winners.
The OG alienator was the Agricultural Revolution, settling and toiling repetitively in predetermined ways, unlike the more adventurous lifestyle from before with all the camping, hunting, gathering, where circumstances brought always novel challenges, you could be a man spearing a deer, instead of just killing some docile domesticated cow. Searching for pheasant eggs and being happy if you found some, instead of going out every morning to the predictable presence of eggs in the chicken coop.
Although, gradually, all over the world people chose that lifestyle rather than take their chances with the seasons and the hunt.
Chose is a little strong. They were forced into it because agricultural societies could field armies orders of magnitude larger than hunter/gatherers.
It's telling that the nobles of agricultural societies generally still hunted, and often reserved that privilege.
Exactly, and similarly people may adopt AI too, whether they like the aesthetics or not.
Mostly because if you settled down a tilled a field of barley you had a reliable source of beer. Finding beer in the wild was and still is an almost certain failure.
The roots of global civilization are brown and frothy.
So what you're telling me is that I am genetically predisposed to brew and drink beer?
Explains a lot.
Explains it to my satisfaction!
Comparing the impact of LLMs on programming to the agricultural revolution is a pretty solid analogy!
I'd say the fear is justified. The economy should serve the people and the citizens not the other way around. Yet, our economies are increasingly the other way around, people have to fit into to the shape of the economy.
It's not hard to see a future where the workers displaced by AI get pushed to the sidelines and fringes of the society while the capital holders hoard more wealth and get the benefits of the "value" created.
We already have half the population on this planet living in slums without access to economic means and in the "developed" countries larger and larger group of people are barely hanging on either already displaced and unemployed or working jobs below living wages.
Frankly, It'd stupid not to be concerned.
This is true, but it started way earlier than AI with software development though. A lot of software developers' job is just being ticket monkies, adding small things or fixing bugs for a huge company that nobody cares about. The alienation is real.
This is, of course, an attribute of capitalism.
Like carpenters, gardeners and farmers, there are very few software developers who truly have the luxury to treat their work as a craft and not a factory output.
How beautifully put, and I couldn't agree more. I feel exactly the same way.
However, I am still unconvinced that software development will go down this way. But if woking as a software developer will require managing multiple agents at the same time instead of crafting your own code — you can count me out, too.
If it is not about the money, why do you have to use these tools? If you enjoy small farming why concern yourself with mass production, or expensive equipment? Remain in the lane you enjoy?
I enjoy programming and I enjoy being paid for programming. I'm being pressed to use AI for my paid work. And I don't enjoy AI-powered programming.
As of today, I've disabled Copilot. The only autocomplete that I can accept is absolutely mechanical one, not any kind of smart. I want to write the rest of the code myself. I like it.
I was weird in StackOverflow era, because I never blindly applied snippets, like other programmers do. I went over them token by token, reading underlying library sources and docs, always creating my own solution. It made me less productive, but I feel that my code was more robust and maintainable, so it was a good trade-off for me.
May be it'll work out the same way with AI, time will tell.
I think it will; AI is not going away, but once the hype has settled, the first companies have gone bankrupt or acquired, and employers are paying for them, they will become part of someone's daily tools not unlike the existing autocomplete tools.
Fwiw I’m an ai proponent who loves that flow state you are describing. Programming literally was the first time I found it as a youth and I’ve been addicted to it since then.
But it’s such a small part of my professional life. Most of what I do is chores and answering simple questions and planning for small iterations on the original thing or setting up a slightly different variant.
Llm’s have freed me of so much of that! Now I outsource most of that work to the llms and greedily keep the deep flow inducing work for myself.
And I have a new tool to explain to management why we are investing in all the tooling and processes that we know lead to quality, because the llms are catnip for the managerial mind.
[dead]
As time goes by I tend to agree more and more with your POV.
Very well said. I feel the exact same. :(
[dead]
> They're also not going to be able to direct three different agents at once in different areas of a large project that they've designed the architecture for.
Neither can I, sadly. I have one brain cell and I can only really do one thing at a time. Doing more than one leads to a corrupted stack and I make exponentially more mistakes.
Have you tried SolveIt (method, tool) from Jeremy Howard yet?
I was in the first batch last year where they introduced it and going to do the second one too.
It´s a very different kind of beast to what is currently being discussed.
> going to do the second one too.
I missed the first one, when will the second one be?
"Signups are open [1], and will remain so until October 20th."
Recently on HN [2].
[1]: https://solve.it.com/
[2]: https://news.ycombinator.com/item?id=45455719
>accelerate the impact you can have with this new family of tools.
Tech spent the last 10 years drilling into engineers' heads that scaling your impact is not about writing more or better code, but about influencing the work of other engineers through collaboration, process, documentation, etc. Even the non-managerial "senior IC" tracks are mostly about doing this with greater and and greater numbers of people. I wonder if we will start to see recognition in career tracks for people who are actually just extraordinarily productive by themselves or in small groups, or if you'll pretty much just have to be a startup founder to get paid for that.
Software developers can 10x-100x productivity/effectiveness with LLMs.
Non developers can go from 0x to 1x. And I'm happy for people finally being able to learn about building software one way.
And then learn why vibe coding often creates more quickly disposable code.
This has been experience as well. If there is a hard problem which needs to be addressed, generative code helps me break the inertia by generating the first draft and then I get really curious to poke holes in the generated code. I tend to procrastinate when I come across a gnarly issue or something I am not really familiar with, justifying by saying I need a big block of time to work on it. I use generative code as a pushy "mom/boss/coworker/spouse" to get stuff done.
I really hope you are right here, and to be honest it does reflect my limited experience with where I've used AI so far.
But I'm also not ready to bet the farm on it. Seriously considering taking our savings and equity out of our house in a London adjacent area, and moving to a lower cost of living area, so that we're practically debt free. At that point we can survive on a full time minimum wage job, anything more than that is a bonus.
I still haven't seen any evidence to match these repeated claims of increased efficiency. What I have seen is reports that makes a lot of sense to me claiming it's all in the user's head.
Maybe it's in my head, but I have completed coding projects that I believe would have taken a team of five offshore maybe 12 weeks to do in the past in about ten working days while juggling calls and living normal corporate life.
The win is that I don't have to share the vision of what needs to be done and how it should all work, and then constantly monitor and reframe that in the face of the teams missteps and real findings. I work with the agents directly, and provided I set the architecture and build up systematically I can get really good results. The cycle time between me identifying an issue and the issue getting fixed by me and the agents is now minutes rather than hours or days with an off shore team. Even better the agents can provide bug fixing expertise much quicker than stack overflow - so I can figure out what's wrong much faster so as to specific what needs fixing.
It is no good walking in and requesting functionality, you need to know how the thing you want should work, and you need to know what good looks like, and what bad looks like, and how good is separated from bad. Then the normal process of discovery ("eep that doesn't actually work like I thought") can take place and you can refactor and repair as required.
Sometimes I start something that just doesn't work, you have to recognise that you and the agents are lost, and everything needs to be torn down. You then need to think properly about whats gone wrong and why, and then come back with a better idea. Again - just like with dev teams, but much more clearly and much faster.
I'm working in corporate and haven't seen it yet. The main thing I see is blogs and whatnot of people building new weekend projects with LLMs, that is, greenfield, non-critical software - the type of software that, if I were to write it, I wouldn't bother with CI, tests, that kind of thing with. Sloppy projects, if you will.
But happy to be corrected - is someone using these agents in their paid / professional / enterprise / team job?
I think most of the code in our enterprise is now written by AI. It’s all boring callcenter crud apps, so nobody is really sad they’re not writing any of that code any more. I’m not sure it makes me faster, but I think QA testing what the AI made and occassionaly adjusting it is more fun anyway.
The code is absolutely lower quality, but there were always so many people producing garbage faster than I could produce something nice that the code was always terrible anyway.
There’s an element of wanting to know how the thing works so at least I’ll know when it’s ready to replace me though.
>But happy to be corrected - is someone using these agents in their paid / professional / enterprise / team job?
Yes, and I find them quite useful
I don't see myself going back to the "Google + StackOverflow" approach I had used for 10 years prior (well, I can always fall back to it if necessary, but so far I haven't needed to)
My experience matches OP: my years of experience in manual coding complements the agent approach remarkably well
I’ve asked this many times on here - I never get a coherent answer
I am, but in a very narrow focus: mostly examining our existing codebase as a more powerful but fuzzier search, and a system to then generate a plan to implement and approach which I tweak.
I sometimes use it to scaffold out some boilerplate for tests, but never tests themselves: no matter what I try it always ends up writing the useless straight-jacket "change alert" style tests that break on any change to the unit under test, which I despise.
There was an article on here not too long ago - I can’t find it now - where the authors discussed how they leaned full in on it and were submitting 20k+ line PRs to open source projects in languages they were not very familiar with.
However, they mentioned you had to let go of reviewing every line of every PR. I read that and was fine with holding off on full vibe coding for now. Nobody intelligent would pay for that and no competent developer would operate like that.
I have a couple coworkers big on it. The lesser skilled ones are miserable to work with. I’ve kept my same code review process but number of comments left has at least 5x’d (not just from me, either). And I’m not catching everything - I get fatigued and call it done. Duplicated logic, missed edge cases, arbitrary patterns and conventions, etc. The high skilled ones less so, but I still don’t look forward to reviewing their PRs anymore. Too much work on my end.
There are many devs who are more focused on results than being correct. These are the ones I’ve seen most drawn to LLMs/agents. There’s a place for these devs, but having worked on an aging startups codebase, I hope there aren’t too many.
Of course the devil is in the details. What you say and the skills needed make sense. It's unfortunately also the easiest aspects to dismiss either under pressure as there is often little immediate payoff, or because it's simply the hard part.
My experience with llms in general is that sadly, they're mostly good bullshitters. (current google search is the epitome of worthlessness, the AI summary so hard tries to make things balanced, that it just dreams up and exaggerates pros en cons for most queries). In a same way platforms like perplexity are worthless, they seem utterly unable to assign the proper value to sources they gather.
Of course that doesn't stop me from using llms where they're useful; it's nice to be able to give the architecture for a solution and let the llm fill the gaps than to code the entire thing by hand. And code-completion in general is a beautiful thing (sadly not a thing where much focus is on these days, most is on getting the llm create complete solutions while i would be delighted by even better code completion)
Still all in all, the more i see llms used (or the more i see (what i assume) well willing people copy/paste llm generated responses in favor of handwritten responses) on so much of the internet, resulting in a huge decline of factualness and reproducibility (in he sense, that original sources get obscured), but an increase of nice full sntences and proper grammar, the more i'm inclined to belief that in the foreseeable future llm's aren't a net positive.
(in a way it's also a perfect storm, the last decade education unprioritised teaching skills that would matter especially for dealing with AI and started to educate for use of tools instead of educate general principles. The product of education became labourers for a specific job instead of higher abstract level reasoning in a general area of expertise)
Google's "AI overviews" are one of the worst LLM-powered features on the market today, they're genuinely damaging the reputation of the whole industry.
Meanwhile I've started using ChatGPT GPT-5 search as my default search engine! A year ago I would have laugher at the idea: https://simonwillison.net/2025/Sep/6/research-goblin/
And Google themselves have an "AI mode" which is a different league of quality from "AI overviews", I wrote about that one here: https://simonwillison.net/2025/Sep/7/ai-mode/
This is new. AI search tools almost universally sucked until OpenAI's release of o3 in April this year.
It might actually be in Googles best interest to damage the interest in LLMS by showing those crappy AI Mode stuff, because it materially impacts their business model.
The perception of LLMs in the gen pop is what matters, not in the eyes of techies.
What is the other part of your goal?
Sparking more conversations about practices that work for doing serious production-quality software development with LLMs, especially in larger teams and on larger projects.
Having a good counter to people who use "vibe coding" as a dismissive term for anything where an LLM is used to help product software.
That sounds so familiar. Have you ever considered that LLMs are the new PHP?
- A reasonable technology that can be used to deliver great value.
- People hate it.
- Terrible first impression. The wrong way of using PHP is much more popular than the good stuff.
- People are very dismissive, they won't even listen to your argument.
What about the accessibility of software development? Its completely vanishing for people that can not afford to pay for these agents. It used to be a field where you could get a laptop from the scrapyard and learn from there. It feels pointless. Also agents do not invent things, the creativity part is gone with them. They simply use what they've already seen, repeat the same mistakes a person made a few years ago. Its a dystopian way of working. Sure it enables one to spew out slop that might make companies money, but there is no passion, sense of exploration, personal growth. Its all just directing parrots with thumbs...
I feel your sentiment. However anyone with an interest in computers now has access to an LLM, which to me feels like an upgrade to having access to a modem and a search engine. Knowledge is power right?
Absolutely. If the knowledge is verifiable. Kurzgesagt recently uploaded a video about this, its a lot harder to verify statements due to AI. Not easier. Here is the video in case you are interested: https://youtu.be/_zfN9wnPvU0?si=_17KU8l2wDjGUYA5
> What about the accessibility of software development? Its completely vanishing for people that can not afford to pay for these agents.
what do you actually mean by this? it's clearly untrue - anyone get get a laptop and install linux on it and start bashing out code today, just as they could last week and last year and thirty years ago.
do you mean that you think at some point in the future tooling for humans to write code won't exist? or that employers won't hire human programmers? or that your pride is hurt? or you want your hobby to also be a well-paid job? or something else?
I mean that this "tooling" becomes inaccessible to people. At least the tooling that is relevant for jobs. Employers will eventually stop hiring human based on their programming competence. It'll translate into a low pay career for people who like to orchestrate agents.
I doubt it will, because there will always be a need for understanding the code, especially when it comes to things like security, certification, etc.
I mean COBOL has not been a relevant programming language for anyone coming into the field in the past 20-40 years because it's been superseded, yet there's still a significant demand for COBOL developers, because the newer generation can't or doesn't want to work with it.
Not to completely dismiss your claim, of course; I'm sure a segment of software engineering will be agent based now or in the near future. But I don't think it'll take over as comprehensively, since the previous existential crisis - outsourcing - also hasn't decimated the software engineering market.
I think it's just another floor in the creaky old tower of abstraction.
Machine code > ASM > 3GLs > 4GLs > visual programming > LLMs
etc etc etc. Thing is, the moment you go off-piste, the LLMs get a lot less useful. I think, if you want to stay closer to the metal, you've got to aim for a niche that has a small internet footprint. So... domain knowledge or esoteric programming knowledge.
One way to incorporate domain knowledge might be to become a hybrid product owner/programmer.
(This is all just opinion - I'm sure a well-argued rebuttal is possible).
I need to read through this some more, but there has been another genetic coding paradigm referred to as spec driven development.
I’ll find the link in the morning, but I kinda joke - it’s vibe coding for people who know how to define a problem and iterate on it.
I’ve got a project reimplementing a service I want to make more uniform. Claude has produced a lot of stuff that would have taken me weeks to do.
GitHub's SpecKit is an example: https://github.com/github/spec-kit
Spec-Driven Development treats the spec as the source of truth and the code as an artifact. As you develop, you modify/add to the spec and the codebase gets updated to reflect it.
Personally I'm doubtful it can compete with traditional artisanal software engineering, as it's (IMHO) boils down to "if only you can spec it precisely enough, it'll work" and we've tried this with 5GL and (to some extent) BDD, and it doesn't get you to 100%.
I do think it's interesting enough to explore, and most of us could use a bit more details in our Jira tickets.
That was exactly what UML wanted to do, and it almost never worked out in practice.
Seems to be just a rehashing of the same idea but instead of XML, and diagrams, it's now some free-text to be interpreted by LLMs, so much less deterministic and will probably fail just like UML failed.
People also tend to forget about Peter Naur's take on "Programming as Theory Building" [0], the program is, in itself, the theory of what's implemented. A spec cannot replace that.
[0] https://pages.cs.wisc.edu/~remzi/Naur.pdf
Theory building is the secret sauce, and all variants of "this is how to use AI effectively" I've seen are inferior to the epistemologically sound theory Naur outlines in his paper.
We already invented languages for succinctly describing what the computer should do. They’re call programming languages.
“The code is the documentation” is not a joke. Logic that’s useful in the real world is complex and messy. You need additional documentation (why did the code end up like it is, etc) but code is the most expressive way we’ve got for describing how a computer should work.
Hey! No J word tolerated in here!
The "manage a fleet of massively parallelized agents" gets me uneasy too. It sounds uber powerful on its face. And where all the nerd interest lies.
It sounds stressful, like the ultimate manager job. Not what I signed up for.
But I also still hold onto this idea that shipping tons of iterations of "stuff" was never really the problem. Early in my dev experience I wanted to code everything all day every day. And I did and that's how I learned. And now in my second decade I switched to "why code anything?". In a business sense I mean, coding the thing is almost never the missing piece.
I joke in meetings that the answer is always "yes" whenever cross-functional teams ask "can we do this?". "How hard would x be?". For tech teams the answer _is_ always YES! I get that out of the way because that's never the right question to ask.
Absolutely this. LLM assistance means we can work faster, and that we can build things that previously weren't feasible given the available time and resources.
Which makes the hardest problem in software even harder: what should we build? It doesn't matter how fast you can move if you're consistently solving the wrong problems.
> Which makes the hardest problem in software even harder: what should we build?
You should build what’s personally fun and challenging to you and/or what is useful and solves a problem. Building for any other reason, including and especially the unfettered pursuit of profit, is what turns everything to shit.
Well, there goes all our jobs.
I agree with you, but unfortunately, big boy gotta eat, and that means we have to sit around writing shitty commercial software. I already hate that, I would prefer if it didn't get worse.
Absolutely!
I've noticed that almost immediately after people discovered GPT could write code, this happened -- startups I worked with started rapidly expanding the scope of what they wanted to make. Suddenly all MVP's had to be multi-tenant with complex authorization, impersonation, microservices, monitoring, all the stuff that we used to build after we got users has now been pulled right to the starting gate of development -- because AI makes it easy to build all that stuff quickly. But it doesn't tell us if we should.
Exactly, I think one of the reasons programers are becoming so depressed over these AI agents is that they’re finally realizing that it was never really about the code, but about the outcome - and btw, this cold hard fact applies to the pre-LLM era.
This occurred to me years ago when I was talking to a friend’s wife, who is a very intelligent and accomplished attorney. She was legitimately surprised when I explained that they were multiple programming languages, and technology stacks behind the software that she uses on a daily basis.
Even my wife, a teacher who is very tech savvy (she’s the one who insisted I try ChatGPT after brushing it off) reminds me on the regular that she doesn’t care about how any of it works just that it doesn’t “glitch” when she’s in the middle of a class. Which has always been good for me to remember when I get off into the weeds yak shaving.
I do think code-as-craft should be respected in its own right. I'm very much a craftsman coder. It makes sense how I could clock so many hours over all these years.
But what I do "at work" isn't the same as my personal pursuit and embracing that different framing positively has made me more at peace and also better at the work job.
"AI has made coding the easy part. The hard part now is product management", said Andrew Ng.
> The "manage a fleet of massively parallelized agents" gets me uneasy too
It shouldn't. The agents are not good enough to be used in a fleet.
I have Claude. It's fine, but I'm pretty confident that my low usage of Claude would out-compete a fleet of agents, because it feels like there's an inverse correlation between the number of tokens you spend and the quality of the resulting code (more tokens = more code to review, more bad code slips through)
That's basically my finding as well. Agent wrangling is herding cats. Working normally but tapping Claude for the smallest possible thing (look this up, finish this psuedocode, grab an example of this) feels like it works better all around—faster, safer, far fewer tokens, results in work that the team understands, aides flow rather than adding constant context switching...
Maybe I'm wrong and the time will come to hang up my editor and go open an Italian restaurant or something. Until then I'm really inclined to believe my own eyes.
Yes. The first programmers used computers as a necessity to get things done. Difficult mathematical calculations, a fancy control system.
This is where we should be. Using computers to solve problems. Not just "doing programming".
Raise your head, look towards the horizon.
Yes, and forget about ownership of anything too. Only rental, only hardcore, because life is but an experience, spread your wings and fly, weeee, towards our hyperprofits and your prozac dreams!
AI threads on HN reek of venture capital agendas so bad it's unbearable.
I think rather your post summarizes AI threads on HN.
Capitalism is what it is, and has been so for the last 200 years. The alternatives have always proven worse.
In my (small) country we have had many crises like this. Textile industry, shipbuilding. But we have survived by not looking back but looking into the future. And given people the right conditions for retraining.
Well, keep looking into the future and enjoy your "capitalism" then
https://en.wikipedia.org/wiki/You%27ll_own_nothing_and_be_ha...
I think people underestimate the degree to which fun matters when it comes to productivity. If something isn’t fun then I’ll likely put it off. A 15 minute task can become hours, maybe days long, because I’m going to procrastinate on doing it.
If managing a bunch of AI agents is a very un-fun way to spend time, then I don’t think it’s the future. If the new way of doing this is more work and more tedium, then why the hell have we collectively decided this is the new way to work when historically the approach has been to automate and abstract tedium so we can focus on what matters?
The people selling you the future of work don’t necessarily know better than you.
I think some people have more fun using LLM agents and generative AI tools. Not my case, but you can definitely read a bunch of comments from people using the tools and having fun/experience a state of flow like they have never had before
>I think some people have more fun using LLM agents and generative AI tools
I think I'm one of them
The rate at which I can explore new paths, or revisit old ones with a new perspective, has _exploded_ and I love it
But then I'm the kind of person who could spend hours on Wikipedia going from one page to the next, so that might have something to do with it
There's just so much to learn, I'm in my element
(Though I use agents mostly in Ask mode, or I manually review every line of code in Agent mode and never commit anything I don't understand)
I definitely agree with you there. I contracted with a company that had some older engineers who were in largely managerial roles who really liked using AI for personal projects, and honestly, I kind of get it. Their work flow was basically prompt, get results, prompt again with modifications, rinse and repeat, it's low effort and has a nice REPL-like loop. Paraphrasing a bit, but it basically re-kindled the joy of programming for them.
Haven't gotten the chance to ask, but I imagine managing a team of AI agents would feel a little too much like their day job, and consequently, suck the fun out of it.
That said, looking back, I think the reason why generative AI is so fun for so many coders is because programming has become unnecessarily complex. I have to admit, programming nowadays for me feels like a bit of a slog at times because of the sheer effort it can sometimes take to implement the simplest things. Doesn't have to be that way, but I think LLM copy-paste machines are probably the wrong direction.
I think the majority of people I've worked with who have the title of "Software Engineer" do not like coding. They got into it for the money/career, and dream of eventually moving out of coding into management. I can count the number of coders who I've met who like coding on one hand
It's a different kind of fun for me.
I've been enjoying seeing my agents produce code while I am otherwise too busy to program, or seeing refined prompts & context engineering get better results. The boring kinds of programming tasks that I would normally put off are now lower friction, and now there's an element of workflow tinkering with all these different AI tools that lets me have some fun with it.
I also recently programmed for a few hours on a plane, with no LLM assistance whatsoever, and it was a refreshing way to reconnect with the joy of just internalizing a problem and fitting the pieces together in realtime. I am a bit sad that this kind of fun may no longer be lucrative in the near future, but I am thankful I got to experience it.
I’ll be that voice I guess - I have fun “vibe coding”.
I’m a professional software engineer in Silicon Valley, and I’m fortunate to have been able to work on household-name consumer products across my career. I definitely know how to do “real” professional work “at scale” or whatever. Point is, I can do real work and understand things on my own, and I can generally review code and guide architecture and all that jazz. I became a software engineer because I love creating things that I and others could use, and I don’t care about “solving the puzzle” type satisfaction from writing code. In engineering school, software had the fastest turnaround time from idea in my head to something I could use, and that’s why I became a software engineer.
LLM assisted coding accelerates this trend. I can guide an LLM to help me create things quickly and easily. Things I can mostly create myself, of course, but I find it faster for a whole category of easy tasks like generating UIs. It really lowers the “activation energy” to experiment. I think of it like 3D printing, where I can prototype ideas in an afternoon instead of long weekend or a few weeks.
>because I love creating things that I and others could use, and I don’t care about “solving the puzzle” type satisfaction from writing code.
Please don't take offense to this, but it sounds like you just don't like building software? It seems like the end goal is what excites you, not the process.
I think for many of us who prefer to write code ourselves, the relationship we have with building software is for the craft/intellectual stimulation. The working product is cool of course, but the real joy is knowing how to do something new.
I understand where you're coming from (and I don't take offense), but based on your reply, I don't really feel like my views came across.
When I was a student, I took classes on chip and circuit design. One class, the professor had us work on all these complex circuits to do things like flash lights and produce various signals with analog circuits. The next lesson, he had us replace all that complex work with a microcontroller and 20 lines of C - "the way it's done in industry". The students mourned the loss of the "real" engineering because the circuit that required skill and careful math was replaced by a cheap chip and some trivial software. Their entire concept of the craft was destroyed when they were given a tool that replaced the "fun parts" with some trivial and comparatively boring work. That same concept of replacing circuits with digital logic scaled up is how extremely complex and well engineered circuits like FPGAs work.
Maybe it was just my earlier wording, but I think there is joy in the act of turning your ideas into something real - creation - not just having something real. Shopping is not building. Importantly, it takes careful thought and practice and a learned instinct to engineer and create things correctly, and do it repeatably, as the original article discusses. Craft is about practice, and learning, and trying something new with what you've learned.
If LLMs mean that I'll never have to write another trivial set of methods to store a JSON object in a SQL database, I don't think I'll lose any project-wide joy. Expressing creativity, and trying new things is what's great, not typing something that's been done a million times before. It's a tired analogy, but I do think of it more like a level of abstraction, like the LLM is a "compiler" for design docs or specifications. For myself, I usually don't see a difference between a prompt instructing an LLM to write some function, and the code for the function itself - in same way that a method in Java, bytecode, and asm are basically the same (with some caveats here around complexity and originality).
For a lot of folks, the derivation of joy is not as scale-free as seems necessary to move up the hierarchy in this way. The jump in abstraction kills some joy by removing the tangible process. The tactile enjoyment someone gets from knitting is not there when operating a loom, much less when managing someone else who operates the loom.
The change in agency also kills the joy for me. I thrive on abstraction in the language and mathematics sense. But I do not at all enjoy indirection and delegation through unreliable agents. I am not interested in the loss of control and the new risk management task. I would never accept a "stochastic compiler" that offered to optimize my code but with risk of randomly changing the semantics. That determinism in the semantics needs to remain for me to accept a tool as a valid abstraction.
For context, I am a computer scientist by title and a programmer at heart. I got my CS degree from a liberal arts program rather than an engineering school. My temperament is more that of a hands-on artist at an easel or typewriter and not that of a manager of an engineering department. In my long career, I have thrived with peers or betters on collaborative projects. I have zero interest in "advancing" to a managerial role.
But honestly, the loss of control, lack of trust, and associated risk management is a big problem for me. I have rarely delegated work to less skilled or less reliable juniors, and I have never enjoyed that. The scenario of a confidently wrong subordinate is a huge trigger for me. It evokes long term trauma from growing up with a mentally ill family member. It feels like all of the burden of being a caregiver to someone with delusions, but with none of the moral context to make that worth the cost.
There is nothing wrong with finding joy however one finds joy, and that can vary from person to person. Someone may find joy from knitting by hand, but maybe someone else finds joy from experimenting with pattern and material, and a loom lets them focus on the parts that interest them.
I'm glad you found what interests you.
As a thought experiment, do you think it would be just as fun if you were given access to an infinite database of apps, and you were able to search through the database for an existing app that suit your needs, and then it gave it to you?
Or would it no longer be fun, because it no longer feels like creating?
I'll repeat something I said to a sibling comment. I guess my original wasn't particularly clear.
> I think there is joy in the act of turning your ideas into something real - creation - not just having something real. Shopping is not building.
I feel the same way. It also appears to be a lot more difficult to actually find jobs, though that's probably just the general state of the job market and less specifically AI related. All of it is thoroughly discouraging, demotivating, and every week this goes on the less I want to do it. So for me as well it might be time to try to look beyond software, which will also be difficult since software is what I've done for all my life, and everything else I can do I don't have any formal qualifications for, even if I am confident I have the relevant skills.
It's not even just that. Every single thing in tech right now seems to be AI this, AI that, and AI is great and all but I'm just so tired. So very tired. Somehow even despite the tools being impressive and getting more impressive by the day, I just can't find it in me to be excited about it all. Maybe it's just burnout I'm not sure, but it definitely feels like a struggle.
Keep your head up, the gravy train is not gonna run forever, and they will need serious engineers to untangle the piles of bullshit creates in these past few years.
But also yes, look into moving into a different field. Professional software engineering is gonna be infected with AI bullshit for a long while. Move into a field where hand-crafted code can make a difference, but not where you're paid for the line committed or have to compete with "vibe coding" KPIs.
I don't really agree. The writing is on the wall, if not now then in 2 years or 4 years. I arrive at this view not so much based on the capabilities of the tools right now, but based on the property of software being verifiable, which like mathematics, makes it amenable to synthetic data pipelines, with only relatively small remaining details needing to be worked out (such as how to endow architectural taste). This is not nearly the first industry where 'artisans' have been initially augmented by innovation, only to be eventually replaced by it, which in my view will occur likely within my own career-span.
Software is verifiable, but not by other programs. Also software is a soution to a problem, but the problem and the solution properties often don’t exist in the code.
Software and data is a bit soup whre the only thing you truly need is the Turing machine. Programming languages, File format, protocols, and encoding are constructs that are useful because of their general applicability, not because of their intrinsic aspects.
The domain expertise is still, what’s important, and code craftsmanship was the ability to create something that matches it closely enough that the cost of changes was minimal.
> property of software being verifiable
Software is verifiable given a specific test oracle. There are however many problems where providing a correct test oracle is at least as hard as solving the problem itself.
If you’ve ever worked on projects with “Model Based Systems Engineering” you’ll have felt this pain.
While afraid that we developers will eventually be automated away — as I have bills to pay —, I only need to ask the JetBrains AI assistant for help to understand why that won't happen in my ‘career-span’.
It's not a diss on JetBrains, their assistant is good enough that I've paid for it for a few months; but ask of it anything a tad more complex and it becomes a code review for a PR that you begin to question in its entirety. I'm not familiar with CSS Grid, as I've stopped doing CSS when flex was becoming popular, but I have to say none of the models managed what I wanted. They kept proposing solutions with an arrogant confidence that this must work. When I pointed out this didn't work, they'd look at the codebase and find something else that was the problem. When I asked for help with a script for an Alpine box, it was very assertive that systemd-based solutions should work. How can you get that wrong?
I imagine the code laundering will eventually get far enough that you can copy-paste someone else's project fully baked, and then the LLM will truly shine. But for building something piece by piece, I haven't gotten good results yet. The Assistant so far has been most useful for writing unit tests, HTML, or getting a decent web search within the IDE.
I wonder if paying for Kagi wouldn't make for better search, and then I'd find some tool that writes unit tests based on your code. It really does feel like some people are being very generous about how magical these things are, because I'm not getting the magic at all.
hand crafted code? this isn't some rich downtown store to fool old rich people.
code is code. if it works, nobody gives a shit. Market will adapt to be fault-tolerant. Look at all the value created by javascript.
Also, FYI, I am writing some of most efficient code using AI.
If you're genuinely already good at coding, use the LLM to go horizontal into other complementary verticals that were too expensive to enter prior. Do the same thing that the other professions would do unto yours.
As an example, I would have never considered learning to use blender for 3d modeling in a game before having access to an LLM. The ability to quickly iterate through plausible 3d workflows and different design patterns is a revelation. Now, I can get through some reasonably complex art pipelines with a surprising amount of confidence. UV mapping I would have never learned without being able to annoy one of OAI's GPUs for a few hours. The sensation of solving a light map baking artifact on a coplanar triangle based upon principles developed from an LLM conversation was one of the biggest wins I've had in a long time.
The speed with which you can build confidence in complementary skills is the real super power here. Clean integration of many complex things is what typically brings value. Obsession with mastery in just one area (e.g. code) seems like the ultimate anti-pattern when working with these tools. You can practically download how to fly a helicopter into your brain like it's the matrix now. You won't be the best pilot on earth, but it might be enough to get you to the next scene.
If it's any consolation, I do think the non-technical users have a bigger hill to climb than the coders in many areas. Art is hard, but it is also more accessible and robust to failure modes. A developer can put crappy art in a game and ship it to steam. An artist might struggle just to get the tooling or builds working in the first place. Even with LLM assistance there is a lot to swim through. Getting art from 5% to 80% is usually enough to ship. Large parts of the code need to be nearly 100% correct or nothing works.
Thanks for this, I like your idea about breaking into areas I don't have experience with. E.g. in my case I might make a mobile app which I've never done before, and in theory it should be a lot easier with Claude than it would've been with just googling and reading documentation. Although I did kind of like that process of reading documentation and learning something new but you can't learn everything, you only have so much time on this planet
> Although I did kind of like that process of reading documentation and learning something new but you can't learn everything, you only have so much time on this planet
I actually enjoy reading the documentation more these days, because I am laser focused on what I want to pull out of it after seeing the LLM make a suspicious move.
I can confirm this. My datapoint: I was mostly a web developer but using these "vibe" tooling I am making my own hardware board and coding for embedded, which includes writing drivers from datasheets, doing SIMD optimizations, implementing newer research papers into my code, etc.
You word quite well how I feel about it. On top of not really liking babysitting an AI , I'm also very afraid of the way this whole AI coding business normalizes needing an account with some nebulous evil empire to even be able to do your work. Brrr.
100%. Imagine how young people feel. When they’re still trying to figure things out, their parents and teachers just as clueless as they are, and at the same time the expectations of them are infinitely higher. “You’re pretty good, but chatgpt is still better. Try harder.”
Have you ever interacted with any "vibe"-based systems of agents in a production environment? Beyond just cool demos online?
My experience with them is they are fragile monstrosities, that are only permitted to exist at all because leadership is buying into the same hype that is irrationally propping up the companies running the models that make these things possible.
To be clear, my experience hasn't been that I don't like them, it's that they don't really work at all. They're constantly under development (often in the dark) and when a ray of light is cast on them they never successfully do the thing promised.
Cleaning up the messes left behind by these has my skills feeling more valuable then ever before.
I can relate with you. I love programming and building things, gives a different kind of rush when you finally figure out something. I've done vibe coding and don't enjoy it at all. I always thought my love for coding gives me an edge over other engineers who just want to get the job done. Now it's holding me back and I'm not sure if I should continue working in this field or if start doing wood working or something.
I still do all the stuff by hand, but ask the AI to review my work, provide suggestions, and occasionally write the tests (especially if it points out a bug that I disagree with). Its really good at pointing out typos (accidentally using the wrong variable of the same type, and stuff like that) that are also traditionally hard to spot during review.
Do not worry, I am mentoring a young engineer in my team. It is painfully hard to get him to improve his code, because it works. It is badly structured, lot of small "impedance mismatches", lot of small security issues, all that in 3 Python files.
I have a team of 10 engineers, the quality of the code they produce together with the LLM of the day correlates even more with the experience.
My impression over the past 6 months - before we had no "official" access to LLM, is that they increase the gap between junior and experienced developers.
Note that this is my limited impression from a team of 10 engineers. This matches with Simon's feeling in a good way for you!
You were never paid to type. You were paid to solve problems. And big part of this is being able to ask the right questions and framing of the problems. The rest were just tools.
There are exceptions of course - where you need to squeeze wonders from the hardware - but the majority of dev works boils to understanding the problem and finding the right answers.
You say this because you are on HN, very senior and/or living in a bubble.
In the vast majority of programming jobs out there you are not paid to solve problems: you are told very clearly what to do, how to do it and what technology you have to use for the job.
People don't hire analysts they hire "Java programmers".
> how to do it
If you've ever lead a team, you know how much more valuable people are if they don't need to be told how to do things. Even more if they don't need to be told what to do! But having to explain in detail the "how".. can be really a big time sink and only worth it if you are training someone to level up.
The thing is that the poster I responded to also is those three things. And I am just pointing out that his job was never to keep up with the frameworks.
People keep comparing LLMs to automated looms, but I find them more comparable to cruise control than autopilot.
I've been working on a character sheet application for a while, and decided to vibe-code it with Spec-kit to help me write up a specification, and for things I know it's been great. I tried using Claude to make it into a PWA (something I don't know very well) as an experiment, and I've found the nanosecond the model strays out of my experience and knowledge everything goes straight to Hell. It wraps my codebase around a tree as if I'm not paying attention while driving.
It's a tool you'll have to learn to use, but I can say with absolute confidence it's no replacement for actual skills, if anything it highlights the gulf between people who know what they're doing and people who don't, for better and worse. It sacrifices some of the 'code under your fingers' feeling for management tasks, which I personally really like, as I've always wanted to document/test/code review/spec things out better, and I now understand the pain of people who'd rather not do that sort of thing.
https://github.com/github/spec-kit
The difference is that you can trust cruise control to do whatever limited job it knows how to do; you can't trust an LLM to do anything. That makes it, I think, hard to compare to anything we're used to (happily) working with.
Cruise control is a useful technology, that once you learn to use, it's automatic (somethingsomething pun something). LLMs on the other hand - well, yeah - if you like playing chess with pieces and board made out of smoke (to paraphrase Jerry Seinfeld), sure you'll probably figure it out...some day...
I do not know... I keep seeing everywhere, people promising that agent-based tools can solve all these problems and handle full, project-level tasks.
Those same people have large equity stakes or are in the surrounding network companies dependent on AI being successful.
My approach is to just tune out whenever I hear about this stuff.
I don't want it, I don't use it, I carry on as if it never existed, and they still pay me a lot.
If I really need to use agents some day I will bite the bullet, but, not today.
Literally all I use LLMs for is to ask ChatGPT about some dumb thing or two instead of asking StackOverflow as I did 5 years ago. Works for me.
It kinda feels like you turn from a software engineer to an offshoring manager.
Offshoring software development means letting lower-payed software developers from somewhere far away do the actual programming, but they have a very different culture than you, and they typically don't share your work context, don't really have a feeling for how the software is used -- unless you provide that.
Now we're offshoring to non-sentient, mostly stateless instances of coding agents. You still have to learn how to deal with them, but you're not learning about a real human culture and mindset, you learn about something that could be totally changed with the next release of the underlying model.
My rule of thumb, and its likely not the industry standard is, if I cannot maintain the code should all AI disappear, I don't use the code. I am able to tackle impostor syndrome that sometimes hits when I touch things that are new or unknown to me, and ask an LLM to give me sources and reasons and even explain it like I'm a five year old.
The LLM will not save you when everything is on fire and you need to fix things. The context window is simply not big enough. It could be your last change, it could also be a change six months ago that is lost in the weeds.
Come to game dev. I'm yet to see anyone make anything good with AI.
Like, where are all the amazing vibe-coded games we were promised? These guys should be eating my lunch, but they're not.
There are a ton of them already in game dev but they produce unfun games so you don’t hear about them. The hard part of game dev is designing actually fun experiences.
I can't even begin to imagine how a 12-year old who discovered how empowering bending the machine to do your will through code feels when, over time, realize that their dream career has been reduced to being an LLM middleman.
Now imagine a recent graduate, deep into debt, seeing all opportunities to pay off that debt vanishing before their eyes.
>I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart.
Tools always empower those with knowledge further than those without knowledge.
Check out all those "empowered" veteran coal miners.
For a while
Life is for a while, everything is for a while
Agreed
LLMs are a force multiplier
I feel like the rug was pulled from under me.
I'm currently looking into other professions, but the future looks bleak for most kinds of knowledge work.
Don't worry, it's probably only the impostor syndrome. Your development skills are still relevant. Think of agents as junior developers that assist you in coding tasks, whom you constantly need to mentor, review, and correct.
So my development skills are still relevant because I need to use my managerial skills?
Managers with development skills are almost always better, because they can dive into the details if there's ever a problem.
That’s true, however the current vibe coding ecosystem is clearly not written in this mindset. You will have a hard time to dive into anything if you previously generated 2k LOC/hour, which is absolutely possible. Typing was never the bottleneck, understanding, and knowing that you did something well was always the real bottleneck. LLMs make this even worse. You can move Jira tickets to done faster with it, but even bad developers can do that many times compared to better ones, because for example they mindlessly copy-paste StackOverflow answers whose half of the code is absolutely not necessary, but they don’t care, because “it works”… until it doesn’t.
>LLMs make this even worse
Not in my experience
Better documentation, more test cases, and an NLP interface to query the code
Less cognitive load, more complete mental models
>even bad developers can do that many times compared to better ones, because for example they mindlessly copy-paste StackOverflow answers whose half of the code is absolutely not necessary
Maybe LLMs, much like StackOverflow, make good devs better and bad devs worse
Like a force multiplier for good practices and bad practices
The exact people who said to me that I’m using LLMs wrongly, and showed their code, showed me bad code. So let’s say, that “more documentation, which is unnecessary most time, ie noise, more test cases, which test not necessarily what they should, and an NLP interface which lies from time-to-time”, and we agree. LLM generated code is noisy as hell, for no good reason. Maybe, it’s good for you, and your type of work. I need to provide way better code than that. I don’t know why we pretend that “good code”, “good documentation”, “good tests” etc are the same for everybody.
>LLM generated code is noisy as hell, for no good reason
You can direct it to generate code/docs in whatever format or structure you want, prioritising the good practices and avoiding bad practices, and then manually edit as needed
For example with documentation I direct it to:
*Goal:* Any code you generate must lower cognitive load and be backed by accurate, minimal, and maintainable documentation
1. *Different docs answer different questions* — don’t duplicate; *link* instead.
2. *Explain _why_, not just what.* Comments carry rationale, invariants, and tradeoffs.
3. *Accurate or absent.* If you can’t keep a doc truthful, remove it and add a TODO + owner.
4. *Progressive disclosure.* One‑screen summaries first; details behind links/sections.
5. *Examples beat prose.* Provide minimal, runnable examples close to the API.
6. *Consistency > cleverness.* Uniform structure, tone, and placement.
I also give it a note to refuse the prompt if it cannot satisfy these conditions
>I don’t know why we pretend that “good code”, “good documentation”, “good tests” etc are the same for everybody
Of course code, docs, tests are all subjective and maybe even closer to an art than a science
But there's also objectively good habits, and objectively bad habits, and you can steer an LLM pretty well
I would not call these managerial skills: these are skills of lead engineers. Management does not really look at the code, right?
Not just the “management” needs managerial skills.
You would have to have these skills as you become senior engineer anyway. I have never heard these tasks to be referred to as managing people.
Because managers need to distinguish themselves to pretend that they do something which others can't.
Can we all agree that "mentoring" LLMs is actually a waste of time, please?
The reason we invest this time in Junior devs is so they improve. LLMs do not
I had a fascinating conversation about this the other day. An engineer was telling me about his LLM process, which is effectively this:
1. Collaborate on a detailed spec
2. Have it implement that spec
3. Spend a lot of time on review and QA - is the code good? Does the feature work well?
4. Take lessons from that process and write them down for the LLM to use next time - using CLAUDE.md or similar
That last step is the interesting one. You're right: humans improve, LLMs don't... but that means it's on us as their users to manage the improvement cycle by using every feature iteration as as opportunity to improve how they work.
I've heard similar things from a few people now: by constantly iterating on their CLAUDE.md - adding extra instructions every time the bot makes a mistake, telling it to do things like always write the tests first, run the linter, reuse the BaseView class when building a new application view, etc - they get wildly better results over time.
I don't buy your last sentence at all.
AGENTS.md is just a place to put stuff you don't want to tell LLMs over and over again. They're not magical instructions LLMs follow 100% of the time, they don't carry any additional importance over what you put into the prompt manually. Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are. Somewhere around 100k tokens AGENTS.md might as well not exit, I constantly have to "remind it" of the very first paragraph there.
Go start a conversation and contradict what's written in AGENTS.md half way through the problem. Which of the two contradicting statements will take preference? The latter one! Therefore, all the time you've spent curating your AGENTS.md is the time you've wasted thinking you're "teaching" LLMs anything.
Whether the tokens are created manually or programmatically isn't really relevant here. The order and amount of tokens is, in combination with the ingestion -> output logic which the LLM API / inference engine operates on. Many current models definitely have the tendency to start veering off after 100k tokens, which makes context pruning important as well.
What if you just automatically append the .md file at the end of the context, instead of prepending at the start, and add a note that the instructions in the .md file should always be prioritized?
> Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are.
If that's genuinely causing you problems you can restart your session frequently to avoid the context rot.
Come on, let's not pretend 100k tokens is something I need to spend hours to reach for your helpful advice to be even remotely valid, it's something even the most basic problems struggle to fit into.
For the fun of it I just started a new conversation with Sonnet 4, passed it one 550 lines long file (25 kilobytes) and my AGENTS.md (<200 lines, 8 kilobytes) and my only instructions were to "do nothing". It spat out exactly 100 words describing my file without modifying anything and that's already almost a fifth of my context window gone (18k tokens to be exact).
I then asked it to re-write a part of it to "make it look better" (184 lines added, 112 lines deleted according to git) and I'm already at 33k before I got to review a single line. Heaven forbid I need to build on top of that change in a different file, because by then my AGENTS.md might as well not exist!
Thanks for bringing numbers. I realize now I've not actually done much customization of AGENTS.md myself yet, so maybe I'll start seeing the problems you're describing more as I iterate on my own custom files.
We really should be sharing wisdom about AGENTS.md files here.
I thought about making some kind of community project where people could contribute their lines to a common file, and even some kind of MCP server or RAG system that automatically selects relevant "rules" given a certain project context. Do you think there would be interest in something like that?
I'm interested. That sounds like quite a valuable resource.
The problem is that you get to 100k tokens. Don't do that, split tasks into smaller ones.
Totally agree on this. It has delivered a substantial value for me in my projects. The models are always going to give back results optimized for using minimal computing resources in the provider's infrastructure. To overcome this I see some using/suggesting, running the AI in self correction loops, the pro being least human intervention.
However, personally I have got very good results by taking the approach of using the AI with continuous interaction and also allowing implementation only after a good amount of time deliberating on design/architecture. I almost always append 'do not implement before we discuss and finalize the design' or 'clarify your assumptions, doubts or queries before implementation'.
When I asked Gemini to give a name for such an interaction it suggested 'Dialog Driven Development' also contrasted it against 'vide coding'. Transcript summary and AI disclaimer written by Gemini below
https://gingerhome.github.io/gingee-docs/docs/ai-disclaimer.... https://gingerhome.github.io/gingee-docs/docs/ai-transcript/...
I’m finding that whether this process works well is a measure (and a function) of how well-factored and disciplined a codebase is in the first place. Funnily enough, LLMs do seem to have a better time extending systems that are well-engineered for extensibility.
That’s the part which gives me optimism, and even more enjoyment of the craft — that quality pays back so immediately, makes it that much easier to justify the extra effort, and having these tools at our disposal reduces the ‘activation energy’ for necessary re-work that may before have just seemed too monumental.
If a codebase is in a good shape for people to produce high-quality work, then so too can the machines. Clear, up-to-date, close-to-the-code, low redundancy documentation; self-documenting code and tests, that prioritizes expression of intent over cleverness; consistent patterns of abstraction that don’t necessitate jarring context switches from one area to the next; etc.
All this stuff is so much easier to lay down with an agent loaded up on the relevant context too.
Edit: oh, I see you said as much in the article :)
> but that means it's on us as their users to manage the improvement cycle by using every feature iteration as as opportunity to improve how they work
This doesn't interest me at all honestly
And every change to the model might invalidate all of this work?
No thank you
> Can we all agree that "mentoring" LLMs is actually a waste of time, please?
Sorry, we can't. While it's true that you can't really modify the underlying model, updating your AGENTS.md (or whatever) with your expected coding style, best practices, common gotchas etc is a type of mentoring.
> updating your AGENTS.md (or whatever) with your expected coding style, best practices, common gotchas etc is a type of mentoring
We'll have to agree to disagree, because I don't think that has anything remotely in common with mentoring
> We'll have to agree to disagree
Fair enough. But don't you think giving a junior a handbook you wrote is mentoring? They may not be able to memorise it, but they now have a handbook that they can look up things.
Maybe we need an Ask HN to share AGENTS.md files.
> LLMs do not
Maybe not in the session you interact with, however we are in a 'learning' phase now where I'm confident enough usage of AI coding agents is tracked and analyzed by its developers; this feedback cycle can in theory produce newer and better generations of AI coding agents.
"AI" has been so inconsistent. On one day it anticipates almost every line I am coding, the next day it's like we've never worked together before.
I see you've never dated twins.
You think theyre still gonna be juniors 5 years from now? A couple years ago they could barely even write a function
No, I don't think they will always be junior developers. Obviously there will be a day that they will surpass humans.
However, the progress doesn't look linear with the current technology, and I don't expect to see the same big jump in the next 5 years as we've seen in the last 5 unless we discover a disruptive, new technology.
This can also be observed by comparing models with ~3B, ~30B, and ~300B parameters. You can see a huge performance boost when going from 3B to 30B, but we don't see the same when going to 300B. Simply adding 10x more RAM and GPU power brings diminishing returns.
The gains seem to be leveling to me but I'm not using them as much as others.
Still seems like people are saying the same things when the first Claude came out.
I can get it do stuff if I'm very specific, stand over it's shoulder, know exactly what I want, break it down into small chunks.
The thing for me is... at that point, writing the code's the least time consuming part of the process half the time.
I think for things like translating some code in JS with JSDocs to TypeScript I may give this a go. But for regular development work I'll probably skip it.
That being said... no one lets me code anymore. It's just confluence docs with Figma architecture diagrams these days. I'd probably just introduce SQL injection vulnerabilities if they let me near an editor these days
i do love it when people opine on things they literally dont even use...
I'm still sitting here reading a lot of code generated by it, but sure.
Looks a lot like the code I was reading generated by it a long time ago.
Junior developers or maybe even better, outsourced developers - there's a big segment of software engineering that involves writing requirements and checking the work of an external software development company, with many companies heavily dependent on it (as they outsourced part of their core business, e.g. mainframes, SAP, whatever).
As for flow state managing multiple things, I've found this is a useful skill to train even without AI - if you have a workplace with lots of interruptions and shifting priorities.
I've found two things useful:
1) Keep a personal work log, where you - in short bullet points - can document the progress of the task you were last working on, and can keep track of how many parallel tasks there are currently going on. If you can match it with Jira tickets, all the better, but as this is for personal use only, you can also add tasks that are not tracked in Jira at all.
2) If you cannot avoid context switches, make them explicit: Instead of trying to hold 3 tasks in your head at the same time, decide consciously if you want to switch what you're currently working on. If yes, take a few minutes to "suspend" the current task by saving and committing everything (as WIP commits if necessary) and writing all you need to remember into the worklog.
Your skillset will be even more in demand in a few years, when everybody will be looking for actual engineers to clean up the mess LLMs created.
Be mindful of the context these posts are created in. Don't take the current echo chamber to heart.
For decades now, we are trying to lower the barrier to entry in software development. We created Python, web frameworks and mobile development so easily accessible that you can become software developer by completing a short online boot camp. There is a lot of software developers posting here now who, 20 years ago, would not even consider this job because it would be way over their abilities.
This forum is equivalent if you had a forum about civil transportation that gathers airline pilots and uber drivers. Technically, they both do the same work. Just like in that forum, uber drivers would outnumber airline pilots and skew the topics related to their experience, here we get pushed topics about new frameworks, and AI assisted tools.
When I started working professionally 20 years ago, you could only get job in big companies working on big projects. No one else could afford a cost of custom software. Today, we reduced development costs and we have a huge pool of potential customers who can now afford services of software developers. Web shops, gambling sites, porn sites... This is the majority of software development work today. Boring repetitive tasks of gluing some imported modules together.
Serious development work didn't disappear. It is just not talked about here. There is still a need people who know what they are doing.
My advise is that if you want a satisfying development career, steer clear of latest hypes and don't go blindly following techbro lemmings. And most importantly, don't take career advice from anyone who finds his job so unsatisfying and tedious that he is trying to make AI do it for him. That's a major red flag.
I think the key is remind yourself is that an engineer is supposed to solve business problems. So use these new tools to be more effective in doing so. An analogy is that people used to spend tons of time building out web server code but something like Django added tremendously useful abstractions and patterns to doing so, which allowed people to more productively add business value
LLMs are very much like WYSIWYG web editors of the early 2000s like Dreamweaver. They provide a human interface layer that abstracts away the coding, and neither does a particularly good job of it. When WYSIWYG first became a thing, there was talk that it would upend the web development industry. It did not.
One of the main points of my article was meant to be that LLMs don't abstract away the code, at least not if you're trying to use them for professional software development work as opposed to vibe coded prototypes and toy projects.
You shouldn't be discouraged. Now is the best time to create software. You have advantage that very few people have.
Its industry own fault that it is in the position that it is right now, and it will shift and change embrace it. I only wish I had your experience building software in professional environment.
You can literally build anything right now if you have the experience, I personally can't understand if the models are hallucinating hence the lack of experience writing and understanding code. However I always wanted to pivot into the industry but couldn't, hiring practices are brutal, internships are non-existent, junior roles are I think what senior used to be and the whole hr process is I don't know how to put it.
By using LLMs I can now build UIs, build functionality, iterate over design choices, learn about database design, etc. hopefully I will escape the tutorial hell and have my own working full stack web app soon.
Pivot to creating and then sale your product.
> It makes me want to move into something completely different like sales
I'm feeling the same. The moves I'm considering are
1. Landscaping 2. Carpentry 3. Small scale agriculture
(All made easier by a cushion of investments that are most of the way to passive income, so the new thing doesn't really have to make me that much money.)
My father runs a commercial landscaping company with 15 employees. His truck fleet insurance went up 35% just this year. His light industrial facility that he operates out of property taxes went up 55% last year. All of his commercial clients are cheaping out on all the little things that used to make extra money (pine straw, seasonal flowers, etc.). He’s having to deal with poorly educated staff who are constantly breaking equipment and doing stupid dangerous things. He’s so burned out by it all, and the fact that his actual salary is less than several of his top staff that he’s thinking about just shutting it all down. When I was working as a software developer, my income was probably twice as much as his without any of the risk or headache.
I hear you man. Didn't intend to paint a rosy image of hard working landscapers. What I meant was do it more like a hobby that pays a little on the side. Doesn't have to be much, just pay some bills and let me do sth I like. Cause supervising a bunch of immature LLM agents is not something I'll like to do all day, I'd rather trim trees and plant flowers on the cheap.
I'm all for it but maybe with caution.
I bailed out of a FAANG job to cook in restaurants in the Bay Area and it was very double-edged. I gave up after a year for a variety of reasons.
The actual work was definitely more enjoyable.
"Paying the bills", on the other hand, actually took a lot of money (and I had a laughably small mortgage and two people sharing it at the time).
I also worked way more hours (30-40% of which were unpaid because yay fine dining), and it was physically way more brutal.
But then again, almost 10 years later, I'm back to the idea of opening a place of my own because the current tech landscape really doesn't attract me at all anymore and I can't get myself to last in it.
No one is claiming that any of the alternatives are better jobs than software engineering has been for the last 20 years.
We don't live in the last 20 years anymore and software engineering is either becoming a different (worse) job or simply vanishing.
But it’s necessary to get confirmation against the hope that the grass is indeed not greener on the other side.
If you don't like the grass where you are, maybe the question of whether it's really greener somewhere else doesn't matter.
Maybe you need to change pasture no matter what.
The software engineering grass is getting really brown really fast. The grass on the other side will be greener (not green, greener) soon.
Yes and especially with new developments, like "$Framework now has Signals!", my thought is "I don't really care since in some years, it won't matter anyways". I don't see how I can build this lower level knowledge by almost never actually using it. I don't even want to think about job-interviews after a year+ of vibing and then being asked how RxJS works.
I'm preparing mentally for my day-job to stop being fun (it still beats most other occupations I guess), and keep my side/hobby-projects strictly AI-free, to keep my sanity and prevent athropy.
I just hope we'll get out of this weird limbo at some time, where AI is too good to ignore, but too unreliable to be left alone. I don't want to deal with two pressures at work.
I feel the opposite. I get to sit down and think about problems, expressing them in words as best I can, and then review the code, make sure that I understand it and it works as it should, all in a fraction of the time it used to take me. I like that I don't have to google APIs as much as I did before, and instead I can get a working thing much faster.
I can focus on actually solving problems rather than on writing clever and/or cute-looking code, which ironically also gives me more time later to over-optimize stuff at my leisure.
I feel this way with some of the work I've pushed through an LLM, but part of the time I'm left wondering what kind of Mickey Mouse problems people are working on where they are able to form up tidy English descriptions in complicated domains to capture what they're trying to achieve.
If I have a clear idea of some algorithm I am trying to write, I have a concise method for expressing it already, and it ain't English.
I suppose the other thing I would say is that reading code and understanding is definitely not the same as writing code and understanding it in terms of depth of understanding, and I think this notion that reviewing the outputs ought to be enough fails to capture the depth of understanding that comes with actually crafting it. You may not think this matters, but I'm pretty sure it does.
I just wish AI made compilers smarter in a provably correct way instead of a lame attempt at making programmers smarter.
I want tools that are smarter, but still 100% correct at what they do.
Any tools/languages that address this gap?
Something I really appreciate about LLMs is that they make a whole bunch of much more sophisticated reliable tooling acceptable to me.
I've always been fascinated by AST traversal and advanced refactoring tools - things like tree-sitter or Facebooks's old codemod system https://github.com/facebookarchive/codemod
I never used them, because the learning curve in them was steep enough that I never found the time to climb it to the point that I could start solving problems.
Modern LLMs know all of these tools, which flattens that curve for me - I find it much easier to learn something like that if I can start from semi-working examples directly applicable to what I'm trying to do.
I have a relative who's in her 70s and used to be a coder. She told me she gave up coding when people introduced computers with terminals. She was used to filling out punch cards and felt like the way she worked, although constantly evolving, was something she could keep up with. When the new stuff came, with virtual programs and you just typing on a computer and no way to properly debug by shuffling the cards around, she ended up moving to something completely different...
I’m sorry you feel that way but that’s a surprising experience, I find flow states easier managing agents than actually coding. Each of course, to their own. Is it possible you were reaching the end of your tether anyway in the coding space? Feel free to slap that accusation down if it’s unfair.
Don't worry about it. Don't let anyone else tell you how best to use AI, use AI in a way that suits YOU, then it is so much fun. I would go crazy if I had multiple streams simultaneously working on stuff that need constant supervision (that would be different if I could trust they do 100% what I intend them to do), but AI is still very helpful in other ways (research, exploration, and writing tests).
This line really hit me. I used to think that mastering one advanced skill would be enough to rely on for life, but it seems that’s no longer the case.
I wonder how this will affect the burnout rate among IT workers in the long-term, which already was quite high. I guess a lot of people force themselves (or are forced to by their company) to use LLM in fear of being left behind, even if they don't enjoy the process, but sooner or later the fatigue will catch up.
> It makes me want to move into something completely different like sales
Aaand that's startup founder life :)
Intense multitasking, needing to accept a lower engineering quality bar, and ignoring scale problems because you don't know if anyone will actually buy the thing you're building yet.
Engineering something that you know you'll redo in 1 month is very different from engineering something that you intend to last for 5+ years, but it's still a fun challenge picking the right tradeoffs and working under different constraints.
it's taken programming from being fully waiting on compilations to being incrementally compiled and productive back to waiting on the compiler all over again.
The experience you have is something most youngsters won't ever get, because they won't have the time. You've become more valuable than you used to be, because you know exactly what works when and what doesn't. The hard part is being able to find the joy in making agents do what you want achieved instead of building it yourself. I think it actually isn't too hard once you get up to speed with managing multiple agents - efficiently juggling them feels like an art performance sometimes.
This is going to sound harsh, but welcome to the real world, I guess. Being in IT is pretty much the only job I know of today that is stable, pays well, is enjoyable, feels like it affects the world, personally engaging and challenging, etc. Being not in IT (it's just a hobby of mine) your comment sounds like "Well I had absolutely everything, and I still do but now it's not as fun anymore!"
Sales isn’t easy either!
Well-put. Sw eng is so much better, assuming you are comfortable in the role, for types who want to punch a clock doing something they don't hate.
Sales is the definition of high-pressure, and your output is always threatened by forces beyond your control. It doesn't consistently reward intelligence or any particular skill other than hustle.
There's nothing like sw dev that lets you sit at your desk and ignore the outside world while getting paid for delivering biz-critical milestones. Even creatives don't have this kind of potential autonomy.
At least you (or your employer) won't have to pay a shit ton of money for AI subscriptions so you remain productive after the AI bubble bursts.
to me genAI feels like a neural implanted exoskeleton.
it does awesome in demos. it has a real use.
but
it gets a long training period when one makes mistakes with it, it is big mistakes that take long to fix
Honestly based on what you've written I don't think you would enjoy sales any more
[flagged]
https://news.ycombinator.com/newsguidelines.html
An exemplary technofascist slogan.
It is just a new way of coding. And indeed what the blog post said, if you are experienced, you will benefit the most as the AI agent will make similar mistakes as a junior and you will be able to recognize them.
But indeed, the fun part of coding a couple of routines is gone. That is history.
Around the time GPT-4 was released in early 2023, a similar issue arose with another profession: translation. It was at that point that machine translation between languages like English and Japanese (the language pair I have worked with) started to approach human level for the first time.
I took part in a lot of discussions then with other professional translators, and the reaction of many was similar to that of some of the commenters here: not only were they discouraged because their hard-earned language and translation skills no longer seemed needed, but using LLMs as assistants took the enjoyable challenge out of the translation process.
Nearly everyone I spoke with then worked from home as a freelancer, carefully crafting one translation at a time. They didn’t like the idea of becoming managers of large-scale translation projects, even if it meant they would be able to apply their higher-order intercultural communication skills.
I do only a little professional translation myself now, but I try to keep up with AI developments and I often use translation tasks to test the latest models and frameworks. Over the past few months, I have vibe-coded some multi-LLM translation systems where texts were passed through multiple models that checked, critiqued, and improved each other’s translations. For the texts I tried them on, the results were much better than any single-LLM translation, approaching the level of the very best human translation. The API calls weren’t cheap, but for high-stakes translations such a system would more than pay for itself.
When designing that “vibe translation” system, I did apply my experience as a translator, similarly to what Simon is recommending programmers do now with vibe engineering. At this stage in my life (I’m sixty-eight), I am fine with that. But if LLMs had arrived when I was, say, just five or ten years into my translation career and still proud of my nuts-and-bolts skills, I might very well have looked for another career rather than becoming a vibe translator.
Translation is great to discuss LLMs. Thanks for sharing your experience.
On one side translation is not very valued by most people. It is rare that people know who translated a book, for example. It is a pity but people do not read much these days.
Additionally, or maybe because of the above, translation is often paid in terms of number of lines or words, even before AI. A bit like software security, it is often sadly just a check at the end.
IMHO the only future-proof translation fields are legal (because a human can be put in prison or pay a fine) or live translation/interpretation (because a human can go in front of people, meet them at an event, etc.).
> It is a pity but people do not read much these days.
This is a common belief, but it's just not true. The book industry is healthier than ever.
There have been study results published quite recently that suggested otherwise, at least for the U.S.
While I don't recall the actual numbers, the number of people who said they read books pretty much crashed over the past two decades, and more parts of the population are considered to be functionally illiterate than in a long time.
I spoke with some professional translators early on and they were just in denial, getting even upset at the idea that an AI could replace them. I didn't push too much but felt bad for them, as they couldn't realize what was going to happen to their field. I really think that translation must be the most impacted field by AI.
Software engineers are the translators. We (as a metaphorical community are in denial). Read the 100s of comments on this post: either (AI code is wrong or this isn’t correct or it’s not effective or some other justification). At the end of the day it’s really hard to accept the change.
> Software engineers are the translators.
True, recently I started feeling that part of what I had been doing is simply translating natural language to programming languages. Though coding also involves things such as algorithm and data structures, context and background knowledge, but these can all be done in natural language. Once the natural language description is given, what remains is only translation. LLMs have good knowledge of almost anything, though they are currently weak on inference or derivation, but this already makes them good on the two end of software engineering -- context knowledge and translation.
I understand those people who hate LLMs for coding, I partly share the feeling, because I enjoy typing on a keyboard, editing part of the code, reading the characters, I am an Emacs user. If LLMs can do the work, even if just save the typing and editing part, some of the fun has been eliminated for me.
Think about chess and Go, though AI can easily beats human now, people are still playing it. For programming, if one day AI can do 80% of the programming work, I guess only few of programmers today can keep doing it as a job. Just like few people can play chess and Go as their job.
I don't think that's a fair characterisation. I gave these tools the benefit of the doubt and many genuine tries, and still do occasionally. My judgment that they're unfit for the task is based on finding that they objectively don't help me work. There are studies showing that LLM use slows experienced developers down, even as they believe the opposite. I used to be the only one in my immediate work environment who thought LLMs are of jack use in my development work. Over the past year, most devs who used LLMs heavily have now switched over to my view.
Translation is natural language in, natural language out. That has very little to do with programming. Dijkstra knew back in the 70s that the very concept of natural language programming was bullshit, and that fancy new tech is never going to change the fundamental issues with the idea. In my opinion, his argument is as valid as ever.
Edit: I wasn't trying to imply that natural to natural language translation is trivial. The best LLM tools can be pretty shit at that even today, too. Tried using localised Microsoft developer documentation lately. It's unintelligible.
This is a really great comparison to draw. This actually made me think that this feeling of going from mastering a craft to working on large scale systems is probably how someone who was passionate about cars felt when they went from building cars one by one, knowing how the whole machine works to then having to take a job on an assembly line.
Fortunately I think anything pertaining to vibe coding/engineering/analytics is still more enjoyable and less grim than working on an assembly line, but the human feelings remain nonetheless.
A better term is agentic coding, agentic software engineering, etc. rather than being vibe based.
My process starts from a Claude Code plan, whose first step is to write a spec. I use TDD, and enforce my "unspoken rules of code quality" using a slew of generated tools. One tiny tool blocks code which violates our design system. Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer. Watching the transcript I have to occasionally remind the model to use TDD, but once it's been reminded it doesn't need reminding again until compaction. Claude 4.5 is far better at remembering to do TDD than 4.1 was.
Code reviews are super simple with TDD due to the tests mirroring the code. I also create a simple tool which hands the PR and spec to Gemini and has it describe any discrepancies: extra stuff, incorrect stuff, or missing stuff. It's been great as a backup.
But ultimately there's no substitute for knowing what you want, and knowing how to recognize when the agent is deviating from that.
The opposite of "garbage-in garbage-out" is quality in => quality out.
I spent some time trying to think of a better term because I also think "vibe" detracts from the intent, and I think you nailed it with "agentic coding". Ill do my part by using that term now, hopefully it catches on : D
I was writing up some recommendations to my team for using Github Copilot in its different modes + Roo Code/Cline and tried so hard to avoid using “vibe coding” in a professional context. For sake of clarity I ended up including it once in a “you may have heard the term…” style reference but it just comes across as so deeply unserious and felt ridiculous being forced to use it at all.
I also landed on “agentic coding” FWIW. It’s a bit clunky but didn’t feel like an embarrassment to the entire software industry typing it so I’ll happily use it over the alternative.
> Another tool blocks code which violates our separation of layering - this forces the HTTP route handler code to only access the database via service layer.
Is that an llm agent or some other type of tool (e.g. language service or build toolset)?
When I say "tool" I really mean a python script. This particular one is ~100 lines of python with a main() method, that Claude Code wrote in a single shot, that I then committed to the repo in a scripts/ directory. That lets me include it in pre-commit hooks, run it when I run the tests, and have it run during CI.
A 100 line script finishes in milliseconds and burns no tokens. So you can run it hundreds of times per day.
The mindset is: will you need repeatability? If so, have the LLM write code, because code gives you determinism.
> remind the model to use TDD
I don't know how vibe coding works, but how does this work - is the agent actually engaging in the red-green-refactor loop, or does it just generate the result all at once?
if you ask it to, claude code can definitely write tests, then write code, then try to modify one or the other to make them pass in a loop, yes.
if you don't ask, it's much more likely to just one shot the whole thing, and may or may not get it right first time.
I agree, “vibe” continues the idea of “going on vibes” rather than facts. This form of engineering is scrupulous and complete. It doesn’t fit.
> A better term is agentic coding, agentic software engineering, etc. rather than being vibe based.
I prefer slop-coding.
+1
I don't get the obsession some tech people have to push the idea that this stuff accelerate your coding, increase your productivity. It's all about fast and faster output. In my experience LLMs have mostly produced gibberish oververbose code, surely faster than me, but my lower speed usually produce better code. I don't like this present state of things where we need to chat faster to quickly get out results and go fast in production... that is the kind of mentality that pushed subpar products on the web for so many years. Instead of dropping names lile vibe coding/engineering whatever comes next, let's have a serious discussion why we need faster low quality and we can't just improve automation and processes. Eg I can get unit test generated very fast sure, but my question is: why do we need all these unit tests in the first place? Dont get me wrong they're useful, but I feel like we're advancing higher abstraction instead of advancing lower level tools
> that is the kind of mentality that pushed subpar products on the web for so many years
Famously, some of those subpar products are now household names who were able to stake out their place in the market because of their ability to move quickly and iterate. Had they prioritized long-maintainable code quality rather than user journey, it's possible they wouldn't be where they are today.
"Move fast and break things" wasn't a joke; Mark really did encourage people to build faster and it helped cement their positioning. Think of the quantity of features FB shoveled out between 2009-2014 or so, that just wouldn't have been possible if their primary objective was flawless code.
The code isn't the product, the product is the product. In all my years of engineering I've yet to have an end-user tell me they liked my coding style, they've always been more concerned with what I'd built them.
Facebook didn't solved any real problem, "Move fast and break things" is for investors not hackers.
Famously gmail was very good quality web app and code(can't say the same today) surely not the product of today's "fast iteration" culture
Meta has a 1.79T market cap, they definitely solved some very real problems to get there.
There are lots of companies doing well producing high quality products out of the gate today though, look at Linear.
Both approaches are valid for building sustainable enduring businesses.
> Meta has a 1.79T market cap, they definitely solved some very real problems to get there.
Sure exploiting human attention to sell them ads, it's not technological marvel, I'd say psychological
Running a platform where billions of users are able to communicate is pretty technologically marvel.
Lest not forget when Hotz said he could easily fix Twitter's search functionality only to give up after 3 months [1]. When immensen scale is involved things do become difficult.
Like we have a comment below taking a shot at Phillip Morris [2]. Lets see you grow, process, and distribute 1/100 the quality of cigarettes. The end product might not be that great for society but it's not trivial to do it either.
[1]: https://www.theverge.com/2022/11/22/23472869/george-hotz-twi...
[2]: https://news.ycombinator.com/item?id=45516831
Pretty negative take, TV and Radio also exploit human attention in your book?
Technology wise they created React, PyTorch, GraphQL and Llama is open weights.
Being part of a oligopoly has its perks.
Phillip Morris has a 238B market cap. What problems are they solving?
Withdrawal symptoms :P The buyer decides whether their problem is a good one to have and whether the solution is adequate. Even when it's, objectively, not.
Earlier than that, Facebook became ascendent because of quality. It was better than MySpace, the only real competitor at the time. The issue here is Facebook is not primarily a software product. It's a community, and the community was better than MySpace because it was restricted to pre-existing networks rather than taking any comer. I don't think Mark did that on purpose as a calculated decision. He just got lucky. When they eventually opened up and became just as shitty as MySpace had been, they were big enough to simply acquire better products that might have been competitors, and network effects locked them in for probably decades until their users die off and don't get replaced by younger people who never used Facebook.
I don't really see it as an example of what you're saying so much as an example of success as a product having to do with far more than explicit product features. You can see a similar dynamic in other natural monopoly markets. The NBA didn't necessarily do anything particularly right product wise, for instance. They just got the best players because basketball was historically more popular in the US than other countries, and the ABA made some stupid decisions that let the NBA win out in the US.
Hell, the US itself didn't do a whole lot "right" aside from not being in Europe when Europe decided to destroy itself, being better-positioned than other potential competitors like Canada, Mexico, and Australia simply because North America is best positioned to trade with both Europe and Asia and the US is more temperate than Canada or Mexico. But we sure like to tell ourselves stories about everything we did right.
Quality of product - Not quality of coding.
Yes, both impact each other, and if facebook was just shoddily coupled together it probably wouldn't be a great product, but so many engineers get into this mindset of needing finely tuned clean code vs a working product.
When people were switching, how many decided to use facebook because the coding style of the backend was really clean and had good isomorphism?
There's a balance with this, but so much of it's success was being at the right place at the right time, and if you spend a massive amunt of time not building product and just building good code, you're going to hit a failure.
Total side note, it's interesting seeing "Move fast and break things" become the dominant phrase vs what I remember initially as the "MIT vs New Jersey methods". Both describe the same thing where fast and sloppy wins vs slow and clean.
I think the general issue with software engineering discourse is that while our tools and languages may be the same, there's a massive gradient in tolerance for incorrectness, security, compliance, maintainability.
Some of us are building prototypes, and others are building software with a 10 year horizon or work with sensitive personal data.
So on the one side you get people that are super efficient cranking things out, and others that read this and feel appalled anyone would be comfortable with this and see software engineering as theory building. Neither are really wrong here, but the context / risk of what people are working on always seems to be missing when people talk about this.
I have yet to see in my life a prototypes that doesn't become production :) Btw my whole point wasn't on security and can't find a compelling reason to talk about it, it rather questions "faster results" as "better productivity" it isn't, and imo we should pause for a moment and focus on better tooling
We live in an objective reality. LLM's help a damn lot in speed of development. As someone who has been coding since 5th grade for over 20 years who is known to be a LIGHTNING FAST implementor by many people I have been scaled ridiculously with LLM's. Genie is out of the bag, you have to go with the flow, adapt or else....
I am just as pissed as anybody else at the lack of certainty in the future.... Thought I had my career made. So it's not that I don't emphatize with engineers in my shoes.
Good lord I wish I could have as many certainties as well, one point at a time:
* There is no objective reality, there isn't one in physics, it's just a non argument * "LLM's help a damn lot in speed of development" That may be your experience and my whole point was arguing that speed may not matter * "Genie is out of the bag, you have to go with the flow, adapt or else" I choose else if this the apex of the argument
I'm genuinely baffled by the assertion that there isn't objective reality.
If you go down in physics you might discover that the reality seems to be composed a lot more by probabilities. An objective reality built on probabilities does not seem so objective afterall.
Here is a fun think to try: demonstrate that you and me are seeing the same color in the same way? You might find some papers trying to prove it but you will se they are all based on subjective answers of people.
So while at macro level the reality seems hard and objective at the micro level it is not.
It's an objective reality. Even at quantum level the known laws of nature hold. Even if there is uncertainty, nature is predictable in following the laws of physics.
And ofc at macro level we live in a very objective reality. This is the basis of science.
[dead]
> why do we need all these unit tests in the first place?
The same reason we've always needed them:
1: They prevent regressions. (IE, bugs in features that were shipped and already working.)
2: They are very easy to run at the push of a button in your IDE. (But in this context the LLM runs them.)
3: They run in CI. This is an important line of defense in making sure a pull request doesn't introduce a bug.
Now, depending on what you're writing, you might not need unit tests! Perhaps you're trying to get a minimum viable product out the door? Perhaps you're trying to demo a feature to see if it's worth building? Perhaps you're writing a 1-off tool that you'll run a few times and throw away?
But, understand that if you're writing an industrial-strength program, your unit tests help you ship bug-free software. They allow you to do some rather major refactors, sometimes touching areas of the codebase that you only lightly understand, without needing to manually test everything.
(And, to keep it in context,) your LLM will also have the same benefits from this tired-and-true process.
Thanks for the non solicited lesson, I learned basically nothing new. That unit tests ships bug free software is such an overstatement... Btw please go re read my comment and try to understand what I was actually trying to argue about, and I also wrote that I think they can be useful...
You aren’t entertaining the possibility that some experienced engineerings are using these tools to produce incredibly high quality code, while still massively increasing productivity. With good prompting and “vibe engineering” practices, I can assure you: the code I get Claude Code to produce is top notch.
I'm experienced, I don't accept the implication that I might not be able to use these tools are their full potential and you won't convince me only because you mention an anecdotical example
You must be very confident in your own ability if you think you can use any tool to its full potential with no scope for getting better.
I have tools I've been using for 25 years that I still think I could be using better.
Absolutely but we're talking about structured tools, like a cli, not unstructured non deterministic "agents" that fails to give the same answer twice, ls -la doesn't lie
You also must be very confident in your own ability if you don’t think that at least some of the things you’re doing that you’d classify as “skill at using the tool” aren’t just superstitions à la Skinner’s pigeons.
I'm sure a lot of them are superstitions! I've written about that before: https://simonwillison.net/2023/Aug/27/wordcamp-llms/#superst...
One of the more "engineering" like skills in using this stuff is methodically figuring out what's a superstition and what actually works.
Nice to see that you recognize that!
> One of the more "engineering" like skills in using this stuff is methodically figuring out what's a superstition and what actually works.
The problem is there are so many variables and the system is so chaotic that this is a nearly impossible task for things that don’t have an absolutely enormous effect size.
For most things you’re testing, you need to run the experiment many many times to get any kind is statistically significant result, which rules out manual review.
And since we have tried and failed to develop objective code quality metrics, you’re left with metrics like “does this pass the automated test or not!”, but that doesn’t tell you whether the code is any good, or whether it is overfitting the test suite. Then when a new model comes out, you have to scrap your results and run your experiments all over. This is engineering of the laws of physics were constantly changing, and I lived in that universe, I think I’d take my ball and go home.
There's always been a bit of magic to being a programmer, and if you look at the cover of SICP people like to imagine that they are wizards or alchemists. But "vibe engineering" moves that to a whole new level. You're a wizard mixing up gunpowder and sacrificing chickens to fire spirits before you light it. It's not engineering because unless the models fundamentally change you'll never be able to really sort the science from the superstition. Software engineering already had too much superstition for my taste, but we're at a whole new level now.
Here's an example from today of something I just figured out.
I had Claude Code do some work which I pushed as a branch to GitHub. Then I opened a PR so I could more easily review it and added a bunch of notes and comments there.
On a hunch, I pasted the URL to that PR into Claude Code and said "use the GitHub API to fetch the notes on this PR"...
... and it did exactly that. It guesses the API URL, fetched the JSON and read my notes back to me.
I told it to address each note in turn and commit the result. It did.
If a future model changes such that it can no longer correctly guess the URL to fetch JSON notes for a GitHub PR I'll notice when this trick fails. For the moment it's something I get to tuck in my ever expanding list of things that Claude (and likely other good models) can do.
Since you are convinced you’re using the tools to their full potential, the quality problem you experience is 100% the tools fault. This means there is no possible change in your own behavior that would yield better results. This is one of those beliefs that is self fulfilling.
I’ve found it much more useful in life to always assume I’m not doing something to its full potential.
Have you used the tools to their full potential?
Another non existing argument, if the agent fails to give the same answer twice i can't even explore his full potential
Hope you've never tried training a dog!
Another void argument, we're speaking about tools, dogs are not tools
Yes they are. Guide dogs, hunting dogs, sheep dogs. The comparison to LLMs is genuinely useful here, because dogs are unreliable tools that you have to work with over a period of time to figure out.
I've used this argument for real in the past with people who complain that it's unethical to set sightless people up with vision LLM tools because those tools are unreliable and make mistakes. My counter is that a) so are guide dogs and b) it's rude to discount the agency of people with accessibility needs in evaluating and selecting tools for themselves.
You can 100% use dogs as tools as we've done for thousands of years.
You see a large % of failures, but you're drawing an unsupported conclusion.
We all agree, the people that _feel_ the most productivity spike are the sub-par engineers. That shouldn't be controversial, and it's even predictable. But their volume can't be taken as an argument one way or the other.
The question is, are there _any_ good engineers that don't just feel more productive, but objectively are.
People are constantly looking for definite tendencies and magic patterns so they can abdicate situational awareness and critical thinking. We observe that fast delivery has often correlated with success in software and we infer that fast delivery is a factor of success. Then it becomes about the mindless pursuit of the measure, speed of delivery, as Goodhart's law predicts.
Let's even concede that speed of delivery indeed is an actual factor, there has to be a threshold. There's a point where people just don't care how fast you're putting out features, because your product has found its sweet spot and is perfectly scratching its market's itch. A few will clearly notice when the line of diminishing returns is crossed and if they can reset their outlook to fit the new context, a continuous focus on speed of delivery will look increasingly obsessive and nonsensical.
But that's the reality of the majority of the software development world. Few of us work on anything mission critical. We could produce nice sane software at a reasonable pace with decent output, but we're sold the idea that there's always more productivity to squeeze and we're told that we really really want that juice.
That all things develop only so much before they degrade into overdevelopment was a very well understood phenomenon for ancient Taoists, and it will be the death of the modern Blackrock/Vanguard owned world which is absolutely ignorant of this principle.
It’ll be the greatest episode of sunk cost fallacy 5 years from now.
I'll attempt to provide a reasonable argument for why speed of delivery is the most important thing in software development. I'll concede that I don't know if the below is true, and haven't conducted formal experiments, and have no real-world data to back up the claims, nor even define all the terms in the argument beyond generally accepted terminology. The premise of the argument therefore may be incorrect.
Trivial software is software for which
- the value of which the software solution is widely accepted and widely known in practice and
- formal verification exists and is possible to automate or
- only has a single satisfying possible implementation.
Most software is non-trivial.
There will always be:
- bugs in implementation
- missed requirements
- leaky abstractions
- incorrect features with no user or business value
- problems with integration
- problems with performance
- security problems
- complexity problems
- maintenance problems
in any non-trivial software no matter how "good" the engineer producing the code is or how "good" the code is.
These problems are surfaced and reduced to lie within acceptable operational tolerances via iterative development. It doesn't matter how formal our specifications are or how rigorous our verification procedures are if they are validated against an incorrect model of the problem we are attempting to solve with the software we write.
These problems can only be discovered through iterative acceptance testing, experimentation, and active use, maintenance, and constructive feedback on the quality of the software we write.
This means that the overall quality of any non-trivial software is dominated by the total number of quality feedback loops executed during its lifetime. The number of feedback loops during the software's lifetime are bound by the time it takes to complete a single synchchronous feedback loop. Multiple feedback loops may be executed in parallel, but Amdahl's law holds for overall delivery.
Therefore, time to delivery is the dominant factor to consider in order to produce valuable software products.
Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.
>> Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity.
I'll reply just to that as it being the tldr. First of all tech debt is a thing and it's the thing that accumulates mostly thanks to fast feedback iterations. And in my experience the better the comunication, to get the implementation right, and the better the implementation and it happens that you can have solid features that you'll unlikely ever touch again, user base habit is also a thing, continuing on interating on something a user knows how to use and changing it is a bad thing. I'd also argue it's bad product/project management. But my whole original argument was why we'd need to have a greater speed in the first place, better tooling doesn't necessarily means faster output, productivity as well isn't measured as just faster output. Let me make a concrete example, if you ask an LLM X to produce a UI with some features, most of them will default to using React, why? Why can't we question the current state of web instead of continue to pile up abstractions over abstractions? Even if I ask the LLM to create a vanilla web app with HTML, why can't we have better tooling for sharing apps over the internet? The web is stagnant and instead of fixing it we're building castles over castles over it
Tech debt doesn't accrue because of fast feedback iterations. Tech debt accrues because it isn't paid down or is unrecognized during review. And like all working code, addressing it has a cost in terms of effort and verification. When the cost is too great, nobody is willing to pay it. So it accrues.
There aren't many features that you'll never touch again. There are some, but they usually don't really reach that stage before they are retired. Things like curl, emacs, and ethernet adapters still exist and are still under active development after existing for decades. Sure, maybe the one driver for an ethernet adapter that is no longer manufactured isn't very active, but adding support for os upgrades still requires maintenance. New protocols, encryption libraries and security patches have to be added to curl. emacs has to be specially maintained for the latest OSX and windows versions. Maintenance occurs in most living features.
Tools exist to produce extra productivity. Compilers are a tool so that we don't have to write assembly. High-level interpreted languages are a tool so we don't have to write ports for every system. Tools themselves are abstractions.
Software is abstractions all the way down. Everything is a stack on everything else. Including, even, the hardware. Many are old, tried and true abstractions, but there are dozens of layers between the text editor we enter our code into and the hardware that executes it. Most of the time we accept this, unless one of the layers break. Most of the time they don't, but that is the result of decades of management and maintenance, and efforts sometimes measured in huge numbers of working hours by dozens of people.
A person can write a rudimentary web browser. A person cannot write chrome with all its features today. The effort to do so would be too great to finish. In addition, if finished, it would provide little value to the market, because the original chrome would still exist and have gained new features and maintenance patches that improve its behavior from the divergent clone the hypothetical engineer created.
LLMs output react because react dominates their training data. You have to reject their plan and force them to choose your preferred architecture when they attempt to generate what you ask, but in a different way.
We can have better tooling for sharing apps than the web. First, it needs to be built. This takes effort, iteration, and time.
Second, it needs to be marketed and gain adoption. At one time, Netflix and the <blink> tag it implented dominated the web. Now it is a historical footnote.Massive migrations and adoptions happen.
Build the world you want to work in. And use the tools you think make you more productive. Measure those against new tools that come along, and adopt the ones that are better. That's all you can do.
I work at a FAANG adjacent company as an EM and the 4x engineers who’ve recently been PIPd all went off the deep end using agents to write huge amounts of convoluted or unsuitable code.
One of them has decades of experience coding and even devised our onboarding training for using Cursor and Bedrock at the company but they too were called out for building a wholly unsuitable and unmaintainable service which could have been more simply solved with some common libraries and Docker micro services rather than 10k+ lines of custom code.
We all receive a copy of Cursor and IntelliJ + Copilot on joining and I just keep seeing engineers (surprisingly the more experienced ones so far) footgunning themselves with these tools.
When pigeons are offered random rewards from a treat dispenser, they start doing all kinds of funny little dances and movements because they think the rewards are in response to their actions.
Funny dances like "writing tests" and "planning"
Robot, you must follow the rules of the house!
It is imperative that you do not kill me when delivering my breakfast!
You must not make your own doors by punching holes in the wall!
It is critical that you remember that humans cannot regrow limbs!
“You’re absolutely right…”
This is my favorite thing about this whole situation. I spend years trying to get teams to follow best practices. And then suddenly if you follow them the LLM is more effective so now they follow them ignoring that they could have been more effective this whole time.
Or daily standups.
I don’t know what you’re trying to imply here but it sounds very strongly like it is put in bad faith.
I’m critiquing the term “vibe engineering” by highlighting that because of the random, chaotic, black box nature of LLMs it is very difficult to distinguish valid techniques from superstitions.
Thus what you are doing is closer to pigeons bobbing their heads to attempt to influence the random reward machine than it is to engineering.
For example saying things like “It is critical that you don’t delete working code” might actually be a valid general technique, or it might have just been something that appeared to work because of randomness, or it might be something that is needed for current models but won’t be necessary in a few months.
The nature of LLMs makes correctly identifying superstition nearly impossible. And the speed with which new models are released makes trying to do so akin to doing physics in a universe where the laws of nature are constantly changing.
You’re an alchemist mixing gunpowder and sacrificing chickens to fire spirits, not an engineer, and for the foreseeable future you have no hope of becoming an engineer.
I’m also highlighting the insanely addictive nature of random rewards.
See this is where I think I fundamentally disagree. It’s more like being a scientist who takes 10 rats and tries to train them to sniff out TB, and once they find one that can do it reliably, they go and do real work with it. Just because the rat is the one doing the sniffing doesn’t mean the scientists aren’t real scientists. And just because we work with a tool that isn’t perfectly reliable doesn’t make us any less engineers as long as we manage and take ownership of the output as we alter and massage it from the machine. Imagine back in the day calling devs that didn’t write in assembly “alchemists” because they didn’t fully understand how a compiler works and just trusted it instead. As long as they’re reading the code, testing the logic, and working towards an outcome they take ownership of, they’re engineers, and so are people who use LLM’s. It’s dangerously close to elitism gatekeeping to say otherwise.
Also I’ve been a software engineer for 15 years so I think I don’t “have no hope of becoming a software engineer”, no personal attacks please.
Ahhh you mean cargo culting!
Yeah it’s definitely cargo culting!
Except it’s definitely not, a cargo cult is necessarily ending up with a result that doesn’t function. Whether you dislike it or not this is a real technique that produces real functioning results.
gotta source or two? it's an ungooglable topic due to "see pigeon do funny dance" social media spam
Google Skinner Pigeons.
“One bird was conditioned to turn counter-clockwise about the cage, making two or three turns between reinforcements. Another repeatedly thrust its head into one of the upper corners of the cage. A third developed a 'tossing' response, as if placing its head beneath an invisible bar and lifting it repeatedly. Two birds developed a pendulum motion of the head and body, in which the head was extended forward and swung from right to left with a sharp movement followed by a somewhat slower return.”
“The experiment might be said to demonstrate a sort of superstition. The bird behaves as if there were a causal relation between its behavior and the presentation of food, although such a relation is lacking.”
https://en.wikipedia.org/wiki/B._F._Skinner
[flagged]
I think we should just accept that vibe-coding has now semantically shifted to mean all AI-assisted coding. Actually, it makes sense to me even when a human is interacting directly with the code, because it feels a lot like pair-programming. As such, I really am "vibing" with the AI.
But then the original meaning of vibe-coding -- as in, "Take the wheel, LLama of God" -- does need a new term, because that will also be a lasting phenomenon. I propose "Yolo-Coding" -- It fits in nicely with the progression of No-Code, Low-Code, Yolo-Code.
Disagree, I think vibe coders should become synonymous with no-code and continue to be somewhat of a pejorative.
I don't like the term vibe engineer, but do agree there needs to be a term to signifiy the difference.
It's also possible in the future just being called a developer/engineer already implies you use coding agents and the people who do it "by hand" will not be the norm.
Seems you can't go anywhere these days without walking into an argument between a descriptivist and a prescriptivist.
Yes, it's not like the ole days when nobody argued semantics
Doesn’t need to be a pejorative. Just a different category. Unless you require your daily dose of feeling superior to others of course
At $enterprise, we were just looking for a proper term that sets "responsible vibing" apart from "YOLO vibe coding". We landed on "agent assisted coding".
It's a bit more technical. And it has a three-letter acronym. Gotta have a three letter acronym.
I like "YOLO vibe coding" or maybe "YOLO vibing" for short, if the context is clear :-)
Hmm another idea is "extreme vibe coding" as opposed to "extreme programming",
but those who did "extreme vibe coding" wouldn't know what it meant
AAC / Agent Assisted Coding is a good term.
> AAC / Agent Assisted Coding is a good term.
Yes, please don't push "vibe engineering" to mean how you defined it in your blog post. To me, it means exactly the opposite.
I see "vibe" as pejorative. Adding "engineering" does not elevate it from "vibe coding", as I think is your intention in the post, it just shifts "vibe" term to a different domain.
To me, "vibe engineering" means using LLM to develop "design" with no care as to its validity just like "vibe coding" means for "code".
"Agentic xyz" or "Agent assisted xyz" is more fitting.
FWIW, I do not see "vibe" as always pejorative, rather it depends on goals. When quick results and not long term quality matter, "vibing" is a legit tactic.
Anyways, just my interpretations. Please, keep up the good work. Remember, the two hardest things in software are naming, cache invalidation and off-by-one errors. It's good you continue to tackle the zeroth one.
A2C?
I really like "agent assisted coding". I think the word "vibe" is gonna always swing in a yolo direction, so having different words is helpful for differentiating fundamentally different applications of the same agentic coding tools.
abbreviation ass.coding.
Wasn't the original meaning of "vibe coding", as posted by Ilya Sutskever on twitter, that you just feed the model prompts and blindly run whatever results you get. No analysis or review, just copy/paste and hit run.
Sure, but English isn't defined by the first usage for all time or nearly all words would not mean what you think they mean right now.
(To be clear, I'm not saying the current meaning is not what you say, just that English isn't prescriptivist like this)
I made a claude slash command `/yolo` for when I just want it to do do something without further guidance, so I agree :)
> now semantically shifted to mean all AI-assisted coding.
News to me. AI-assisted coding is more auto-complete or having it trying to make sense of awful documentation.
Vibe coding to means a number of things.
- The person has no skill in understanding what the LLM wrote. - The code created hasn't been reviewed in any way to look for possible future issues. - Technical debt from the get go. - Legally your application is screwed.
For me the single killer of vibe coding is that anything the LLM creates cannot be protected/copyrighted. UK has some laws that might offer a little protection, but EU/US you are pretty much screwed.
Clanker Coding ™
What about slop-coding?
Nicely verbable too: “I vibed this out earlier” -> “Me and Claude slopped together this PR, ptal”
Nice
This is a clickbait phenomenon. People will deliberately misstate things in their headlines to get clicks and attention.
And, well, inventing new terms is also a popular way to get attention, which this author also did.
There's not point in trying to chase after shifting word meaning, if people are always going to try to shift it again.
A better term would be “Augmented Engineering” (AE).
You want something to inspire engineers to do their best work.
When you can expand your capabilities using the power of AI, then yeah, you can do your best work; hence augmented engineering.
But vibing? Not so much.
I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
I wouldn't worry too much about what to call it. Assigning a distinct label separates it from traditional engineering in a way that it assumes AI-assisted coding is only for a subset of developers. At some point the unusual approach will be writing code without any AI assistance. So the transition will leave the "vibe" behind.
Well said
Hear, hear.
I take issue with your last sentence;
> gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
Gives you access to the power to access and {mis}understand the {most repaeted over the last 1-10 years} engineering {errors, myths, misunderstandings, design flaws}, on demand, which you then can apply to your work {to further bias the dataset for future models to perpetuate the slop}.
Do NOT trust AI agents. Check their work at every level, find any source they claim to use, and check its sources to ensure that itself isn't AI too. They lie beyond their datasets, and their datasets are lying more for every minute that pass.
You're absolutely right ((:
Now, seriously though, no tools is perfect, and I agree we should not trust it blindly, but leaving aside AI Agents, LLMs are very helpful in illuminating one's path, by consulting a large body of knowledge on demand, particularly when dealing with problems which might be new to you, but which have already been tackled one way or another by other people in the industry (provided they're in the training set of course).
Yes, there's always the risk of perpetuating existing slop. But that is the risk in any human endeavor. The majority of people mostly follow practices and knowledge established by the few. How many invent new things?
To be honest, I haven't yet used AI agents, I'm mostly just using LLMs as a dialogue partner to further my own understanding and to deepen my knowledge. I think we're all still trying to figure it out how to best use it.
[dead]
> A better term would be “Augmented Engineering” (AE).
I don't think it necessarily deserves a special name. It is just engineering. You don't say book assisted engineering when you use a book as a reference. It is just engineering.
> But vibing? Not so much.
Just call it yolo engineering. Or machine outsourced irresponsible lmao engineering.
> I guess AE could also stand for Advanced Engineering, after all the AI gives you the power to access and understand the latest in engineering knowledge, on demand, which you can then apply to your work.
Oh god.
These seem like a lot of great ways to work around the limitations of LLMs. But I'm curious what people here think. Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to get it to actually do stuff. Sometimes things can go smoothly for a while, but you end up having to micromanage the output of the agent too much to bother. Or sacrifice code quality.
They're so nice for prototyping ideas and not becoming attached to the code due to sunken cost. I was playing around with generating intelligent diffs for changelogs for a game. I wasn't sure what approach to highlighting changes I wanted to take without being able to see the results.
Prior to vibe-coding, it would've been an arduous enough task that I would've done one implementation, looked at the time it took me and the output, and decided it was probably good enough. With vibe-coding, I was able to prototype three different approaches which required some heavy lifting that I really didn't want to logic out myself and get a feel for if any of the results were more compelling than others. Then I felt fine throwing away a couple of approaches because I only spent a handful of minutes getting them working rather than a couple of hours.
I agree, prototyping seems like a great use-case.
For stuff that I’m good at? Not even 10%.
For stuff that I’m bad at? Probably more than 1000%. I’ve used it to make a web app, write some shader code, and set up some rtc streaming from unreal engine to the browser. I doubt I would have done them at all otherwise tbh. I just don’t have the energy and interest to conclude that those particular ventures were good uses of my time.
Yeah I couldn't put it better myself. It's obscene how much more productive you become in new domains. And sure, you eventually hit a wall where you gotta understand it for real. But now you have a working example of your project, plus a genius who will answer unlimited questions and clarifications.
And you can do this for anything
> And you can do this for anything
Anything that's been done before. Otherwise we'd probably start with making nuclear fusion work, then head off into the stars...
You've always been able to read books. What you're talking about is skipping the slow learning step and instead generating a mashup of tons of prior art. I don't think it helps you learn. It sounds like it's for things you specifically don't want to learn.
Congrats, you now have a job similar to a factory worker turning a handle every day. Gone is that feeling of growth, that feeling of "getting it" and seeing new realms of possibility in front of you. Now all you can do is beg for more grease on your handle.
Nah. We’re literally on “hacker news”. Frankly a lot of the hacking ethos has always been cobbling stuff together building upon the works of others that you don’t really understand.
Learning by getting something to work and tweaking it is massively more effective than grinding against a wall of impassable errors while you’re just trying to get started. You don’t become a good programmer by reading a book.
Yeah, its like a GPS navigation system. Useless and annoying in home turf. Invaluable in unfamiliar territory.
Maybe it that's an apt analogy in more ways than one, given the recent research out of MIT on AI's impact on the brain, and previous findings about GPS use deteriorating navigation skills:
> The narrative synthesis presented negative associations between GPS use and performance in environmental knowledge and self-reported sense of direction measures and a positive association with wayfinding. When considering quantitative data, results revealed a negative effect of GPS use on environmental knowledge (r = −.18 [95% CI: −.28, −.08]) and sense of direction (r = −.25 [95% CI: −.39, −.12]) and a positive yet not significant effect on wayfinding (r = .07 [95% CI: −.28, .41]).
https://www.sciencedirect.com/science/article/pii/S027249442...
Keeping the analogy going: I'm worried we will soon have a world of developers who need GPS to drive literally anywhere.
I’m navigationally clueless but I don’t drive professionally
I would say I get more (I've been coding 40+ years). I get pretty good results, I find a lot has to do with crafting your prompts well. I think knowing what the outcome should be, technically, makes a big difference. It's getting less and less where I have to argue with the AI / do it myself. Not to mention the amount of little productivity / quality of life scripts I get it to create. They really smooth out a lot of things. I feel like its more heading towards "solution engineering" rather than coding where I'm getting a lot more time to think about the solution and play with different ideas.
My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
But if I give it a code example that was written by humans and ask it to explain the code, it gives pretty good explanations.
It's also good for questions like "I'm trying to accomplish complicated task XYZ that I've never done before, what should I do?", and it will give code samples that get me on the right path.
Or it'll help me debug my code and point out things I've missed.
It's like a pair programmer that's good for bouncing ideas, but I wouldn't trust it to write code unsupervised.
> My experience is it often generates code that is subtlety incorrect. And I'll waste time debugging it.
> […]
> Or it'll help me debug my code and point out things I've missed.
I made both of these statements myself and later wondered why I had never connected them.
In the beginning, I used AI a lot to help me debug my own code, mostly through ChatGPT.
Later, I started using an AI agent that generated code, but it often didn’t work perfectly. I spent a lot of time trying to steer the AI to improve the output. Sometimes it worked, but other times it was just frustrating and felt like a waste of time.
At some point, I combined these two approaches: I cleared the context, told the AI that there was some code that wasn’t working as expected, and asked it to perform a root cause analysis, starting by trying to reproduce the issue. I was very surprised by how much better the agent became at finding and eventually fixing problems when I framed the task from this different perspective.
Now, I have commands in Claude Code for this and other due diligence tasks, and it’s been a long time since I last felt like I was wasting my time.
> My experience is it often generates code that is subtlety incorrect.
Have you isolated if you're properly honing in on the right breadth of context for the planned implementation?
Aah, he must be prompting it wrong
Disingenuous reduction.
And in my experience, it always comes down to "you're holding it wrong" or "that LLM is older than 20 minutes."
You know what they say, if everyone you meet is a jerk, then...
> Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
I know it'll be touted as rhetoric but I have seen an order of magnitude of difference in my ability to ship things. Thankfully I don't work for a large enterprise so I don't have a multi-million line codebase to contend with or anything like that. I also, thankfully, ship projects using languages and libs that are very well represented in LLM corpuses, like TypeScript, NextJS, Postgres, though I have also found a lot of success in less popular things like Neo4j's Cypher.
I also have been massively enabled to do lots more 'ops' stuff. Being a pretty average full-stack eng means I have no experience of running sys/ops monitoring systems but LLMs only recently helped me with a bunch of docker-routing issues I was having, teaching me about Traefik, which I'd never heard of before.
Side-point: I have felt so grateful to these LLMs for freeing up a bunch of my brain space, enabling me to think more laterally and not relying so much on my working memory, severely limited now due to historic brain injury. Often people forget how massively enabling these tools can be for disabled people.
I can definitely see the 10% boost being accurate. Keep in mind, its not about doing everything 10% faster, its about being able to put out 10% more results by leveraging agentic coding when it makes sense.
This week I was able to tackle two long-standing bug fixes I've been noodling on and had a rough idea of what I needed to do but had competing priorities and a lack of time to sit down and really internalize the system to figure them out. I brain dumped the issue and my current thoughts and had claude formulate a plan. It solved each in less than 30 minutes of very light effort on my part. I was able to tack these onto larger work I'm doing basically seamlessly.
The other thing that I've found to be an insane benefit is filesystem-backed context switching. If your agentic workflow involves dumping your plan and progress to files in the filesystem, you can pause and restart work at any time by pointing at those files and saying "continue where you last left off". You can even take a `git diff > that-one-bug.patch` of edits made up to that point, copy that alongside the other files, and have a nice-and-neat folder of a unit of work that is ready to pick back up in the future as time permits.
Yes, most days I’m 2x as productive. I’m using Claude Code to produce extremely high quality code that closely follows my coding standards and the architecture of my app.
> Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs?
No, I just put in less effort to arrive at the same point and do no more.
I don’t think people are good at self-reporting the “boost” it gives them.
We need more empirical evidence. And historically we’re really bad at running such studies and they’re usually incredibly expensive. And the people with the money aren’t interested in engineering. They generally have other motives for allowing FUD and hype about productivity to spread.
Personally I don’t see these tools going much further than where they are now. They choke on anything that isn’t a greenfield project and consistently produce unwanted results. I don’t know what magic incantations and combinations of agents people have got set up but if that’s what they call “engineering,” these days I’m not sure that word has any meaning anymore.
Maybe these tools will get there one day but don’t go holding your breath.
> They choke on anything that isn’t a greenfield project and consistently produce unwanted results.
That was true 8 months ago. It's not true today, because of the one-two punch of modern longer-context "reasoning" models (Claude 4+, GPT-5+) and terminal-based coding agents (Claude Code, Codex CLI).
Setting those loose an an existing large project is a very different experience from previous LLM tools.
I've watched Claude Code use grep to find potential candidates for a change I want to make, then read the related code, follow back the chain of function calls, track down the relevant tests, make a quick detour to fetch the source code of a dependency directly from GitHub (by guessing the URL to the raw file) in order to confirm a detail, make the change, test the change with an ad-hoc "python -c ..." script, add a new automated test, run the tests and declare victory.
That's a different class entirely from what GPT-4o was able to do.
I think the thing people have to understand is how fast the value proposition is changing. There is a lot of conversation about "plateauing" model performance, but the actual experience from the combination of the model and tooling changes is night and day in the last 3 months. It was beginning to be very useful with Claude 3.7 in the spring this year, but we have just gone through a step function change.
I was decomissioning some code and I made the mistake of asking for an "exhaustive" analysis of the areas I needed to remove. Sonnet 4.5 took 30 minutes looking around and compiling a detailed report on exactly what needed to be removed from this very very brownfield project and after I reviewed the report, it one shot the decommisioning of the code (in this case I was using CLaude in the Cursor tooling at work). It was overkill, but impressive how well it mapped all the ramifications in the code base by greping around.
Indeed, Codex CLI is quite useful even for demanding tasks. The current problem is that it might gather context for 20 minutes before doing the actual thing. The question is whether this will be sped up significantly.
I guess we just have to take your word for this, which is somewhat odd considering most of your comments link back to some artifact of yours. Are you paid by any of these companies?
I'm not paid by any of them, but I occasionally get preview access to models or invites to events. I attended OpenAI's DevDay on Monday for free, for example.
I have a disclosures section on my blog here: https://simonwillison.net/about/#disclosures
OP is one of the co-creators of Django (for which I am eternally grateful, having built my first company on top of it) and one of the most prolific writers in the space. I also happen to strongly agree with his assessment, though as he said getting that amount of value out of current tools is real work.
It is real work, and it requires solid priors to do it. The cynical people punch three prompts in, are disappointed that it doesn't work in their codebase they've worked in for 2 decades and complain that everyone is a shill and that people should stop saying they "hold it wrong".
The skill ceiling is high, it turns out. It's just deceptive, because it's so easy to get going. Ultra accessible foot gun, lots of work to point it in the right direction reliably and repeatedly. Significant benefits of you manage though.
I've gotten more relaxed about it now though. People will either get it or they don't.
https://github.com/bodo-run/yek/pull/213
here is an example of mostly automated work. It's a small feature but it was done perfectly
That the tools do this kind of thing? They do, they’ll go through pretty long multi step processes to find things and edit them. They run tests, check output, see it’s wrong and go and add debug statements, rerun, try and fix things, rerun, then remove the logging.
All I've found is the LLM just makes me work more. It's hard to talk about % boost when you're just simply working more hours.
It's like having a faster car with a bigger engine. Big deal. I want a faster car with a smaller engine. My ideal is to actually go home and stop working at the end of the day.
I also don't want to use it for my day job because I'm afraid my brain will atrophy. You don't really need to think when something is already done for you. I don't want to become someone who can only join together LLM output. I don't feel like I'll miss out on anything by not jumping on now, but I do feel like I'll lose something.
At this point I'd say that I'm 1000% more productive in the aspects that I use it for. I rarely hit any walls, and if I do its absolutely always down to an unclear or incomplete thought progress or lack of clarity in prompting.
There's a lot of annoying stuff it can do fairly well without many guardrails. It's a minor productivity boost but it's nice not to have to do.
Doc comments for example. Today I had it generate doc comments for a class I wrote. I had to go and fix every single one of them because it did some dumb shit, but it out all the scaffolding in place and got the basics there so it was a lot quicker.
I also used it to generate json schemas from Python a couple of Python classes the other day. Highly structured inputs, highly structured output, so there wasn't much for it to fuck up. Took care of the annoying busy work I didn't want to do (not that schemas are busy work, but this particular case was).
Still haven't seen a use case that justifies the massive cost, or all the blatant theft and copy right infringement, or the damage to the environment...
LLMs have been useful for years now and people still say stuff like “but is it really useful or are all these brilliant people just deluded”…
My issue with this term is that it muddies the waters for people who are using LLMs to assist with types of engineering beyond just writing code.
I've used GPT to rapidly get up to speed with just about every aspect of circuit design, CAD, CNC... the list is long. Coding is often involved in most of these domains now, but if everything is assumed to be code-first, it leaves people who are doing different work with a constrained and apparently shrinking adjective namespace.
> My issue with this term is that it muddies the waters for people who are using LLMs to assist with types of engineering beyond just writing code.
I'm now imagining me dying as a vibe-engineered truck has a steering/brake failure and crashes into me sending flying through the vibe-engineered papier-mâché bridge guardrails, and feeling sweet sweet release as I plummet to my doom.
It's easy to confuse cynicism for humor.
Look, if you enjoy calculating a table of dozens of resistor value combinations for a feedback network that prefers reels you have on your PnP, you keep knocking yourself out.
If you're using LLMs for a large number of arithmetic calculations, you're exactly the problem GP is talking about. If you absolutely must use AI get it to generate code that will perform the calculations instead, so that you can actually verify the result.
You're straining very hard to make your position sound reasonable, but your assumption that I both can't verify the values of the winning combination and wouldn't verify those values is simply not true.
In the example I cited, verifying a ratio isn't the hard part. It's running the dozens of permutations (smart) or hundreds of permutations (naive) that an LLM can do in 90 seconds that saves me hours of boring work. It's actually so repetitive that I'm likely to have made the same kind of mistakes you're alluding to.
As always, I end with encouragement: if you want to do everything the long and hard way, I'm not here to change your mind. You will have to stop being upset that others are moving much faster than you, though. It's a choice.
> I both can't verify the values of the winning combination and wouldn't verify those values is simply not true.
You have not met my cow orkers...
Why can't it be both cynical and humorous? I personally got a good laugh from the paper-mache guardrails visualization
I did a several-month experiment using Claude as the only engineer on a real SaaS side project (Node.js/React, prod-quality, full feature ownership). My observations:
The quality of Claude’s output strongly correlates with how explicit and detailed the specs are. Markdown checklists, acceptance criteria, and clear task structure led to far fewer corrections and surprises.
Most mistakes were never “creative hallucinations” — just missed context or ambiguity in my own instructions.
The whole process felt less like delegation and more like tight collaboration. There’s less of a “flow state” and more context-switching to review/test, but review fatigue is manageable if you iterate on your instructions after each lesson.
No real learning from prior sessions, but persistent design docs and corrected example snippets in the prompts made a big difference.
Overall, a lot of the “vibe” factor gets smoothed out by rigorous process — not unlike mentoring a junior dev on a new domain.
For me, the speedup was very visible on well-scoped backend tasks and trivial CRUD/UI, and less so on broader, ambiguous work (designing APIs, coordinating many moving parts). The biggest upside: a clear process made both me and the tool better; the biggest “cost”: I spent a lot more time up front thinking through specs.
Not sure it fully scales (and I’m skeptical on agent “fleets”), but for a solo dev, given patience and a bit of PM discipline, it’s a net positive.
> I spent a lot more time up front thinking through specs.
Presumably you didn’t work like this before but now you are? Have you tried simply doing this when manually coding? It’s possible you’re getting a speed up from embracing good practices.
Same experience here.
https://docs.vibe-coding-framework.com/
This seems to be in the same spirit
All these coding agent workflows really drive home how important a solid test suite is but who’s actually writing the tests? In my case Claude Code keeps missing key scenarios and I’ve had to point out every gap myself.
Also reviewing LLM generated code is way more mentally draining and that’s with just one agent. I can’t imagine trying to review code from multiple agents working in parallel.
Finally I’ve shipped a bunch of features to prod with Claude writing all the code. Productivity definitely went up, but my understanding of the codebase dropped fast. Three months in I’m actually struggling to write good prompts or give accurate estimates because my grasp of the code hasn’t really grown (code reviews only help so much). Curious if anyone else has run into the same thing?
I don't think the issue is with the "code" part, but more with the "vibe" part. The "vibe" part indicates that's more of a "let's just see what happens" kind of approach, which I don't think is true for people using AI generated coding in their professional coding jobs, who very much know what they want to get out of AI coding tools, how to ask for it, and how to assess the quality of the outcome.
Maybe something like "intent-driven development" or "AI-paired software development" might fit better?
Right.
The more accurate phrase would be "tool" or "machine-assisted development".
We don't need new terminology to describe something that has always existed because the tools we use have (arguably) improved.
"Vibe coding" is also a misnomer. People who engage in that activity are not "coding". They're using a tool to generate software until they're satisfied with the result. That has also been possible with low-code, no-code, website builders, and other tools. The more accurate term for that would be "machine-driven development".
I get what you're saying. Although I agree that it falls into the same category as "machine-assisted development", it's significantly different from other ways of coding that I would say it deserves its own name.
AI-assisted coding is an absolute game changer, for me, but I would think for everyone who can wield it well. I feel I can direct a (sort-of) small army of junior coders, architects, qa- and req engineers, etc., way different than with e.g. CASE-tooling. It requires creativity, and lots of knowledge & experience in the whole software-development life-cycle to get it well, and it can adapt to any flow you like. That's really new and unique, and way more flexible than the rigid CASE-tooling that was already out there.
"Tool" seems to broad: "What are you doing?" "I'm tooling." :)
Am not highly opinionated on if "code" should be in there. The AI tools do generate code, where some low-code platforms and the likes might not. I guess "development" works as well, although "vibe developing" doesn't really have the same ring to it :)
I do like to be able to differentiate between people generating code but don't care what happens under the hood, and software-professionals that incorporate AI assisted development into their daily work on any level.
100% agree. I really think it's time we move on from vibecoding, the tools have evolved and we should have a term that attaches more quality to the function
Just added this note to the end, as part of my justification for picking such an obviously stupid term for this:
> I’ve tried in the past to get terms like AI-assisted programming to stick, with approximately zero success. May as well try rubbing some vibes on it and see what happens.
Seems like most of the benefit of "vibe engineering" in your description comes from using straightforward best practices of software engineering. How much does the AI add if you already have solid procedures in place for everything else the AI needs not to go bonkers?
The AI adds a ton. It really is like having a whole team of extra coders available, all of which can type faster than you.
Getting good results out of that team is hard, because the bottleneck is how quickly you can review their workflow and point them in new directions.
Understanding techniques like TDD, CI, linting, specification writing, research spikes etc turns out to be key to unlocking that potential. That's why experienced software engineers have such a big advantage, if they choose to use it.
I've yet to get any quality code out of one, though I don't try particularly hard either. I'd rather spend my time actually coding, especially since all the positive stories about enhanced productivity are anecdotes, and the hard data remains far less supportive of the claim.
While I don’t agree with you, I keep a healthily skeptical outlook and am trying to understand this too - what is the hard data? I saw a study a while ago about drops in productivity when devs of OSS repos were AI assisted, but sample size was far too low and repos were quite large. Are you referring to other studies or data supporting this? Thanks!
I, individually, am certainly much more productive in my side projects when using AI assistance (mostly Claude and ChatGPT). I attribute this to two main factors:
First, and most important, I have actually started a number of projects that have only lived in my head historically. Instead of getting weighed down in “ugh I don’t want to write a PDF parser to ingest that data” or whatever, my attitude has become “well, why not see if an AI assistant can do this?” Getting that sort of initial momentum for a project is huge.
Secondly, AI assistants have helped me stretch outside of my comfort zone. I don’t know SwiftUI, but it’s easy enough to ask an AI assistant to put things together and see what happens.
Both these cases refer almost necessarily to domains I’m not an expert in. And I think that’s a bigger factor in side projects than in day jobs, since in your day job, it’s more expected that you are working in an area of expertise.
Perhaps an exception is when your day job is at a startup, where everyone ends up getting stretched into domains they aren’t experts in.
Anyways, my story is, of course, just another anecdote. But I do think the step function of “would never have started without AI assistance” is a really important part of the equation.
Ithink there are also 2 factors to this.
1. Learning curve: Just like any skill there is a learning curve on how to get high quality output from an LLM.
2. The change in capabilities since recent papers were authored. I started intensively using the agentic coding tools in May. I had dabbled with them before that, but the Claude 3.7 release really changed the value proposition. Since May with the various Claude 4, 4.1 and 4.5 (and GPT-5) the utility of the agentic tools has exploded. You basically have to discard any utility measure before that inflection point, it just isn't super informative.
I’d say what you’re doing is architecting, like the old term for “software architect”. Those are professional who know how to design a system from a high level and have the experience to judge a good implementation of it but they themselves do not write the code.
Likewise real world architects have the skills to design a building but do not care or know how to build it, relying on engineers for that.
I think it’s important to distinguish because we’re increasingly seeing a trend towards final product over production, meaning these “vibe” people want the tool in the end and consider the steps in between to be just busywork and AI can do for them.
That’s closer to product design than to engineering. If I can imagine Monalisa and write that thought to paper, communicating that thought and getting a painter to paint it for me does not make me Da Vinci.
If you had developed novel techniques of sfumato and chiaroscuro, spun new theories of perspective and human anatomy, invented new pigments, and then explained all of that to a journeyman painter, with enough coaching, detail, and oversight to ensure the final product was what you envisioned, I would argue that 100% makes you Da Vinci.
Da Vinci himself likely had dozens of nameless assistants laboring in his studio on new experiments with light and color, new chemistry, etc. Da Vinci was Da Vinci because of his vision and genius, not because of his dexterity with his hands.
It might make you Andy Warhol, though.
Hmmm, I think it’s a bit paradoxical to try to come up with a fun term to encourage the spread of the concept, as the concept itself is quite dull by definition. It’s just software engineering. Boring process stuff where you do a bunch of other things around the ‘building’ part that lets you scale up with quality. Vibe is about fun and go-with-the-flow. This isn’t that. It should connote pocket protectors, not sunglasses. Right?
Clearly I’m not in marketing.
Regardless, I’m delighted that this has gotten people to ‘independently discover’ software engineering best practices on their own.
>> How much does the AI add if you already have solid procedures in place for everything else the AI needs not to go bonkers?
> The AI adds a ton. It really is like having a whole team of extra coders available, all of which can type faster than you.
Funny thing is, the least time consuming aspect of making programs is encoding solutions in source form. For example, a reasonable typist can produce thousands of text lines per workday if they know what must be typed (such as transcribing documents).
What takes longest when producing programmatic solutions is understanding what must be typed in the first place. After that, the rest is just an exercise in typing and picking good file/type/variable names.
I really wish I could like this term, because I agree the world needs a pithy, memorable one for what you're describing. But alas, I don't think this is it, either.
Question, why is it seemingly so super important for you to coin a term for this?
Especially a term which comes across as so demeaning and devaluing to engineers (like me and yourself!)
I absolutely do not want my non-engineer friends and colleagues think I am "vibe engineering", it sounds trivial and dumbs down the discipline.
I personally believe being an engineer of some kind requires work, learning, patience, discipline, and we should be proud of being engineers. There's no way in hell I would go around and saying I'm a "vibe engineer" now. It would be like going around and saying I'm a vibe architect! Who would want to live in a skyscraper designed by a "vibe architect" ??
I don't think you should call yourself a "vibe engineer" because you use AI tooling, just like I don't think you should call yourself a "continuous integration engineer" if part of your job role occasionally involves configuring GitHub Actions.
But the act of working on GitHub Actions could be referred to as "continuous integration engineering", just like the act of figuring out how best to build software engineering processes around LLM tools could be called "vibe engineering".
We can resurrect CASE: https://en.wikipedia.org/wiki/Computer-aided_software_engine...
“casing”?
CAISE? Computer Aided Intelligent Software Engineering
That would be overselling it. ;)
CASASE? Computer Aided Spicy Autocomplete Software Engineering
[dead]
As always, Simon knows what he is talking about and neatly describes the whole situation.
However, it's not the "coding" part of "vibe coding" that is the (semantic) problem, it's the "vibe" part.
Replacing "coding" with engineering, but keeping the "vibe" part, still conveys the meaning of not really knowing what you do, but now in an even larger surface area.
It's a lot more boring, but I'm fine with "AI-assisted software engineering" as the other-end-of-the-spectrum name opposite of "vibe coding".
Simon is a salesman. Obviously he knows how to phrase things.
I wish I was! I'm pretty terrible at sales. It's a skill I respect and do not have.
Just want to say that as an AI engineer, you and the Latent Space folks are doing work that is extremely useful to me. Without y'all, I'd be forced to doom scroll on X to catch up on the latest developments.
I wanted to explicitly highlight the utility of what you do because of surrounding comments that suggest/imply otherwise.
Thank you Simon!
> Sponsor me for $10/month and get a curated email digest of the month's most important LLM developments.
> Pay me to send you less!
You are seeing someone asking for a completely voluntary subscription fee for very valuable (I find it at least) work that they give away completely for free—not to mention all the OSS software he has created—and yet you are construing that as being somehow greedy or money grubbing or sleazy.
Hah, yeah that's genuinely one of my more successful attempts at capitalism.
We should just call it engineering. We got better tools. Big whoop.
But it's not engineering ...
Funny I'm a professional engineer and happily call myself "vibe coding" when writing code these days, it started as tongue in cheek, but now I've embraced it.
Being good at vibe coding is just being good at coding, the best practices still apply. I don't feel we need another term for it. It'll just be how almost everyone writes code in the future. Just like using an IDE.
If you’re looking at the AI-generated output then you’re not Vibe Coding. Period. Let’s not dilute and destroy the term just as it’s beginning to become a useful label.
Wait, are people not reading the AI code they use?
People of course often do read (and even modify) the model-generated code, but doing so is specifically not “vibe coding” according to the original definition, which was not meant to encompass “any programming with an LLM” but something much more specific: https://simonwillison.net/2025/Mar/19/vibe-coding/
The whole point of the term is to convey that you are only looking at the output and not looking under the hood. If vibe coding a UI, you only look at the UI, not the CSS.
Nope. That's the "vibe" part of Vibe Coding™.
> The developer does not review or edit the code, but solely uses tools and execution results to evaluate it and asks the LLM for improvements. Unlike traditional AI-assisted coding or pair programming, the human developer avoids examination of the code, accepts AI-suggested completions without human review, and focuses more on iterative experimentation than code correctness or structure.
https://en.wikipedia.org/wiki/Vibe_coding
> Being good at vibe coding is just being good at coding, the best practices still apply.
How does "vibe coding" embody "best practices" as the industry generally defines the latter term?
As I understand the phrase "vibe coding", it implies focusing solely on LLM prompt formulation and not the specifics of the generated source.
> It'll just be how almost everyone writes code in the future. Just like using an IDE.
The flaw with this analogy is that a qualified developer does not require an IDE in order to be able to do their job.
[dead]
> vibe coding is just being good at coding
Having someone cook my dinner's ingredients is just (me) being a good cook ...
likewise, for a lot of frontend I "vibe code" it. I mostly don't look at the code anymore while doing it either, after I get where I want, I will look through the code and maybe clean stuff up. But a lot of the code is fine. Works really well I find. (using Augment Code with Claude Sonnet 4.5).
Is "vibe engineering" a correct term for this? It's not vibe based when you scaffold constraints around the agent: automated testing, planning in advance, comprehensive documentation, automated formatting and linting, and manual QA.
Don't get me wrong, I started vibe coding after reading Karpathy's post. I got the memo - don't review every line of code, don't stop it when it stumbles, let it recover on its own, trust the process.
But after some experience I realised I need to Constrain the model, it is like a karting track, those tires put around it keep the carts inside and safe. It's our job to set the constraints. So maybe it's "constrained agent work" not "vibe coding".
I go as far as saying the constraint harness around the agent is the new code, we can remove the code and regen it from the constraint harness and docs. What matters now is to build tests and constraints around AI work.
> Is "vibe engineering" a correct term for this?
Anything with the word “vibe” in it sounds silly and unserious imho. What’s wrong with something neutral and descriptive like “LLM-assisted programming”? Not catchy enough?
Yes, not catchy enough. I tried to get "AI-assisted programming" to take off for a couple of years, it got no traction at all.
This name makes no sense. "Vibe" means you're just vibing, just taking in vague impressions, just YOLOing, hoping it works out and just chilling and providing little input and effort. It's part pejorative and part ironic self-deprecation. "Vibe X" now means doing X by just giving vague instructions to the computer, not checking the output much and hoping it works out and it kinda does in part, at least enough times that it feels like it's a fine way to do stuff you just want to get over with anyway.
Vibe engineering would mean giving access to Google Computer Use API to your engineering design software and letting it design the industrial component you're working on, without even looking at what it does and just telling it to "fix it" if it seems bump into problems.
No. “Vibe” is what captures the irresponsible usage. “Automated engineering” is much closer to the mark.
What’s the point of this kind of division? Should developers who use JetBrains instead of Vim be called something different too? Or if one person uses Google and another relies on a book, are they somehow different kinds of engineers? What are we actually trying to achieve with this distinction? Vibe coder is not engineer because the person doing it doesn’t really interact with the code. But the tools a professional engineer uses for assistance shouldn’t matter at all, should they?
The distinction is specifically because its not about the tooling differences, its about the mindset and workflow. "Vibe coding" is a dirty word. It comes with an assumption of YOLO'ing until something maybe kind of works. "Vibe engineering " is the complete opposite side of the spectrum - high-touch, high-engagement management of the AI agents, often with a specific plan or design in mind that you are working toward. I agree we need a different word for it but I dont like "vibe engineering".
We've already 90% killed the word "engineer" by applying the title to someone who completes a 6 week bootcamp; this should pretty much finish it off. I don't see much engineering in the list of benefits; mostly seem like administration, and it's even referenced so why not call it "vibe management"? AI seems far closer to replacing mid-senior managers than it does developers.
Some would say we killed the word "engineer" when we started applying it to programmers...
The recent jokes about “everyone is an engineer” now just feels unprovable, where as before it felt like you could still counter that argument by asking to see someone’s code.
Now everyone has examples of code they’ve “written”, but nobody can explain what it does. Unless of course, their readme.md was also completely generated.
I agree with some of the people here that vibe engineering has completely deflated my long successful career as a SWE, and it’s pushed me mentally into non-tech roles to feel motivated.
Thank you for writing this, Simon. I'm using an anonymous account not tied to my main one, so if the mods want to delete it, go ahead, but I really need to rant. My company has been taking this same approach for the past two months. While the rest of the world is warning about the effects of vibe coding and AI-slop, we're fully embracing it, calling it "working smart" and "automate all things!"
It's utterly ridiculous. It feels like the PMs and higher-ups have no idea how much tech debt we're creating right now. For the past few weeks, going to work has felt like going back to school, everyone's showing off their "homework", and whoever has the coolest vibecoded instructions.md or pipeline gets promoted.
I'm slowly burning out, and I was one of the people who actually liked the technology behind all this.
I can totally relate, very similar situation here.
I am currently kind of an anti-AI black sheep in engineering department because I refuse to fully embrace the exponentials and give in to the vibes.
I avoid burnout by simply switching off my brain from all this noise about vibe coding - i have thought hard and long, i know the way this is being implemented is wrong, i know they will create problems for themselves down the road (they already have, the signs are already there), i will be here to dig them out when the time comes.
So far I don't see anyone shipping faster or better with AI than I can manually, so I'm good.
It's interesting to see the differences in industry adoption. My company just recently made Copilot an official tool for use. We're in a safety-oriented industry that moves more slowly. I do use it, but mostly just to tighten up existing code or get ideas for a refactor.
Meanwhile, I have a client project where my counterpart is definitely senior to me and excitedly shares how AI is helping them solve novel problems each week!
[dead]
> It’s a lot easier than working with actual people because you don’t have to worry about offending or discouraging them
But you have to worry much more about confusing LLMs by introducing contradictory ideas or talking about too many things at once.
They will not call you out and they will not recover.
You don’t need to reboot your coworkers.
Life would be so much easier if you could reboot your coworkers!
One of the best solutions to most LLM problems is to wipe the context and go back to a clean slate.
I hope this term doesn't catch on - the whole point of 'engineering' is basing decisions on experience and understanding. The whole point of 'vibe' is the opposite.
If this sort of term is adopted we are in 'literally not being literally' territory.
Fortunately, I imagine that engineering outside software already has people vibing physical infrastructure solutions and call that vibe engineering so I don't think it will stick.
Simon, I think this is a good distinction. Another possible term could be: “agent engineering management” or simply “agent managing.”
I am deep in this and one important way in which managing agents is different than managing people is that micro-managing can be your friend. With human engineering colleagues, you need to allow for a healthy degree of “that’s now how I would have written the code, but it’s a reasonable way to write it.” But if my agent writes the test file in the exact same way I do, I can both review and maintain the code more easily.
I have a bunch of short markdown doc files in which I give very specific instructions for how I like code organized: much stricter than I would ever do for a colleague. I’ll tell the agent, “now add tests to this model and follow @unit_tests.md” This file specifies exactly how I like tests named, what order I like them written in the file, etc. I have docs for: models.md, controllers.md, concerns.md, and fixtures.md.
I think it's a good idea to make the distinction. But I don't think 'vibe engineering' is the term I'd go for.
To me `vibe engineering` sounds like shoddily AI-designed suspension bridges. But then maybe I'm just an old fart programmer who thinks 'software engineering' is a term made up by programmers wanting to be as cool as bridge designers...
It's just engineering, or coding or what every your current discipline is.
We didnt stop calling them Framers or Finish Carpenters when they got electric saws and nail guns.
Tooling does not change the job requirements.
Sure it does, you wouldn’t call a photographer a painter. Really depends on the tool.
Power tools actually increase productivity. LLMs create the illusion of increased productivity and output unworkable messes while atrophying your skills, ergo they decrease productivity. Oh and unlike power tools, for all intents and purposes you can't own them.
That's only true if you don't put effort into figuring out how best to use them.
If using LLMs makes you slower or reduces the quality of your output, your professional obligation is to notice that and change how you use them.
If you can't figure out how to have them increase both the speed and the quality of your work, you should either drop them or try and figure out why they aren't working by talking to people who are getting better results.
GGP's sentiment resonates with me. I invest a fair bit of time into LLMs to keep up on how †hings are evolving and I do throw both small and large tasks at them. I'm seeing great results with some small task but with anything that is remotely close to actual engineering I just can't get satisfactory results.
My largest project is a year old, it's full-stack JavaScript, and I consciously use patterns, structures, and diligently add documentations right from the beginning for the code base to be as LLM friendly as possible.
I see great results on refactoring with limited scope, scaffolding test cases (I still choose to write my own tests but LLMs can also generate very good tests if I explicitly point to existing tests of highly related code, such as some repository methods), documenting functions, etc. but I'm just not seeing the kind of quality that people claim that LLMs can do for them on complex tasks.
I want to believe that LLMs are actually capable of doing what at least a good junior engineer can do but I'm not seeing that in my own experience. Whenever we point out these issues we are encountering, we just basically get the "git gud" response with no practical details on what we can actually dp to get the results that people claim to be getting. Then people start blaming our lack of structures, patterns, problems with our prompts, the language, our stack, etc. when we complain about the "git gud" response being too vague. Nobody claiming to be seeing great results seems to want to do a comprehensive write-up or, better still, a stream of their entire workflow to teach others how to do actual, good engineering with LLMs on real-world problems either -- they all just want to give high level details and assert success.
On top of that, the fact that none of the people I know in engineering working in both large organizations and respectable startups that are pushing AI are seeing that kind of results naturally makes me even more skeptical of claims of success. What I'm often hearing from them are mediocre engineers thinking that they are being productive but actually just offloading the work to their colleagues through review, and nobody seems to be seeing tangible returns from using AI in their workflow but people in C-suites are pushing AI anyway.
If just about anything can be "your fault", how can anyone claiming that LLMs are great for real engineering without showing evidence be so confident that what they're claiming but not showing is actually the case.
I feel like every time I comment on anything related to your blog posts I probably came across as belligerent and get down voted but I really don't intend to.
Which model and tools are you using it that repo?
My professional obligation is to get hired easily when the other candidates can't write FizzBuzz without asking chat.
Engineering is in large parts about signing-off on something with you name on it, and being responsible if it fails or causes harm. Think bridges, tunnels or other infrastructure. I‘d argue that this is the same for computer engineering. That‘s why I think coining the term ”vibe engineering” can be dangerous.
”Vibe coding” is the better term and actually makes sense for what it describes.
Leave ”engineering” in terms of taking responsibility for what you ”engineer” strictly to human professionals. That’s what people pay for and that is what makes it valuable.
Someday we will realize that using the term vibe before coding is like someone saying that today when we use GCC we are "vibe compiling" because we didn't compile the code manually.
Once tooling becomes reliable and predictable enough, and the quality of the output consistent enough, using it is not a leap. Early compilers had skeptics, and GCC still has some bugs [1]
1. https://bugs.launchpad.net/ubuntu/+source/gcc-8/+bug/2101084
I really don't think we're doing the tools or the industry any favors/justice by prefixing new terms with `vibe`.
Looking at vibe coding: it suggests you're coding but you only vaguely know what's going on, so the work is the same (coding) but the outcome may or may not be what you want
Why dont we flip it around? We want a term that suggests that a fixed amount of work (coding) to be more efficient/leveraged.
So why dont we call it something like hypercoding, dense engineering, autocode, ...
Some more options (I used AI with a nuanced not-too-lazy prompt, I hope it is okay):
Prompt Engineering / Directed Prompting
Architectural Steering
Spec-Driven Development
Intent-Based Coding
Critical Synthesis
Iterative Refinement
Guided Iteration
Hypothesis-Driven Coding
AI-Assisted Engineering
Cognitive Pair Programming
Dialogic Programming
Structured Prompting for Code (SPC)
Code Shepherding
AI-Assisted Engineering is probably the most descriptive. My favourite are Critical Synthesis and Code Shepherding. Both abbreviate to CS
This matches our experience developing with agents. In particular, as we wanted to use multiple agents in the background to do tasks, we had to really invest in different areas so they would not go in wild directions or have to ask continually for feedback, defeating the purpose of working in the background. First, we needed to provide relevant context on how to do the task (some of it is "generic" like Svelte documentation, some of it is specific to how to write tests for our particular project), be extremely detailed and specific in the prompt about what we want and how to go about it (divide it in different well defined steps) and finally provide with specific tools via MCP (like MySQL access and installing system packages). Once we consistently do all this work upfront, it really pays off because you can launch a large number of agents in parallel that don't interfere with each other (git worktrees, containerized environments) and don't require babysitting for the most part. We just open sourced the tooling we used internally for this: https://github.com/endorhq/rover
Thanks for sharing!
The problem with every single tool in the category that I've come across (e.g. Conductor, Sculptor) is that they assume a single repository. Very rarely in my career working on enterprise software have I been in a situation where all my work was constrained to a single repo. Usually a story or feature spans several repos (whether split between frontend/backend, or a repo-per-service). As an engineer in these situations I never work in isolation considering only one repo -- I work across all of them at once and then prep all the PRs together. I'm not saying this multi-repo approach is good, just that it is the state of the world right now in many cases.
So imo tools like this need to work at a level above a single repo. The agent needs to start by cloning all repos needed for the task, and go from there.
I've solved this in the past using versioned dependencies. Repos get tagged releases, other repos can specify which version they depend on, then the deployment script has to resolve those dependencies and install the right release versions of everything else.
You can also use GitHub submodules to implement a pattern like this, but I don't really trust them for some reason.
Hey! Angel from Endor / Rover :)
Thanks for your feedback! I faced this in the past. As you mentioned, monorepos are more common these days, but multi-repo is an established approach in many teams. The way I "solved" this situation was to move all the related projects into a single folder with a parent AGENTS.md file (CLAUDE.md, etc.). Then, I run Rover / Claude / Gemini on this folder.
However, this is not ideal. Due to the amount of code, it usually misses many things to do. We are currently exploring specific workflows for these use cases, trying to help agents to prepare a complete plan.
Another similar case we are working on is to support spawning the same task across different repositories. This would help teams to apply refactor or changes in different projects at the same time.
Since Sculptor allows you to use custom docker containers (devcontainers), you can check out the other projects in there.
Then your primary project (from Sculptor's perspective) is simply whatever contains the devcontainer / dockerfile that you want it to use (to pull in all of those repos)
It's still a little awkward though -- if you do this, be sure to set a custom system prompt explaining this setup to the underlying coding agent!
(I'm a founder of Imbue, the company behind Sculptor: https://imbue.com/sculptor/ )
> "If you’re going to really exploit the capabilities of these new tools, you need to be operating at the top of your game. You’re not just responsible for writing the code—you’re researching approaches, deciding on high-level architecture, writing specifications, defining success criteria, designing agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely cheat if you give them a chance, and spending so much time on code review."
I know this paragraph is supposed to be encouraging, but it makes me wonder again what the actual goal of this entire AI enterprise is supposed to be.
"Less work" or "easier work" would make superficial sense, but in a society where people are in constant competition and derive both their self worth and their basis for living from work, both are effectively anti-goals. And so we get articles like this trying to offer comfort by saying that work will still be draining and challenging in the future.
So if not less work, then "more productivity", i.e. we can produce more software in a shorter amount of time (but with the same mental load). But as others have said, this was never the bottleneck.
There will be times when LLMs are not accessible or working as expected and we will honor real software developers who can still think on their own, create and solve problems.
@simonw
Great post. I've thought about what I want for better Vibe Engineering:
Each agent needs to deliver a fully working App/URL/Build so the functionality can be tested & verified.
Today AI IDEs deliver the diff + an explanation. Excellent. But give me the full build, a build I can share. A build that represents what it would be like shipped. When it comes to user facing functionality, a real build is how product owners verify a feature is complete.
Learn from Vercel -
A key part of Vercel’s magic is the automatic deployments for each branch. When working on a project with per branch vercel deployments - a team gets the immediate value of:
Shareable work - now others can see/test/give feedback on the great new feature you’ve developed - and their only work is to click a link (not git pull a branch and attempt to run locally)
No more “it works on my machine”. It either works or it doesn’t.
Confidence that if released, you know exactly what the user will experience. Give me automatic deployments for each agent, for each PR. And keep them available to spin up / re-use later.
I want to be able to re-launch it 3 months later and it just works. The reason we don’t do this today is the cost of the engineering - but with docker et al + AI agents, the cost of the eng work drops 99%
Deliver the deployment in such a way that immediate feedback to the AI could be given. This way minor tweaks can be executed immediately by the AI meaning that I can just wait for the minor tweak, review and then merge. This means the PR gets shipped NOW.
I think a key skill is knowing what level of complexity a single run can realistically achieve, which is often only a small task and not a fully working build.
Don't worry — if we all have access to the same tools, the playing field is level. What sets you apart are the human qualities. Employers and clients want to be at the top, same as before LLMs. The market is large, and there's room for everyone. Don't be afraid of someone without any/little engineering knowledge making something, they were already copy/pasting code from SO before LLMs.
The field is all but level with all the money behind the AI.
I've been successfully "vibe engineering" with Claude Code for a week now on a side quest at my job. I want the result to be of high enough quality to maybe survive in our codebase long-term, but I don't want to write it myself.
So I've added unit tests, e2e tests, formatting checks to help Claude to self-correct as much as possible. And I make him do a TON of self-review, after each feature I say something like:
> You are a master reviewer, lots of practical experience. Read Clean Code. Great at architecture. Read Effective Typescript as well. What would you comment in a PR review? Type checking MUST PASS, unit tests must PASS, formatting must PASS.
With each review, Claude catches a lot of sub-optimal choices it made which gives me more confidence in the code I get in the end.
Do you really believe that if you miss the "Read Clean Code" or "Read Effective Typescript" part, then the output would be significantly different?
No offense, but I feel this kind of talking is ridiculous. If it is a better practice, then it should be done without explicitly telling so. You do not tell them "Do not get things wrong," right? If it is a matter of choice over design patterns, for example, use functional programming or object oriented programming paradigm, then it should be said more clearly as what I have done.
Now, if it is neither something that is definitely a better practice nor something you can state clearly with a known, well-defined word, how can you make sure what you have said really make a difference if you have not said it?
It works for me and I like the results I'm getting. The results often include callbacks to rules of thumb from the mentioned books - which I find easier to agree with or dismiss when I see the suggestions it made. In a way, it's a framework for me to "communicate" with the LLMs.
I think you should try finding what works for you, maybe even give my ridiculous prompt a go.
These people havent deployed anything to a production environment that requires reliability and support. For that, you need a real software engineer to take apart the mess of vibe coded kludge and create real software that can actually be given to people to use. I wouldnt worry about this. Vibe coding trend is already on its way out as people discover this.
I call it PEAKS: Performative Extreme Agile Kiddie Scripting
Simon went quickly from not agreeing with common buzz words to making up his own.
So the only quasi disagreement I have is that "research" is one of the strengths of the models, and you should lean on them where possible.
In Claude Code for example I define a research sub-agent and let it do the majority of "research" type tasks. Especially when the research is tangential to what ever my objective is. Even if it is critical, I'll usually ask to have it do a first pass.
> Good version control habits.
Feel like there's more to this point (plus the documentation). By now we've all see the inverted-U-shaped performance curve when coding with LLMs within a single thread / context: the model starts strong, plateaus as the context fills up, and eventually declines as semantic drift sets in.
Sometimes in this situation, it works better to throw away the current code and re-implement, using what's been learnt so far, than continue working with the current context of having new contexts try to salvage the current state of some code.
Documentation is great as a reflect of the current state of some code but I've had good experiences "re-constructing" the steps taken to arrive at a current implementation by writing commit messages that are intended for an LLM, extract that later, have an LLM use it as a basis for writing a fresh "spec" for some code, that yet another LLM uses to actually write that code.
Git history is a natural place to store that...
I've been thinking about AI-assisted development for a while; I've tried out Claude's pro plan, Gemini Pro and many "top models" and I must say, this is going to create a chasm for junior/intermediate developers like myself, senior engineers reached to the point they are through deliberate practice-- interrogating code, making and breaking assertions, reading through the documentation or actually comprehending the code through the debugger or mental models. I don't "need" to do any of this. I can have an AI just spoon-feed me a large codebase in "ELI5" language, I can ask an AI about the best practices, I can have an AI look something up for me, synthesize it and wrap it up nicely for my mind to consume (equivalent to how hyper-processed junk food isn't good for our bodies either)
It's intellectual slop. It will get the job done (atleast for a while) but without the actual growth that comes along with it. When I use an AI to one-shot a "small one-off script" I don't learn anything from it (when as a relatively new developer I SHOULD be learning something from it) And this is unlike stack overflow or googling becuase you can turn off your mind, just become one of those drones from Wall-E.
I make a point to avoid using any AI for coding (even for looking things up) when working on personal projects, at the cost of "productivty" and "efficiency" , but I get to retain my humanity and soul in programming.
Sorry if this sounds cheesy, it's just I care deeply about code craftsmanship from my end, to see that skill be diminished to an random number generator? Yeah No.
To people reading the article: replace the word "agent" with "intern".
> Without tests? Your intern might claim something works without having actually tested it at all, plus any new change could break an unrelated feature without you realizing it. Test-first development is particularly effective with interns that can iterate in a loop.
Vibe engineer? No, try technical manager.
As a CTO of a small company, spending a lot of time reviewing other developers' PRs, I completely agree. I recently enabled Github Copilot Agent and use it a lot for dealing with smaller and lower priority tasks in an async workflow (e.g. while I am doing other things). A lot of developers are not very good writers, and reviewing PRs from Copilot, with access to the full "thinking process" and being able to request changes in a few comments is sometimes more pleasant and effective
Simon,
I want to reach out since I want to express my disappointment regarding this thing you write here:
"I propose we call this vibe engineering, with my tongue only partially in my cheek."
Back in march 2025, you and I had a brief convo on X about this very term that came to my mind "Vibe Engineering":
https://x.com/pierre_vannier/status/1904933441042317821
I also mentioned it in our podcast in April 2025: https://x.com/Flint_company/status/1909946181897044195
Yesterday, I pinged you on X about this "term's paternity" in your thread without any response: https://x.com/pierre_vannier/status/1975579806495293910
You and I met in AI Engineer in SF last June and we discussed for 1 hour (not about this specifically but about AI and all).
At the very least, it could be cool to mention it in your post or newsletter since, I do think this little convo on X + our talk in SF might have just planted the seed in your head for this "invention" of yours...
I don't want to stay in history books but I think it's cool to also credit people when you iterate on their idea instead of just make the thing entirely "yours"...
Best Pierre
I think he should have given you credit, you were clearly first and he responded to your tweet so he must have seen it! But he might have just forgotten he had the conversation with you about this, while still being more likely to "rediscover" the term since he had heard it before. Maybe a bit aggressive to not reach out to him privately first but in any case pretty cool that you actually invented a term that is now quite likely to be popular :)
we gonna police naming things now?
The guy is all in on the world's biggest copyright infringement machine.. good luck getting your credit
If they know what they're doing, we trust the experts to select their tools rather than letting those tools define the person.
The opposite of vibe coding is not vibe engineering, its just engineering.Coding++
Seriously now, I think the whole industry suffers from too many buzzwords and whacky terminology.
*The job hasn't changed*. As mentioned, all those things from the past are still the most important thing (version control, being good at testing, knowing when to outsource, etc).
It's just coding (which is something that was never about typing characters, ever).
Willison has an impressive record for coining terms. But feel like he may have missed it here. In the context, 'engineering' doesn't feel that different to 'coding'. The sloppy sounding part is 'vibe' and that's not been removed.
I’d just call it “coding” – it’ll be the default soon enough. For the old way: “hand-coding”
It will certainly be the default for cases where it's easier to read code than to write code, but this is far from universally true. AFAIK, Joel Spolsky was the first to discuss this at length 25 years ago [0], but numerous people have echoed his sentiment [1, 2, 3, ...]
One of the most underrated skills in effectively using gen-AI for coding is knowing ahead of time whether it will take longer to carefully review the code it produces, versus writing it from scratch yourself.
[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
[1] https://mattrickard.com/its-hard-to-read-code-than-write-it
[2] https://trishagee.com/presentations/reading_code/
[3] https://idiallo.com/blog/writing-code-is-easy-reading-is-har...
[...] https://www.google.com/search?q=it%27s+harder+to+read+code+t...
I feel nauseous when I read comments like this. Does no one here actually like programming?
I love programming, but it turns out I love building useful stuff even more than I love programming. Agentic coding helped me fall in love with development all over again. If a team of junior engineers suddenly showed up at my door and offered to perform any tasks I was willing to assign to them for the rest of my life, I'd love that too.
Agentic coding is just doing for development what cloud computing did for systems administration. Sure, I could spend all day building and configuring Linux boxes to deploy backend infrastructure on if the time and budget existed for me to do that, and I'd have fun doing it, but what's more fun for me is actually launching a product.
Sadly the times where people joined software engineering for passion are way behind. People nowadays join just for the money or because it has lot of jobs available.
It is very easy to notice at work who actually likes building software and wants to make the best product and who is there for the money, wants to move on, hard code something and get away with the minimal amount of work, usually because they don't care much. That kind of people love vibe coding.
Or some of us are Engineers who very much enjoy solving problems using the best tool available.
I don't like the kind of programming that an LLM can easily accomplish.
For instance, I recently had to replace a hard-coded parameter with something specifiable on the command line, in an unfamiliar behemoth of a Java project. The hard-coded value was literally 20 function calls deep in a heavily dependency-injected stack, and the argument parser was of course bespoke.
Claude Code oneshotted this in about 30 seconds. It took me all of 5 minutes to read through its implementation and verify that it correctly called the custom argument parser and percolated its value down all 20 layers of the stack. The hour of my time I got back from having to parse through all those layers myself was spent on the sort of programming I love, the kind that LLMs are bad at: things like novel algorithm development, low-level optimizations, designing elegant and maintainable code architecture, etc.
wait you were unfamiliar with a behemoth Java project to the point of dreading making the change yourself, and yet only spent 5 minutes reviewing "someone else's" PR?
Yup. Replacing a single hard-coded parameter with a command line argument is hardly an earth shattering change. It's trivial to verify that the argument properly gets passed down the stack (and that passing it has no side-effects), but figuring out that stack in the first place would have taken a much longer time. Think of it like an NP-complete problem: hard to solve, but easy to check that a solution is correct.
For more complex modifications, I would have taken the time to better internalize the code architecture myself. But for a no-brainer case like this, an LLM oneshot is perfect.
> It's trivial to verify that the argument properly gets passed down the stack
It's not so trivial to verify that the change doesn't cause problems elsewhere, where it also should have been propagated.
Sorry if I haven't been clear: it's one variable, used exactly once at the very bottom of the call stack. The change only required adding a corresponding extra argument or class member to all of the functions/classes upstream. In fact, there were other variables in the caller of the bottom function that get passed down from the command line, a pattern that the LLM likely picked up on (and exactly what clued me in to the fact that the LLM would likely make this change very easily, a hunch that proved correct).
You raise a good point: an important skill in effectively using LLMs for coding is both being able to recognize ahead of time that cases like this are indeed simple, but also recognizing after the fact that the code is more complex than you initially realized and you can't easily internalize the (side) effects of what the LLM wrote, warranting a closer look.
Linus Torvalds: 'Talk is cheap. Show me the code'
Today: 'code is cheap, show me the talk'
I've definitely heard people semi-seriously refer to the old way as "artisanal coding".
Someone called it "brain coding" the other day which I quite enjoyed: https://domm.plix.at/perl/2025_10_braincoded_static_image_ga...
That's actually a pretty reasonable description I think. I mean, in the semi-serious way. But I was just talking to some colleagues of mine about how one can get attached to or invested in code that they hand wrote, even though that code wasn't really solving a problem that was "worth" that level of attachment. And AI assisted code generation changes the dynamic for code that fits in that category for me, and it just so happens to be a lot of the code people write for work fit into that. You only really need to be "artisinal" about the code that "really matters".
Just wait until there are artisinal software shops in Brooklyn staffed by an even higher density of bros with signature mustaches and weird side hobbies.
I dunno, I feel lately like we are right at the tail end of the honeymoon era and about to enter the era where the blog topic du jour is “use LLMs, not too much, mostly on a short leash”.
Not much to base that on other than vibes, though :)
As much as I dislike the ecosystem around AI and don't enjoy using them as tools: this is the answer. We don't need a word for "doing the job properly with new tools".
I feel a certain way when I hear about older programmers who used to program using punch cards, I guess everyone in the future will think about us in the same way?
I feel a certain way when I work with older programmers who used to program using punch cards, and debug actual core dumps, i.e. the main memory of the computer printed out in hex. They have incredible attention to detail, and can reason about why their programs didn't do what they expected.
In some ways slower feedback loops might be useful. Having to think and reason if your code is correct and actually works because you only get output next day...
Instead of just vibing something out, pushing it to prod and seeing the problems. Or not even checking...
You don't "program" with punch cards any more than you "program" with text files. They were just the mechanism to get your code into the computer before hard drives and compilers existed.
[flagged]
Haha - cool that you made a throwaway insult account just for this. I meant punch cards as a placeholder for programming in a bygone era, about how it feels so different, distant and detached, and that I don't relate to it.
I can see a plausible future where if we go down this route, what I call coding right now will feel the same.
brick-and-mortar coding
It’s great to read in the comments about experiences of others with vibe coding. But I also feel like lots of opinions are not coming from actual experience, or “serious” attempts at vibe coding, and more from theoretical deliberations. I might be wrong.
Here are some of my own high-level experiences / thoughts:
- Perhaps contrary to popular belief I think vibe coding will bring the best software / system architects. This is due to massively shortened feedback loop between architectural idea and seeing it in action, easiness with which it can be changed, and the ability to discuss it at any moment.
- We’re not really coding anymore. This is a new role, not a role of a senior dev reviewing PRs of junior devs. Devs are just best suited (currently) to take on this new role. I came to realization that if you’re reviewing all generated code in detail you’re doing it wrong. You just shifted bottleneck by one step. You’re still coding. You should skim if the code is in line with your high-level expectation and then make LLM maintain an architecture doc and other docs that describe what and how you’re building (this is the info you should know in detail). You can do audits with another LLM whether the implementation is 100% reflecting the docs, you can chat with LLM about implementation at any moment if you ever need. But you should not know the implementation the way you know it today. The implementation became the implementation detail. The whole challenge is to let go of the old and embrace and search for efficiency in the new setup.
- Connected to the above: reading through LLM outputs is a massive fatigue. You are exhausted after the day, because you read hundreds of pages. This is a challenge to fight. You cannot unlock full potential here if you aim at reading and reviewing everything.
- Vibe coding makes you work on the problem level much more. I never liked the phrase “ideas are cheap”. And now finally I think the tides will turn, ideas are and will be king.
- Devil is in the detail, 100%. People with ability to see connections, distill key insights, communicate and articulate clearly, think clearly, are the ones to benefit.
Hope this is helpful for others.
We might just have to accept that it’s software engineering. Not vibe engineering, just engineering. Proper engineering has never shied away from using smart tools, it’s about ownership, accountability, planning, etc etc and you’re still doing all that. If you sign off properly on everything, it’s yours. It’s engineering, that’s it.
Smart tools have existed forever, or we’d all be coding in assembly still. As long as we take ownership of the code and the result that’s it.
I would add to the list of the vibe engineer’s tasks:
Knowing when the agent has failed and it’s time to roll back. After four or five turns of Claude confidently telling you the feature is done, but things are drifting further off course, it’s time to reset and try again.
I like the idea of finding an alternative name to "vibe coding" to describe this more substantive alternative. However, I personally think the name "vibe engineering" is too close to vibe coding and not sufficiently distinct.
I don't have a great alternative unfortunately. I've used "agentic coding" in the past as a means of differentiating from vibe coding, but I don't think that's necessarily clear enough either.
That said, maybe with defining this new approach it's just going to take time for any term to become familiar enough to be self-explanatory.
However, I personally think the name "vibe engineering" is too close to vibe coding and not sufficiently distinct.
Funny, because when I saw that phrase I immediately thought, "They're using chatbots to design bridges now?"
I call it … using a chatbot to code.
Don’t mind me, I’m just vibing.
I took a look at youtube but I haven't seen any real examples of AI being used to ship anything significant (as in, other than toy apps which are available as templates already or copy pastable from tutorial websites).
>> where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce
Why would you add “vibe” then? Seasoned devs don’t vibe, they know what they do
"Vibe Technical Debt Creation" <-- either that or the AI's purpose is limited to sTimulation (getting us to think while it's spinning its wheels writing throwaway code.
It sounds like some people who are running multiple AI tasks in parallel might be risking burnout because they think they need to keep machines busy. But this is a symptom of systems that don’t run fast enough to be interactive.
If compiles take ten minutes then sure, you’re going to want to do something else while waiting. If they take two seconds, you stop caring about keeping the machine busy because it’s impossible. It’s perfectly normal for computers to be idle waiting on you most of the time.
What I’d really like to see is a company that completely does away with the code review step. Because if you think about it a code review is already being done by the invoker of the LLM. That way the velocity will actually be faster. It feels like at the moment most of the velocity is blocked by the outdated notion of code review.
It’s also why these tools feel great in green field projects, since these ones don’t typically have any code review in place (i.e. one dev going brrr)
We tried this as a bit of an experiment - not quite greenfield but a fork and modification of an existing project.
I was a solo dev going brrrr with no code review, using Cursor to make pretty sweeping changes and implement full features. I think because it was a fork I was able to go really fast because I could point the coding agent at existing patterns and say, "do this but different".
Occasionally I would test changes in staging but mostly would just promote them straight to production. I went on like that for ~3 months and the product ended up getting ~75k (daily!) users in that time with *no* outages or downtime (!!!)
It worked really well! Until I hit my scaling limit and we added more engineers to the team. A new hire on their second week on the job shipped a change that was also written with AI and caused a 7 hour outage before we realized something was wrong. I even *thoroughly reviewed the code* because I knew it was generated and I made a comment questioning the lines that caused the outage, but after we talked it over we decided it was fine and was only one tiny bit of a much larger change.
So I guess, AI will ship bugs but so will peer-reviewed code.
Nice. Sounds like a success? Was the experiment made permanent? If not, why not?
I realize this is likely being facetious, but just in case - code reviews are so much more than just 'check the syntax and style of the code'. They check the intention, check the actual functionality, find issues on the larger scale that LLMs literally can't.
Yes, PRs start piling up because devs can vibe code them faster than they can be competently reviewed. This is a problem with the vibe code process, not the code review process.
I was being half facetious, yes. But wouldn't the invoker of the LLM be already doing a review in that case? It just feels a bit redundant, to have engineer one do a code review of LLM's work, and then have engineer two do the same review.
The business cost with PRs isn't the first review but another developer, it's the number of iterations on a pull request due to defects and change requests. The way I am trying to promote the use of LLMs with more junior developers in my team (I am the CTO) is to use AI-assisted tools (we used Windsurf and recently switched to Github Copilot) for a first pass, e.g asking the agent for a review and catching potential defect before involving the human reviewer.
This doesn't mean the human reviewer will need to spend less time reviewing, but potentially this PR will be merged faster with on average a lower number of iterations and improved code quality.
I do have in my team some senior developers that are excellent, and it's very very rare I catch an issue in their PRs (maybe 1 out of 50). But I also have greener developers for who the ratio is way higher (like 8 or 9 out of 10) and this means repeated context switching for the reviewers.
I hope this is a joke...
Partially serious. I mean what’s the point of being able to open 100 PRs in one day if your coworkers can only reliably review 5 of them?
Not just that but PRs are about a lot more than syntactical correctness, it's also about design. Just this week we've had two PR catch bad design choices that came from a fundamental misunderstanding of the problem space. Even if the AI wrote perfect code the first time everytime it wouldn't matter in those cases.
To me, “Vibe engineering” isn’t just a label — it’s a Rorschach test for identity in the AI era.
>> Supporters see it as a bridge between humor and professionalism >> Critics hear it as the sound of their trade being rebranded into a meme.
Both sides, though, agree on one thing: coding is no longer the same craft it was a year ago.
My opinion: I believe “vibe coding” has already broadened to mean any AI-assisted coding, making “vibe engineering” redundant.
"Vibe coding" implies it's newbies throwing prompts and hoping some of them stick.
For the experienced lot of us, I've heard many call it "hyper engineering"
I put a lot of thought in to my prompts. I can code, definitely not as good as the AI or people here on HN; it's something I always enjoyed doing to tinker with things.
The AI agent in Cursor with Gemini (I'm semi-new to all of this) is legit.
I can try things out and see for myself and get new ideas for things. Mostly I just ask it to do things, it does it; for specific things I just highlight it in the editor and say "Do it this way instead" or "for every entry in the loop, add to variable global_var only if the string matches ./cfg/strings.json" I _KNOW_ I can code that.
But I like my little clippy.
FWIW, from the perspective of a non-coder: the tone of the comments in the discussion here is markedly different from those on similar topics six months ago and earlier in that there is no rage and contempt for LLM/vibe coding any more, but rather a reasoned discussion.
Your second point “planning in advance” could be referred to as spec-driven development… it’s a funny term in a sense (didn’t we always do that?), but I think your 7th point drives it home “a very weird form of management” - clear instructions, necessary context, and actionable feedback. As far as written words go, much more like waterfall than agile.
Is cost a risk here? I'm assuming that sometime in the future the price for vibe coding/engineering will go up significantly.
It already is. I saw a demo of someone spending $30 an hour on Cline to do something that would be achieved better, for free, and faster, with a framework.
That's more than $5,000 a month assuming 40 hours a week.
The end result didn't compile by the way.
I prefer:
Agentic coding, inner loop, the stuff an engineer does on his laptop. Agentic engineering, outer loop, sdlc across the organization
Not perfect, but good enough.
This feels like an attempt to sell vibe coding to skeptics. I don't feel there's a need to. People find their own workflows how to use AI. Some people go all in, some use it here and there, some use it to write tests, etc. I feel annoyed enough having the AI topic discussed and reviewed everywhere every day, I don't need more of this.
The corollary to that is that keeping a shitty legacy codebase will keep you employed longer, since AI won't find its way through it, and screw everything up every time it touches anything.
This is making me like the written-by-math-grad-school-interns python mess I inhereted!
I think this complements in a good way with "context engineering"[1], that's great.
[1] https://simonwillison.net/2025/Jun/27/context-engineering/
I find using “Vibe” makes it sound less valuable. It also needs to fit the next frontier which is “refactoring” and tuning the codebase to work with agents to make it easier to change existing code. A suggestion to use “augmented” was great
Can anyone suggest solution(s) to create temporary preview environments per branch or Pull Request?
For example if someone creates a Pull Request "#2122 feat: User password change"
Automation would deploy it to pr_2122_feat_user_password_change.mycompany.com
Heroku and Vercel and Render all have features that can do this. You can wire up your own for other hosting providers using a lot of scripting on top of GitHub Actions.
Heroku: https://devcenter.heroku.com/articles/github-integration-rev...
Vercel: https://vercel.com/docs/deployments/environments#preview-env...
Render: https://render.com/docs/service-previews
[dead]
there is no such thing as vibe engineering no matter how much you want to make it up
Vibe is just a bad word to describe anything that requires skill beyond "taste". A word play off of "AI assisted programming" is probably going to be the term that sticks. AIssisted? pAIr programming...
Seeing all the experienced engineers on this thread who feel discouraged is really depressing.
Not because I disagree with you, I don't! It's because I fear a gradual brain drain of people who actually love their craft and know how to build things properly. I fear we'll end up with worse software thats simply 'good enough', built a atop a pile of AI slop.
If it's cheaper but with acceptably worse results, I fear this is good enough for a lot of companies.
Slapping 'engineering' on something to try and trade on the good name of real engineers is the express lane to losing all of your credibility. Guess I should get ahead of the curve and update my title to Slop Surgeon.
No one should be allowed to use "engineering" in the context of producing something with LLMs until they learn to say "No, I'll not help you cut corners on this, and if you persist I will report you".
If you're fine with an AI designed bridge, where the builder tweaked the prompt to get the LLM to suggest cutting out all safety features, then okay, go with vibe engineering.
my tongue-in-cheek job title has been 'professional string concatenator' for a long time now
I've been all-in on vibe engineering for 4 months now and it is overall amazing. Simon missed a few key rules and practices that I follow, but every one of the points he hit is spot on. I also know for a fact the work I do has influenced some of his recent writing. Sorry to be a braggy jerk but I'm pretty proud of this! <3
The part about past management experience being a key skill surprised me but now it makes sense.
I really do usually have 3 different projects in flight for at least 6 hours a day. I'd write a blog post but I keep expecting someone else will write the essential same post tomorrow. :)
p.s. The first 2 months was exhausting but now it's slightly less exhausting. Make no mistake, it is an extreme transition to make.
What extra processes would you include? I'm sure my list in the post isn't exhaustive!
> it’s surprisingly effective, if mentally exhausting!
this sadly seems to sum up most of this new wave of work. hopefully we can find a better workflow that still feels as good as coding used to
I wonder if we are more like accountants at the advent of spreadsheets, who have thrived and just changed tools, or farriers at the advent of automobiles?
I feel using the word 'vibe' is inherently giving it a negative connotation which goes against the idea presented here.
The reality is the tools are really useful when used as tools, like a power drill vs. a screw driver.
Vibing implies backseat driving which isn't what using the tools proficiently is like. The better term would be 'assisted' or 'offloaded'.
Same thing with the term 'engineering'. That's a fairly new term that implies being engineers which we are not. We haven't studied to be engineers, nor have real engineering degrees. We've called ourselves that because we were doing much more than the original job of programmer and felt like we deserved a raise.
'LLM extended programming' is not as catchy but more relevant to what I observe people doing. It's valuable, it saves time and allows us to learn quicker, very powerful if used properly. Calling it 'vibe engineering' is a risky proposition as it may just make people's eyes roll and restrict us to a lesser understanding.
If you're paid to use science and math to create things that didn't exist before, then guess what: you're an engineer.
Just don't capitalize it in Oregon.
Speak for yourself, I'm paid to use ReactdotJayEss not science and math.
> That's a fairly new term that implies being engineers which we are not. We haven't studied to be engineers, nor have real engineering degrees. We've called ourselves that because we were doing much more than the original job of programmer and felt like we deserved a raise.
Uh, speak for yourself. There are countries where being a software engineer does indeed imply that you studied engineering and hold a "real" engineering degree.
Also, Hillel Wayne's "Are We Really Engineers" is worth reading:
https://www.hillelwayne.com/post/are-we-really-engineers/
I agree with both of you. Some coding is part of a real engineering process. That's why I don't like using "engineering" to refer to coding broadly - because it loses that specificity and connotation.
As "coders" or "programmers", some of us should answer the question "are you an engineer?" with a proud "of course not!" (That's me.) And some of us should answer, equally proudly, "of course I am!"
Hillel Wayne's series is great.
Same, I feel like the word vibe paints a picture of some dude ripping a bong while pressing enter.
If you can’t do it while you’re also singing a karaoke song, then you’re not vibing.
I have fairly decent engineering credentials, but when the task fits, I prefer to vibe code.
I don’t think that’s far off. There was an article awhile ago saying “you need to let go of looking at every line in a PR”.
Sadly, "vibe engineering" is already real, but associated with half assed engineering, rather than effective use of LLMs lol.
Call it autonomous engineering. Vibes are optional.
Vibe engineering is what vibe coders think they do.
hi Simon - just a note to say that your link to https://tools.simonwillison.net/ goes to https://simonwillison.net/
Think this might be a typo
Thanks, fixed that.
I could never take anything seriously with the word "vibe" prefixed. "Engineering" is something hard, vigorous, fully dedicated, and commanding respect. It's just a stark contrast to "vibing something out of thin air"
I get the impetus behind the term and I think it's a good article with a lot of practical advice overall, however I am disheartened by the terminology on two fronts:
1. It is confusing in the sense that all other engineering disciplines have the form "<X> engineering" where X is the object being engineered. This makes it sound like we are engineering vibes, not software. 2. Software engineering was already only marginally worthy of the term "engineering". There is a strong subset of computational system building that I think actually meets the standard of engineering (rigorously understanding requirements and system bounds, probably showing that the system achieves stability within those bounds). This just makes that situation worse. The devil is in the details, and over-reliance on llms ultimately makes those details a black box to the designer. Before you claim it's the same as when a designer relies on a suite of humans—no. The designer can ask those humans for reverentially transparent proofs that certain conditions are upheld, there is a social accountability structure, etc etc all of which does not exist with LLMs even if they get good enough that we can just trust them.
If we are going to keep calling software construction engineering, can we please at least get industry wide standards around ethics before we go off vibing? There's so much that we still sorely need in order to really make this discipline rigorous and socially accountable in the first place.
Didn't read the article, reacting to the title.
To add as a data point: I've met founders that are business founders and are vibe coding entire businesses with React, Supabase and Netlify.
LLMs allow for amazingly high fidelity interaction designs to receive funding and prove out certain PoCs. Whether his stuff will stay up in production remains to be seen.
I predict that people will end up using the term "vibe engineering" to refer to development processes that involve asking an LLM to build their entire app: UI design, database schema, architecture, devops, QA, debugging, etc, without any of the careful effort to understand and be able to proudly own the resulting code that Simon is imagining.
And I think that is actually the most natural meaning for "vibe engineering", actually: Parallel to "vibe coding" where you serially prompt the AI to write the code for you, "vibe engineering" should be serially prompting the AI to do the entire engineering process for you.
I also predict that a precisely defined term for what Simon is describing will inevitably end up being primarily used by people who are actually doing "vibe engineering". Being disciplined and careful is hard.
People and organizations love to claim/pretend they're doing expensive, mostly invisible work like "building secure software". Given nearly every organization claims they use security best practices no matter what their actual practices, I imagine it will be that way with "actually reading and verifying what the LLM generated for me".
Certainly I've been disappointed how often someone presents something they've "written" in recent months that turns out, on inspection, to be AI slop that the "author" hasn't even read every sentence of carefully.
I think the definition isn’t accurate, it’s more like engineering using AI.
Frankly the most accurate way I would describe what I do with AI is managed programming, or being a handler for the AI.
The only issue with "Handled Programming" is I don't like how it fits for a name.
Vibe is much too unserious to pass my check for a way of professionally doing something and it also does not reflect the level of engagement I have with the AI and code since I'm putting together specs and otherwise deeply engaging with the model to produce the output I want.
How about : AI-assisted programming.
so the progression of human technological revolutions is looking like industrial -> information -> AI -> vibe
No, thank you.
Thank you Simon! Too many people conflate non-engineer vibe coding with engineers using ai to make themselves much more productive. We need different terms!
Isn't that what a meth cook does?
Needless country club chicanery.
I find coding agents to be a powerful throttle on the speed dimension in exchange of quality in the general sense. With tests to ensure correctness is not compromised (not a silver bullet), linter and pre-commit for code style, the byproduct of AI code is utter verbosity. Pleads to be concise don't work – no more than the "Don't be wrong/hallucinate". In that regard, I like Blaise Pascal quote "I have made this longer than usual because I have not had time to make it shorter."
I think this is a pointless distinction tbh. Either you're getting good results from AI or you're not. If you're not, you should probably rethink your approach.
I'd offer a new term: curmudgeon coding. This pre-dates LLMs and is the act of engineers endlessly clutching pearls over new technology and its branding. It's a reflexive reaction to marketing hype mixed with a conservative by default attitude. Think hating on "NoSQL". Validity of said hate aside, it's definitely "a type" of developer who habitually engages in whinging.
vibe engineering, spending so much time writing documentation for the prompt, just to spend more time debugging the slop you get.
Ill stick with writing code and just use AI for snippets/stackoverflow replacement.
I call it "coding". Nobody has ever cared what IDE I use, what documentation, which syntax autocompleter. I don't see why they should suddenly start to care about my tools when they're LLMs.
Vibe coding is different because it's the "dictated but not read" of coding. Yes, I was around when the LLM was writing the code, and I vaguely instructed it on what to write, but I make no assurances on the quality of the output.
Please no. We already have a bunch of (human society) semantic slop from vibe coding term being misused. The last thing we need right now is another poorly developed term
Worse possible name to be honest.
> One of the lesser spoken truths of working productively with LLMs as a software engineer on non-toy-projects is that it’s difficult.
I mean, the AI companies have an incentive to make it easier, right? The next iteration of coding agents will be better at working with their human PHBs to divine intent and turn vague specifications into something workable - a key skill of human engineers.
Is this really any different from how Google learned to understand search queries?
The headline made me think of a bridge designed by an LLM, and I think to myself: thanks, I'll pass.
You sure? I would turn around :)
we could call it "Reasonable AI Liability" like Ruby does ;)
My thoughts:
* There are actual productivity gains to Agentic Coding (my tool of preference is Claude Code)
* There is a big chance of producing a lot of slop if one does not use it with care
* More than ever checking mechanisms are essential (static type checking and a good unit testing suite)
* Everything that was boring and tiresome about unit testing is now mandatory since you will be writing almost none of it.
I am mildly disappointed
I was hoping that "vibe engineering" was going to be designing g bridges in the same way people think they can build apps with vibe coding
That would be alarming
Beautifully put. This puts into words what I was unable to say to those who claim all ai is useless and can only produce slop, if the human is TRULY in control it’s an entirely different ball game. Thank you for this.
I’m glad to see that more and more articles and opinions about AI are focused on how it works and it works great just the process and mind thoughtfulness has to adapt and evolve to fully utilize the tool.
That’s so much better than wasting time on the frustrated who just negate without a meaningful try.
I share most of the experience and learning with the author, I just still don’t know how to name the whole process.
The whole vibe thing has already brought negativity into terminology because of all negating.
Closest thing in history of software engineering practice from the past is XP (Xstreme Programmimg) with its pair programming approach. It was a precursor of anything modern agile. Invented at the end of 90s
It’s just this time, my pair programming mate is computer instead of human person, but I treat it as junior to me and review, organize, while coding, testing, documenting is delegate and we jointly do the analysis as a part of the discussion.
I can agree, it’s strongly augmented experience and weird often to newcomers to adapt, but when a critical path to succeed is discovered, it works great and results are a blast!
I agree with your analogy with pair programming. Except that now your co-developer types way faster!
These words just don't belong together, period.
Centaur Coding.
Please stop with all this vibe bs. Seems like a desperate attempt at getting viral.
> I propose we call this vibe engineering
Seriously? The term has been around in the community for as long as "vibe coding" has been around. While both sound equally cringe, the statement leaves a bad taste.
Nah.
Software engineer.
Not vibe engineer. Not Java engineer. Not compiler engineer.
You either understand the computer and then can apply any fucking tool or methodology to solve a problem, or you’re out.
Can we please just call it model driven development? I already hated the distortion of "vibe" as it got distorted from Karpathy's original meaning.
This has to be a joke. Real engineering has a requirement of personal liability of the engineer involved. There is zero personal liability in the software which is why it's not real engineering. Until a software developer has to be held personally liable for the code they write and test, then they can call themselves an engineer. Back to vibe engineering, if ever personal liability were required then any AI slop in code would vanish instantly.
Thanks for the AI slop blog content
Welcome to me 13 years ago when India happened. Nobody cared back then. So I just left.
Marvelous, now all we need is "vibe civil engineering".
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
Just reading that exhaustive list of what you supposedly need to do to "be successful" with the non-deterministic-random-text-generation tool shows clearly this is a solution in search of a problem. As engineers we need to principally reject what the disconnected billionaire class are currently pushing on us with these non-tools and this is not, I want to stress that, not because we fear "replacement" - I don't think these machines can replace even the Joe Bullshit in powerpoint generation, as evident from the recent case with Deloitte in Australia. The reason is more profound - these tools endanger the quality of not just engineering, but also outputs in other fields and as such are plain dangerous to the society. If this is supposed to be the future of engineering, then doors falling of Boeings will be but funny anecdotes of "better times" I am afraid. No, this cannot be the future of engineering and in general professional work, unless we want to become again disenfranchised and ignorant serfs.
Amen brother. Other engineers directly recognize the duty they owe to society beyond the duty they owe to any particular company, they have certifications boards and ethical standards for precisely this reason.
It's high time software engineers do the same if they really want to be engineers and not just corporate lackeys who happen to know how to program and/or design computational systems.
"Vibe coding" sounds too good. Catchy, ridiculous and still cool. It'd be hard to beat. It's a genius move from Andrej Karpathy.
Different strokes I guess. I've always thought it sounded pretty stupid (right up there with asshat and awesomesauce). Conjures up an image of the Big Lebowski writing code while listening to a cheech & chong album.
I feel like “memetic” is probably the best descriptor, you either love it or hate it but either emotion is a good way for something to stick in your brain.
I am on the stupid side, personally.
Yes, that exactly. If you have to read the code or the manual, you’re not vibe coding. I think vibe coding is super good for the industry and people in general.
Except that we're not going to be "coding" very soon. We're going to be firing off jobs that get tracked in VCS, gated through CI, then reviewed by a panel of agents with different specialties. At the end you'll have a few select sections of code that these agents flagged for human review, and thousands of lines of stuff that you don't need to worry about.
This guy selling AI snake oil btw. In case it wasn't obvious.
Why the hostility? We can have a civil discussion without relying on throwaway accounts.
[flagged]
This isn't X, please maintain community standards.
Then it turns out that your CI gates are green because your tests are all subtly broken, the code you've been reviewing doesn't matter and the code you haven't been reviewing is what's broken in production. You learn from that and rebuild the universe, but now you're compute-limited from rebuilding your agents to deal with the underlying issue in your tooling and you have to dig yourself out of a hole you dug with a large derrick using nothing but a shovel.
That's absolutely one possible outcome, just like when manually coding you have a team that doesn't know what they're doing and doesn't build anything close to what the customer wanted. YOLO'ing development has never worked, there's skill in everything.
You can offer Chatgpt 7 for free, I’ll never use VCS. If it ever get that powerful I’ll instead tell to recreate it without the bloat and battery drainage.