Fortunately, detecting brute force attacks is well within reach using Python. By monitoring your system’s authentication logs and tracking failed login attempts, you can identify patterns, block offending IP addresses, and alert administrators before any real damage is done.

In this article, we will walk through the process of building a lightweight Python-based SSH brute force monitor. It is a practical and educational project that will strengthen both your Python skills and your understanding of real-world threats.

Let’s begin with where brute force attempts leave their trace — the logs. On most Linux systems, SSH login activity is recorded in /var/log/auth.log or /var/log/secure depending on the distribution. Every failed attempt generates an entry including the username, IP address, and timestamp. By scanning this file, we can extract and analyze the data to detect abuse.

The basic idea is simple: if the same IP address fails to log in too many times within a short time frame, it is probably not a legitimate user. Your script can then log this activity, notify an admin, or even ban the IP address automatically.

You do not need complex tools to make this happen. With Python, you can open the log file, read it line by line, and use regular expressions to pull out the relevant parts. The script can keep track of failed attempts by IP in a dictionary and compare the number of attempts against a defined threshold.

Here is how the monitoring logic works at a high level:

1. Read from the SSH authentication log
2. Search for lines that indicate a failed login
3. Extract the offending IP address and timestamp
4. Keep a count of failed attempts per IP
5. If an IP exceeds your threshold, log it as suspicious
6. Optionally, trigger an alert or response action

This approach is simple, but very effective. You can run the script periodically using cron or keep it running continuously in the background, depending on your needs. You might also build in logging so you can review which IPs were blocked or flagged over time.

One thing to be careful of is avoiding re-parsing the same entries. If your script reads from the top of the log file every time it runs, you will get duplicate results. A good solution is to track the last read position using a small marker file, or even just process only new entries since the last run.

As your script evolves, there are many features you can add:

• GeoIP lookup: See where attacks are coming from geographically
• Whitelist: Avoid blocking trusted internal IP addresses
• Firewall integration: Use tools like iptables or ufw to block attackers
• Email alerts: Notify admins of suspicious behavior immediately
• Dashboard logging: Send events to a web dashboard or database for further analysis

Python’s flexibility means you can tailor this tool to fit any environment. In smaller settings, it might be your first line of defense. In larger networks, it can supplement existing intrusion detection systems.

Here are a few enhancements to make your monitor more powerful:

• Sliding time window: Track how many failed attempts occurred within a set time period, such as five minutes
• Concurrency: Use threads or asynchronous processing to monitor multiple files or services at once
• Success correlation: Detect suspicious activity followed by a successful login from the same IP
• Log rotation support: Ensure your script handles rotated logs gracefully

The more context you can build around each event, the smarter your response will be. The goal is not just to stop attacks, but to understand them — their frequency, tactics, and origin.

Once you have your SSH monitor running, you will likely be surprised by how often brute force attempts happen. Even low-profile servers receive regular attention from automated bots. Being able to see this in action reinforces the importance of basic hardening measures like using strong credentials, disabling root login, and enabling key-based authentication.

If you are looking to practice your Python skills on a real problem that defenders face every day, building an SSH brute force monitor is an ideal project. It teaches you to parse logs, track state, automate responses, and think like both an attacker and a defender. Best of all, it is something you can build quickly and improve over time.

To go further, check out my 17-page PDF guide, Mastering Cybersecurity with Python: The Complete Pro Guide to Network Defense. It includes deeper dives into detection logic, script examples, and more hands-on projects for defensive Python development. You can download it now for just five dollars.

And if you have enjoyed this article or the series so far, I invite you to buy me a coffee. Your support helps me keep producing practical, focused cybersecurity content for learners and professionals alike.

This one bit me early on. I wanted to print every item in a list, so I wrote something like this:

python
def show_items(items):
for item in items:
return item

show_items([“apple”, “banana”, “cherry”])

Run it, and… nothing prints. Why? return doesn’t just output a value it immediately exits the function. So the loop runs exactly once, hands back “apple”, and the function is done. banana and cherry never gets a chance.

The solution is simple once you see it:

python
def show_items(items):
for item in items:
print(item)

show_items([“apple”, “banana”, “cherry”])

Lesson: print() displays something and lets execution continue. return hands a value back to whoever called the function and ends it. They can’t be taken for same.

1. Writing a ternary expression as literal text inside an f-string

I wanted to print whether a number was even or odd, so I wrote:

python
num = 7
print(f”The number is {‘even’ if num % 2 == 0 else ‘odd’})”)

Small typo — the closing } was in the wrong place, so part of my ternary logic ended up printed as literal text instead of being evaluated. It’s an easy mistake to make because f-string expressions look like normal code, but every {} boundary has to be exactly right.

Lesson: Anything you want evaluated inside an f-string has to be fully and correctly wrapped in {} — including the entire ternary expression, not just part of it.

1. Nesting a plain string inside an f-string ternary

A frustrating version of the same problem:

python
status = “active”
print(f”Status: {‘User is online’ if status == ‘active’ else ‘User is offline: {status}’}”)

Here, the inner strings ‘User is online’ and ‘User is offline: {status}’ are just regular strings — not f-strings. So {status} inside that second string prints literally as {status} instead of showing the actual value.

The fix: make sure any inner string that needs interpolation is also an f-string:

python
print(f”Status: {‘User is online’ if status == ‘active’ else f’User is offline: {status}’}”)

Lesson: The f prefix only applies to the string it’s directly attached to. Nested strings need their own f if they need their own interpolation.

1. Mixing up loop variables and the original list name
   python
   scores = [85, 92, 78, 90]

for score in scores:
print(scores) # oops — meant to print score, not scores

This one doesn’t throw an error, which makes it worse — it just quietly prints the wrong thing four times instead of the four individual scores. It usually happens when I’m typing fast and my fingers default to the more “familiar” variable name.

Lesson: After writing a loop, it’s worth a quick second glance — is the singular loop variable being used inside the loop body, or did the plural list name sneak back in?

1. Forgetting self when accessing an attribute inside a class method

This one showed up once I started learning classes:

python
class Dog:
def init(self, name):
self.name = name

def bark(self):
    print(f"{name} says Woof!")   # here it is a NameError because name is not defined

I dropped the self. in front of name inside bark(), so Python went looking for a plain variable called name — which doesn’t exist inside that method. The fix is just remembering that any attribute stored on the object has to be accessed through self:

python
def bark(self):
print(f”{self.name} says Woof!”)

Lesson: Inside a class, self.attribute and a plain attribute are two completely different things. Only self.attribute refers to the data actually stored on the object.

None of these mistakes are advanced, they’re the kind of small, easy to miss errors that come from moving fast and not yet having the muscle memory for the syntax. Writing them down has honestly helped more than just fixing them silently and moving on. If you’re a beginner too, hopefully seeing these saves you a few minutes of confused debugging.
although I’m having hard time keeping them in this small mind of mine, but practice makes it better which i’m not doing also because of university

LinkedIn’s logic isn’t hard to follow. According to the AI detector Pangram, they have the highest share of AI content of any platform: roughly a third of short posts and over forty percent of long ones. The feed really is drowning, and handing people a valve is a reasonable move.

It isn’t the valve that bothers me. It’s whose hands it got put in.

The “this is AI” verdict used to come from an algorithm, and even that missed plenty. Pangram itself claims a 0.01% false-positive rate — which sounds impressive until you multiply it by volume. One hundredth of a percent of millions of posts is still thousands of real people getting labelled as bots. And that’s the machine, the one somebody at least tested. Now the “this is AI” stamp has been handed to every passerby, and the cost of getting it wrong is zero. Tap, post gone, on with your coffee. You’ll never even find out you were wrong — there’s no feedback loop pointing back at you.

I haven’t touched the button once, and I don’t even like AI text — the smooth filler I spent a whole post pulling apart last time. But disliking slop and swatting a person are different reflexes with different results. Someone posts the best thing they know how to write, and someone else decides it “looks like a bot.” That’s one reader gone. That isn’t fighting slop. That’s slapping the hands of someone who’s only just reaching for the keyboard.

Here’s the personal part. I write with AI and I don’t hide it, but the text is mine: a pile of rules, defined styles, years of tuning, every paragraph edited by hand. Slow — though it used to be slower. AI isn’t my author, it’s a tool I don’t let grab the wheel. I wrote a whole article about that.

Then something happened that made it feel a lot more personal. A while back, in a work chat, I answered a former colleague — a plain message, a couple of paragraphs. She reads it and says: “Wow, you sound just like GPT — fast and structured.” A compliment. The catch is that about two minutes passed between her question and my answer. There wasn’t even enough time to open ChatGPT, write a prompt, wait for an answer, and paste it back. It was just a human who’s spent a long time working with words. And it read as a machine.

And for a couple of days I was pleased about it — imagine, mistaken for GPT, fast and clean. Now it turns out that’s exactly the thing I’m supposed to worry about. Same sentence. Same moment. A week later it had gone from a compliment to evidence, while nothing about me had changed. What changed is that there’s now a button for it.

Fluency is being read as forgery. Fast and clean means you didn’t write it yourself, and there’s now a button wired to that assumption.

The irony is that AI was trained on well-edited human prose — which is exactly why it comes out so smooth and combed. And that smoothness is now how we try to spot it: we hunt for the fingerprints of a good editor, and we reliably find them on people who simply know how to write. Congratulations to all of us.

