Building a Geometry Calculator: What AI Got Right, Wrong, and Everything In Between

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.

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. The problem? My requirements were deceptively simple. Eight shapes. Dynamic inputs. SVG diagrams. i18n support. Dark mode. I figured this would take an afternoon, tops. Spoiler: it took three sessions with AI assistance, and the journey taught me more about AI-assisted development than any "hello world" tutorial ever could. Let me break down what I thought would be straightforward: Sounds manageable, right? The first prompt I gave to the AI was something like: "Build a geometry calculator with 8 shapes, dynamic inputs, SVG diagrams, i18n, and dark mode. Pure vanilla JS." The AI generated a working version in about 30 seconds. It looked great. It functioned. And then I started testing edge cases. The 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: js const SHAPES = { circle: { inputs: 'r' , svg: 'circleSVG' }, triangle: { inputs: 'b', 'h', 'a', 'c' , svg: 'triangleSVG' }, rectangle: { inputs: 'w', 'h' , svg: 'rectSVG' }, // ... more shapes }; This data-driven approach meant adding a new shape was just adding an entry — not rewriting logic. Smart architecture from the start. The formula implementation was also spot-on. For the circle: function circleFormulas r { return { area: Math.PI r r, circumference: 2 Math.PI r }; } Clean. Correct. No surprises. Here'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. js // AI's initial version function triangleFormulas a, b, c { const s = a + b + c / 2; const area = Math.sqrt s s - a s - b s - c ; return { area, perimeter: a + b + c }; } Try putting in sides 1, 1, and 10. You get NaN for the area, and no warning. A user would be completely confused. The fix required checking the triangle inequality before computing: function isValidTriangle a, b, c { return a + b c && a + c b && b + c a; } This 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. I mentioned dark mode in my requirements. The AI implemented it using CSS variables with a prefers-color-scheme media query. Perfect approach, right? @media prefers-color-scheme: dark { :root { --bg: 1a1a2e; --text: e2e8f0; / ... / } } But 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. "Classic 'works on my machine' situation," I muttered, adjusting the SVG colors to use CSS variables: <svg <circle cx="50" cy="50" r="40" stroke="var --text " fill="none" stroke-width="2"/ <text x="50" y="85" fill="var --text-secondary " r</text </svg The AI learned from this and started using CSS variables in subsequent SVG generations. It was like watching a junior developer grow in real-time. Another 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 . Technically correct, semantically wrong. I had to add validation that the AI kept getting subtly wrong: js function validateInput value, label { const num = parseFloat value ; if isNaN num || num <= 0 { throw new Error ${label} must be a positive number ; } return num; } The AI initially used Number value instead of parseFloat , which meant empty strings became 0 instead of NaN . That's a subtle bug that would've frustrated users. For the bilingual support, the AI suggested a translation object pattern that turned out to be elegant: js const i18n = { zh: { circle: '圆形', area: '面积', // ... }, en: { circle: 'Circle', area: 'Area', // ... } }; But 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. The fix was to make the formula generation function language-aware: js function getFormula shape, lang { const symbols = i18n lang .symbols; return ${symbols.area} = π${symbols.radius}² ; } This was the point where I realized: AI is great at scaffolding, but you need to think through the user experience yourself. You might wonder why I didn't just use an existing library or online calculator. Trust me, I considered it. But the requirements were specific: The AI suggested using Math.PI directly instead of hardcoding 3.14159 , which was correct. It also recommended rounding to 4 decimal places to avoid floating-point weirdness: js const round = num = Math.round num 10000 / 10000; This handles the classic 0.1 + 0.2 == 0.3 problem gracefully. The AI-assisted approach really shined in these areas: The most effective workflow I found was iterative: For example, when I found the triangle inequality issue, I said: "The triangle area calculation returns NaN for invalid triangles. Add validation and show a user-friendly error message." The AI not only fixed the calculation but also added the error message infrastructure. It was learning from my feedback. 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. 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. 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 instead of 2πr² + 2πrh . They're mathematically equivalent, but the AI's version was harder to read and explain to users. After 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. The 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 . During 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. If 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. The 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. Tags: javascript, webdev, ai, tools, productivity