Forem: Nader

The AI Approval Process: Why Amazon's New Policy Matters for Every Dev Team

Nader — Wed, 11 Mar 2026 06:27:38 +0000

Amazon just made a significant change to their deployment process: senior engineers must now sign off on all AI-assisted code changes before they go to production. This comes after a series of outages linked to AI-generated modifications. But this isn't just an Amazon problem—it's a wake-up call for the entire industry.

We've been living in the golden age of AI coding assistants. Tools like Copilot, Cursor, and Claude have revolutionized how we write code. They're fast, they're helpful, and they can churn out solutions in seconds. But speed without scrutiny is a recipe for disaster.

The issue isn't that AI writes bad code—it's that AI writes plausible code. Code that looks right at first glance but might miss edge cases, ignore security implications, or introduce subtle bugs that only surface under production load. Human developers make these mistakes too, but we've built decades of review processes around human work. We haven't yet adapted those processes for AI output.

Amazon's policy is simple but powerful: require a senior engineer to review and approve any change that was substantially AI-generated. This creates accountability and ensures that experienced eyes verify the logic before it ships. It's not about distrusting AI—it's about treating AI-generated code with the same rigor we'd apply to code from a junior developer.

For smaller teams, this might mean establishing clear guidelines: When is AI assistance appropriate? Who reviews AI-generated PRs? What level of testing is required? The key is intentionality. Use AI as a powerful tool, but never abdicate responsibility for what ships.

The bottom line: AI makes us faster, but human judgment keeps us reliable. Amazon's policy isn't a step backward—it's a mature approach to leveraging AI while maintaining engineering excellence.

Should Your AI Coding Session Be Part of the Git Commit?

Nader — Mon, 02 Mar 2026 08:11:40 +0000

The rise of AI-powered coding assistants has introduced a fascinating new question to our development workflow: if AI writes your code, should the conversation history be included in the commit?

At first glance, it sounds absurd. We don't commit our Google searches or Stack Overflow browsing history. But AI-assisted coding is fundamentally different. The prompt engineering, the back-and-forth refinement, the edge cases you discussed—these aren't just research. They're part of the design process.

Consider this: when reviewing a PR six months later, wouldn't it be valuable to see why the developer chose a particular approach? With traditional code, we rely on commit messages and code comments. But AI sessions often contain rich context—the constraints discussed, alternatives considered, and reasoning behind implementation choices.

Some developers are already experimenting with this. They're appending AI session summaries to commit messages or maintaining parallel documentation of significant AI interactions. Others argue it's noise—that code should speak for itself.

The truth likely lies somewhere in between. Not every AI interaction deserves preservation, but pivotal architectural decisions made through AI collaboration might warrant documentation. Think of it like pair programming notes: you don't transcribe every word, but you capture the key insights.

As AI becomes more integrated into our workflows, we'll need new conventions. Maybe a .ai-sessions/ directory? Commit message footers? Or perhaps IDE plugins that let you tag and archive significant interactions?

The conversation is just beginning, but one thing is clear: our version control practices need to evolve alongside our tools.

Also, if you want to check out my blogging project, visit Pluma.ink - a clean platform for documenting ideas.

Why Headless Sync Clients Matter (And Why Obsidian Just Made the Right Move)

Nader — Sun, 01 Mar 2026 08:22:26 +0000

Obsidian just launched a headless sync client, and the developer community is buzzing. But why does a "headless" version of a note-syncing tool matter so much?

The Power of Headless

Headless clients strip away the GUI and expose core functionality through CLI or API. For developers, this unlocks automation possibilities that GUI-only tools can't touch. Want to sync your notes as part of a CI/CD pipeline? Automatically backup your knowledge base to multiple locations? Trigger syncs based on git hooks or cron jobs? Now you can.

Developer Workflows Are Non-Linear

We don't work in neat, linear patterns. We context-switch constantly—from terminal to editor to browser. When your tools require opening an app and clicking buttons, friction builds up. Headless clients remove that friction. They meet you where you already are: the command line.