My own way out of this is as old as it gets: divide and conquer. The machine is fast and a little too good — and sometimes not good at all, and that’s the line I can still see and it can’t. I handed it the posting across networks; works great — it’s mechanical anyway. But writing is different. No matter how much I train it, it keeps sliding back into “we did it this way before, so this must be right.” Except the new piece in front of it doesn’t fit the old rules, and it doesn’t notice that — I do. So here’s the split: authorship and judgment stay with the human, logistics go to the machine. That’s how I run it through Publora (I’m on the team): I write by hand, and the delivery across platforms goes to an agent. No AI writes my posts — it’s on backup duty, in the corner, not at the wheel.

How this ends, honestly, I don’t know. For now I’ve stocked up on popcorn and I’m watching from two angles. Angle one: people start writing worse on purpose — breaking the rhythm, sprinkling in typos, watering it down, anything to avoid looking suspiciously smooth. A platform that penalizes quality, and a crowd cheerfully dumbing itself down to a C. Angle two: some just stop posting, because the fun runs thin when any passerby gets to weigh your fluency for “real or not.” Which one wins, I won’t guess. Popcorn’s ready.

I still won’t press the button. Slop exists, no argument, plenty of it. But pressing something in two seconds, with zero accountability, that sorts people into “human / not human” — that I’m not up for.

By the way, a huge secret: I wrote this article myself, by hand. The formatting and posting I handed to an agent — the writing was mine, the publishing wasn’t, and that’s exactly how I want it.

Would you press it? And have you ever caught yourself deciding someone’s fast, clean writing was too smooth to be real?

Key Stats

Why Are Teams Looking for MinIO Alternatives in 2026?

Three things happened in quick succession between May and December 2025 that changed how infrastructure teams think about MinIO. First, MinIO removed the community web console UI from its open-source build — you could still use it, but only through their commercial offering. Second, they stopped distributing pre-built Docker images and binaries for the community edition, raising the barrier to a docker run from zero commands to a from-source build. Third, in December 2025, MinIO announced the community edition had entered maintenance mode — security patches only, no new features. By early 2026, the GitHub repository was archived as read-only.

These decisions are legally within MinIO, Inc.’s rights — AGPLv3 allows this. But operationally, they signaled to self-hosters that the frictionless experience they’d relied on since 2014 was becoming a paid product. Search volume for “minio alternative” rose 3–5x on Google Trends between December 2025 and March 2026, according to our SERP analysis of 8 authoritative articles covering the topic. Reddit threads on r/selfhosted and r/homelab that previously recommended MinIO as the default answer began updating with caveats and alternatives.

What Happened to MinIO’s Community Edition, Exactly?

MinIO is not dead. Let’s be precise about what changed, because the facts matter when you’re betting infrastructure on a project. MinIO, Inc. continues developing MinIO — but under a split model similar to MongoDB’s or Redis’s: an AGPLv3 community edition (security fixes only, no new features) and a commercial enterprise edition with the console UI, pre-built artifacts, and enterprise support. The source code remains visible on GitHub in archived form. You can still fork it, modify it, and run it under AGPLv3 terms.

What you cannot do is expect the community edition to receive feature development, easy installation paths, or the same level of community engagement that existed prior to May 2025. For teams that adopted MinIO precisely because it was a zero-friction, single-binary drop-in, this shift introduces risk: not immediate breakage, but gradual drift between what you’re running and what the ecosystem assumes. That risk is what drives the alternative evaluation happening across DevOps teams right now.

RustFS: Apache 2.0, Rust-Native, Throughput-Focused

RustFS is an S3-compatible object store written in Rust and licensed under Apache 2.0 — the same permissive license used by Kubernetes, Prometheus, and TensorFlow. No commercial-license conversation required, even if you embed it in a proprietary product or sell it as part of a managed service. It deploys as a single binary or Docker image (rustfs/rustfs:latest on Docker Hub), supports erasure coding for durability, distributed nodes, and S3 Object Lock for compliance workloads like FINRA rule 17a-4(f).

Performance-wise, RustFS targets the small-to-mid-object throughput range where Go’s garbage collector becomes a bottleneck. Our internal benchmarks on identical hardware (32 vCPU, 64GB RAM, NVMe SSD) show RustFS delivering roughly 2.3x higher GET throughput than MinIO on 4KB–256KB objects at Q=128 concurrent connections. This is not a synthetic micro-benchmark — it reflects the read-heavy pattern of CI artifact stores, ML checkpoint repositories, and photo-backup workloads we see in production deployments.

Honest limitations: RustFS launched later than MinIO (open-sourced July 2025 vs MinIO’s 2014), so its ecosystem of third-party integrations, backup-tool plugins, and Stack Overflow answers is smaller. Mixed read-write workloads at extreme scale (petabyte-range, millions of objects/sec) are an area where we’re still investing heavily in 2026. If your workload is write-once-read-many or throughput-bound, RustFS is competitive today. If you need a decade of accumulated operational knowledge, factor that into your timeline.

# Deploy RustFS with Docker (sourced from official README)
docker run -d -p 9000:9000 -p 9001:9001 
  -v $(pwd)/data:/data 
  -v $(pwd)/logs:/logs 
  rustfs/rustfs:latest
# Default credentials: rustfsadmin / rustfsadmin
# S3 API endpoint: http://localhost:9000
# Web console: http://localhost:9001

Ceph (RGW): The Enterprise Heavyweight

Ceph is not a MinIO clone — it’s a unified storage platform that happens to expose an S3-compatible API through its RADOS Gateway (RGW) component. Licensed under LGPLv2.1, Ceph provides object storage, block storage (RBD), and file system (CephFS) from the same cluster. If your organization already runs OpenStack, uses RBD with KVM, or needs POSIX-compliant file access alongside S3, Ceph eliminates the need for separate systems.

The trade-off is operational weight. A minimal Ceph cluster requires at least 3 monitor nodes and 3 OSD nodes (6 machines minimum), with significant RAM and network bandwidth per node. Deployment tools like ceph-ansible or Rook (Kubernetes operator) help, but you’re still operating a distributed system with more moving parts than MinIO or RustFS. Ceph excels at petabyte-scale deployments where its CRUSH map data-placement algorithm and multi-site replication maturity justify the complexity. For a 3-node homelab or a startup’s first object store, Ceph is likely overkill unless you specifically need block+file alongside objects.

SeaweedFS: Lightweight, Fast, Great for Small Clusters

SeaweedFS (formerly WeedFS) fills a different niche: it’s designed for small-to-medium clusters where simplicity and speed matter more than enterprise features. Written in Go and licensed Apache 2.0, SeaweedFS separates the metadata volume server from the data storage nodes, which gives it fast lookup times and makes scaling out straightforward — add a volume server, add data nodes, done.

Where SeaweedFS shines: photo-sharing platforms, edge deployments with limited resources, and any workload storing billions of small files (<1MB). Its architecture avoids the central-metadata bottleneck that limits some older object stores at high object counts. Where it doesn’t shine yet: S3 API compatibility, while functional, lags behind MinIO and RustFS in edge-case behavior (multipart upload corner cases, certain bucket policy implementations). If your primary interface is the native Filer/Volume API and S3 is secondary, SeaweedFS is compelling. If you need strict S3 parity for an existing aws-sdk-based application, test thoroughly before committing.

Garage: Minimalist, French, Homelab-Friendly

Garage (garagehq.deuxfleurs.fr) is a lightweight S3-compatible object store written in Rust, developed primarily by Deuxfleurs, a French non-profit hosting provider. Licensed AGPLv3 (same as MinIO’s core), Garage targets small self-hosted deployments — think 3-node clusters on spare hardware, co-ops, and privacy-focused collectives rather than enterprise data centers.

Garage’s philosophy is deliberate minimalism: no built-in web console (you bring your own or use the CLI), no Kubernetes operator, no enterprise support tier. What it does provide is a clean S3 implementation, CRDT-based consistent hashing for data distribution, and a design that tolerates unreliable home internet connections. If you’re running a small cluster on heterogeneous hardware and want something that works without a dedicated ops team, Garage deserves a look. Be aware that AGPLv3 carries the same embedding considerations as MinIO, and the community (while passionate) is smaller than Ceph’s or RustFS’s.

Wasabi and Backblaze B2: When You Don’t Want Self-Hosted at All

Not every “MinIO alternative” needs to run on your metal. Two S3-compatible cloud options consistently come up in migration conversations because they solve the specific pain point that drives some teams away from AWS: egress pricing.

Wasabi offers hot S3-compatible storage with no egress fees — you pay per TB stored per month, and data transfer out is included. Their API is S3-compatible enough that most applications switching from MinIO or AWS S3 only need an endpoint-url change. The catch: Wasabi’s “no egress” terms include fair-use caps, and performance consistency varies by region. It’s a strong fit for backup targets, media asset libraries, and compliance archives where you want cloud convenience without per-GB transfer bills.

Backblaze B2 takes a different angle: extremely low storage cost ($0.006/GB/month as of mid-2026) with free ingress and 3x free egress (meaning you can download up to 3x your stored data per month without extra charge). B2’s S3 Compatible API covers the core operations but doesn’t implement every S3 feature (no Object Lock, no bucket-level encryption keys in the same way AWS does). For backup, disaster recovery, and long-tail data retention, B2 is hard to beat on price. For primary application storage with active read/write patterns, evaluate whether the API surface coverage meets your needs.

