Forem: Ola Prøis

Is Dev.to a community or a club? I'm leaving, but first, let me explain.

Ola Prøis — Sun, 22 Mar 2026 15:58:12 +0000

After some months of posting on dev.to, I'm moving on. Not out of frustration (well, maybe a little), but because I think this platform has a structural problem worth naming.

I write about different stuff, and joined some challenges. My posts take real effort, they're not "10 JavaScript tips" listicles. And yet, week after week, the same handful of authors dominate the trending section. The weekly top badges? Same names. The homepage? You already know who'll be there.

I don't think those authors are doing anything wrong. But I do think the platform's reaction-based ranking creates a feedback loop: popular authors get more visibility → more reactions → more visibility. New or niche voices don't stand a chance unless they game the same system.

Dev.to markets itself as an inclusive community, but from where I'm standing, it's started to feel more like a club where membership is measured in follower count.

Some honest questions before I go:

Does anyone else experience this, especially writing in less mainstream areas like Rust, systems, or DevOps?

Is there a better platform for technical writing that actually surfaces quality content? (Hashnode? Lobsters? A personal blog?)
I'm not here to burn bridges. I genuinely hope the platform evolves. But for now, I'm putting my energy into spaces that feel less like shouting into a void.

I Built a Quantum Circuit Simulator Without Understanding Quantum Physics

Ola Prøis — Tue, 17 Mar 2026 13:12:51 +0000

A few days ago I set myself a weird challenge. I'm not a quantum physicist. I'm not a Rust developer. But I wanted to know: can you build something genuinely useful in a technical domain you don't personally understand, by directing AI carefully and being honest about what you don't know?

The answer, I think, is yes. But it's more complicated than that.

The Gap I Saw

I was looking at quantum computing tools and noticed something odd. Every visual quantum circuit editor is either a web app, a Python library that generates static plots, or a cloud-based service. Nothing just runs as a native binary on your desktop. No install process. No Python environment to manage. No browser required.

For someone learning quantum computing, that friction matters. You want to drag a gate onto a wire, see the Bloch sphere update in real time, step through the circuit gate by gate, and understand what's happening. You shouldn't need to pip install anything or log into IBM's cloud.

So I decided to build that. Even though I don't really understand quantum mechanics.

Tool	Visual Editor	Native Desktop	Open Source	Real-time Sim
KetGrid	✅	✅	✅	✅
Qiskit Composer	✅	❌ (web)	Partial	Cloud
Quirk	✅	❌ (web)	✅	✅ (JS)
QPanda	❌	❌	✅	✅

How It Was Built

KetGrid is written entirely in Rust using egui for the GUI. The entire codebase was generated through AI-assisted development. I provided the direction, the architecture decisions, the requirements, and the review. The AI wrote the code.

I want to be completely transparent about this. It's in the README. It's not something I'm trying to hide, and I think it's actually part of what makes this interesting as an experiment.

The architecture ended up as a clean Cargo workspace with three crates:

ketgrid-core handles the circuit data model, gate definitions, and serialization formats
ketgrid-sim runs the state vector simulation engine with Rayon parallelism and gate fusion
ketgrid-gui is the egui application: the editor, visualizations, and everything you interact with

The sim crate uses rayon for parallelization on larger circuits and nalgebra for complex matrix operations.

What It Does Right Now

As of v0.1.0, released today:

Circuit Editor: Drag gates from a palette onto qubit wires and see the state vector update in real time at 60fps. Right-click context menus, undo/redo (100 operations deep), and keyboard shortcuts.

Bloch Spheres: Per-qubit Bloch sphere for each qubit that updates as you build, computed from the reduced density matrix.

Step-Through Mode: Advance one gate column at a time with playback controls to watch the quantum state evolve. This is where the learning happens.

Probability Visualization: Phase-aware histogram coloring with toggleable amplitude tables. Entanglement between qubits is shown directly on the wires themselves.

21 Built-In Examples: Bell states, quantum teleportation, Grover's algorithm, QFT, Deutsch-Jozsa, Bernstein-Vazirani, Simon's, superdense coding, and the three-qubit Shor error correction code. All searchable from a built-in browser.

Export: OpenQASM 2.0, Qiskit Python code, SVG circuit diagrams, and a native JSON format.

The current ceiling is around 14 qubits in real time. GPU acceleration is planned for v0.3 to push that to 25+.

What I'm Genuinely Unsure About

Here's where I need to be honest. I don't know if this is useful.

I think the teaching and learning use case is real. Step-through mode with live Bloch spheres is something I haven't seen anywhere else in a native offline app. The 14-qubit ceiling is fine for Bell states, teleportation, Grover, and QFT.

But I don't know if the people who would benefit from this will find it, or whether the qubit ceiling is a dealbreaker for them, or whether I'm missing obvious things that would make it more useful.

Where I Want to Take It

The roadmap has three major workstreams after v0.1.0:

GPU Acceleration (Workstream A)

Push from ~14 to 25+ qubits using wgpu compute shaders. Cross-platform by default: Vulkan on Linux, DX12 on Windows, Metal on macOS. The crossover point where GPU beats CPU is around 13-15 qubits.

Quantum Phenomena Visualization (Workstream B)

Make quantum mechanics visceral. Animated amplitude flow showing how gate operations redistribute probability across basis states. Measurement collapse as a dramatic visual event. Entanglement propagation, "spooky action at a distance" made visible. A combined "Quantum Playground" mode for circuits ≤6 qubits.

Interactive Bell Inequality Experiment (Workstream C)

This is the one I'm most excited about. The idea is a mode where you run a CHSH test: the most important experiment in quantum physics. You collect measurement outcomes across multiple shots, watch the S-value rise, and see it cross the classical limit of 2.

That crossing is the empirical proof that quantum mechanics cannot be explained by classical hidden variables.

"Classical physics says S cannot exceed 2. You just measured S = 2.7. Welcome to quantum mechanics."

No existing tool lets you run this interactively and watch it happen. I don't know enough about this domain to know if I'm overestimating how compelling that would be. That's partly why I'm writing this.

The AI Development Angle

I want to say something about the process because I think it's worth discussing.

Building software in a domain you don't understand forces you to think very carefully about what you're asking for. You can't rely on instinct. You have to:

Describe behavior precisely: no hand-waving
Review output for correctness: even when you can't fully evaluate the implementation
Be honest about what you're missing4: and design around that honesty

There were things the AI got wrong that I didn't catch until much later. There are probably things in the current codebase that experienced Rust developers would consider bad patterns. That's part of the journey and I'm open about it.

What surprised me is how far you can get with this approach. The circuit editor works. The simulation is real. The export formats are correct. The thing I built actually does what I intended.

If You Want to Try It

KetGrid is MIT licensed, fully open source, and there are pre-built binaries for Windows, macOS, and Linux on the releases page. No install process, just download and run.

# Or build from source
git clone https://github.com/OlaProeis/KetGrid.git
cd KetGrid
cargo run --release -p ketgrid-gui

If you're a quantum computing researcher, a physics educator, or a Rust developer, and you try it and have opinions, I'd really like to hear them. I'm specifically looking for feedback on whether the tool is actually useful in its current state, or whether specific roadmap items need to happen first before it's worth your time.

GitHub | Releases | Roadmap

From AI Studio to Cursor: Building Archlyze with Google Gemini

Ola Prøis — Wed, 04 Mar 2026 14:43:48 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

I built Archlyze, a browser-based AI code analyzer that lets you paste in source code and get an instant, structured analysis: what the code does, potential issues, security concerns, and architectural patterns.

The entire thing runs without a traditional backend. Gemini is the backend. The API is called directly from the browser, which surprised me with how capable and practical that turned out to be for a tool like this. It felt like a different mental model, instead of building a server to orchestrate AI calls, I just... talked directly to the model from the client.

Archlyze is also getting a significant update today! with an Executive Briefing feature, a full on-demand presentation layer powered by Gemini that transforms raw code analysis into a management-ready deck. It includes:

