Are they bleeding? Their multipliers seem to be reasonable. They are not offering $60 worth of usage for $10 on every model, only some. In the case of the expensive ones, it is only $15.
Given how subscription models work (not every one uses every last $ of their plan), they should achieve breakeven soon enough I guess.
Making SVGs is coding (of a very specific markup language). So it's not actually absurd. We've also seen that more capable models are generally better at everything minus benchmark contamination (benchmaxxing) anomalities.
So if you don't know what CI is, what does "I am someone in tech", mean? Marques Brownlee probably doesn't know CI is, but he's also in tech. Because if you by mean "I am in tech" that "I am a software engineer", and you don't know what CI is, then boy; I'd be worried for you.
Also the case of 'learning that someone did updates directly on AWS console instead of terraform and losing 0.5 or more days cleaning up the resulting mess'
I am a Site Reliability Engineer, I have been for close to a decade, and this is not as common an abbreviation as you think it is. Also, my entire job isn't in question because I didn't memorize shorthand for a term that I don't use in my day-to-day.
Really appreciate getting downvoted to hell for saying "We can't throw readers a simple bone?"
All I'm asking for is CI(Continuous Integration) in the first paragraph.
I didn't say I don't know what Continuous Integration was. I said I didn't know what "CI" stood for.
Cannot stress enough, this is like, basic communication/writing that they teach in elementary school.
But I'm so happy you're able to get off on your feelings of superiority that you always automatically know what those two letters stand for. I hope that translates to meaningful happiness and fulfillment in your life.
Overly complex; yaml files, heavy framework. Same mistake as Claude Code's Dynamic Workflows. Why not just use the dehydrated skills as the workflow skeleton and use custom guidance docs to hydrate the skills with taste and preference depending on the domain of the task? Now you can build a library of small workflows that compose into larger workflow, and you can export any workflow as a single skill to be used in other harnesses. For example, I have a code.md. It's really small, just a bit of taste preference. If I'm using it to hydrate orch-work for coding tasks, then maybe I want to create a code.api.md which hydrates for further specificity if the task is about creating APIs. Then when new models come out, I can just delete code.api.md and leave it as code.md for /orch-work to read from within a workflow because newer models won't need as much prescription.
Part of what's happening is this is running on Kubernetes, which is oft described as "Overly complex; yaml files, heavy framework" but has value regardless, as perceived by being an industry standard. All the things you describe are well and good, but do not address how one runs many of them reliably (from an infra stand point)
> This plus the memory issues make dreams of long horizon agents, that could plausibly handle changing specifications, quite implausible with current architectures.
Any reason why that can't be solved through context management and keep-forward scaffolding?
And who’s to manage context? And who’s building the scaffolding? Yes, AI can be used for both, but you do realize that all this being self-contained and regulated internally is what makes biological agents successful agents, right? If you break the process apart and need to dial back in these aspects, and can only do so with human input, or another agent which will need the same handholding the one whose issues you’re solving for, where’s the agency?
reply