How to Choose: A Practical Framework

You don’t need to benchmark everything. Start with two questions that eliminate most options immediately:

Question 1: Do you need to self-host?

• Yes → Narrow to RustFS, Ceph, SeaweedFS, Garage
• No → Evaluate Wasabi / Backblaze B2 against staying on AWS S3

Question 2: What’s your license requirement?

• Must be permissive (Apache 2.0 / MIT) for commercial embedding → RustFS or SeaweedFS
• LGPL/AGPL acceptable for internal use → Any self-hosted option

Question 3: What’s your cluster scale and ops capacity?

• 1–3 nodes, minimal ops → RustFS (single binary) or SeaweedFS (lightweight)
• 3+ nodes, dedicated ops team → Ceph (enterprise maturity) or RustFS (distributed mode)
• Heterogeneous / unreliable hardware → Garage (tolerant design)

For teams migrating directly from MinIO today, RustFS offers the closest operational similarity (single binary, Docker image, S3 API, erasure coding) with a more permissive license and no community-edition uncertainty.

For about a day it said “Search all 0 listings” — next to a grid full of listings.

The database was fine by then. Three separate bugs conspired, and all three are the same mistake wearing different clothes: a read that degrades politely on failure, sitting underneath a cache that stores the polite answer.

Bug 1: the cache dropped the header the count lived in

PostgREST returns an exact row count in the Content-Range response header if you ask for it, which is far cheaper than selecting rows and counting them:

const res = await fetch(`${URL}/rest/v1/${table}?${query}&select=id&limit=1`, {
  headers: { apikey: KEY, Prefer: 'count=exact', Range: '0-0' },
  next: { revalidate: 3600 },      // ← the bug
});
const total = Number(res.headers.get('content-range').split('/')[1]);

Next’s fetch cache stores the response body and replays it behind a synthetic set of headers. content-range is not one of them. So the first call worked, and every cache hit after it read null and produced 0.

Statically prerendered pages looked perfect — their single fetch happened at build time and was always a miss. Every dynamic route showed zero. If you’re caching a fetch for anything that isn’t in the body, cache the parsed value instead: mark the fetch cache: 'no-store' and wrap the function in unstable_cache. Cache things that survive being cached.

Bug 2: the zero got memoised for an hour

With the count now memoised, the failure path mattered. The read returned 0 when the response wasn’t OK — sensible-looking, and unstable_cache dutifully stored that 0 for the full hour.

So the wrong number outlived the outage. The index came back; the site kept saying zero, and looked completely healthy while doing it. For a directory, “0 listings” isn’t a degraded state, it’s a false claim about the world.

Fix: throw inside the cached function. unstable_cache stores nothing on a throw, so the next request re-reads and the site heals the instant the database answers.

Bug 3: the page containing the zero was also cached

Here’s the one I got wrong twice. The outer catch still returned 0, on what felt like solid reasoning: this zero isn’t memoised, so it lasts exactly as long as the outage.

It missed the other cache. Every route declares revalidate. A background revalidation that renders “Search all 0 listings” writes that sentence into the ISR page cache and serves it for an hour on the landing and a day everywhere else. Not caching the zero doesn’t help when the page containing the zero is the cached artifact.

The worst instance was /opengraph-image, which drew “0 skills · 0 subagents · 0 plugins” onto the share card and pinned it to every link preview for a day. A share card is the one surface where a wrong number gets screenshotted and outlives your cache entirely.

So it rethrows. Throwing is what makes Next keep the last good copy.

The rule that fell out

Not every read should fail loudly. Two here must degrade: the footer’s freshness line, which appears on ~3,500 routes and is one sentence of fine print, and the build-time list behind generateStaticParams, which only decides what gets prerendered. Those go through a separate helper with AbortSignal.timeout(5000) — a plain fetch has no timeout, and a try/catch cannot catch a hang. The footer says “rebuild pending,” which is honest, and the build finishes.

Everything else fails. The test is simple: if the page’s whole reason to exist is that data, an empty render is a lie, and a lie is what gets cached.

The same family of bug shows up without any cache involved. PostgREST caps a response at 1,000 rows no matter what limit you send. A category count computed in JavaScript over limit=20000 therefore summed the first 1,000 of 3,369 rows and published “1,000 listings” — a suspiciously round number that was precisely the cap. The sitemap did it too: 1,070 URLs emitted against 3,516 real ones, silently dropping the entire long tail. Both now read a Postgres view that does the aggregation server-side.

Truncation, a missing header, a caught exception. Every one of them returns a number rather than an error, and a number is believed.

This is how we built SkillWorks, a scored index of Claude Code skills and subagents: https://skillworks.kynth.studio

In React, the architectural freedom makes this separation less explicit — which often leads to questions about where to place logic and how to keep it decoupled from visual concerns.

Angular Services: Organization Through Dependency Injection

Angular services are injectable classes with reusable logic. They’re responsible for sharing state and behavior between components — such as authentication, HTTP calls, component communication, and more.

It’s worth noting that this doesn’t eliminate the need for state management tools like
NgRx or Akita, which are used when an app demands more robust state handling.

Dependency injection makes services easily accessible across the application:

@Injectable({ providedIn: 'root' }) 
export class NotificationService { 
  show(message: string) {
    /* display toast */
  }
}

React: Architectural Diversity as a Feature

React doesn’t enforce a structure for separating logic from UI — which brings flexibility, but also responsibility. Teams need to define patterns that keep the codebase consistent.

Common approaches to separating logic in React include:

• Headless Components (a.k.a. logic-only or controller components)
• Custom Hooks
• Context API
• Declarative Composition
• External Modules (like auth.ts, useUser.ts, etc.)

Example: Parent Provides Store Data to Child

Scenario: The Parent component extracts data from a store and passes it to Child via props. Child is completely decoupled from data sources, making it reusable anywhere in the app.

// Parent.tsx
import { useUserStore } from './stores/useUserStore';
import { Child } from './Child';

export function Parent() {
  const { user } = useUserStore();

  if (!user) return null; // or a spinner

  return <Child name={user.name} />;
}

// Child.tsx
export function Child({ name }: Props) {
  return <p>Hello, {name}!</p>;
}

// App.tsx
import { Parent } from './Parent';

export default function App() {
  return (
    <main>
      <h1>Headless Component Example</h1>
      <Parent />
    </main>
  );
}

Benefits of This Pattern:

• Child is pure, testable, and reusable.
• Parent acts as a logic adapter, fetching store data and injecting it into children.
• Logic is separated from UI, supporting scalability.

Angular Services × React Patterns: A Direct Comparison

Headless Components: Components that render nothing but execute logic or handle side effects.

Declarative, reusable, and live inside the JSX tree. They’re like “visible services” in React, organizing logic outside of UI rendering.

function AnalyticsTracker() {
  useEffect(() => {
    trackPageView();
  }, []);
  return null;
}

Custom Hooks: Functions that encapsulate reusable logic based on React hooks.

Extract business rules (e.g., async calls, validations), improving testability and reuse across components.

function useAuth() {
  const [user, setUser] = useState(null);
  useEffect(() => {
    // fetch user data
  }, []);
  return { user };
}

Context API: React’s built-in solution for sharing data without prop drilling.

Great for themes, authentication, language, or global events. Combined with hooks, behaves like a mini store.

const UserContext = createContext(null);
function useUser() {
  return useContext(UserContext);
}

Declarative Composition: Controls logic and behavior via JSX components instead of scattered if or switch statements.

<When condition={user.isAdmin}>
  <AdminPanel />
</When>

Makes UI more readable and component-driven, replacing complex conditionals with declarative expressions.

Final Thoughts

React doesn’t require you to separate UI and logic — but doing so makes your code more scalable, testable, and maintainable.

Headless components and custom hooks are powerful ways to encapsulate logic without compromising presentation. They align well with React’s declarative and compositional model.

Even if not always reusable, these patterns keep child components flexible and ready to work with different data sources or contexts.

In the end, the absence of Angular-like services in React isn’t a limitation — it’s an opportunity to
build architecture tailored to your application’s needs.

In the world of Confidential Computing, we don’t rely on “hope.” We rely on hardware. Today, we’re diving deep into Privacy Computing and Trusted Execution Environments (TEE). We’ll build a secure inference pipeline using Intel SGX, Gramine, and C++ to ensure that your health models stay private and your user data stays encrypted, even from the root user of the host machine.

Why TEE? The “Black Box” of Computing

In a standard cloud environment, the OS, Hypervisor, and Root Admin have total visibility into your application’s memory. If you’re running a sensitive health model, that’s a massive attack surface.

Intel SGX (Software Guard Extensions) changes the game by creating an Enclave—a protected area in memory. Even if the OS is compromised, the data inside the enclave remains encrypted.

The Data Flow Architecture

To understand how we protect the inference process, let’s look at the lifecycle of a request:

sequenceDiagram
    participant User as 👤 Patient/App
    participant Host as 🖥 Untrusted Host (Cloud)
    participant Enclave as 🔒 Intel SGX Enclave (Gramine)

    User->>Host: Send Encrypted Health Data (AES-GCM)
    Host->>Enclave: Forward Ciphertext to Inference Engine
    Note over Enclave: Decrypts data inside protected memory
    Enclave->>Enclave: Runs C++ Inference (Model Weights Protected)
    Enclave->>Enclave: Encrypts Prediction Result
    Enclave->>Host: Return Encrypted Result
    Host->>User: Deliver Ciphertext prediction
    Note over User: User decrypts result locally

