I typically see the exact opposite problem when giving Claude the reins on a large undertaking.
Claude will, without prompting, break the implementation into 6 phases, and write AI slop “code as English” specs for each phase, each one with glaring errors and unintelligible terse jargon. It will review them all several times with major findings every time and tons of design churn…
Then it will implement a total heap of garbage over many hours of many agents, despite it working in “lanes” and in parallel, and with regular input needed.
Just thousands and thousands of lines of junk, which auto review then plays whack-a-mole to polish and fix. All the while it is able to see the errors and edge cases, yet fails to see the key architectural blunders that led to them in the first place.
I’ve had to fully rethink my approach to LLM tasks like this. For example, for library-esque modules, I have found that isolating the problem outside of the codebase is one useful approach. Something about the lack of noise. It can land on a cleaner solution that can be retrofitted.
I also find that asking it to implement end to end in one fell swoop with a very high level plan actually saves time and creates a cleaner result.
Seems like high-risk and low-reward for your network security. You could host it behind the WG interface, but… still exposing the castle’s master key to a python web app.
I have found that WG client management is as simple as a couple scripts and a TSV file to match pubkeys to users.
Anyhow, cool project and I like the overall concept of respecting existing config.
Well, I don't rely on tools to deliver security out of the box without me knowing what is all about. Therefore, this tool is not meant to be secure by itself. I use other means to achieve that.
With ParaSpace I can use a real terminal and my normal tooling to develop locally on fast booting isolated containers. I even get to bring my own dotfiles.
Claude already does summaries at the end of long output but they often sound even more like terse jargon nonsense than the long form, eg “the hardwired seam and the relocated barrel”.
Sometimes the summaries feel totally alien to the task or code.
The authors make some good points: compile time and test speed matter, platforms matter. But they really dodge the whole “guardrails matter” thing. And guardrails are going to win long term.
As for readability, the fact that AI-written Go closely resembles human-written Go is not necessarily a point in Go’s favour.
> "guardrails matter"
This thing has been solved in the 70s. Basically, have a powerful type system, and a compiler that beats you into submission when you try to stray from the straight and narrow. Languages like (S/OCa)ML, Haskell and Rust will bring this to you.
As a consequence, you fight the compiler, and once it submits, you have a good chance it's going to work. The compiler is also the ultimate refactoring tool here. Change the concept? Just change the type in the code and follow through by fixing the error messages the compiler spits out.
Of those, the weakest points for Haskell and the MLs is the platform and documentation. However, I don’t know if we can call this solved just yet. We may need to invent whole new types of guardrail.
but there are a whole lot of ways you can mess up a dull language, like shitty variable names, bad code organization, etc.
if an llm has learned dumb things from dumb users it could disproportionately cause provlems versus other languages, just by being "in a sloppy mood" when writing go.
Not panicking doesn’t mean working as intended, the biggest issue with LLM generated code is that it will do something that’s subtly wrong not that it will crash. It anything LLMs are too careful with Golang code and litter useless nil checks everywhere e.g. for function calls with pointer receivers. That whole fear of panics is totally overblown.
Sure, rust has better memory safety than most languages, but it also has a strong enough type system that many other kinds of programming errors won't pass compilation.
And by that point a program written in go has been deployed and making money for months. These are two wildly different languages, people should stop comparing them as if they're targetting the same niche. Checks and protections that rust has aren't necessary in most cases, but increase development and maintenance time.
Do you have some evidence of that? I use both daily and my experience has been the opposite, if anything. Once I was as proficient at Rust as I was at Go, the "increased development and maintenance time" disappeared completely.
Claude will, without prompting, break the implementation into 6 phases, and write AI slop “code as English” specs for each phase, each one with glaring errors and unintelligible terse jargon. It will review them all several times with major findings every time and tons of design churn…
Then it will implement a total heap of garbage over many hours of many agents, despite it working in “lanes” and in parallel, and with regular input needed.
Just thousands and thousands of lines of junk, which auto review then plays whack-a-mole to polish and fix. All the while it is able to see the errors and edge cases, yet fails to see the key architectural blunders that led to them in the first place.
I’ve had to fully rethink my approach to LLM tasks like this. For example, for library-esque modules, I have found that isolating the problem outside of the codebase is one useful approach. Something about the lack of noise. It can land on a cleaner solution that can be retrofitted.
I also find that asking it to implement end to end in one fell swoop with a very high level plan actually saves time and creates a cleaner result.
reply