Thanks for the AI slop blog content
Vibe engineering
301–310 of 759 posts
Re: Vibe engineering
#302Earlier quoted context omitted.
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 too…
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?
Re: Vibe engineering
#303I 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 f…
It’ll be the greatest episode of sunk cost fallacy 5 years from now.
Re: Vibe engineering
#304> 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...
Re: Vibe engineering
#305Earlier quoted context omitted.
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 t…
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.
Re: Vibe engineering
#306Earlier quoted context omitted.
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 di…
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.
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.
Re: Vibe engineering
#307I 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.
Re: Vibe engineering
#308Earlier quoted context omitted.
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".
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.
Re: Vibe engineering
#309I 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 f…
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.
Re: Vibe engineering
#310[dead]