zlacker

[parent] [thread] 54 comments
1. mattma+(OP)[view] [source] 2026-02-02 20:04:23
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

replies(9): >>wtp1sa+77 >>paulpa+pa >>datsci+Bc >>soloma+Ji >>stefan+lj >>WarmWa+qv >>dkarl+uY >>roboca+K51 >>jayd16+Y91
2. wtp1sa+77[view] [source] 2026-02-02 20:34:02
>>mattma+(OP)
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?
replies(2): >>thephy+0p2 >>mattma+tr2
3. paulpa+pa[view] [source] 2026-02-02 20:48:04
>>mattma+(OP)
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.

replies(1): >>forget+4c
◧◩
4. forget+4c[view] [source] [discussion] 2026-02-02 20:55:17
>>paulpa+pa
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.
replies(3): >>FireBe+cj >>fragme+Gp >>charci+5Z
5. datsci+Bc[view] [source] 2026-02-02 20:57:35
>>mattma+(OP)
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.
replies(1): >>dehugg+If
◧◩
6. dehugg+If[view] [source] [discussion] 2026-02-02 21:14:09
>>datsci+Bc
surprising considering you just listed two primary use cases (exploring codebases/data models + creating documentation)
replies(4): >>gmueck+vl >>s5fs+hm >>palmot+NM >>heavys+mm1
7. soloma+Ji[view] [source] 2026-02-02 21:26:34
>>mattma+(OP)
>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?

replies(1): >>Manuel+jl
◧◩◪
8. FireBe+cj[view] [source] [discussion] 2026-02-02 21:28:39
>>forget+4c
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.

9. stefan+lj[view] [source] 2026-02-02 21:29:00
>>mattma+(OP)
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.
◧◩
10. Manuel+jl[view] [source] [discussion] 2026-02-02 21:38:15
>>soloma+Ji
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:

https://dx-tooling.org/sitebuilder/

https://github.com/dx-tooling/sitebuilder-webapp

replies(2): >>soloma+An >>iamacy+uJ
◧◩◪
11. gmueck+vl[view] [source] [discussion] 2026-02-02 21:39:24
>>dehugg+If
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.
replies(1): >>phatfi+Ty
◧◩◪
12. s5fs+hm[view] [source] [discussion] 2026-02-02 21:41:53
>>dehugg+If
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.

replies(1): >>btown+sy2
◧◩◪
13. soloma+An[view] [source] [discussion] 2026-02-02 21:47:55
>>Manuel+jl
Thanks for the link.

So, basically you made a replacement for webflow for your use case in 10 days, right?

replies(1): >>Manuel+LR1
◧◩◪
14. fragme+Gp[view] [source] [discussion] 2026-02-02 21:56:14
>>forget+4c
It's not that AI is magically going to do it, it's that the human running the migration now has better tools to generate code that does account for those one-off edge cases.
15. WarmWa+qv[view] [source] 2026-02-02 22:15:54
>>mattma+(OP)
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.

replies(3): >>magica+PC >>roboca+o61 >>grvdrm+a73
◧◩◪◨
16. phatfi+Ty[view] [source] [discussion] 2026-02-02 22:28:37
>>gmueck+vl
This captures succinctly the one of the key issues with (current) AI actually solving real problems outside of small "sandboxes" where it has all the information.

When an AI can email/message all the key people that have the institutional knowledge, ask them the right discovery questions (probably in a few rounds and working out which bits are human "hallucinations" that don't make sense). Collect that information and use it to create a solution. Then human jobs are in real trouble.

Until that AI is just a productivity boost for us.

replies(1): >>datsci+dg1
◧◩
17. magica+PC[view] [source] [discussion] 2026-02-02 22:42:33
>>WarmWa+qv
> 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.

replies(2): >>mwigda+5K >>graeme+RM
◧◩◪
18. iamacy+uJ[view] [source] [discussion] 2026-02-02 23:06:06
>>Manuel+jl
I’m not sure the world needed yet another CMS
replies(1): >>daniel+wG1
◧◩◪
19. mwigda+5K[view] [source] [discussion] 2026-02-02 23:08:35
>>magica+PC
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.

replies(2): >>WarmWa+Pj1 >>magica+gD3
◧◩◪
20. palmot+NM[view] [source] [discussion] 2026-02-02 23:21:12
>>dehugg+If
> 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.

replies(1): >>dehugg+N74
◧◩◪
21. graeme+RM[view] [source] [discussion] 2026-02-02 23:21:54
>>magica+PC
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.

replies(3): >>lmm+xO >>coldte+s91 >>magica+XE3
◧◩◪◨
22. lmm+xO[view] [source] [discussion] 2026-02-02 23:29:37
>>graeme+RM
> 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)

replies(1): >>thfura+2c1
23. dkarl+uY[view] [source] 2026-02-03 00:19:09
>>mattma+(OP)
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.

