{"slug": "the-code-ai-won-t-write", "title": "The Code AI Won't Write", "summary": "A developer tested Claude, ChatGPT, and Gemini on a form validation coding challenge and found that all three AI models independently produced a recursive validation approach that fails to detect missing keys. The developer argues that the flaw stems from driving validation from data rather than a schema, and that the AI models all reached for the same incorrect fix when the issue was pointed out.", "body_md": "I use a form validation problem as a technical interview question. It's deceptively simple — and the solutions people reach for reveal a lot about how they think.\n\nThen I tried it on Claude, ChatGPT, and Gemini. The results were illuminating, but not for the reasons I expected.\n\nMany form libraries share a common convention: form data is represented as a plain nested object, and the validation function returns an object of the same shape containing the errors. You'll find this pattern in [Formik](https://formik.org/docs/guides/validation) and [React Final Form](https://final-form.org/docs/react-final-form/examples/record-level-validation) in React, and — full disclosure — in [Inglorious Web](https://inglorious.dev/web/featured/form.html#validation), my own framework, which ships form handling built in without any extra dependencies.\n\n``` js\nconst values = {\n  productName: 'VR Visor',\n  quantity: 1,\n  homeAddress: { street: 'Long St', zip: '00666' },\n  shippingAddress: { street: 'Short St', zip: '00777', co: 'Inglorious Coderz' },\n  billingAddress: { street: 'Wide Plaza', zip: '00888', vat: '1142042' },\n}\n```\n\nThe validation function should return an object containing all errors found. A starting example:\n\n``` js\nfunction validate(values) {\n  const errors = {}\n\n  if (!values.productName) {\n    errors.productName = 'required'\n  }\n\n  return errors\n}\n```\n\nThe ask: *extend this to validate every field*.\n\nNotice that the three address types aren't identical. `shippingAddress`\n\nrequires a `co`\n\nfield. `billingAddress`\n\nrequires a `vat`\n\n. These differences matter — and how you handle them reveals a lot.\n\nThe most common approach I see in interviews is a single `validateAddress`\n\nfunction with a `type`\n\nparameter:\n\n``` js\nfunction validateAddress(values = {}, type) {\n  const errors = {}\n\n  if (!values.street) errors.street = 'required'\n  if (!values.zip) errors.zip = 'required'\n\n  if (type === 'shipping' && !values.co) errors.co = 'required'\n  if (type === 'billing' && !values.vat) errors.vat = 'required'\n\n  return errors\n}\n```\n\nIt works. But every new address type, every new special rule, becomes another branch inside the same function. The differences between types are hidden rather than expressed.\n\nThe cleverest answer I ever received in an interview was this:\n\n``` js\nfunction validate(values) {\n  function validateNode(values = {}) {\n    const errors = {}\n\n    for (const [key, value] of Object.entries(values)) {\n      if (value && typeof value === 'object' && !Array.isArray(value)) {\n        const nestedErrors = validateNode(value)\n        if (Object.keys(nestedErrors).length) {\n          errors[key] = nestedErrors\n        }\n      } else if (!value) {\n        errors[key] = 'required'\n      }\n    }\n\n    return errors\n  }\n\n  return validateNode(values)\n}\n```\n\nNo schema, no flags — just a recursive walk of the data shape itself. Elegant, clever, a bit too complex for my taste maybe, but genuinely impressive.\n\nBut it has a silent flaw: it only validates fields that are *present* in `values`\n\n. If `billingAddress`\n\narrives without a `vat`\n\nkey entirely, the error is never registered. The function doesn't know what it doesn't see.\n\nTo be clear: the problem here isn't recursion itself. It's that the implementation has no source of truth about what fields are *expected*. A recursive validator can work perfectly — if it's driven by something that knows the shape of the domain.\n\nInterestingly, this was also the first instinct of all three AIs — Claude, ChatGPT, and Gemini independently reached for this same structure. When I pointed out the missing-key problem, they all reached for the same fix.\n\nOnce the missing-key flaw is on the table, the natural repair is to drive the iteration from a schema rather than from the data:\n\n``` js\nconst schema = {\n  productName: true,\n  quantity: true,\n  homeAddress: { street: true, zip: true },\n  shippingAddress: { street: true, zip: true, co: true },\n  billingAddress: { street: true, zip: true, vat: true },\n}\n\nfunction validate(values) {\n  function validateNode(schema, values = {}) {\n    const errors = {}\n\n    for (const [key, rule] of Object.entries(schema)) {\n      const value = values[key]\n\n      if (rule === true) {\n        if (!value) errors[key] = 'required'\n      } else {\n        const nestedErrors = validateNode(rule, value)\n        if (Object.keys(nestedErrors).length) {\n          errors[key] = nestedErrors\n        }\n      }\n    }\n\n    return errors\n  }\n\n  return validateNode(schema, values)\n}\n```\n\nThis is technically sound. It handles missing keys, it scales, it's data-driven. All three AIs converged on this pattern independently — and honestly, it's not wrong. If address types were configured at runtime via metadata rather than hardcoded in the codebase, this approach would be the right one. When variability lives in data, a data-driven solution wins.\n\nBut here, the schema is just a mirror of the data shape, with `true`\n\nwhere values should be. It's a solution to a problem — missing keys — that the composition approach never has in the first place.\n\n``` js\nfunction validate(values) {\n  const errors = {}\n\n  if (!values.productName) errors.productName = 'required'\n  if (!values.quantity) errors.quantity = 'required'\n\n  errors.homeAddress = validateAddress(values.homeAddress)\n  errors.shippingAddress = validateShippingAddress(values.shippingAddress)\n  errors.billingAddress = validateBillingAddress(values.billingAddress)\n\n  return errors\n}\n\nfunction validateAddress(values = {}) {\n  const errors = {}\n  if (!values.street) errors.street = 'required'\n  if (!values.zip) errors.zip = 'required'\n  return errors\n}\n\nfunction validateShippingAddress(values = {}) {\n  const errors = validateAddress(values)\n  if (!values.co) errors.co = 'required'\n  return errors\n}\n\nfunction validateBillingAddress(values = {}) {\n  const errors = validateAddress(values)\n  if (!values.vat) errors.vat = 'required'\n  return errors\n}\n```\n\nNo schema. No recursion. No flags. Each address type is its own function, and the shared logic is composed in.\n\nThe missing-key problem doesn't exist here — `validateBillingAddress`\n\nalways checks for `vat`\n\n, regardless of what arrives. But the reason isn't just simplicity: it's that `validateBillingAddress`\n\nexists because a billing address is a *distinct business concept*, not because it saves lines of code. The structure of the code reflects the structure of the domain.\n\nWhen a new address type appears, you introduce a new validator rather than extending a growing set of conditional rules. Modification doesn't disappear — it becomes localized.\n\nThe flag, the recursion, and the schema all share the same instinct: *find the common pattern and centralize the logic*. It's what we're taught. It's what most production code looks like. It's a sound instinct — and sometimes the right one.\n\nThe composition approach asks a different question first: *where does the variability actually live?* If address types are stable domain concepts that belong in code, then composition wins — each type gets its own function, and differences are expressed rather than parameterized. If address types are dynamic, configurable, and driven by external data, then the schema wins.\n\n**The problem with the flag, the recursion, and the schema is not that they're wrong — it's that they all assume the answer to that question without asking it.**\n\nWhat's striking is that the cleverest human in the room and three AI models all converged on the same solution independently. In hindsight, this isn't surprising. Programming education spends years teaching us to eliminate duplication and generalize patterns. Large language models are trained on the output of that culture, so they inherit many of the same instincts. This isn't a story about what AI can't do — it's a reflection on what software engineering culture taught both AI and us to reach for by default.\n\nAI can write the composition solution. It just rarely chooses to.\n\nThe simplest solution isn't the one that requires the least typing. It's the one that most honestly reflects what the domain is actually telling you.\n\nNext time you find yourself reaching for a flag or a schema, ask: *is this variability in my code, or in my data?*\n\nThe answer changes everything.", "url": "https://wpnews.pro/news/the-code-ai-won-t-write", "canonical_source": "https://dev.to/iceonfire/the-code-ai-wont-write-1ieb", "published_at": "2026-06-16 12:30:05+00:00", "updated_at": "2026-06-16 12:47:21.666962+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "developer-tools"], "entities": ["Claude", "ChatGPT", "Gemini", "Formik", "React Final Form", "Inglorious Web"], "alternates": {"html": "https://wpnews.pro/news/the-code-ai-won-t-write", "markdown": "https://wpnews.pro/news/the-code-ai-won-t-write.md", "text": "https://wpnews.pro/news/the-code-ai-won-t-write.txt", "jsonld": "https://wpnews.pro/news/the-code-ai-won-t-write.jsonld"}}