Comment by lateforwork 9 hours ago
> The fear is that these [AI] tools are allowing companies to create much of the software they need themselves.
AI-generated code still requires software engineers to build, test, debug, deploy, secure, monitor, be on-call, support, handle incidents, and so on. That's very expensive. It is much cheaper to pay a small monthly fee to a SaaS company.
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. It's not just a converter, it's a gui with the tools needed to facilitate a quick manual conversion.
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.
No, it is incredibly streamlined because it tailored specifically to achieve this modernization.
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.
> It's not just a converter, it's a gui with the tools needed to facilitate a quick manual conversion.
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.
It's not just a joke, it's a meta-joke! To address the substance of your comment, it's probably an opportunity cost thing. Programmers on staff were likely engaged in what was at least perceived as higher value work, and replacing the $250/mo subscription didn't clear the bar for cost/benefit.
Now with Claude, it's easy to make a quick and dirty tool to do this without derailing other efforts, so it gets done.
The problem with this reasoning is it requires assuming that companies do things for no reason.
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.
Our company just went through an ERP transition and AI of all kinds was 0% helpful for the same reason it’s difficult for humans to execute: little to no documentation and data model mismatches.
Exploring a codebase tells you WHAT it's doing, but not WHY. In older codebases you'll often find weird sections of code that solved a problem that may or may not still exist. Like maybe there was an import process that always left three carriage returns at the end of each record, so now you got some funky "lets remove up to three carriage returns" function that probably isn't needed. But are you 100% sure it's not needed?
Same story with data models, let's say you have the same data (customer contact details) in slightly different formats in 5 different data models. Which one is correct? Why are the others different?
Ultimately someone has to solve this mystery and that often means pulling people together from different parts of the business, so they can eventually reach consensus on how to move forward.
> creating documentation
How is an AI supposed to create documentation, except the most useless box-ticking kind? It only sees the existing implementation, so the best it can do is describe what you can already see (maybe with some stupid guesses added in).
IMHO, if you're going to use AI to "write documentation," that's disposable text and not for distribution. Let the next guy generate his own, and he'll be under no illusions about where the text he's reading came from.
If you're going to write documentation to distribute, you had better type out words from your own damn mind based on your own damn understanding with your own damn hands. Sure, use an LLM to help understand something, but if you personally don't understand, you're in no position to document anything.
I don't find this surprising. Code and data models encode the results of accumulated business decisions, but nothing about the decision making process or rationale. Most of the time, this information is stored only in people's heads, so any automated tool is necessary blind.
I worked on a product that had to integrate with Salesforce because virtually all of our customers used it. It must have been a terrible match for their domain, because they had all integrated differently, and all the integrations were bad. There was virtually no consistency from one customer to next in how they used the Salesforce data model. Considering all of these customers were in the same industry and had 90% overlapping data models, I gave up trying to imagine how any of them benefited from it. Each one must have had to pay separately for bespoke integrations to third-party tools (as they did with us) because there was no commonality from one to the next.
One thing that's interesting is that their original Salesforce implementations were so badly done that I could imagine them being done with an LLM. The evergreen stream of work that requires human precision (so far, anyway) is all of the integration work that comes afterwards.
> So what happens is a corporation ends up spending a lot of money for a square tool [SaaS] that they have to hammer into a circle hole.
You are assuming that corporations have the capability to design the software they need.
There are many benefits to SaaS software, and some significant costs (e.g. integration).
One major benefit of SaaS is domain knowledge and most people underestimate the complexity of even well known domains (e.g. accounts).
Companies also underestimate the difficulty of aligning diverging political needs within the business, and they underestimate the expense of distraction on a non-core area that there is no business advantage to becoming competent at. As a vendor sometimes our job was simply to be the least worst solution.
At least that's what I saw.
If it is not a small fee, I do wonder - is there still advantage to having a provider which one may take out a lawsuit against if something goes wrong? To what extent might liability and security vetting by scaled usage still hedge against AI, in your view?
>But it does reduced by an order of magnitude the amount of money you need to spend on programming a solution that would work better
Could you share any data on this? Are there any case studies you could reference or at least personal experience? One order of magnitude is 10x improvement in cost, right?
I‘m not sure it’s a perfect example, but at least it’s a very realistic example from a company that really doesn’t have time and energy for hype or fluff:
We are currently sunsetting our use of Webflow for content management and hosting, and are replacing it with our own solution which Cursor & Claude Opus helped us build in around 10 days:
Oh, but that doesn't matter. SaaS tools aren't bought by the people that have to use them. Entire groups in big companies (HR & co) are delegating the majority of their job to SaaS and all failures are blamed on the people who have to interact with them while they are entirely ancillary to their job.
Modern AI probably could’ve done almost all of the work for him.
no way. We're not talking a standalone AI created program for a single end-user, but entire integrated e-commerce enterprise system that needs to work at scale and volume. Way harder.
I also have pretty hefty skepticism that AI is going to magically account for the kinds of weird-ass edge cases that one encounters during a large data migration.
Just like coding the AI can reach out to a human for clarification on what to do.
I was interviewing with a company that has done ETL migration, interop and management tools for the healthcare space, and is just dipping their toes in the "Could AI do this for us or help us?"
Their initial answer/efforts seem to be a qualified but very qualified "Possibly" (hah).
They talked of pattern matching and recognition being a very strong point, but yeah, the edge cases tripping things up, whether corrupt data or something very obscure.
Somewhat like the study of MRIs and CTs of people who had no cancer diagnosis but would later go on to develop cancer (i.e. they were sick enough that imaging and testing was being ordered but there were no/insufficient markers for a radiologist/oncologist to make the diagnosis, but in short order they did develop those markers). AI was very good at analyzing the data set and with high accuracy saying "this person likely went on to have cancer", but couldn't tell you why or what it found.
Hmm, I wonder if it would be cheaper to hire a couple of software engineers to vibe-code custom SaaS apps on top of the company's existing data layer instead of paying for a hundred different SaaS subscriptions.
Financial considerations aside, one advantage of having in-house engineers is that you can get custom features built on-demand without having to be blocked on the roadmap of a SaaS company juggling feature requests from multiple customers...
I'm at a large company that is building connections between all of its different financial systems. The primary problem being faced is NOT speed to code things, the primary problem at large companies is getting business aligned with tech (communication) and getting alignment across all the different orgs on data ownership, access, and security. AI currently doesn't solve any of this. Throw in needing to deal with regulation/SOX compliance and all the progress you think AI might make, just doesn't align with the problem domains.
Totally makes sense. Turns out that a lot of what Palantir's "Forward Deployed Engineers" do is navigating these bureaucratic and political obstacles to get access to the data: https://nabeelqu.co/reflections-on-palantir -- which may be Palantir's real secret sauce, rather than the tech itself.
I haven't seen what you're suggesting from a CEO at a large company that's primary business is non-software related. At some point in a businesses life theres an accumulation of so many disparate needs and systems that there can be many many layers of cross org needs for fulfilling business processes. This stuff is messy.
I think I saw it asserted that its easier for a new company, which definitely makes sense as you don't carry along all the baggage.
I work in large projects like this, the CEO doesn't get involved in the little "computer project" except during the project kickoff. Even then, it's just to "say a few words about the people I admire on this team". In large global companies these projects are delegated 3 or 4 levels below the CEO at the highest.
This is also generally true for all mid to large businesses I've ever worked at.
The code they write is highly domain-specific, implementation speed is not the bottleneck, and their payroll for developers is nothing compared to the rest of the business.
AI would just increase risk for no reward.
> one advantage of having in-house engineers is that you can get custom features built on-demand without having to be blocked on the roadmap of a SaaS company juggling feature requests from multiple customers...
Many larger enterprises do both – buy multiple SaaS products, and then have an engineering team to integrate all those SaaS products together by calling their APIs, and build custom apps on the side for more bespoke requirements.
To give a real world example: the Australian government has all these complex APIs and file formats defined to integrate with enterprises for various purposes (educational institutions submitting statistics, medical records and billing, taxation, anti-money laundering for banks, etc). You can't just vibe code a client for them – the amount of testing and validation you have to do with your implementation is huge–and if you get it wrong, you are sending the government wrong data, which is a massive legal risk. And then, for some of them, the government won't let you even talk to the API unless you get your product certified through a compliance process which costs $$$. Or, you could just buy some off-the-shelf product which has already implemented all of that, and focus your internal engineering efforts on other stuff. And consider this is just one country, and dozens of other countries worldwide do the same thing in slightly different ways. But big SaaS vendors are used to doing all that, they'll have modules for dealing with umpteen different countries' specific regulations and associated government APIs/file formats, and they'll keep them updated since they are forever changing due to new regulations and government policies. And big vendors will often skip some of the smaller countries, but then you'll get local vendors who cover them instead.
If AI can code, why do you think it cannot handle building, testing, debugging, securing, monitoring, supporting, incident handling, and so on?
Consider incident handling. What if your AI sets up monitoring that detects errors or outages, wakes up an agent, gives it the problem context, then sets it to work so it can debug the issue, produce a fix, then deploy it? You now have an end-to-end system that works 24/7. Many issues will probably be resolved before you've even noticed them.
If your response is, AIs won't ever be smart or capable enough to do this as well as humans, how has that same prediction worked out for coding?
The next generation of AI "coding" tools will essentially be SaaS companies in a box. Agents will code the app, but they'll also test it, debug it, support it, etc. And this will happen in months, not years.
> Consider incident handling. What if your AI sets up monitoring that detects errors or outages, wakes up an agent, gives it the problem context, then sets it to work so it can debug the issue, produce a fix, then deploy it? You now have an end-to-end system that works 24/7. Many issues will probably be resolved before you've even noticed them.
Have you ever been actually involved in trying to fix an error or outage? Like actually on an on-call rotation where you had to deal with reported issues?
Atlassian tools for a client like mine (hundreds of employees) can easily cover the expense of internalizing it. It's Jira plus confluence mostly, it's not rocket science.
And that's just atlassian.
Start adding stuff that costs many many many yearly salaries (special software for managing inventories and warehouses) it starts making sense to prototype alternatives internally.
I came to the conclusion that if it's not Teams/SharePoint or the moat is on the extreme legal complexity side (e.g. payrolls), you can at least think of building an alternative that is good enough without needing to be perfect.
Ugh you are aware that Atlassian earlier was providing on-perm edition for years.
You also know how neglected those on-perm instances were?
No one updated those, no one wanted to pay for more CPU/RAM. File storage, I know people who had some random requests to cleanup files from projects because company wouldn’t buy more hard drives. Everyone was nagging at sys admins that they do bad job and at Atlassian that JIRA sucks.
That is mostly why Atlassian pulled off on premise because companies would not update at all, would like to have all new features and also not pay for file storage,RAM, CPU to make it work well.
Don’t forget you still will need to have dedicated employees to deal with AI built solution - because existing employees have work to do.
What we pay for JIRA and Confluence would never offset fact that we pay and it works, NOT A SINGLE EMPLOYEE CARES as they have their job to do.
Don’t forget the salary for every dev team having the Atlassian Jira Jockey to mess around with the board all day and make sure the next 7 epics worth of tickets are in the 9 columns and in prioritised order.
Where would we be without them!?
jira premium is $15/mo/user for 300 users. you're saying $50k can cover developing the app inclusive of integrations, maintaining it, providing 24/7 service and 3 9s uptime (per the sla)? don't forget compliance and security. maybe the logic is everyone can be fired and replaced with agents?
Atlassian had on premise option already.
All instances I remember seeing were neglected, not updated running on lowest amount of resources. Everyone in company nagging how slo it is but no one wanted to share budget to improve it.
So for me that experiment „it will be better and cheaper building our own JIRA” was already done. It is going to be cost center that no one will want to throw money at.
There is no way you would get anything close to as good as JIRA. Your best bet with that budget would be trying to integrate an existing open source on-prem solution (not sure what that alternative is for JIRA).
I told to my colleague that it would take less time for me to vibe code jira that it would take him to configure it. Sounds crazy ? Not so much : factor the part of jira you use (maybe 10%), the many choices and dimensions you have to configure, the time it take and the complexity it bring. On the other side, the vibe code version have only the fields you want, most of the logic hard written in code (ie epic > story >task...), and that you could do anything any role, any authentication scheme.
This reminds me of all the "i could turn the spreadsheet into a webapp in a weekend" type comments. Sure, you could get CRUD and a datatable working but then a user is going to ask you for a custom field and you'll say "ok let me vibe code that, update the database, and then deploy" but the user will say "well in Jira I could just to that myself...". Then the next thing they're going to ask is some kind of custom workflow utility which you'll then goto work vibe coding that feature and they'll say again "...but in jira that was already there". Meanwhile they'll ask you why they can't change the validation criteria on the custom field from before, they said it should be required but now there's a case where it's optional.
Pretty soon you're just re-implementing Jira while your users wait and get pissed because they could have just been using Jira all along. It's just like turning a spreadsheet into a webapp, inevitably you just end up trying to re-implement Excel.
"Small Monthly Fee" is a very loaded term here. Im in the negotiations for these platforms, the price that many of these companies command for their products will very often pay the salaries of a whole software department. Add to this the quality of support being the lowest possible option above "nonexistant" and I would say the risk to these SaaS companies is real.
The real benefit of these types of SaaS offerings was their ubiquity across multiple industries and verticals. If a company bought Salesforce, they could very readily find employees that would be able to quickly onboard since they would likley have used it at previous companies. AI software generation is changing this as more and more software being created is bespoke and increasingly one-of-a-kind with these tools allowing companies to create software that fits their unique and specific needs.
My hot take here is that the moats previously enjoyed by SaaS companies will increasingly vanish as smaller and smaller teams can assemble "good enough" solutions that companies will adopt instead of paying giant chunks of their budget on pre-built SaaS tools that will increasingly demand more training to Onboard.
There is one big argument against these "good enough" solutions: commercial business software providers need to put a lot of R&D into finding generalized workflows that apply to as many clients as possible. Effectively, they find and encode current standard practices into their products. This is valuable from a business operations perspective in two ways: it's a good bet that transitioning the customer's operations to match the software is cleaning up internal processes, and it makes onboarding new employees easier because the tools and workflows should be much more familiar right from the start.
Saas was always fueled by B2B buying through same investor circle. sequoia companies buying from other sequoia companies, softbank companies buying from other software companies. Without this circular buying and selling of the software, the whole B2B software market crashes.
>My hot take here is that the moats previously enjoyed by SaaS companies will increasingly vanish as smaller and smaller teams can assemble "good enough" solutions that companies will adopt instead of paying giant chunks of their budget on pre-built SaaS tools that will increasingly demand more training to Onboard.
why do people pay red hat/ibm for rhel? they earn pretty good margins too. to parent's point on software/=code
yes, but this does fit into the head of MBA-bobo-management stylers, who believe ChatGPT will replace everyone :)
Hyper custom software can allow your business flows to sync together a lot better than the alternative, using zapier to glue a bunch of mostly poor fits and ending up with Frankenstein processes.
Also, it allows you to pick and choose what you want from where.
We’ve just completed the first month of our internal CRM that has replaced about 500$ a month in subs with something that flows much better and enforces our own internal processes.
That would justify a good multiple of 5 to 10. Not 30 or above as for high growth companies.
multiple of what? there is maybe one software company trading above 30x revenue - palantir. many companies growing at 20% trade at single digit revenue multiples.
that is really not the case in software, people commonly go between EV/S and EV/FCF for high growth names. also earnings could mean: GAAP earnings, non-GAAP earnings, ebitda, ebita, FCF, FCF ex share based comp.
Lol. ServiceNow, Oracle, Workday, etc are not small monthly fees. That's what the market is shitting on. (Oracle is different, given the corruption and OpenAI grift angle.)
My buddy works for a company like these. He landed a $5M contract last year, which netted him almost $800k. There's alot of fat to be cooked out of this stuff, and AI will help smaller entrants attack those margins.
AI-based startups like Vanta make it much easier for companies to meet the compliance bullshit the large companies require. Again, it will drive more competition == better values for customers.
> There's alot of fat to be cooked out of this stuff, and AI will help smaller entrants attack
truer words have never been spoken. I work in some of these platforms and lead teams of developers who write customizations. These customizations are not rocket surgery, basic CRUD with some logic requirements that can't be met ootb. It's very time consuming and therefore expensive to clients. The significant moat incumbents have is brand recognition and trust. On the other hand, a hot new "Agent First" consulting firm at 1/3 the price would be hard for a director to not at least experiment with.
yes but investors don't know that
or for a more charitable comment, I think the issue people struggle with right now is how much of non-AI software will be replaced by AI-native versions. and it's not even a 1:1 mapping. we may see 5 different small companies replaced by a single AI interface. all TBD, but there's merit to avoiding that risk right now if you can just allocate to NVDA and GOOG instead
> AI-generated code
AI "generated" code requires a large base of training data to draw from. If we all stop writing code then there will no new code written. Just rehashes of stolen ideas. There is no long tail to this industry or ideal.
> That's very expensive.
As long as you convince someone else to pay the bill who cares? The real problem is are you losing your competitive edge? If everyone else can crank out the same stolen crap you can then there is no reason for you to even exist.
It has to annotate it too.
We've let models do this before. They devolve into an incomprehensible mess in very short order. Errors multiply. Lossy weight compression on erroneous material makes it all that much more worse.
Foundational software requires that, but the foundation is pretty much completely built at this point. The workforce required to keep it running is but a tiny fraction of what was required to build it. The past has shown that innovation in hardware can push for the foundations to be rebuilt, but we've also already got computers basically everywhere now. There may not be some new innovation that requires the foundations to be completely rewritten again.
The little one-off programs that we thought would keep developers busy forevermore don't require engineers. They often don't even require code. LLMs can natively do a lot of things that historically would have required software.
You still seem to be thinking about code in the traditional sense. A lot of the software I am using now in my non-tech business isn't rooted in code at all. It is simply asking an LLM to carry out a task. Still programming, of course, but not with a traditional programming language. The LLM will produce the excepted results in realtime. The intermediary step of building an executable is totally unnecessary.
In the olden days it would have taken considerable engineering effort to produce a comparable tool. That is no longer the case.
Open source doesn't implement, host, and support itself. Some of these software companies stocks are companies selling open source software.
Haha, maybe… you can stick your head in the sand all you want, but everyone I know whose output is code is delegating 100% of their work to Claude Code today, I cannot see this magically drawing a line at people whose output is configs and emails…
Stock prices are very forward looking, so if half the hype being sold about AI is true I would expect most software-centric companies to be devalued by wall-street (as the test, deploy, support should be automated in the coming years...according to the AI CEO's).
However, if I was a wall street analyst and believed the AI dreams I would further be concerned that software companies aren't taking advantage of the last remnants of value before software (and maybe labor) values go to zero.
If you've got a gold mine and have recently built the most efficient shovels in the world, why are they not bringing in mass amounts of workers to utilize these shovels before all the neighboring mines. Once all that gold is on the market, the price crashes so it's better to be one of the first mines to get in and dig out all possible value first.
I think you either don't believe in the AI hype, which means a lot of silicon valley companies are tremendously overvalued. Or you do, in which case another huge part of silicon valley is overvalued especially when they are not looking to out-innovate their peers (as evidenced by downsizing), but just riding the wave of AI until what they are selling has no marginal value over some guy coding alone in his bedroom. SV is putting itself into a weird position, but still has some time for financial buffoonery before the party stops.
>If you've got a gold mine and have recently built the most efficient shovels in the world, why are they not bringing in mass amounts of workers to utilize these shovels before all the neighboring mines
Because they are completely consumed by the need to increase margins, which they think they will be able to do it with AI by laying off a lot of people. But Saas economy is connected and based on per user pricing, so as layoffs continue, Saas economy is showing its biggest weakness. All of Saas companies also seem to embrace AI so much that they would rather add another summarise button rather than actually making something which cant be copied easily by competitors.
> > The fear is that these [AI] tools are allowing companies to create much of the software they need themselves.
If that's their fear they don't know much how your typical big businesses functions.
You've dealt with a large, consumer bank? Many of them still run on IBM mainframes. The web front end is driven by pushing buttons and screen scraping 3270 terminal emulators. You would think a bank with all it's resources could easily build it's IT infrastructure and then manage all the technology transitions we've gone through over the past few decades. Clearly, they don't and can't. What they actually do is notice they have to adapt to the newfangled IT threat, hired hordes of contractors to do the work, then fire them when done. After it's done they go back to banking and forget all the lessons they've learnt about building and managing IT infrastructure.
If you want to see how banking and computers should be combined, look at the Fintech's, not banks. But for some reason I don't understand traditional banks still out compete Fintech's. Maybe it's getting your head around both banking and running an IT business it too much for one human mind?
That same pattern is repeated everywhere. Why was everyone so scared of Huawei? It wasn't because they built the gear. It's because the phone telco's have devolved into marketing and finance companies who purchase in the gear from companies like Huawei and rent it out. Amazingly they don't know how to run the gear they purchased, instead get the supplier to install it and maintain it. But that meant what some eyes viewed as an organ of the Chinese communist party was running the countries phones with full access to every SMS and voice call. (Interestingly, IBM pulled the same stunt with the banks back in the day: you didn't buy an mainframe, you leased / rented it from IBM, and they maintained it.)
It's the same story everywhere I look. These big firms stick to the knitting. If you want to see total, utter incompetence in IT go work whose core business doesn't revolve around IT for a while. These are the firms that still choose Microsoft, despite the fact they've seen Sony's Microsoft based IT infrastructure torn apart so badly by North Korea they didn't know who their employees were, how much they owed creditors or how much debtors owned them for a while. Why do they choose Microsoft? Look around - who else allows you to outsource the know how about connecting millions of computing devices in 1000's of offices to a redundant cloud infrastructure that allows them to share data while providing a centralised authentication / authorisation infrastructure. There is only one choice, apart from developing it themselves which is out of the question.
If those businesses did start using what passes for AI today to manage and develop their own IT infrastructure, the result would not be pretty. But for all the shit I'm throwing at them here, I'm confident they are smarter than that. They know their limitations, they haven't done it before, and they won't start doing it now.
> AI-generated code still requires software engineers
No, they don't.
A domain expert armed with an Excel spreadsheet and the ability to write VBA macros will be enough for most business.
Excel spreadsheets have little to no validation logic that you're actually getting a good result, unless you have a secondary check (most spreadsheets are structured as "single entry" accounting, so lack the checks)
A prime example of this was the Reinhart/Rogoff paper advocating austerity that was widely quoted, and then it was discovered that the spreadsheet used had errors that invalidated the conclusions:
https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt#Metho...
Just because technology is in use and "works" doesn't mean it's always correct.
You are taking my comment way too literatlly.
The point is not that people will be using specifically Excel, but that most business only pay for software because it is the tool that gives them the most power to automate their processes. They don't need high availablility, they don't need standards compliance, they don't extensive automated tests, they won't need cloud engineeers and SRE... all you need is some tool that can get the results your are looking for right now.
Academia already works like this. Software wrtiten for academic purposes is notoriously "bad" because it is not engineerd, but that doesn't matter because it is good enough to deliver the results that researchers need. Corporate IT will also start looking like this even at mid-sized companies.
An academic paper needs to deliver its output once, for the research. Maybe someone will try to replicate it later but that's someone elses problem (and fairly often proves the output of the former to be wrong)
Some stuff in companies might be similar, but there's a lot of things that people use every day, in a lot of different ways, and the software needs to work correctly regardless. You can't just drop it like a hot potato once you've built processes around it.
As always, the first 80% takes 20% of the time/effort, the last 20% takes the other 80%.
I don't disagree with anything you say here - using a tool that lacks guardrails is fine for a lot of tasks, but if that's the only tool and used where those guardrails go from "nice to haves" to something more critical is where the problem is.
I've been in ops for a long time and have encountered far too many "our IP addressing plan is just a spreadsheet with manual reconciliation".
I truly wonder if Excel and all it's predecessors and direct clones (Google Sheets, etc.) are holding back industry from making something truly better and more reliable.
That's a software engineer that is limited to an mostly untyped macro language, with worse version control and poor tooling. It's not that software can't be written as an Excel spreadsheet, it is that it is just inefficient and failure prune.
I guess that's technically true, because "most businesses" are sole proprietorships without any employees... but they could get by just fine with a checkbook and a note pad.
But the reasons the business software sector grew far beyond Excel of the 1990s is because of the inherent limitations in scaling solutions built by business analysts inside of Excel. There's a vague cutoff somewhere in the middle of the SMB market where software architecture starts to matter and the consequences for fuckup are higher than the cost of paying for professionally made software with, importantly, a vendor on the hook for making sure it doesn't fuck up.
Uh, no. The main reason the software sector grew in the 90s was a particularly potent combination of FOMO, kickbacks, and strategically deployed cocaine.
Do you forget how much different offices looked back in the 90s?
A lot of these companies are not small monthly fees. And if you’ve ever worked with them, you’ll know that many of the tools they sell are an exact match for almost nobody’s needs.
So what happens is a corporation ends up spending a lot of money for a square tool that they have to hammer into a circle hole. They do it because the alternative is worse.
AI coding does not allow you to build anything even mildly complex with no programmers yet. But it does reduced by an order of magnitude the amount of money you need to spend on programming a solution that would work better.
Another thing AI enables is significantly lower switching costs. A friend of mine owned an in person and online retailer that was early to the game, having come online in the late 90s. I remember asking him, sometime around 2010, when his Store had become very difficult to use, why he didn’t switch to a more modern selling platform, and the answer was that it would have taken him years to get his inventory moved from one system to another. Modern AI probably could’ve done almost all of the work for him.
I can’t even imagine what would happen if somebody like Ford wanted to get off of their SAP or Oracle solution. A lot of these products don’t withhold access to your data but they also won’t provide it to you in any format that could be used without a ton of work that until recently would’ve required a large number of man hours