DEV Community: Ronak Parmar

I turned my phone into a remote deck for my Windows laptop — no cloud, no accounts, one npm start

Ronak Parmar — Wed, 22 Jul 2026 15:52:01 +0000

It started with the dumbest problem in computing: I'm in bed, a movie is
playing on my laptop across the room, and pausing it requires physically
getting up.

Every existing fix annoyed me in some way. Remote desktop apps are overkill
and route through someone's cloud. Remote-control apps want accounts,
subscriptions, or a native app install. I just wanted my phone to poke my
laptop over my own Wi-Fi.

So I built LapDeck: one Node.js
process on the laptop, a PWA on the phone. Scan a QR code once and your
phone becomes an app launcher, touchpad, keyboard, live screen viewer, and
media/power remote. MIT licensed, plain JavaScript, no build step.

This post is about the four problems that turned out to be more interesting
than I expected.

The architecture in one line

Phone (PWA) ── WebSocket + MJPEG over Wi-Fi ──► Node.js agent (Windows)

The agent serves the PWA, exposes a WebSocket for commands, and streams the
screen as MJPEG. The protocol is deliberately dumb JSON envelopes — no
protobuf, no RPC framework — so a native Android client or a CLI script can
speak it in an afternoon. Windows-specific glue (volume, brightness, power,
capture) is isolated in src/win/, so a macOS/Linux port only has to
reimplement that layer.

Problem 1: mobile keyboards lie to you

The obvious way to build a remote keyboard is to listen for keydown and
forward key codes. On mobile, this collapses immediately: swipe typing,
autocorrect, and IME composition don't emit per-key events. Android will
happily tell you every key is keyCode 229.

The fix: stop listening to keys entirely. I keep a hidden input, and on
every input event I diff the field's value against the last known
state — compute the common prefix, then emit "delete N chars, type this
string" to the laptop. Swipe-type a whole word and the laptop receives one
clean text insertion. IME composition, autocorrect rewrites, emoji — all
just become diffs.

The lesson generalizes: on mobile web, treat the text field as the source of
truth, never the key events.

Problem 2: streaming a screen without WebRTC

I wanted live screen view with tap-to-click. WebRTC would be the "correct"
answer, but it drags in a signaling dance and a pile of dependencies for
what is fundamentally "pictures, quickly."

MJPEG turned out to be embarrassingly good for this. The agent runs a
capture loop (screenshots via nut.js, resize + JPEG encode via sharp) and
pushes frames as multipart/x-mixed-replace — a <img> tag on the phone
renders it natively, zero client code. Quality presets just change fps,
width, and JPEG quality.

Latency is fine for "tap where you want to click," but a raw MJPEG stream
makes the cursor feel laggy. So the phone renders its own client-predicted
cursor overlay on top of the stream — your finger drives a local cursor
instantly, and the real cursor catches up underneath. The perceived latency
of the whole feature is the latency of that overlay, not the stream.

Problem 3: the security model for "my phone can shut down my laptop"

Giving a web page on the network the power to inject input and kill your
machine deserves paranoia. The rules I settled on:

A 256-bit random token, generated on first run, embedded in the QR link. You scan once; the phone stores it. Every WebSocket command and the MJPEG stream require it. Comparison is constant-time.
First WebSocket message must authenticate within 3 seconds or the socket drops.
Feature switches are enforced server-side. If you disable screen view in settings, the agent refuses those commands — it doesn't just hide the button.
Destructive actions are opt-in and abortable. Sleep/shutdown/restart each need to be enabled in settings, require an explicit confirm flag, and shutdown/restart honor a grace period during which one tap aborts. (I have fat-fingered shutdown. The abort window has paid for itself.)

Transport is plain HTTP/WS, which is fine for a home LAN you trust — and
explicitly not fine for the open internet. Which leads to:

Problem 4: remote access without running a server

"Control your laptop from anywhere" usually means either port forwarding
(no) or somebody's relay cloud (also no). The answer that costs nothing and
required surprisingly little code: detect Tailscale.

