Tony Bytes

Do LLMs Kill Config Generators?

2026-04-05T00:00:00+00:00

I once wrote a blog post about how to create .gitignore files by using gitignore.io. For those that haven’t used it before, it’s a website and api that lets you compose a .gitignore for a project by listing the technologies your project will use (either in their website or by curl’ing the service on the CLI), and it spits out a .gitignore accordingly.

This service did a pretty good job, and I would routinely reach for it when starting new projects. I liked it; it was an improvement from copy-pasting example snippets from various other .gitignore files found on GitHub.

But it occurred to me today that I stopped using this tool and in fact will probably never use it again. Not because it’s bad, but because, well - an LLM will just create this file now. But it’s more subtle than that. It’s not like I’ve asked an LLM to specifically create this file for me lately - or I might have had these thoughts sooner - it will create it as a sub task of setting up a new project and I won’t even notice unless something weird shows up in a git status that would normally go in the ignore.

So that got me thinking about config generators more broadly.

When was the last time I wrote a Dockerfile? A Github workflow? A terraform module? A compose file?

These used to be routine tasks for me in my day job as an Infrastructure Engineer, and I can honestly say I haven’t done any of these by hand once in 2026, despite having set up several projects that called for all of them since the beginning of the year.

LLM-powered coding tools like Claude Code, Cursor, and Copilot do a great job of setting up all of these things, and they often do them without asking anything beyond the initial project setup, or feeding them an example project to reference.

So… are config generators dead? Are project scaffolds dead? Are cookie-cutters dead?

I honestly don’t know, but I can speculate based on my own usage of LLMs that the work these tools performed will now be done by LLMs whenever it’s feasible for them to do so, and the only situations where writing or generating a config file will make sense are:

LLMs don’t have the ability to do it yet for whatever reason
Using a tool will save a meaningful number of tokens (you can imagine having an LLM write a complicated terraform module when it could use an existing one, or a Github workflow when you know you have an existing one that’s basically perfect, etc)
You need the deterministic output of a tool over an LLM for a config

But I’d push back on that last one. Chatting with my own friendly neighborhood Clanker (Opus 4.6), the example it gave was generating IAM policies according to company cloud requirements. In this situation, a generator ensures your IAM policies are created properly and include the right things (AdministratorAccess for the win!).

But that’s not something I’d use a generator for, or ever have, really - that’s more like validation. And I do still need to validate config. I need to validate Dockerfiles, Github workflows, IAM policies, terraform modules (at least the output of a plan). There’s a bigger thought here - that a lot of my work now is spent steering an LLM at the start of a task and validating its outputs at the end - but that’s meta commentary for another post.

So does that mean the value for devs looking to build useful tools in the config space is moving from generators to validators?

Maybe? I’m not sure, but I’m going to speculate that probably, yes, validators are still useful, and will continue to be.

Let me know what you think in the comments that I haven’t yet enabled below.

Hello, World

2026-04-04T00:00:00+00:00

Earth, photographed by Artemis II Commander Reid Wiseman from the Orion spacecraft. NASA

Generating a .gitignore for a Project

2024-05-01T00:00:00+00:00

The company Toptal runs a wonderful api for composing a .gitignore on the fly.

By composing, I mean you give it a list of components that should be considered, and it generates a .gitignore snippet for each and concatenates them into one.

The api has a web interface at gitignore.io:

But also an api at https://www.toptal.com/developers/gitignore/api/ that can be interacted with from the command line:

$ curl -s https://www.toptal.com/developers/gitignore/api/
gitignore.io help:
  list    - lists the operating systems, programming languages and IDE input types
  :types: - creates .gitignore files for types of operating systems, programming languages or IDEs

Let’s use the api to create some .gitignore files for a project.

MacOS

If the project will be developed on MacOS, let’s make sure to ignore the annoying files it generates automatically:

$ curl -s https://www.toptal.com/developers/gitignore/api/macos

This returns:

# Created by https://www.toptal.com/developers/gitignore/api/macos
# Edit at https://www.toptal.com/developers/gitignore?templates=macos

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

# End of https://www.toptal.com/developers/gitignore/api/macos

Pretty neat! But you probably won’t just be concerned with ignoring MacOS generated files. Let’s say we are building a website using the static site builder called hugo and we want to include this as well.

MacOS + Hugo

$ curl -s https://www.toptal.com/developers/gitignore/api/macos,hugo

This returns:

# Created by https://www.toptal.com/developers/gitignore/api/macos,hugo
# Edit at https://www.toptal.com/developers/gitignore?templates=macos,hugo

### Hugo ###
# Generated files by hugo
/public/
/resources/_gen/
/assets/jsconfig.json
hugo_stats.json

# Executable may be added to repository
hugo.exe
hugo.darwin
hugo.linux

# Temporary lock file while building
/.hugo_build.lock

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

# End of https://www.toptal.com/developers/gitignore/api/macos,hugo

Notice that the result is the composition of a MacOS snippet and a Hugo snippet! Pretty neat.

Okay, next, let’s say our hugo site will be making use of some Nodejs modules, and include a section for Node.

MacOS + Hugo + Node