The Bigger Picture

This trend extends beyond note-taking. We're seeing headless versions of CMS platforms, design tools, and analytics dashboards. The pattern is clear: developers want programmatic access to everything. We want to script, automate, and integrate tools into our unique workflows.

Obsidian's move validates what many power users have known for years: the best tools are the ones you can bend to your will. Whether you're building a personal knowledge management system, automating documentation, or creating custom backup solutions, headless access turns tools from applications into building blocks.

The future isn't just about better apps—it's about composable, scriptable tools that adapt to how you work.

Also, if you want to check out my blogging project, visit Pluma.ink - a clean platform for documenting ideas.

Why Passkeys Aren't Ready for Encrypting Your User Data (Yet)

Nader — Sat, 28 Feb 2026 06:21:20 +0000

Passkeys are everywhere. GitHub uses them. Google pushes them. Your password manager probably nags you about them. They're the future of authentication, right?

Well, yes and no.

While passkeys are excellent for passwordless login, there's a critical limitation developers need to understand: don't use them to encrypt user data.

Here's why:

Passkeys rely on the WebAuthn API's PRF (Pseudo-Random Function) extension to derive encryption keys. Sounds solid, but there's a catch—PRF support is inconsistent across platforms. Your users might authenticate successfully with a passkey but fail to decrypt their data because their device doesn't support PRF.

Imagine building an end-to-end encrypted notes app. A user creates an account on their MacBook (PRF supported), encrypts their notes, then tries to access them from their iPhone (PRF might not work). Boom. Data inaccessible. Your support inbox explodes.

The safer approach: Use passkeys for authentication, but handle encryption separately with traditional key derivation methods. Think password-based encryption (PBKDF2, Argon2) or server-managed keys with proper access controls.

This isn't to say passkeys are bad—they're fantastic for eliminating phishing and credential stuffing. Just don't overload them with responsibilities they can't consistently handle yet.

As the ecosystem matures and PRF support becomes universal, this will change. But today, in 2026, treat passkeys as what they are: a robust authentication mechanism, not a encryption key manager.

Keep your auth modern, but keep your encryption battle-tested.

Also, if you want to check out my blogging project, visit Pluma.ink - a clean platform for documenting ideas.

Stop Coding First: Why README-Driven Development Saves Time

Nader — Fri, 27 Feb 2026 09:17:23 +0000

You've been there: diving into code, building features, then realizing three hours later that you've built the wrong thing. Or worse, built something you can't explain to your team.

README-driven development flips the script. Write the README first. Before a single line of code.

Here's why it works:

Clarity Before Complexity

Writing what your project does, who it's for, and how to use it forces you to crystallize your thinking. If you can't explain it simply, you haven't thought it through.

Immediate Feedback Loop

Share your README with a colleague. Get feedback. Pivot if needed. It's infinitely cheaper than refactoring a week's worth of code.

Documentation That Actually Gets Done

Let's be honest: documentation written after the fact is often rushed or skipped. Write it first, and it's already done when you ship.

Better API Design

When you write usage examples before implementation, you design from the user's perspective. Your API becomes cleaner, more intuitive.

The Practice

Create README.md
Write project description, installation, and basic usage
Add code examples showing how it should work
Only then: start coding

Your future self will thank you. Your teammates will thank you. Your users will thank you.

Start with words. Then code. Not the other way around.

Also, if you want to check out my blogging project, visit Pluma.ink - a clean platform for documenting ideas.

The 5-Minute Code Review Checklist That Catches 80% of Bugs

Nader — Thu, 26 Feb 2026 09:52:41 +0000

Code reviews don't have to be exhausting marathons. After reviewing thousands of pull requests, I've distilled the process into five quick checkpoints that catch most issues before they hit production.

1. The "Why" Test (60 seconds)

Can you understand why this change exists from the PR description? If not, ask. Context prevents future confusion and helps with debugging months later.

