Toolsnix Blog
← All articles
Developer Guides

How to Review JSON Generated by an AI Coding Assistant

A practical way to catch syntax errors, wrong value types, and shape mismatches in AI-generated JSON before it reaches your app.

By Zain AliPublished Last updated

Format the output, check its shape, and validate it against the contract that consumes it.

That last part is easy to skip. A JSON formatter can tell you whether the text parses and make nested data easier to read. It cannot tell you whether retryCount should be a number, whether a required key is missing, or whether your app expects an array instead of an object.

I build Toolsnix with Next.js in the Node.js ecosystem, and this is the review I use when an assistant hands me a configuration or payload: first make the structure readable, then compare it with the code that will use it. You can run the syntax step in the Toolsnix JSON Formatter.

What does a JSON formatter actually check?

JSON has a defined grammar. A JSON parser rejects things such as single-quoted strings, comments, and trailing commas. The Toolsnix formatter parses the input and prints valid JSON with indentation. If parsing fails, it reports that the input is invalid.

That gives you a useful first check, but only a first check. A formatter doesn't know your API contract or TypeScript type. It can happily format JSON that is valid but unusable for your app.

A small failure example: valid JSON, wrong type

Suppose an assistant suggests this settings object:

{
  "service": "orders",
  "retryCount": "3",
  "timeoutMs": 5000,
  "headers": []
}

This is valid JSON. But if the caller expects retryCount to be a number, the string value "3" can behave differently in comparisons, arithmetic, or validation. Formatting won't change it, because the formatter has no knowledge of the caller's contract.

Now consider the easy-to-miss syntax version:

{
  "service": "orders",
  "retryCount": 3,
}

The comma after 3 is valid in some JavaScript object literals, but it is not allowed in JSON. The formatter rejects this one. Remove the trailing comma, format again, and then check the types and fields separately. MDN documents this trailing-comma parsing error.

Which problems can formatting reveal, and which need another check?

  • Trailing comma or unquoted key: The text is invalid JSON and will not format. Fix the syntax, then try again.
  • Quoted number such as "3": Formatting shows that it is a string. Compare its type with the consumer's contract.
  • Missing field: A formatter usually cannot detect this because it does not know which fields are required. Check the interface, schema, or API documentation.
  • Repeated key: The JSON may still parse, but duplicate-name handling can be unpredictable. Remove the duplicate; RFC 8259 says object names should be unique.
  • Unexpected list order: A formatter preserves array order. Check whether that order matters to the consumer.

The distinction matters in a Next.js project too. Environment variable values arrive as strings in Node.js, so parsing a JSON string from an environment variable doesn't automatically convert its fields to the types your code expects. And values prefixed with NEXT_PUBLIC_ are exposed to browser code, so never put a secret there. See the Next.js environment variable guide.

How should I review AI-generated JSON before using it?

Use this short pass before copying a generated object into a config file, request, or fixture:

  1. Find the contract first. Look at the TypeScript type, API docs, schema, or code that reads the value. Don't use the AI response as its own specification.
  2. Format the raw response. Paste it into the JSON Formatter and choose Format. This tool currently reports a generic invalid-JSON message rather than a line and column, so check the most recent edits first; use your editor or runtime parser if you need a character position.
  3. Check the root and nested shapes. Is the root an object or array as expected? Are collections still arrays? Are nested objects under the right keys?
  4. Check types and edge values. Look closely at strings that should be numbers, null versus an omitted field, empty arrays, booleans, and numeric units such as milliseconds versus seconds.
  5. Scan for duplicate or unexpected keys. Don't rely on duplicate-key behavior; different parsers can handle it differently. Also remove example secrets or real personal data before sharing a payload.
  6. Run the consuming check. If the project has a JSON Schema, validate against it. Otherwise, run the smallest test or request that exercises the real reader, including one boundary case.

The formatter makes step two quick. It does not replace steps one or six. If you use a schema, the JSON Schema guide explains how schemas describe data types and constraints.

Why the formatted output can still fail at runtime

Readable data feels finished. It isn't necessarily finished. A parser checks whether the text can be interpreted as JSON; your application then applies its own assumptions. Those assumptions might include a required field, a numeric range, a known enum value, or a particular array shape.

I find it helpful to keep those checks separate: syntax first, shape second, behavior last. That way, a green-looking formatted block doesn't quietly become a claim that the feature works. For AI-generated code, the same principle applies to the code around the JSON: inspect the actual use site and run the relevant project checks before merging.

Sources