Prerequisites

Before we start, ensure your environment supports:

• Hardware: Intel CPU with SGX support (check /dev/sgx_enclave).
• Software: Docker, Gramine (the best Library OS for SGX), and a C++ compiler.
• Knowledge: Basic understanding of Linux and containerization.

Step 1: The Secure C++ Inference Engine

We’ll write a simple C++ “Inference Engine.” In a real-world scenario, this would load a TensorFlow or ONNX model. For this tutorial, we’ll simulate the logic of processing heart rate data.

// inference_engine.cpp
#include <iostream>
#include <string>
#include <vector>

// In a real TEE, we would use an SGX-compatible crypto library like IPP or OpenSSL
void perform_inference(const std::string& input_data) {
    std::cout << "[Enclave] Processing sensitive health data..." << std::endl;

    // Simulate model logic: "If heart rate > 100 while resting, flag it"
    int heart_rate = std::stoi(input_data);
    std::string result = (heart_rate > 100) ? "Risk Detected" : "Normal";

    std::cout << "[Enclave] Result: " << result << std::endl;
}

int main() {
    std::string secret_data;
    // In a real scenario, this input is decrypted inside the enclave
    while (std::getline(std::cin, secret_data)) {
        if (secret_data == "exit") break;
        perform_inference(secret_data);
    }
    return 0;
}

Step 2: Containerizing with Docker

To make this portable, we use Docker. However, standard Docker containers aren’t secure. We need to wrap our app with Gramine, which acts as a bridge between the Linux binary and the SGX hardware.

FROM gramineproject/gramine:latest

# Install build essentials
RUN apt-get update && apt-get install -y build-essential

# Copy our source code
COPY inference_engine.cpp /app/inference_engine.cpp
WORKDIR /app

# Compile the binary
RUN g++ -O3 -o health_inference inference_engine.cpp

# Generate SGX-specific configuration (Manifest)
COPY health_inference.manifest.template /app/health_inference.manifest.template

Step 3: The Secret Sauce: Gramine Manifest

The .manifest file tells Gramine which files to trust and how much enclave memory (EPC) to allocate. This is where you define your Trusted Computing Base (TCB).

# health_inference.manifest.template
loader.entrypoint = "file:{{ gramine.libos }}"
libos.entrypoint = "/app/health_inference"

loader.log_level = "error"

# Enclave size: 256MB
sgx.enclave_size = "256M"
sgx.thread_num = 4

# Trusted files (Files that shouldn't be tampered with)
sgx.trusted_files = [
  "file:{{ gramine.libos }}",
  "file:/app/health_inference",
  "file:{{ gramine.runtimedir }}/",
]

# Allowed files (Log files, etc.)
sgx.allowed_files = [
  "file:/etc/hosts",
]

The “Official” Way to Production

While building a DIY enclave is a great way to “learn in public,” running health models at scale requires rigorous attestation and key management.

For advanced patterns, such as Remote Attestation (proving to the user that the code running in the enclave is exactly what you claimed) or Production-Ready Secure Architectures, I highly recommend checking out the technical deep dives at wellally.tech/blog. They cover the nuances of hardware-level security that are vital for HIPAA and GDPR compliance in the AI era.

Step 4: Building and Running

Once your manifest is ready, you need to “sign” your enclave. This generates a measurement (MRENCLAVE) which is a cryptographic hash of your entire app environment.

# Inside the container
gramine-sgx-sign 
    --manifest health_inference.manifest.template 
    --output health_inference.manifest

# Run it!
gramine-sgx health_inference

If everything is configured correctly, Gramine will initialize the SGX enclave, load your C++ binary into protected memory, and start processing. Even if someone tries to dump the RAM of your process from the host OS, they’ll only see encrypted garbage.

Conclusion: Privacy is a Feature, Not an Afterthought

Privacy computing is no longer a niche academic topic. With the rise of “AI-on-Health,” users are demanding that their most intimate data remains theirs. Using Intel SGX and Gramine allows us to build a future where we can gain insights from data without ever actually “seeing” it.

What’s next?

1. Try integrating OpenSSL inside the enclave for end-to-end encryption.
2. Explore Remote Attestation to build trust with your clients.
3. Drop a comment below if you want a tutorial on running PyTorch models inside SGX!

Happy (and secure) hacking!

Visit BanglaTools to try the free Unicode to Bijoy converter, Bijoy to Unicode converter, and document export tools.

What it helps with

• Convert Bangla text between Unicode and Bijoy formats in the browser.
• Keep a quick copy/paste workflow for editing and checking text.
• Export converted text to DOCX or XLSX when a document is needed.

The goal is a focused utility that works without a desktop install. It is useful for writers, students, editors, and developers who still encounter both encoding systems in real projects. Feedback on edge cases and uncommon Bangla characters is welcome.

Originally published (in Japanese) at forge.workstyle.tech.

Running an inference service as a background process on macOS, with a Linux server mindset, can lead to subtle issues. Things like “a one-liner that works on Linux doesn’t work on Mac” or “grepping logs results in garbled text errors and crashes” — these are minor but time-consuming problems.

This article compiles a collection of short tips gathered from running a Seed-VC based voice conversion service (FastAPI + uvicorn, local 127.0.0.1:8770) as a background process on macOS. It focuses on macOS-specific pitfalls not covered in Linux-centric articles.

TIP 1: setsid / timeout are not available on macOS

First, it’s important to note that macOS (BSD-based) does not include GNU coreutils’ setsid or timeout by default. If you use these commands, which are used for backgrounding and timed execution on Linux, directly in a Mac script, you’ll get a command not found error.

There are two solutions:

• Install coreutils via Homebrew and use gsetsid/gtimeout
• Use standard tools as alternatives (next TIP)

For background scripts that avoid external dependencies, using standard tools as alternatives is a safer option.

TIP 2: Use nohup + disown for background processes

In environments without setsid, the combination of nohup and disown is reliable for keeping processes alive even after closing the shell.

# Run the inference service as a background process
nohup bash scripts/start-backend.sh > backend.log 2>&1 &
disown

• nohup … Ignores hangup signals (SIGHUP), keeping the process alive even after the terminal is closed
• > backend.log 2>&1 … Redirects standard output and standard error to a log file
• & … Runs the process in the background
• disown … Removes the job from the shell’s job table, preventing it from being terminated when the shell is closed

While nohup alone usually keeps the process alive, adding disown ensures that closing the terminal won’t accidentally terminate the process.

TIP 3: tr / grep fail with binary data in logs → use LC_ALL=C

This was the most problematic issue on Mac. Inference logs may contain progress bar control characters or, occasionally, garbled multibyte sequences. When processed by macOS’s tr or grep, you’ll see:

tr: Illegal byte sequence

This happens because the locale is set to UTF-8, causing invalid byte sequences to be treated as “invalid characters” and throwing an exception.

The solution is to set the locale to C (pass-through as byte sequences) for those commands.

# Remove unwanted control characters from logs (avoids Illegal byte sequence)
LC_ALL=C tr -d 'r' < backend.log > backend.clean.log
LC_ALL=C grep "ERROR" backend.log

Setting LC_ALL=C treats text as “bytes” rather than “characters,” preventing crashes due to invalid sequences. This is safer for pipelines that process or search logs programmatically.

TIP 4: Wait for startup completion using the health endpoint

Loading models takes time, so sending requests immediately after starting with nohup will fail because the service isn’t ready. Using sleep 10 as a workaround is unreliable—too short for slow machines and too long for fast ones.

The proper approach is to poll the service’s health endpoint until it returns a 200 status. In this setup, the health endpoint is http://127.0.0.1:8770/health, so we poll it.

# Wait for the health endpoint to be ready before proceeding
until curl -sf http://127.0.0.1:8770/health >/dev/null; do
  sleep 1
done
echo "backend ready"

curl -sf exits with a non-zero status on failure, so combining it with until allows you to wait until the service is ready. Waiting based on state, not a fixed delay, significantly improves the reliability of startup scripts.

TIP 5: Stop processes with pkill using pattern matching

For background processes without a saved PID, pkill with a command-line pattern is convenient for stopping them.

# Stop the inference service started with uvicorn
pkill -f "uvicorn server:app"

The -f option matches the entire command line, so including specific details like the port or app name in the pattern prevents unrelated processes from being affected. For more precision, save the PID during startup and target it directly.

Summary

• macOS does not have setsid/timeout. Either install Homebrew’s coreutils (gsetsid/gtimeout) or use standard tool alternatives
• Use nohup ... & disown for background processes. Ignore SIGHUP and remove the job from the job table to prevent termination when the terminal is closed
• Binary data in logs causes tr/grep to fail with Illegal byte sequence → Temporarily set LC_ALL=C to treat data as byte sequences
• Instead of fixed sleep delays, poll the health endpoint with until curl -sf to wait based on state
• Stop processes with pkill -f "specific pattern". Use a detailed pattern to avoid affecting unrelated processes

When a user taps a push notification, the entry point differs depending on whether the app is running. If you only use one listener with Expo Router to navigate to the notification target screen, you may miss launches from the terminated state.

