For me, the dividing line is this question: Do you know what's going on?

You see people brag about how "they" "made" something, with neither the qualifications nor the vision to motivate me to care. If I wanted vibecoded slop, I could just cut out the middle man, like everybody else with a Claude subscription.

But this stuff really does shine when competent people such as myself - an expert, gentleman, scholar, etc. - use it for things like exploring a new topic, rubberducking design ideas, diagnosing problems, and sometimes go the extra mile.

Software projects are full of incidental, boring stuff, and it makes a meaningful difference to be able to say to Claude things like "please compare the performance of these 5 different approaches, and show me your notes". But just like a colleague, it has no clue what your actual intentions are unless you tell it, and you can't communicate those intentions if you don't know them yourself - and crucially, you can't know them if you don't have the expertise to know what you actually want.

This doesn't feel like cheating at all, and I don't relate to the choir of disillusioned programmers who feel demotivated by the introduction of LLMs in their workflow. I mean, maybe their work wasn't all that interesting to begin with? I don't know. I get that it sucks to feel replaceable.

"do you know what's going on" is shallow because I don't know what's going on when I use python. Do you? I mean exactly how the interpreter works, what each optimization is doing and such. I'd guess not in most cases and still it's perfectly acceptable to use technologies that abstract complexity away to a point where the code solution space and how it actually manifests in the hardware are two completely different disciplines.

So I'd expand and say that the line should be drawn at knowing how the architecture works, but also we need a pinch of good faith, because it's not very hard to know when you cross the line of overreaching for AI, and it's usually when you hit a point where your prompts start to look like "previous implementation didn't work, try again" or "that's not what I had in mind" or "bug is still there try fixing again"

I've worked on a couple vibe coded pet projects now. I wouldn't say that I "wrote" them but I would say that I "designed" them and might even say that I "made" them as it took quite a few back-and-forth passes before I was happy with the results. But to your point, one one of those projects I don't fully know "what's going on". Even though I could open the source and grok the code after a brief inspection that's not really the point of that exercise.

On a different note, AI tools have been great at combating corporate bureaucracy! If the Big Man says that all modules need unit tests with 80% code coverage, you can give the agent that task and then move on to more interesting hard-thinks.

Many have said things like “do you know what’s going on in your car while you’re driving?”

IMO, this is a wrong way of looking at things if the job is software engineer.

We aren’t the end user who is driving. They don’t need to know how the car works. It takes them to and from work or their kid’s sports event.

The engineer does need to know how the car works. Sure, there are specializations so someone working on one part of the car might not know how another part works. But, they know how these things work together, at least at a high level.

I’m noticing that without proper planning and architecture, these AIs go off the rails and introduce horrific complexities that are hard to diagnose and even harder to fix.

For some small app that nobody cares about besides me, I don’t really care about the internals much. I can have the agent churn and do fixes and updates.

For something larger that will have end users who rely on the software to work, I don’t think having the agents burning millions of tokens and many minutes on each task is a good way to work.

The strength of AI is that it can work across many files, reading and writing magnitudes faster than any human. Their weakness is that they need direction, otherwise the result is chaos.

I’ve tried various approaches and honestly, I’m back to spending time up front planning the system and doing a little bit of mixed (manual and AI assisted) coding to set the foundation.

A few days or even a week or two of focused writing concise documentation, with enough foundational code that shows how the system is architected, yields tremendous results down the road. Even the AI benefits from it because it knows exactly where, what, and how to change. Every system is unique, that last 10% that separates it from the generic recipe is what matters.

I am not saying that humans are perfect or that I’m some god-tier engineer. I know my limits, and as an AI enthusiast I have also realized where these tools have consistently fallen short. Unfortunately, we must realize that no system is perfect, and humans need to do boring work like planning and proper guardrails because chaos is easy.

Sorry for the long write up/rant.

> If I wanted vibecoded slop, I could just cut out the middle man, like everybody else with a Claude subscription.

I've been thinking about this a lot, and I've been going back and forth on it. Because I do feel similarly, but I don't think the premise is itself quite true:

- It neglects that people often don't do things that they want to - and can - do, and that lowering the activation energy can in fact make a positive difference in things happening vs. not. (i.e. "You could've, but you still didn't" happens all the time.)

- It neglects that tokens are, in fact, limited - especially with the best models.

- It neglects that prompting itself is be a skill that can vary across people in a manner that doesn't have a 100% correlation with their ability to understand or do things manually.

- It neglects that time is limited, even the smaller amounts you have to spend with AI assistance.

- It neglects that sometimes the friction is elsewhere (e.g. setting up the harness and thorough testing of the change might have a lot of overhead), not in reviewing the change itself.

- It neglects that the value of a single isn't binary: some person or AI having said "this looks plausible to me, though I'm not an expert" can still be a better signal than nothing, even if a weak one.

The trouble is, of course, that the humans mailing these out often have a very different sense of which way the balances tip than the reviewers do, so what could be true in theory still often isn't in practice...

>For me, the dividing line is this question: Do you know what's going on?

Not a question a customer can give a clear answer to.

I agree that the question we need to grapple with for the foreseeable future is "Do you understand this code?". If you write it by hand you (very probably) understand it, but if you let the LLM write it then you understand it less. If you let the LLM take over for too long, some inflection point is crossed where you understand a minority of the code base; that's when you notice the water around you is boiling, and your entire industry is fanning the flames.

I don't want to doommax: AI is great, but if we allow ourselves to lose understanding of what our code is doing then we're not doing engineering anymore, we're just doing summoning spells hoping the complexity demon spirit doesn't kill us as a result.