Gemini CLI と Jules：2026 年 3 月の私のスタック

開発ワークフローは非常に個人的なものです。各 AI や LLM コーディングツールが進化していく中で、私は何が入りやすいのかを試している次第です。これは私の個人プロジェクトのためですので、自分が実際に楽しんでいるかは重要です。最大限のエフィシエンスではありません。また、私の働き方自体を更新することでもあります。狂信的な hype（熱気）には免疫がないため、他の Markdown ファイルが私の人生を変えるとは息を吐くような概要を読むのに耐える必要があります。 また、他の人がワークフロー全体を自動化し、数多のエージェントが「マッド・マックス」MMORPG を構築していることについて話されるのを見る際は少し畏敬の念を感じてしまいます。そこで、私のより漸進的な進行を共有することにしました。それが他の人のために刺激になるかもしれません。 私は「すべてが非常に速く変化しているため、始められる希望がない」と感じて揺れ動きますが、何か自分の生活を本当に容易にし、少し楽しいものにするものを見つけることもあります。 完全な開示：これらは主に Google のツールです。そこで勤務しており、一般的には私達の物を使っています。我々 ChromeOS 内部的な Linux VM を私の主開発環境としています。なぜ？それは素晴らしい質問です。 しかし、私が現在の組み合わせで正しいノットを打ったことは明らかです。退屈なスケーフolding（足場作り）を取り扱い、私が考えないであろうエッジケースを強調し、実際の実装を可読性のある状態に保つのです。私のスタックの tl;dr（要約）は以下の通りです： プルリクエストにおける自動化されたテストと静的解析 プルリクエストにおける自動化された Firebase Hosting のデプロイ アクティブなペアプログラミングのための Gemini CLI バックグラウンドでの提案のための Jules すべてのコードと設定は fractious GitHub リポジトリに確認できます。 tl;dr の tl;dr：レビューを容易にしてください。それは、成熟したチームプロジェクトと比較して、我々が期待する多くのインフラを追加することを意味します。長期的には、最終的に'90 年代のように Extreme Programming を行うかもしれません。その超ワイドジーンズが再び戻ってきたため、何事も可能です。 さて、私の（フロステッドではない）私の環境向けヒントに入ります。 私がどのソーシャルメディアでもあなたに追いかけているなら、あなたは私が私の Mandelbrot フラクタルエクスプローラー Fractious から不比例数のスクリーンショットを投稿していることを知っています。私は作成したアップデートについての適切なブログ記事を書かなければなりませんが、ここで関連するのは「前回の反復は『完了』しましたが、ズーム深さの制限に不満を感じていた」ことです。そして Ingvar は BigDecimal.js を見ることを提案しました。私はそれをすぐにやらず、代わりに Gemini に私が何ができるか尋ねました。そこから私たちは、完全な WebGL シェーダーベースの実装から Wasm での参照計算と WebGPU での出力描画への移行を成功裡に行いました。 ここでの甘みスポットは：私が何を知りたいか、良いアーキテクチャがどのようなものであったかを知っていたが、そこに行くための正確な構文やステップは知っていないことでした。 私は通常、3 つのターミナルタブを開いています：1 つはビルド/開発サーバーで、もう 1 つは私の独自の Git コマンドで、そして 1 つは Gemini CLI です。その後、私は探索的な作業を行うために慣れたコーディングセットアップを持ち、Gemini に何か行わしたい時にそれを切り替えるための別の VS Code インスタンスを開いています。この分離により、私は探索的な作業をするための私の熟悉的なコーディングセットアップを維持し、その後、Gemini に何かをやらせるために切り替えることができます。 私は VS Code の統合や Antigravity などを試しましたが、少なくとも個人的には、現時点ではそれが私を邪魔することがよくあります。私が打ち込みつつある最中に AI が飛び込む傾向があるため、私の思考の道筋を脱線させ、それを加速させる傾向があります。これはまた、私がどちらか一つのモードで長く滞在する傾向をもたらします。つまり、私は自分自身で何かを行うか、Gemini に作業させているかをレビューしています。私は AI が私の alongside と一緒に協力する混成モードで働くことを実際には行いません。 Fractious におけるその最大部分は Rust ベースの Wasm モジュールの実装でした。私は Rust も、そのツールエコシステムも知りません。しかし、Gemini により、私が何かを実行できるものをすぐに Bootstrap することができました。それは私にとって、学ぶと実行するのがはるかに容易です。

