You know that moment. You’re editing a config file. You need to comment out a line to test something. And you remember: JSON doesn’t allow comments. You curse. You delete the line. You hope you remember what it was for later. You never do.
This is the shared trauma of every developer who has ever touched a JSON config. And yet, despite decades of better alternatives, JSON remains the default. Why? Because the JavaScript ecosystem got there first, and we’re all too lazy to change. Not because JSON is good.
JSON isn’t the right format for humans. It’s the right format for machines that want to ignore humans.
Let’s be clear about what JSON actually is. It’s a data interchange format. Designed to be parsed by computers, not written by people. No comments. No trailing commas. No flexibility. It’s the format you’d pick if you were writing a quick script to move data from an API to a database. It’s the last format you’d pick if you were designing something for a human being to read and edit every day.
Yet look around. Your editor config. Your linter config. Your test config. Your CI pipeline config. JSON. Everywhere. The reason? Not because it’s superior. Because JavaScript developers with a ‘good enough’ mindset built these tools, and JSON is the lowest common denominator. It’s easy to parse. It deserializes directly into objects. And it’s already everywhere. So we’re stuck.
Every JSON config file is a monument to the path of least resistance.
But there’s a way out. And it’s not TOML. It’s not YAML. They’ve solved the comment problem, sure, but they still require you to learn a format. To remember the syntax. To debug a typo in your indentation. No, the real escape is the end of config files entirely.
Eric Raymond once suggested writing configuration in plain English. It didn’t work back then because computers couldn’t understand English. But now we have LLMs. Large language models that can read, interpret, and generate structured data. The config file of the future isn’t a file. It’s a sentence: ‘Use port 3000, enable logging at debug level, but instead of logging to a file, send it to the console, and let the frontend proxy to localhost:5173.’ And an LLM translates that into the required format—or better yet, directly applies it.
Now you might be skeptical. LLMs are nondeterministic. They make mistakes. You can’t have a prompt-based system that occasionally forgets the port. That’s a fair concern. But the same was said about pretty much every new technology. And here’s the thing: LLMs don’t have to replace the config system entirely. They can be used to generate, validate, and explain config files. ‘What does this flag do?’ You ask. The LLM explains it. ‘Change the timeout to 10 seconds.’ The LLM edits the JSON or TOML correctly. The config file remains, but you never touch it again.
That’s the shift we’re heading towards. The death of the config file as a manual task. Not because we invent a better serialization format, but because we stop needing to write serialization formats at all. The language of the future is not a superset of JSON. It’s natural language.
The most human-readable format is the one you never have to read.
So yes, JSON config files will die. Not with a bang. Not with a better format. But with the rise of AI that understands us better than any spec. And when that happens, your future self will look back at the comment-free JSON file and wonder how humanity survived it for so long.
FAQ
Q: LLMs are nondeterministic. How can we trust them to configure production systems?
A: You won't use raw LLM output for critical config. Instead, LLMs act as a front-end that generates structured config which you can review. It's like having a smart assistant write the JSON for you, with the ability to validate it against a schema. Nondeterminism is mitigated by constraints and validation.
Q: What should developers do right now? Switch to TOML or YAML?
A: If you control a config format, switching to TOML or YAML solves the comment problem and reduces friction today. But the bigger opportunity is building LLM-powered config editors that let users speak natural language. The infrastructure for that is emerging fast—start experimenting now.
Q: Isn't JSON's rigidity actually a feature? It forces explicit structure.
A: Rigidity is only useful when clarity is critical. For config, that rigidity ends up as a burden. A well-designed config format should be writable by humans. JSON's strictness is a lie of objectivity—it makes machines happy and humans miserable.