{"slug": "building-a-geometry-calculator-what-ai-got-right-wrong-and-everything-in-between", "title": "Building a Geometry Calculator: What AI Got Right, Wrong, and Everything In Between", "summary": "A developer building a geometry calculator with AI assistance found the AI generated clean, working code for happy paths but struggled with edge cases, including triangle inequality validation, dark mode SVG visibility, and input validation. The experience highlighted that AI-assisted development requires human oversight for edge cases and semantic correctness.", "body_md": "While working on a collection of browser-based developer tools, I hit an unexpected wall. I needed a geometry calculator — not for myself, mind you, but as one of those \"everyone expects it to exist\" tools that round out a utility suite. You know the drill: area, perimeter, volume, the usual suspects.\n\nThe problem? My requirements were deceptively simple. Eight shapes. Dynamic inputs. SVG diagrams. i18n support. Dark mode. I figured this would take an afternoon, tops.\n\nSpoiler: it took three sessions with AI assistance, and the journey taught me more about AI-assisted development than any \"hello world\" tutorial ever could.\n\nLet me break down what I thought would be straightforward:\n\nSounds manageable, right? The first prompt I gave to the AI was something like:\n\n\"Build a geometry calculator with 8 shapes, dynamic inputs, SVG diagrams, i18n, and dark mode. Pure vanilla JS.\"\n\nThe AI generated a working version in about 30 seconds. It looked great. It functioned. And then I started testing edge cases.\n\nThe initial structure was solid. The AI handled the shape selection logic cleanly, and the SVG diagrams were surprisingly good. Here's a snippet of the shape data structure it created:\n\n``` js\nconst SHAPES = {\n  circle: { inputs: ['r'], svg: 'circleSVG' },\n  triangle: { inputs: ['b', 'h', 'a', 'c'], svg: 'triangleSVG' },\n  rectangle: { inputs: ['w', 'h'], svg: 'rectSVG' },\n  // ... more shapes\n};\n```\n\nThis data-driven approach meant adding a new shape was just adding an entry — not rewriting logic. Smart architecture from the start.\n\nThe formula implementation was also spot-on. For the circle:\n\n```\nfunction circleFormulas(r) {\n  return {\n    area: Math.PI * r * r,\n    circumference: 2 * Math.PI * r\n  };\n}\n```\n\nClean. Correct. No surprises.\n\nHere's where things got interesting. The first real bug appeared when I tested the triangle with three sides (SSS case). The AI had implemented Heron's formula correctly for the area, but the perimeter calculation was... well, it was just the sum of sides. Which is correct, but the AI forgot to handle the case where the triangle inequality is violated.\n\n``` js\n// AI's initial version\nfunction triangleFormulas(a, b, c) {\n  const s = (a + b + c) / 2;\n  const area = Math.sqrt(s * (s - a) * (s - b) * (s - c));\n  return { area, perimeter: a + b + c };\n}\n```\n\nTry putting in sides 1, 1, and 10. You get `NaN`\n\nfor the area, and no warning. A user would be completely confused.\n\nThe fix required checking the triangle inequality before computing:\n\n```\nfunction isValidTriangle(a, b, c) {\n  return a + b > c && a + c > b && b + c > a;\n}\n```\n\nThis was my first \"aha\" moment with AI-assisted development: the AI writes beautiful code for happy paths, but edge cases are where you earn your keep as a developer.\n\nI mentioned dark mode in my requirements. The AI implemented it using CSS variables with a `prefers-color-scheme`\n\nmedia query. Perfect approach, right?\n\n```\n@media (prefers-color-scheme: dark) {\n  :root {\n    --bg: #1a1a2e;\n    --text: #e2e8f0;\n    /* ... */\n  }\n}\n```\n\nBut here's what the AI missed: the SVG diagrams. They were hardcoded with dark colors for strokes and labels. In dark mode, they became invisible against the dark background.\n\n\"Classic 'works on my machine' situation,\" I muttered, adjusting the SVG colors to use CSS variables:\n\n```\n<svg>\n  <circle cx=\"50\" cy=\"50\" r=\"40\" \n          stroke=\"var(--text)\" fill=\"none\" stroke-width=\"2\"/>\n  <text x=\"50\" y=\"85\" fill=\"var(--text-secondary)\">r</text>\n</svg>\n```\n\nThe AI learned from this and started using CSS variables in subsequent SVG generations. It was like watching a junior developer grow in real-time.\n\nAnother subtle issue: the AI allowed negative numbers and zero in the input fields. A circle with radius -5 shouldn't be a thing, but the AI was happy to compute `Math.PI * (-5) * (-5) = 78.54`\n\n. Technically correct, semantically wrong.\n\nI had to add validation that the AI kept getting subtly wrong:\n\n``` js\nfunction validateInput(value, label) {\n  const num = parseFloat(value);\n  if (isNaN(num) || num <= 0) {\n    throw new Error(`${label} must be a positive number`);\n  }\n  return num;\n}\n```\n\nThe AI initially used `Number(value)`\n\ninstead of `parseFloat`\n\n, which meant empty strings became `0`\n\ninstead of `NaN`\n\n. That's a subtle bug that would've frustrated users.\n\nFor the bilingual support, the AI suggested a translation object pattern that turned out to be elegant:\n\n``` js\nconst i18n = {\n  zh: {\n    circle: '圆形',\n    area: '面积',\n    // ...\n  },\n  en: {\n    circle: 'Circle',\n    area: 'Area',\n    // ...\n  }\n};\n```\n\nBut the first version had a critical flaw: it only translated the UI labels, not the formula display or the SVG text labels. When you switched languages, you'd get a Chinese UI with English formulas. Not ideal.\n\nThe fix was to make the formula generation function language-aware:\n\n``` js\nfunction getFormula(shape, lang) {\n  const symbols = i18n[lang].symbols;\n  return `${symbols.area} = π${symbols.radius}²`;\n}\n```\n\nThis was the point where I realized: AI is great at scaffolding, but you need to think through the user experience yourself.\n\nYou might wonder why I didn't just use an existing library or online calculator. Trust me, I considered it. But the requirements were specific:\n\nThe AI suggested using `Math.PI`\n\ndirectly instead of hardcoding `3.14159`\n\n, which was correct. It also recommended rounding to 4 decimal places to avoid floating-point weirdness:\n\n``` js\nconst round = (num) => Math.round(num * 10000) / 10000;\n```\n\nThis handles the classic `0.1 + 0.2 !== 0.3`\n\nproblem gracefully.\n\nThe AI-assisted approach really shined in these areas:\n\nThe most effective workflow I found was iterative:\n\nFor example, when I found the triangle inequality issue, I said:\n\n\"The triangle area calculation returns NaN for invalid triangles. Add validation and show a user-friendly error message.\"\n\nThe AI not only fixed the calculation but also added the error message infrastructure. It was learning from my feedback.\n\n**AI is a fantastic junior developer.** It's fast, consistent, and never gets tired. But it needs supervision. It'll happily implement a feature with subtle bugs that only show up in edge cases.\n\n**The prompt matters more than the model.** Being specific about requirements — \"show the formula alongside the result,\" \"use CSS variables for theming\" — made a huge difference in output quality.\n\n**You still need to understand the math.** The AI can write formulas, but you need to verify them. I caught a bug where the cylinder surface area formula was `2πr(r+h)`\n\ninstead of `2πr² + 2πrh`\n\n. They're mathematically equivalent, but the AI's version was harder to read and explain to users.\n\nAfter three sessions of back-and-forth, I had a working tool. It's not perfect — nothing is — but it handles all the edge cases I could think of, supports both languages properly, and looks decent in both light and dark modes.\n\nThe whole process made me appreciate the collaborative nature of AI-assisted development. It's not about replacing the developer; it's about amplifying their capabilities. The AI handled the tedious parts (SVG diagrams, repetitive code structure) while I focused on the parts that require human judgment (UX decisions, edge case handling, accessibility).\n\nDuring this process, I built a small browser-based tool to make this workflow easier. You can check it out if you're curious about geometry calculators or want to see the final result in action.\n\nIf you're thinking about using AI for your next project, here's my advice: treat it like a pair programmer who's read every Stack Overflow answer but has never shipped a product. It's brilliant at patterns and syntax, but it needs your experience to know what \"done\" actually looks like.\n\nThe geometry calculator taught me that AI-assisted development isn't about writing less code — it's about thinking more clearly about what you want that code to do. And sometimes, the most valuable output isn't the code itself, but the questions it forces you to ask about your own requirements.\n\n*Tags: javascript, webdev, ai, tools, productivity*", "url": "https://wpnews.pro/news/building-a-geometry-calculator-what-ai-got-right-wrong-and-everything-in-between", "canonical_source": "https://dev.to/ggwork/building-a-geometry-calculator-what-ai-got-right-wrong-and-everything-in-between-ne9", "published_at": "2026-08-12 05:38:14+00:00", "updated_at": "2026-08-12 05:46:50.129550+00:00", "lang": "en", "topics": ["developer-tools", "generative-ai"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/building-a-geometry-calculator-what-ai-got-right-wrong-and-everything-in-between", "markdown": "https://wpnews.pro/news/building-a-geometry-calculator-what-ai-got-right-wrong-and-everything-in-between.md", "text": "https://wpnews.pro/news/building-a-geometry-calculator-what-ai-got-right-wrong-and-everything-in-between.txt", "jsonld": "https://wpnews.pro/news/building-a-geometry-calculator-what-ai-got-right-wrong-and-everything-in-between.jsonld"}}