Executive Translation: Gemini rewrites the analysis in plain, jargon-free language for non-technical stakeholders
Code Walkthrough: Side-by-side view with full source and plain English explanations, section by section
Architecture Diagram: Auto-generated Mermaid.js flowchart rendered live in the presentation
Security Scorecard: Visual risk heatmap with a 0–100 score and per-component health table
Multilingual Briefings: Configurable output language: English, Norwegian, Japanese, or others
Export: Download as Markdown, PowerPoint (.pptx), or PDF
Editable: Toggle edit mode to tweak the Markdown before exporting

It runs entirely on-demand and doesn't touch the standard analysis pipeline.

Demo

👉 Read my original build post here

https://archlyze.vercel.app/

What I Learned

The biggest lesson was about workflow switching. I started the project entirely in Google AI Studio, iterating on the React setup through a lot of trial and error, probably 10+ attempts before things clicked. That repetition wasn't wasted though; years of working with Cursor taught me that reiteration is just part of the process, not a sign something is wrong.

At a certain point, when the project had good momentum but was growing in complexity, I switched to Cursor. Not because AI Studio failed me, but because I needed more control over session state and context. Cursor gives me tighter, more predictable context windows and better tooling for managing a growing codebase. The two tools ended up being complementary rather than competing: AI Studio for exploration and prototyping, Cursor for refinement and complexity management.

The other surprise was how naturally Gemini fits as a "zero-backend" architecture. For the right kind of project, especially developer tools and internal utilities, calling the model directly from the client is a completely legitimate approach, not a hack.

Google Gemini Feedback

Honestly impressed, especially early on. Gemini was fast, coherent, and produced genuinely useful output right out of the gate for a project like this.

Where I ran into friction: context management over long sessions. AI Studio feels designed around a long, continuous conversation, and that works well up to a point. But as the project grew and my prompting got more layered and less structured, I started losing confidence in whether the model was still tracking the full picture. I'm not sure if it was the model, my prompting style, or the lack of a rules/system-prompt setup, but it felt like complexity was the ceiling.

For focused, well-scoped tasks? Excellent. For managing a multi-session project with evolving requirements? I'd want more control, custom instructions, explicit context resets, and better visibility into what the model is "holding." That's ultimately why I moved to Cursor for the harder parts.

But the core capability is strong. The speed and quality on the initial build genuinely impressed me, and using it as a live backend for a browser app is an approach I'll absolutely use again when it fits.

DEV.to Weekend Challenge Submission - forgeStat

Ola Prøis — Sun, 01 Mar 2026 19:23:34 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built forgeStat for the open-source community, the maintainers, contributors, and users who make GitHub the heartbeat of collaborative software development.

If you've ever maintained an open-source project, you know the struggle: you juggle GitHub's web UI, email notifications, third-party analytics tools, and browser tabs just to answer basic questions:

Is my project growing?
Are issues piling up faster than I can close them?
Who's contributing and how active are they?
Are there security vulnerabilities I missed?

This tool is for the solo maintainer burning the midnight oil, the team managing hundreds of repos, and the curious developer who wants to understand any project's health at a glance. The terminal is our natural habitat, why leave it to check GitHub?

What I Built

forgeStat is a real-time GitHub repository dashboard that runs entirely in your terminal. It gives you a single-screen view of everything happening in a repository: stars, issues, PRs, contributors, releases, velocity metrics, and security alerts, all without leaving the command line.

Key Features

8 Real-Time Metric Panels

Stars: Sparkline charts showing 30-day, 90-day, and 1-year trends with milestone predictions
Issues: Open issues grouped by label, sortable by age and activity
Pull Requests: Open, draft, ready, and merged counts with average merge time
Contributors: Top contributors by commits + new contributors tracking
Releases: Release history with publish dates and average release intervals
Velocity: Weekly opened vs closed/merged metrics (4/8/12 week views)
Security: Dependabot vulnerability alerts broken down by severity
CI Status: GitHub Actions success rate and recent run history

Repository Health Score (0-100)
A comprehensive grade based on four dimensions:

Activity (25%): Commit velocity, PR merge rate, CI success
Community (25%): Contributor diversity, new contributors, issue engagement
Maintenance (25%): Release cadence, security alerts, health files
Growth (25%): Star trends, forks, watchers

Interactive TUI Experience

Zoom mode for full-screen panel details (Enter)
Mini-map for bird's-eye overview (m)
Fuzzy finder for quick repo switching (f)
Diff mode to compare snapshots (d)
Command palette with Vim-style commands (:)
Mouse support with draggable panel resizing
6 built-in themes + custom theme support
Pong mini-game during loading - Play while fetching large repos (>5k stars)

CLI Output Modes
When you don't need the full TUI:

--json for complete data export
--summary for compact status checks
--report for markdown health reports
--watchlist for multi-repo dashboards
--compare for side-by-side repo comparison

Loading Screen Experience
Fetching data from GitHub can take time, especially for popular repos. The loading screen turns this wait into a delightful experience:

Twinkling starfield background with subtle animations
Real-time progress tracking see which endpoint is being fetched and page-by-page progress for star history
Animated cyan border with pulsing glow effect
Pong mini-game automatically appears for repos with >5,000 stars. Use ↑/↓ to play against the AI while you wait!
Auto-refresh every 10 minutes keeps your data fresh while you leave the app running

For huge repos like torvalds/linux or facebook/react, you'll get a warning: "⚠ This repo has 182.2k stars, loading may take a while!"
Then you can challenge the AI to a game of Pong.

Demo

Quick Demo Commands

# Interactive TUI - the full experience
forgeStat ratatui-org/ratatui

# Try a large repo to see the Pong game while loading!
forgeStat microsoft/vscode

# Quick summary for CI pipelines
forgeStat facebook/react --summary

# Export data for analysis
forgeStat microsoft/vscode --json > vscode-metrics.json

# Compare two competing projects
forgeStat react --compare vue

# Multi-repo dashboard
forgeStat --watchlist microsoft/vscode,rust-lang/rust

The 8 Metric Panels

Code

Repository: https://github.com/olaproeis/forgeStat

Built with Rust using:

ratatui for the terminal UI
octocrab for GitHub API
tokio for async runtime
serde for serialization

How I Built It

The Stack

Purpose	Technology
Language	Rust 1.74+
TUI Framework	ratatui
GitHub API	octocrab + reqwest
Async Runtime	tokio
CLI Parsing	clap
Config/Cache	serde + toml + serde_json

Architecture

Key Technical Decisions

Cache-First Architecture: Data is cached locally with a 15-minute TTL. This enables:

Instant startup when revisiting repos
Full offline mode support
Respect for GitHub's rate limits

Parallel Fetching: All 8 metrics are fetched concurrently using tokio::join!, making the most of the async runtime.

Modular TUI: Each feature gets its own file in tui/app/ - keeps the codebase maintainable as features grow.

Zero-Config by Default: Works out of the box with sensible defaults. Optional GitHub token unlocks higher rate limits and private repo access.

Challenges Faced

Rate Limiting: GitHub's 60 req/hour for unauthenticated requests required smart caching and batching strategies.
TUI Layout Complexity: 8 panels that need to work on any terminal size, with resizable borders, zoom states, and a mini-map overlay. Solved with ratatui's constraint system and careful state management.
Large Repository Loading Times: Repos with 100k+ stars can take 1-2 minutes to fetch due to GitHub API pagination. Rather than showing a boring spinner, I built an engaging loading screen with twinkling starfield background, animated progress bars, and a playable Pong mini-game that appears automatically for large repos. Users can pass the time playing while their data loads!

What I'd Do Differently

Start with a more robust testing strategy from day one
Consider a plugin architecture for custom metrics
Plan for internationalization earlier (date formats, etc.)

Try It Out

Installation (NB! Not all tested, might be better to clone and build)

Windows (PowerShell)

iwr https://github.com/OlaProeis/forgeStat/releases/latest/download/install.ps1 -UseBasicParsing | iex

macOS / Linux

curl -fsSL https://github.com/OlaProeis/forgeStat/releases/latest/download/install.sh | bash

Homebrew (macOS/Linux)

brew tap olaproeis/tap
brew install forgeStat

Cargo (any platform after clone)

cargo install forgeStat

Or download directly from releases:

https://github.com/OlaProeis/forgeStat/releases/latest

Closing Thoughts

The terminal is where developers live. Bringing GitHub insights there feels natural. I hope this tool helps others keep their projects healthy and their communities thriving.

