AI will improve the lives directly of people who work in that field or apply it profitability, so naturally we're enthusiastic.
Whether the products of those efforts improve the lives of other people remains to be seen. In many ways, and like all other technology, the current use cases have both wide benefits and equally wide downsides.
This is fascinating, useful, and slightly terrifying. I definitely want to try sending a screenshot or console logs on command but I'd want to be the one deciding exactly when that happens and in the context of what other prompt. I often say things like, "You can see how..." and I want to be sure that goes with only the screenshot(s) I want.
Because Cursor goes off the rails easily with even a medium sized amount of context, I'm a little leery of letting it include ongoing screenshots or console logs during a thread.
Hey - it doesn't send the logs and screenshot automatically at any point. All control is in your hands
You can send those on-demand with a mouse click / keybind whenever you want
And there's no server game here either. So no latency issues, context issues, and no worries about privacy either
Btw it's my first time on hackernews and idk if I get notified about anything here, so missed your comment by 2 days. Sorry about that. Feel free to share your thoughts on our discord here so we can have a better conversation about this: https://discord.gg/cyA7NpTUQS
Very true. A couple years ago I designed a custom card game and had it manufactured in China, just a small run. It was already hard to make any profit on a small indie item like that. A bigger tarrif would have priced me out completely when the consumer looks at the price of Uno on the shelf that MB can make for $1/deck and I can't get anywhere near that.
The US game industry is horrified by this. As the largest market for games, reduced purchases in the US affect everyone who works in the business -- one that is already the poster child for layoffs.
Anything that punishes the games business in the US can only hurt the US more than other countries. It would be ideal to build game consoles here and we could and should. We invented all the fundamental technologies behind computer hardware, software, and video games. There must be a way to attract that business back here with a carrot rather than a stick.
Why would it be ideal for the USA to build consoles? The Asians build the hardware, the Americans make the software. That’s exactly the kind of specialization and efficiency that trade is all about.
I agree and it worked as long as that carve-out were permitted. But if we want to make that stuff here, we certainly can and every community targeted for such a factory would welcome it.
Working class Americans lived their highest standard of living when more physical things were made here. We still have that option.
That’s basically what the IRA was but for renewables and battery technology. The same states that benefited from it (red states in the south) voted against it in the last cycle. It’s crazy.
This is an excellent article but starts out with the false dichotomy of vibe vs craft programming.
An alternate term is starting to appear, flow coding or agentic coding, where the tool is supervised and direced into coding precise areas under human architectural control, with all the programmer understanding that entails.
The author hints at this idea toward the end and likens it to a skilled builder who uses tools to make a precise part.
It's basic and confuses uses abstractions with not knowing fundamentals.
It goes into all the common places of "AI will replace you if you don't think" and pretends you fundamentally don't reason or think if you interact with an abstraction or AI.
The examples are so rudimentary that I very much suspect this person is not particularly good at software engineering.
People will read this title and comment because doom posting about AI is what people want to do if they're uncertain about "losing value" but it's very low quality.
I do agree that in the end the most productive approach will be a mix. Humans with AI support. My fear is on the possibility that learning to program always with AI support, will limit the quality of learning. Only time will tell.
Honest question, do you think this will lead to more work for “hands-on” programmers to fix errors, or this could just be the early stages of agenic coding becoming better and more akin to the best (or close to it) “hands-on” programmer?
Market forces will drive the outcomes in different sectors.
In aviation-minded companies, human-reviewed guardrails will always be in place, some may eventually decide to might as well have humans write the whole thing to begin with to keep it end-to-end auditable.
In automotive-minded companies, "chabuduo" is the norm and agentic may be "good enough if it appears to work" and only involve humans when visible crises surface, in which case the most desired programmer are those who can churn.
The shocking part of this story is not that you could vibe code a note taking app in a week, it's the idea that it would cost $300 in LLM agent fees!
That's too much and speaks poorly of both the tool he chose and the vibe approach. A more experienced programmer wouldn't have used $300 worth of credits building this.
That and the fact that most of those AI-generated web sites are clones of the thousand of applications that already exist, except that they now require an internet connection and a Google account for some reason.
His tool looks like a sticky note application with some Markdown inside. I'm pretty sure there are plugins that already can do this on Obsidian or any other text editor. It's funny to try to "vibe it" yourself but it's really useless in the long run since you'll be the one who will maintain it compared to the other projects with a good community behind.
100%. I love DIY software but I only build it if it's going to be better that what's already out there. And the "better" part has to include maintaining, extending, and deploying it. Those are the parts a non-dev won't want to do. Heck, I don't want to do it either (that's not the fun stuff), but flow coding or pair programming with an agent makes that part easier.
That's like asking how to make money on the internet. The answer is to integrate it into something you already know how to monetize -- an area where you already have expertise.
If you work in software, this would be figuring out how to include AI in the kind of software you make (for the user; RAG) and in your process (agents).
There most definitely is. You can ask Cursor to do both those things, for example. It's often faster at it than a person. That said, "vibe coding" implies a hands-off approach that definitely doesn't work.
Write them? Unquestionably. Have them be the basis for "is my vibe coded app doing what the product owner expects?" is where reasonable people have differing opinions
Not to be dismissive, but we could describe all of programming this way. Since computers just run machine code and deal only with simple math and swapping memory and storage values, all of our code is just "reframing" the problem in different ways. We pick the language or abstraction that's easiest to work with for what we're trying to accomplish, like you did with picking the "HSL" language over RGB. In reality, both will be converted to binary values in storage and voltage levels in your monitor.
While trivially true, I think the question has merit as some of these reframings are more interesting than others.
In physics for example, Lagrangian mechanics[1] is an interesting reframing of classical physics allowing for drastically simpler implementations in certain cases, while still just being a bunch of partial differential equations and numbers.
In engineering and signal processing, the Laplace transform reframes time-varying signals such[2] that it's much easier to calculate or design the resonse of a system.
Back in programmer land, several such useful reframings that aren't directly rooted in physics or linear algebra that I can think of come from crossing the functional-imperative border.
Another is inversion of control[3], in the general sense[4], where you pass the code modifying the behavior, rather than explicitly drive the modified behavior from the outside.
reply