Development workflow is a very personal thing. As the various AI and LLM coding tools evolve, I've been trying different things to see what fits with how I want to code. This is for my personal projects, so it's important to me that I'm actually enjoying myself - it's not necessarily about maximum efficiency. It's also about updating how I work. I'm allergic to rabid hype, so getting into tools has required resisting that eye-twitch while I read a breathless summary about how another Markdown file is going to change my life. Also, I do find it a little bit intimidating when you see other people talking about how they've automated their entire workflow and have hordes of agents building a Mad Max MMORPG. So, I thought I'd share my more incremental progress in case it's encouraging for anyone else. I do oscillate between feeling that everything is changing so quickly that I've got no hope of getting started and then finding something that really does make my life easier and even a bit more delightful. Full disclosure: these are mostly Google tools. I work there, I generally try to use our stuff. I even use the Linux VM inside ChromeOS as my primary development environment. Why? That's a great question. However, I've found a current combination that hits the right notes for me. It takes care of tedious scaffolding, highlights edge cases I wouldn't have considered, and keeps the actual implementation legible. Here's the tl;dr of my stack: automated tests and static analysis on pull requests automated Firebase Hosting deploys on pull requests Gemini CLI for active pair work Jules for background suggestions You can see all the code and configuration in the fractious GitHub repo. The tl;dr of the tl;dr: make reviews easy. That means adding more of the infrastructure I'd expect on a mature team project versus personal hobby toys. Long-term, maybe I'll finally do Extreme Programming like it's the '90s again. Those ultra-wide jeans are back in again, so anything is possible. Anyway, let's get into my (non-frosted) tips for my own environment. If you follow me on any social media, you know I post a disproportionate number of screenshots from my Mandelbrot fractal explorer, Fractious. I need to write a proper blog post on the updates I've made, but the relevant bit here is that I'd "finished" the previous iteration but was frustrated by the limit to the zoom depth. Then Ingvar suggested looking at BigDecimal.js, which I promptly did not do, going straight to asking Gemini what I could do instead. From there we successfully migrated from an entirely WebGL shader-based implementation to doing the reference calculation in Wasm and rendering the output with WebGPU. The sweet spot here was: I knew what I wanted, I knew what a good architecture looked like, but I didn't know the exact syntax or steps to get there. I tend to have three terminal tabs open: one running the build/dev server, one for my own Git commands, and one for Gemini CLI. I then have a separate VS Code instance open where I'm either editing or checking diffs. This separation means I have my familiar coding setup for doing the exploratory stuff and then I switch over to Gemini when there's something I want it to do. I've tried the VS Code integration, Antigravity, etc. and at least personally, and at the moment, it more often gets in my way than helps me. The AI jumping in all the time while I'm in the middle of typing tends to derail my train of thought rather than speed it up. This also means I tend towards longer periods in one mode or another. As in, I'm either doing things myself or I'm asking Gemini to work and then I'm reviewing. I don't really work in a mixed mode where the AI is collaborating alongside me. The biggest part of that in Fractious was implementing the Rust-based Wasm module. I don't know Rust and I don't know the tooling ecosystem. However, with Gemini I could get something that worked bootstrapped pretty quickly. It's much easier for me to learn and expand on a working example versus starting from a blank canvas. I also used Gemini to untangle the myriad of config files required for these tools. I maintain that YAML ain't a human-readable format (looking at you, GitHub Actions), but thankfully, it no longer has to be human-writable at least. I integrated a few different tools here: general linting with ESLint complexity and other checks with the SonarJS plugin for ESLint security checks with, unsurprisingly, eslint-plugin-security dependency checks with Dependency cruiser This pipeline catches dead code, unnecessarily nested if statements, and "cognitive complexity" (which I think is mostly cyclomatic complexity with a fuzzier name), along with a whole bunch more. Again, this is all standard infrastructure for a work project accepting contributions. In this case, the contributor just happens to be a robot. I also dropped in a basic unit test harness with vitest. Yes, I'm a bad developer—I should have written the tests first. Not very Extreme Programming of me. However, having the harness in place means I can incrementally drop in tests (or ask the agent to do it) one by one. The crucial part is that these checks run on a GitHub Action against every pull request and push to main. I'm using Firebase Hosting, which features a GitHub Actions integration to deploy to a preview channel on every PR. This is vital because it creates a workflow where I can review, test, and approve incoming changes directly from my phone. This is nice because now it turns into an activity I can do wherever I am rather than needing to grab my laptop. The pull request comes in. The automatic checks and tests give me a base level of confidence in the contribution. I go play with the deployed app to make sure it works the way I expected. Then I peruse the diff to see if I agree with what's coming in. If I do, I just merge - if not then it waits until I'm at my laptop. As a bonus, reviewing PRs on my phone has taken a meaningful bite out of my reflexive doomscrolling. So, "where are these AI contributions coming from?" I hear my rare reader ask. Jules is a hosted agent that runs a bit more autonomously. It has a Suggestions feature and scheduled tasks that go through the codebase and look for issues, improvements, changes, etc. I go through these suggestions in the web interface and tell it to get started on the ones I'm interested in and then a bit later I get a pull request. The provided scheduled agents are quite helpful, with templates for performance, security, and UI improvements. It's useful looking through the prompts provided to see what those aspects are. For example, the performance agent includes: "identify and implement ONE small performance improvement" "never sacrifice code readability for micro-optimizations" "measure the impact, add benchmark comments" So far this has resulted in pull requests that really are just changing one thing across 1-4 files. The performance ones often do come with a benchmark script showing the improvement. The UI improvement agent has been adding ARIA rules which do help with my unhealthy predilection for using emojis for labels and buttons. There are still quirks to manage. I avoid triggering multiple suggestions that touch the same code simultaneously to dodge merge conflicts. Occasionally, an agent will persistently re-suggest a change I've already rejected, just formatted slightly differently. I've also watched the performance agent optimize a block of code, only for the security agent to swing by later and revert it to the old, more robust implementation. Still, it's been pleasing getting a nice little list of improvements each morning. With the tests and preview deploys in place, there's very little effort or spin up time for me to get into looking at them. The scope of each change isn't overwhelming either - so I really can just pick up my phone and make a little progress. I don't know if this is the workflow I'll have next month. Things do change quite quickly and I'm also learning and adapting as I go. Right now, this pattern of having the agent as a local partner or remote contributor is working quite well for me. However, as I start resuscitating those Behavior-Driven Development (BDD) skills I can see myself getting more comfortable with a hands-off approach when I have enough confidence in the test suite. That said, I'm an inherent tinkerer. I like to know how the app is working under the hood and on personal projects, playing with the code is the entire point.