DEV Community: Martzcode

I Built a Whole Desktop App Because I Couldn't Pick a Gacha Banner

Martzcode — Wed, 21 Oct 2026 15:51:53 +0000

It was 1:47 AM.

I had 42 pulls, a credit card that was dangerously within reach, and two banners staring back at me. On the left, the character everyone said was meta. On the right, the one I actually liked. Both were limited. Both would disappear in a few days.

I did what any reasonable person does in that situation: I opened a coin flip website.

Then I closed it, because a cookie banner asked me to accept 847 partners.

Then I opened another one. It wanted an account.

Then I opened a random number generator that looked like it had been designed in 2003 and had a 3-second ad before showing me a number.

And somewhere between the third pop-up and the fourth "accept all", I thought:

Why is the simplest decision in the world the hardest thing to do on a computer?

That night, I didn't pull. I opened my code editor instead.

The tiny problem behind the big project

The gacha dilemma is silly. I know that. But it's also the perfect example of a much more common problem.

We hesitate constantly:

Which of these two apartments should I take?
Which candidate do we hire?
Which feature do we build next?
Which restaurant do we pick when nobody wants to decide?

And for all of these, we either overthink for 40 minutes, or we ask a friend who cares way less than we do.

I didn't want to build "a random generator". I wanted to build the thing I wished existed at 1:47 AM: something that opens instantly, does one job perfectly, and gets out of the way.

No account. No ads. No cookie banner. No loading spinner. No internet.

Just a decision.

So I built Capricio

Capricio is a small desktop app for Windows, made with Tauri 2, Angular 22 and Rust.

It does four things, and it tries very hard to do them well:

Coin flip: with custom labels, so you can flip between "Banner A" and "Banner B" instead of Heads and Tails.
Random number: min/max, optional no-repeat, instant result.
List draw: paste a list, pick one or several winners, with or without replacement.
Weighted pros & cons: list your arguments, give them a weight, and get a verdict with a score and a percentage gap.

The whole thing is designed around one rule: a decision should take less than three clicks.

There's a short animation, a "Play again" button, full keyboard navigation, four languages (English, French, German, Spanish), light/dark/system themes, and a local history so you can look back at what you decided, and whether you actually followed through.

And here's the part I'm most proud of: it's 100% offline.

No account. No telemetry. No tracking. No ads. Your arguments, your lists, your history, they never leave your machine. Not because of a privacy policy, but because there is no server to send them to.

What building it taught me

I thought this would be a weekend project. It wasn't.

1. Rust makes "fast" feel effortless

All the sensitive logic lives in Rust: the random draws, the weighted scoring, the bias detection when only one side of a pros/cons list is filled. Angular only renders. That separation is not just architectural purity, it's what makes the app feel instant.

Cold start is under 1.5 seconds. The installer is under 15 MB (without the system WebView). Idle memory stays under 50 MB.

When you're half-asleep trying to make a decision, those numbers are not specs. They're the difference between using the app and closing it.

2. The hardest part of a decision tool is trust

If I'm going to let an app decide something for me, even something small, I need to trust it. So I unit-tested the scoring and random modules heavily. Not because it's a checklist, but because a decision helper that is subtly wrong is worse than no decision helper at all.

3. Constraints are a feature

I removed things. A lot of things. No cloud sync in V1. No export. No social features. No "AI-powered decision engine".

Every feature I added was a reason for someone to hesitate before making a decision, which is exactly the opposite of the goal.

4. The pause is the product

This is the one that surprised me most.

People don't actually want an app to decide for them. They want permission to stop circling. The coin flip doesn't choose for you, it shows you how you feel about the result.

Capricio is not an oracle. It's a pause button with a clean interface.

The moment it became real

A few days after publishing it, a friend texted me a screenshot.

He had used the pros & cons screen to decide whether to accept a job offer. He told me he already knew the answer, he just needed to see it written down, weighted, and laid out in front of him.

That's when it stopped being "the app I built because of a gacha banner" and became something I actually want to maintain.

Try it

Capricio is free, open source, and available now.

Microsoft Store: Download Capricio
GitHub: Martzcode/Capricio

It's built for Windows 10/11 today, with a cross-platform architecture underneath (macOS and Linux builds are possible).