If the agent sees a Tailscale interface, it prints a second "remote" QR and
the UI offers a one-tap switch to the tailnet URL. WireGuard gives you
end-to-end encryption, MagicDNS + tailscale cert gives you a real HTTPS
URL (which also makes the PWA installable from anywhere), and I run zero
infrastructure. Any VPN that puts your phone on your home network works —
Tailscale is just the zero-config path.

Things I deliberately didn't do

No TypeScript, no build step. Plain ESM on Node ≥ 20. Clone, install, run. Contributors can read every line that executes.
No Electron, no tray app. It's a console process; a PowerShell script installs a hidden autostart launcher into the Startup folder if you want it permanent (no admin needed).
No cloud component, period. There is nothing to sign up for, nothing that phones home, and the whole thing works with Wi-Fi and no internet.

Try it

Windows 10/11, Node ≥ 20, phone on the same Wi-Fi:

git clone https://github.com/ronak-create/LapDeck.git
cd LapDeck
npm install
npm start

Scan the QR, add to home screen, done.

Repo: https://github.com/ronak-create/LapDeck — the WebSocket protocol
is documented in docs/PROTOCOL.md if you want to build your own client.
macOS/Linux ports, multi-monitor support, and code roasts all welcome.

What's the laziest problem you've ever over-engineered a solution for?

pretty interesting stuff!!

Ronak Parmar — Wed, 22 Jul 2026 14:07:37 +0000

shekhar

Jul 22

I built a CLI so I'd stop typing ImageMagick flags wrong.

#cli #javascript #opensource #ai

2 min read

The project file is the interface: letting AI agents drive a video editor

Ronak Parmar — Thu, 09 Jul 2026 15:54:17 +0000

Last week I open sourced FableCut,
a Premiere-style video editor that runs in the browser and that AI agents can
operate. It hit the front page of Hacker News
(thread), and the questions
there made me realize the interesting part isn't the editor. It's one design
decision: the project file is the interface.

The usual way, and why I flipped it

Most AI video tools hide the edit behind an API. You call addClip(),
applyFilter(), and the tool owns the state. If you want a human to touch the
result, you build a whole collaboration layer.

FableCut does the opposite. The entire timeline lives in one JSON document,
project.json: media, clips, tracks, keyframes, transitions, markers. The
editor UI reads it. The export renders it. And anything that can write JSON
can edit video: Claude Code through MCP, a Python script, jq, or you with a
text editor.

{
  "id": "c_title", "kind": "text", "track": "V3",
  "start": 0, "duration": 2.2,
  "props": { "text": "HANDMADE", "font": "Bebas Neue",
             "glow": 45, "textAnim": "letter-pop" }
}

That clip is a glowing kinetic caption. There is no API call that creates it.
Writing it into the file IS creating it.

SSE as a doorbell, not a data channel

The first question on HN was "what's the benefit of SSE here?" Fair question,
because the SSE channel does almost nothing, and that's the point.

The server watches the project file with fs.watch, debounces 150ms, and
pushes the literal string change to the browser. No payload. The browser
re-fetches the project and re-renders. The whole mechanism is about 15 lines
on a bare node:http server.

Why not WebSockets? Because the data only flows one way. Everything that
writes (the UI, an agent, a shell script) goes through REST or the
filesystem. The browser only ever needs to hear "something changed, go look."
An event with no payload can't arrive out of order, and a missed event costs
nothing because the next fetch has the latest state anyway.

The revision counter, or: how a human and an agent share a timeline

The file carries an integer revision. Every write must bump it. If a write
arrives with a revision that isn't newer than what's on disk, the server
rejects it with a 409.

This one integer is the entire concurrency model. If I drag a clip in the UI
while an agent is mid-edit, the agent's stale write bounces, it re-reads,
re-applies its change on top of mine, and writes again. No operational
transforms, no CRDTs, no lock files. It works because edits are coarse
(a whole document) and rare (human speed), so last-writer-wins with a
staleness check is enough.

The trick I'm proudest of: frame-accurate CSS animations

