I'm watching @poteto's talk from yesterday and this part caught my attention as she talks about useEffect being often misused and "you need a PhD to use useEffect".
You know what also has several parts that are often misused and that people say you need a PhD to use it? TLA+ (I'm thinking of the CHOOSE operator as one example).
We were very worried about preventing misuse when building Quint because we wanted any dev to be able to use it. There are way more static anatalysis checks in Quint than for TLA+.
Lamport built TLA+ for mathematicians and people as smart as him. It requires a lot of nuance to work well. Agents are not good at nuance! They are not really mathematicians, you know.
We've been experimenting with new checks inside Quint Studio to keep specs generated by agents to good standards. I feel like this is a promising direction 💜
On episode 61 of Generationship, @rachelchalmers speaks with Gabriela Moreira (@bugarela), co-founder and CEO of @quint_lang, about building trust in AI-generated code. Gabriela explains how executable specifications help engineers explore software behavior and why passing tests can offer false reassurance. They discuss making formal methods more accessible while preserving the judgment and curiosity that good engineering requires.
https://t.co/U1XIpb7zbr
In case you’ve been living under a rock or a dam, Quint Studio just entered open beta! Free, and open to everyone.
Capture how your software should behave, surface the bugs and gaps your tests miss, and stay in command as AI writes more of the code.
We did a short write up on why we built it: https://t.co/AuEb5OHrzf
@P33RL3SS Appreciate the follow! That's also an interesting approach. I like what @chadfowler is doing with the Phoenix Architecture, you might want to check it out
Thanks for reporting! I'm taking you mean this?
Although our scan supports big repos to some extent, we are seeing reports today of people having issues with big monorepos and directing them to try to run studio on sub-folders while we work on a nicer way of doing it. It could help in your case.
If you want us to dig dipper into what happen on your specific case, you could consider asking some agent to see what happened on that run. Your logs and transcripts are local, so your agents are our best way to diagnose it 😅
Quint Studio is now in open beta!
Here’s how it works in a minute. Studio breaks your codebase into components, agents write a Quint spec for each, real bugs get reproduced as tests, and your specs are kept in sync as the code changes.
It's in deed very hard to come up with a visualization that works for any kind of spec. It's much better to produce something specific for the spec you have, and agents are quite good at that.
So I would avoid trying to come up with one visualization method to rule them all, but documenting your visualization preferences in a skill and building it up as you iterate should help you get more consistent results with different specs.
I like understanding my specs from individual traces. So I find one interesting trace (either a property violation or something that observes some interesting scenario) and visualize that state (like with https://t.co/mELTM2B6z9 or the new visualizer inside Quint Studio - see step 3 in "how quint works" section at https://t.co/qNYdqAhtoM)