I recently exclaimed that “vibe coding is BS” to one of my coworkers before explaining that I’ve actually been using GPT, Claude, llama (for airplanes), Cline, Cursor, Windsurf, and more for coding for as long as they’ve been available (more recently playing with Gemini). Cline + Sonnet 3.7 has been giving me great results on smaller projects with popular languages, and I feel truly fortunate to have AWS Bedrock on tap to drive this stuff (no effective throttling/availability limits for an individual dev). Even llama + Continue has proven workable (though it will absolutely hallucinate language features and APIs).
That said, 100% pure vibe coding is, as far as I can tell, still very much BS. The subtle ugliness that can come out of purely prompt-coded projects is truly a rat hole of hate, and results can get truly explosive when context windows saturate. Thoughtful, well-crafted architectural boundaries and protocols call for forethought and presence of mind that isn’t yet emerging from generative systems. So spend your time on that stuff and let the robots fill in the boilerplate. The edges of capability are going to keep moving/growing, but it’s already a force multiplier if you can figure out ways to operate.
For reference, I’ve used various degrees of assistance for color transforms, computer vision, CNN network training for novel data, and several hundred smaller problems. Even if I know how to solve a problem, I generally run it through 2-3 models to see how they’ll perform. Sometimes they teach me something. Sometimes they violently implode, which teaches me something else.
> That said, 100% pure vibe coding is, as far as I can tell, still very much BS.
I don't really agree. There's certainly a showboating factor, not to mention there is currently a goldrush to tap this movement to capitalize from it. However, I personally managed to create a fully functioning web app from scratch with Copilot+vs code using a mix of GPT4 and o1-mini. I'm talking about both backend and frontend, with basic auth in place. I am by no means a expert, but I did it in an afternoon. Call it BS, the the truth of the matter is that the app exists.
People were making a front and backend web app in half a day using Ruby on Rails way before LLMs were ever a thing, and their code quality was still much better than yours!
So vibe coding, sure you can create some shitty thing which WORKS, but once it becomes bigger than a small shitty thing, it becomes harder and harder to work with because the code is so terrible when you're pure vibe coding.
> People were making a front and backend web app in half a day using Ruby on Rails way before LLMs were ever a thing, and their code quality was still much better than yours!
A few people were doing that.
With LLMs, anyone can do that. And more.
It's important to frame the scenario correctly. I repeat: I created everything in an afternoon just for giggles, and I challenged myself to write zero lines of code.
> So vibe coding, sure you can create some shitty thing which WORKS (...)
You're somehow blindly labelling a hypothetical output as "shitty", which only serves to show your bias. In the meantime, anyone who is able to churn out a half-functioning MVP in an afternoon is praised as a 10x developer. There's a contrast in there, where the same output is described as shitty or outstanding depending on who does it.
There's an ambiguity here between palindromic words and palindromic sentences (where punctuation and spacing are non-breaking):
"Go hang a salami, I'm a lasagna hog"
or
"A man, a plan, a canal, Panama"
though it seems that all of the answers (in the one tutorial and one round that I played) are single words, often slid in as character insertions. Just go light on the spacebar, apparently.
It’s actually just jargon-ified. When pressing a piece of sheet metal into a die (concave form) with a punch (convex form) to stretch and compress the metal into a deep shape (e.g., a cup, can, etc.), using ultrasound to induce some wiggles can reduce the chance of tearing, likely allowing for less material use and greater yield rates for a machining process.
Basically, if you’re forming metal with high force, give it some high speed micro-wiggles and things will be better.
This should feel pretty natural for folks who have tried to squeeze into skinny jeans after Thanksgiving.
There’s a pleasantly elegant “hey, we’ve solved the practical functional complement to this category of problems over here, so let’s just split the general actual user problem structurally” vibe to this journey.
It often pays off to revisit what the actual “why” is behind the work that you’re doing, and this story is a delightful example.
I wrote an arbitrary precision arithmetic C++ library back in the 90’s. We used it to compute key pairs for our then new elliptic-curve based software authentication/authorization system. I think the full cracks of the software were available in less than two weeks, but it was definitely a fun aside and waaaay too strong of a solution to a specific problem. I was young and stupid… now I’m old and stupid, so I’d just find an existing tool chain to solve the problem.
That’s really the core problem here. As is often the case with rent control models, the natural outcome of an incentive structure came to pass in spite of the best intentions of legislators/regulators.
Yep. Government-imposed price controls and caps should actually be illegal. Like actually unconstitutional, with the requisite constitutional amendments in California (and the other States) and the US Constitution being passed.
No matter what anybody’s intentions are, they always end up creating market distortions that eventually lead to more societal issues than the ones they’re suppose to alleviate and it’s just bad economics that shouldn’t even be a tool in politicians’ (or voters, but ballot box lawmaking should be illegal too) toolboxes so they’re forced to address the upstream concerns that cause prices on land, housing, rents, services and goods to climb to the point of being unaffordable to most of the population.
However, state and local agencies undertake prescribed burns regularly. To be fair, clarity (read: honesty) from political figures on this topic (and others) is at an all time low.
I once had my boss at a new job sit me down, a couple of weeks into the job, and tell me "Matt, we have a pace that we work at, and we need you to work at that pace... If leadership gets the idea that we can deliver at a much faster pace, they'll expect it from us all the time." By the time I quit that job, I was able to finish my whole week's work before lunch on Monday. Then I'd just spend the rest of the time working on exploratory projects to stay sharp. So I've seen the utterly pathological version of Parkinson's law. However...
Shipping the wrong thing fast is just shipping the wrong thing, and it's a natural impact of trying to squeeze blood from a stone.
I often give something along the lines of this lecture:
You're trying to solve a $5M problem for $1M, so you're going to push people to make poor choices that don't actually address your problem, and it's going to end up costing $10M after they back up the train and re-lay the tracks. In many cases, the "shortcuts" that teams jump to end up being "longcuts" that drag the program out due to being insufficient to address all of the feature requirements, unplanned due to rushing, etc.
Basically stating the fact that people fail to see the value in reinvestment of time and resources for improvement. Being Idle is not a failure but a way to think and be ready if a period of higher intensity comes. And it is healthy to have sometimes more time for a menial task.
People get so crazy about the idea of optimization, but fail to account for severe issues that arise when time is always occupied by something, which seems to happen more and more these days...
> Matt, we have a pace that we work at, and we need you to work at that pace... If leadership gets the idea that we can deliver at a much faster pace, they'll expect it from us all the time.
Work/life balance is a part of the compensation package. If you suddenly start expecting your employees to work harder, the most talented ones will simply jump ship, because from their perspective, if they're already forced to spend long hours on complex projects, why not at least do it for lots of money. So the only people who stay will be hard-working ones, but less skilled. Meanwhile, in a healthy company, you need a mix of people willing to do demanding, yet simple work, and those who rescue a dumpster fire of a project and then take five coffee breaks.
On the other hand, if you expect your employees to produce every week only what they can do in an afternoon and no more, many of the most talented ones will also jump ship, because they are motivated by accomplishing high-quality work.
It may have less to do with talent than motivation. Motivations people can have at work (and many can and do have a combination in different proportions) can include: making as much money as possible; doing as little work as possible; producing as high-quality work (in their own opinion) as possible; recognition from others for contribution; social relationships and/or being liked; learning new things and developing new skills; being challenged; not being challenged; being part of a collaborative team working well together or being left alone to work independently; etc.
But I think few "most talented" people would last very long at workplace GP described, where doing more than a half-day's worth of work in a week was restrained.
Intrinsic motivation can be better than extrinsic motivation. Google won a lot of fans and dedicated employees with its original version of 20% time that encouraged people to find stuff they were highly motivated to want to work on and could do so relatively safely in the company's sandbox. It is possible this sort "everything the company needs you to do can be done in one afternoon each week" could be an incredible "80% time" company. There are lots of people that would find "80% of my time at the company is my own" to be quite motivating.
Of course, certainly not in the example scenario above where one layer of management is effectively lying to another layer. That's not a healthy "80% time" when it involves duplicity and covert play acting.
But if you were feeling crazy enough to try to build an overt "80% time" company you likely wouldn't have a hard time finding some of the "most talented" people.
That's certainly how Xerox PARC is described in some of the tales of their classic discoveries/inventions/Demos.
Certain decades of Bell Labs, too, have that glimmer of a bunch of the smartest people allowed to explore stuff they cared about with only the oversight from fellow technical people.
I've even heard Microsoft Research can still sometimes feel a bit like that, though with all the pressures of academia like grant finding and patent applications and other such hustles.
This. Motivation is the key to getting employees to produce over a period of time. Give the good ones the maximum amount of ownership they can handle and they will set an example for everyone else. Grow the talent over time.
Fire the whinny shit-talkers as soon as possible. They drag everyone down.
> if you expect your employees to produce every week only what they can do in an afternoon and no more
... then they will have time to fix problems that arrive randomly, rework the parts of their work they got wrong on the first try, and study and train to stay sharp to do the next piece of work. Ironically, all of those will make them produce their next piece of work faster, making this one "problem" worse and worse.
But I left the real benefit to the end... those people will have enough time to think about how they can work into improving something on their workplace. You know, the people that actually do the work, how they can apply the work they know about, because they do it, instead of people that know nothing about it being specialized in thinking how to apply other people's work.
The GP saw a good manager trying to keep his people safe from a dysfunctional organization. The dysfunctional organization is a read flag, for sure, but it doesn't automatically mean the environment is a bad one.
Good software shops leave a good amount of "slack" time for their engineers. It's how you handle shit hitting the fan without burnout.
I currently work on a team that has been basically solving multiple crises per year for years now. In the blips where we've returned to normalcy, we didn't push hard. Because we knew that was time to recover because another crisis was definitely coming.
The crises were external / due to leadership being aggressive without our input..so at that point, all you can do is execute. And part of executing is resting.
Sandbagging is a superpower within reason under many circumstances. Most people would much prefer to get a quality promised deliverable on time or a bit early even if it's a bit longer than they would have preferred in an ideal world. (And, if they really do want to pull something in, you sigh and say you'll do your best but no promises.) If something really has a hard aggressive deadline, OK maybe.
But usually it's a case of it will probably take me this long to do a task. But there are some unknowables and someone I might have to lean on could have a sick kid for a couple days. Generally, everyone is happier if you underpromise and overdeliver including you.
An engineering manager I used to work with would drive me crazy because he had this idea of 90% schedules he got from somewhere. Which basically meant there was a 90% chance of meeting the schedule if nothing went wrong. (Which naturally mostly never happened.)
Sandbagging can also lead to nothing ever being worth doing.
Of course, it is shocking how many projects are started without anyone knowing anything other than the end date.
In my view, if the project is of such marginal value that a precise estimate is needed, don't even start the project - instead, find something more valuable to work on.
Maybe that's true of major projects, especially when there are maybe unknown unknowns. (And maybe not.) But there are a ton of deliverables that should be fairly predictable that come with people who have downstream dependencies on them. (Promotion, launch plans, etc.) When something is late it can cause a lot of scrambling and wasted time/money.
[And just to add, I'm mostly speaking to work I'm creating and delivering--for the most part individually. And to the degree that I'm depending on client reviews, etc. that's in the contract.]
The 90% schedule is not a bad idea, but you need to look at it via metrics - what percentage are you actually meeting that schedule? If you are not doing so 9 out of 10 times, you are at a 20% schedule or a 10% schedule.
No, it’s because Kirk respected Scotty and gave him leeway.
Picard is the meathead, if anyone, and actually watching all the episodes in detail and figuring out their characters you’ll realise that Kirk is twice the scholar and then some Picard pretended to be, especially accounting for the movies and later series. Kelvin timeline doesn’t count, of course.
I would say that it's practically a worse situation. They aren't just ignorant, but willfully so because of a lack of measurable consequences for most. Even worse when there is market capture.
In a distributed setting where a me may wish to join the party late and receive a non-forged copy, it’s important. The crypto is there to stand in for an authority.
> In a distributed setting where a me may wish to join the party late and receive a non-forged copy, it’s important. The crypto is there to stand in for an authority.
Yeh, but that's kinda my point: if your primary use case is not "needs to be distributed" then there's almost never a benefit, because there is always a trusted authority and the benefits of centralisation outweigh (massively, IMO) any benefit you get from a blockchain approach.
100% agreed there. A central authority can just sign stuff. Merkle trees can still be very valuable for integrity and synchronization management, but burning a bunch of energy to bogo-search nonces is silly if the writer (or federated writers) can be cryptographic authorities.
reply