The Code AI Won't Write

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. Then I tried it on Claude, ChatGPT, and Gemini. The results were illuminating, but not for the reasons I expected. The Problem Many 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 and React Final Form in React, and — full disclosure — in Inglorious Web , my own framework, which ships form handling built in without any extra dependencies. const values = { productName : ' VR Visor ' , quantity : 1 , homeAddress : { street : ' Long St ' , zip : ' 00666 ' }, shippingAddress : { street : ' Short St ' , zip : ' 00777 ' , co : ' Inglorious Coderz ' }, billingAddress : { street : ' Wide Plaza ' , zip : ' 00888 ' , vat : ' 1142042 ' }, } The validation function should return an object containing all errors found. A starting example: function validate ( values ) { const errors = {} if ( ! values . productName ) { errors . productName = ' required ' } return errors } The ask: extend this to validate every field . Notice that the three address types aren't identical. shippingAddress requires a co field. billingAddress requires a vat . These differences matter — and how you handle them reveals a lot. Four Solutions, Four Instincts 1. The Flag — the average human The most common approach I see in interviews is a single validateAddress function with a type parameter: function validateAddress ( values = {}, type ) { const errors = {} if ( ! values . street ) errors . street = ' required ' if ( ! values . zip ) errors . zip = ' required ' if ( type === ' shipping ' && ! values . co ) errors . co = ' required ' if ( type === ' billing ' && ! values . vat ) errors . vat = ' required ' return errors } It works. But every new address type, every new special rule,