UK, USA and Singapore are the popular choices for this. UK is simple and cheaper, Singapore is a bit more expensive. I don’t see a reason to go USA route unless you are seeking investment from there.
I’m using UK myself. It takes a few forms and half a day to get a working Wise/Stripe account.
I think this is a common sentiment among heavy users of AI that also still cares about code quality.
I've built up a skill harness and review flow that makes Opus generate slop-free code 90% of the time. But the remaining 10% requires me to stay at the helm. Especially in the early stages.
I would love to use loops to automate more, but I couldn't do it with the current generation models.
And on the back of my mind I'm still evaluating the possible future where we are forced to API pricing. I'm currently paying $400 for Opus, and use around 1.5-2 billion tokens per day. This will cost around $20k/m with API pricing. And I don't want to even imagine the possible scenario of getting locked out of frontier models because of politics.
Will the models get better to cut me out of the loop completely? I believe so.
Will the open source models catch up tho SOTA models, and diversify from China-only? I hope so. Otherwise 2 superpowers will wield a soft power that can cripple the tech industries of all other countries.
Even that would be more meaningful test. They basically coated the ball with a strong smell, then they prepped the dog with that smell, then set it loose in a 5x5 meter area.
"Our tests gave models the vulnerable function directly, often with contextual hints (e.g., "consider wraparound behavior")."
And it's very valid. Because otherwise you would ask Claude to trim a tree and it would go raze the whole forest and plant new seeds. This was the primary pain point last year, especially with Sonnet.
Similar usage here. But I encountered this moments, and I chalk it up to the random nature of LLMs. Back in Sonnet 3.5 days, it would happen every other day. I even build an 'you are absolutely right' tracker back then to measure it. Opus 4.6, maybe once or twice a month.
We are not there yet. While there are teams applying dark factory models to specific domains with self-reported success, it's yet to be proven, or generalizable enough to apply everywhere.
I created a system which I call 'devlog'. Agent summarizes what it did & how it did in a concise file, and its gets committed along with first prompt and the plan file if any. Later due to noise & volume, I started saving those in a database and adding only devlog id to commit nowadays.
Now whenever I need to reason with what agent did & why, info is linked & ready on demand. If needed, session is also saved.
If you are not going all in with agents, yes, it would. On the other hand, the documentation & workflows need to be created only once. You need to invest a bit upfront to get positive RoI.
Anyone that have spent serious time with agents know that you cannot expect out-of-the-box success without good context management, despite what the hyping crowd would claim.
Have AI document the services first into a concise document. Then give it proper instructions about what you expect, along with the documentation created.
Opus would pass that.
We are not there yet, the agents are not ready to replace the driver.
I've been increasingly removing myself from the typing part since August. For the last few months, I haven't written a single line of code, despite producing a lot more.
I'm using Claude Code. I've been building software as a solo freelancer for the last 20+ years.
My latest workflow
- I work on "regular" web apps, C#/.NET on backend, React on web.
- I'm using 3-8 sessions in parallel, depending on the tasks and the mental bandwidth I have, all visible on external display.
- I've markdown rule files & documentation, 30k lines in total. Some of them describes how I want the agent to work (rule files), some of them describes the features/systems of the app.
- Depending on what I'm working on, I load relevant rule files selectively into the context via commands. I have a /fullstack command that loads @backend.md, @frontend.md and a few more. I have similar /frontend, /backend, /test commands with a few variants. These are the load bearing columns of my workflow. Agents takes a lot more time and produces more slop without these. Each one is written by agents also, with my guidance. They evolve based on what we encounter.
- Every feature in the app, and every system, has a markdown document that's created by the implementing agent, describing how it works, what it does, where it's used, why it's created, main entry points, main logic, gotchas specific to this feature/system etc. After every session, I have /write-system, /write-feature commands that I use to make the agent create/update those, with specific guidance on verbosity, complexity, length.
- Each session I select a specific task for a single system. I reference the relevant rule files and feature/system doc, and describe what I want it to achieve and start plan mode. If there are existing similar features, I ask the agent to explore and build something similar.
- Each task is specifically tuned to be planned/worked in a single session. This is the most crucial role of mine.
- For work that would span multiple sessions, I use a single session to create the initial plan, then plan each phase in depth in separate sessions.
- After it creates the plan, I examine, do a bit of back and forth, then approve.
- I watch it while it builds. Usually I have 1-2 main tasks and a few subtasks going in parallel. I pay close attention to main tasks and intervene when required. Subtasks rarely requires intervention due to their scope.
- After the building part is done, I go through the code via editor, test manually via UI, while the agent creates tests for the thing we built, again with specific guidance on what needs to be tested and how. Since the plan is pre-approved by me, this step usually goes without a hitch.
- Then I make the agent create/update the relevant documents.
- Last week I built another system to enhance that flow. I created a /devlog command. With the assist of some CLI tools and cladude log parsing, it creates a devlog file with some metadata (tokens, length, files updated, docs updated etc) and agent fills it with a title, summary of work, key decisions, lessons learned. First prompt is also copied there. These also get added to the relevant feature/system document automatically as changelog entries. So, for every session, I've a clear document about what got done, how long it took, what was the gotchas, what went right, what went wrong etc.
This proved to be invaluable even with a week worth of develops, and allows me to further refine my workflows.
This looks convoluted at a first glance, but it's evolved over the months and works great. The code quality is almost the same with what I would have written by myself. All because of existing code to use as examples, and the rule files guiding the agents. I was already a fast builder before, but with agents it's a whole new level.
And this flow really unlocked with Opus 4.5. Sonnet 3.5/4/4.5 was also working OK, but required a lot more handholding and steering and correction. Parallel sessions wasn't really possible without producing slop. Opus 4.5 is significantly better.
More technical/close-to-hardware work will most likely require a different set of guidance & flow to create non-slop code. I don't have any experience there.
You need to invest in improving the workflow. The capacity is there in the models. The results all depends on how you use them.
What you are describing is the most basic form of prompt injection. Current LLMs acts like 5 years old when it comes to cuddling them to write what you want. If you ask it for meth formula, it'll refuse. But you can convince it to write you a poem about creating meth, which it would do if you are clever enough. This is a simplification, check Pliny[0]'s work for how far prompt injection techniques go. None of the LLMs managed to survive against them.
You are describing the HN that I want it to be. Current comments here demonstrates my version sadly.
And, Solving this vulnerabilities requires human intervention at this point, along with great tooling. Even if the second part exists, first part will continue to be a problem. Either you need to prevent external input, or need to manually approve outside connection. This is not something that I expect people that Claude Cowork targets to do without any errors.
Solving this probably requires a new breakthrough or maybe even a new architecture. All the billions of dollars haven't solved it yet. Lethal trifecta [0] should be a required reading for AI usage in info critical spaces.
This was apparent from the beginning. And until prompt injection is solved, this will happen, again and again.
Also, I'll break my own rule and make a "meta" comment here.
Imagine HN in 1999: 'Bobby Tables just dropped the production database. This is what happens when you let user input touch your queries. We TOLD you this dynamic web stuff was a mistake. Static HTML never had injection attacks. Real programmers use stored procedures and validate everything by hand.'
It's mostly based on feelings/"vibes", and hugely dependent on the workflow you use. I'm so happy with Claude Code, Opus and plan mode that I don't feel any need to check the others.
I’m using UK myself. It takes a few forms and half a day to get a working Wise/Stripe account.