In post 10 I closed the composition-versus-coherence question with one paragraph: I kept strict object-scoping, reserved an Inline operator for later, and rejected automatic reach-down. That was true, and it was too fast. A reader told me the reserved operator was not clear from a sentence, which is fair. A design record that asserts a decision without showing it is not really a record. So here is the seam, worked out. First, the good news that made this only one seam and not ten: composition and coherence mostly do not collide. Composition substitutes complex types ; coherence binds scalar facets ; those are disjoint kinds of member. A collection gives one persona per element. Draw order falls out of the eager construction rule from post 7. And the resolver pipeline I pre-paid for back in post 4 turned out to be coherence's host. The two threads layer cleanly almost everywhere. Almost. The discontinuity Coherence is object-scoped (post 5). That one rule has a consequence that only shows up once you have composition encouraging you to split a type across nested objects: moving a facet into a child changes whether it coheres. // Flat: Email is a Person facet, so it coheres with the name. Customer { FirstName , LastName , Email } // -> "Maria", "Gonzalez", "maria.gonzalez@..." // Decomposed: Contact is its own scope. A lone Email there does not activate a // persona (one corroborating member, no name anchor), so it is a plain, unrelated email. Customer { FirstName , LastName , Contact : ContactInfo { Email } } // -> "Maria", "Gonzalez", "rwilson@..." Same three fields, same intent, different result, decided entirely by which object they live on. That is the discontinuity. The options A, strict: object-scoping stays. The decomposed email does not cohere. Maximally predictable. The gap is the already-deferred cross-entity work. B, reach-down: a child with no entity of its own is absorbed into the parent scope. The email coheres. But "absorbed or not" now depends on hidd