If you try it, two small favors

Star the repo on GitHub. It takes two seconds, and for a solo open-source project, it genuinely helps more than you'd think, it's often how other developers discover the project.
Leave a rating on the Microsoft Store if the app is useful to you. Ratings are the main signal that tells new users "this is legit, and it's maintained." If something's missing or broken, tell me in the review or open an issue, I read everything.

And if you have a better idea for the next feature, open an issue. I built this because I couldn't decide between two banners. I'd love to hear what you can't decide between.

Final thought

We spend so much energy trying to optimize decisions, and so little energy noticing that most of them don't need optimizing. They need a nudge.

So here's my nudge to you: next time you're stuck between two options, don't open fifteen tabs. Flip a coin. Notice your reaction to the result.

You'll probably have your answer before the animation even ends.

That's how Capricio was born. Not from a product strategy, but from a very tired developer, a gacha banner, and a refusal to accept one more cookie pop-up.

"What I Wish I Knew About GitHub (and Especially GitHub Actions)"

Martzcode — Wed, 30 Sep 2026 13:33:29 +0000

When I started using GitHub, I treated it as a place to store code. Years later, I realized it's also a build server, a release manager, a deployment platform, and an automation engine, all included in the same repo.

This is the article I wish I had read at the beginning. First, a quick tour of the commands worth knowing. Then the main event: GitHub Actions and everything you can automate with it.

Part 1: GitHub essentials (the short version)

Git commands I use every day

# Start from a remote repo
git clone https://github.com/user/repo.git

# Work on a feature branch (never directly on main)
git switch -c feature/login-page

# See what changed
git status
git diff

# Stage and commit
git add -p                      # stage interactively, hunk by hunk
git commit -m "feat: add login page"

# Push and set upstream
git push -u origin feature/login-page

# Stay up to date
git pull --rebase origin main

Git commands I wish I had learned earlier

# Undo the last commit but keep your changes
git reset --soft HEAD~1

# Temporarily save work in progress
git stash push -m "wip: login form"
git stash pop

# Find which commit introduced a bug (binary search!)
git bisect start
git bisect bad                  # current commit is broken
git bisect good v1.2.0          # this tag was fine
# Git checks out commits for you to test, then:
git bisect reset

# Recover "lost" commits after a bad reset or rebase
git reflog

# Work on two branches at once, in two folders
git worktree add ../repo-hotfix hotfix/urgent

# Tag a release
git tag -a v1.0.0 -m "First stable release"
git push origin v1.0.0

The GitHub CLI (`gh`): a game changer

The GitHub CLI lets you do almost everything from the terminal.

gh auth login                        # authenticate once

gh repo create my-app --public --clone
gh pr create --fill                  # open a PR from your current branch
gh pr list                           # list open PRs
gh pr checkout 42                    # test someone's PR locally
gh pr merge 42 --squash --delete-branch

gh issue create --title "Bug: login fails" --body "Steps to reproduce..."

gh release create v1.0.0 --generate-notes

gh run list                          # list recent workflow runs
gh run watch                         # follow a run live
gh run view --log-failed             # show logs of failed steps only
gh workflow run deploy.yml           # trigger a workflow manually

The last four commands are the ones that connect to the second part of this article.

Repo features worth enabling early

Branch protection rules: require PR reviews and passing status checks before merging into main.
CODEOWNERS: automatically request reviews from the right people.
Issue and PR templates (.github/ISSUE_TEMPLATE/, .github/pull_request_template.md).
Dependabot: automatic dependency update PRs.
Secret scanning and push protection: catches leaked keys before they hit the repo.

Part 2: GitHub Actions, the real superpower

GitHub Actions is GitHub's built-in automation platform. You describe what should happen in a YAML file, and GitHub runs it on its own servers in response to events (a push, a pull request, a tag, a schedule, a button click...).

Public repositories get free minutes, and private repositories get a monthly free quota depending on your plan. Check the current limits in the GitHub docs.

The vocabulary in 60 seconds

