There is only one program that offers this ability, but you need to pay for the entire software suite, and the process is painfully convoluted anyway. We went from doing maybe 2-3 files a day to do doing 2-3 files an hour.
I have repeated ad-nausea that the magic of LLMs is the ability to built the exact tool you need for the exact job you are doing. No need for the expensive and complex 750k LOC full tool shed software suite.
is this like a meta-joke?
> I have a prime example of this were my company was able to save $250/usr/mo for 3 users by having Claude build a custom tool for updating ancient (80's era) proprietary manufacturing files to modern ones.
The funny thing about examples like this is that they mostly show how dumb and inefficient the market is with many things. This has been possible for a long time with, you know, people, just a little more expensive than a Claude subscription, but would have paid for itself many times over through the years.
Now with Claude, it's easy to make a quick and dirty tool to do this without derailing other efforts, so it gets done.
However possible it was to do this work in the past, it is now much easier to do it. When something is easier it happens more often.
No one is arguing it was impossible to do before. There's a lot of complexity and management attention and testing and programmer costs involved in building something in house such that you need a very obvious ROI before you attempt it especially since in house efforts can fail.
I wonder how much of the benefit of AI is just companies permitting it to bypass their process overhead. (And how many will soon be discovering why that process overhead was there)
Experience shows that that's the case at least 50% of the time
The paid program can do it because it can accept these files as an input, and then you can use the general toolset to work towards the same goal. But the program is clunky an convoluted as hell.
To give an example, imagine you had tens of thousands of pictures of people posing, and you needed to change everyone's eye color based on the shirt color they were wearing.
You can do this in Photoshop, but it's a tedious process and you don't need all $250/mo of Photoshop to do it.
Instead make a program that auto grabs the shirt color, auto zooms in on the pupils, shows a side window of where the object detection is registering, and tees up the human worker to quickly shade in the pupils.
Dramatically faster, dramatically cheaper, tuned exactly for the specific task you need to do.
I know we are in a bubble here, but AI has definitely made its way out of silicon valley.
That's a task that I could automate as a developer, but other than LLM "vibe coding", I don't know that there's a good way for a lay person to automate it.
1. Simple CRUD apps
2. Long-tail / low-TAM apps
Because neither of these make economic sense for commercial companies to develop targeted products for.Consequently, you got "bundled" generalized apps that sort of did what you wanted (GP's example) or fly-by-night one-off solutions that haven't been updated in decades.
The more interesting questions are (a) who is going to develop these new solutions and (b) who is going to maintain these new solutions? In-house dev/SRE or newly more-efficient (even cheaper) outsourced? I'd bet on in-housing, as requirements discovery / business problem debugging is going to quickly dominate delivery/update time. It already did and that was before we boosted simple app productivity.
I’m working with a company now that thinks that AI is great until you need to deploy to Prod. Probably true in some cases, especially for tools built with Prod environments as targets.
But I’m using Claude Code for a tool that doesn’t absolutely require that sort of environment. It helps a company map data (insurance risk exposure data) to a predefined intermediate layout and column schema.
I know that I’ll run into resistance once I say “this could be deployed to Prod” but I think AI is a major win for Prod-like things.
My professional world largely lives in spreadsheets and relational databases. Neither going anywhere anytime soon. And spreadsheets are the currency of the business and industry in so many ways. They are very prod-like in my opinion.
Agreed absolutely, but that's also what I'm talking about. It's very clear it was a bad tradeoff. Not only $250/month x three seats, but also apparently whatever the opportunity cost just of personnel tied up doing "2-3 files a day" when they could have been doing "2-3 files an hour".
Even if we take at face value that there are no "programmers" at this company (with an employee commenting on hacker news, someone using Claude to iterate on a GUI frontend for this converter, and apparently enough confidence in Claude's output to move their production system to it), there are a million people you could have hired over the last decade to throw together a file conversion utility.
And this happens all the time in companies where they don't realize which side of https://xkcd.com/1205/ they're on.
It's great if, like personal projects people never get started on, AI shoves them over the edge and gets them to do it, but we can also be honest that they were being pretty dumb for continually spending that money in the first place.
I mean, I'm absolutely familiar with how company decision making and inertia can lead to these things happening, it happens constantly, and the best time to plant a tree is today and all that, but the ex post facto rationalizations ring pretty hollow when the solution was apparently vibecoded with no programmers at the company, immediately saved them $750 a month and improved their throughput by 8x.
Clearly it was a very bad call not to have someone spend a couple of days looking into the feasibility of this 10 years ago.
I wouldn't.
Knowing what to build is part that many businesses struggle with.
As much as consultants are lambasted, my experience of companies is that they struggle to develop or maintain anything in-house - even where it should theoretically make economic sense. >>46864857
I imagine "vibe coder" will eventually coalesce with business requirements analyst, into a sort of "LOB developer-lite." I.e. every low-code products' undelivered citizen developer dream.
You need someone in the technical details and with some developer background (thinking through edge cases is a hard skill requirement), and you need someone with the process analysis and documentation skills (as well as the ability to push back / simplify requirements where it makes sense).
External developers/consultants are typically terrible at the requirements discovery and specification stage, because they're not embedded day-to-day with the business. Ergo, you get stupid feature decisions because someone left a sentence off a doc.
From your other comment, I think you're thinking about more complex / core / feature-rich solutions than I am. I agree those may remain SaaS / outsourced.
But there's no way in hell dirt-simple CRUD and "I am the only person in the world who has this need" solutions stay out of house.