FableCut has animated SVG overlays (lower thirds, confetti, sparkles) that
are plain .svg files animated with CSS @keyframes. The problem: a video
compositor needs to render the animation state at an exact time, and export
isn't realtime. You can't just let the animation play.

The solution: pause every animation and drive time by hand. The compositor
sets animation-delay: calc(var(--d, 0s) - t) where t is the clip's local
time. A negative delay means "you started in the past," so a paused animation
with delay -1.3s displays exactly its 1.3 second frame. Deterministic,
scrubbable, identical in preview and export. The only rule for SVG authors is
to never hardcode animation-delay and use the --d custom property for
staggering instead.

"You can just give Claude access to ffmpeg"

Someone said this on HN and it deserves a straight answer. For trims,
concats, and batch transcodes: yes, absolutely, do that.

The difference is the creative loop. ffmpeg is write-only. The agent builds a
filter graph, renders for minutes, and cannot see what it made. You give
feedback, everything re-renders. In FableCut an edit is a JSON diff, the open
browser updates in 150ms, and the timeline stays editable instead of being
baked into a filter string. It's not a replacement for ffmpeg anyway: the
export pipeline renders frames in the browser and pipes them to ffmpeg for
encoding. FableCut is the state and preview layer between the agent and
ffmpeg.

Honest limitations

The compositor is the browser, so export needs a browser open (headless
export is not there yet). It's Chromium-first. And an AI can misjudge a cut
just fine, which is why the human-in-the-loop part matters more than the AI
part: the agent does the labor, you do the taste.

Full disclosure since HN asked: Claude helped write the README, and large
parts of the editor were built in collaboration with it. That felt fitting
for a tool whose primary user is an AI agent, but the architecture decisions
above are the ones I'd defend in person.

Repo: https://github.com/ronak-create/FableCut. It's MIT, zero dependencies,
one node server.js. If you build something weird with it, I want to see it.

Why I Reimplemented 22 Unix Tools in Go for AI Agents

Ronak Parmar — Mon, 06 Apr 2026 14:12:20 +0000

I spent three weeks rebuilding ls, grep, cat, find, stat, diff, and 16 other Unix coreutils in Go. Not because the originals are broken — they're masterpieces of systems programming that have survived decades of use. I rebuilt them because AI coding agents are terrible at reading their output.

The Problem Nobody Talked About

Every time an AI agent runs ls src/, it receives something like this:

-rw-r--r--  1 user  staff  2048 Apr  6 12:00 main.go
drwxr-xr-x  3 user  staff    96 Apr  6 11:00 internal
lrwxr-xr-x  1 user  staff    12 Apr  6 10:00 link -> main.go

The agent has to figure out which column is the filename. Which is the size. Whether that d at the start means directory. Whether Apr 6 means this year or last year. It guesses. Sometimes it guesses wrong. And every wrong guess costs tokens, introduces errors, and degrades the quality of the code it writes.

Now multiply that by every grep, every cat, every find the agent runs in a single session. The token waste is staggering. The parsing fragility is a constant source of subtle bugs.

The Insight

AI agents don't need pretty terminal output. They need structured data. They need to know that main.go is 2048 bytes, was modified 3600 seconds ago, is written in Go, has MIME type text/x-go, and is not a binary file. They need this information labeled, unambiguous, and machine-readable.

So I asked: what if ls returned XML?

<ls timestamp="1712404800" total_entries="3">
  <file name="main.go" path="src/main.go" absolute="/project/src/main.go"
        size_bytes="2048" size_human="2.0 KiB"
        modified="1712404800" modified_ago_s="3600"
        language="go" mime="text/x-go" binary="false"/>
  <directory name="internal" path="src/internal"/>
  <symlink name="link" target="main.go" broken="false"/>
</ls>

Zero ambiguity. Zero parsing. The agent reads the attributes and knows exactly what it's looking at. No regex to extract filenames from column-aligned text. No heuristic to determine if something is a directory. No guesswork.

Why XML and Not JSON?

Good question. JSON is the lingua franca of APIs. But XML has a structural advantage that matters for AI context windows: attributes.

