You knew exactly what you wanted, since you already built it. All decisions were already made, all tradeoffs reached. LLMs are definitely helpful, but try exploring something new with them and you'll slow down significantly.
Most of my time these days is learning about domains, not technical skills. I keep programming books around for references, but the books I read most are books that go deep into some domain, either technical like operating systems or network, or soft skills like planning, design and communication.
It’s kinda the old saying about $900/hr expert that only taps with an hammer. The price is not about tapping, it’s about knowing where to tap.
Not to mention the poster understands what the output is, what it's supposed to do, and can judge that it is the thing that they intended to build.
But this has always been a developer's work, it's understanding what is needed, translating it to working software, and judging the result, and doing so at scale, over time, and with other people.
Yes, and that's also why I'm really effective at using AI when the context is one I'm comfortable with. Still - it doesn't feel like I'm actually doing anything. The product was never the goal for me. The craft was. I feel like someone who always loved to be a blacksmith who is now in charge of a production line of 10 CNC mills that produce coat hooks. The fact that I know what makes a good coat hook doesn't really help make it a job I don't really enjoy.
I am a Freelancer who has worked the last ten years on Embedded/Containerized Linux Systems. Last project (~5y) included evaluating and moving an existing product from Linux Network Stack to high-performance DPDK based solution.
I have a weak spot for Go; In my free time I explore using it in an embedded context. Have a look at https://www.github.com/clktmr/n64
This just shows how bad search engines have become. About 15 years ago you could type fully worded questions into Google and would be pointed to the exact sentence of a website that answers your question. I happened so slowly, we were all frogs in boiling water.
An the same will happen to AI. We will remember these days as the golden age for AI, where you weren't required to prompt an AI three times before it answers with a non-ad response.
It took the mass public a long time (15 years?) to realize search engines had shifted from the former to the latter, and that allowed Google to leverage that misplaced trust into huge profits.
Expect commercial AI to be the same, unless it's explicitly set up otherwise (read: Kagi assistant).
This reminds me of an old video about a guy that got invited to stay in the penthouse suites of casinos. In the video, he has a 'friend' who organises these trips for him (the friend works for the casinos).
This guy couldn't recognise the conflict of interest, and neither will 80%+ of AI users.
You're right but I think AIs can be better than Google at it's height.
But whether it's search or AI-chat, what's annoying is efforts to have it replace that things that exist rather than serving as useful addition. I use ChatGPT X many times a day (or hour) but unless I ask for an AI's opinion, I don't want it.
> Agents, by making it easiest to write code, means there will be a lot more software. Economists would call this an instance of Jevons paradox. Each of us will write more programs, for fun and for work.
There is already so much software out there, which isn't used by anyone. Just take a look at any appstore. I don't understand why we are so obsessed with cranking out even more, whereas the obvious usecase for LLMs should be to write better software. Let's hope the focus shifts from code generation to something else. There are many ways LLMs can assist in writing better code.
I think we, as engineers, are a bit stuck on what “software” has traditionally been. We think of systems that we carefully build, maintain, and update. Deterministic systems for interacting with computers. I think these “traditional” systems will still be around. But AI has already changed the way users interact with computers. This new interaction will give rise to another type of software. A more disposable type of software.
I believe right now we are still in the phase of “how can AI help engineers write better software”, but are slowly shifting to “how can engineers help AI write better software.” This will bring in a new herd of engineers with completely different views on what software is, and how to best go about building computer interactions.
the disposeware is here. maybe we can call it spongeware (similar to software) which is like a kitchen sponge, one uses it several times until it starts to break, just to be replaced with a similar but different one...
Sometimes “better” means “customized for my specific use case.” I expect that there will be a lot of custom software that never appears in any app store.
The amount of single purpose scripts in my ~/playground/ folder has increased dramatically over the past year. Super useful, wouldn’t have had the time for it otherwise, but not in any way shareable. Eg “parse this excel sheet I got from my obscure bank and upload it to my budgeting app’s REST API”. Wouldn’t have had the time or energy to do this before, now I have it and it scratches an itch.
This. Just today I added a full on shopping list system to our internal dashboard at work (small business) simply because it was slightly annoying and could be solved in 3 prompts and 15 minutes.
If we take it a step further, in a few years, why would anyone purchase generic software anymore? If we can perfectly customise software for our needs and preferences for almost free, why would anyone purchase generic software from an App Store? I genuinely think Apple's business model is in jeopardy.
Most apps aren’t standalone and the services they depend on are nontrivial to build. For example, maybe you could vibe code a guitar tuner app, but not a ride share app.
I agree. The services which will be left standing will be those with a competitive moat: critical mass (Tinder, Facebook), content (YouTube, AppleTV), and scale (frontier AI models requiring expensive hardware), etc.
That said, if you look at the apps on your phone, I wager a large proportion don't have these moats. Translation, passwords, budget, reminders, email, to do, project management, messaging, browser, calendar, fitness, games, game tracking, etc.
Customization often turns out to be a long term liability. Funnily enough, my employer learned this 20 years ago with our ERP and we are still paying the price.
That's not what Jevons paradox means though. He's just name dropping some concept.
Jevons paradox would be if despite software becoming cheaper to produce the total spend on producing software would increase because the increase in production outruns the savings
Jevons paradox applies when demand is very elastic, i.e. small changes in price cause large changes in quantity demanded. It's a property of the market.
> Agents, by making it easiest to write code, means there will be a lot more software.
He's saying that agents make code much cheaper, therefore there will be a large increase in demand for code. This appears to be exactly what you're describing.
> I don't understand why we are so obsessed with cranking out even more... the obvious usecase for LLMs should be to write better software
I honestly think this is ideal. Video games aside, I think one day we'll look back and realize just how insane it was that we built software for millions or even billions of users to use. People can now finally build the software that does exactly what they've wanted their software to do without competing priorities and misaligned revenue models working against them. One could argue this kind of software, by definition, is higher quality.
I don't think this will be true for average consumers. Perhaps for nerds like us, who enjoy a bit of tinkering and can put up with weird behaviors. I mean, are you envisioning that everyone would have their own custom messaging app, for example? Or email? Or banking app? I mean, I think most people's demands for those things are all extremely homogenous. I want messages to arrive, I want emails to get spam filtered a little but not too much, and I want my bank to only allow me to log in and see my balances, etc.
I could see maybe more customization of said software, but not totally fresh. I do agree that people will invent more one-off throwaway software, though.
> Perhaps for nerds like us, who enjoy a bit of tinkering
Tinkering? Even today, people don’t need to understand software. They just need to be able to describe their problems and goals to create an app.
> I mean, are you envisioning that everyone would have their own custom messaging app, for example? Or email?
Well first I think there’s a good chance that most apps as we know them today won’t even exist, and most “apps” will be tool use on APIs. But even then, shopping apps, for example, could be so highly personalized that no two people have the same one.
> I mean, I think most people's demands for those things are all extremely homogenous.
They aren’t, as evidenced by the fact there are many dozens of popular messaging apps with millions of users. Despite the network effects for a messaging app to even be viable.
Also, I’m not talking one-off throwaway apps… these are living, breathing pieces of production-grade software users will mold to fit their needs and evolve with them for years.
> Let's hope the focus shifts from code generation to something else. There are many ways LLMs can assist in writing better code.
My view is actually the opposite. Software now belongs to cattle, not pet. We should use one-offs. We should use micro-scale snippets. Speaking language should be equivalent to programming. (I know, it's a bit of pipe dream)
In that sense, exe.dev (and tailscale) is a bit like pet-driven projects.
The most recent software paradigm has been SaaS - software as a service. Capex is distributed among all customers and opex is paid for through the subscription. This avoids the large upfront capex and provides easy cost and revenue projections for both sides of the transaction. The key to SaaS is that the software is maximally generic. Meaning is works well for the largest number of people. This necessitates making tough cuts on UX and functionality when they only benefit small parts of the userbase.
Vibe coding or LLM accelerated development is going to turn this on its head. Everyone will be able to afford custom software to fit their specific needs and preferences. Where Salesforce currently has 150,000 customers, imagine 150,000 customers all using their own customised CRM. The scope for software expansion is unbelievably large right now.
SaaS is not a new idea and has been renamed multiple times.
In the 70s, it was called "time-sharing". Instead of buying a mainframe, you got a CICS application instance on a mainframe and used that. (tangentially, spare time on these built-out nation-wide dialup-supported networks is what gave birth to CompuServe and GEnie).
In the dot-com era, it was called "application service providers". Salesforce and actually started in this era (1999). So did NetSuite. This was the first attempt to be browser-based but bandwidth and browsers sucked then.
I think PaaS is a more recent software paradigm, albeit a far less successful one.
There will be only 1 Microsoft® Excel, 1 Google Sheets and 1 LibreOffice and the rest are billions of dead vibe-coded "Excel killers" that no-one uses.
Except that list originally had one item, and that item was Visicalc. Times change, but that list is going to stop being relevant before Excel gets knocked off the list.
If you're doing anything complicated, Excel just doesn't make sense anymore. it'll still the be data exchange format (at least, something more advanced than csv), but it's no longer the only frontend.
"No one uses" is no longer the insult it once was. I don't need or want to make software for every last person on the world to use. I have a very very small list of users (aka me) that I serve very well with most of the software that I generate these days outside of work.
> "No one uses" is no longer the insult it once was.
It certainly is for lots of businesses, otherwise they go out of business.
There is something called 'revenue' which they need to make from customers which are their 'users', and that revenue pays for the 'operating costs' which includes payroll, office rent, infrastructure etc.
This just means that it is important than ever to know what to build just as how it is built. It is unrealistic for a business to disregard that and to build anything they want and end up with zero users.
Oh is that how it works? This "user" concept. Is that like a "customer"? Do they enjoy being talked down to? Are they excited to give money to people who treat them like that? I suspect you're not as good as you think you are at this business thing.
My intuition is that agents lift up the floor to some degree, but at the same time will lead to more software being produced that’s of mediocre quality, with outliers of higher quality emerging at a higher rate than before.
Humans have been making quality versus quantity decisions since the time we first grew these big giant brains of ours a million or two years ago, maybe longer.
If you wanted to, you could make an argument about the principal-agent problem - that as hunter-gatherers or subsistence, farmers, our quality versus quantity decisions only affected us, whereas in a market economy, you could argue that one person’s quality versus quantity decision affects someone else.
But dismantling capitalism will not solve this problem. It just moves the decision-making to a different group of people. Those people will face the same trade-offs and the same incentives. After the Revolution, even the most loyal comrade will have to contend with the fact that they can choose to provide the honourable working class with more of a thing if they drop the quality.
Big agree. I would love the focus to be on contributing, improving, and consolidating around existing open-source solutions. Unfortunately, most AI-enabled contributions have been slop and the maintenance burden of open source has increased
I've written a fair amount of code for EmbeddedGo. Garbage Collector is not an issue if you avoid heap allocations in your main loop. But if you're CPU bound a goroutine might block others from running for quite some time. If your platform supports async preemption, you might be able to patch the goroutine scheduler with realtime capabilities.
The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.
Not me. I typically merge main onto a feature branch where all the conflicts are resolved in a sane way. Then I checkout main and merge the feature branch into it with no conflicts.
As a bonus I can then also merge the feature branch into main as a squash commit, ditching the history of a feature branch for one large commit that implements the feature. There is no point in having half implemented and/or buggy commits from the feature branch clogging up my main history. Nobody should ever need to revert main to that state and if I really really need to look at that particular code commit I can still find it in the feature branch history.
This is what I do, and I was taught by an experienced Git user over a decade ago. I've been doing it ever since. All my merges into main are fast forwards.
The advent of coding agents killed Hacker News to some degree for me. Before I could always come here to get a pause from the hype, scandal and bait. Top comments were usually insightful; I really had this feeling to learn while browsing the feed. Today every brainfart about AI makes it to the frontpage. I know this sounds very dismissive, but most pieces really have no substance at all.
The good content is still there buts it drowns in noise and I'm not very good at filtering it out. I even suspect Hacker News is one of the prime advertisement targets of coding agent companies.
I would love to see if this is just my perception or if it can be found in the data.
Personally I don't care about what news articles end up on the front page - it's AI now, but there have been other trends in the past that did the same.
The bigger problem is the effect that it's had on "Show HN" postings, which in the past were things you could depend on were built by the person submitting it. That's why those posts tended to be more strongly moderated, because they often were seen as attacks on the person's art. Now I feel like most of the credibility has left the room on those posts.
Don't get me wrong - I have no problem with "vibe coding". I do plenty of it myself these days, for commercial purposes. But I feel it cheapens and waters down someone presenting work as their own.
A project was one of the easiest ways to evaluate a stranger. It was a great bullshit detector. If they can make something like this then they are probably someone with ability and experience and so the rest of what they have to say is probably worth listening to. But I also agree with the parent. HN seems to be flooded with hustle and rubbish since AI has taken off. It's eternal LLMber.
I wonder if the marketing/hustlebros who only value our art as a "get rich quick scheme" (IE: the people pushing "Learn to 'code' (I hate the term 'coding')and half the new faces from india) learnt about Show HN and decided to ruin something good by making a linkedin post about "how great of a marketing avenue" we are and the vibecoded slop pushers listened in full force because they know nothing about our industry and thus don't know how valuable a non-salesy place to talk trade is
I'm just going to wait it out, as these trends come and go; before AI it was Rust, before Rust it was IoT, before IoT it was big data, crypto was weaved through it, etc.
tl;dr of the essay, we need to move back to human-to-human recommendations and trust systems, and people are already doing that a lot of ways by retreating to DMs (iMessage, email, in-person conversations) and personal recommendations rather than relying on Google + the algorithm. What this means for public forums I don't know. I think they're gone and will never come back, probably.
It's probably in their interest to have as many vibed codebases out there as possible, that no human would ever want to look at. Incentivising never-look-at-the-code is effectively a workflow lockin.
I always review every single change / file in full and spend around 40% of the time it takes to produce something doing so. I assume it's the same for a lot of people who used to develop code and swapped to mostly code generation (since it's just faster). The spend I time looking at it depends on how much I care about it - something you don't really get writing things manually.
reply