71–80 of 89 posts
Earlier quoted context omitted.
You'd probably get much further along by fine tuning a small BERT style encoder model based classifier for it. IMO, even something as simple as training a linear classifier on the CLS token embeddings from a frozen encoder might work.
Yeah, Ive tried a bi-encoder, cross encoder and some small LLMs so far. I think I’ll do BERT soon too
I wouldn't underestimate the community effect of software. There are plenty of features that get shipped because a small but important minority requested them, only to benefit the long tail of users who never knew to ask for such a feature but now find it indispensable. If everyone is building their own isolated solutions, how does this positive externality manifest itself?
the features that affect the long tail can come from vocal complaints, but the best usually are ones you have to go asking around to find out about.
the really important people to ask have seemed to be the ones who don’t know how to ask or assumed they aren’t allowed to ask or something.
YMMV
I feel like the build threshold discussed is _extremely_ optimistic? > But does that always hold true? Let’s take the other side for a second by examining a much higher-priced SaaS product. Gemini reports that the price of a fully loaded Salesforce seat is ~$500/mo. Say you need 50 seats, that’s $25k/mo! > For that price you could have 1.5x engineering resources (25 / 16.7) working on your clone full time. Once again…
There is a range of information quality to sort out, but frontier coding models are learning a great deal from interacting with effective developers that the models can then model their agents on.
But they’ll never YOLO. Life goes on outside us and all around us ;)
I have multiple side projects that I would never have contemplated building before but whose utility now exceeds the much lower cost to build. I got a few weeks in to each and then stalled on all of them because the effort and motivation required to extend beyond the crazed early days _is_ still more than the utility I get. In a professional context, paying someone for software to do something outside my core domain…
He, the CEO, saw this as saving $40K per year. Until I asked simple questions:
What happens when Joe leaves?
When he goes on vacation?
If he has a health emergency?
The LLM isn't going to magically maintain the software, evolve, fix or support it.
What are you going to do?
The obvious conclusion was that he likely had to hire another person to work with Joe on this in-house CRM and, at a minimum, have redundant project ownership. Backup for development, maintenance and support.
The easy conclusion was: This will save him $40K a year until he decides to hire another person, at which point this "free" software will cost him $150K per year, $110K/year more than what he was paying Salesforce. If he does not hire a second person to work in the internal CRM, he might get lucky and things could be fine for a few years or he will have to face a crisis at some point when Joe is no longer around and nobody knows the first thing about his mini-CRM, not even the LLM.
I wonder how many people are falling for this trap these days. The allure of zero-cost software vs. the reality of introducing risk, technical debt and organizational risk.
To be sure, we are using LLM's extensively. However, until this is better understood, in the realm of software development it is constrained to what I would call "advanced auto complete" at the file level rather than anything resembling project-wide work. When we do write full applications, they are often relatively trivial internal tools that a person could complete in not much more than one week. In other words, easy to understand and code if another engineer had to jump in and none of these utilities are mission critical.
“buy vs. build. . . the calculus changed”
was the gun having a smoke?