> Canonical: https://drkishanrees.com/learn/is-ai-code-actually-good/ # Is AI-generated code actually good? *AI-generated code can be good, but "the page appeared" is not proof. Good code does the right job, survives checks, works on a phone, and can be changed without quietly breaking something else. You do not have to read every line, but you do have to ask for evidence and inspect the result.* Quality & Ownership. 5 min read. First published 9 August 2026 Working once is a useful start. Good code keeps working under the conditions it was built for, does not damage what was already there, and leaves the next change safer rather than harder. ## Is the code actually good? Sometimes. It can also be untidy, overcomplicated, insecure, inaccessible or surprisingly fragile while producing a page that looks completely convincing. That is not a reason to avoid it. Human-written code can have all the same faults. It is a reason to judge code by evidence rather than by who, or what, wrote it. The first question is not "Did AI write this?" It is "What would have to be true for me to call this good?" For a small website, good code should pass five tests: 1. **It does the job you asked for.** The words, links, buttons and behaviour are correct. 2. **It works in the places people will use it.** That includes a narrow phone screen, a larger screen and the main browsers you expect visitors to use. 3. **It does not quietly break something else.** The new change should leave the rest of the site working. 4. **It can be checked.** The project should have repeatable tests or build checks, not only the model's assurance that everything is fine. 5. **It can be changed again.** The model should be able to explain the structure, keep the change contained and make the next edit without unravelling the last one. Good is not a property the model can declare. It is a conclusion you reach after those checks. ## Do I have to read the code to judge it? Not line by line. You can judge a great deal from the outside, just as you can tell whether a lift stops level with the floor without knowing how its motor was wired. Ask the model to show its work in plain language: - What did you change? - Which files did you touch? - What did you deliberately leave alone? - What checks did you run? - What could still be wrong? - How can I verify the result myself? Then do the part the model cannot do for you: look at the thing. Follow every link. Press every button. Resize the page. Use it with a keyboard. Read the words. Try the awkward case, not only the happy path. If a form says it worked, confirm that the message really arrived. You do not need to become the code reviewer. You do need to remain the accountable reviewer. ## Will it look good on a phone automatically? No. A model may produce a responsive layout, and many modern tools encourage one, but "responsive" is not a magic word and a small preview window is not a real phone. Mobile problems often hide in ordinary places: a heading that wraps into six lines, a menu that cannot be closed, a button too small to tap, text pushed sideways off the screen, a photograph cropped across the important part, or an animation that makes everything around it jump. So make mobile part of the brief and part of the proof: > Make this work from a narrow phone screen upwards. Do not create a separate mobile version. Check that no text or controls overflow, every menu can be opened and closed by touch and keyboard, buttons are comfortable to tap, images keep their subject, and the page remains readable when text is enlarged. Show me the widths you checked and any compromises you made. Then inspect it yourself on a real phone if you can. "The model says it is mobile responsive" is a claim. "I used it on my phone and saw it hold" is evidence. ## What if all the automated checks pass? That is encouraging, not conclusive. Automated checks are guard rails. They are good at catching the things they were built to catch, and completely silent about things nobody thought to test. A build can pass while the wrong sentence is on the page. A link checker can pass while the link points to the wrong source. An accessibility scan can miss whether the order of a page makes sense. A mobile screenshot can look fine while a menu does nothing when tapped. The strongest answer uses both kinds of proof: - **Machines check what can be repeated:** builds, tests, links, accessibility rules and regressions. - **A person checks what has to be judged:** meaning, usefulness, taste and whether the experience actually makes sense. Neither is enough alone. ## Where can I see this on the site? The lesson on [fixing a bug without reading the code](/learn/fix-a-bug-without-reading-code/) records two defects in the same visual component. Both were found by looking at the rendered page, not by reading the component. One took three failed fixes before a measurement named the real mechanism. That is the useful distinction: code that has been changed is not necessarily code that has been fixed. The design bench keeps alternatives and the reasons they were rejected. The [colophon](/colophon/) records how the site is built and checked. Together they show the two halves of quality: visible judgement and repeatable proof. ## So, is AI-generated code actually good? It can be. Do not trust it because it was written by AI, and do not dismiss it for the same reason. Give it a clear job, make the model explain what changed, run repeatable checks, inspect the result on the devices people will actually use, and keep every material change small enough to undo. The model writes quickly. Quality comes from the discipline around what it writes. ## Questions and answers ### Is AI-generated code worse than human-written code? Not by definition. Either can be excellent or poor. Judge the result by whether it is correct, testable, usable, maintainable and appropriate for the risk involved. ### Do I need to understand every line before publishing? Not for a small, low-risk website. You do need to understand what the change is meant to do, what it touched, how it was checked, and what remains uncertain. Higher-risk features need deeper technical review. ### How do I know it really works on mobile? Ask for explicit narrow-screen checks, then use the page yourself on a real phone. Check wrapping, overflow, menus, tap targets, images, forms and enlarged text. A responsive framework is not proof of a responsive experience. ## Related resources - Fix a bug without reading the code: two defects caught by looking: https://drkishanrees.com/learn/fix-a-bug-without-reading-code/ - How this site is built and checked, on the colophon: https://drkishanrees.com/colophon/ Cite as: Rees, Kishan. 'Is AI-generated code actually good?'. drkishanrees.com, first published 9 August 2026. https://drkishanrees.com/learn/is-ai-code-actually-good/