Replies: 1 comment
|
I think the whole point of AI is the ability to adapt to humans and not vice versa. If I have to change the way I write code so that AI understands it, then the AI just doesn't deliver on promise. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hey everyone,
I've been thinking a lot about how we interact with AI code assistants like Copilot, and I've landed on a conclusion that feels both obvious and profound, especially for us in the MobX world.
We're all seeing endless tutorials on "prompt engineering" to get the best results from AI. But I'm starting to believe that for in-project code generation, the text we type is only 10% of the story. The other 90%—the real prompt—is the quality and structure of the code the AI is reading.
And this is where using MobX feels like a superpower.
My argument is simple: A well-structured MobX store is the most effective, high-fidelity "prompt" you can give an AI.
Think about it:
The Ground Truth is Clear: A MobX store is a pure representation of your domain state (observables) and its synchronous mutations (actions). There's no UI clutter, no async side effects, no rendering logic. When you ask an AI to "add a feature to remove discounted items," it's working with a clean, unambiguous model of reality. The context is perfect.
The "API" is Explicit: The actions on your store serve as a clear, well-defined API for state manipulation. The AI doesn't have to guess how to change the state; the patterns are already there. It just needs to add a new "endpoint" (a new action) that follows the existing rules.
Relationships are Self-Documenting: computed values are a gift to AI. They explicitly declare the relationships between different pieces of state. This is a massive hint. The AI can easily understand that totalPrice depends on items and taxRate without having to reverse-engineer complex logic.
Let's contrast this with the alternative:
Imagine a massive React component with 20 useState hooks, tangled useEffect calls, and business logic mixed with API fetching. Asking an AI to modify this is a gamble. The "prompt" (the context) is a mess, so the output will be unpredictable.
But when I point Copilot to my CartStore.js and say, "// Add a method to clear the cart but keep the user's favorite items," the generated code is almost always perfect. It's because the "prompt" I gave it wasn't my comment; it was the clean, decoupled, and highly predictable structure of the store itself.
We've always advocated for clean, decoupled state management for human reasons: maintainability, testability, and readability. It turns out these same principles are exactly what's needed to turn our AI assistants from clumsy interns into expert collaborators.
So, what do you think?
Have you noticed your AI assistants performing better in your MobX stores compared to complex components?
Is "writing clean code for humans" the ultimate, unspoken form of "prompt engineering"?
Or am I overstating the case?
Curious to hear your thoughts and experiences
All reactions