I’m building a Valentine’s side project that turns relationship signals into something people can actually share: a little “relationship analysis” app that scores a couple across a handful of dimensions and visualizes the result. It’s lighthearted by design, but the product requirement is serious in one very specific way: the output is radar chart sharable in WhatsApp.
It’s familiar, compact, and instantly communicative. It also has the convenient property of looking vaguely scientific, which is exactly the tone you want for something that’s half playful and half “please don’t start an argument over your communication score.”
Like most developers in 2026, I didn’t start by opening a blank file. I started by asking an AI.
Codex 5.2 produced an SVG radar chart almost immediately. The geometry was right, the labels were placed sensibly, and the output was clean enough to drop into a UI without embarrassment. In that moment, AI felt like the mythical coworker who ships fast and doesn’t start threads about bikeshedding typography.
Then I tried to share the SVG on WhatsApp.
WhatsApp, it turns out, does not care about your clean vector graphics. It won’t preview SVGs the way it previews PNGs or JPEGs. The file can be sent, sure, but it lands like a document attachment, not a visual result.
The Requirement That Actually Mattered: Sharing on WhatsApp
So the radar chart stopped being a chart problem and became an output problem. The natural next move was obvious: convert the SVG into a PNG before sharing.
This is where “vibe coding” stops feeling like magic and starts feeling like a sitcom. My backend was running on AWS Lambda in Python, because Lambda is what you choose when you want to ship quickly and pretend dependencies are someone else’s issue. SVG-to-PNG conversion in Python has well-known solutions, and the AI went straight to them: CairoSVG, native renderers, headless browser approaches. Technically valid. Operationally, in the Lambda environment I was using, not so simple.
CairoSVG is not just a pip install and a smile. In serverless environments you quickly collide with system libraries, native dependencies, and packaging constraints. Lambda will happily run your Python, but it is far less excited to host a miniature graphics stack. The AI’s suggestions reflected that reality, but in the most AI way possible: each option was a solution that was correct in theory and exhausting in practice.
One path involved paid conversion APIs. Another leaned on Docker-based Lambda images, bringing along a heavier build pipeline just to produce an image. Others implied bundling binaries and wrestling with runtime quirks. I tried a second model, Gemini, hoping for a more pragmatic angle. It arrived at the same destination: workable ideas that looked like overengineering once you remembered the actual goal, which was “let someone see a chart inside WhatsApp without friction.”
Reading those suggestions was genuinely funny for a minute. Then it was annoying. Not because the models were “wrong,” but because they behaved like classic problem solvers with no product sense: they saw a conversion task and tunneled into making the conversion task work, regardless of how much complexity it dragged into the system. The recommendations weren’t malicious, just narrow. They treated my architecture as fixed, and the requirement as local. In reality, the architecture was negotiable, and the requirement was the whole point.
That’s when I realized I’d been framing the problem backwards. I was trying to force the chart to fit my deployment choice, instead of choosing a chart pipeline that fit the sharing experience. I kept asking, “How do I make SVG-to-PNG work in Lambda?” when the healthier question was, “Why am I doing image rendering in Lambda at all?”
At some point, every developer has to decide whether they’re solving a problem or constructing a monument to stubbornness. My version of that moment arrived in the form of a radar chart.
The Lesson: Stop Forcing One Solution
I stepped back and redesigned the system so image generation no longer depended on the constraints of AWS Lambda’s Python runtime. Rather than continuing to bolt on conversion machinery, I moved the rendering responsibility to an environment where generating PNGs is normal, supported, and boring. Boring, in this case, is the gold standard. Boring means predictable packaging. Boring means fewer moving parts. Boring means I can focus on the product again, instead of maintaining an image conversion side quest.
It’s tempting to treat this episode as a niche corner case, but it captures something broader about how developers are using AI right now. AI is extremely good at producing an answer to the question you asked. It’s less reliable at noticing the question you should have asked.
In my case, neither model automatically surfaced the real constraint: the output wasn’t meant for my application, it was meant for a messaging platform with its own rules. WhatsApp’s behavior is not a “coding” detail, but it’s the detail that decides whether the feature works. If you don’t state those constraints upfront, the model will rarely assume them for you. It will optimize for code correctness, not for user experience.
The second lesson is the one that hurts more, because it’s not about AI at all. It’s about developer psychology. When you commit to a single approach, especially one that feels close to the finish line, you start searching for breakthroughs instead of alternatives. You keep stacking exceptions and workarounds until the “simple fix” becomes a small monster: a paid service here, a container there, a build step nobody wants to touch, a dependency that breaks when you change regions or runtime versions. The feature ships, but it leaves behind a fragile subsystem that quietly taxes every future release.
AI can accelerate that pattern because it is endlessly willing to propose another workaround. It never gets tired. It never gets annoyed. It never says, “This is becoming a mess, maybe rethink the plan.” That part is still your job.
The irony is that the AI did what I initially wanted: it made the chart fast. The wall I hit had nothing to do with drawing polygons and everything to do with the messy reality of sharing formats, platform previews, and serverless packaging. The actual work wasn’t “convert this file.” The work was aligning the system with the user journey.
developers need to know there are alternatives
So that’s my vibe coding collision: AI suggestions are not always work and forced an architecture rethink. It’s a small story, but it’s a useful reminder. When an AI starts suggesting paid APIs and container orchestration just to meet a basic output requirement, it’s not a sign that you need a better conversion trick. It’s a sign that the boundary is wrong.
The code can be easy and still be the wrong solution. The part that matters is where the code lives, what it needs to touch, and where it needs to end up. WhatsApp doesn’t preview SVG, and no amount of cleverness changes that. The only winning move is to design as if that fact matters, because it does.
Leave a Reply