> First thing I did was look at the raw bytes: xxd -l 4 "ClientApp.make"
I recommend using the linux "file" command, since it will generally be able to tell you these sorts of things straight away. I've been working on a long-term project to directly import figma design files into Unity, so I've ended up coming across a lot of these things myself
We need different language for describing things AI did for us vs things we figured out ourselves. When a human presents work under their own name, there is an unspoken but widely relied-upon assumption that the presenter has exercised judgment over the space of possible choices and can explain why these ones were taken.
In other words, we naturally assume they engaged with the problem space deeply enough to justify the decisions made.
I think AI-produced code and investigation needs a disclaimer, and I say that as someone who uses vibe coding a lot to produce tooling used in our development process.
If you didn’t do it or write it yourself, you don’t understand it as well as if you had. If you didn’t look at the output in great detail and understand every choice made, you really shouldn’t be putting your name on it — or staking your reputation on it — without a pretty clear disclaimer.
And if you present an investigation done by AI as something done by yourself, you’re not really providing human insights. (Almost) anyone can drive an AI, and there’s not a lot of value there for your audience if you don’t disclose that’s what you did.
If you attach your name to work, you are asserting that you can meaningfully answer “why this and not something else?” across the decisions that matter. Tools that produce answers faster than humans think require new language, because our old words still imply thought occurred.
Funny, actually not the case. Co-authored partly yes, mainly to compensate for my lack of knowledge of the intricacies of English (not my native language). Anyway: take from it what you want, if it helps you: nice! Else: have fun doing something else.
Interesting that you feel this is necessary. Why would a disclaimer be needed? If I read the technical docs for a library and use that in my code, should I explicitly mention that I got this from the docs? I know a lot, but am happy to admit I do not know everything, so I am happy to use tools that help me. And I got what I wanted in the end: being able to continue with my real work: helping a client.
This felt like an article of "This is how I worked this out". If you found something out through the docs, I'd be interested to know that. If you found it out through asking an LLM, that would be helpful to know as well. Maybe other people would write that kind of article differently, but when I write them, I try to put in as much detail as I can about how I worked something out, in case it's useful to other people
> When a human presents work under their own name, there is an unspoken but widely relied-upon assumption that the presenter has exercised judgment over the space of possible choices and can explain why these ones were taken.
> …
> If you attach your name to work, you are asserting that you can meaningfully answer “why this and not something else?” across the decisions that matter. Tools that produce answers faster than humans think require new language, because our old words still imply thought occurred.
Figma's API returns 400 for .make files, so I dug into the binary. Turns out it's a ZIP with a custom format: Deflate for the schema chunk, Zstandard for the data, then Kiwi binary decoding. Scripts on GitHub if useful: https://github.com/albertsikkema/figma-make-extractor
This is fascinating, thanks for sharing! I also appreciated the "when would you need this" section at the end.
> "When Would You Need This?
- Client hands you a Figma Make prototype but not the design file
- You want to audit AI-generated code before deployment
- You need to migrate away from Figma Make to a different stack
- You want to extract design tokens for your design system
- Pure curiosity about how Figma structures its data"
It's interesting that the AI tool just writes react rather than creating a figma drawing. All that training on writing code has made it easier for AI to just write the app than make an illustration of it.
I mean, it makes sense. In order to sketch out a screen, you need to run (most of) a layout engine in your head. If you're an AI, it's simpler to just... use a layout engine.
It's a pattern I see with more tools (lovable.dev does something similar). However looking at the code produced, lovable seems to be more precise about the code itself: just cleaner even over several iterations. Which is nice because it gives you a decent platform to continue on with your own code.
> First thing I did was look at the raw bytes: xxd -l 4 "ClientApp.make"
I recommend using the linux "file" command, since it will generally be able to tell you these sorts of things straight away. I've been working on a long-term project to directly import figma design files into Unity, so I've ended up coming across a lot of these things myself
Thanks, will keep that one in mind for next time!
Tell it to Mr. Claude. Who do you think made all these decisions?
Even if that was the case: is it a real problem? I am not a purist in any sense: whatever tool gets the job done, I am fine with it.
This is depressing.
We need different language for describing things AI did for us vs things we figured out ourselves. When a human presents work under their own name, there is an unspoken but widely relied-upon assumption that the presenter has exercised judgment over the space of possible choices and can explain why these ones were taken.
In other words, we naturally assume they engaged with the problem space deeply enough to justify the decisions made.
I think AI-produced code and investigation needs a disclaimer, and I say that as someone who uses vibe coding a lot to produce tooling used in our development process.
If you didn’t do it or write it yourself, you don’t understand it as well as if you had. If you didn’t look at the output in great detail and understand every choice made, you really shouldn’t be putting your name on it — or staking your reputation on it — without a pretty clear disclaimer.
And if you present an investigation done by AI as something done by yourself, you’re not really providing human insights. (Almost) anyone can drive an AI, and there’s not a lot of value there for your audience if you don’t disclose that’s what you did.
If you attach your name to work, you are asserting that you can meaningfully answer “why this and not something else?” across the decisions that matter. Tools that produce answers faster than humans think require new language, because our old words still imply thought occurred.
(To clarify, all the work I did was me-authored, not LLM authored)
the whole blog post and all the author's replies are authored by an LLM.
Funny, actually not the case. Co-authored partly yes, mainly to compensate for my lack of knowledge of the intricacies of English (not my native language). Anyway: take from it what you want, if it helps you: nice! Else: have fun doing something else.
Seems so. It should be much more explicitly disclaimed.
Interesting that you feel this is necessary. Why would a disclaimer be needed? If I read the technical docs for a library and use that in my code, should I explicitly mention that I got this from the docs? I know a lot, but am happy to admit I do not know everything, so I am happy to use tools that help me. And I got what I wanted in the end: being able to continue with my real work: helping a client.
This felt like an article of "This is how I worked this out". If you found something out through the docs, I'd be interested to know that. If you found it out through asking an LLM, that would be helpful to know as well. Maybe other people would write that kind of article differently, but when I write them, I try to put in as much detail as I can about how I worked something out, in case it's useful to other people
> When a human presents work under their own name, there is an unspoken but widely relied-upon assumption that the presenter has exercised judgment over the space of possible choices and can explain why these ones were taken.
> …
> If you attach your name to work, you are asserting that you can meaningfully answer “why this and not something else?” across the decisions that matter. Tools that produce answers faster than humans think require new language, because our old words still imply thought occurred.
Figma's API returns 400 for .make files, so I dug into the binary. Turns out it's a ZIP with a custom format: Deflate for the schema chunk, Zstandard for the data, then Kiwi binary decoding. Scripts on GitHub if useful: https://github.com/albertsikkema/figma-make-extractor
I'm curious if you tried binwalk? That's usually my goto for mysterious files.
I agree. It would likely have identified the separate deflate and zstd chunks automatically.
Never thought about using that, thanks for the tip!
that is a good one. Will try that next time.
This is fascinating, thanks for sharing! I also appreciated the "when would you need this" section at the end.
> "When Would You Need This? - Client hands you a Figma Make prototype but not the design file - You want to audit AI-generated code before deployment - You need to migrate away from Figma Make to a different stack - You want to extract design tokens for your design system - Pure curiosity about how Figma structures its data"
Thanks!
It's interesting that the AI tool just writes react rather than creating a figma drawing. All that training on writing code has made it easier for AI to just write the app than make an illustration of it.
I mean, it makes sense. In order to sketch out a screen, you need to run (most of) a layout engine in your head. If you're an AI, it's simpler to just... use a layout engine.
It's a pattern I see with more tools (lovable.dev does something similar). However looking at the code produced, lovable seems to be more precise about the code itself: just cleaner even over several iterations. Which is nice because it gives you a decent platform to continue on with your own code.
I once reverse engineered the Figma .fig file they have utilised quite good compression and data storage techniques for a tech company that uses AWS
That is a funny observation! You are right, that is strange.