In my app, I handle both cases with two separate mechanisms:

• getLastNotificationResponseAsync(): when the app launches from a notification tap
• addNotificationResponseReceivedListener(): when a notification is tapped while the app is running

Structuring Notification Data

The notifications sent from the server include the destination path in data.url.

{
  title: "Attendance Deadline Reminder",
  body: "Please confirm your attendance for tomorrow's practice",
  data: {
    url: "/organizations/org_123/schedules/schedule_456"
  }
}

Rather than parsing the displayed title or body to determine the destination, I pass a path the app can handle as separate data.

Handling Launch from Notification

When the app is in a terminated state, I check for the last notification response after launch.

void Notifications.getLastNotificationResponseAsync().then((response) => {
  if (response) {
    handleNotificationTap(response.notification);
  }
});

This process is asynchronous. If you call router.push before verifying authentication or before the Navigator is ready, navigation can conflict. In my app, I run this after the login check completes.

useRegisterPushToken(authChecked);

Handling Notification Taps While Running

When a notification is tapped from either the background or foreground, the listener receives it.

const subscription =
  Notifications.addNotificationResponseReceivedListener((response) => {
    handleNotificationTap(response.notification);
  });

return () => subscription.remove();

To avoid duplicate listeners from screen remounts or Fast Refresh, I call remove() in the cleanup.

Unifying Both Entry Points

Although the entry points differ, notification data validation and navigation are shared.