◧◩◪
24. charci+5Z[view] [source] [discussion] 2026-02-03 00:23:22
>>forget+4c
Just like coding the AI can reach out to a human for clarification on what to do.
replies(1): >>Quiark+Fm5
25. roboca+K51[view] [source] 2026-02-03 01:05:27
>>mattma+(OP)
> 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.

replies(1): >>daniel+iG1
◧◩
26. roboca+o61[view] [source] [discussion] 2026-02-03 01:10:16
>>WarmWa+qv
Was the custom tool developed by copying how the existing software worked? Copying existing functionality is not always possible, and doesn't capture the real costs.
replies(1): >>WarmWa+hj1
◧◩◪◨
27. coldte+s91[view] [source] [discussion] 2026-02-03 01:30:37
>>graeme+RM
>The problem with this reasoning is it requires assuming that companies do things for no reason

Experience shows that that's the case at least 50% of the time

28. jayd16+Y91[view] [source] 2026-02-03 01:34:36
>>mattma+(OP)
Why waste your time on something that isn't your core business when, presumably, the SAASes of the world will use the new tech and lower prices as well?
replies(1): >>daniel+qG1
◧◩◪◨⬒
29. thfura+2c1[view] [source] [discussion] 2026-02-03 01:48:58
>>lmm+xO
Sure, there's a lot of process that is entirely justified, but there's also a whole lot of process that exists for reasons that are no longer relevant or simply because there are a lot more people whose job it is to make process than whose job it is to stop people from making too much process.
◧◩◪◨⬒
30. datsci+dg1[view] [source] [discussion] 2026-02-03 02:14:53
>>phatfi+Ty
The AI will also have to be trained to be diplomatic and maybe even cunning, because, as I can personally attest, answering questions from an AI is an extremely grating and disillusioning experience.

There are plenty of workers who refuse to answer questions from a human until it’s escalated far enough up the chain to affect their paycheck / reputation. I’m sure that the intelligence is artificial will only multiply the disdain / noncompliance.

But then maybe there will be strategies for masking from where requests are coming, like a system that anonymizes all requests for information. Even so, I feel like there would still be a way that people would ping / walk up to their colleague in meatspace and say “hey that request came from me, thanks!”

◧◩◪
31. WarmWa+hj1[view] [source] [discussion] 2026-02-03 02:35:28
>>roboca+o61
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.

replies(1): >>jlaroc+qp1
◧◩◪◨
32. WarmWa+Pj1[view] [source] [discussion] 2026-02-03 02:39:23
>>mwigda+5K
We have no programers on staff, we are not a tech company.

I know we are in a bubble here, but AI has definitely made its way out of silicon valley.

◧◩◪
33. heavys+mm1[view] [source] [discussion] 2026-02-03 03:01:06
>>dehugg+If
Please don't feed people LLM generated docs
replies(1): >>dehugg+J64
◧◩◪◨
34. jlaroc+qp1[view] [source] [discussion] 2026-02-03 03:27:04
>>WarmWa+hj1
I think use cases like that will be where "AI" has the biggest wins.

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.

replies(1): >>ethbr1+Jm2
◧◩
35. daniel+iG1[view] [source] [discussion] 2026-02-03 06:05:14
>>roboca+K51
this is true in many cases and not in many cases. Another true one is payments - it's complex AF and and no one will sit down and vibe code it. A CRM? Easy in many cases. Some workflow tool? Easy, they know the exact workflow.

So, sure, some products will go the way of the dodo and some will not.

replies(1): >>nasmor+og2
◧◩
36. daniel+qG1[view] [source] [discussion] 2026-02-03 06:06:05
>>jayd16+Y91
In most cases they can't. The cost they face is sales and marketing. Acquiring a customer costs money. Churn happens.
◧◩◪◨
37. daniel+wG1[view] [source] [discussion] 2026-02-03 06:06:58
>>iamacy+uJ
It doesn't. The person is saying they built just the functionality they needed. Probably 25% of a CMS. That's the point.
replies(1): >>Manuel+HR1
◧◩◪◨⬒
38. Manuel+HR1[view] [source] [discussion] 2026-02-03 07:45:51
>>daniel+wG1
Exactly.

And the big advantage for us is two things: Our content marketers now have a "Cursor-light" experience when creating landingpages, as this is a "text-to-landingpage" LLM-powered tool with a chat interface from their point of view; no fumbling around in the Webflow WYSIWYG interface anymore.

And from the software engineering department's point of view, the results of the work done by the content marketers are simply changes/PR in a git repository, which we can work on in the IDE of our choice — again, no fumbling around in the Webflow WYSIWYG interface anymore.

