Let’s talk about getting the computer to write code for you.

It might sound like something from the future, but it’s a daily practice in Go. I use code generation to handle the boring, repetitive parts of programming. It saves time, reduces mistakes, and keeps everything consistent. Think of it like teaching the computer to write its own instruction manual, so you don’t have to keep repeating yourself.

Go has a built-in feature called go:generate that makes this official. You add a comment, run a command, and Go creates new source files for you. It’s a powerful way to extend the language without changing the compiler.

Here’s a simple start. Imagine you have a set of status codes in your program.

type Status int

const (
    Pending Status = iota
    Processing
    Completed
    Failed
)

If you print Pending, you’ll just see the number 0. That’s not helpful for logs or messages. You could write a function to translate it, but you’d have to update it every time you add a new status. Instead, you can generate it.

//go:generate stringer -type=Status

Adding that line and running go generate ./... creates a new file. Inside it is a String() method for the Status type. Now, fmt.Println(Pending) prints the word “Pending”. It’s automatic and always correct.

This is the first pattern: generating string representations. It’s perfect for enums, error codes, or any set of constants. You describe what you have, and the tool writes the method to display it.

Another common task is making your structs work with JSON or databases. This often involves writing a lot of repetitive code to marshal, unmarshal, or scan data. You can generate this too.

Take a user struct. You want to save it to a database and read it back.

type User struct {
    ID        int       `db:"id"`
    Name      string    `db:"name"`
    Email     string    `db:"email"`
    CreatedAt time.Time `db:"created_at"`
}

Writing all the SQL queries to insert and select this data is tedious. It’s also easy to make a typo in a column name. Instead, you can use a tool that reads the struct tags and generates the SQL boilerplate.

You might run a command like sqlgen -type=User -table=users. This would produce functions for InsertUser, SelectUserByID, and so on. The generated code is type-safe. If you change the Email field’s type from string to []byte, the generated SQL code will fail to compile until you fix the mismatch. It turns a runtime database error into a compile-time error, which is much safer.

This leads to the second pattern: generating data access layers. It turns your struct definitions into a complete persistence layer. You define your data shape once, and the tedious CRUD operations write themselves.

When you build an application, you usually have interfaces. For testing, you need mock objects that implement those interfaces. Writing mocks by hand is slow and brittle. If the interface changes, you have to update the mock.

The solution is to generate them. Let’s say you have a repository interface.

type UserRepository interface {
    FindByID(ctx context.Context, id int) (*User, error)
    Save(ctx context.Context, user *User) error
}

Using a tool like mockgen, you point it at this interface.

mockgen -source=repository.go -destination=mock_repository.go -package=main

It generates a struct called MockUserRepository with all the methods. The mock has methods to set expectations, like EXPECT().FindByID().Return(...). You can control exactly what it returns for your tests. This is the third pattern: mock generation. It makes unit testing with dependencies straightforward and consistent.

In web services, you often work with protocol buffers for gRPC. You define your messages and services in a .proto file. Then, the protoc compiler generates the Go code. This is a classic form of code generation.

You write a definition like this:

