Yep, this. I've seen it coined as "the age of personal software" and I totally agree.
I've built easily a dozen personal apps in the last few months that I have no plans on releasing or sharing, run locally, and solve very specific productivity (or one-off) issues for me.
I would never have spent the time building these apps in the pre-LLM days because the effort wouldn't have been worth the gains.
But now? Sure Claude, build me a MacOS app in Swift that does this exact thing I need. Less than an hour later, it's done.
1. See a vuln domain reported, clone the site.
2. Wait for it to expire and snag it.
3. Republish the site with malware
4. Watch people dither about domain names and stuff instead of taking time to fix things.
Most domains are only like ~$10/year. I already have a handful registered for potential project ideas because they're borderline free, for major vulnerabilities I would do the same.
GitHub.io domains, workers.dev domains, etc are all free domains.
Clever use and abuse of some startups can get you a free domain with a signup package that you can subsequently transfer out, but those are harder to find these days.
Seriously, the bad guys figure this out all the time.
I mean, your productivity gains are relative to your starting point in some way.
If you are already an advanced company filled with skilled people, you may not see the gains that a mid-tier company filled with mediocre seat warmers would see when their "best and brightest" start adopting AI to replace said seat warmers.
The latter is something I’m dealing with and it’s given me some existential angst. An example is a company’s monolith with millions LoC and hacked together. With proper engineering strategies, it could be closer to 100k. Without proper AI tooling, my verdict was let it be. When you have so many developers, PMs, stakeholders who tie their value to the pile of slop and making “engineering” decisions with it, it becomes very unpopular to suggest any refactoring - especially when that refactoring relies on principles that require an understanding of software engineering.
An example: the UI applications suffer from massive amounts of repetitive code. People on hacker news will probably instantly jump to some kind of componentization strategy. More wise individuals probably understand you need to draw a winning strategy before that’s possible. Identify common workflows, from that, identify common components, figure out a parameterization and so on. The footguns are the slop having unintended consequences which fixing might actually cause production bugs by being “features”.
Hypothetical now: a current alternative solution which may exist is two simple detail views (of which there may be 30+ in the application) are 1000+ LoC template files, hand-coded, copy-paste, with all the errors you could imagine. You can get a lot of work from that so people are/could be content just fixing slop with slop and calling it engineering while piling on more features. Maybe it works but it doesn’t allow for much engineering room.
With AI tooling, popular support becomes less necessary - correctness matters more. Instead of galvanizing people to realize this is wrong (and it’s not just a want thing, with offshoring and the general difficulty of software engineering, many people don’t understand these concepts. They are great people but struggle understanding for loops intuitively; I don’t know what to say). Now I can provide my strategy to the tooling and do the decomposition and componentization myself. On top of this, my strategy can be more intelligent and robust because I’m not doing it by hand like concurrently using the API layer as a source of truth to give my agents more context on what the UI was trying to do. The code itself is confused so part of the work is learning the intent behind each module and also capturing bugs that are “features” to prevent regressions. Basically, a clean room rewrite (but we have access to the source code so I know that’s not the exact correct term).
The engineering moat is still there. If I say, “Claude make my UI codebase smaller” it will burn tokens and fail. One day it will succeed but right now it will fail. Likewise if I say “Claude suggest ways to make my codebase smaller”, it may suggest my strategy but it may not capture all the critical wrinkles. LLMs are not good at simplifying so to simplify (which is always a good goal in software engineering as long as the abstractions still hold), requires human strategies when complexity is high enough. Especially in my case where the behavior of the code is almost more emergent rather than engineered.
Then carrying on, hypothetically, I started to devise a system for not only rewriting the UI but the rest of the application (API and DB layer) as well as the corporate processes around the application. This may sound rude but these corporate processes can be disempowering and wasteful. The trick is inversion. First build a conceptual interface around the layer. The model will understand the purpose without understanding or rewriting the internals. This saves context and allows it to do more powerful reasoning by having perspective instead of being in a vacuum. Then when you have bandwidth, use that interface along with all the context you developed working on other modules, to take control. An example, you have a team which is responsible for building and deploying. To build and deploy, you may need to fill out forms, contact layers of people, all to achieve the end of goal of “building and deploying”. Through inversion, you communicate with an agent endpoint that handles communications to that team. Escalating, writing forms, and doing whatever is needed to get the code built and deployed. For all intents and purposes, you are now in control of that process. What used to be, for example, “I want my code built and deployed to QA” -> “message A” -> “message B” -> “write form A” -> “monitor for responses” -> “build triggered” can now be “I want my code built and deployed” -> “activate agent process” -> “build triggered”. This is an application of inversion in a nutshell. AI allows to apply engineering principles not only to our code but corporate processes where applicable.
So in this case, there could be 100+ individuals supporting this application and process. The one or two or three engineers that used to own the development process (more or less) were drowned out yet still responsible for the overall process and integrity of the software. It was an impossible task but now it seems more possible. The existential angst part comes from the all processes that were sprung up to support a reality where this all wasn’t possible.
Last, I definitely do not think the solution is one hundred engineers. If you know the show “Breaking Bad”, I actually find the reality of software engineering to be more like this now. The difference between 60, 90, 95, and even 98 percent purity is staggering. And the chemist who takes the input (money and tokens) and produces the highest quality output (codebase and processes), dominates. Just as in Breaking Bad when Walter White inherently has power, despite all other chemists and structures of authority, because his process had the highest purity output. It’s just business sense and adding more chemists does not increase purity. Output quantity is no longer gated by number of bodies so that argument goes out the window. Mentorship will be key (as in Breaking Bad) and large teams of all-high-quality producers should be put together into super high-thoroughput teams. But for regular operations, prioritize the highest quality output where the input is guided by the highest quality producer because adding more cooks will seriously degrade the output, at an exponential rate.
I've been exploring Chatto as a self-hosted chat UI in my homelab for interfacing with durable agents and it works pretty well so far, although the API is (by the author's own admission) not fully stable yet.
Linked. Also no screenshots, no details. Just a long black page with no substance. Github link form the hamburger menu doesn't work so it's a.... very premature submission at the very least.
As a Lightroom user, I've tried _many_ times to use Darktable, and I've given up every time.
Like so many open source GUI projects, it's clear they have solid technical developers who are building good underlying tech, but they have no one on the project doing any kind of user research or spending time thinking about what good UI/UX looks like.
I think the idea here is that all these reverse-engineering projects are _saying_ they're doing clean room implementations for quasi-legal protection.
So they are claiming to follow the legally protected "decompile -> write spec -> new code from spec only" process but they're likely skipping the "write spec" step, and hoping/assuming that it's basically impossible to prove that they're doing so.
Sure but the idea here is that so many people are doing it, it will be a game of whack-a-mole for rightsholders to go after every single person who is trying this, or forking repos, etc..
And if you get a letter from lawyers, then you tell your agents to write the spec at that point, and you produce the spec..
I'm not saying this is correct or legal, but I've noticed that everyone doing LLM-powered RE these days is stating "clean-room implementation" and my gut tells me that most of them are not actually doing it.
Laws are unlikely to stop indivduals from building vibe-coded clones of commercial software, but they may stop above-board communities from forming around them, and will almost certainly prevent commercial sponsorship of their development.
They may also lead commercial AI companies to severely restrict the capabilities of publically available models, especially in terms of reverse-engineering, which is a cost that could be far greater than the value provided by vibe-cloned software.
Given that nearly every commercial software license agreement prohibits decompilation, can you even legally carry out the first step without residing in a jusrisdiction that doesn't respect international copyright conventions?
And isn't importing material produced in violation of copyright into countries that do respect these conventions prohibited by law?
Maybe I'm a cynical old man, but all these ArtCraft apps feel a bit too good to be true?
They come out of nowhere (sort of), and they're just a bit long-con trojan horse for some point in the future where the userbase will have to pay the piper.
If these apps eventually have millions of users, most of whom will just be downloading the binary releases and using auto-update to get the latest version through some opaque updater, what's to stop a future update from being nefarious?
Yes, but there used to be a gatekeeping effect because the development of huge software packages like LibreOffice was too capital-intensive to be enticing for a criminal enterprise. If you have malicious intent and know your way around software, finding a security defect and exploiting it for the umpteenth ransomware campaign is much easier than building a full office suite from scratch and getting a userbase going in order to sneak malware in years down the line. The implied fear is that coding chatbots may make this attack economically viable.
I would argue it happens even inside marketplaces. We've seen the authors of popular Chrome extensions take payouts and sell their extensions to new owners who have bad intentions for the userbase.
I was also going to post "this sounds like usability/user research".
But I guess we all re-discover things when we need to.
The biggest issue I've seen with tech docs is often expert users of a given tool or product are enlisted to write the docs, because of their expertise.
But then ironically they end up writing those docs for an audience that shares their level of expertise, rather than for the intended audience.
So you end up with lots of assumptions or leaps of logic in the docs that the intended audience can't follow.
I've built easily a dozen personal apps in the last few months that I have no plans on releasing or sharing, run locally, and solve very specific productivity (or one-off) issues for me.
I would never have spent the time building these apps in the pre-LLM days because the effort wouldn't have been worth the gains.
But now? Sure Claude, build me a MacOS app in Swift that does this exact thing I need. Less than an hour later, it's done.
reply