replies(1): >>daniel+sO3
◧◩◪◨
39. Manuel+LR1[view] [source] [discussion] 2026-02-03 07:46:37
>>soloma+An
That's fair to say, yes, with the important caveat that it isn't a 1:1 replacement of Webflow, which is exactly the point.
◧◩◪
40. nasmor+og2[view] [source] [discussion] 2026-02-03 10:58:43
>>daniel+iG1
Only the still meek vibe code payments, the truly brave simply install the Stripe MCP directly in their on site chat window
replies(1): >>daniel+4L4
◧◩◪◨⬒
41. ethbr1+Jm2[view] [source] [discussion] 2026-02-03 11:44:52
>>jlaroc+qp1
There are two forms of business software gen AI coding is 100% going to eat:

   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.

replies(1): >>roboca+AT4
◧◩
42. thephy+0p2[view] [source] [discussion] 2026-02-03 11:59:23
>>wtp1sa+77
It’s generally a tradeoff decision between comparative advantage of a vendor versus {price cost and contracting cost}.

Contracting my cost is the difference in costs for a contract across companies versus a purely internal project. This could involve the lawyers on both sides, the time taken to negotiate which party is responsible for what deliverable / risk, the cost to enforce the contract, the time taken for negotiations/ iterations, etc.

One efficient company doing it internally is obviously efficient. Two inefficient companies negotiating a contract is obviously inefficient. The interesting questions are the other 2 quadrants, where the answer may change between the LLM case and non-LLM case.

◧◩
43. mattma+tr2[view] [source] [discussion] 2026-02-03 12:17:08
>>wtp1sa+77
Well in that case the provider is likely paying for insurance and charging you a mark up, so you could likely just buy the insurance and save the markup anyway.
◧◩◪◨
44. btown+sy2[view] [source] [discussion] 2026-02-03 13:03:52
>>s5fs+hm
Adding that this just gets worse when databases are peppered with direct access by vibe-coded applications that don’t look at production data or gather these insights before deciding “yeah this sounds like the format of text that should go in the column with this name, and that’s the column I should use.”

And now there’s an example in the codebase of what not to do, and other AI sessions will see it, and follow that pattern blindly, and… well, we all know where this goes.

◧◩
45. grvdrm+a73[view] [source] [discussion] 2026-02-03 15:57:02
>>WarmWa+qv
Is this a tool deployed into an internal production environment? Or is it more of “dev” or “business user desktop” type app that isn’t deployed formally.

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.

◧◩◪◨
46. magica+gD3[view] [source] [discussion] 2026-02-03 18:04:57
>>mwigda+5K
> 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.

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.

◧◩◪◨
47. magica+XE3[view] [source] [discussion] 2026-02-03 18:10:26
>>graeme+RM
> 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 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.

◧◩◪◨⬒⬓
48. daniel+sO3[view] [source] [discussion] 2026-02-03 18:45:23
>>Manuel+HR1
This is the benefit few understand properly. The storage layer is where you get a lot of benefits.
◧◩◪◨
49. dehugg+J64[view] [source] [discussion] 2026-02-03 20:02:37
>>heavys+mm1
i love the assumption by default that "ai generated" automatically excludes "human verified".

see, i actually read and monitor the outputs. i check them against my own internal knowledge. i trial the results with real trouble shooting and real bug fixes/feature requests.

when its wrong, i fix it. when its right, great we now have documentation where none existed before.

dogfood the documentation and you'll know if its worth using or not.

replies(1): >>heavys+Bc5
◧◩◪◨
50. dehugg+N74[view] [source] [discussion] 2026-02-03 20:06:16
>>palmot+NM
Whats with this assumption that there's no human involvement? I dont just say "hey scan this 2m loc repo and give me some docs'... that would be insane. T

he AI is there to do the easy part; scan a giant spaghetti bowl and label each noodle. The humans job is to attach descriptions to those noodles.

Sometimes I forget that people on this site simply assume the worst in any given situation.

◧◩◪◨
51. daniel+4L4[view] [source] [discussion] 2026-02-03 23:31:50
>>nasmor+og2
this is hilarious
◧◩◪◨⬒⬓
52. roboca+AT4[view] [source] [discussion] 2026-02-04 00:18:41
>>ethbr1+Jm2
> I'd bet on in-housing

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

replies(1): >>ethbr1+Fr6
◧◩◪◨⬒
53. heavys+Bc5[view] [source] [discussion] 2026-02-04 02:25:27
>>dehugg+J64
Literally several times a week, I have to close PRs with docs that clearly no one read because they are blatantly wrong. This happened after LLMs. If what you're claiming is happening, I'm not seeing it anywhere.

AI is incapable of capturing human context that 99.999% of the time exists in people's brains, not code or context. This is why it is crucial that humans write for humans, not an LLM that puts out docs that have the aesthetics of looking acceptable.

◧◩◪◨
54. Quiark+Fm5[view] [source] [discussion] 2026-02-04 03:58:13
>>charci+5Z
yeah but it doesn't :)
◧◩◪◨⬒⬓⬔
55. ethbr1+Fr6[view] [source] [discussion] 2026-02-04 13:13:42
>>roboca+AT4
There would definitely need to be new positions / roles hired internally.

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.

[go to top]