851–860 of 958 posts
For me the distinction is the quality and rigor of your pipeline. Vibe coding: one shot or few shot, smoke test the output, use it until it breaks (or doesn't). Ideal for lightweight PoC and low stakes individual, family or small team apps. Agentic engineering: - You care about a larger subset of concerns such as functional correctness, performance, infrastructure, resilience/availability, scalability and maintainabi…
The disconnect for AI is that it is a jagged frontier and it only really shines when one of its jagged frontiers extends counter to one of your valleys. If you've been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made. If you'r…
When it got dangerous to spend that kind of time without a bullet-point deliverable.
> I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it’s just going to do it right. It’s not going to mess that up. You have it add automated tests, you have it add documentation, you know it’s going to be good. I feel like this is just not true. An JSON API endpoint also needs several decisions made. - How should the endpoint be named - W…
I start by telling the agent what I'm trying to accomplish, and then I throw in some questions like this, concerns I have, edge cases I've thought about, whatever. It goes out and does all the research, both in my code base and beyond, asks me questions where it needs clarification, and then writes me a plan. I review the plan, we go back and forth a bit with adjustments to the plan, and then the plan is ready for implementation. At that point, the implementation is mostly a formality, because all of the difficult parts are already done.
On top of that, most of what you've described as decisions that need to be made are either trivially made by a frontier model without even needing to be told, or stuff I can bake into my skills so I don't need to specify it on every task.
Given the above, I can't fathom an approach where I'd be faster without AI than with it, because the acceleration is the planning / decision-making, not the implementation. Whether the implementation takes the agent two minutes or six hours really doesn't matter, because I'm not involved at that point.
"I want professionally managed software companies to use AI coding assistance to make more/better/cheaper software products that they sell to me for money.” (Simon Willison herein quotes Matthew Yglesias) - this is such a naive and sloppy take. What do you want? "better software"? not going to happen. "cheaper software"? not going to happen either. "more software"? for sure, but is it really what you want? If I hire…
And on the creation side, I run a SaaS that's taking over a niche market because it replaces a human-powered process with an AI-powered one. Customers switch to me because they get better results more consistently, much faster, and much cheaper.
The disconnect for AI is that it is a jagged frontier and it only really shines when one of its jagged frontiers extends counter to one of your valleys. If you've been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made. If you'r…
I vibe engineer to learn. I am currently doing this with a project to build a Vector DB extension in postgres. Several aspects of this project are very new to me. I don't write any of the code. I have never written a single line of Rust. I do, however, spend a significant amount of time discussing architecture and design with the agents.
I started with well known algorithms (HNSW, IVF, DiskANN, TurboQuant, RabitQ, PQFastScan) and have since moved on to a novel implementation based on fairly recent research papers.
My primary goal is to learn. That is a success and ongoing. A stretch goal is to contribute novel ideas back to the community, which may be useful even if what I build isn't ever production ready.
> The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn’t. No, it was never designed around that. All methodologies of software dev don't focus too much on writing the code, but on everything else: requirement definition, quality, maintenance, speed of integrating feature, scaling the work, ... Personally with…
Literally every single one of these is much, much faster with AI than without. It's not even close.
Earlier quoted context omitted.
A much more charitable framing: people who enjoy the process vs people who enjoy the result. (Though, granted, the results are a lot better if you craft it by hand)
But business people always cared only about thr result. My PM (who speaks like a salesman) only cares about the results. My “head of” same. My ceo same. The only ones who ever cared about the process and quality were us the engineers… if we don’t have that care, well, to hell with everything
Just about everyone cares about process and quality when things start falling apart. And at least with current technology, it seems like vibe coding your way into a large project will inevitably land you in that spot.
Earlier quoted context omitted.
Can AI make developers lazy in new ways? Of course! Why wouldn’t it? I don’t write things in ASM because I can be “lazy” and write 50x more useful instructions with a few lines of a modern language. I doubt I’d be able to write working ASM anymore without a serious refresher. Did newer languages erase my memory of ASM and make me “lazy”, or did my efforts evolve to make use of the newest technology regardless of “los…
> You wouldn't trust an engineer a bridge that an engineer vibe-engineered would you? If it was as easy to stress test/battery test/materials test/etc a bridge as it is to test code - then yes. I'd trust an engineer who vibe-engineered a bridge. --- The problem with mapping digital problems into meat-space is that there is inherently a few orders of magnitude of cost automatically added to anything that happens in me…
The disconnect for AI is that it is a jagged frontier and it only really shines when one of its jagged frontiers extends counter to one of your valleys. If you've been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made. If you'r…
In my view, AI is worst at crossing the rubicon from a 200-line script to a maintainable architecture of ~10kloc. If you already have a decent architecture, adding a new feature is usually fine. If you have nothing and need it to write a 200-line script, that's usually fine. If you need it to figure out a maintainable architecture that will be easy to extend in the future... that;'s where the problems start.
Earlier quoted context omitted.
This is actually my biggest gripe with vibecoding. The single best feature of any programming language is that it is precise. And that is what we throw out?! I favor of natural language , of all things?! We're insane!
That's because very often the precision is just common sense that can be derived, either from general knowledge, or from your existing code.