I extensively use types to represent invariants in the code. "Invariants" can sound very computer science-y and obscure, but it can be as simple as "If you are passed a Username you are guaranteed that it has already been validated as being a 'valid' username by whatever the local definition of 'valid' is." It means that the rest of the code has no need to do the validation; indeed it is wrong to have any internal validation because any mismatch between that internal validation and the real validation creates a discontinuity that will at least create the opportunity for bugs and possibly security issues. If you want to change the definition of "valid" change it in the one place where it is defined. If you need another local definition, you create a new type to represent it.

AI can sort of use these types. However, it has a distinct tendency to want to crack into the types and add methods that break the invariants, like, "Hey, I'm loading usernames from some new source I've never loaded them before, let me just add a method

func (u *Username) Set(username string) { u.username = username }

on in there for you."

No. That is exactly what the username is not doing. Use the existing construction function and handle errors appropriately.

Which in a situation like this, may be to bail out at the first invalid username, but can also be "collect all the errors with errors.Join, do what you can, and return the entire error at the end". The AI has an extremely strong bias to just bailing on the first error regardless, because that's pretty much all the training data does. I can deal with that, though. That is arguably the "default" handling if I don't specify anything else.

It does also tend to sometimes try to splat down some validation code inside the program even so sometimes, because unfortunately, while I consider this a relatively basic technique upon which we build other ways of building good, strong programs, it is not really all that well-represented in the training data.

And I do not believe I have yet seen an AI spontaneously realize "Oh, I have an opportunity for a new type like this", even when it is working in a code base saturated in this pattern. If anything, like I said, it has a strong tendency to try to destroy this code if I don't stop it.

What I would say is that right now, AIs are great at blasting out scripting code. Which they are... when I am writing a throwaway script where I don't really care what happens to the code once it is run the one time I will run it, wow is it ever an advantage. I can write scripts in 10 minutes now that I would have quailed at writing at all in the Before AI Time.

But AI is always writing scripting code. It always wants to load some things in as strings, bash them around, fling around booleans and ints with wild abandon, and generally write the sort of code that will break down as it scales up. And AIs, being finite, will still choke on the code as it scales up, as many, many people have noticed. It blasts lines of code out so quickly that it overwhelms its own improvements in handling large code bases in as little as a week or two if you try to just vibe code without guiding it. The AIs still need good code bases, but they don't generate them yet.

My current task is wrangling an AI to try to turn certain permissions that exist in a MySQL database in a complicated schema into something that a different type of system can implement. I've had to correct it several times to, for instance, use the functions the internal project has defined for getting these things, which defines some rather non-trivial logic. It wants to use SQL directly. It is reluctant to connect to the database in the correct way the code wants. All of these things are overcome with prompting. This is actually still a fine tool for me, but I definitely think if your average interaction with an AI tool right now is 1. Make a prompt 2. Yeah, that's probably good enough, ship it, then you are going to mess your code base up something fierce. This particular thing isn't in Go but this seems a general AI trend.

Ask me again in a year. Who knows. I have to admit I'm not sure this will actually improve though, because like I said, the training data just doesn't look like this. One of the AI advances I'm hoping to see is something that allows them to train on a lot less data, so we can create curated sets of training data of just high-quality code instead of pouring every syntactically-correct (if that!) bit of Go code we can find in the entire world into the AI, because code quality seems generally distributed on a power law and the average bit of code's quality is actually pretty bad. I'd like an AI I can train on the best of the best rather than the average.