Inspiration
The latest generation of AI agents, like Codex, has fundamentally changed what agents are capable of. They can already execute surprisingly complex workflows. The real challenge is no longer execution—it’s teaching.
Today, teaching an agent means writing prompts, documenting every step, describing edge cases, and iterating until it behaves correctly. It’s time-consuming, brittle, and, most importantly, unnatural.
Humans don’t teach this way.
When you onboard a new teammate, you don’t hand them a 10-page manual. You sit next to them, perform the task, explain what you’re doing, and answer why you’re making each decision.
That simple observation inspired Mimex.
Instead of teaching AI through specifications, we wanted to teach it through demonstrations.
What we learned
Building Mimex gave us a much deeper understanding of how modern AI agents actually work.
We explored how reusable agent skills are structured, how skill.md files encode workflows, and what makes a skill deterministic instead of relying on the model to improvise. We also learned how to combine multiple modalities—screen recordings, speech, and reasoning—to reconstruct not only what a user did, but why they did it.
One of our biggest takeaways is that today’s models are already incredibly capable. The missing piece isn’t more intelligence—it’s a better interface for transferring human knowledge.
How we built it
We built Mimex around a simple idea: record once, reuse forever.
A user records their screen while narrating what they’re doing, just like they would when training a new colleague.
We combine speech transcription, visual understanding, and reasoning models to reconstruct the workflow. The result is compiled into a reusable skill that an AI agent can execute repeatedly on new inputs.
The project was built using OpenAI’s latest models, including Codex and the GPT-5.6 family, leveraging each model for the tasks it performs best.
Ironically, writing the code wasn’t where we spent most of our time.
Most of the hackathon was dedicated to product thinking: designing the right architecture, deciding what information should become part of a skill, separating actions from intent, and making sure generated skills remain reusable instead of overfitting to a single demonstration.
Codex also became part of our own development workflow, helping us iterate faster while we focused on product design and architecture.
Challenges we ran into
The hardest part wasn’t the technology—it was defining the right product.
At the beginning, we had dozens of ideas. It was tempting to automate everything, add more features, or solve adjacent problems. We quickly realized that the challenge wasn’t building more—it was identifying the actual bottleneck.
Every design decision came back to one question:
How can someone teach an AI exactly as they would teach another human?
That mindset led us to several important decisions.
For example, we deliberately chose a web application instead of a native desktop app. While a desktop application could access more system-level capabilities, it would also require significantly more permissions and introduce friction for users. A browser-based experience made recording, sharing, and onboarding dramatically simpler while keeping the experience accessible.
Another challenge was finding the right level of abstraction. We didn’t want to generate scripts tied to one recording—we wanted to generate reusable skills that could generalize to future tasks while remaining deterministic.
That focus helped us avoid feature creep and build something centered on what we believe is the next bottleneck for AI.
Execution is getting cheaper every month.
Teaching is not.
Built With
- better-auth
- cloudflare
- codex
- docker
- ffmpeg
- github-actions
- gpt-5.6
- hetzner
- hono
- motion
- node.js
- openai
- postgresql
- prisma
- react
- resend
- shadcn-ui
- stripe
- tailwindcss
- traefik
- typescript
- vite
- whisper
Log in or sign up for Devpost to join the conversation.