We use Anthropic's Claude to help build and maintain this site — it's the AI assistant answering questions in the corner of this page right now, and it's also been in the room for the actual engineering work: bug fixes, new features, content, even internal tooling. That gives us a real answer to a question prospects ask a lot: does AI actually hold up on production work, or is it a demo trick?
Here are three specific things we learned, not the generic "AI changes everything" take.
1. AI is only as good as its willingness to verify, not guess
A mobile layout bug came in: a section on the homepage was crowding the edge of the screen on phones. The obvious move is to read the CSS and reason about what should be wrong. That's also how you miss the real bug.
The actual cause was a legacy stylesheet with five overlapping @media breakpoints that aren't mutually exclusive — a fix scoped to one breakpoint doesn't override a conflicting rule at a wider breakpoint that's still in effect at the same screen width. The only way to catch that reliably was live browser inspection at the actual viewport size — checking computed styles, not just reading the source and assuming. We treat that as a hard rule now: verify UI fixes in a real browser before calling them done, every time, no exceptions for "obvious" fixes.
2. The failure modes of the tool matter as much as its capabilities
Generating a branded social media graphic sounds simple — a photo, a logo, some text. Doing it programmatically (rather than by hand in a design tool) means moving image data through several systems: down a photo, encoding it, handing it to a script, exporting the result.
One early attempt corrupted an image silently — no error, just a slightly-wrong file that "worked" until you checked the byte count against the source. The fix wasn't a smarter AI, it was a different process: move binary data file-to-file through the shell instead of retyping it, and verify file sizes instead of trusting that "no error" means "correct." That's an engineering discipline problem, not a model-quality problem, and it's the kind of thing you only learn by actually shipping things, not by reading about AI coding in the abstract.
3. Genuinely obscure technical depth is where it gets interesting
Building a branded PowerPoint template meant understanding the difference between a .potx template and a regular .pptx file — which, it turns out, has nothing to do with the file extension. It's a single content-type declaration buried in the file's internal XML (presentationml.template.main+xml vs presentationml.presentation.main+xml). Get that wrong and PowerPoint silently treats your template as a regular presentation.
That's not a "write me a poem" task. It's the kind of specific, unglamorous technical detail that separates AI-assisted work that actually ships from AI-assisted work that looks good in a demo and falls apart on contact with a real file format.
The honest takeaway
None of this replaces engineering judgment — it accelerates it, if the process around it is disciplined: verify instead of assume, know your tools' actual failure modes, and don't shy away from the unglamorous technical details. That's the same standard we hold any senior engineer to, human or AI-assisted. See how we evaluate and apply Claude and other AI platforms across client engagements, or read what we're building it on.