I think it will click once you actually sit down with the AI agent, toggle Plan mode, and just tell it what you want to do in couple of sentences. It will immediately start building up the plan, presenting it to you what it thinks is the right approach , with the steps to take, with open questions that you can look at and answers. Then send them back to the AI. Repeat. That process along would give you a progress way further than you try to do it by yourself.
You can tell it to start implementing step 1. And you pick it up from there. Very natural how you would approach an expert for help, but you can always audit.
I can't provide a transcript because it's work I made for a customer and I'm bound to a clause of confidentiality.
What I did is what I use to do while starting to work on a major feature: make a list of changes, new and modified functionality, think which code and db tables I will touch and how, set constraints on the edits (eg: that API must not change, that one must be retro compatible) etc. I've been a bit pedantic because this time I had to tell it to someone else. I wrote it into a md file and asked Claude to check the code and find out if my plan was consistent with the code we were starting from. It made a list of things that I needed to detail more, added some questions and we iterated on it. Basically it's what I do myself but it happened faster.
I came across this repo while trying to find alternative to NimbleCSV, the go-to CSV parser for Elixir. NimbleCSV took 230s to parse a 250MB file with 35000 rows and 2000+ columns. RustyCSV took 1.7s.
It would be nice if there is an extension for VSCode or its forks that let you monitor your agent *running inside* your local machine, or VSCode adds support for it. I want to run agents on the codes I have open, not pushing them to a cloud "box" to run agents on there. But I do like being able to monitor or pick up the next steps from my phone.
Last time I tried to let AI build such extension, it told me that VSCode did not expose extension API to monitor AI chat.
I have just moved from a free environment in which I was able to use any AI harnesses or models to a strict enterprise environment.
I was shocked to realize how difficult it has been to have a GitHub CoPilot license on Azure. I mean, they're both Microsoft products. But no, the IT now has to figure out how to set up a GitHub enterprise, link to Azure subscription, and all that.
and set reasonable global and user token limits to avoid burning a year's IT spend cause Dave in Legal went ham on tokenmaxxing by uploading his entire legal case history.
in a company of 12 you can do that by saying 'we're all generalists, just don't be an idiot'. In a company of 10,000, you hired Dave cause he's good at legal merger mumbo jumbo not because he's an IT generalist.
I love Elixir but I had been a JS developer by trade. Bridging that interface keeps my brain focusing on building instead of splitting between JS and Elixir.
Still a lot to do, but I love the progress so far. This puts the joy of building something back to me.
I built Signet.js because I wanted a reactive layer for high-performance edge applications that felt more like a browser standard than a "framework."
## The Architectural Context:
I’ve spent years working on high-performance websites and legacy CMS modernizations. I found that existing reactive frameworks often introduce excessive memory overhead or rigid DSLs that don't play well with bespoke, performant, or legacy-injected code. I wanted to see if I could build a "toolbox" instead of a "black box" that stays small.
## Design Philosophy & Trade-offs:
- Why `Proxy`? I initially explored `Object.defineProperty` to minimize bundle size, but I eventually pivoted to `Proxy`. While it adds a tiny bit of runtime trap cost, the engine-level optimizations in modern browsers make the performance impact negligible for UI cycles. More importantly, it allowed for clean, dynamic object handling without the "magic" workarounds required by descriptor-based reactivity.
- Standards-First: I’m building Signet to be a thin orchestration layer. It currently leverages `@preact/signals-core` for its robustness, but the architecture is designed as a drop-in reactive layer. My roadmap is to align the internal primitive with the upcoming [TC39 Signals Proposal](https://github.com/tc39/proposal-signals), treating Signet as a bridge to native browser reactivity as it matures.
## Why did I build Signet instead of using [Alpine / petite-vue]?
The `petite-vue` Gap: Petite-vue was the gold standard for "sprinkling" interactivity, but with it no longer being maintained, there's a real need for a modern alternative that bridges the gap between pure HTML and heavy SPA frameworks.
Solving "DOM Pollution": A common friction point I found when moving to Alpine was the "messy DOM"—state-heavy applications often left behind excessive attributes and listeners that made the DOM feel cluttered. Signet is architected to be "DOM-transparent," ensuring that reactive bindings don't leave a trail of debris when components unmount.
Signal-First Architecture: By building Signet directly on a Signal primitive, I’m opting for a "Reactive-first" model. This is fundamentally cleaner than the directive-heavy, "magic-attribute" approach of previous libraries, leading to more predictable data flows and easier debugging.
## Memory Stability:
I ran a 10,000-component mount/unmount stress test using WeakRef to verify garbage collection. The results confirmed stable heap usage, proving that you can achieve leak-free reactivity with Proxy if you manage the dependency graph lifecycle correctly.
## A Note on Implementation:
I approached the development of Signet as a human architect utilizing AI agents for the implementation. My role was defining the constraints (e.g., bundle size limits, dependency lifecycle logic, memory stability) and enforcing the "clean DOM" architecture, while the AI handled the boilerplate and repetitive logic. This allowed me to iterate on the internal signal graph and performance testing at a speed that would have been impossible manually. This project is a deliberate experiment in "AI-assisted architecture"—where the human provides the technical constraints and domain expertise, and the AI acts as a high-speed implementation engine. I also let the AI implementor construct the full document site at https://sntran.github.io/signet.js/.
reply