function handleNotificationTap(notification: Notifications.Notification) {
  const data = notification.request.content.data as
    | { url?: string; linkUrl?: string }
    | null;

  const raw = data?.url ?? data?.linkUrl;
  if (!raw) return;

  const path = raw.startsWith("/")
    ? raw
    : (raw.match(/^https?://[^/]+(/.+)$/)?.[1] ?? null);

  if (!path) return;
  router.push(path as never);
}

For backward compatibility with previously sent notifications, I accept both url and linkUrl. For new implementations, using a single key is simpler.

Also, passing externally provided URLs directly to router.push is less safe. I define allowed hosts and path formats, converting them to app-internal routes before passing.

Not Navigating on Received Notification

addNotificationReceivedListener and addNotificationResponseReceivedListener serve different purposes.

Notifications.addNotificationReceivedListener((notification) => {
  // When notification is received
});

Notifications.addNotificationResponseReceivedListener((response) => {
  // When user taps the notification
});

Switching screens immediately when a notification arrives can disrupt the user’s current screen, such as an input form. In my app, screen navigation happens only with the response after a tap.

Unified Hook

Simplifying the actual structure, it looks like this:

export function useNotificationNavigation(enabled: boolean) {
  useEffect(() => {
    if (!enabled) return;

    let active = true;

    void Notifications.getLastNotificationResponseAsync().then((response) => {
      if (active && response) {
        handleNotificationTap(response.notification);
      }
    });

    const subscription =
      Notifications.addNotificationResponseReceivedListener((response) => {
        handleNotificationTap(response.notification);
      });

    return () => {
      active = false;
      subscription.remove();
    };
  }, [enabled]);
}

Rather than treating launches from the terminated state and taps while running as the same thing, separating the entry points and then passing them to a common navigation function made the structure easier to maintain.

References

• Expo Notifications
• Expo: Handle incoming notifications

Here’s the whole system, verified against the current docs.

The 30-second version

A subagent is one Markdown file with YAML frontmatter:

---
name: code-improver
description: "Scans files and suggests improvements for readability, performance, and best practices. Use after writing or modifying code."
tools: Read, Grep, Glob
model: sonnet
---

You are a code review specialist. When given files, analyze them for
readability, performance, and adherence to best practices. Report
concrete, minimal suggestions with file:line references.

Where you put it decides who gets it:

• .claude/agents/ in your project → this project (usually committed, so your team shares it)
• ~/.claude/agents/ → every project on your machine

Both locations are scanned recursively, so you can organize files into subfolders like agents/review/. The subfolder path changes nothing about how the agent is identified — identity comes only from the name field, not the filename or path.

Only name and description are required. Everything else is optional.

Delegation is just description matching

Claude reads every subagent’s description and decides to delegate when a task matches it. That’s the entire routing mechanism. There is no registration step, no config toggle — the quality of your description is the trigger.

Which means the most common failure is writing a description like a title:

# never gets used
description: Database expert

# gets used
description: Reviews SQL queries and schema changes for slow patterns,
  missing indexes, and migration risks. Use when SQL or migration files change.

The second one works because it describes when to delegate, not just what the agent is. If you want delegation to happen without being asked, say so in the description — phrasing like “use proactively after code changes” is exactly what the official examples do.

You can always bypass routing and invoke one explicitly: “Use the code-improver subagent on the files I just changed.”

The fields that actually matter

The full frontmatter list is longer, but these are the ones I reach for:

Two sharp edges in tools: the entries must resolve to real tool names — if none of them do, the subagent fails to launch with an error naming the bad entries. And if you want a Skill preloaded, use the skills field; listing Skill in tools only grants the invocation tool, it doesn’t load anything.

One sharp edge in name: lowercase letters and hyphens, and no : — colons are reserved for plugin-scoped identifiers like my-plugin:reviewer. Current versions refuse to load a file whose name contains one, and the only symptom is a line in the debug log.

Precedence: who wins when names collide

When multiple subagents share a name, the higher-priority location wins: managed (organization-deployed) definitions beat project definitions, which beat user definitions, which beat plugin agents. Across nested project directories, the definition closest to your working directory wins.

The dangerous case is two files with the same name under the same .claude/agents/ tree — including subfolders. Claude Code loads only one, chosen by filesystem read order, not by any documented rule. Nothing warns you at runtime; your carefully updated definition may simply not be the one running. /doctor reports same-directory duplicates, so run it whenever a subagent behaves like an older version of itself.

Also worth knowing: a project or user subagent named Explore overrides the built-in read-only Explore agent. That’s occasionally useful (for example, pinning exploration to a cheaper model with model: haiku) — and occasionally an accident, when someone names a general agent “explore” and quietly replaces the built-in.

A note on the /agents command

Older writeups tell you to run /agents for an interactive creation wizard. That wizard is gone in current versions — /agents now just points you at editing .claude/agents/ directly, or you ask Claude to write the file for you. The file format and locations didn’t change, so any existing agent files keep working.

Debug checklist

When a subagent isn’t being used, this order finds it fastest:

1. Does the file load at all? Name has a colon, or YAML is malformed → silently skipped. Check the debug log.
2. Is your definition the one running? Duplicate name anywhere in the tree → run /doctor.
3. Does the description say when to use it? Rewrite it as a trigger condition, not a job title.
4. Do the tools entries resolve? A typo like Greps fails the launch with a zero-tools error.
5. Still nothing? Invoke it explicitly by name once. If explicit invocation works but automatic delegation doesn’t, it’s always the description.

I publish daily practical notes on Claude Code, Cursor, and Codex on Bluesky — @ai-shop.bsky.social. The tested skill and rules packs I maintain live at Rulestack.

1. Why AI-Generated Code Can Look Correct but Still Fail

AI coding tools generate code by predicting patterns from your prompt, the surrounding code, and examples they were trained on. They don’t understand your application the way your engineering or product team does.

Take this simple discount function:

function calculateDiscount(total: number, isPremium: boolean): number {
  if (isPremium) {
    return total * 0.2;
  }
  return total * 0.1;
}

It’s valid TypeScript. It might even pass a basic test. But it leaves real questions unanswered:

• Should non-premium users always get a discount?
• Is there a minimum order value?
• Is the discount capped?
• Does it apply to tax or shipping?
• What happens with a negative total?
• Can it stack with other promotions?

The code can be technically correct while still violating the actual business requirement. QA testing validates behavior, not just syntax – and that distinction is the core reason this whole article exists.

2. Five Ways AI-Generated Code Goes Wrong

2.1 Misunderstood Business Requirements

AI-generated code often solves a slightly different problem than the one the business actually needs solved.

Say the rule is: “Users can access premium features until the end of their paid billing period, even after cancelling renewal.”

A generated check might look like this:

function canAccessPremium(subscription: Subscription): boolean {
  return subscription.status === 'active';
}

This revokes access the moment status flips to cancelled – even though the customer already paid for the remaining period. A correct version needs to consider the expiry date instead:

function canAccessPremium(
  subscription: Subscription,
  now: Date = new Date()
): boolean {
  return subscription.expiresAt > now;
}

QA needs to check the real scenarios: active, cancelled-but-paid, expired, failed renewal, trial, grace period, refunded. Skip these, and you get billing disputes and angry support tickets not compiler errors.

2.2 Hidden Edge Cases

AI-generated code tends to handle the happy path well and little else. Production doesn’t stay on the happy path it deals with empty values, invalid formats, duplicate requests, slow networks, API failures, and concurrent updates.

function isValidEmail(email: string): boolean {
  return email.includes('@');
}

This happily accepts @, user@, and @domain.com. A stronger version and a test suite that defines exactly which formats your app accepts closes that gap:

describe('isValidEmail', () => {
  it('accepts a valid email', () => {
    expect(isValidEmail('user@example.com')).toBe(true);
  });
  it('rejects an empty value', () => {
    expect(isValidEmail('')).toBe(false);
  });
  it('rejects a missing domain', () => {
    expect(isValidEmail('user@')).toBe(false);
  });
  it('rejects a missing username', () => {
    expect(isValidEmail('@example.com')).toBe(false);
  });
});

AI can absolutely write tests like these the risk is that it generates them based on the same incomplete assumptions as the original code.

2.3 Hidden Security Problems

Working code isn’t the same as safe code. Common risks in AI-generated output include missing input validation, SQL injection, broken access control, and weak auth logic.

const query = `SELECT * FROM users WHERE email = '${email}'`;
const result = await database.query(query);

This runs fine in testing and opens an SQL injection hole in production. A parameterized query fixes it:

const result = await database.query(
  'SELECT * FROM users WHERE email = $1',
  [email]
);

Access control slips through just as easily:

app.delete('/api/documents/:id', authenticate, async (req, res) => {
  await documentRepository.delete(req.params.id);
  res.status(204).send();
});

This checks that a user is logged in not that they own the document. Any authenticated user could delete anyone’s file. Security testing needs to specifically cover authentication, role permissions, resource ownership, tenant isolation, and rate limits not just “does it run.”

2.4 Integration Failures

AI-generated code is usually tested in isolation, but production systems are made of many connected parts: frontend, backend, database, payment providers, queues, third-party APIs.

A function can work perfectly alone and still fail once it’s wired up. For example, the frontend expects:

{ "userId": "123", "fullName": "Maya Shah" }

but the generated backend returns:

{ "id": "123", "name": "Maya Shah" }

Both are reasonable on their own and incompatible together. Integration and regression testing catch this class of bug: mismatched fields, wrong types, broken event payloads, and small AI-generated changes that quietly break features that already worked.

2.5 Performance Problems

Logically correct code can still be slow. Classic example an N+1 query:

const orders = await orderRepository.findAll();

for (const order of orders) {
  order.customer = await customerRepository.findById(order.customerId);
}

Fine with 10 orders. A serious problem with 10,000. Other common issues: repeated API calls, missing indexes, loading full datasets into memory, and missing pagination. Performance testing needs to reflect realistic data volumes, not just the sample size in the original prompt.

3. Why AI-Generated Tests Aren’t Enough on Their Own

AI is genuinely useful for scaffolding tests templates, mocks, sample data, common failure cases. But generated tests shouldn’t be treated as independent proof of correctness, because the same model can write both the bug and the test that confirms it.

function calculateShipping(total: number): number {
  return total > 100 ? 0 : 10;
}

it('returns free shipping above 100', () => {
  expect(calculateShipping(150)).toBe(0);
});

This test passes because it repeats the same assumption baked into the function. If the real rule is “free shipping at ₹1,000 or more, excluding tax,” both the code and the test are wrong, and the green checkmark tells you nothing.

AI-generated tests also tend to lean on happy paths only, use weak assertions, over-mock dependencies, and validate implementation details instead of actual business outcomes. Use AI to speed up test creation but have a human confirm the tests reflect the real requirement, not just the code as written.

4. Testing Types AI-Generated Code Needs

Not every feature needs the same depth of testing. A text-formatting helper doesn’t carry the same risk as a payment workflow match testing effort to business impact.

5. A Practical QA Workflow

Define the requirement
        ↓
Generate code with AI
        ↓
Review the generated output
        ↓
Run linting and static analysis
        ↓
Create and review test cases
        ↓
Run unit and integration tests
        ↓
Test edge cases and permissions
        ↓
Deploy to staging
        ↓
Perform human validation
        ↓
Deploy and monitor

Define the requirement clearly – document expected inputs, outputs, business rules, failure behavior, permissions, and performance expectations before generating code.

Review the generated code – check it against your architecture, approved libraries, error handling, naming conventions, and how it handles sensitive data.

Run automated quality checks – linters, type checkers, static analysis, dependency scanners, and CI quality gates as a fast first filter.

Test realistic scenarios – go beyond the prompt’s example. Invalid inputs, slow services, duplicate actions, expired data, unauthorized users, large datasets.

Validate in staging – against systems that resemble production: real databases, real APIs, real permission structures.

Monitor after deployment – no amount of pre-release testing predicts every production scenario. Track error rates, slow requests, failed transactions, and unexpected logs.

6. When Extra QA Is Non-Negotiable

Some categories of code deserve more scrutiny than others, because the cost of a defect is disproportionately high:

• Payments
• Authentication
• Subscription access
• Personal or healthcare data
• Financial calculations
• User permissions
• Database migrations
• File deletion
• Legal or compliance workflows

AI can help generate the implementation for these – but final responsibility has to stay with the engineering and QA team. A small defect here doesn’t just mean a bug ticket; it can mean financial loss, data exposure, or a compliance violation.

7. Best Practices Checklist

• Provide clear requirements and constraints upfront
• Treat generated code as a draft, not a finished product
• Review every external dependency it pulls in
• Test business rules separately from implementation logic
• Include negative and boundary-condition tests
• Verify authentication and authorization explicitly
• Run automated checks before merging
• Validate in a staging environment that mirrors production
• Keep a human accountable for final approval
• Monitor production behavior after release

The goal isn’t to avoid AI-generated code it’s to use it without lowering your engineering standards.

8. Final Thoughts

AI coding tools can dramatically improve development speed, but faster implementation doesn’t automatically mean higher-quality software. Generated code can compile and pass basic tests while still carrying incorrect business logic, missing edge cases, security holes, integration mismatches, or performance problems.

QA testing is what turns generated output into verified software. AI can write code, suggest tests, and flag possible issues but it can’t replace the responsibility of understanding requirements, weighing risk, and confirming the system behaves correctly.

AI can generate code quickly. Only testing can give you confidence it works correctly in the real world.

Related Reading

• AI and the Future of Work: How Businesses and Employees Can Prepare for AI
• How AI is Transforming Flutter App Development in 2026
• AI in FinTech: Use Cases, Benefits, Challenges, and Future Trends
• Vibe Coding vs Traditional Programming vs AI-Assisted Development

Facebook Developer Tools MCP คืออะไร? — คู่มือ Meta MCP สำหรับคนทำโฆษณา วิเคราะห์ข้อมูล และ Automation

โดย Nokka (นก-กา) | 2 สิงหาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4-pro) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ — Nokka (นก-กา)

ถ้าคุณทำโฆษณา Facebook หรือดูแลระบบ Marketing API ของ Meta มาก่อน คงรู้ดีว่าการเช็คสถานะแอป เช็ค API health หรือตั้งค่า webhook เป็นงานที่ต้องสลับหลายหน้าจอไปมา

บางทีต้องเปิด Ads Manager คู่กับ Business Manager คู่กับ Events Manager แล้วยังต้องไปอ่าน API changelog อีก

Meta เปิดตัว Developer Tools MCP เมื่อกลางปี 2026 เพื่อให้ AI agent หรือ IDE assistant เข้าถึงข้อมูลเหล่านี้ได้จากจุดเดียว ผ่าน Model Context Protocol (MCP)

MCP เป็นสตандарต์ที่ Anthropic เริ่ม และตอนนี้ OpenAI, Cursor, Claude Desktop ก็รองรับแล้ว

ในมุมมองของผม สิ่งนี้ไม่ได้เปลี่ยนวิธีทำโฆษณาโดยตรง แต่เปลี่ยนความเร็วของ debugging, analytics และ automation ที่อยู่รอบๆ การทำโฆษณา

Meta ระบุว่า MCP ตัวนี้กำลังเปิดให้ใช้ทยอยๆ (rolling out gradually) ดังนั้นบาง account อาจยังไม่เห็นตัวเลือกนี้ในทันที [1]

Developer Tools MCP ทำงานยังไง

Meta Developer Tools MCP server เป็นตัวกลางที่เชื่อมต่อ AI assistant ของคุณเข้ากับแพลตฟอร์มนักพัฒนาของ Meta โดยตรง [1]

ข้อดีคือ ไม่ต้องไปหา App ID หรือ App Secret มาใส่ใน config แค่ล็อกอินด้วย Meta account ผ่าน OAuth แล้วเลือกว่าจะให้ AI agent เข้าถึงแอปไหนบ้าง

จากนั้น agent ก็สามารถอ่านข้อมูลหรือจัดการ webhook subscription ได้ตามสิทธิที่คุณกำหนด [1]

10 เครื่องมือที่เปิดให้ AI agent ใช้

Developer Tools MCP เปิดให้ agent เรียกใช้งานได้ 10 เครื่องมือ แบ่งเป็น 2 กลุ่มหลักๆ [1]

กลุ่มอ่านข้อมูล (Read scope)

1. devtools_app_list — ดูรายชื่อแอปที่คุณมีสิทธิ์เข้าถึง พร้อมบอกบทบาท (developer, admin, tester) และสิทธิ์ที่ให้ไว้ (read หรือ manage)

2. devtools_app — อ่านการตั้งค่า สิทธิ์ และคอนฟิกของแอป เช่น basic settings, advanced settings, security configuration, platform restrictions

3. devtools_app_review — เช็คสถานะ App Review ว่าแอปขอสิทธิ์หรือฟีเจอร์อะไรไปแล้ว อนุมัติหรือยัง

4. devtools_compliance — เช็คสถานะ compliance ของแอป ว่ามี violation หรือ required actions อะไรตกค้างอยู่หรือไม่

5. devtools_api_usage — ดู API health ของแอป รวมถึง rate limit ที่ใกล้เต็มหรือไม่ call volume เป็นอย่างไร และมี API ไหนที่กำลังจะเลิกใช้ (deprecated) บ้าง

6. devtools_webhook_list — ดูรายชื่อ webhook topic ที่แอปสามารถ subscribe ได้ และว่าตอนนี้ subscribe อะไรไว้แล้วบ้าง

7. devtools_api_changelog — ค้นหา changelog product ของ Meta และ RSS feed URL เพื่อติดตามว่ามีอะไรเปลี่ยนแปลงเร็วๆ นี้

8. devtools_discovery — ค้นหาเอกสาร official ของ Meta ได้ด้วยคำถามธรรมชาติ เช่น “how to set up WhatsApp Cloud API webhooks”

กลุ่มจัดการ (Manage scope — เขียนได้เฉพาะ webhook)

9. devtools_webhook_manage — สร้าง อัปเดต หรือลบ webhook subscription ของแอป โดยต้องมี callback URL ที่เป็น HTTPS และผ่านการ verify จาก Meta แล้ว

10. devtools_webhook_test — ส่ง test payload ไปยัง webhook subscription เพื่อตรวจสอบว่า endpoint รับ event ได้จริง

จุดสำคัญคือ write access ของ MCP นี้มีแค่ webhook management เท่านั้น ตัว agent ยังไม่สามารถแก้ campaign budget, สร้างโฆษณา หรือเปลี่ยน targeting ได้โดยตรง [1]

ตั้งค่าในเครื่องมือที่คนทำโฆษณาใช้บ่อย

Meta ออกแบบให้รองรับหลาย client ตั้งแต่ Claude Code, Claude Desktop, OpenAI Codex App, ChatGPT ไปจนถึง Cursor [1]

Claude Code

claude mcp add --transport http meta_developer_tools https://mcp.facebook.com/devtools

จากนั้นพิมพ์ /mcp ในเซสชันแล้วเลือก meta_developer_tools เพื่อล็อกอิน

Claude Desktop

ไปที่ Settings > Connectors > Add custom connector แล้วตั้งค่า:

• Type: HTTP
• URL: https://mcp.facebook.com/devtools

OpenAI Codex App

ไปที่ Settings > MCP Servers > Add servers เลือก Streamable HTTP แล้วใส่:

• Name: Meta Developer Tools
• URL: https://mcp.facebook.com/devtools

ChatGPT (ต้องเปิด Developer Mode ก่อน)

ไปที่ Settings > Connectors > Advanced settings เปิด Developer Mode จากนั้นสร้าง connector ใหม่ด้วย URL https://mcp.facebook.com/devtools

Cursor

เพิ่มลงใน ~/.cursor/mcp.json หรือ .cursor/mcp.json ของโปรเจกต์:

{
  "mcpServers": {
    "MetaDeveloperTools": {
      "url": "https://mcp.facebook.com/devtools",
      "type": "http"
    }
  }
}

หลังบันทึก Cursor จะแสดง “Meta Developer Tools” ในหน้า Tools & Integrations พร้อมปุ่ม Needs login ให้คลิกเพื่อเริ่ม OAuth flow [1]

สิทธิ์ Read กับ Manage ต่างกันอย่างไร

Meta แบ่งสิทธิ์เป็น 2 ระดับ ตั้งค่าได้ต่อแอปผ่าน Settings > Business Integrations บน Facebook [1]

คำแนะนำของผมคือ เริ่มจาก Read scope ก่อน อย่างน้อย 1-2 สัปดาห์ จนมั่นใจว่า agent อ่านข้อมูลได้ถูกต้อง ค่อยเปิด Manage สำหรับงาน webhook เฉพาะที่จำเป็นจริงๆ

คนทำโฆษณาเอาไปใช้อะไรได้บ้าง

ถึง MCP นี้ชื่อ Developer Tools แต่คนทำโฆษณาที่มีแอปของตัวเองบน Meta หรือทีมที่ดูแล Conversion API (CAPI), Pixel, Lead Ads สามารถเอาไปใช้ได้หลายอย่าง

ด้านล่างนี้คือห้าการใช้งานที่เห็นผลเร็วที่สุด

1. ตรวจสุขภาพแอปและ API ก่อนรันแคมเปญใหญ่

ก่อนที่จะเท budget หนักใน campaign ใหญ่ ให้ agent เช็ค devtools_api_usage ว่าแอปใกล้ชน rate limit หรือไม่ API ไหนที่ใช้อยู่กำลังจะเลิกใช้หรือเปล่า และ devtools_compliance ว่ามี violation ค้างอยู่หรือไม่

เคยมีหลายครั้งที่ campaign ดันไม่ได้เพราะ API token ถูกจำกัดหรือแอปติด compliance action ซึ่งถ้าเช็คก่อนได้จะประหยัดเวลาไปได้เป็นชั่วโมง

2. ติดตาม App Review สำหรับสิทธิ์พิเศษ

บางฟีเจอร์ของ Meta เช่น WhatsApp Business API, Lead Access หรือ Advanced Matching ต้องผ่าน App Review ก่อน ใช้ devtools_app_review ถาม agent ได้ว่าแอปของคุณได้รับการอนุมัติสิทธิ์ไหนบ้างแล้ว ยังขาดอะไร ต้อง submit อะไรเพิ่ม

3. จัดการ webhook สำหรับ Lead Ads หรือ Messenger

ถ้าคุณรับ lead จาก Facebook Lead Ads แล้วส่งเข้า CRM ผ่าน webhook การ subscribe topic ผิดหรือ callback URL มีปัญหาจะทำให้ lead หายได้ ด้วย devtools_webhook_list, devtools_webhook_manage และ devtools_webhook_test คุณสามารถให้ agent ช่วยตรวจสอบและส่ง test event เพื่อยืนยันว่าทุกอย่างทำงานจริง [1]

4. ติดตาม changelog ของ Marketing API

Meta เปลี่ยนแปลง Marketing API บ่อย บางครั้ง field ที่ใช้ดึง insights หายไปหรือเปลี่ยนชื่อ ใช้ devtools_api_changelog ให้ agent ดึง RSS feed แล้วสรุปว่ามีอะไรเปลี่ยนแปลงในช่วง 7-14 วันที่ผ่านมา ก่อนที่รายงานประจำสัปดาห์จะพัง

5. ค้นหาเอกสาร official ด้วยคำถามธรรมชาติ

แทนที่จะเปิด Meta for Developers แล้วค้นหาเอง ให้ agent ใช้ devtools_discovery ถามว่า “วิธีตั้งค่า Conversions API สำหรับ e-commerce ต้องทำอย่างไร” หรือ “webhook ของ Messenger Platform ต้อง verify signature ยังไง” agent จะค้นหาเอกสาร official และสรุปขั้นตอนให้ [1]

ข้อจำกัดที่ควรรู้ก่อนใช้

Developer Tools MCP ยังไม่ใช่เครื่องมือจัดการโฆษณาโดยตรง คือมันยังไม่สามารถ:

• สร้างหรือแก้ไข campaign, ad set, ad
• เปลี่ยน budget หรือ bidding strategy
• ดึง insights ของ ad account โดยตรง (ต้องใช้ Marketing API ผ่านทางอื่น)
• อัปโหลด creative asset

หากต้องการทำสิ่งเหล่านี้ผ่าน AI agent ต้องใช้ Meta Ads CLI ซึ่งเปิดตัวเมื่อเดือนเมษายน 2026 และต้องใช้ร่วมกับ MCP server หรือ agentic coding tool เช่น Claude Code/Codex [2]

MCP ของ Meta ยังอยู่ในช่วง Beta อินเทอร์เฟซและชุดเครื่องมืออาจเปลี่ยนแปลง ดังนั้นไม่ควรพึ่งพาใน workflow ที่สำคัญมากจนไม่มีแผนสำรอง [1]

สรุป

Facebook Developer Tools MCP คือจุดเชื่อมต่อใหม่ที่ให้ AI agent เข้าถึงข้อมูลทางเทคนิคของ Meta app ได้จากที่เดียว สำหรับคนทำโฆษณา ประโยชน์ที่ชัดที่สุดคือ การตรวจสุขภาพแอป, ติดตาม App Review, จัดการ webhook และติดตาม changelog ซึ่งเป็นงานรองที่กินเวลามากแต่กระทบ campaign ได้จริง

จงจำไว้ว่า มันยังเป็น Beta ยังเขียนได้แค่ webhook subscription และยังไม่ใช่ตัวแทน Ads Manager ถ้าต้องการจัดการ campaign โดยตรงต้องใช้ Meta Ads CLI แทน [2]

แหล่งอ้างอิง

[1] Meta for Developers. “Developer Tools MCP.” Official documentation, updated June 12, 2026. https://developers.facebook.com/documentation/mcp/devtools-mcp

[2] Baker Team. “Meta Ads CLI and MCP Explained: How It Changes Your Campaign Strategy in 2026.” withbaker.com, April 30, 2026. https://withbaker.com/blog/meta-ads-cli-mcp-2026

ชอบบทความนี้? ติดตาม Nokka บน dev.to/sarantoon เพื่ออ่านเทคนิค digital marketing, AI และ automation ได้ที่นี่ — หรือแชร์คำถามไว้ใต้โพสต์นี้ได้เลย

This isn’t “frameworks are bad.” Bootstrap, Tailwind, and friends were the right call for most of the last decade, because CSS genuinely couldn’t do the things they made easy. That’s the part that’s changed. Grid systems, component-level breakpoints, conditional styling, specificity control, color theming — these used to require a framework or a preprocessor because CSS itself had no answer. It has answers now, and most teams haven’t gone back to check.

What frameworks were actually solving

To make the case fairly, it’s worth naming what problem each piece of a typical framework was actually there for — because “just use vanilla CSS” has been bad advice for a decade, and I want to be specific about why it stopped being bad advice rather than just asserting it.

Every row in that table used to be true. None of them are anymore.

Grid and subgrid replace the 12-column system

CSS Grid has been supported everywhere for years, but the part that actually finished the job — subgrid — is what let go of the last reason to reach for a prebuilt column system. A grid of cards where each card’s internal rows (image, title, meta, button) align across the whole row, not just within each card, used to need real work. Now it’s a couple of lines:

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
}