Star the repo ⭐ if you find it useful, and open an issue if you have ideas for improvement, its untested on MacOS and Linux!

Thanks for reading! Built with ❤️ for the open-source community.

Dotfiles Coach Update: Interactive TUI and RAG Search for Shell History

Ola Prøis — Mon, 16 Feb 2026 11:43:53 +0000

A couple of weeks ago I posted about Dotfiles Coach, a CLI tool that analyses your shell history and uses GitHub Copilot CLI to generate aliases and functions based on your actual workflow.

Since then I've added two features that I think make the tool a lot more useful, and I wanted to share them.

Search: find forgotten commands by describing them

Ever typed a really useful command three weeks ago and have no idea what it was? Instead of scrolling through thousands of history lines or piping through grep, you just describe what you're looking for:

dotfiles-coach search "that docker compose command"
dotfiles-coach search "kubernetes pods"
dotfiles-coach search "ffmpeg convert"

It tokenizes your query and every command in your history, then scores them with a weighted mix of exact keyword overlap, fuzzy Levenshtein matching, substring detection, frequency, and recency. The top results come back ranked in a table with scores and usage counts.

The whole thing runs 100% locally. No network, no Copilot needed for the core search. But if you add --explain, it sends just the top result (scrubbed of secrets) to Copilot for a plain-English explanation of what the command does and when you'd use it.

This quickly became my favorite feature. It's the kind of thing you don't think you need until you use it once, and then you use it all the time.

Interactive TUI: review suggestions before applying

The original version dumped all Copilot suggestions to your terminal at once. That works, but when you have 20+ suggestions it's hard to decide which ones to keep and which to skip.

Now you can add --interactive to either suggest or apply:

dotfiles-coach suggest --interactive
dotfiles-coach apply --interactive --dry-run

This launches a terminal UI built with ink (React for CLIs) where you can:

Scroll through suggestions one at a time
Press Enter to mark one for apply, Space to ignore it
Press e to open the code in your editor, tweak it, and come back
Press a to approve everything at once
Press q when you're done

The TUI re-renders after each editor session so you can keep reviewing. If you're piping output or running in CI, it falls back to non-interactive mode automatically.

Updated pipeline

The workflow diagram now includes search as its own branch:

And the internal architecture shows how search sits alongside the suggest pipeline, sharing the same parser layer but going straight to the tokenizer/scorer without touching Copilot:

Updated numbers

The test suite grew quite a bit with these additions:

425 automated tests (up from 291), across 22 test files
102 tests just for the search scorer (tokenization, fuzzy matching, edge cases)
The interactive TUI has TTY detection and graceful fallback, tested in both modes

Try it out

Everything works with the bundled sample data, no real history or Copilot subscription needed:

git clone https://github.com/OlaProeis/dotfiles-coach.git
cd dotfiles-coach
npm install && npm run build && npm link

# Search (100% local)
dotfiles-coach search "docker" --shell bash --history-file tests/fixtures/sample_bash_history.txt

# Suggest with interactive TUI
dotfiles-coach suggest --interactive --shell bash --history-file tests/fixtures/sample_bash_history.txt --min-frequency 1

# Apply with interactive review (dry run)
dotfiles-coach apply --interactive --dry-run

If you don't have Copilot installed, set DOTFILES_COACH_USE_MOCK_COPILOT=1 first and the mock client will return realistic sample suggestions.

Repo: github.com/OlaProeis/dotfiles-coach

Hope these additions make the tool more useful. Happy to answer any questions in the comments.

Building an AI Code Analyzer with Google AI Studio (And Finishing It in Cursor)

Ola Prøis — Wed, 11 Feb 2026 18:20:59 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

Archlyze is a browser-only SPA that uses Google Gemini to analyze source code (Rust, Python, JS/TS, Go, and more): it extracts components and dependencies, flags issues with severity, suggests fixes and unit tests, and generates flowcharts/UML/data-flow diagrams via gemini. We started from a detailed prompt in AI Studio (refined with Perplexity and Gemini), then finished and extended the app in Cursor with folder import, .gitignore parsing, session history, model selection, and Markdown export.

Demo

! I ran out of free tier credits, so don't have a screenshot with images yet, will upload to the github when i have. apparently it can take from moments to a few weeks to get billing on your google api.

https://archlyze.vercel.app/

My Experience

Starting in AI Studio. We began by drafting the concept and prompt with different models (Perplexity and Gemini), then took it into Google AI Studio to build the first version. We hit a recurring issue early on: React and tooling versions. The generated app kept failing to run or build, and we had to iterate many times (10+ attempts) before we got a working setup.

The Prompt:

Build 'RustFlow Analyzer'—a web app for comprehensive Rust file analysis. Users upload a .rs file (max 500 lines) or paste code. 
Gemini 1.5 Pro performs deep analysis: extract all functions, structs, traits, impls; map dependencies and call relationships; identify ownership patterns, error handling, and common anti-patterns (unnecessary clones, unwrap() abuse, missing lifetimes).

Display results in three panels:

Code View: Original code with syntax highlighting (Monaco editor), clickable line numbers to jump to explanations

Analysis Panel: Collapsible sections for each major code block (functions/structs) with plain-English explanations, detected issues marked with warning/error badges, and best-practice suggestions

