Replying for the ~5 people who happened to download earlier this afternoon, the rc20 build that was uploaded earlier today was missing the update server URL. Re-downloading rc20 should have a corrected build that will notify you of any updates in the future.
Almost certainly not; it really depends on how iCloud handles the sync. Cassava supports (at the moment) CSV (and its variants TSV, etc.) and JSON files. If your sync mechanism works well for those files in a text editor like vscode or sublime, then it will work well with Cassava. If not, there's not much we can do on our end - that's really a problem with how the sync mechanism works.
Linux support is there and working, half my team uses arch btw. Windows is working, I just don't build for it right now.
Excel is cripplingly slow (thought more capable). I don't like using text editors for sheet data; it's simply not as ergonomic to browse a CSV as a text file.
I've spent the last 8 weeks or so building the spreadsheet tool I want to see in the world. CSVs as first-class citizens with the ergonomics and speed of my text editor. It's been a great opportunity to explore building GUIs in rust, and to really experiment with coding assistants.
My experience thus far is that the local models are a) pretty slow and b) prone to making broken tool calls. Because of (a) the iteration loop slows down enough to where I wander off to do other tasks, meaning that (b) is way more problematic because I don't see it for who knows how long.
This is, however, a major improvement from ~6 months ago when even a single token `hi` from an agentic CLI could take >3 minutes to generate a response. I suspect the parallel processing of LMStudio 0.4.x and some better tuning of the initial context payload is responsible.
I see this as the next great wave of work for me and my team. We sustained our business for a good 5–8 years on rescuing legacy code from offshore teams as small-to-medium sized companies re-shored their contract devs. We're currently in a demand lull as these same companies have started relying heavily on LLMs to "write" "code" --- but as long as we survive the next 18 months, I see a large opportunity as these businesses start to feel the weight of their accumulated tech debt accrued by trusting claude when it says "your code is now production ready."
Looking forward to trying this out. An early comment: I would love to be able to override tool descriptions and system prompts from a config. Especially when working with local models, context management is king and the tool descriptions can be a hidden source of uncontrollable context.
Like my co-founder said, we're a small company based in the US, and hiring in foreign jurisdictions is both expensive and time consuming. We're currently set up to hire in the US and Canada, and while we'd be willing to expand our footprint for the right candidate, the easiest thing for us is to look for candidates in our current operating jurisdictions.
Seeking a skilled frontend-focused full-stack engineer who thrives on building beautiful and functional user interfaces, but still feels comfortable on the back-end.
While we’re looking for developers with strong technical skills we don’t typically hire for experience in a particular framework or technology. We’re mostly seeking generalists that enjoy working in new technical stacks and have exceptional communication skills; because we’re a small company, everyone here takes on a lot of roles, and strong relationships with our clients are essential to our success.
We offer a 20-hour work week, retirement and health benefits, a competitive salary, an unlimited vacation and parental leave policy. You can read more on our work philosophy here: https://www.apsis.io/mission.
If you're interested, please reach out to us with any questions or with your resume at [email protected].
I agree with the sentiment elsewhere in this thread that this represents a "hideous theft machine", but I think even if we discard that, this is still bad.
It's very clear that generative has abandoned the idea of creative; image production that just replicates the training data only serves to further flatten our idea of what the world should look like.
The bottleneck is not putting code on the hard drive, or turning my thoughts into code — the productivity bottleneck is thinking and frankly no LLM is thinking better than an average developer.
Even if that’s what they mean (and I agree, that’s plausible, though not obvious) it’s still an asinine statement in the context of their broader thesis: advancements in generative AI are going to power the rise of the solopreneur. In absolute terms, an individual developer may be more productive in 3 years than they are today, but in relative terms, they will still be underpowered when compared to large teams building complex software. It only makes sense if we also assume the consumer and quality bar of today as well — and I don’t think LLMs are expected to crack time travel.
There will still be successful solopreneurs, just as there are today, but the idea that tooling-based productivity gains for individual developers are going to drive a power shift towards solo development and away from team-based companies is stupid.
Depends on if you think AI is more like a shovel or an excavator. The article to me implies a shovel: a tool used by one person to increase individual productivity. An excavator is not run by a single worker — it’s run by a team. If AI assisted coding is an excavator, a solo developer won’t outperform a 100 person dev team, because they won’t be able to operate the AI tooling efficiently or effectively.