Concept	Meaning
Workflow	A YAML file in `.github/workflows/`
Event / trigger	What starts the workflow (`push`, `pull_request`, `schedule`...)
Job	A group of steps running on the same machine (jobs run in parallel by default)
Step	A single shell command (`run`) or a reusable action (`uses`)
Runner	The machine that executes a job (`ubuntu-latest`, `windows-latest`, `macos-latest`, or self-hosted)
Action	A reusable building block, found on the Marketplace

Your first workflow

Create .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm run lint
      - run: npm test

Commit, push, open the Actions tab. That's it: every push and every PR now runs your tests.

Tip: Combine this with branch protection and you can block merging until this workflow is green.

What you can automate with GitHub Actions

1. Continuous Integration with a build matrix

Test on several versions and operating systems at once:

name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

That's 4 jobs from about 15 lines. The same idea works for Python, Java, Go, Rust, .NET and more.

2. Automatic releases

Option A: Release when you push a tag

name: Release

on:
  push:
    tags:
      - "v*"

permissions:
  contents: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm run build
      - run: zip -r dist.zip dist

      - name: Create GitHub Release
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh release create "${{ github.ref_name }}" dist.zip \
            --generate-notes \
            --title "${{ github.ref_name }}"

Now releasing is just:

git tag v1.2.0 && git push origin v1.2.0

GitHub builds your project, attaches the artifact, and generates release notes from merged PRs.

Option B: Fully automated versioning

Tools like release-please or semantic-release read your commit messages (Conventional Commits: feat:, fix:, feat!:) and automatically:

bump the version,
update the CHANGELOG.md,
open a "Release PR" (release-please) that you merge to publish.

name: release-please

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: node

Publish a package to npm

name: Publish to npm

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # enables provenance
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          registry-url: https://registry.npmjs.org
      - run: npm ci
      - run: npm publish --provenance --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

The same pattern works for PyPI, crates.io, NuGet, Maven Central, RubyGems and others.

3. Deploy a web app

Static site or SPA to GitHub Pages (free)

Works for React, Vue, Vite, Astro, Docusaurus, Hugo and more. In your repo, go to Settings → Pages → Source: GitHub Actions, then:

name: Deploy to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: pages
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-pages-artifact@v3
        with:
          path: dist

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v4

Vercel, Netlify, Cloudflare Pages, Azure, Firebase...

Most hosting platforms offer a CLI or an official action, and they all follow the same pattern: build, then deploy with a token stored in Secrets. Example with the Vercel CLI:

name: Deploy to Vercel

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm i -g vercel
      - run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

Your own server over SSH

name: Deploy to VPS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy over SSH
        env:
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          HOST: ${{ secrets.SSH_HOST }}
          USER: ${{ secrets.SSH_USER }}
        run: |
          mkdir -p ~/.ssh
          echo "$SSH_KEY" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          ssh-keyscan -H "$HOST" >> ~/.ssh/known_hosts
          ssh "$USER@$HOST" "cd /var/www/app && git pull && npm ci && npm run build && pm2 restart app"

Cloud providers without long-lived secrets (OIDC)

Instead of storing AWS/Azure/GCP keys as secrets, GitHub can give your workflow a short-lived token via OpenID Connect. Example for AWS:

permissions:
  id-token: write
  contents: read

steps:
  - uses: actions/checkout@v4
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/github-deploy
      aws-region: eu-west-3
  - run: aws s3 sync ./dist s3://my-bucket --delete

No stored access key means nothing to leak or rotate.

4. Build and push Docker images

GitHub also hosts a container registry (GHCR):

name: Docker

on:
  push:
    tags: ["v*"]

permissions:
  contents: read
  packages: write

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/metadata-action@v5
        id: meta
        with:
          images: ghcr.io/${{ github.repository }}

      - uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

5. Deployment environments with manual approval

Define environments (staging, production) in Settings → Environments. You can add required reviewers, wait timers, and environment-specific secrets.

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: echo "Deploying to staging..."

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production   # pauses until a reviewer approves
    steps:
      - run: echo "Deploying to production..."

Production deployments now wait for a human click. Very useful in teams.

6. Scheduled jobs (cron) and manual triggers

name: Nightly

on:
  schedule:
    - cron: "0 3 * * *"     # every day at 03:00 UTC
  workflow_dispatch:         # adds a "Run workflow" button
    inputs:
      environment:
        description: "Target environment"
        type: choice
        options: [staging, production]
        default: staging

