I recently "vibe coded" a long term background job runner service... thing. It's rather specific to my job and a pre-existing solution didn't exist. I already knew what I wanted the code to be, so it was just a matter of explaining explicitly what I wanted to the AI. Software engineering concepts, patterns, al that stuff. And at the end of the day(s) it took about the same amount of time to code it with AI than it would've taken by hand.
It was a lot of reviewing and proofreading and just verifying everything by hand. The only thing that saved me time was writing the test suite for it.
Would I do it again? Maybe. It was kinda fun programming by explaining an idea in plain english than just writing the code itself. But I heavily relied on software engineering skills, especially those theory classes from university to best explain how it should be structured and written. And of course being able to understand what it outputs. I do not think that someone with no prior software engineering knowledge could do the same thing that I did.
I've heard a lot of people prefer OpenCode to Claude Code, myself included. Having tried both, I find myself having a much better time in OpenCode. Have you tried it?
I'll admit it lacks on the agent teams side but I tend to use AI sparingly compared to others on my team.
I’ve been using Claude Code for about six months and evaluated OpenCode on my Windows work laptop a few weeks ago. Found 3 dealbreakers that sent me back:
1. No clipboard image paste. In Claude Code I constantly paste screenshots – a broken layout, an error dialog, a hand-drawn schema – and just say “fix this.” OpenCode on Windows Terminal can’t do that without hacky workarounds (save to file, drag-and-drop, helper scripts). I honestly don’t understand how people iterate on UI without this.
2. Ctrl+C kills the process instead of copying. And you can’t resume with --continue either, so an accidental Ctrl+C means losing your session context. Yes, I know about Ctrl+Ins/Shift+Ins, but muscle memory is muscle memory. I also frequently need to select a specific line from the output and say “this part is wrong, do it differently” – that workflow becomes painful.
3. No step-by-step approval for individual edits. Claude Code’s manual edit mode lets me review and approve each change before it’s applied. When I need tight control over implementation details, I can catch issues early and redirect on the spot. OpenCode doesn’t have an equivalent.
All three might sound minor in isolation, but together they define my daily workflow. OpenCode is impressive for how fast it’s moving, but for my Windows-based workflow it’s just not there yet.
I think so. The last few months have shown us that it isn't necessarily the models themselves that provide good results, but the tooling / harness around it. Codex, Opus, GLM 5, Kimi 2.5, etc. all each have their quirks. Use a harness like opencode and give the model the right amount of context, they'll all perform well and you'll get a correct answer every time.
So in my opinion, in a scenario like this where the token output is near instant but you're running a lower tier model, good tooling can overcome the differences between a frontier cloud model.
I wonder if there's something to be said about screenshots preventing context poisoning vs parsing. Or in other words, the "poison" would have to be visible and obvious on the page where as it could be easily hidden in the DOM.
And I do know there are ways to hide data like watermarks in images but I do not know if that would be able to poison an AI.
Considering that very subtle not-human-visible tweaks can make vision models misclassify inputs, it seems very plausible that you can include non-human-visible content the model consumes.
While I don't use Gemini, I'm betting they'll end up being the cheapest in the future because Google is developing the entire stack, instead of relying on GPUs. I think that puts them in a much better position than other companies like OpenAI.
I use garage at home, single node setup. It's very easy and fast, I'm happy with it. You're missing out on a UI for it, but MountainDuck / CyberDuck solves that problem for me.
After years of using Garage for S3 for the homelab I’d never pick anything else. Absolutely rock solid, no problem whatsoever. There isn’t ONE other piece of software I can say that about, not ONE.
Major kudos to the guys at deuxfleurs. Merci beaucoup!
I used to be a big ruby/rails fan but I have to agree with you. I now write c-sharp and it's a lot less stressful than Ruby. If a Ruby/Rails codebases get to a large enough point it's really difficult to keep track of what types a method you wrote accepts. You end up just constantly double checking your own code. Or you end up with a few type checks and/or type conversions at the top of every method. And maybe I was doing it wrong because it was early on in my career. But when a method can accept literally anything and return literally anything, not even a strong IDE like RubyMine can save you.
For Mac, yes and no. IIRC you don't need a developer's license to build and sign software for yourself. But you do need one to distribute pre-built software.
You can still run unsigned software, but you need to approve 2? prompts, and also allow exception for every executable by going to Privacy & Security tab in settings.
IIRC there is a CLI command for achieving the same.
You can’t run unsigned software on Apple silicon. Note that when you build your software if you use Apple’s tools it will inject an ad-hoc signature into the product.
You very much _can_ run unsigned software on Apple silicon. At work my department has a bit less than 50 engineers with Macs (M1 to M4) and nobody complained that they can't build and run our product (using GCC from Homebrew, not Clang from Apple). But it involves some jumping through hoops, yes.
As mentioned above you have to approve the binary two times (at least), being careful the first time because the dialog popup offers to remove the binary. Also since our product has some networking to do one has to mingle with firewall settings to allow the binary to do the networking.
To check I did this: removed the signature (LC_CODE_SIGNATURE section) using lief Python package (no affiliation, just looked suitable for the task), checked by otool that the section is indeed gone, started the binary - it worked. The spctl said that the binary is "rejected", but it says so about every non-Apple binary I checked on my machine so not informative. The codesign tool shows "is not signed at all" on the binary with stripped signature.
I'm not too well-versed in OSX system/dev tools, so if there is a more correct/precise method of checking the signatures I'd very much like to know.
Nope, 15.7.2. Maybe there are some settings, unknown to me, that are configured by MDM and that allow for such behaviour - our Macbooks are managed by the employer and are intended for development, so would be logical to set them up this way.
_A Mac with Apple silicon doesn’t permit native arm64 code to execute unless a valid signature is attached. This signature can be as simple as an ad hoc code signature (cf. codesign(1)) that doesn’t bear any actual identity from the secret half of an asymmetric key pair (it’s simply an unauthenticated measurement of the binary)._
_For binary compatibility, translated x86_64 code is permitted to execute through Rosetta with no signature information at all. No specific identity is conveyed to this code through the device-specific Secure Enclave signing procedure, and it executes with precisely the same limitations as native unsigned code executing on an Intel-based Mac._
The signature that gets added is vaguely a hash of the binary. You probably want to look at the UUID that gets injected into your binary instead of this.
To be fair, there’s a massive banner on their front page warning users it’s in beta. Until they settle on a proper release it’ll continue to be a bit chaotic. All software development is like that.
It was a lot of reviewing and proofreading and just verifying everything by hand. The only thing that saved me time was writing the test suite for it.
Would I do it again? Maybe. It was kinda fun programming by explaining an idea in plain english than just writing the code itself. But I heavily relied on software engineering skills, especially those theory classes from university to best explain how it should be structured and written. And of course being able to understand what it outputs. I do not think that someone with no prior software engineering knowledge could do the same thing that I did.