Compare these two representations of the same file:

<file size_bytes="2048" language="go" mime="text/x-go"/>

{"size_bytes": 2048, "language": "go", "mime": "text/x-go"}

The XML version is 40 characters. The JSON version is 60. That's a 33% difference. When you're listing 1,000 files, that's tens of thousands of tokens saved. AI context windows are expensive and limited. Every character counts.

That said, aict supports --json for every tool. The schema is identical. Use whatever your pipeline prefers.

Why Go?

Three reasons:

Single binary. Go compiles to a static binary with zero runtime dependencies. aict is one file you drop on a system and it works. No pip install, no npm install, no shared libraries to manage. For a tool that's supposed to replace coreutils, this is non-negotiable.

Standard library only. Every feature — regex matching, MIME detection, filesystem walking, XML encoding — uses Go's standard library. Zero external dependencies means zero supply chain risk, zero version conflicts, and the ability to audit the entire codebase in an afternoon.

Performance is good enough. Yes, aict grep is slower than ripgrep. Yes, aict ls is slower than eza. But we're talking 15ms vs 2ms for listing 1,000 files. The overhead comes from language detection, MIME sniffing, and structured output — features that are the entire point of the project. For normal codebases, the difference is imperceptible.

What I Built

Twenty-two tools across five categories:

File inspection: cat, head, tail, file, stat, wc
Directory & search: ls, find, grep, diff
Path utilities: realpath, basename, dirname, pwd
Text processing: sort, uniq, cut, tr
System & environment: env, system, ps, df, du, checksums

Plus a git subcommand suite (status, diff, log, ls-files, blame) and an MCP server that exposes every tool as a callable function to AI assistants like Claude and Cursor.

Every tool supports three output modes: XML, JSON, and plain text. Every error is structured data in stdout, never stderr. Every path is absolute. Every timestamp is a Unix epoch integer.

The MCP Server

This is where it gets interesting. aict ships with an MCP (Model Context Protocol) server binary called aict-mcp. You configure it in Claude Desktop or Cursor, and suddenly every tool becomes a typed, callable function.

The AI agent doesn't shell out to run aict ls src/. It calls the ls function with {path: "src/"} and receives structured JSON. No shell spawning. No output parsing. No ambiguity.

This is the future of how AI agents interact with filesystems. Not by typing commands into a terminal and reading the output like a human would. By calling typed functions and receiving typed responses.

What I Didn't Build

I intentionally excluded write operations: cp, mv, rm, mkdir, chmod, chown. These are dangerous when called by AI agents without human confirmation. aict is a read-only tool. It observes, it doesn't modify.

I also didn't try to match GNU coreutils flag-for-flag. Where a flag made sense for the AI use case, I added it. Where it didn't, I skipped it. The goal is not compatibility — it's utility for AI agents.

The Honest Benchmark

I benchmarked aict against GNU coreutils. Here are the results:

Tool	GNU	aict	Ratio
`ls` (1,000 files)	~2ms	~15ms	7×
`grep` (100k lines)	~1ms	~100ms	100×
`find` (deep tree)	~2ms	~9ms	5×
`cat` (100k lines)	~1ms	~23ms	17×
`diff` (1,000 lines)	~1ms	~10ms	10×

grep and cat are slow because every file is MIME-typed and language-detected. Use --plain to skip enrichment when you only need content. The trade-off is intentional: more tokens spent on parsing vs. more semantic information returned.

Is This Actually Useful?

I've been using aict with Claude and Cursor for two months. The difference is noticeable. The agent makes fewer mistakes about file types. It doesn't confuse directories with files. It correctly identifies binary files before trying to read them. It understands the structure of a codebase faster.

The token savings are real. A directory listing that used to cost 2,000 tokens in plain text now costs 800 in XML with three times the information density. Over a typical coding session with dozens of tool calls, that adds up.

Open Source

The project is MIT licensed and on GitHub. It's written in Go with zero external dependencies. You can audit the entire codebase in an afternoon. I'd love contributions — new tools, performance improvements, bug fixes.

