I'm currently working on lastclone. It's a tool for backing up my SBOM (Software Bill of Materials), and more specifically the third-party open source libraries that are at risk of disappearing with the advent of AI, or simply if the maintainers decide to shut down the project. As a CTO, it's important to guarantee business continuity and to ensure that the open source projects we use can be easily recovered.
The lastclone project is written in Go. The version I'm working on is a CLI version. Some parts are developed with Claude Code, but I've run into certain issues.
The code suggested by Claude Code doesn't take into account the latest developments in Go. There are two main reasons for this.
First, there's the training data cutoff. Claude Opus 4.6 is the latest release to date, but the training is based on data up to May 2025. Since Go is a language that evolves regularly, the latest features present in 1.25 or 1.26 are not known to the model.
Second, an LLM model, no matter how good it is, is a statistical model that operates based on its training. In the case of Go, the majority of the codebase used for training was developed on earlier versions. This codebase hasn't necessarily been adapted to the language's new features, and therefore, the model isn't able to use them.
JetBrains comes to the rescue by publishing yesterday (20-FEB-2026) a plugin for Claude Code that allows it to be "instructed" on the latest best practices of the language. The plugin is well-structured and can detect the version of Go being used based on the go.mod file.
You can also add golangci-lint with the modernize linter and tell Claude in CLAUDE.md to run it on every code change as an ambulance at the bottom of the cliff.
Won’t stop Claude from writing “old” style, but it will fix the lint errors.
An aside: I find the range of possible meanings of “modern” fascinating. In some contexts it means post-Middle Ages, in some post-Industrial Revolution, in some mid-20th century, and in many (as here) it just means now-ish. (I’m ignoring non-temporal uses of it, which are a whole other thing.) This use, in the OP, is a particularly sharp one, since the JetBrains blog explicitly means in the last 6 to 12 months.
I looked it up, and apparently the first use of “modern” (well, “modernus”, but who’s counting) to mean “now, when things are up to date, not earlier when things were old fashioned” was in the 6th century CE. [1] And even though in formal contexts modernity is long past, its colloquial use continues to drift along with us.
Anyway, gotta go tell Claude to get with the times.
I'm currently working on lastclone. It's a tool for backing up my SBOM (Software Bill of Materials), and more specifically the third-party open source libraries that are at risk of disappearing with the advent of AI, or simply if the maintainers decide to shut down the project. As a CTO, it's important to guarantee business continuity and to ensure that the open source projects we use can be easily recovered.
The lastclone project is written in Go. The version I'm working on is a CLI version. Some parts are developed with Claude Code, but I've run into certain issues.
The code suggested by Claude Code doesn't take into account the latest developments in Go. There are two main reasons for this.
First, there's the training data cutoff. Claude Opus 4.6 is the latest release to date, but the training is based on data up to May 2025. Since Go is a language that evolves regularly, the latest features present in 1.25 or 1.26 are not known to the model.
Second, an LLM model, no matter how good it is, is a statistical model that operates based on its training. In the case of Go, the majority of the codebase used for training was developed on earlier versions. This codebase hasn't necessarily been adapted to the language's new features, and therefore, the model isn't able to use them.
JetBrains comes to the rescue by publishing yesterday (20-FEB-2026) a plugin for Claude Code that allows it to be "instructed" on the latest best practices of the language. The plugin is well-structured and can detect the version of Go being used based on the go.mod file.
You can also add golangci-lint with the modernize linter and tell Claude in CLAUDE.md to run it on every code change as an ambulance at the bottom of the cliff.
Won’t stop Claude from writing “old” style, but it will fix the lint errors.
An aside: I find the range of possible meanings of “modern” fascinating. In some contexts it means post-Middle Ages, in some post-Industrial Revolution, in some mid-20th century, and in many (as here) it just means now-ish. (I’m ignoring non-temporal uses of it, which are a whole other thing.) This use, in the OP, is a particularly sharp one, since the JetBrains blog explicitly means in the last 6 to 12 months.
I looked it up, and apparently the first use of “modern” (well, “modernus”, but who’s counting) to mean “now, when things are up to date, not earlier when things were old fashioned” was in the 6th century CE. [1] And even though in formal contexts modernity is long past, its colloquial use continues to drift along with us.
Anyway, gotta go tell Claude to get with the times.
1: https://en.wikipedia.org/wiki/Modernity#Etymology
Related, Using go fix to modernize Go code https://go.dev/blog/gofix
[dead]