message UserRequest {
  int32 user_id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

Running the protocol buffer compiler generates Go structs for the messages and client/server stubs for the service. All the serialization and network code is created for you. You just implement the business logic in the server handler. This is the fourth pattern: protocol buffer integration. It ensures your client and server speak the same language, literally.

Configuration is another area ripe for generation. Your app might read settings from a YAML file, JSON, or environment variables. You want to load these into a Go struct with the right types.

server:
  port: 8080
  timeout: 30s

database:
  host: "localhost"
  max_connections: 20

You could write the parsing code yourself, but it’s error-prone. A generated approach is safer. You define your config struct and add tags.

type Config struct {
    Server struct {
        Port    int           `yaml:"port"`
        Timeout time.Duration `yaml:"timeout"`
    } `yaml:"server"`
    Database struct {
        Host           string `yaml:"host"`
        MaxConnections int    `yaml:"max_connections"`
    } `yaml:"database"`
}

A generation tool can read this struct and create a function LoadConfig(path string) (*Config, error). This function handles reading the file, parsing the YAML, and setting default values. It can even generate validation. This is the fifth pattern: configuration binding. It gives you type-safe, validated configuration with very little code on your part.

As your project grows, you might want to embed build information into the binary. Knowing the exact Git commit, version, and build time is invaluable for debugging production issues. You can generate a Go file with this data during the build process.

A simple generator script might look like this:

// File: generate_build_info.go
package main

import (
    "fmt"
    "os"
    "time"
)

func main() {
    f, _ := os.Create("build_info.go")
    defer f.Close()

    commit := os.Getenv("GIT_COMMIT")
    if commit == "" {
        commit = "unknown"
    }

    fmt.Fprintf(f, `package main

const (
    Version   = "%s"
    GitCommit = "%s"
    BuildTime = "%s"
)`, "1.0.0", commit, time.Now().UTC().Format(time.RFC3339))
}

You run this script with go generate. It creates a build_info.go file. Your application can then print Version or GitCommit. This is the sixth pattern: embedding build-time information. It automates the process of stamping binaries with metadata.

Sometimes you need a collection of functions that are identical except for the type they operate on. Go doesn’t have generics in the traditional sense, but you can generate type-specific code.

Suppose you need a simple container for different types. Instead of writing IntContainer, StringContainer, and UserContainer by hand, you write a template.

// A template for a container in a file named container.tmpl
type {{.Name}}Container struct {
    items []{{.Type}}
}

func (c *{{.Name}}Container) Add(item {{.Type}}) {
    c.items = append(c.items, item)
}

func (c *{{.Name}}Container) Get(index int) {{.Type}} {
    if index < 0 || index >= len(c.items) {
        var zero {{.Type}}
        return zero
    }
    return c.items[index]
}

You write a small Go program that reads this template. It loops over a list of types like {{"Int", "int"}, {"String", "string"}}. For each pair, it executes the template, writing a new .go file. This is the seventh pattern: template-based generation. It’s useful for creating utilities that follow the same pattern across many types.

For web APIs, you might describe your interface with OpenAPI. This specification can be used to generate a full HTTP client in Go. You run a tool like oapi-codegen on your openapi.yaml file. It produces a client with methods for every endpoint. The generated code handles HTTP requests, JSON marshaling, and error responses. This is the eighth pattern: API client generation. It keeps your client code in perfect sync with your server’s API contract.

Validation is crucial. You want to check that data is correct before you use it. Writing validation functions by hand is repetitive. Generated validation is consistent and thorough.

You annotate your struct with tags.

type RegistrationForm struct {
    Username string `validate:"required,min=3,max=20"`
    Email    string `validate:"required,email"`
    Age      int    `validate:"min=18"`
}

A generation tool reads these tags and creates a Validate() error method for the struct. The method checks each field against the rules. This is the ninth pattern: generating validation code. It moves validation logic from runtime interpretation to compiled, fast code.

Finally, consider dependency injection. Connecting all the parts of a large application—databases, loggers, services—can be messy. Tools like Google Wire let you describe your component relationships in Go code. Then, you run go generate to create the exact initialization code that wires everything together.

You write a function that returns, for example, a *HttpHandler. In its body, you call constructors for a database, a logger, and a service. You don’t write the wiring logic yourself. Wire analyzes the code and generates a function that calls all the constructors in the right order, passing the results where they need to go. This is the tenth pattern: dependency injection wiring. It creates a clear, compile-time blueprint of your application’s object graph.

To bring it all together, I place these //go:generate comments right next to the code they relate to. When I or another developer looks at a struct, we immediately see there’s generated code for it. Running go generate ./... from the project root regenerates everything.

The beauty of this system is its simplicity. The generated code is plain Go. You can read it, and in most cases, you’d never know it was machine-written. It gets checked into version control, so builds are reproducible. If you change a struct tag and forget to regenerate, the existing generated code might not compile, alerting you to run go generate.

I find this approach transforms how I work. I spend less time on boilerplate and more on the unique logic of my application. The consistency it enforces is a huge benefit for team projects. Everyone’s mocks, stringers, and validators work the same way. It reduces the “it works on my machine” problem because the supporting code is generated from the same source definitions.

Code generation in Go isn’t magic. It’s a practical tool for automation. You start with a clear definition—a struct, an interface, a protocol file. You use a focused tool to transform that definition into executable Go code. The result is software that is more reliable, easier to maintain, and faster to build. It turns manual, repetitive tasks into a quiet background process, letting you focus on solving new problems.