I train a lot, and with AI’s help I built a small app that pulls my Garmin and Strava data and helps me structure my training around it.
Made me curious what else people are building. What’s something you’ve put together recently with AI’s help, big or small?
Top comments (8)
Subscribe
Collapse Expand
hackers will forever exist else bugs are nothing.
-
Location
Nigeria
-
Education
Internet
-
Work
Freelancer
-
Joined
Oct 21, 2025
• Sep 11
An SVG editor. Basically reads svg and edits OTG. Not export but save back to SVG. Still exploring
Collapse Expand
That sounds nice, I would guess this was giving you a hard time doing it manually before?
Collapse Expand
hackers will forever exist else bugs are nothing.
-
Location
Nigeria
-
Education
Internet
-
Work
Freelancer
-
Joined
Oct 21, 2025
• Sep 12
More about exploration. SVG as a CAD app tool not an export.
ah, got it now. I’ve also created a lot of tool for exploration, most of them tuned out to be absolute surprise to me, wondering what my inital prompt was 😀 😀
Collapse Expand
I’ve been using Claude to build a Russian-syntax programming language
(SkyForge). The interesting part for me wasn’t writing the interpreter —
it was building a transpiler that converts my AST into Python AST so
compile() can turn it into native bytecode.
fib(32) went from ~60 seconds (tree-walking interpreter) to ~0.4
seconds (transpiled). That’s within 6% of plain CPython.
The AI was genuinely useful for two things: boilerplate (writing 30+
ast.* node types by hand is tedious) and catching weird edge cases
I’d miss — like Python 3.12+ refusing to compile an AST where a child
node’s lineno is less than the parent’s.
Hardest part: AI tends to invent keywords that don’t exist in my
language. Had to write a strict context file of “only these constructs
exist” and it still happens occasionally.
That’s a nice trick, going through Python’s own AST and compile() instead of writing your own bytecode compiler basically gets you CPython’s actual VM for free. 0.4s for fib(32) within 6% of native CPython is a great result for the code you didn’t have to write yourself.
The lineno ordering constraint is a fun one to hit blind, that’s a genuinely obscure CPython internal to stumble into from a hobby language.
On the invented-keywords problem: have you tried feeding the model a formal grammar file (even a stripped-down EBNF) instead of, or alongside, the prose “only these constructs exist” context? A grammar tends to anchor these things harder than a list of allowed words, since it also constrains structure, not just vocabulary.
Collapse Expand
Fair point — I haven’t tried EBNF yet, which is honestly an oversight
given that I wrote the parser by hand and could have derived the
grammar from it.
What I use instead: a short list of canonical examples, one per
construct. Instead of “these keywords exist”, the context file has
a small snippet for функция, если, для, попробовать, etc.
That anchors better than prose because the model copies structure,
not just vocabulary — you can’t fake a valid если block without
also writing иначе in the right place.
But you’re right that a grammar would be stronger. The thing I keep
hitting is structural drift, not word invention: the model gets the
keywords right but nests a block one level too deep or forgets a
closing brace. A grammar constrains that; examples don’t.
Did you have a specific approach for feeding EBNF to a model in
practice, or is it just “paste the grammar in the system prompt”?
For further actions, you may consider blocking this person and/or reporting abuse