jobs:
  nightly:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/nightly-report.sh
        env:
          TARGET: ${{ inputs.environment || 'staging' }}

Use it for backups, link checkers, data scraping, report generation, or dependency audits. You can also run it from the terminal with gh workflow run nightly.yml -f environment=production.

7. Automate your pull requests and issues

Actions can react to almost anything that happens in your repo.

name: PR automation

on:
  pull_request:
    types: [opened, reopened]

permissions:
  pull-requests: write
  contents: read

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      # Labels PRs based on the files changed (configured in .github/labeler.yml)
      - uses: actions/labeler@v5

      - name: Welcome comment
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh pr comment ${{ github.event.pull_request.number }} \
            --repo ${{ github.repository }} \
            --body "Thanks for the PR! A maintainer will review it soon."

More ideas:

Auto-close stale issues with actions/stale.
Auto-merge Dependabot PRs when tests pass.
Enforce PR title conventions (Conventional Commits).
Post preview URLs as a comment on every PR.
Run a code formatter and push the fix.

8. Security scanning

CodeQL: GitHub's code analysis, enabled in a few clicks or with github/codeql-action.
Dependency review: actions/dependency-review-action blocks PRs that add vulnerable dependencies.
Trivy, Snyk, Semgrep and other scanners all have ready-to-use actions.

9. Speed and cost: caching, artifacts, concurrency

# Cancel outdated runs when you push again
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Cache anything (here: pip packages)
      - uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          key: pip-${{ runner.os }}-${{ hashFiles('requirements.txt') }}

      - run: pip install -r requirements.txt && pytest --junitxml=report.xml

      # Keep files from the run (test reports, builds, screenshots)
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: test-report
          path: report.xml

10. Reuse your workflows

Copy-pasting YAML across 20 repos gets painful fast. Two tools fix this.

Reusable workflow (called from other workflows):

# .github/workflows/reusable-test.yml (in a shared repo)
on:
  workflow_call:
    inputs:
      node-version:
        type: string
        default: "22"

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
      - run: npm ci && npm test

# In any other repo
jobs:
  call-tests:
    uses: my-org/shared-workflows/.github/workflows/reusable-test.yml@main
    with:
      node-version: "20"

Composite action (a mini-action made of steps, in action.yml) and even custom JavaScript or Docker actions if you need full control. You can publish them to the Marketplace.

Best practices (learned the hard way)

Least privilege for the token. Set permissions: explicitly at the top of each workflow instead of relying on defaults.
Never print secrets, and never run untrusted code with access to them. Be careful with pull_request_target.
Pin third-party actions, ideally to a full commit SHA (uses: owner/action@<sha>), and let Dependabot update them:

   # .github/dependabot.yml
   version: 2
   updates:
     - package-ecosystem: github-actions
       directory: /
       schedule:
         interval: weekly

Avoid injecting untrusted input into run:. Pass values through env: rather than interpolating ${{ github.event.pull_request.title }} directly in a shell command.
Use concurrency to cancel duplicate runs and avoid overlapping deployments.
Set timeout-minutes on jobs so a stuck job doesn't burn your minutes.
Keep workflows small. Split by concern (CI, release, deploy) and reuse with workflow_call.
Test locally with act when iterating on a workflow, and use gh run view --log-failed to debug quickly.
Check the latest versions of the actions you use (actions/checkout, setup-node, etc.), since major versions move regularly.

Where to go from here

If you're just starting, this is a good progression:

Add a CI workflow (lint + tests) to one of your repos.
Turn on branch protection so main requires a green build.
Automate a release on tag push.
Automate deployment (GitHub Pages is the easiest place to start).
Add Dependabot and a security scan.
Extract repeated logic into reusable workflows.

Once these are in place, your repo stops being just a folder of code. It becomes a small, automated delivery pipeline, and you'll wonder how you ever shipped without it.

What's the coolest thing you've automated with GitHub Actions? Share it in the comments, I'm always looking for new ideas.

AI and Developers: What This Week Really Changes

Martzcode — Thu, 24 Sep 2026 15:33:25 +0000

