1,591 karma · joined October 14, 2015
> Unlike many prior models that release weights without reproducible data pipelines or regard for content-owner rights, Apertus models are pretrained exclusively on openly available data, retroactively respecting robots.txt exclusions and filtering for copyrighted, non-permissive, toxic, and personally identifiable content.
For repeating patterns I'll identify 1-3 commit hashes or PRs, reference them in a slash command, and keep the command up to date if/when edge cases occur.
For well defined tasks that Claude creates, I'll pass off execution to a locally run model (running in another Claude Code instance) and it works just fine. Not for every task, but more than you might think.
It's faster than I am, and it knows things like ffmpeg flags I don't care to memorize.
Even opencode running on a local model is decent at this.
I've experienced the exact issues you've described. I've also drastically reduced these issues via good instructions and automated followup passes that eliminate code that was created from ignored instructions.
It all feels like a hack, but the more I choose to trust it and treat it like it's the correct path and that it's just a different set of problems that need to be solved, the more success I have.
Coding bootcamps weren't really around when I started, but I avoided online courses and traditional learning methods. I would have also avoided bootcamps for the same reasons. I wanted to create and solve problems that were exciting, rather than follow through a textbook and take tests.
I'm self-taught and learned C in my early teens because I really wanted to do something that I couldn't find any code or preexisting solutions for, and I knew C was really the best way (for me) to solve it. I didn't want to learn it but I wanted the cool thing more, so I struggled through forum browsing, reading documentation, and trial/error and successfully got what I wanted while gaining more skills that led to where I am today.
The desire and drive to learn something matters more than the method, in my opinion.
This is a genuine question, since I see you work at CF. I'm very curious what the distinction will be between a user and a crawler. Is trust involved, making spoofing a non-issue?
I've been able to print baseplates that fit precisely inside different drawers, add magnets, etc.
Query -> Person Lookup -> Result-> Structured Output `{ firstName: "", lastName: "" }`
When result doesn't have relevant information, structured output will basically always output a name, whether it found the correct person or not, because it wants to output something, even if the fields are optional. With this example, prompting can help turn the names into "Unknown", but the prompt usually ends up being excessive and/or time consuming to get correct and fix edge cases for. Weaker models might struggle more on details or relevance with this prompt-only approach.
`{ found: boolean, missingFields: [], missingReason: "", firstName, lastName }`
Including one or more of these additional text output properties has an almost magical affect sometimes, reducing the required prompting and hallucinated/incorrect outputs.
For structured outputs, making fields optional isn't usually enough. Providing an additional field for it to dump some output, along with a description for how/when it should be used, covers several issues around this problem.
I'm not claiming this would solve the specific issues discussed in the post. Just a potentially helpful tip for others out there.
Using the API would have cost me $1200 this month, if I didn't have a subscription.
I'm a somewhat extensive user, but most of my coworkers are using $150-$400/month with the API.
Coming back to an implementation that has good test coverage, functions exactly as specified, and is basically production-ready is achievable through planning/specs.
Maybe Cursor can do this now as well, but it was just so far behind last time I tried it.
Sometimes I do planning in stronger models like Gemini 2.5 Pro (started giving o3 a shot at this the past couple days) with all the relevant files in context, but often times I default to Sonnet 4 for everything.
A common pattern is to have the agent write down plans into markdown files (which you can also iterate on) when you get beyond a certain task size. This helps with more complex tasks. For large plans, individual implementation-phase-specific markdown files.
Maybe these projects can provide some assistance and/or inspiration:
Here are some others, although some seem to be experiencing issues due to the current outage I can only presume.
- https://atlas.ripe.net/probes/public
- https://www.ihr.live/en/global-report
Write good base instructions for your agent[0][1] and keep them up to date. Have your agent help you write and critique it.
Start tasks by planning with your agent (e.g. "do not write any code."), and have your agent propose 2-3 ways to implement what you want. Jumping straight into something with a big prompt is hit or miss, especially with increased task complexity. Planning also gives your agent a chance to read and understand the context/files/code involved.
Apologies if I'm giving you info you're already aware of.
[0] https://code.visualstudio.com/docs/copilot/copilot-customiza...
[1] Claude Code `/init`
Maybe keeping your HN profile/gist/repo/webpage up to date would be better.
I'm using Claude Code on a large legacy monstrosity, and don't have this problem. There are problems and my flow automatically has it reviewing its own work in phased implementations, but even in the worst situations it's easy to get back on track.