Прийшлось написати з нуля власний рендер, аудіо процесінг і усю пов"язану херню навколо. Дякую SDL2 за зручне апі. Дякую Кармаку за підглянуті алгоритми!
@whatafactukr Те саме робив але з garmin. Маю стату за кілька місяців %) Доволі прикольно спостерігати)) Спочатку мені openclaw відправляв самарі, а потім дійшли руки зробити UI.
@whatafactukr Те саме робив але з garmin. Маю стату за кілька місяців %) Доволі прикольно спостерігати)) Спочатку мені openclaw відправляв самарі, а потім дійшли руки зробити UI.
Прийшлось написати з нуля власний рендер, аудіо процесінг і усю пов"язану херню навколо. Дякую SDL2 за зручне апі. Дякую Кармаку за підглянуті алгоритми!
you dont need skills
recently i was reading about Thiele Machine, a fun twist on the Turing machine that adds something like a "soul" to computation. cool rabbit hole. but it got me thinking about something practical.
all these skills, rules, specs we feed to LLMs to make them code better.. they dont actually fix the root problem. the root problem is that an LLM generates code that *looks* statistically correct. and when you give it tests, it will happily bend the tests to match whatever it produced. plans, specifications, detailed prompts, all of these are just more text where the model can hallucinate or lose the plot. more surface area for things to go sideways.
so i started looking at formal verification. specifically TLA+ for writing specifications and Lean for proving them.
heres why this is different from just "better prompting". Lean has a proof kernel. its a tiny deterministic checker that either accepts your proof or rejects it. there is no "close enough". no statistical guessing. the LLM literally cannot bullshit its way through a Lean proof, the kernel will just say no. same story with TLA+, the TLC model checker will exhaustively verify your invariants against all reachable states. you cant sweet talk a model checker.
but heres the fun part. i tried generating tests from TLA+ specs *before* any business code exists. the LLM that writes tests never sees the implementation. then separately, the business code gets generated within the constraints of a Lean theorem. two completely isolated contexts. the test generator and the code generator know nothing about each other.
this is not TDD. in TDD you write tests based on your *understanding* of what the code should do. here the tests come from a mathematical model of the system. they encode invariants and properties, not example inputs and expected outputs. a TDD test says "when i call f(2) i get 4". a TLA+ derived test says "for all reachable states, this property holds and this transition is valid". the coverage is fundamentally different because it comes from the *shape* of the system, not from a developers imagination about edge cases.
so you get: formal proof that wont let the LLM drift from the goal + business tests written before code even started existing + complete isolation between test generation and code generation. the model cant game what it cant see.
and then today i see this: https://t.co/u8OkM1O04w
mistral just released Leanstral, an open source agent built specifically for Lean 4 formal verification. literally yesterday.
my take: all these skills and spec files we write today, thats a transitional period. within the next year SOTA models will be smart enough and formal verification will become a native part of code agents. when that happens its basically like C rising above assembly. you still need to understand whats underneath but you operate on a completely different level.
p.s. also think about erlang/otp. it waited so long for its moment and now its rising from the ashes. OTP was literally designed and prepared for this. it maps perfectly onto the modern ai agents world. i even built a few implementations myself, and then openai came with https://t.co/kzSl11xZq8 (elixir on BEAM) and other folks shipped https://t.co/oS5gXxWLJe and suddenly building my own felt pointless =(
I’ve been thinking for a few weeks about TLA+/Lean/Coq specifically for formal verification. I think agents should generate TLA+ at the spec generation stage first, and then only after review and approval generate application-level tests with the TLA spec in context.
This absolutely needs to be built into the core of coding agents themselves. That’s the only way formal verification will actually help.
HOLY FUK I JUST LEARNED ABOUT TLA+ AND IT'S SO GOOD FOR AGENTIC CODING
ur telling ME that i can mathematically fact check every possible scenario of my design STATE to prevent bugs and crashes
AND IF IT FINDS SOMETHING THE AGENTS GET INSTANT FEEDBACK AND LOOP FIXING IT TILL IT ALL POSSIBLE BUGS IN THE DESIGN ARE PATCHED
LOL THIS IS OP
@dmpanch Причому прошивка дрону однакова. А FCC хак давно існує і його продають за 30 євро. І судячи з знайденого в офіційному додатку точно колись була кнопка для дебагу. Але вони прибрали тіло методу.
Okay, this is getting interesting.
Ghidra MCP and Claude Code dug through the DJI Fly app and figured out how to switch the drone into “FCC mode.”
And the funniest part: at the end it just said, “It’s already 2 AM. Let’s continue tomorrow.”