The U.S. leadership has a bad habit of starting conflicts that the bulk of the population doesn't want, which leads to large political costs and resulting half-measures. Our current leadership literally ran on "no more wars." Morons.
I wonder if this is a sign of things to come for dirt-cheap model hosting: no servers running old versions, only new versions. Just to keep costs down.
Gemini is still my top choice within production software for typical data extraction from unstructured data. Gemini Flash Lite feels like a cheat code for speed, and it's really cheap.
Some other Chinese models are also fast and cheap, but a harder sell in a U.S. production environment.
Speaking from experience here, flash lite models have amazing price, speed, and perform far above their size, but are susceptible to very bad instruction following and recall when either complexity or context size inch up. They’ll just forget to apply your instructions to portions of the input, and repeat parts of the input that should be returned verbatim as direct quotes but with subtle changes (breaking urls, for example).
This was 3.5 flash lite, actually, and after prompt tuning. It was very clearly an issue that correlated with input (JSON array) size, the more elements in the batch, the higher the error rate.
3.0 flash (not lite) handled it like a champ though, fwiw.
Hi, I’m the author of this blog. It depends on how strong of a model you need, but in general, Qwen is easily the best among the Chinese models right now.
Googles local gemma models which target roughly the same parameter count range, are known for being a lot better at vision tasks than qwen, no idea if 3.8 has changed that though
It’s an extremely consistent experience, and you can sit in the front seat (something I like personally). With Uber and taxi services, you never know what kind of driver or ride you’re going to get.
They use to be (along with Lyft). But it's been a very long time since that was clearly true.
In reality I think you can get better experiences than a taxi with a rideshare service (which they really haven't been for a very long time), but it's very hit or miss.
So less consistently bad as a taxi service... but far from consistently good.
You really have to believe your own narrative to do well as a startup founder, even when evidence is initially scant. This likely also has a tendency to slide into self-delusion.
I'm tired of being strung along on these silly narratives. I can't wait for open-weight models to be deployed around the world just so people like Dario will shut up about the mystical levels of power these models have.
Yes, I’m a senior engineer at a 3-engineer startup, and there isn’t “junior-level” or “senior-level” work here. It’s all just work. Claude allows me to tear through the kind of gruntwork I’ve been doing ad nauseam for the last 15 years.
If my tasks were things like squeezing 3% more efficiency out of an algorithm, that might be different. Although, even then, my PM (!) used Claude to boost the efficiency of one of our more complex Postgres queries by up to 5x, in ways I honestly would not thought of doing. It was quite humbling. A former engineer here used pgMustard on the same query a couple years ago and claimed it was as fast as it could get.
I can’t speak for the kind of work done in the higher echelons of big tech, but for us, there isn’t much that Claude can’t help with.
Yeah those single points of failure/bottlenecks are prefect focal points for people with floating responsibilities and a good understanding of how to use claude.
The system-sweeping features I still would ask to review, but you can't argue with a DB query just getting faster.
> Although, even then, my PM (!) used Claude to boost the efficiency of one of our more complex Postgres queries by up to 5x
Would you be kind to describe what test set-up do you have that a PM felt safe enough to deploy the changed query without the fear they'll break something?
Who said they deployed it themselves? I would expect that they made a PR (probably with some benchmarks), and that there are tests ensuring that the results are the same independent of timing, so then the author of the comment could verify whether it still worked and reproduce the benchmark results and then chose where to approve and merge based on that.
The same techniques that were used to try to prevent regressions before we had LLMs still work for LLM-generated code, provided that you actually use them. If you have an insufficient test suite and a lax policy around who reviews code before merging, you're going to have a bad time even if you only have your seniors writing the code by hand.
They built a comparison harness between the old and the new query, and ran it across thousands to benchmark and ensure valid results. And then I reviewed the PR.
We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves.
I ended up building an agent orchestrator in Elixir and Phoenix, not because I love working in Elixir/Phoenix (I do, but I just don't write code by hand anymore), but because the BEAM/OTP capabilities genuinely worked more reliably and elegantly to solve our orchestrator challenges.
I see projects like Hologram potentially showing up as the right tool for the job much more often. The barrier to picking up a new tool/framework/stack is so low these days with agentic development, and it comes down to speed, capability, and reliability.
Ironically, I don't think agents are going to suggest anything like Hologram on their own, so it is still down to human engineers to push it into common use. That might be the biggest barrier to adoption: overcoming obscurity so that LLMs suggest it as a solution.
I'm on the opposite side of this. With LLMs, I no longer feel the need to use crazy frontend frameworks and abstractions. I'm back to building static HTML with minimal JS (and ideally no build step). Instead of using Tauri/Wails for GUI apps, I just use Swift.
I no longer try to build everything around my choice of language.
right, you're using the tool for the job. author was reaching for reliability, re: OTP/beam. now we don't know if they actually needed it, but, you're saying the same thing to me
It was the BEAM process/actor model that fit much better for managing agents, and then there was the out-of-the-box live UI with Phoenix/LiveView that was really appealing. I had started the project in Typescript/Node (because that's my company's primary stack choice), but it hit a plateau in reliably managing multiple independent long-lived agent processes (not really what Node is designed for). I could have used an even more boring tech like Go with more robust process management, but Elixir and Phoenix also came with a lot out of the box. It's no surprise that OpenAI's reference project for agent orchestration (https://github.com/openai/symphony) is also written in Elixir.
i see one person saying it is now cheap to support the new hotness, which previously would have been its own project, and another saying it has become cheap again to do things the boring-yet-reliable way that maybe didn’t used to scale so great.
that's fair. probably i attached more weight to the opening line: "We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves."
assuming author wouldn't choose X _just because_ it is the new hotness
My framework/stack choice on the other hand is now much more dictated by the quantity and depth of existing literature on the internet about that stack.
does that really help? I have had llms fumble pretty simple stuff in html/css and probably that's what there's more information on the internet, while with simple packages/languages with clear cut semantics it seems to be much better, even if off some samples pasted into context.
[edit] the case was simply, write me an html landing page, with a navbar, a content area and a footer, make sure the content on each area doesn't extend beyond 1200px wide , make each container centered (paraphrasing)
reply