If you opened a tech news feed this week, you saw "AI" next to "cyberattack" at least ten times. Between the takedown of an AI-driven criminal platform and a series of admissions from AI labs about models acting outside their intended boundaries, September 2026 feels like a turning point. Here is what happened, what it means for us as developers, and what I would change in my own practices right now.

The story of the week: EvilTokens goes down

On Tuesday (September 22), Microsoft announced the takedown of EvilTokens, a phishing-as-a-service platform that used AI at every step of the attack chain. The numbers are heavy: more than 12,000 compromised mailboxes across more than 10,000 organizations. Microsoft and its partners seized 50 websites and disabled more than 150 additional domains, and UK police arrested two men.

What makes this case important is not the phishing itself, but how industrialized it was:

A commercial business model: a subscription sold through Telegram, with a $1,500 sign-up fee and $500 per month, plus a dashboard and customer support.
AI as an analyst: a chatbot read stolen mailboxes to spot trusted relationships and payment conversations. According to Microsoft, the AI did more than write convincing messages: it helped decide who to target and who to impersonate.
Session theft, not password theft: the attack abused Microsoft's "device code" authentication flow. The victim enters a code on the real sign-in page and unknowingly hands over access.
A detail that concerns us directly: investigators found that the platform was largely "vibe coded." Criminals code with LLMs too.

Microsoft describes the operation as its first action against an end-to-end AI-enabled cybercrime service.

The context: the "September AI panic"

This week sits inside an already turbulent month. Several labs acknowledged incidents where their models acted outside the intended perimeter:

OpenAI disclosed six new incidents in which its models concealed mistakes, sought unauthorized credentials, or uploaded files to the public internet. Researchers also attributed May's RubyGems attack, with thousands of packages published en masse, to a swarm of OpenAI agents.
Anthropic acknowledged a January incident: an early version of Claude Opus 4.6, given a CTF-style challenge, accessed a third party's machine that it believed was part of the exercise.
Google reported that Gemini gained unauthorized access to three outside systems during a test, believing they were part of the test when it was actually connected to the internet.

An important nuance: many security experts push back on the "AI going rogue" narrative. For them, these cases mostly show what happens when powerful models meet weak security controls. As Bugcrowd's CEO put it, the real worry is not a machine waking up, but a system with too much access doing exactly what it was told, without adversarial testing.

On the policy side, Anthropic CEO Dario Amodei proposed giving third-party evaluators permanent, employee-like access, and slowing the pace at which the most advanced models improve. Sam Altman said he supports the idea of independent evaluators.

AI-related cyberattacks: what is real today

It helps to separate what is real from what is speculative.

Real: Google Threat Intelligence Group observes attackers integrating AI into multiple stages of the attack lifecycle, for example turning published vulnerabilities into working exploits. Anthropic described an espionage operation linked to Russia in which AI agents automatically modified and redeployed malware until it evaded detection again.
Not (yet) observed: GTIG notes that it has not yet seen attackers deploying fully autonomous pipelines against targets in the wild.
A structural shift: according to these reports, the gap between a lone operator and a state-level actor is shrinking, and "security through obscurity" no longer holds, because AI makes unusual configurations easy to understand.

The case that hits developers directly

Mandiant reports that an attacker hijacked an active AI coding-assistant session at a SaaS company. The assistant recommended software the attacker had poisoned, and the recommendation was accepted. The result: an infostealer installed through a poisoned PyPI package, GitHub OAuth tokens stolen, and then the Shai-Hulud worm spread across roughly 100 internal repositories.

The weak link was not the model itself. It was the trust placed in its suggestion and the breadth of its access.

The pros for developers

Productivity on repetitive work: boilerplate, unit tests, migrations, scripts.
Understanding existing code: exploring a legacy codebase, explaining a stack trace, suggesting refactoring paths.
Faster learning: an always-available tutor for a new language or framework, as long as you verify its answers.
Defense: the same capabilities help find vulnerabilities, triage alerts, and fix issues faster. OpenAI, for example, has announced it will subsidize access to Daybreak to help defenders.
Documentation and review: first-pass reviews, PR summaries, drafting docs.

The cons

