Nicholai’s Blog

For years, I kept both Google Chrome and Microsoft Edge in my workflow. Chrome fit naturally with my Google services, while Edge offered Microsoft integrations. Over time, the benefits I actually used stopped justifying the complexity of keeping both as daily browsers.

This is a personal workflow decision, not a benchmark or a claim that either browser is bad. Both remain useful products. My priorities have shifted toward predictable tools, fewer distractions, and an environment I can understand and maintain.

When the integration stopped earning its place

One attraction of Google’s AI ecosystem was the possibility of moving between documents, spreadsheets, and practical automation without constantly rebuilding context. I wanted help that could carry a task through to a verifiable result.

In one session lasting more than an hour, the assistant reported no tool calls and no successful actions. I came away without the work I had expected. That experience mattered to my decision, but it does not establish that Google removed those capabilities for everyone.

Chrome, the Gemini app, Gemini CLI, and Workspace integrations should not be treated as one product. Availability and behavior can differ by product, account, permissions, and configuration. A failed assistant session is a reason to inspect that setup—not proof that the browser itself caused the failure.

For automation, I also draw a firm boundary between ordinary configuration and secrets. A spreadsheet may be useful for non-sensitive settings, but I would not use it as a staging area for passwords or production API keys. Credentials belong in a dedicated secret manager with controlled access.

Why I stopped choosing a browser for its AI sidebar

Chrome’s compatibility and extensions still have value. Edge’s integrations may be valuable to someone who uses them every day. In my case, an integrated assistant only earns its space when it reliably reduces the steps between a request and a finished task.

I now choose my everyday browser separately from my AI tools. An assistant’s name in a sidebar is less important to me than whether it can access the right tools, explain its limits, and show what it changed.

Where Brave and Opera fit

Brave has become my preferred everyday browser. I like its approach to blocking unwanted content through Brave Shields and the way it fits my browsing habits. Opera remains an option I value for its sidebar and workspaces.

These are preferences, not evidence that either browser is universally faster or more private. Extensions, settings, open tabs, hardware, and the sites being visited all affect the result. I would compare the same workload before claiming a measurable improvement.

Changing browser brands also does not necessarily mean changing the underlying engine. For example, Brave’s desktop browser is built on Chromium, and Edge shares that foundation with Chrome. Product features and defaults can differ even when browsers share a substantial technical foundation.

My AI tools have different jobs

I get more value from choosing a tool for a specific task than from expecting one assistant to do everything:

• Copilot: I turn to it for design discussion, feature brainstorming, planning, and refining documentation.
• ChatGPT and Codex: I use them for code review, debugging, refactoring, and automation. Repository, deployment, or infrastructure work still depends on the tools and permissions available in that session.
• Meta AI: I use it for another perspective and quick idea generation.

Those roles describe my habits, not a ranking of which product is objectively best. For any assistant, I care about observable results: a reviewed diff, a passing test, a deployment I can open, or an explanation of what remains blocked.

Measure system health before blaming the browser

A slow machine can have several contributing factors: too many startup applications, unnecessary extensions, background work, or a process whose memory use keeps growing. High memory use in one snapshot does not, by itself, prove a leak. A scheduled task or network connection is not automatically suspicious either.

My starting point is a read-only inventory. The following PowerShell commands inspect Windows processes, startup entries, scheduled tasks, connections, and executable signatures. Some information may be inaccessible without additional permissions; the script reports signature-inspection failures instead of silently hiding them.

# Read-only Windows audit. Nothing is removed or disabled.
# Working set is a snapshot, not a measurement of total system impact.
Get-Process |
  Sort-Object WorkingSet64 -Descending |
  Select-Object -First 20 Name, Id, @{
    Name = 'WorkingSetGB'
    Expression = { [math]::Round($_.WorkingSet64 / 1GB, 2) }
  }

# Review startup entries and both ready and running tasks.
Get-CimInstance Win32_StartupCommand |
  Select-Object Name, Command, Location, User

Get-ScheduledTask |
  Where-Object { $_.State -in 'Ready', 'Running' } |
  Select-Object TaskPath, TaskName, State

# OwningProcess lets you correlate connections with process IDs.
Get-NetTCPConnection |
  Select-Object LocalAddress, LocalPort, RemoteAddress,
    RemotePort, State, OwningProcess

# Review signature status; unsigned does not automatically mean unsafe.
Get-Process | ForEach-Object {
  $process = $_
  try {
    $path = $process.Path
    if (-not $path) { throw 'Executable path unavailable' }
    $signature = Get-AuthenticodeSignature -LiteralPath $path -ErrorAction Stop
    if ($signature.Status -ne 'Valid') {
      [PSCustomObject]@{
        Process = $process.ProcessName
        Id = $process.Id
        Status = $signature.Status
        Path = $path
      }
    }
  } catch {
    Write-Warning ("Could not inspect {0} ({1}): {2}" -f
      $process.ProcessName, $process.Id, $_.Exception.Message)
  }
}

Review the results in context. A valid signature is not a guarantee that software is harmless, and an unsigned file is not proof of malware. The command reports signature information, as described in Microsoft’s Get-AuthenticodeSignature documentation. Keep paths, account names, and connection details private when sharing audit output.

Remove software deliberately

Before removing a browser, check that bookmarks, passwords, and any profiles you need are backed up or available elsewhere. Google documents uninstalling Chrome through the operating system’s application settings in its Chrome removal guide.

On Windows, identify the installed package before asking WinGet to remove it. The second command below performs an uninstall; it is separate from the read-only audit.

winget list --id Google.Chrome --exact
winget uninstall --id Google.Chrome --exact

The explicit ID and exact-match flag help select the intended package. See the WinGet uninstall reference. I would use supported removal options for Edge where available, rather than scripts that force-delete browser components.

For an npm-installed Gemini CLI, first check the global packages in the environment where you installed it:

npm list -g --depth=0
# Only if @google/gemini-cli is installed globally with npm:
npm uninstall -g @google/gemini-cli

Use the matching package manager for other installation methods; the official installation guide describes the supported approaches. Uninstalling a CLI is a separate decision from deleting its settings. I would inspect and back up the ~/.gemini directory before removing any data; Gemini’s settings documentation identifies the configuration stored there.

A simpler workflow, on my terms

I am not declaring the browser wars over. Browsers still differ in accessibility, enterprise management, privacy settings, compatibility, and everyday usability. Those differences deserve evaluation against real needs.

For me, keeping fewer daily browsers and choosing AI tools independently makes the workflow easier to manage. I am aiming for less clutter and more completed work. If another tool becomes useful again, I can reconsider it. Software should earn its place through what it helps me do.