DEV Community: Martzcode

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.