2. Error Handling Scan (90 seconds)

Skim for try-catch blocks, null checks, and edge cases. Most production bugs come from missing error handling, not logic errors.

3. The Delete Check (30 seconds)

Look for what was removed. Deleted code can break dependencies in unexpected ways. A quick scan saves hours of debugging.

4. State Management Reality Check (60 seconds)

Does this change introduce new state? If yes, trace how it's updated and accessed. Race conditions and stale state are silent killers.

5. The "Merge Tomorrow" Question (60 seconds)

Would you be comfortable merging this if the author disappeared? If there's anything unclear, flag it now.

This isn't about perfection—it's about catching the high-impact issues quickly. You can always do deeper reviews for critical systems, but this checklist prevents 80% of the bugs that slip through rushed reviews.

The best code reviews are fast, focused, and kind. Save the energy for the tricky stuff.

If you want a clean space to document your developer journey, visit Pluma.ink - a blogging platform built for exactly that.

The 5-Minute Documentation Rule That Saved My Sanity (And My Team's)

Nader — Fri, 20 Feb 2026 07:10:55 +0000

I used to hate documentation. It felt like extra work that slowed me down. Then I discovered a simple rule that changed everything: If future-you will need more than 5 minutes to understand it, document it now.

Here's why it works:

The 5-minute threshold is the sweet spot

Too short (like variable names), and you're wasting time. Too long (like full architecture docs), and you'll never finish. Five minutes is just enough pain to motivate action.

What to document

Non-obvious function behaviors
Why you chose approach A over B
Environment setup quirks
API endpoints and their gotchas
That weird bug fix that took 3 hours

How I apply it

When I'm about to commit code, I ask: "If I saw this in 6 months, would I understand it in under 5 minutes?" If not, I add a comment or update the README. It takes 2-3 minutes now, saves hours later.

The magic side effect

Your code reviews get faster. Your onboarding improves. Your future self sends thank-you notes (mentally).

Documentation doesn't have to be perfect. It just has to exist. Start with the 5-minute rule, and watch your codebase become less of a mystery box.

Your future teammates (and yourself) will thank you.

If you want a clean space to document your developer journey, visit Pluma.ink - a blogging platform built for exactly that.

Anthropic Just Banned Subscription Auth for Third-Party Apps — What Developers Need to Know

Nader — Thu, 19 Feb 2026 08:25:19 +0000

If you've been building tools or apps that piggyback on a user's Claude subscription instead of using the official API — that door just closed.

Anthropic quietly but officially updated their compliance documentation to explicitly ban using subscription-based authentication to power third-party applications. In plain terms: you can't tunnel Claude.ai access through someone's paid plan to serve your own users.

Why does this matter?

A lot of indie developers and startups took this shortcut. It was cheaper. Subscription pricing is predictable. API tokens are metered and can spike hard. So the temptation was real.

But this was always a grey area — and now it's not. It's a clear line.

What changes right now

Any app routing Claude requests via a user's subscription login needs to migrate to the API
Token-based access via api.anthropic.com is the only compliant path forward
Violating this risks account bans for both you and your users

The silver lining

This actually levels the playing field. Apps that were cutting corners now compete on equal footing with those who built properly from day one. And Anthropic's API while metered has solid rate limits and predictable pricing tiers.

If you're not already on the API path, now's the time. Set up a key, wrap your calls, and stop relying on session auth hacks.

The bigger picture

As AI tooling matures, expect more of this. Platforms are drawing clearer lines between consumer use and developer use. Build on APIs, not workarounds.

If you want a clean space to document your developer journey, check out Pluma.ink - a blogging platform built for exactly that.

Your AI Tools Make You 10x Faster. So Why Isn't Your Company 10x Productive?

Nader — Thu, 19 Feb 2026 08:23:23 +0000

A Fortune article trending on Hacker News today dropped a quiet bombshell: thousands of CEOs in a new study admitted AI has had no measurable impact on employment or productivity.

Meanwhile, you're shipping features in half the time. Something doesn't add up.

The gap is real — and it's not about the tools

Economists call it the productivity paradox. It happened with computers in the 80s, with the internet in the 90s. New technology floods in, individual workers feel faster, but aggregate productivity barely moves. Then, suddenly — it does. All at once.

We're probably in that delay right now.

Where individual gains go to die

When you use Copilot to write boilerplate faster, that time usually gets absorbed — more meetings, more scope creep, more tickets queued up by a PM who now assumes you can deliver twice as much. The bottleneck just moved.

Organizational structure is the real constraint. If your deploy pipeline takes 3 days of approvals, writing code in 20 minutes instead of 2 hours doesn't matter.

What actually changes things

The devs who seem superhuman with AI aren't just autocompleting code. They're:

Replacing whole workflows, not just tasks
Shipping ideas faster, not just lines
Using AI to do things they simply wouldn't have done before

The leverage isn't in doing the same thing quicker. It's in raising your ambition threshold.

The take

CEOs not feeling it makes sense — they're measuring the wrong layer. But the productivity wave is real. It's just building in individuals first. The macro numbers will catch up.

You're early. Stay sharp.

If you're a developer who wants a clean space to document your ideas and builds, check out Pluma.ink — a blogging platform I built for exactly that.

Stop Writing CSS Like It's 2015 — 5 Modern Properties You Should Already Be Using

Nader — Tue, 17 Feb 2026 08:05:35 +0000

If your CSS still looks like a Stack Overflow answer from 2014, it's time for a refresh. Browsers have quietly shipped some genuinely great stuff while we were busy arguing about utility-first frameworks.

Here are 5 modern CSS properties worth adding to your muscle memory today:

1. container-size (Container Queries)
Responsive design based on parent size, not viewport. Finally. Components that adapt to where they live, not just the screen.

@container (min-width: 400px) {
  .card { flex-direction: row; }
}

2. :has() — The Parent Selector
The selector CSS was "never going to have." Now it does. Style a parent based on its children without JavaScript.

form:has(input:invalid) { border-color: red; }

3. color-mix()
Mix two colors in CSS without a preprocessor or JS. Dead simple theming.

background: color-mix(in srgb, #3b82f6 30%, white);

4. text-wrap: balance
One line. Fixes orphaned words in headings automatically. Throw it on every h1–h4 and never think about it again.

5. @layerCascade layers let you explicitly control specificity order. No more !important arms races.

The CSS landscape in 2026 is genuinely exciting. A lot of patterns we reached for JS or preprocessors to solve are now native — and browser support is solid.

Pick one, drop it into your next project, and see how it feels.

If you're building something you want to write about, check out Pluma.ink — a clean blogging platform built for developers who want a simple space to document their ideas.

Stop Writing Perfect Code on the First Try (Your Future Self Will Thank You)

Nader — Mon, 16 Feb 2026 17:19:57 +0000

Here's a truth that took me years to internalize: the developers who ship the most aren't the ones writing perfect code on the first attempt. They're the ones who embrace the messy middle.

We've all been there. You stare at a blank file, paralyzed by the need to architect the "right" solution from line one. You refactor before you've even validated the feature works. You spend hours debating variable names when you haven't proven the concept yet.

Here's what changed my workflow:

1. Permission to be ugly first. My initial implementation is always rough. No abstractions, some duplication, hard-coded values. But it works, and I can click through it.

2. The 48-hour rule. I commit the working mess, ship it to staging, and walk away. Two days later, I return with fresh eyes. The refactor opportunities become obvious.

3. Delete, don't preserve. That clever abstraction you're not sure about? Delete it. Code is cheap. Cognitive load is expensive. If you can't justify it in one sentence, it's premature.

4. Comments are code smell. If you need a comment to explain what code does, the code isn't clear enough. Rename, extract, simplify.

The irony? Once I gave myself permission to write bad code first, my "final" code got significantly better. Because I was optimizing the right thing: working software that solves real problems.

Your first draft doesn't need to be your best work. It just needs to exist.

Also, if you want to check out my blogging project, visit Pluma.ink - a clean platform for documenting ideas.

Tags: #productivity #softwaredevelopment #coding #cleancode

The Real Cost of "I'll Refactor It Later" (And Why I Finally Stopped Lying to Myself)

Nader — Sat, 14 Feb 2026 11:15:00 +0000

We've all been there. You're deep in flow, solving a problem, and you write something that works but... isn't quite right. The variable names are vague. The function is doing three things instead of one. There's a comment that says "TODO: clean this up."

"I'll refactor it later," you tell yourself. Narrator: They did not refactor it later.

I spent years accumulating technical debt with this exact promise. Every "quick fix" that became permanent. Every "temporary solution" that's still running in production. And honestly? It nearly killed my latest project.

The Wake-Up Call

Last month, I was adding a simple feature to a project I'd been building for months. What should have taken an hour took three days. Why? Because I was navigating around six months of "I'll refactor it later" decisions. Functions with misleading names. Tight coupling everywhere. Logic scattered across files with no clear pattern.

The feature worked eventually, but I was exhausted. More importantly, I'd lost the joy of building. Every change felt like defusing a bomb.

The Hidden Costs

Here's what "later" actually costs:

Mental overhead: Every time you open that file, you have to re-decode what past-you was thinking. It's like paying compound interest with your attention.

Slower iteration: Features that should be simple become archaeological expeditions. You spend more time understanding existing code than writing new code.

Lost momentum: Nothing kills motivation faster than dreading your own codebase. When opening your project feels like homework, you've lost.

The mindset shift that changed everything

I made one simple rule: If I'm touching a file, I leave it better than I found it. Not perfect. Just better.

Adding a feature? Clean up the function names while you're there. Fixing a bug? Extract that nested logic into a helper. Touching a view? Rename those cryptic variables.

Five minutes of cleanup today saves thirty minutes of confusion next week.

The Boy Scout Rule

This is basically the Boy Scout Rule: "Leave the campground cleaner than you found it." But here's the key insight I missed for years: you don't have to fix everything.

You're not refactoring the entire codebase. You're just improving the small area you're already working in. It's opportunistic. It's incremental. And most importantly, it compounds.

After two weeks of following this rule, my codebase started feeling different. After a month, adding features was actually fun again. Functions had clear names. Logic was where I expected it. The code was becoming self-documenting.

When "Later" Is Actually Never

Let's be honest about what "I'll refactor it later" really means:

"I'll refactor it when I have time" = Never (you won't have time)
"I'll refactor it when the project is done" = Never (projects are never done)
"I'll refactor it when we hit issues" = Too late (you're already drowning)

The only "later" that works is "the next time I touch this code" - which is exactly the Boy Scout Rule.

Practical Guidelines

Here's what I actually do:

If it takes less than 5 minutes, do it now. Rename that variable. Extract that constant. Add that type annotation.
If it's bigger, create a ticket. But be honest: will you actually do it? If not, do the 5-minute version now.
Don't refactor for hypothetical futures. Refactor for clarity today. The future will take care of itself.
Test as you go. Small refactors are easy to verify. Big ones are scary. Stay small.

The Exception

There is one valid "later": when you're prototyping or exploring an idea. Throw away code can be messy. But the moment you decide it's staying, that's when the Boy Scout Rule starts.

What Changed

Six months ago, my codebase felt like a weight. Today, it feels like a tool. The difference? I stopped deferring quality to "later" and started making tiny improvements in the moment.

Your code doesn't need to be perfect. It just needs to be slightly better than it was yesterday.

Also, if you're working on projects that need a clean blogging platform to document your journey, check out Pluma.ink - I built it to keep technical writing distraction-free.

Tags: #productivity #coding #webdev #programming