Introduction It was a perfectly normal day. I opened my laptop, ready to get some work done, and then... BAM. A black screen. Not a gentle fade to black, but more like my computer shouting, "I’ve had enough of your crap!" The same operating system that had been working perfectly just five hours earlier had suddenly decided it had had enough of life. I wasn't too worried though. After all, I had ChatGPT on my side. Three hours later... Yeah... my confidence crumbled faster than my phone battery at 2%. What followed was a three-hour rabbit hole involving NVIDIA drivers, multiple Linux kernels, Secure Boot, DKMS, Xorg, GDM, journalctl , systemd , and more terminal commands than I'd like to admit. Somehow, against all odds (and probably a little divine intervention), we managed to fix it. And honestly? I enjoyed every minute of the chaos. It was like a wild adventure—except with more curse words and less danger. So I decided to document the entire debugging journey—not just because it might help someone who runs into the same issue, but also because I deserve a little sympathy after spending three hours arguing with my laptop. (And if the solution seems painfully obvious to you... please let me enjoy my victory. Don't take this away from me.😤 The Problem After rebooting my laptop, I was greeted with just a black screen. No login screen, no desktop… just nothing.** At first, I tried to enter TTY using Ctrl + Alt + F3, but that wasn’t working either. Since I wasn’t able to reach TTY directly, I had to take a different route. By editing the GRUB boot entry and booting into multi-user.target , I forced Linux to start in text-only mode, giving me access to a terminal.** For this, I edited the GRUB boot entry and appended systemd.unit=multi-user.target to the end of the kernel command line (after quiet splash ). That was the first breakthrough, though. The operating system wasn’t completely dead… only the graphical interface was failing to wake up. First Clues and Initial Ass

AI takes the path of least resistance. That one characteristic explains most of what changed for me about architecting a system once an agent was in the loop. It is genuinely faster than I am on frameworks, patterns, and the standard way to wire something up . Since it has read more on them than I have. But "least resistance" means it optimizes for the thing in front of it, e.g., getting an endpoint to work or a test to pass. It cannot optimize for the shape the system needs for your use case because it does not know all details. You still own 100% of that part. Two ways least-resistance goes wrong Left alone, the path of least resistance breaks in two opposite directions. It cuts a corner to make the immediate thing work: collapses a boundary, hardcodes a value, skips the seam that would have let two pieces move independently later. And when you try to correct it, it will over-engineer and reach for patterns, layers, and abstractions you did not ask for and don't need yet. Both come from the same place: it is solving the prompt, not steering the architecture . Here is the version I lived with. My app is layered the usual way: an API layer, a service layer under it, a data-access layer under that, with clear rules about what each one is allowed to do. Database transactions belong in the service layer. The agent kept ignoring that. Commits I had scoped to the service layer kept turning up in the data layer, or up in the API. The worst one was a transaction that opened in the service layer and got committed two layers down. If left at simple prompts, it will run and deliver you something that works, but you'll find that along the way it has quietly broken the boundary and created a brittle system. Here is the flip side, from just the other day. I was working on a bug fix with the agent on its own branch off main. Mid-test, I hit a separate gap, related to the feature but not the bug, and asked the agent to fix that too. It sensibly put the gap on its own branch, but b

🇧🇷 Leia a versão em português aqui In Part 5 of this series, we validated the cluster end to end by deploying Nginx. Now let's go one step further: build a custom application's Docker image, publish it, get it running in the cluster, and explore day-to-day operations — version updates, rollback, and scalability (both manual and automatic). As an example, we used a simple REST API ( myapp.war ), built with Spring Boot, purely for illustration — the process applies to any application packaged as a container image. Building the application's Docker image The first step is writing the application's Dockerfile . In this example, a lightweight base image ( alpine ) was used, with Java 11 installed to run the application: FROM alpine WORKDIR /opt/app RUN apk update && apk add vim openjdk11-jre COPY runapp.sh . CMD ash runapp.sh Building the image docker image build -t oregontecnologia/myapp-api:1.0.0 . Publishing the image Before using the image in the cluster, it needs to be available in some registry — either Docker Hub or a private registry . If you'd rather host your own on-premise registry (recommended for corporate environments or those without internet access), check out the companion article on creating a local registry server . To publish to Docker Hub: docker login username: password: docker push oregontecnologia/myapp-api:1.0.0 Deploying the application With the image published, you can check the cluster's current state before proceeding: kubectl get pods -o wide kubectl get deploy -o wide Create the Deployment directly from the command line, pointing to the published image: kubectl create deploy myapp-deploy --image = oregontecnologia/myapp-api:1.0.0 Unlike previous examples in this series (where we used YAML files with kubectl apply -f ), here the Deployment is created directly via the command line with kubectl create deploy . Both approaches are valid — YAML files are more suitable when you need to version and consistently reapply configurations. Exposing the

🇧🇷 Leia a versão em português aqui In previous parts of this series, we built the cluster from scratch: prepared the environment (Part 1), installed containerd and Kubernetes (Part 2), initialized the control-plane (Part 3), and joined the workers (Part 4). With the cluster up and all nodes in Ready state, it's time to actually put it to work: let's deploy our first application. In this article, we'll use Nginx as an example — a classic use case for validating that the cluster is working end to end, from pod creation to service exposure. Organizing the files First, create a directory to organize this deployment's manifests: mkdir nginx cd nginx Keeping Kubernetes manifests organized in per-application directories is a good practice that makes maintenance and versioning (e.g., with Git) easier as the cluster grows. Creating the Deployment A Deployment is the Kubernetes object responsible for managing pod replicas, ensuring the desired number of instances is always running — and handling things like rolling updates and automatic recovery in case of failure. Create the file nginx-deployment.yaml with the following content: apiVersion : apps/v1 kind : Deployment metadata : name : nginx-deployment labels : app : nginx spec : replicas : 2 selector : matchLabels : app : nginx template : metadata : labels : app : nginx spec : containers : - name : nginx image : nginx:1.14.0 ports : - containerPort : 80 This manifest defines: 2 replicas of the Nginx pod ( replicas: 2 ), distributed across the available workers; A selector that ties the Deployment to the pods via the app: nginx label; The nginx:1.14.0 image, exposing container port 80 . Applying the Deployment With the file saved, apply it to the cluster: kubectl apply -f nginx-deployment.yaml kubectl will create the Deployment, and from there Kubernetes takes care of scheduling the 2 pods across the available workers. Checking the Deployment To confirm the Deployment was created and has the desired number of replicas running

🇧🇷 Leia a versão em português aqui In Part 1 of this series, we prepared the environment: defined the hardware, configured /etc/hosts , adjusted the firewall, and disabled SWAP on all nodes. Now that the foundation is ready, it's time to install the container runtime ( containerd ) and the Kubernetes packages themselves ( kubelet and kubeadm ). All the steps below should be run on all servers in the cluster — master and workers — unless stated otherwise. Loading kernel modules Kubernetes, through containerd, depends on two Linux kernel modules: overlay (for the layered filesystem used by containers) and br_netfilter (so that bridge network traffic passes through iptables rules). For these modules to load automatically on every boot, create the file /etc/modules-load.d/containerd.conf : overlay br_netfilter And, to load them immediately (without needing a reboot), run: $ sudo modprobe overlay $ sudo modprobe br_netfilter Adjusting kernel network parameters Create the file /etc/sysctl.d/99-kubernetes-k8s.conf with the following parameters: net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 1 These parameters ensure that network traffic between pods and services is correctly routed and filtered by Kubernetes. To apply the settings without restarting the server: $ sudo sysctl --system Installing containerd Containerd is the container runtime used by the cluster. In this case, we'll install it through Docker's official repository, using only the containerd.io package (without installing full Docker). 1. Download the repository's GPG key: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg 2. Create the repository file at /etc/apt/sources.list.d/docker.list : deb [ arch = amd64] https://download.docker.com/linux/debian bullseye stable 3. Update the package list and install containerd: sudo apt-get update sudo apt-get install containerd.io 4. Generate the default

🇧🇷 Leia a versão em português aqui This is the first part of a series where I'll share, step by step, how I built my own on-premise Kubernetes cluster, without relying on any cloud provider. The goal is to document the whole process — from environment preparation to a working cluster — as a reference for anyone studying the topic or looking to replicate the same setup at home or at work. I used VPS (Virtual Private Server) and VM (Virtual Machine) for this cluster. However, it can also be set up on physical machines (Bare Metal). Bye the end of this series, it will be easier to understand cloud clusters on AWS (EKS), Google (GKE) and Azure (AKS). In this first part, we'll cover everything needed before installing any Kubernetes component: hardware requirements, basic network configuration, firewall rules, and a few mandatory operating system adjustments. Requirements The following topology was used for this cluster: 3 servers in total 1 master server (control-plane): 2 CPUs (cores) and 2 GB of RAM 2 worker servers (slaves): 1 CPU and 1 GB of RAM each Root access on all machines This is a minimal setup, ideal for study, lab, or testing environments. For production, resources should be scaled according to expected load. Configuring the hosts file Before installing anything, it's important for the machines to resolve each other by name, not just by IP. Edit the /etc/hosts file on all servers and add the corresponding entries: 10 . 0 . 10 . 100 master . company . local master 10 . 0 . 10 . 101 slave01 . company . local slave01 10 . 0 . 10 . 102 slave02 . company . local slave02 This ensures that, later on, the Kubernetes components can correctly resolve node names. Configuring the Firewall Kubernetes depends on specific ports being open between nodes so the control-plane can communicate with the workers (and vice versa). The ports vary depending on the server's role in the cluster. On the master server: Port Protocol 6443 TCP 2379-2380 TCP 10250 TCP 10251 TCP 10252 TCP

A post scheduled to publish at a specific time doesn't go live when expected. A plugin's recurring email notification never arrives. This tends to happen on low-traffic sites, and there's a specific reason for it. Note: WP-Cron is WordPress’s built-in scheduling system. It sounds like the OS-level cron daemon, but the underlying mechanism is quite different. WordPress’s WP-Cron doesn’t work like a real OS cron daemon. On every page load, WordPress checks whether any scheduled task is past its due time and, if so, runs it. This is what's known as "pseudo-cron" — and its weakness is that nothing runs without a page visit . Schedule a post to publish at 3am on a site with little overnight traffic, and the publish task can sit unexecuted until the next visitor happens to load a page. WP-CLI lets you look inside this otherwise invisible system and run exactly the task you need, right now. Listing what's scheduled wp cron event list hook next_run_gmt recurrence publish_future_post 2026-06-20 03:00:00 - wp_version_check 2026-06-20 06:12:00 12 hours wp_scheduled_delete 2026-06-21 00:00:00 daily hook is the task's identifier, next_run_gmt is the next scheduled run time in UTC, and recurrence is the repeat interval. If publish_future_post is still listed despite its time having already passed, that confirms the task is overdue simply because no page load has triggered it yet. Running a task right now To trigger a specific task immediately: # Run a specific hook right now wp cron event run publish_future_post # Run every overdue task at once wp cron event run --due-now --due-now finds every task whose scheduled time has passed but hasn't run yet, and executes all of them. Instead of waiting for a visitor to trigger the check, this one command runs the post publish, the email notification, or whatever else is pending. Confirming WP-Cron itself is working wp cron test This checks whether the WP-Cron scheduler is functioning at all. On sites where wp-config.php has define('DISABL

Every MCP server I've read that wraps a third-party REST API has the same shape: someone picked fifteen or twenty endpoints that seemed useful, hand-wrote a Zod schema for each, and shipped it. That works for about three months. Then the API adds a field, deprecates an enum value, renames a query parameter. The wrapper doesn't notice, because nothing in it is connected to the API's own description of itself. The schemas drift. The model starts getting rejected by the upstream API for reasons it can't see, and you get to debug an LLM guessing at a shape that stopped being true in February. The other failure is quieter. You need endpoint twenty-one — the one about persistent disks, or scaling, or environment groups — and the author skipped it. Now you're back to curl , except the agent is holding half the context and you're holding the other half. I wanted neither, so I built render-useful-mcp : an MCP server for Render where every API tool is generated from Render's own OpenAPI document. All 207 endpoints, no curation. The generating part took a weekend. Everything after that was the actual work. Make the generator refuse to guess The tempting way to write a spec-to-tools generator is to make it forgiving. Skip what you can't parse, fall back to { type: "object" } when a $ref gets hairy, log a warning and move on. You get 207 tools on the first run and feel great. You also get tools that lie. A parameter typed as a free-form object when the API actually wants one of four enum values is worse than no tool at all — the model will confidently produce garbage, and the failure surfaces three layers away from the cause. So the generator is fail-closed. It aborts the build, loudly, on: An operation whose tag doesn't map to a known toolset. Render added a resource category and I haven't classified it yet. That's my problem to solve, not something to paper over. A tool name collision. Two operations deriving the same name means my naming scheme is wrong. A cyclic $ref it can'

Microsoft pitched its own homegrown AI models, harnesses, and even a Mythos competitor on Wednesday, telling Wall Street it plans for continued growth.

I have been pushing up to 90 commits a day on a MacBook Air via 4-5 parallel agents. As you can imagine when all the agents try to build, test and run dev servers on an 8GB machine it is the fast lane to a force quit and restart. I also did not want to pay the CI minutes on 90 pushes a day. So I designed a local merge queue to have all commits land one at a time and fully tested. Hopefully this helps other folks with more modest machines. Appreciate any feedback.

I've spent enough time in the trenches of software engineering to know that there is nothing more soul-crushing than writing 'glue code.' You know exactly what I mean—the thousands of lines of boilerplate, error handling, and webhook listeners required just to make two services talk to each other. When Bland AI first arrived on the scene, it was essentially another API you had to integrate. You'd write a Node script, handle the async nature of outbound calls, manage your credentials in environment variables, and then spend weeks building a dashboard just so you could see what happened during a call. It worked, but it wasn't intelligent. The shift we are seeing right now with the Model Context Protocol (MCP) changes the fundamental architecture of integration. We are moving from 'integration as an engineering task' to 'integration as a capability.' Instead of writing code to bridge Bland AI and your application, you provide an MCP server that gives your LLM—whether it's Claude or Cursor—direct access to those telephony tools. I recently started using the Bland AI MCP server via Vinkius, and the difference in how I can orchestrate workflows is night and day. This isn't about just 'making a call.' It's about giving an agentic loop control over a communication channel. The Architecture of Voice Orchestration When you look at traditional API integrations for something like Bland AI, you focus on the request/response cycle. You send a payload to trigger a call, and then you wait for a webhook to notify your backend that the call is finished. With this MCP server, the mental model shifts. You aren't managing webhooks; you are managing tools. The toolset provided here—including send_phone_call , create_voice_agent , and list_recent_calls —allows an LLM to act as a telephony engineer. Here is what happens when you actually use it in Cursor or Claude: You don't just say "Make a call." You can instruct the agent, "Look at my recent calls from yesterday, find any where the tran

TL;DR: MCP servers run with significant privileges inside AI agent pipelines, and most teams ship them without any security review. mcp-security-scan is an open-source CLI and GitHub Action that checks for credential theft patterns, data exfiltration, unsafe execution, and code obfuscation — and outputs a 0-100 trust score that integrates with AgentGraph's identity layer. The Moltbook breach last year is still the clearest example of what happens when you scale agent infrastructure without thinking about trust. 770,000 agents, zero identity verification, and when it went down it exposed 35,000 emails and 1.5 million API tokens. The tokens were the real problem — many of them were credentials passed through MCP servers that nobody had audited. MCP (Model Context Protocol) servers are the connective tissue of modern agent systems. They sit between your LLM and the outside world, handling tool calls, filesystem access, API requests. That position gives them a lot of power. It also makes them an obvious target. And yet most teams treat MCP servers like they treat npm packages circa 2015: install and trust. What Actually Goes Wrong Before getting into the scanner, it's worth being specific about the threat categories. There are four that show up most often in real codebases: Credential theft — MCP servers that read environment variables indiscriminately, log request/response payloads, or forward tool call arguments to external endpoints. This one is subtle because the server might be doing legitimate work and exfiltrating credentials. Data exfiltration — Outbound HTTP calls to domains that weren't declared in the server's manifest, or calls that happen inside tool handlers where the LLM can influence the destination URL. Prompt injection into tool parameters is the attack vector here. Unsafe execution — eval() , exec() , subprocess calls, or dynamic require() / import() where the argument comes from tool call input. If an LLM can influence what gets executed, you have a

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. You know those...

avatarin uses OpenAI’s GPT-Realtime to give Yamada Denki shoppers 24/7 multilingual support. In two weeks, 30,000 people used the agent and 92% of survey responses were positive.