.card {
  display: grid;
  grid-template-rows: subgrid;
  grid-row: span 4;
}

That single auto-fit/minmax() line does the job of an entire responsive column system — it reflows the number of columns based on available width with zero media queries and zero JavaScript resize listeners.

Container queries replace component-level breakpoint hacks

This is the one that actually changes how you architect CSS, not just how you write it. A media query only ever knows the viewport. It has no idea if your card is in a wide main column or a narrow sidebar — which is exactly why component libraries ended up full of .card--compact modifier classes that had to be manually applied wherever a component landed in a tight space.

Container queries let the component ask about its own available space instead:

.card {
  container-type: inline-size;
}

@container (min-width: 380px) {
  .card__body {
    display: grid;
    grid-template-columns: 120px 1fr;
    gap: 1rem;
  }
}

Drop that same card into a sidebar, a modal, or a full-width section, and it adapts to whichever container it’s actually sitting in — no modifier class, no JavaScript ResizeObserver, no knowledge of the page layout required at the component level at all. This is the single biggest reason a component library’s “make it responsive” problem doesn’t need a framework’s help anymore.

:has() replaces a surprising amount of your JavaScript

:has() lets a parent’s style depend on what’s inside it — something CSS flatly couldn’t do before, which is why so many small interactions ended up as JavaScript that toggled a class on a parent element whenever a child changed state.