$ curl -s https://www.toptal.com/developers/gitignore/api/macos,hugo,node

This returns:

# Created by https://www.toptal.com/developers/gitignore/api/macos,hugo,node
# Edit at https://www.toptal.com/developers/gitignore?templates=macos,hugo,node

### Hugo ###
# Generated files by hugo
/public/
/resources/_gen/
/assets/jsconfig.json
hugo_stats.json

# Executable may be added to repository
hugo.exe
hugo.darwin
hugo.linux

# Temporary lock file while building
/.hugo_build.lock

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

### Node ###
# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*
.pnpm-debug.log*

# Diagnostic reports (https://nodejs.org/api/report.html)
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json

# Runtime data
pids
*.pid
*.seed
*.pid.lock

# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov

# Coverage directory used by tools like istanbul
coverage
*.lcov

# nyc test coverage
.nyc_output

# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
.grunt

# Bower dependency directory (https://bower.io/)
bower_components

# node-waf configuration
.lock-wscript

# Compiled binary addons (https://nodejs.org/api/addons.html)
build/Release

# Dependency directories
node_modules/
jspm_packages/

# Snowpack dependency directory (https://snowpack.dev/)
web_modules/

# TypeScript cache
*.tsbuildinfo

# Optional npm cache directory
.npm

# Optional eslint cache
.eslintcache

# Optional stylelint cache
.stylelintcache

# Microbundle cache
.rpt2_cache/
.rts2_cache_cjs/
.rts2_cache_es/
.rts2_cache_umd/

# Optional REPL history
.node_repl_history

# Output of 'npm pack'
*.tgz

# Yarn Integrity file
.yarn-integrity

# dotenv environment variable files
.env
.env.development.local
.env.test.local
.env.production.local
.env.local

# parcel-bundler cache (https://parceljs.org/)
.cache
.parcel-cache

# Next.js build output
.next
out

# Nuxt.js build / generate output
.nuxt
dist

# Gatsby files
.cache/
# Comment in the public line in if your project uses Gatsby and not Next.js
# https://nextjs.org/blog/next-9-1#public-directory-support
# public

# vuepress build output
.vuepress/dist

# vuepress v2.x temp and cache directory
.temp

# Docusaurus cache and generated files
.docusaurus

# Serverless directories
.serverless/

# FuseBox cache
.fusebox/

# DynamoDB Local files
.dynamodb/

# TernJS port file
.tern-port

# Stores VSCode versions used for testing VSCode extensions
.vscode-test

# yarn v2
.yarn/cache
.yarn/unplugged
.yarn/build-state.yml
.yarn/install-state.gz
.pnp.*

### Node Patch ###
# Serverless Webpack directories
.webpack/

# Optional stylelint cache

# SvelteKit build / generate output
.svelte-kit

# End of https://www.toptal.com/developers/gitignore/api/macos,hugo,node

A file with a section for MacOS, Hugo, and Node!

Oh, let’s add Go, too, since it’s possible to add go modules to a Hugo site:

MacOS + Hugo + Node + Go

# Created by https://www.toptal.com/developers/gitignore/api/macos,hugo,go
# Edit at https://www.toptal.com/developers/gitignore?templates=macos,hugo,go

### Go ###
# If you prefer the allow list template instead of the deny list, see community template:
# https://github.com/github/gitignore/blob/main/community/Golang/Go.AllowList.gitignore
#
# Binaries for programs and plugins
*.exe
*.exe~
*.dll
*.so
*.dylib

# Test binary, built with `go test -c`
*.test

# Output of the go coverage tool, specifically when used with LiteIDE
*.out

# Dependency directories (remove the comment below to include it)
# vendor/

# Go workspace file
go.work

### Hugo ###
# Generated files by hugo
/public/
/resources/_gen/
/assets/jsconfig.json
hugo_stats.json

# Executable may be added to repository
hugo.exe
hugo.darwin
hugo.linux

# Temporary lock file while building
/.hugo_build.lock

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

# End of https://www.toptal.com/developers/gitignore/api/macos,hugo,go

That’s our completed file for an example project being programmed on a MacOS and using Hugo, Node, and Go!

Extras

Use gitignore.io domain instead

The domain https://gitignore.io runs a redirect service to https://toptal.com/developers/gitignore so the api can be accessed in a more memorable way. Just add –location/-L to the curl command to follow redirects.

$ curl -sI https://gitignore.io/api/
HTTP/2 301
date: Fri, 17 May 2024 19:16:12 GMT
content-type: text/html
content-length: 167
location: https://www.toptal.com/developers/gitignore/api/
cache-control: max-age=3600
expires: Fri, 17 May 2024 20:16:12 GMT
server: cloudflare

So, for instance, a Python .gitignore can be generated by running:

$ curl -sL https://gitignore.io/api/python

Shell function / Git alias

Finally, as another extra the api can be added as a shell function or git alias, as described in their documentation.

Let’s add a git alias:

$ git config --global alias.ignore \
'!gi() { curl -sL https://gitignore.io/api/$@ ;}; gi'

And use it to generate a Rust .gitignore:

$ git ignore rust,macos

Pretty slick, right!?