This is a submission for the GitHub Copilot CLI Challenge
What I Built
I built one of my dream projects — a minimalist vector drawing app — but with a twist.
The goal isn’t to provide the usual “vector editor toolkit” (Bezier curves, snapping, boolean ops, perfect shapes, layers, etc.). Instead, it focuses on just two actions:
- Draw free lines
- Fill closed areas
That sounds simple, but it’s deceptively hard.
The drawing is made of independent line segments. There’s no automatic merging, no “path building” UI, no assumption that the user is drawing clean vector shapes. The fill algorithm has to detect when those freehand strokes form a closed boundary and then flood the interior reliably.
The tech behind it is the best part for me:
- The UI is simple HTML
- The engine is Rust compiled to WASM
- The core engine is view-independent, so later I can plug the same logic into other frontends and build a more serious drawing application without rewriting the geometry engine
I know: today many people don’t want to draw without AI.
But sometimes you just want a fast sketch, a logo idea, or a colorful doodle — and you want full control.
This tool is built exactly for that.
A Long Long Time Ago
Back when I was a Flash programmer (and also did graphic design), I loved the vector drawing workflow in the Flash IDE — especially its “lazy fill” feeling. In practice it often behaved better than many modern vector tools in situations where paths aren’t perfectly clean.
Later, when Flash faded away, I worked with a painter-style program built on early SVG tech (around 2014). That’s where I hit the classic problem: filling areas formed by loosely intersecting strokes is hard.
At the time I could solve it on paper, but I couldn’t implement it properly.
This project is me returning to that problem — with better tooling, Rust, and a clean geometry-focused approach.
Demo
The source on my github page is:
rustroke github
Also very handy solution to use vercel to host my app. Give instant test on other devices also after every commit. Which is happen frequently with copilot cli workflow.
rustroke in action
My Experience with GitHub Copilot CLI
This project also came with an unexpected “environment story”.
A few months ago, my workplace required me to switch from a MacBook Pro to a Windows laptop — and not a shiny new one, but a 7+ year old Dell. I still wanted to keep my UNIX-terminal-first workflow, so my first move was to install Ubuntu via WSL.
After that, Windows became “Linux enough” for my daily work — while I could still run a few company-critical native apps like Teams.
wsl install ubuntu
There’s one downside though: Ubuntu can run GUI apps through WSL, but the windowing experience clashes with Windows’ own window management. So I mostly stick to cmd as a terminal host and organize everything through split panes.
On my main monitor, I keep a dedicated large panel for Copilot CLI. On the laptop display, Teams runs separately. With this setup, Copilot is always “there” — far more convenient than switching to a browser-based AI app.
Copilot CLI main advantage
For me, the main advantage of Copilot CLI is that it can work directly with a folder’s context and apply changes inside the repository quickly.
Install
# node 24
npm install -g @github/copilot
copilot
/login
Standard start:
copilot --allow-all-tools --allow-all-paths
That makes the workflow simple:
- I write a prompt about what I want changed
- Copilot applies it directly in the repo
- I stay in my terminal-first flow instead of context switching
AI as a reasoning tool, not a typing tool
One unexpected lesson from this project was that I didn’t really use AI as a code generator — I used it as a thinking partner.
I ended up with a very clear separation:
- ChatGPT → problem discussion
- Copilot CLI → code modification
This turned out to be extremely effective for this kind of project.
Geometry problems are rarely about syntax errors.
They are about understanding what actually happens.
For example, I could describe situations like:
“At this corner the algorithm should continue along the horizontal edge because the tangent changes less than the vertical one.”
That is much easier to explain conceptually than by pasting 800 lines of Rust.
I didn’t need to provide the full source code.
Instead, I explained the behavior.
We could reason about:
- topology
- edge direction
- turning angles
- graph traversal rules
Once the idea became clear, I translated it into a precise modification request — and Copilot CLI applied it directly to the project.
So the workflow became:
- Discuss the visual or mathematical problem
- Refine the algorithm
- Write a minimal change request
- Let Copilot implement it inside the repo
For algorithm-heavy software, this is surprisingly powerful.
The AI wasn’t replacing development —
it separated thinking from editing.
And for a geometry engine, that made a huge difference.
Hardes Spot
The real challenging issue was the debugging this math heavy RUST/WASM engine, which is time to time freez. So that why put the log on UI
Final Puzzle
Finally this image lead to a breaktruh to AI understanding. With this I can describe to ChatGPT how important is to keep tangent is line by line in a good direction. This is where fill debug show a wrong case where the ground and roof top area are connecteted.
Then ChatGPT make a perfect prompt to CopilotCLI which is do their job perfectly.
Top comments (0)