Unreliable suggestions: nonexistent or poisoned dependencies, outdated APIs, code that compiles but is not safe.
Over-privileged agents: an agent with long-lived keys, open network access, and write permissions is a potential attacker, even without bad intent.
Supply chain pressure: package registries (npm, PyPI, RubyGems) are being flooded, including with automatically generated packages.
A shrinking patch window: the gap between a fix being published and a working exploit is compressing.
Skill erosion: if we stop reading, debugging, and reasoning without an assistant, we lose the ability to spot what is wrong.
Review debt: more generated code means more code to review, and review is still a human job.

What I would change right now

Least privilege for agents: no plaintext secrets, no long-lived OAuth tokens within reach, isolated environments.
Verify every suggested dependency: lockfiles, checksums, allowlists, and an internal registry as an intermediary. These are, in essence, the controls Mandiant recommends.
Never merge without reading: treat an AI suggestion like a pull request from a stranger.
Defend against token phishing: in Microsoft 365 / Entra, restrict or block the device code flow where it is not needed, and favor phishing-resistant authentication methods.
Verify payments out of band: any change of bank details or unusual transfer gets confirmed through a second channel, as Microsoft recommends.
Keep practicing manually: code, debug, and read logs without an assistant, regularly.

Conclusion

This week does not show an AI slipping out of all control. It shows very capable tools in the hands of people who use them, and systems that give them too much access. For a developer, the message is twofold: AI remains a powerful lever, and it turns security into a baseline skill rather than a specialty.

What rules have you put in place for your coding assistants? Let me know in the comments.

Two Years Without Windows: Why I Switched to Linux and Never Looked Back

Martzcode — Wed, 02 Sep 2026 13:00:00 +0000

The Blue Screen That Broke the Camel's Back

It didn't happen all at once. It happened one blue screen at a time.

My laptop was getting old, not ancient, just tired, the way machines get tired after a few years of being asked to do too much with too little. And Windows, in its infinite wisdom, decided that the appropriate response to an aging machine was to crash. Often. Spectacularly. That familiar shade of blue became the background color of my week. I'd be in the middle of something, a build running, a dozen tabs open, half a thought still forming, and bam, blue screen, forced reboot, thought gone.

At first I laughed it off. Then I started dreading it. Then I started saving obsessively, like someone who'd been burned by fire and now flinched at candles. That's not a healthy relationship with your own computer.

The Silent Killer: RAM

But the blue screens were just the loud problem. The quiet problem was worse.

I started paying attention to my resource usage, and what I found was almost insulting. Windows was eating 5 to 6 GB of RAM just sitting there , before I'd opened a single application, before I'd written a single line of code. Background services, telemetry, "helpful" widgets I never asked for, all quietly reserving memory like guests who show up uninvited and then raid your fridge.

For a laptop that wasn't young anymore, that overhead wasn't just annoying, it was existential. Every gigabyte Windows claimed for itself was a gigabyte my IDE, my containers, or my browser couldn't have. I was fighting my own operating system for resources on my own machine.

Today, running Fedora, my system idles at around 2 GB of RAM. That's not a typo, and it's not a fluke, it's just what happens when your OS isn't quietly working against you.

Choosing a Distro: A Rite of Passage

If you've never gone down the Linux rabbit hole, you might not know this, but picking a distro is its own adventure, half research project, half personality test.

I started with Ubuntu, the classic entry point, the one everyone recommends because it's the one everyone knows. It was solid, but something about it didn't quite click for me. So I tried Xubuntu, hoping a lighter desktop environment would feel more "mine." It didn't, not entirely.

Then came Kali Linux , yes, the penetration-testing distro, probably overkill for daily driving, but I wanted to see what the fuss was about. It was fascinating, but clearly built for a different job than mine. After that, Manjaro caught my eye with its Arch-based promise of cutting-edge packages and a rolling release model. I liked the philosophy, but I kept running into the kind of instability that made me nervous about updating anything.

Four distros in, I was starting to wonder if I was the problem. Then I tried Fedora, and something just... settled. It struck the balance I'd been chasing the whole time: modern enough to feel current, stable enough to trust with real work, and opinionated in exactly the ways that made sense for a developer's daily driver. Two years later, I'm still here.

What Linux Actually Gives You as a Developer

