The tradeoff between building something custom and adapting an existing solution is changing. Whether maintaining all that custom software turns out to be equally cheap is another question.
There is no doubt everyone is far more productive with LLMs in generating code. However, a lot of productivity is going into things like that. Have you always been bothered by the limitations of Grafana? You can generate another dashboarding solution that works best for you. You know that deployment team that is so slow and annoying? Now you can generate your own deployment engine. Have you always hated how kubectl lets you manage one k8s cluster at a time? Now you can ask AI to generate fleetctl. You can start your project with DynamoDB, rewrite it to mysql, then to postgres, then to duckdb. Start with Python, switch to Golang, then switch to Rust. Deploy on AWS, then move to Azure, then move to a hybrid option then throw colocation in the mix. Don't like your source control? create a new one. Json is too limiting? Invent a hybrid JSON/HCL language. The browser sandbox is limited? Make a desktop app, make a language, make an OS, make a kernel.
This is one of the core reason that I dislike the LLM hyping. People are just reinventing stuff and when you ask them, it's actually a very subjective reason. Ok, anyone can do what they want with their time, the issue is that they want people to follow in their steps.
Not saying that you need a novel idea to be worthy, but those random projects have no guarantees behind them other than some cursory testing. All software have bugs, but I can't interact with something that is randomly built.
I am one of those people that reinvents the wheels because external ones don't fit my use cases.
The fact I can now fork any software and do these changes I always wanted but had no time to is amazing to me.
I do not pretend to sell it or share it, as it is de facto void of any value whatsoever.
That’s OK, but I’ve yet to see someone articulating what exactly doesn’t work in the old product. It’s always “Let’s rewrite or reinvent 90% of it, then add a minuscule variation”. The variation may be interesting, but the reinvent is what’s make it untouchable as no one (including the author) has time to ensure things are right.
A patch or a plugin is ok, but not a whole new project with dubious claims.
They are trying to get in every opensource projects, increasing the burden of maintainers. And once a ban is announced, they’re here protesting.
When other people start doing that to other teams at work, other people in open source, other people in professional settings, etc it becomes a problem for various reasons. The idea that I'm gonna gift you with a 75k lines of python to "just run it" and ask your agent to hack on it might be fine (who cares as you put it). Now scale that to 47 of such projects (a month)
Assumptions. I've rebuilt a number of inference engines to run on windows and unify the dependency venv to last version to save space, unrolling model blocks so they fit in my 16gb card etc. A lot of thing thay I was locked out are possible now as i am no longer held back by invariants decided by someone else, and because I do not have to spend time to get things done. I've changed games to have a less grindy loop, added features, or making learning them easier. Ive fixed drivers, patched versions, brought dlss5 to game weren't supposed to have it
It's not ground breaking, but its liberating.
Communication and coordination are bottlenecks.
There will be no common framework to build on. Like imagine talking now to someone from ancient rome, they will not have an understanding for what most of everyday words you are using today.
For some things, you'll need to build a working framework from grounds up. Electricity or more complex maths would be an example. For some, it might be enough to repurpose the existing framework they already have. For example, microbes: if you're trying to communicate something about health and hygiene, chances are, the other side already has a half-decent framework built around malevolent spirits or taint, that amounts to the same thing in practice.
Or, just tell the universal translator to ELI5 it to the other person :). Or "explain like they're a caveman". Our UTs are fully capable of translating concepts between conceptual frameworks.
And, there are also people who know what they’re doing building things they couldn’t before.
This situation is a net positive, and not too different than before. It’s up to you to navigate the noise.
Not really. But equally, I imagine most people have a similar experience of software development to me - complex, messy and confusing code also often has poor performance and a high rate of bugs.
This is actually a scary side of AI for providers: we use our own AI to research better choices and escape dark UI patterns and vendor lock-in. That information asymmetry and the difficulty of leaving a provider used to be their moat.
On a system level I think AI code is more like biological diversity, it hedges against monoculture risks. We don't all fall down at the same time if we don't replicate the same code.
As for the bio-diversity, I guess we’ll see the next time us-east-1 goes down.
At work I've been building an end to end system to do a certain process. The codebase is definitely more spaghetti than ideal and I really am concerned about maintenance down the road. But on the other hand I was able to POC it faster than anyone on the team would've before LLMs came along. We're already getting useful results from it too.
Unfortunately this starts to break when there's more than one you on the team.
I see a lot of hand-rolled NIH solutions that create value for one person only, and are a net negative on the team.
I can’t imagine a worse hell in a team or collaborative setting though. Imagine (or you don’t have to imagine since it’s already happening) asking a coworker “how they check how feature X is doing in prod” and their answer isn’t a query (regardless of how long it is) or some slightly complicated script to run. Instead their answer is a 27k line custom Rust desktop app. Then 2 days later you discover that the big green “All Systems Operational” is just a bit of static text, and in fact not all systems are operational. The app just doesn’t check things correctly.
Well, things are not that bleak, probably, at least not for our customers. Regulations (accountability) and physical world matters still require them. But not us for our customers, not that much and not for too long. They tend to be the tech savvy folks eager to jump at adjacent domains when it saves them a percentage or two off the construction costs (not a small pile of money), and AI with its programming language of English and deep knowledge pool is not that big a jump from their standpoint. Our domain is pretty well formulated, regulated, documented, inherently built on do-check-adjust loops already. With a thing like AI it might worth to try making and improving a design solution in a second loop. But they also started to invest in robots already driven by software for their factories, AI might jump in there, and I wonder how much more until the regulations are forced to change by Super Intelligent (R) politicians for the sake of AI accelerated built environments (housing crisis, you know!), shifting the AI use further out towards generic population, wanting to order a new two bathroom condo for next Friday from Alibaba. The conservative construction business is a nuisance and obstacle in the way of modernisations anyway, go around it!
I will go to work tomorrow, and for some time, but the picture above feel less and less fictious with each passing day of AI news and usage.
There's so much intricacy and subtlety in each organization and even individuals' environment being incorporated into tooling that expecting these tools to generalize at this point is perhaps an expired ethos.
I even see this in the tooling that I run in my own personal stack. Many projects are candidates for sharing, and I have nothing against it, but they incorporate such specificity toward my own environment, including things like hardware, that creating shareable and more generalizable projects from them adds more to the maintenance surface than I would care to support.
Software development is not as much de-risking at the front like it used to be before building.
Now teams can build lots of stuff that works great, except it's the wrong things.
Most things are becoming the understand the problem "shape".
Understanding the shape of the problem isn't something LLMs can always make as.. svelte as early on.
Word generators gotta generate..
That used to be called "time wasting". If you want to build software that will be used, you need to interview the users. Maybe a few things does require research to nail things right. But most software are user-facing, the research side is about optimization.
> Most things are becoming the understand the problem "shape".
Then should we be so reluctant about "trialing" invented solutions. It's the same thing with most AI projects, they're trying to justify the project after the facts while being very reluctant to get user insights.
Vibe coding can be kind of a new type of cowboy coding. It could can be harnessed productively if done mindfully.
Interviewing users is critical, more importantly solving problems worth that people are lining up to pay to have solved before writing a line of code is critical.
Trialing solutions is always worth learning from, I usually ask about the problem that lead to building it. Sometimes that can be too narrow or vague of a story and you can learn how much of it is a solution looking for a problem, or vice versa.
The key, still, is shipping far less, too soon, to minimize cruft.
Some people write (I hate the word "build" here) software for non-business purposes. As nice as it would be to interview potential users, there's no clear way to discover and contact them.
... probably the majority (by package count) of the Python ecosystem? Or the JS one?
My suspicion is that this simply won't go away as the models get better, because it isn't a question of how good the models are. It's a question of the human operators knowing exactly what they want. Which is, I conjecture, usually impossible until you try something and critique it properly.
There's a reason the product-minded highly-technical engineer was always highly sought out.
But also, some of these internally developed tools get published and end up pretty successful.
- they have implementation cost.
- they are usually born from arrogance mixed with lack of understanding of existing solutions and their tradeoffs, and typically end up being a net negative.
Before LLMs, the cost is what primarily used to stop us from building them, it used to be a natural filter for bad ideas. Now that the cost is gone, it's nearly impossible for most teams to stay disciplined and not be building those.
Why wouldn't you build a software factory? If you succeed, the ROI is infinite. Who cares about immediate customer needs, we're building a utopia here. Once it's done, all customer needs will be solved. Just one more month, I promise.