The value of Groq comes from its excellent price-to-performance ratio. Its inferencing speeds are faster than those of H200s, and it has the lowest costs in the industry. When running similar batch jobs across different providers compared to Groq, the processing speed can sometimes be more than 10 times faster. These figures are important for developing practical applications for production use. It's common for me to run workloads in Groq that cost less than $100, while the same workload can approach $1,000 on Bedrock or Gemini. They have tuned a set of OS models that can now deliver a full application. The speeds have allowed me to offload a lot of the functionality from heuristics to straight-up LLMs.
I think there is a different way to look at it. My personal experience is that enterprises that are at the forefront of adopting new ways of working, are now much more comfortable taking risks with building applications and insourcing SaaS functionality. The amount of custom software build is actually increasing and the codebase are getting more complex. Is there a price to pay down the road? Maybe.
> Ai promises to eliminate labor, so businesses correctly identify AI risks as free debt.
These aren't promises, they're just hopes and dreams. Unless these businesses happen to be signing contracts with AI providers to replace their labor in a few years, they're incorrectly identifying AI risks as free debt.
I absolutely agree with you and I’m hyperbolizing to highlight exactly how incorrect that “promise” is
Realistically, the execs see it as either them or their subordinates and the idea of a captain dying with a ship is not regarded as noble amongst themselves. So they’ll sacrifice the crew, if only for one more singular day at sea.
Agent mode without rails is like a boat without a rudder.
What worked for me was coming up with an extremely opinionated way to develop an application and then generating instructions (mini milestones) by combining it with the requirements.
These instructions end up being very explicit in the sequence of things it should do (write the tests first), how the code should be written and where to place it etc. So the output ended up being very similar regardless of the coding agent being used.
I've tried every variation of this very thing. Even managed to build a quick and dirty ticketing system that I could assign to the LLM of my choosing. WITH context. Talking Graph Codebase's diagrams, mappings, tree structure of every possibility, simple documentation, complex documentation, a bunch of OSS to do this very thing automatically etcetcetc.
In the codebase I've tried modularity via monorepo, or faux microservices with local apis, monoliths filled with hooks and all the other centralized tricks in the book. Down to the very very simple. Whatever I could do to bring down the context window needed.
Eventually.....your return diminish. And any time you saved is gone.
And by the time you've burned up a context window and you're ready to get out. Now you're expeciting it to output a concise artifact to carry you to the next chat so you don't have to spend more context getting that thread up to speed.
Inevitably the context window and the LLMs eagerness to touch shit that it's not supposed (the likelihood of which increases with context) always gets in the way.
Anything with any kind of complexity ends up in a game of too much bloat or the LLM removing pieces that kill other pieces that it wasn't aware about.
So, relying on a large context can be tricky. Instead I’ve tried to get to a ER model quickly. And from there build modules that don’t have tight dependencies.
Not the founder? maybe read Walter Isaacson's book.
Stock graph shows Tesla stock had no material impact from the Solar City purchase, 90% of it's value coming after 2020. Today, Tesla energy and solar dominates the industry to the point where every installer offers Tesla Solar including the largest US installer Sunrun.
> Not the founder? maybe read Walter Isaacson's book.
The company was founded in July 1 2003, Musk didn’t even hear about the company until 2004. That’s a rather large gap to call someone a founder. But hey it’s an arbitrary distinction so feel free to disagree.
> Stock graph shows Tesla had no material impact from the Solar City Purchase
From the announcement of the purchase to its completion Tesla’s stock dropped ~20%.
Buying or creating a solar company in house made sense, over paying to bail out a relatives solar company he was involved with didn’t. Solar City was in 1.5 Billion dollars in debt, their business model was failing, and they had just laid off 20% of their workforce so yea Tesla shareholders got hosed.
Tesla was nothing but two guys, a name, an office, and an idea when Musk invested $6.5 million into it. They had no technology, no car, no money, no nothing. That makes Musk a founder.
No, that makes Musk one of two series A investors.
> two guys, a name, an office, and an idea
Add in the paperwork they filled out and we call those things companies. The entire point of incubators like Ycombinator is getting companies to a point where someone would make a significant investment, Martin Eberhard, Marc Tarpenning and Ian Wright who joined a few months later pulled that first major hurdle off on their own.
If Musk had walked away they would’ve just kept looking because it was a very compelling investment as made clear by finding funding within a month of looking and the 1 million put up from a 3rd party.
I gave Zoho a compliment, not sure why there is so much defensiveness.
You are right - open source requires more work. My response related to open source was responding to the article's tone that it was surprising that anything could be cheaper than Google or Microsoft :) Which is silly.
Good point. I have been up way too long. I re-read the question now as just wanting alternatives.
I read the question earlier about email deliverability and black list management as being rhetorical in that those services are usually performed by a centralized service provider.
Glad someone was able to respond with some examples.