If you build AI agents that interact with codebases, give it a try. Your agent will thank you. And if it doesn't work for your use case, that's fine too. GNU coreutils aren't going anywhere.

The repo is at github.com/synseqack/aict.

I got tired of configuring the same stack over and over, so I built a modular project assembler

Ronak Parmar — Wed, 25 Mar 2026 13:26:48 +0000

Every side project I started followed the same ritual.

Find a starter. Clone it. Realize it doesn't have the exact
combination I need — say, Next.js with Express as a separate
backend, PostgreSQL, JWT auth, and Tailwind. Start adding things.
Watch the tsconfig break. Spend 45 minutes on Stack Overflow.
Finally start actually building at 11pm, mentally exhausted.

I did this enough times that I started keeping a folder of
"my personal starters." Which worked until I had six of them and
they were all slightly different and none of them had the latest
versions of anything.

So I built Foundation CLI instead.

What it is

Foundation CLI is a dependency-aware project assembler. You describe
your stack — frontend, backend, database, auth, UI, deployment — and
instead of copying static template files, it:

Resolves the full module dependency graph
Detects and handles conflicts automatically
Merges configs intelligently (deep merge for package.json, key-dedup for .env, semver intersection for requirements.txt)
Commits everything atomically — or not at all

npx @systemlabs/foundation-cli create

The part that was interesting to build

The dependency resolver was the core challenge. Modules don't
conflict by name — they conflict by capability. "Auth JWT" and
"Auth OAuth" are different implementations of the same capability.
The resolver uses capability tokens, not module IDs, to detect this.

Then it runs Kahn's algorithm to build a topological sort of the
module execution order — because if Tailwind needs to run after
Next.js (to patch the config correctly), that dependency needs to be
explicit and enforced.

Conflicts come in two tiers:

Hard conflicts — two auth modules, two frontends. Block the entire scaffold.
Advisory conflicts — Express + Cloudflare Workers (Express doesn't run on the edge). Warn, but don't block.

The config merge problem

This is the part that template copiers get wrong. When you add
Tailwind to a Next.js + Express project, three different files need
to change:

package.json — new devDependencies
tailwind.config.js — new file
globals.css — Tailwind directives
Possibly next.config.mjs — PostCSS config

A static template can't do this. You either have a template per
combination (exponential), or you have a module system that knows
how to merge.

Foundation CLI's merge engine handles this per file type. JSON files
get deep-merged with conflict detection. .env files get
key-deduplicated. docker-compose.yml gets service-merged.
requirements.txt gets semver-intersected.

Zero partial scaffolds

Every write goes through a FileTransaction. Files are staged to a
temp directory. If anything fails — a template render error, a
missing dependency, a hook failure — the temp dir is deleted and
the output directory is left completely untouched.

You either get a complete, working project or you get nothing. No
mystery half-generated directories.

What's in it

28 built-in modules across 7 categories
8 project archetypes (SaaS, AI App, E-commerce, API Backend, etc.) with pre-filled smart defaults
Plugin SDK — third-party modules publish to npm with foundation-plugin keyword
TypeScript throughout, strict mode, all generated projects pass tsc --noEmit

Try it

npx @systemlabs/foundation-cli create

Repo: https://github.com/ronak-create/Foundation-Cli

I'd love feedback — especially if you've built something similar
and solved the config merge problem differently. The current
approach works but I'm not convinced it's the best design.

Open-sourcing Foundation CLI — a dependency-aware project scaffolding tool

Ronak Parmar — Mon, 16 Mar 2026 10:06:11 +0000

I’ve been experimenting with a CLI tool for my own workflow that tries to simplify starting new projects.

The idea is that instead of manually wiring frameworks, databases, auth, etc., you describe the stack you want and the CLI generates the project structure.

For example something like:

"I want a SaaS with Next.js, Express, PostgreSQL and JWT auth"

The tool resolves dependencies, merges configs, and sets up the integration code automatically.

I'm curious if people here actually find tools like this useful, or if most devs prefer starting projects manually.

Would love to hear how others approach bootstrapping new projects.

Github