Visual Panel: Use Imagen to generate architecture diagrams—function call graphs (boxes + arrows showing invocation flow), struct relationship diagrams (ownership/borrowing visualized with solid/dashed lines), and module dependency trees. Include toggle buttons for diagram types (flowchart, UML, data flow). Style: professional developer docs aesthetic, Rust brand colors (orange #CE422B, dark gray), clean minimalist lines.

Features: file upload (.rs), smart truncation warning if >500 lines, 'Regenerate Diagram' button for each section, export full report as HTML with embedded images, dark/light theme, example files (basic HTTP server, CLI parser, async tokio app). Add 'Share Analysis' to generate unique URL with results cached. Loading states with progress indicators, error handling for invalid Rust syntax or oversized files. Deploy-ready SPA with responsive mobile layout

Evolving the idea. Once the base was stable, we shifted from Rust-only to multi-language support and added a lot of features: folder import, .gitignore-aware filtering, session history, dependency detection, issue severity, auto-fix, unit test generation, and diagram types. Doing this in Cursor (with the same codebase) felt natural: AI Studio gave us the initial structure and Gemini integration; Cursor helped us refactor, extend, and keep the code consistent.

Structured output and “thinking” models. The biggest technical takeaway was relying on a strict JSON schema for analysis. Without explicit required fields and clear descriptions in the responseSchema, Gemini 2.5 sometimes returned minimal or inconsistent JSON. Once we defined the schema properly, the analysis results became reliable enough to drive the UI (components, issues, dependencies). I also learned that Gemini 2.5’s “thinking” phase means longer response times, so we added scaled timeouts (e.g. 60s for small files, 180s for large ones) and loading states so the app doesn’t feel broken while the model is reasoning.

Surprises. (1) How much the app could do without a backend, API key in the browser, direct calls to Gemini, and LocalStorage for settings and theme made the architecture simple. (2) Image generation (`gemini-2.5-flash-

Overall, the track was a solid way to go from “idea + prompt” to a real SPA: AI Studio for fast prototyping and Gemini integration, then Cursor to harden and extend it into something we’d actually use.

Repo:
https://github.com/OlaProeis/Archlyze

Try it:
https://archlyze.vercel.app/

Dotfiles Coach: Your Shell History is Full of Automation Gold (You Just Don't Know It Yet)

Ola Prøis — Sun, 08 Feb 2026 14:21:45 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Dotfiles Coach is a CLI tool that mines your shell history for repeated patterns and uses GitHub Copilot CLI to generate smart aliases, functions, and safety improvements -- tailored to your actual workflow.

Every developer types the same commands hundreds of times. git add . && git commit -m "..." && git push. docker compose up -d && docker compose logs -f. cd ~/projects/thing && npm run dev. We all know we should create aliases and shell functions for these, but who has the time to audit their own history?

Dotfiles Coach does it for you:

analyze -- Reads your shell history (Bash, Zsh, or PowerShell) and identifies the most repeated command patterns using frequency analysis with Levenshtein-based grouping. It also flags dangerous commands like rm -rf without safeguards, chmod 777, or sudo with wildcards. This step is 100% local -- no network, no AI.
suggest -- Takes the top patterns, scrubs all secrets locally, and sends them to gh copilot suggest to generate shell-specific aliases, functions, and one-liners. This is where Copilot shines -- it understands your workflow context and produces suggestions that actually make sense for your habits.
apply -- Writes approved suggestions to a dedicated shell config file (~/.dotfiles_coach_aliases.sh or ~/.dotfiles_coach_profile.ps1). It creates backups automatically, supports dry-run previews, and never auto-sources anything -- you stay in control.
report -- Generates a shareable Markdown or JSON report combining analysis results and Copilot suggestions. Great for documentation or team sharing.

Why I built this

I realized I was typing git status, git add ., git commit -m as three separate commands dozens of times a day. I wanted something that looks at my real behavior and suggests automation that fits me -- and I wanted Copilot to be the brain behind those suggestions.

Privacy-first design

The part I'm most proud of: mandatory secret scrubbing. Before any shell history data touches Copilot, it passes through 13 regex-based filters that catch passwords, API tokens, SSH keys, AWS credentials, GitHub/GitLab/npm tokens, Bearer headers, URLs with embedded credentials, npm config set auth commands, Base64 blobs, and more. Every match is replaced with [REDACTED]. This layer cannot be disabled -- it's architecturally enforced, not opt-in.

The numbers

291 automated tests across 20 test files
13 secret-scrubbing patterns (all unit tested)
Multi-shell support -- Bash, Zsh, and PowerShell with auto-detection
3-tier response parser for Copilot output (JSON fences, raw JSON, regex fallback)
Zero API tokens required -- piggybacks on your existing gh auth session

Demo

GitHub repo: https://github.com/OlaProeis/dotfiles-coach

How it works

Quick start

# Install
git clone https://github.com/OlaProeis/dotfiles-coach.git
cd dotfiles-coach
npm install && npm run build

# 1. Analyze your shell history (100% offline)
node dist/cli.js analyze

# 2. Get Copilot-powered suggestions
node dist/cli.js suggest

# 3. Preview what would be written (dry-run)
node dist/cli.js apply --dry-run

# 4. Apply suggestions to a file
node dist/cli.js apply

# 5. Generate a report
node dist/cli.js report --output report.md

Try it without Copilot (mock mode)

You can test the full pipeline without a Copilot subscription using bundled fixture data:

# PowerShell
$env:DOTFILES_COACH_USE_MOCK_COPILOT = "1"
node dist/cli.js analyze --shell bash --history-file tests/fixtures/sample_bash_history.txt --min-frequency 1
node dist/cli.js suggest --shell bash --history-file tests/fixtures/sample_bash_history.txt --min-frequency 1
node dist/cli.js apply --dry-run

# Bash/Zsh
DOTFILES_COACH_USE_MOCK_COPILOT=1 node dist/cli.js suggest --shell bash --history-file tests/fixtures/sample_bash_history.txt --min-frequency 1

Architecture

The pipeline flows through clearly separated layers: parsers (one per shell) feed into analyzers (frequency + safety), which are scrubbed by the secret scrubber, then passed to the Copilot client (real or mock), and finally formatted by formatters (table, markdown, JSON) or written safely by file operations.

Tech stack

Area	Choice
Runtime	Node.js 18+ (ESM)
Language	TypeScript (strict mode)
CLI framework	`commander`
Terminal UI	`chalk`, `ora`, `boxen`
Copilot integration	`execa` wrapping `gh copilot suggest`
String similarity	`fast-levenshtein`
File I/O	`fs-extra`
Tests	`vitest` (291 tests)

My Experience with GitHub Copilot CLI

How Copilot CLI powers the tool itself

Dotfiles Coach doesn't use an npm SDK or REST API for Copilot -- there isn't one for Copilot CLI. Instead, it wraps gh copilot suggest as a child process via execa:

const result = await execa('gh', ['copilot', subcommand, prompt], {
  timeout: 30_000,
  env: { ...process.env, GH_PROMPT_DISABLED: '1' },
});

The tool builds structured prompts from your history patterns (frequency data, command sequences, shell type) and sends them to Copilot. Copilot's response is then parsed through a 3-tier strategy:

JSON extraction from markdown fences -- Copilot often wraps structured output in `json blocks
Raw JSON detection -- Sometimes it returns bare JSON arrays
Regex fallback -- For conversational responses, we extract suggestions via pattern matching

This approach was born out of necessity: Copilot CLI's output format isn't guaranteed to be machine-readable, so the parser had to be resilient.

How Copilot CLI helped during development

Beyond being in the tool, Copilot CLI was my constant companion building the tool. Some examples:

Designing the secret scrubber:
I used gh copilot suggest to brainstorm regex patterns for detecting secrets in shell history. Copilot caught edge cases I hadn't considered -- like AWS access keys always starting with AKIA, or GitLab tokens starting with glpat-. The final scrubber has 13 battle-tested patterns.

Shell compatibility:
When implementing PowerShell history parsing (which stores plain-text commands in ConsoleHost_history.txt via PSReadLine, a different location and convention than Bash/Zsh ~/.bash_history), Copilot CLI helped me understand the format differences and platform-specific path resolution logic.

Safety rules:
The dangerous pattern detection module flags commands like rm -rf / without -i, chmod 777, sudo with wildcards, and unquoted variable expansion in rm commands. Copilot helped me think through edge cases -- like catching rm -rfi (which does have -i) versus rm -rf (which doesn't).

What surprised me

The biggest surprise was how well Copilot CLI handles context. When I feed it a set of command patterns like:

` git add . (47 times) git commit -m "..." (45 times) git push origin main (38 times) `

It doesn't just suggest three separate aliases -- it recognizes the sequence and suggests a single gcp function that does all three with a commit message argument. That kind of workflow-aware intelligence is what makes this tool genuinely useful rather than just a fancy alias generator.

The testing story

With 291 tests across 20 files, testability was a core design goal. The MockCopilotClient returns canned fixture data, which means:

Every test runs without network access
CI/CD doesn't need Copilot credentials
Contributors can run the full suite without a subscription
The mock is toggled by a single env var: DOTFILES_COACH_USE_MOCK_COPILOT=1

This pattern made development incredibly fast -- I could iterate on the suggestion formatting, caching, and apply logic without hitting Copilot every time.

Try it out: github.com/OlaProeis/dotfiles-coach

Your shell history is full of automation gold. Let Copilot help you find it.

I Built a Full Project Management App in 2 days Using Claude 4.6

Ola Prøis — Sat, 07 Feb 2026 11:40:56 +0000

TL;DR: I built Ironpad, a local-first, file-based project & knowledge management system using Rust, Vue 3, and AI-assisted development in about 2 days. The code is open source, Here's how it went.

What is Ironpad?

Ironpad is a personal project management and note-taking system where files are the database. Every note, task, and project is a plain Markdown file with YAML frontmatter. No cloud, no vendor lock-in, no proprietary formats.

You can edit your data in Ironpad's browser UI, or open the same files in VS Code, Obsidian, Vim, whatever you prefer. Changes sync in real-time via WebSocket. Everything is versioned automatically with Git.

Key features:

WYSIWYG Markdown editor (Milkdown, ProseMirror-based) with formatting toolbar
Project management with tasks, subtasks, tags, due dates, and recurrence
Calendar view with color-coded task urgency
Dashboard showing all projects with active task summaries
Git integration — auto-commit, diff viewer, push/fetch, conflict detection
Real-time sync — edit in VS Code, see changes instantly in the browser
Full-text search powered by ripgrep (Ctrl+K)
Dark theme by default, 5 MB binary, ~20 MB RAM, sub-second startup

GitHub: github.com/OlaProeis/ironPad

The Tech Stack

Layer	Technology	Why
Backend	Rust + Axum 0.8 + Tokio	Performance, safety, tiny binary
Frontend	Vue 3 + Vite + TypeScript	Composition API, fast dev experience
Editor	Milkdown (ProseMirror)	WYSIWYG markdown rendering
State	Pinia	Clean, minimal state management
Data	Markdown + YAML frontmatter	Human-readable, editor-agnostic
Version Control	Git (via git2 crate)	Automatic history for everything
Search	ripgrep	Battle-tested, sub-100ms results
Real-time	WebSocket	Instant sync with external editors

Why Rust instead of Electron?

This was a deliberate choice. Here's the comparison:

	Electron App	Ironpad (Rust)
Bundle size	150–300 MB	~5 MB
RAM usage	200–500 MB	~20 MB
Startup	2–5 seconds	< 500ms
Browser	Bundled Chromium	Your system browser
Distribution	Complex installer	Single executable

Every user already has a browser. Why bundle another one?

The Rust backend serves an API, the Vue frontend runs in whatever browser you already use. Double-click the executable, it opens your browser, you're working. That's it.

The Development Process: Built With AI

Here's where it gets interesting. Ironpad was built entirely using AI-assisted development. Not just autocomplete, the architecture, the PRD, the implementation, the debugging. All of it.

I call the approach Open Method: not just open source code, but the open development process. It is documented in the repo under docs/ai-workflow/.

The 6-Phase Workflow

Phase 1: Multi-AI Consultation
Before writing a single line of code, I discussed the idea with multiple AI models, Claude for architecture, Perplexity for library research, Gemini for second opinions. Five minutes getting different perspectives saves hours of rework.

Example: When designing the task system, one model suggested storing tasks as checkboxes in a single tasks.md file. Another pointed out that individual task files with frontmatter would be more flexible and avoid concurrent edit conflicts. Individual files was the right call.

Phase 2: PRD Creation
We wrote a detailed Product Requirements Document covering everything: features, API design, data models, edge cases, and explicitly what's not in scope. The PRD went through 3 versions, incorporating feedback about concurrency control, file watching, git conflict handling, and frontmatter automation.

Phase 3: Task Decomposition
This was a lighter project, with a new model, so i decided to skip task-master and just make a checklist document, testing how much the AI could handle in one go, i was impressed!

Phase 4: Context Loading
AI models have training cutoffs, so I used:

Context7 (MCP tool) to pull current documentation for Axum, Vue 3, and Milkdown
ai-context.md — a lean ~100-line cheat sheet telling the AI how code should fit the codebase

Phase 5: Implementation
Build features in focused sessions. Test. Update checklist. Repeat.

Phase 6: Verification
The AI writes the code. I verify the product. Run it, click the buttons, try the edge cases. Never trust "this should work."

Tools Used

Tool	Role
Cursor IDE	Primary development environment (VS Code fork with AI integration)
Claude Opus 4.5/4.6	Architecture, implementation, debugging
Perplexity AI	Library research, version checking
Google Gemini	Second opinions, catching blind spots
Context7 (MCP)	Up-to-date library documentation

The 200K → 1M Context Window Shift

Midway through development, Claude's context window jumped from 200K to 1M tokens. This was the single biggest change in the project's workflow.

Before: 200K tokens (Claude Opus 4.5)

Could hold ~3-5 files at once
Had to split features into micro-tasks
Required handover documents between every task
Cross-file bugs were hard to find
~15-20 min overhead per task (context setup)

After: 1M tokens (Claude Opus 4.6)

Entire codebase (80+ files) fits in one context
Full features implemented in single sessions
Handovers only needed between days
Cross-file bugs found automatically
~0 min overhead per task

The Codebase Audit

The clearest demonstration: I loaded the entire Ironpad codebase into a single context and asked "what's wrong?"

The AI found 16 issues, including:

Auto-commit silently broken — a flag never set to true anywhere. Finding this required reading main.rs, git.rs, and every route handler simultaneously.
Operator precedence bug — 0 > 0 evaluated before ?? in JavaScript
Missing atomic writes — only 1 of 8 write paths used the safe atomic pattern

14 of 16 issues were fixed in a single session. Zero compilation errors introduced.

This kind of comprehensive audit simply wasn't possible at 200K tokens.

What Worked (and What Didn't)

What worked well

1. PRD-first development
The single highest-leverage activity. The AI produces dramatically better code when it knows exactly what success looks like. Time spent on the PRD pays off 10x during implementation.

2. Rust's strict compiler
Rust is excellent for AI-assisted development because the compiler catches entire categories of bugs before runtime. With dynamic languages, bugs hide until production. With Rust, cargo check is a mechanical verification pass that eliminates memory safety, type mismatches, and missing error handling in one step.

3. The ai-context.md pattern
A lean (~100 line) architectural cheat sheet that tells the AI how to write code for this specific codebase. Without it, the AI invents new patterns. With it, code consistently matches existing conventions.

4. Fresh chats over long conversations
Context accumulates noise. By the third task in a single chat, the AI references irrelevant earlier context. Starting fresh with a focused handover produced consistently better results.

What didn't work

1. Trusting "this should work"
The AI confidently says this every single time. Without exception. Early on I'd take its word and move on. Then things would break two features later.

Fix: Test everything yourself. Click the buttons. Try the edge cases.

2. Vague requirements
"Add search" produces mediocre results. "Add full-text search with ripgrep, triggered by Ctrl+K, showing filename and matching line with context, limited to 5 matches per file" produces excellent results.

3. Over-engineering
The AI tends to add abstractions and generalization you don't need yet. It builds for a future that may never come.

Fix: Explicitly state YAGNI. Call it out. "Simplify this" works surprisingly well.

The Architecture

The design is intentionally simple:

User launches executable
         ↓
   Rust Backend (Axum)
   ├── REST API (notes, projects, tasks, git, search)
   ├── WebSocket server (real-time sync)
   ├── File watcher (external edit detection)
   └── Git auto-commit (60s batching)
         ↓
   Vue 3 Frontend (in your browser)
   ├── Milkdown WYSIWYG editor
   ├── Dashboard, Calendar, Task views
   ├── Pinia state management
   └── WebSocket client
         ↓
   Plain Markdown files on disk
   (editable with any tool)

Core design decisions:

Files are the database. No SQLite, no IndexedDB. The filesystem is the source of truth.
Backend owns metadata. IDs, timestamps, and frontmatter are auto-managed. Users never manually edit metadata.
External editing is a first-class citizen. The file watcher detects changes from VS Code/Obsidian/Vim and syncs them to the browser UI in real-time via WebSocket.
Git for everything. Auto-commit every 60 seconds, manual commit with custom messages, full diff viewer built into the UI.

API surface (29 endpoints):

Notes:       GET/POST /api/notes, GET/PUT/DEL /api/notes/:id
Projects:    GET/POST /api/projects, GET/PUT /api/projects/:id
Tasks:       GET/POST /api/projects/:id/tasks, GET/PUT/DEL per task
             PUT toggle, PUT meta, GET /api/tasks (cross-project)
Daily notes: GET/POST /api/daily, /api/daily/today, /api/daily/:date
Assets:      POST upload, GET serve
Search:      GET /api/search?q=
Git:         status, commit, push, fetch, log, diff, remote, conflicts
WebSocket:   /ws (real-time file change notifications)

The Future of Ironpad

Coming in v0.2.0

Task comments & activity log — date-stamped entries per task, with the latest comment shown as a summary in the task list
Recurring tasks on calendar — daily/weekly/monthly tasks expanded across the calendar grid

On the horizon (v0.3.x)

Calendar drag-and-drop rescheduling
Week and day calendar views
Sort task list by due date or priority
Improved overdue indicators

Longer term

Quick-add task from anywhere
Bulk task actions
Task templates
Cross-project tag filtering
Kanban board view
Backlinks between notes
Graph view of note connections
Export to PDF/HTML
Custom themes
Mobile-friendly responsive layout

What will NOT happen

Ironpad will stay local-first. No cloud sync service, no user accounts, no SaaS. If you want remote access, push your data folder to a Git remote. That's by design, not a missing feature.

Try It / Contribute

Ironpad is MIT licensed and open source.

Quick start:

Download from Releases
Run the executable
Your browser opens — start working

Or build from source:

git clone https://github.com/OlaProeis/ironPad.git
cd ironPad/backend && cargo run    # API server
cd ironPad/frontend && npm run dev # Dev server

The complete AI development workflow documentation is in docs/ai-workflow/ — including the PRD, method, tools, and lessons learned.

If you have ideas or find bugs, open an issue. PRs welcome.

From 200K to 1M: How Claude Opus 4.6 Changed My AI Development Workflow Overnight

Ola Prøis — Fri, 06 Feb 2026 00:15:11 +0000

A follow-up to The AI Development Workflow I Actually Use

I wrote about my AI development workflow a couple of weeks ago. Task Master for structured tasks, Context7 for current docs, handover documents between fresh chats, multiple AI perspectives before coding. That workflow shipped working software.

Today, a significant part of that workflow became optional.

Claude Opus 4.6 launched in Cursor on February 5th, 2026, with a 1 million token context window. I've been using Opus 4.5 with its 200K limit for months. The jump to 1M isn't an incremental improvement. It changes what's possible in a single conversation.

This is what happened when I tested it on a real project.

The Project: ironPad

ironPad is a local-first, file-based project management system I've been building with AI. Rust backend (Axum), Vue 3 frontend, markdown files as the database, Git integration for versioning. It's a real application, not a demo.

Tech stack:

Backend: Rust, Axum 0.8, Tokio, git2, notify (file watching)
Frontend: Vue 3, Vite, TypeScript, Pinia, Milkdown (WYSIWYG editor)
Data: Plain Markdown files with YAML frontmatter
Real-time: WebSocket sync between UI and filesystem

The codebase has around 80 files across backend and frontend. Not massive, but too large for 200K context.

The Old Way: 200K Context

With Opus 4.5 and 200K tokens, my workflow for this project looked like this:

Break big features into 3-5 tasks — because the AI can only hold a few files at once
Write handover documents between each chat — so the next session knows what happened
Carefully select which files to show — can't load everything, so I'd pick the 3-5 most relevant files
Repeat context-setting every session — paste the handover, re-explain the architecture, point to the right files

It worked. I shipped features. But there was some friction in the handover system.
The handover system was my solution to a constraint. A good solution, but still a workaround.

The New Way: 1M Context

Today I opened a fresh chat with Opus 4.6 and said: "Load the entire codebase into your context and analyze it."

That's it. No carefully selected files. No handover document. No context-setting preamble.

The AI proceeded to:

List the entire project structure — every directory, every file
Read every single source file — all Rust backend code, all Vue components, all stores, all configs, all documentation
Hold all of it simultaneously — ~80 files, thousands of lines of code, across two languages and multiple frameworks

Then I asked: "Are there any bugs or improvements we should make?"

What It Found

The AI identified 16 issues across the entire codebase. Not surface-level stuff. Deep, cross-file bugs that required understanding how multiple components interact:

Real bugs:

Auto-commit was silently broken — The background task checked a pending_changes flag, but nothing in the entire codebase ever set it to true. Auto-commits never fired. This is the kind of bug that requires reading main.rs, git.rs, and every route handler to spot. No single file reveals the problem.
JavaScript operator precedence bug — remote.value?.ahead ?? 0 > 0 evaluates 0 > 0 first due to precedence, making push/pull buttons always show wrong state.
Port binding race condition — The server checked if a port was available, dropped the connection, then tried to bind again. Another process could grab the port in between.
Own saves triggering "external edit" dialogs — Only one of eight write paths called mark_file_saved(). The file watcher would detect the app's own saves and pop up "File changed externally. Reload?" for task and project saves.

Architectural improvements:

Non-atomic writes risking data corruption in 3 route files
confirm() blocking the UI thread
WebSocket reconnect using fixed delay instead of exponential backoff
120 lines of duplicated task parsing logic
Missing CORS middleware
No path traversal validation on asset endpoints
Debug console.log left in production code

What It Fixed

I said: "Can you fix all of these please?"

In one session, the AI:

Rewrote the auto-commit system to simply try committing every 60 seconds (the existing commit_all() already handled "no changes" gracefully)
Fixed the port binding by returning the TcpListener directly instead of dropping and rebinding
Made atomic_write() public and switched all write paths to use it (which also solved the mark_file_saved() problem automatically)
Added frontmatter helper functions and deduplicated the task parsing code
Replaced the blocking confirm() with a non-blocking notification banner
Added CORS, path validation, exponential backoff
Fixed the operator precedence bug

Result: cargo check passes. Zero lint errors on the frontend. 14 issues fixed, 2 intentionally deferred (one was a large library migration, the other a minor constant duplication across files).

This was done in a single conversation. No handovers. No task splitting. No lost context.

What Actually Changed

Before: The Handover Tax

With 200K context, every bigger task or change had overhead, and we had to split it up into tasks.,

That overhead was the cost of the constraint. Good handover-systems made it manageable, but it was never free.

After: Direct Work

With 1M context, the full codebase audit looked like this:

Time for entire audit + fixes:
  Loading codebase:     ~2 min (AI reads all files)
  Analysis:             ~3 min (AI identifies 16 issues)
  Fixing all issues:    ~15 min (AI applies all fixes)
  Verification:         ~1 min (cargo check + lint)

  Total:                ~20 min
  Overhead:             ~0 min

The same work with 200K context would have been 5+ separate sessions, each needing its own handover, each limited to the files it could see at once. Some of the cross-file bugs (like the auto-commit issue) might never have been found because no single session would have had both main.rs and git.rs and all the route handlers in context simultaneously.

Does This Kill the Handover Workflow?

No. But it changes when you need it.

Still valuable:

Collaborating with someone who needs to understand what you've done
Documenting decisions for your future self
Projects larger than 1M tokens

No longer necessary:

Splitting a feature into artificial micro-tasks just to fit context
Writing handovers between closely related tasks
Carefully curating which files the AI can see
Re-explaining architecture every session

The handover system goes from "required for every task" to "useful for session boundaries." That's a big shift.

The Broader Pattern

What I've noticed building ironPad is that each AI capability jump doesn't just make existing tasks faster, it enables tasks that weren't practical before.

A full codebase audit wasn't practical at 200K. You could audit individual files, but finding bugs that span the entire system required a human to manually trace connections across files and then describe them to the AI. Now the AI just sees everything.

Cross-cutting refactors weren't practical at 200K. Changing how atomic writes work across 6 files, while also updating the file watcher integration, while also ensuring frontmatter helpers are available everywhere, that's a single coherent change when you can see all the files. At 200K, it's 3-4 sessions with risk of inconsistency between them.

Architecture-level reasoning wasn't practical at 200K. The auto-commit bug is a perfect example. The AutoCommitState was created in main.rs, the mark_changed() method existed in git.rs, but no route handler had access to it. Finding that requires understanding the full request flow from HTTP handler through service layer. That's trivial with the whole codebase loaded.

What's Next for ironPad

The project is open source, i released it 30 minutes ago on GitHub.

We're also going open method. Not just the code, but the process. How every feature was built with AI, what prompts worked, what didn't, how the workflow evolved from 200K to 1M context.

Because the tools keep getting better, but the process of using them well still matters. A 1M context window doesn't help if you don't know what to ask for.

Try It Yourself

The core of what worked today:

Load everything. Don't curate files. Let the AI see the whole picture.
Ask open questions first. "What's wrong?" before "Fix this specific thing." The AI found bugs I didn't know existed.
Let it work in batches. The AI fixed 14 issues in one session because it could see all the dependencies between them.
Verify mechanically. cargo check and lint tools confirm correctness faster than reading every line.
Keep your structured workflow for session boundaries. Handovers and PRDs still matter for smaller tasks and bigger projects. They just aren't needed between every micro-task anymore.

The context window went from a limitation you worked around to a space you fill with your entire project. That changes the game.

*ironPad is being built in the open. Follow the project on GitHub

https://github.com/OlaProeis/ironPad

Why I Deleted egui’s TextEdit and Wrote a Text Editor From Scratch

Ola Prøis — Fri, 30 Jan 2026 09:40:26 +0000

When I started Ferrite, I didn’t plan to write a text editor.

Ferrite began as a side project: a fast, native Markdown editor built with Rust and egui. I didn’t know Rust particularly well, I definitely didn’t know GUI programming, and I really didn’t want to reinvent things that already existed.

egui had a TextEdit widget. It worked. So I used it.

For a long time, that decision was absolutely the right one.

But in Ferrite v0.2.6, I deleted egui::TextEdit entirely and replaced it with a custom editor written from scratch.

This is the story of why.

The Editor That Was “Good Enough”

Ferrite shipped a lot of features on top of egui’s TextEdit:

WYSIWYG Markdown editing
Split view (raw + rendered)
Minimap
Syntax highlighting
Search and replace
Undo/redo

At the time, it felt almost magical that this worked at all.

I wrote previously about shipping Ferrite without really knowing Rust, and that was true here as well. egui’s abstraction let me move fast and focus on features, not editor internals.

And for small to medium files, everything was fine.

That’s the key part: until it wasn’t.

The Bug That Broke the Illusion

The issue that forced my hand was simple to describe and horrifying to observe.

Opening a 4MB text file caused Ferrite to use 1.8GB of RAM.

An 80MB file was effectively unusable.

This wasn’t a slow leak or a missing drop. It was architectural.

After a lot of profiling, the root causes became clear:

The entire document was being cloned every frame
Undo relied on full snapshots
Search paths allocated whole-document copies
Bracket matching scanned the entire buffer repeatedly
egui’s text model assumed “the whole text exists, every frame”

None of this is wrong for an immediate‑mode UI.

But it is fundamentally incompatible with large files.

At some point I had to admit something uncomfortable:

I wasn’t dealing with a bug anymore.\
I was dealing with the limits of the abstraction I chose.

Why You Can’t Patch Your Way Out of This

I tried to optimize my way out.

I really did.

I added guards. Thresholds. Debounces. Hashes. Special‑case logic for “large files”. I fixed one O(N) path only to discover another one hiding behind it.

But egui’s TextEdit makes some assumptions that are deeply baked in:

The full document is owned by the widget
Text is a String
Layout happens eagerly
Undo is snapshot‑based
Rendering isn’t viewport‑aware

Those assumptions are totally reasonable for UI text fields.

They are not reasonable for a code editor.

At some point, optimizations stop being improvements and start being denial.

The Moment the Plan Changed

Rewriting the editor wasn’t originally an impulsive decision.

From early on, I knew there were things I eventually wanted that egui’s TextEdit simply wasn’t built for. Features like proper code folding, reliable sync scrolling, and deeper editor–preview integration were already pushing against its limits.

Because of that, a custom editor had been part of the roadmap for v0.3.0. It was a “someday” project, something to tackle once the surrounding features were stable.

Then the large‑file issue landed.

Opening a 4MB file using gigabytes of memory wasn’t just inconvenient; it was a hard failure. At that point, the rewrite stopped being a future improvement and became an immediate requirement.

The question was no longer if the editor needed to be replaced, but when.

So I moved the plan forward.

What was meant to be a v0.3.0 rewrite became the core of v0.2.6.

It was still intimidating, text editors are iceberg problems, but postponing it would have meant shipping an editor that couldn’t scale or be trusted.

So I did the thing earlier than planned.

I deleted the editor and started over.

FerriteEditor: What Changed Architecturally

The new editor, FerriteEditor, is built around a few core ideas.

1. Rope‑based Text Storage

Instead of storing text as a String, Ferrite uses the ropey crate.

This gives:

O(log n) inserts and deletes
Cheap slicing
Predictable memory usage

Large files stop being special cases and start being normal input.

2. Virtual Scrolling

FerriteEditor only renders what you can see.

Not “most of the document”. Not “everything and hope it’s fine”.

Just:

Visible lines
Plus a small buffer

This single change unlocked editing 100MB+ files smoothly.

3. Viewport‑Aware Everything

Operations that used to scan the entire document are now windowed:

Bracket matching looks at ~200 lines around the cursor
Syntax highlighting is per‑line, per‑viewport
Search highlights are capped to what’s visible

If it’s off‑screen, it doesn’t matter right now.

4. Operation‑Based Undo

Undo is no longer “clone the document”.

Instead, edits are stored as operations and grouped over time (500ms).

For large files:

Undo depth is reduced
Memory stays bounded
Editing remains responsive

5. Caching Where It Matters

Text layout is expensive.

Ferrite uses an LRU cache for rendered lines (egui galleys), so scrolling doesn’t recreate text every frame.

The Numbers That Actually Matter

Here’s what changed in practice:

Opening a 4MB file went from using around 1.8GB of RAM to roughly 80MB.
Files around 80MB, which were previously unusable, now open and edit smoothly.
Bracket matching, which used to scan the entire document every frame, now operates on a small window of roughly 20KB around the cursor.
Undo/redo no longer relies on full document snapshots, but on a compact, operation‑based history.

This wasn’t a micro‑optimization release.

It was a survival release.

What Nearly Broke Along the Way

Some things were far harder than expected:

IME support\ Handling composition text correctly is non‑optional if you want global users.
Word wrap + cursor math\ Visual rows vs logical lines is where many editors quietly fail.
UTF‑8 offsets\ Byte offsets and character offsets must never be confused. I confused them. More than once.
Scrolling accuracy\ “Scroll to line 3000” sounds easy. It is not.

None of these problems are visible in screenshots.

All of them are visible to users.

When You Should Not Rewrite Your Editor

This is important.

You should not rewrite your editor because:

It feels “cleaner”
You want control
Someone on the internet told you to

I only did this because:

The old path was fundamentally blocked
Users were hitting real limits
Features like multi‑cursor and large‑file support required it

Rewrites are expensive. This one was too.

What This Unlocks Next

With the new editor in place, Ferrite can now do things that were previously impossible or fragile:

Stable multi‑cursor editing
Reliable large‑file workflows
Better editor‑preview synchronization
Predictable memory usage
Long‑term maintainability

The editor is no longer the thing holding the project back.

Final Thoughts

egui’s TextEdit wasn’t a mistake.

It let Ferrite exist.

But software grows, and sometimes the abstractions that helped you move fast become the ones you need to leave behind.

Writing a text editor from scratch was the hardest part of Ferrite so far.

It was also the most important.

If you’ve been following Ferrite since the early days: thank you.\
And if you’re building something similar: I hope this saves you a few wrong turns.

https://getferrite.dev

Beyond Open Source: Why AI-Assisted Projects Need Open Method

Ola Prøis — Sat, 24 Jan 2026 13:03:08 +0000

A few weeks ago, someone on Hacker News called my project "open weights."

I'd just shared Ferrite, a markdown editor with 100% AI-generated Rust code. The source was on GitHub, MIT licensed, the whole deal. But this commenter argued that without sharing the prompts and process that created it, I was essentially doing the AI equivalent of releasing model weights without the training data. The code was visible, but the inputs weren't.

At first I pushed back. The code compiles. It runs. Anyone can fork it, modify it, contribute. Isn't that what open source means?

But the comment stuck with me. And the more I thought about it, the more I realized they had a point.

The gap in "open source"

Open source was designed for a world where humans wrote code. The implicit assumption was always: if you can read the code, you can understand how it was made. A skilled developer could look at a function and reverse-engineer the thinking behind it. The code was the process, more or less.

(This is idealized, of course. Plenty of open source projects have opaque decision-making - closed maintainer discussions, undocumented tribal knowledge. But the potential for transparency was there. The code contained enough signal to reconstruct intent.)

AI-assisted development breaks that assumption.

When Claude writes a function based on my prompt, the code tells you what it does, but not why it exists in that form. Was this the first attempt or the fifteenth? What constraints did I give? What did I reject along the way? What context did the AI have about the rest of the codebase?

The code is a snapshot. The process is invisible.

This isn't necessarily a problem for using the software. But it's a problem if you want to learn from it, build on it, or understand the decisions behind it. Traditional open source invited you into the workshop. AI-assisted open source shows you the finished product and locks the door.

What would "open method" look like?

After that HN comment, I went back and documented everything. The actual workflow is now public: how I use multiple AIs for ideation, how I structure Product Requirements Documents, how I break tasks into subtasks, how I write handover prompts between sessions, how I maintain an AI context file so the model knows the codebase patterns.

The full thing is in the repo under docs/ai-workflow/. It's not polished. Some of it is rough notes. But it's real.

And here's what I learned: sharing this stuff is harder than sharing code.

Code has conventions. Linters. Tests. There's a shared understanding of what "good" looks like. But AI prompts? There's no standard format. No agreed-upon level of detail. Do I share every failed attempt? Just the successful ones? The iterative refinements?

I landed on sharing:

The workflow documentation (how I actually work with AI, step by step)
Historical PRDs (the requirements documents I feed to the AI)
Handover prompts (what I tell the AI at the start of each session)
Task breakdowns (how features get decomposed into implementable chunks)

Is this enough? I don't know. But it's more than just the code.

Why this matters beyond my project

I keep seeing AI-assisted projects pop up on GitHub. Some are explicit about it, some aren't. And I think we're heading toward a world where a significant chunk of open source code will be AI-generated or AI-assisted.

If that's true, we need to figure out what transparency means in this context.

The conversation is already starting. Mozilla.ai recently argued that "without an AI Coding policy that promotes transparency alongside innovation, Open Source codebases are going to struggle." They've implemented PR templates asking contributors to disclose their level of AI usage. Coder has published formal guidelines requiring disclosure when AI is the primary author, plus verification evidence that the code actually works.

This is good progress. But disclosure - saying "AI wrote this" - is different from method - sharing how it was written. Both matter, but they serve different purposes. Disclosure helps reviewers calibrate their trust. Method helps others learn, replicate, and build on your approach.

The traditional open source licenses don't cover either. MIT and GPL talk about distribution, modification, attribution. They don't say anything about documenting your process. There's no legal requirement to share your prompts.

But there's a difference between legal requirements and community norms. Open source thrived because of a culture of sharing knowledge, not just code. READMEs, contribution guides, architectural decision records, commit messages that explain why - all of this is technically optional but practically essential.

I'm arguing we need to extend that culture to AI-assisted development. Not as a legal requirement, but as a community expectation. If you're releasing AI-generated code, consider releasing the method too.

There's also a selfish reason to do this: open method protects the author. If your code has quirks or unconventional patterns, the method shows why. It proves you guided the AI - that you made architectural decisions, rejected bad suggestions, iterated toward something intentional. Without it, people might assume you just pasted output without thinking. With it, you're demonstrating the craft behind the code.

What to call it

"Open weights" doesn't quite fit. That term has a specific meaning in ML - releasing model parameters without training data or code. It's about what you're withholding, not what you're sharing.

"Reproducible development" is closer, but sounds academic. And true reproducibility might be impossible anyway - you can't perfectly reproduce an AI interaction. Run the same prompt twice and you'll get different output. This isn't about deterministic reproduction like a build script. It's about conceptual reproduction - understanding the approach well enough to build something similar, or to pick up where someone left off.

I've been thinking of it as "open method" - sharing not just the code, but the process that created it. The prompts, the workflow, the decisions. Enough that someone else could understand not just what you built, but how you built it.

This parallels how academia handles research. "Open science" doesn't just mean publishing results. It means sharing data, methodology, analysis code. A paper without methodology gets rejected - you can't just say "trust me, the results are valid." Yet in software, we accept the binary without the lab notes all the time. We're used to it because the code was the lab notes. With AI-assisted development, that's no longer true.

Software development with AI needs the same shift academia made: recognize that outputs alone aren't enough.

Practical suggestions

If you're releasing AI-assisted code and want to practice "open method":

Document your workflow. Not a polished tutorial, just an honest description of how you actually work. What tools? What prompts? What iteration looks like?

Save your PRDs. If you write requirements documents for the AI, keep them. They're the closest thing to "training data" for your specific project.

Keep handover context. Whatever you tell the AI at the start of sessions - system prompts, context files, architectural notes - consider making it available.

Note significant decisions. When you rejected an AI suggestion or chose between approaches, a quick note about why helps future readers.

None of this needs to be perfect. The bar should be "useful to someone trying to understand how this was built," not "publishable academic paper."

The tradeoffs

I should acknowledge: there are reasons not to share everything.

Prompts can reveal proprietary thinking - your secret sauce for getting good results. Sharing failed iterations might expose security vulnerabilities or embarrassing dead ends. Some companies have legitimate IP concerns about their AI workflows.

This isn't all-or-nothing. You can share your general approach without revealing every prompt. You can document the workflow without exposing sensitive business logic. The goal is enough transparency to be useful, not a livestream of your entire development process.

But I'd argue the default should shift toward openness, especially for open source projects. If you're already sharing the code, sharing the method is a natural extension.

What's still missing

I don't think sharing my workflow documentation solves this problem. It's one example. What we actually need are conventions - the way we have conventions for READMEs, for commit messages, for contribution guides.

What should an "open method" disclosure look like? Is there a standard format? Should it live in the repo, in the PR, somewhere else? How much detail is enough - the final working prompt, or the fifteen failed attempts before it?

We also lack tooling. We have git for code, but we don't have good version control for chat sessions. My "handover prompts" are markdown files I manually maintain. That works, but it's friction. The first tool that makes capturing AI development context as easy as git commit will unlock a lot more openness.

Here's a concrete starting point: what if GitHub repos had an AI_METHOD.md alongside README.md and CONTRIBUTING.md? A standard template that answers: What AI tools were used? What's the general workflow? Where can I find example prompts or PRDs? It's not a perfect solution, but it's a convention - and conventions are how communities coordinate.

I don't have all the answers yet. But I think starting to share, even imperfectly, is how we'll figure it out. The early open source movement didn't have perfect conventions either. They emerged through practice, through people trying things and seeing what worked.

If AI-assisted development is going to become normal, we need to normalize showing our work. Not because there's anything wrong with using AI, but because transparency builds trust, enables learning, and strengthens the open source ecosystem we all benefit from.

The code is the output. The method is the craft. Both can be open.

I'm curious what you think. If you were reviewing an AI-assisted PR, what documentation would actually help you trust it? What would you want to see in an "open method" disclosure? Let's figure this out together in the comments.

I wrote more about the specific workflow in The AI Development Workflow I Actually Use, and the story of building Ferrite in I shipped an 800-star Markdown editor without knowing Rust. The full workflow documentation is in the Ferrite repo.

Beyond Open Source: Why AI-Assisted Projects Need Open Method

Ola Prøis — Sat, 24 Jan 2026 13:03:07 +0000

A few weeks ago, someone on Hacker News called my project "open weights."

At first I pushed back. The code compiles. It runs. Anyone can fork it, modify it, contribute. Isn't that what open source means?

But the comment stuck with me. And the more I thought about it, the more I realized they had a point.

The gap in "open source"

AI-assisted development breaks that assumption.

The code is a snapshot. The process is invisible.

What would "open method" look like?

The full thing is in the repo under docs/ai-workflow/. It's not polished. Some of it is rough notes. But it's real.

And here's what I learned: sharing this stuff is harder than sharing code.

I landed on sharing:

The workflow documentation (how I actually work with AI, step by step)
Historical PRDs (the requirements documents I feed to the AI)
Handover prompts (what I tell the AI at the start of each session)
Task breakdowns (how features get decomposed into implementable chunks)

Is this enough? I don't know. But it's more than just the code.

Why this matters beyond my project

If that's true, we need to figure out what transparency means in this context.

What to call it

"Open weights" doesn't quite fit. That term has a specific meaning in ML - releasing model parameters without training data or code. It's about what you're withholding, not what you're sharing.

Software development with AI needs the same shift academia made: recognize that outputs alone aren't enough.

Practical suggestions

If you're releasing AI-assisted code and want to practice "open method":

Document your workflow. Not a polished tutorial, just an honest description of how you actually work. What tools? What prompts? What iteration looks like?

Save your PRDs. If you write requirements documents for the AI, keep them. They're the closest thing to "training data" for your specific project.

Keep handover context. Whatever you tell the AI at the start of sessions - system prompts, context files, architectural notes - consider making it available.

Note significant decisions. When you rejected an AI suggestion or chose between approaches, a quick note about why helps future readers.

None of this needs to be perfect. The bar should be "useful to someone trying to understand how this was built," not "publishable academic paper."

The tradeoffs

I should acknowledge: there are reasons not to share everything.

But I'd argue the default should shift toward openness, especially for open source projects. If you're already sharing the code, sharing the method is a natural extension.

What's still missing

The code is the output. The method is the craft. Both can be open.