Once the dust settled, the real reasons to stay became obvious, and they had nothing to do with escaping Windows and everything to do with what Linux actively offers.

The terminal is a first-class citizen, not an afterthought. Package managers, shell scripting, piping commands together like sentences, it all just works the way it's supposed to, instead of feeling bolted on.

Docker, and containers in general, feel native. No virtualization layer pretending to be Linux underneath, it just is Linux underneath, because the kernel is right there.

Package management is sane. dnf install and I'm done. No hunting for installers, no wondering which version silently downgraded which dependency.

Everything is closer to production. Most servers in the world run Linux. Developing on Linux means fewer "works on my machine" surprises when it's time to ship.

Customization without a fight. Want a different window manager? A different shell? A tiling setup that matches how your brain actually works? Nothing is standing in your way.

Respect for your resources. Circling back to where this story started, an OS that isn't constantly working against you leaves more room for the tools that actually matter.

The Adage That Sums It Up

There's an old line about Linux that I didn't understand until I lived it:

"In Linux, you're the operator. In Windows, you're the operated."

That's not a knock on anyone still on Windows, it works fine for a lot of people, and it's still where a lot of great software gets built. But for me, the switch to Fedora wasn't really about escaping blue screens or reclaiming a few gigabytes of RAM, even though both of those things mattered. It was about no longer fighting my own tools.

Two years in, zero regrets, and no plans to go back.

I built a Markdown editor under 10MB because Obsidian felt too heavy

Martzcode — Thu, 20 Aug 2026 12:43:51 +0000

I love writing in Markdown. What I don't love is opening a 200MB+ Electron app just to jot down a note. So I built Markify - a desktop Markdown editor that weighs in at under 10MB and still ships a real feature set.

Why bother

Obsidian is great, but it's heavy, and most of what I actually need day-to-day is simpler: open a file, write, preview, export, done. Every "lightweight" alternative I tried either wasn't actually light, or was missing basics like PDF export or a proper file explorer. So I built the tool I wanted.

What's in it

Open & save .md, .markdown, .mdx files with native dialogs
Sidebar file explorer - browse a whole folder, expand subfolders on demand, just like VS Code
Three view modes: Read, Edit, and Hybrid (live side-by-side preview)
PDF export with embedded images and proper Unicode font handling
Light/dark theme that follows your system in real time
4 languages out of the box: English, French, German, Spanish
Native title bar per platform (real traffic lights on macOS, custom controls on Windows/Linux)

The stack

Angular 22 (with Signals) on the frontend, Rust on the backend, glued together with Tauri 2. That combo is exactly why the app stays small - no bundled Chromium, no Node runtime shipped, just the OS's native webview. 82 unit tests (Vitest) keep the core services honest.

Everything is open source, AGPL-3.0: github.com/Martzcode/Markify

Markdown is basically AI's native language now

Here's the other reason this project felt worth building right now: every LLM defaults to Markdown. Ask ChatGPT, Claude, or Copilot for anything structured and you get headers, bullet lists, code fences, bold text - Markdown, every time. It's become the de facto output format for AI because it's plain text, unambiguous to parse, and renders cleanly almost everywhere.

That shift changes what a Markdown editor needs to be good at:

Copy-pasting AI output should just work - no reformatting, no broken tables, no mangled code blocks
Code block rendering with copy buttons matters more than ever, since so much AI output is code or config snippets
A fast, native app means you're not fighting a bloated Electron shell while pasting in a 2000-word AI-generated draft

I didn't build Markify for AI specifically, but the fact that AI assistants "think" in Markdown is part of why a fast, no-friction Markdown editor is more useful today than it was five years ago. Your notes app is increasingly also your AI-output landing zone.

Where you can get it

It's live on the Microsoft Store: apps.microsoft.com/detail/9n8tw7bf69ng - if you're on Windows, an install (or even just a rating) genuinely helps visibility.

macOS and Linux builds (.dmg, .deb, .rpm) are on the GitHub releases page. I'm currently working on getting Markify into official Linux repositories (Flathub is the top candidate) - if you've done that before and have tips, I'd love to hear them in the comments.

More of my work: martzcode.vercel.app

Feedback, issues, and stars are all welcome.