What My JSX-Free React App Taught Me About AI-Assisted Engineering
I still dont really know what JSX is. But if I'm asking AI the right questions, does it matter? Is this really different from architecting systems based on principles and relying on an engineering staff to understand the nuances?
Nino Chavez
Product Architect at commerce.com
I still don’t really know what JSX is. But if I’m asking AI the right questions, does it matter? Is this really different from architecting systems based on principles and relying on an engineering staff to understand the nuances of the tech stack?
In my last post, I shared how my AI-assisted React app didn’t use JSX—and how I cleaned up over 1,000 TypeScript errors using typed wrappers around React.createElement.
That article was about the “what.” This one is about the “so what.”
Because somewhere between wrapping createElement() and rebuilding Shopify’s layout engine, I realized something much bigger:
This isn’t just AI-assisted coding. It’s a new form of software engineering.
And it only works if you’re willing to own the system—not just accept what the AI gives you.
AI Didn’t Make My Architecture. It Exposed It.
The AI gave me React.createElement() everywhere. It didn’t ask me if I wanted JSX. It didn’t “choose” the right architecture.
It just followed patterns—patterns that are common in codebases where layout is built from data.
At first, I thought: “This is probably wrong.”
But the more I looked, the more I saw that programmatic rendering made sense for my data-driven UI. CVA-based components fit the bracket use case. JSX actually would’ve limited flexibility.
What I realized was: The AI wasn’t wrong. But it wasn’t right either. It scaffolded something workable—not intentional.
It was up to me to decide whether it made sense. And then to fix what didn’t.
What I Actually Learned
This wasn’t just a frontend refactor. It was a mindset shift.
1. AI isn’t a coding assistant—it’s a pattern amplifier.
It doesn’t give you best practices. It gives you defaults, fragments, scaffolds. It’s your job to ask: “Is this the right shape for what I’m trying to build?”
2. Engineering doesn’t disappear—it becomes the differentiator.
I didn’t write most of the React syntax. But I audited the patterns, reframed the architecture, preserved type safety, and enforced structure. That’s engineering.
3. One developer and an AI is not a team—it’s a feedback loop.
There’s no design review. No product manager. No senior dev watching your commits. There’s just what the AI generates, what you accept or reject, and how tightly you control the feedback.
This only works if you’re asking the right questions.
4. This isn’t just faster coding. It’s solo systems design.
The moment I decided not to rip out the createElement scaffolding—and instead make it safe and intentional—was the moment I realized:
I wasn’t debugging AI code. I was architecting a system with AI as a builder.
That’s not a hack. That’s a new mode of development.
The Takeaway
If you’re using AI to help you code, and you’re wondering why it feels kind of wrong but still works—it might be because the AI surfaced an architectural pattern that makes sense, but only if you step in to refine it.
I didn’t set out to avoid JSX. I just followed the shape that emerged—and then took responsibility for making it stable.
That’s the real work.
I’m still figuring out where the boundaries are between what AI should scaffold and what requires sustained human attention. But the direction feels right: less fighting the output, more shaping it into something intentional.
Originally Published on LinkedIn
This article was first published on my LinkedIn profile. Click below to view the original post and join the conversation.
View on LinkedIn