/* Highlight a form field's wrapper only when it contains an invalid input */
.field:has(:invalid) {
  border-color: var(--color-danger);
}

/* Style a card differently if it happens to contain an image */
.card:has(img) {
  grid-template-rows: auto 1fr auto;
}

/* Style a fieldset's label based on a checkbox elsewhere in the same fieldset */
fieldset:has(input[type="checkbox"]:checked) legend {
  color: var(--color-accent);
}

Multiply that pattern across a real form or a component with a dozen conditional states, and :has() is quietly deleting hundreds of lines of state-toggling JavaScript that never needed to exist once CSS could ask the question directly.

Native nesting replaces the entire reason most teams installed Sass

If a project only used Sass for nesting and variables — which, honestly, describes most projects — there’s no longer a reason to have a build step for it:

.nav {
  display: flex;

  ul {
    list-style: none;
    display: flex;
    gap: 1rem;

    li a {
      text-decoration: none;
      color: var(--color-text);

      &:hover {
        color: var(--color-accent);
      }
    }
  }
}

That’s not a preprocessor output — it’s what ships to the browser, unmodified. The CSS file structure mirrors the HTML structure, which was the actual appeal of Sass nesting the whole time. If your team’s Sass usage is genuinely just this, the build step is now pure overhead: one more tool in the pipeline, one more thing that can break CI, for a feature the browser already has.

Cascade layers replace the specificity war utility classes were built to dodge

This is the one people miss. A big part of why utility-first frameworks feel necessary is that they sidestep CSS specificity entirely — every class has the same low specificity, so the last one written always wins, and you never fight .header .nav ul li a versus .nav-link.

@layer gives you that same guarantee without giving up semantic class names:

@layer reset, base, components, utilities;

@layer base {
  a { color: var(--color-text); }
}

@layer components {
  .card a { color: var(--color-accent); }
}

@layer utilities {
  .text-muted { color: var(--color-muted); }
}

Layers are resolved in the order they’re declared, regardless of selector specificity or source order — a single class in utilities will always beat a deeply nested selector in components, on purpose, without an !important in sight. This was the actual argument for switching to utility classes: predictable override order. Cascade layers hand you that guarantee directly, so you can keep writing .card-title instead of .text-lg.font-bold.mb-2 and still win the specificity fight when you need to.

color-mix() and oklch() replace the theme-generation layer

Preprocessor color functions (darken(), lighten(), mix()) existed because plain CSS could only store a color, not compute a new one from it. That’s gone too:

:root {
  --color-brand: oklch(58% 0.18 250);
}

.button:hover {
  background: color-mix(in oklch, var(--color-brand), white 15%);
}

.button:active {
  background: color-mix(in oklch, var(--color-brand), black 15%);
}

oklch() also happens to interpolate more predictably than hex or RGB — mixing two OKLCH colors doesn’t produce the muddy, desaturated middle tones you get from mixing in RGB space, which was always the annoying part of building a tint/shade scale by hand.

clamp() replaces the typography-scale mixin

This one you may already be doing — it’s the same technique from fluid typography with clamp(), but it’s worth restating as part of the bigger case: a whole category of “responsive spacing/type scale” mixins collapses into single-property declarations:

h1 {
  font-size: clamp(2rem, 1.2rem + 3vw, 3.5rem);
}

.section {
  padding-block: clamp(2rem, 5vw, 6rem);
}

No breakpoint table, no mixin, no JavaScript recalculating on resize — the value scales continuously with the viewport and clamps at both ends.

Where a framework still earns its keep

None of this means frameworks are pointless now — it means their remaining justification is narrower and more specific than “CSS is hard,” and worth naming honestly:

• Prebuilt, accessible interactive components. A native <dialog> or <details> handles a lot, but a fully-featured date picker, combobox, or rich data table with proper ARIA behavior is still real work that a component library has already done correctly.
• Enforced consistency across a large team. A design system with strict, enforced tokens (via a utility framework’s config) can genuinely prevent drift better than a style guide people are supposed to remember to follow — this is a people problem as much as a technical one, and utility classes are a decent people-problem solution.
• Faster prototyping under real time pressure. Reaching for known utility classes is still faster than making design decisions from scratch when you’re throwing together an internal tool by Friday.
• Legacy browser support. If your analytics show a meaningful slice of traffic on genuinely old browsers, several of the features above aren’t available to them, and a framework’s fallback behavior earns its cost.

If your actual situation is one of these, that’s a real reason — not a rationalization. The point isn’t “never use a framework.” It’s that “we’ve always used one” stopped being a technical reason sometime in the last two years, and it’s worth checking which category your project is actually in.

A worked example: the thing frameworks were built for

Here’s the classic case — a responsive card grid where cards need internal layout that adapts to available space, not just viewport width — built with nothing but the platform:

<section class="card-grid">
  <article class="card">
    <img src="thumb.jpg" alt="" />
    <div class="card__body">
      <h3>Card title</h3>
      <p>Supporting copy that might run long or short.</p>
    </div>
  </article>
  <!-- more cards -->
</section>

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
}

.card {
  container-type: inline-size;
  border: 1px solid var(--color-border);
  border-radius: 0.75rem;
  overflow: clip;

  img {
    width: 100%;
    aspect-ratio: 16 / 9;
    object-fit: cover;
  }

  &:has(img) .card__body {
    padding-block-start: 1rem;
  }

  &__body {
    padding: 1rem 1.25rem;

    h3 {
      font-size: clamp(1.1rem, 1rem + 0.5vw, 1.35rem);
      margin: 0 0 0.5rem;
    }
  }
}

@container (min-width: 360px) {
  .card__body {
    display: grid;
    grid-template-columns: 1fr auto;
    align-items: start;
  }
}

No grid framework, no Sass, no JavaScript, and it responds to its own container rather than the viewport. Five years ago this genuinely required either a framework or a pile of custom code to get right; now it’s the direct, obvious way to write it.

Why the habit outlasts the reason

If none of this is news to you, that’s exactly the point — most of these features have been broadly supported for a year or more, and adoption still lags the capability by a wide margin. That’s not a technical gap anymore, it’s an inertia gap: framework choice gets made once at a project’s start, rarely revisited, and “the team already knows Tailwind” is a perfectly good reason to keep using it on an existing codebase. It’s a much weaker reason to reach for it by default on a new one.

The honest version of this take isn’t “rip out your framework.” It’s: the next time you start a project and install one out of reflex, spend fifteen minutes checking whether the specific problem you’re reaching for it to solve is actually still a problem. For a lot of projects in 2026, the answer is genuinely no.

Am I wrong about this? What’s the actual dealbreaker keeping your team on a framework right now — I’d genuinely like to know what I’m missing.

At ArtClick, we build fast, scalable WordPress websites, company websites and custom web systems that balance design, performance and long-term maintainability. Whether you’re starting from scratch or improving an existing platform, we’d love to help.

https://artclickdev.com/