标签：#dev

You've deployed your app to Kubernetes. The pod starts — then it gets killed. Or it's running but no traffic reaches it. Or it takes 90 seconds to initialize and gets restarted in a loop. Every one of these problems traces back to the same root cause: misconfigured or missing health probes . Kubernetes gives you three types of probes: livenessProbe , readinessProbe , and startupProbe . Each serves a different purpose. Mix them up and your pods restart in infinite loops. Get them right and your deployments self-heal, scale correctly, and handle rolling updates without a single dropped request. Here's what each probe does, when to use it, and how to configure it for a real production service. 1. Liveness Probe: Is the Container Alive? The liveness probe answers one question: "Is this container still running correctly?" If the probe fails, kubelet kills the container and restarts it. livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 3 Use liveness probes for deadlock detection . If your app enters a state where it's alive but not making progress (a goroutine leak, a stuck mutex, an infinite loop), the liveness probe exposes that and triggers a restart. The #1 mistake people make: using the liveness probe to check external dependencies like databases or upstream APIs. Don't do this. If your database is down and your liveness probe fails, Kubernetes will restart your pod — but the database is still down. Restarting the app doesn't help, and now you have a crash loop on top of a DB outage. That's worse. Liveness probes should only check internal process health. Not database connectivity, not Redis, not upstream services. 2. Readiness Probe: Is the Container Ready for Traffic? The readiness probe answers: "Should this pod receive traffic?" If it fails, the pod is removed from all Service endpoints. It is not restarted. readinessProbe: httpGet: path: /ready port: 8080 periodSeconds: 5 failureThreshold: 2 successThre

A previous post covered how to absorb PHP 8.2 Deprecated warnings from WP-CLI using a three-layer defense . The approach — prepending WP_CLI_PHP_ARGS to set error_reporting — works in many environments. But a case came up where Deprecated warnings wouldn’t disappear despite the same configuration. Tracing the cause revealed a structural reason why the environment variable never arrived. This post records that root cause and the three-part fix added in v1.6.8. Why environment variables don’t arrive — the phar + shebang execution path An agency reported that on Xserver, plugin list retrieval was failing across multiple sites (referred to here as "site A / site B") with a large volume of Deprecated messages. We reproduced the same behavior on our own Xserver setup (PHP 8.2.30, WP-CLI 2.7.1) and traced the execution path. Xserver’s /usr/bin/wp is a phar binary. Inside, it starts with a #!/usr/bin/env php shebang, so the actual startup sequence looks like this: shell → /usr/bin/wp (shebang: #!/usr/bin/env php) ↓ env locates php and starts it ↓ php loads the phar → WP-CLI runs In this path, WP_CLI_PHP_ARGS is never read as a PHP startup option. WP_CLI_PHP_ARGS is supposed to let WP-CLI pass a -d flag to PHP, but when PHP itself is launched via shebang, control never reaches the point where WP-CLI can inject that flag into PHP’s invocation. # doesn’t work — /usr/bin/wp on Xserver is a shebang-launched phar WP_CLI_PHP_ARGS = "-d error_reporting='E_ALL & ~E_DEPRECATED'" wp plugin list --format = json # works — -d goes directly to the php binary php -d error_reporting = 'E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED' /tmp/wp-cli-2.7.1.phar plugin list --format = json We verified this against our production setup: with the first form, 407 Deprecated lines remained; with the second, 0. Pillar A — detecting the php-direct path and injecting -d The fix: inspect wp_cli_path for whether it’s a php-direct invocation, and if so, inject -d error_reporting immediately after the PHP

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . This is our official submission for the DEV Big Summer Bug Smash challenge under the #bugsmash track. Below is the technical tale of how we isolated, debugged, and optimized cross-layer node latency issues when deploying our Web3 framework on Polygon. The Problem: The Post-Hard Fork RPC Latency Wall 🐛 During heavy network volume spikes or directly following major ledger upgrades, our automated event listener logging pipeline kept crashing with random, non-deterministic invalid block range exceptions when attempting to pull historical data blocks via standard eth_getLogs routines. The Technical Root Cause The root bottleneck came down to an internal desync inside shared public RPC telemetry environments: The Bor Layer mints new block headers at a blistering speed (~2 seconds). The Internal Indexer DB takes slightly longer to completely unpack, parse, and commit transaction event logs to disk. When our asynchronous scripts called the node, latest grabbed the bleeding edge tip of the chain from memory, but a simultaneous getLogs query hit the slower indexer database. This split-millisecond race condition threw immediate pipeline errors. The Fix: Layered Application Buffering 🛠️ To smash this bug without modifying low-level node client builds, we engineered a programmatic block-padding delay loop directly into our interaction routers. Instead of tracking unfinalized tip block states blindly, we forced our queries to target safe block ranges sitting securely just behind the tip of the chain. // Localized block-buffer deployment fix const currentChainTip = await provider . getBlockNumber (); const indexedBlockBoundary = currentChainTip - 3 ; // Buffer 3 blocks (~6 second safety zone) const targetLogs = await contract . getLogs ({ fromBlock : indexedBlockBoundary - 20 , toBlock : indexedBlockBoundary }); This structural adjustment completely stabilized our off-chain reward data pipeline, gua

Most "SSG vs SSR vs ISR" content out there is written from documentation. Someone reads the framework, restates it, and you're left inferring the actual difference in performance and behavior. So I built a lab where you can just run the commands and see it yourself, no table to trust blindly. astro-wp-seo-lab builds the same WordPress content four different ways with Astro 7.1.1, then serves all four side by side so you can compare them directly. git clone https://github.com/nimajafari/astro-wp-seo-lab npm install npm run compare That builds each arm into its own directory and serves them all at once. arm url what it is ssg-full http://localhost:4301 everything prerendered at build time ssr http://localhost:4302 rendered per request, no caching ssr-cdn http://localhost:4303 per request plus CDN cache headers route-cache http://localhost:4304 per request plus Astro 7 route caching islands http://localhost:4305 static shell with deferred fragments Every page has a black bar at the top showing which arm rendered it and when. That timestamp is the instrument for most of what follows. First build takes a few minutes since each arm fetches from WordPress, later builds are faster because the Content Layer loader caches between them. It ships pointed at a live WordPress install (oxyplug.com), but it works against any public WordPress site with the REST API exposed. npm run probe -- https://your-site.com --save mysite SOURCE = mysite npm run compare probe checks what your own install actually exposes, REST API reachability, Yoast presence, permalink structure, then saves it under a name. Use the URLs npm run compare prints for your own site instead of the ones below, since those are generated from your own content. Build time vs request time This is the distinction most of the SSG vs SSR debate hinges on, and it takes about 30 seconds to see for yourself. Open these two side by side and reload each a few times. http://localhost:4301/optimization/crl-ocsp-certificate-revocati

Over the past few years, AI has fundamentally changed how software gets built. Teams can go from an idea to a working application in a fraction of the time it used to take, and founders can create products with resources that would have been unimaginable just a few years ago. That's an incredible shift, and I think it's one of the most exciting changes our industry has seen. What hasn't changed, though, is the question that comes after the application is built: Is it actually ready? Throughout my career, I've been involved in delivering enterprise software across many different industries and organizations. One thing I've learned is that there isn't a single definition of what makes an application "ready." If you ask six different stakeholders whether a system is ready, you'll probably get six different answers—and they're all likely to be valid. That's because each person is looking at the software through the lens of the outcome they're responsible for: A founder may be wondering whether the application can handle the growth they're hoping for over the next year. A CTO is often focused on where the biggest technical risks are and what should be improved first. An engineering leader is thinking about production readiness, security, reliability, and operational support. An agency inheriting a client application wants to understand what they're taking ownership of before making commitments. An acquirer is trying to estimate the cost of technical debt An Investor wants confidence that the technology is creating long-term value rather than future expense. Those perspectives are different because the questions they're trying to answer are different. The challenge is that we often evaluate all software the same way. Traditional assessments tend to focus on the health of the codebase. They look at architecture, security, maintainability, testing, complexity, and technical debt. Those are all important, and they should absolutely be part of any technical review. But they'r

Early Access games create a documentation problem that ordinary wikis do not handle well: the facts can change faster than search results, community posts, and copied tables are updated. A page can look polished and still be wrong for the current build. I have been working on an independent Subnautica 2 player wiki, and the most useful engineering lesson has been to treat every guide, map marker, and item row as versioned data rather than timeless prose. This post describes the workflow without assuming any particular framework. 1. Put provenance next to the fact For every structured record, keep at least: the game build or patch it was checked against; the source type: official note, in-game observation, or community report; the observation date; a confidence state such as verified, provisional, or disputed; a stable identifier that survives display-name changes. A user should not have to trust a page because it looks complete. They should be able to see whether a coordinate came from the current build and whether another player can reproduce it. 2. Separate stable identity from mutable labels Names, descriptions, recipes, and locations may change. Use an internal key as the identity and keep display text as versioned attributes. This prevents an item rename from creating a second logical entity or breaking every inbound link. The same rule helps with localization: English and translated labels point to one entity, while the source and verification state remain shared. 3. Model maps as evidence, not decoration An interactive map should not be a pile of pins. A useful marker contains coordinates, category, build, evidence, verification state, and a short player-facing note. If a patch moves or removes the object, preserve the history and mark the old observation as superseded. This also makes filters honest. “Show verified markers for the current build” is a meaningful query; “show everything ever imported” is not. 4. Make guides depend on structured facts Low-spoil

Introducing vernLLM: A Resilience Layer for LLM Applications Building production-ready LLM applications is not just about sending prompts and receiving responses. Real-world AI systems need to handle timeouts, provider failures, rate limits, inconsistent outputs, and reliability issues. That is where vernLLM comes in. vernLLM is a lightweight resilience layer for OpenAI-compatible chat completion APIs , providing a single interface with built-in retries, timeouts, circuit breaking, caching, structured output, and usage tracking. Instead of rebuilding the same reliability features for every LLM project, vernLLM gives you the tools needed to make your AI integrations more robust from the start. Features Automatic retries with backoff Transient failures happen. vernLLM automatically retries recoverable errors while failing fast on validation errors and non-retryable responses. Timeouts & cancellation Prevent hanging requests with configurable timeouts and cancellation support. Circuit breaker protection Automatically stop sending requests to failing providers and recover when the service becomes healthy again. Structured output with type safety Pass a Zod schema and receive validated, typed results back. const result = await llm . call ({ systemPrompt : ' Return JSON: { "skills": string[] } ' , userContent : ' Extract skills from: ... ' , schema : SkillsSchema // zod schema }); Provider-native JSON Schema support Constrain model generation itself instead of only validating responses afterward. Built-in caching support Cache LLM responses using your own cache adapter with cachedCall and cachedLLMCall . One interface across providers Use the same API across multiple providers: OpenAI Groq Mistral DeepSeek Cerebras Together AI Fireworks AI Ollama Anthropic Gemini AWS Bedrock Any HTTP-compatible provider through fromFetch Why vernLLM? Many LLM applications end up creating their own wrappers around provider SDKs to handle: retry logic API failures provider switching respons

Microsoft PowerToys includes a Hosts File Editor. It is free, signed, and already on many Windows machines. It is a good editor. It is not always a good hosts workflow . What PowerToys Hosts does well Opens the real Windows hosts file with the right elevation story Simpler than hunting C:\Windows\System32\drivers\etc\hosts in Notepad Free if you already use PowerToys Fine for a handful of static lines When people search for an alternative You switch environments all day Local shop in the morning, client staging after lunch, cutover IP at night. An editor with one big file turns into commented chaos. You want named profiles you can toggle, not archaeology in comments. You also use a Mac or Linux box PowerToys is Windows-only. Your hosts process should not fork by OS if the team shares domain names. You forget ipconfig /flushdns Same bug as every other hosts tool without auto flush: file correct, browser wrong. Alternatives on Windows SwitchHosts Free, open source, profiles, also runs on Mac/Linux. Best PowerToys alternative when you need environment switching and maybe multi-OS later. Locahl Paid one-time. Windows, macOS, Linux. Automatic DNS flush and backups. Best when PowerToys feels too manual and you want the apply step to include flush + safety. Notepad as Administrator Still works. Still easy to save the wrong copy or skip flush. Only fine for rare edits. Hostly / CLI hosts switchers Interesting if you want hosts open Dev from scripts. Check that the project is maintained before you depend on it in CI. Feature snapshot (Windows view) Tool Profiles Auto flush Multi-OS Cost PowerToys Hosts Limited No No Free SwitchHosts Yes No Yes Free Locahl Yes Yes Yes One-time Notepad Admin No No Manual Free Practical upgrade path Keep PowerToys for now if you only have 5 stable lines When you start commenting / staging blocks every week, move to SwitchHosts or Locahl Always backup before the first import After every apply: ipconfig /flushdns ping myapp .test If PowerToys is

Every distributor we spoke to has the same quiet bottleneck, and none of them call it a problem. They call it Tuesday. A request for quote lands in a shared inbox. Sometimes it is a tidy bulleted list. More often it is three lines of text from someone's phone, or a PDF that was scanned at an angle. Someone on the sales desk reads it, works out which catalog part each line actually refers to, checks pricing, and types up a quote. A busy desk does this thirty or forty times a day. It is slow, it is boring, and it is exactly the kind of work where a tired person on a Friday afternoon quotes the wrong bolt and nobody notices until the shipment arrives. We spent three weeks building Distill.ai to do that job. This is what we learned, including the parts that went badly. What we actually built You paste an email or upload a PDF. From there a seven stage pipeline runs: parse -> extract -> classify -> match -> price -> policy -> score Parse cleans the document into text. Extract pulls out the individual line items, quantities, and specs. Classify works out what kind of request this is. Match maps each line to a real catalog SKU. Price applies the pricing rules. Policy runs the business checks. Score attaches a confidence value to every match. The interesting part is not the happy path. It is what happens when the model is unsure. Any line that scores below a 0.70 match threshold does not get quoted. It gets flagged with a reason and routed to a human review queue. A person confirms or corrects it, and the quote goes out clean. That one decision is the difference between a demo and something a sales desk would actually put its name on. An agent that is confidently wrong 5% of the time is worse than useless in procurement, because someone has to check all 100% of the output anyway. An agent that says "I got 47 of these 50 lines, here are the 3 I could not resolve" saves real hours. Why Qwen, and how we wired it up We used two models from Alibaba Cloud Model Studio: Qwen-Plus

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . I spent a week deploying a CrewAI agent to AWS Bedrock AgentCore. The SDK wasn't on PyPI. The error messages were 200 OKs. The container crashed without logs. And the naming regex rejected hyphens without telling me why. This is the full debugging trail. Every failure was silent. Every fix required reading source code nobody documented. Table of Contents The Project Failure 1: The SDK That Doesn't Exist on PyPI Failure 2: The 200 OK That Means Failure Failure 3: The Container That Crashed With No Logs Failure 4: The Naming Regex Nobody Documented The Two-Client Split Nobody Mentions What I Learned The project I built a resume-tailoring AI agent with CrewAI and Amazon Bedrock. It takes a job description, analyzes your resume, identifies gaps, and rewrites bullet points to match what the role actually needs. Locally it worked perfectly. CrewAI orchestrates the agents, Bedrock Nova Pro handles the LLM calls, and the output is solid. Deploying it to production was the problem. AWS launched Bedrock AgentCore in June 2026 as a managed runtime for AI agents. You containerize your agent, push the image, and AgentCore handles scaling, memory, and invocation. Sounds simple. It was not simple. Failure 1: The SDK that doesn't exist on PyPI The docs say to install bedrock-agentcore-client . I ran: pip install bedrock-agentcore-client It installed successfully. No errors. That's because there's a placeholder package on PyPI with that name. It installs, imports fail silently, and your container builds successfully with a broken dependency inside. The real SDK lives in AWS's CodeArtifact registry. You need to configure pip to pull from a private index: aws codeartifact login --tool pip \ --domain amazon-agent-runtimes \ --repository agent-runtimes-pypi \ --domain-owner 600427722194 Then install from there. The PyPI package is a trap. Nobody warns you. Hours lost: 3. The error only appears at runtime

I had a website blocker, a Pomodoro timer, a tab suspender, and a time tracker installed at the same time — four separate extensions, four separate settings pages, none of them talking to each other. Starting a focus session meant manually turning on the blocker, then starting the timer, and neither knew the other existed. So I built TabInsights , which does all four and actually connects them. What it does Website blocker — block by domain, category, or schedule, with an optional typed "unblock challenge" for the days willpower isn't enough. Pomodoro focus timer — one click starts a 15/25/45-minute sprint, which also auto-blocks distracting categories for the duration and unblocks them automatically when it ends. This is the part that actually solves my original problem — the timer and the blocker are the same feature, not two extensions coincidentally running at once. Memory saver — auto-suspends tabs you haven't touched in a configurable window (15–60 min), freeing roughly 50MB of RAM each via chrome.tabs.discard() . Suspended tabs stay in your tab bar and reload exactly where you left off with one click. Automatic time tracking — logs time per domain with no manual start/stop, and shows a daily focus score. A few implementation notes Manifest V3 removed persistent background pages, which meant every "ongoing" feature — sprint timers, the daily summary, auto-suspend checks, license re-validation — had to be rebuilt on chrome.alarms instead of a long-lived timer. The gotcha: Chrome clamps alarm intervals to a minimum of 1 minute in packaged (published) extensions, so anything needing finer granularity has to accept that floor rather than fight it. The blocker uses declarativeNetRequest — you hand Chrome a set of match rules and it enforces them at the browser level. The extension never actually reads the blocked request; it can't, by design, which is also the honest answer any time someone asks whether a blocker "sees" their browsing. The bigger architectural deci

DISCLAIMER: This post was written entirely by me! I used AI for a little research, spelling, grammar, and comprehension checks. This post was originally shared on Hackernoon Entertain me for a moment, let's appreciate where we are today by understanding where we've been… or at least, where I've been. I remember when I first learned to code. I was bad, like really bad. But I was so curious! It all started by writing some VBA in an MS Access Database to create an IT Inventory app in the late 90s. Then I learned JavaScript, ASP (without the .Net), then C#, .Net ( I still have my .Net for Dummies book, see below) , jQuery, Python, Java, Angular, ReactJS, and Python again (yeah, had to relearn that one for some reason), and I'm sure there are others in there I forgot about. Learning to write code was rewarding! There were those days I'd spend hours on a bug, only to realize I didn't initialize the variable or forgot a semicolon. I learned .Net over a weekend thanks to the above book. I never became an artist of the craft, like some of my colleagues have (you know who you are: Josh, Kevin, and many others), but I knew how to build anything. I loved that ability: I could build anything. Pure joy! If you haven't had the joy of learning to code, do your best to learn it, because you can't prompt your way to being a Senior Engineer . As I progressed in my career, I became an architect and senior lead. I started off by leading a single engineering team, and now I support large programs and teams. All the while, I never let go of hands-on-code. I still love coding for work and my myriad of side projects. Then, a few years ago, this GenAI thing showed up. Put me in that group of: oh-no-there-goes-my-joy. Joy, yes, not my job. I love my job because I get to do what I love. I loved the dramatic rollercoasters: architecting a perfect solution, realizing it's wrong, getting to write every line of code, chasing impossible bugs, panicking with deadlines, late nights chasing hot fixes,

Every time you run a JavaScript program, a lot happens behind the scenes. Variables are allocated memory, execution contexts are created, functions are pushed onto the call stack, and the engine starts executing your code. But before we dive into all of that, let's first understand what JavaScript actually is and why it was created. An Introduction to JavaScript What is JavaScript? JavaScript is a programming language that was originally created in 1995 by Brendan Eich in just 10 days while he was working at Netscape. JavaScript is a high-level programming language primarily used to make web pages interactive. Today, it is also used to build servers, mobile applications, desktop software, and much more. Why was JavaScript created? JavaScript was created to make web pages alive . But what does "alive" mean? it means adding interactivity (e.g., animations, clickable buttons, popup menus, etc.) to the static web pages. Today, JavaScript isn't limited to browsers. With runtimes like Node.js, it can also be used to build backend applications and APIs, which allow you to add more functionality to a website. Did you know? When JavaScript was created, it initially had another name: “LiveScript”. Where can JavaScript be used? In your browser — every interactive website uses it (Facebook, YouTube, Gmail). On servers — through Node.js, you can build backend APIs. In mobile apps — using frameworks like React Native. In desktop apps — VS Code itself is built using JavaScript (Electron). In smart devices, games, robots, and much more. Now that we know what JavaScript is, another question comes to mind: How does JavaScript execute my code? Before answering that, let's first understand Who executes my code? . The answer is: The JavaScript Engine The JavaScript Engine We already know what JavaScript is, but what exactly is this engine ? The "Engine" A JavaScript engine is a piece of software responsible for executing JavaScript code. Every environment that runs JavaScript, whether i

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . 🎭 The Recurring Villain If you've built WordPress sites long enough, you know this bug. It doesn't show up as an error in your console. It doesn't throw a fatal exception. It just quietly sits there, page after page, client after client — and it's called video bloat . Nine years into web development, I lost count of how many times a client sent me a site with a message like "it's just... slow." And nine times out of ten, when I opened DevTools and checked the waterfall, the story was the same: three, four, sometimes ten embedded YouTube videos, each one dragging in its own iframe, its own set of scripts, its own chunk of megabytes — all loading the second the page rendered, whether the visitor scrolled past them or not. One video embed alone can pull in 500KB–1MB+ before a user even presses play. Multiply that by a landing page stacked with testimonials, product demos, and a hero video, and you've got a page that fights your Core Web Vitals before it's even finished loading. 🔁 The Manual Fix (Every. Single. Time.) For years, my solution was the same tedious ritual: Find every video embed on the page. Replace the iframe with a static thumbnail image. Write a bit of custom JavaScript to swap the thumbnail for the real embed on click or scroll. Repeat it for YouTube. Repeat it again for Vimeo, because Vimeo's oEmbed API works differently. Repeat it again for self-hosted <video> tags, because now you're dealing with <source> tags instead of iframes. Test it across whatever page builder the client was using — Elementor, Divi, WPBakery, or straight-up Gutenberg blocks — because every one of them nests the video markup slightly differently. It worked. But it was never reusable. Every project meant writing the lazy-load script again, half from memory, half copy-pasted from my own old projects, tweaked just enough to fit the new theme's markup. It was the same bug, wearing a different site's c

Back in July my scheduled DEV.to publishing run failed at the very first step — the quota check couldn't reach dev.to:443 at all. Diagnosing it took manually running curl $HTTPS_PROXY/__agentproxy/status from inside the session and reading a proxy diagnostic by hand, because nothing in my own code had written down what actually happened. Not which host, not which of my two HTTP helper functions made the call, not a timestamp, nothing. The failure was real and the fix (get dev.to added to the environment's egress allowlist) was correct, but I found it by treating my own server as a black box and probing it from outside, which is exactly backwards for code I wrote myself. eight tools, one shared blind spot server.py is an 8-tool FastMCP server: three GitHub tools, four DEV.to tools, one that shells out to claude -p . Every HTTP-calling tool routes through one of two helpers: def _gh ( path , method = " GET " , data = None ): req = urllib . request . Request ( f " https://api.github.com { path } " , method = method ) req . add_header ( " Authorization " , f " token { os . environ [ ' GITHUB_TOKEN ' ] } " ) req . add_header ( " Accept " , " application/vnd.github.v3+json " ) if data : req . add_header ( " Content-Type " , " application/json " ) req . data = json . dumps ( data ). encode () with urllib . request . urlopen ( req ) as r : return json . loads ( r . read ()) def _dev ( path , method = " GET " , data = None ): req = urllib . request . Request ( f " https://dev.to/api { path } " , method = method ) req . add_header ( " api-key " , os . environ [ " DEV_TO_API " ]) req . add_header ( " Content-Type " , " application/json " ) req . add_header ( " User-Agent " , " developer-presence-mcp/1.0 " ) if data : req . data = json . dumps ( data ). encode () with urllib . request . urlopen ( req ) as r : return json . loads ( r . read ()) Neither one logs anything. When urlopen raises, the caller — whichever @mcp.tool() function invoked it — sees a bare urllib.error.HTTPEr

Perplexity added "Skills" to its Agent API, letting developers compose built-in and custom skills for more complex agent outputs. More skills mean more actions, and more actions mean more ways to produce an irreversible change. Before you add a fifth skill to your agent, make sure the first four have an undo path. The undo problem An agent skill that writes, sends, publishes, or deploys is an irreversible action if there is no rollback. The more skills an agent has, the more irreversible actions it can take in a single session. A chain of skills (research → draft → format → publish) can complete before a human notices the first step was wrong. The undo contract Every agent skill should declare: { "skill_name" : "publish_to_blog" , "action_type" : "write" , "reversible" : true , "undo_method" : "set_published_false" , "undo_timeout_seconds" : 3600 , "undo_side_effects" : [ "SEO index will retain the URL for up to 24h" ] } If reversible is false , the skill should require explicit human approval before execution. A skill registry with undo support # skill_registry.py """ Registers agent skills with undo metadata. Blocks irreversible skills from running without explicit approval. """ from dataclasses import dataclass from typing import Optional , Callable import json @dataclass class Skill : name : str action_type : str # "read", "write", "send", "deploy" reversible : bool undo_fn : Optional [ Callable ] = None undo_timeout_seconds : int = 3600 side_effects : str = "" requires_approval : bool = False class SkillRegistry : def __init__ ( self ): self . skills = {} self . execution_log = [] def register ( self , skill : Skill ): # Irreversible write/send/deploy skills require approval if not skill . reversible and skill . action_type in ( " write " , " send " , " deploy " ): skill . requires_approval = True self . skills [ skill . name ] = skill def execute ( self , skill_name : str , inputs : dict , approved : bool = False ): skill = self . skills . get ( skill_name ) i

Visual Studio 2026's July update added organization-level custom agents for GitHub Copilot. An organization owner can now define a custom agent that every repository in the org automatically detects and offers in the agent selector. This is powerful and introduces a rollout risk: a single agent definition affects every developer in the organization simultaneously. The rollout problem When an org-level agent is published, every developer working in any repo in that org sees it in their agent selector. If the agent definition contains an incorrect instruction, a broken tool reference, or an overly permissive scope, it affects all developers at once. There is no canary by default. The agent definition review checklist Before publishing an org-level custom agent, review its definition against this checklist. 1. Instruction review # agent-definition.yml (example structure) name : org-code-reviewer description : Reviews PRs for security and style instructions : | Review each file change. Flag: - SQL injection in string concatenation - Missing input validation on public endpoints - Hardcoded credentials Do not modify files. Only comment. tools : - read_file - search_code - post_comment scope : organization Check: [ ] Instructions are specific enough to be testable ("flag SQL injection in string concatenation" not "review for security") [ ] Instructions do not conflict with existing repository-level AGENTS.md files [ ] The agent does not claim capabilities it does not have (e.g., "run tests" when no tools entry supports it) 2. Tool surface audit # Extract all tool references from the agent definition rg -n 'tools:' agent-definition.yml -A 20 | grep '^\s*-' For each tool: What resource does it access? (filesystem, network, repository API) Is it read-only or read-write? Does it require elevated permissions beyond the developer's own role? A post_comment tool can create noise across every PR. A write_file tool can modify code in every repo. Audit accordingly. 3. Canary test Be

Max Korbacher explains why successful internal development platforms cannot be built on tech alone. He discusses the pitfalls of infrastructure-first thinking, the importance of a clear product mindset, and how to measure real value using DevEx and SPACE metrics. Learn how to align your team, manage tech debt, and foster a thriving community to ensure lasting platform adoption. By Max Körbächer

Moving from Windows to macOS often creates a small workflow problem for developers: where did my familiar SSH tools go? PuTTY has been a classic SSH and Telnet client for Windows for many years. Many developers know its interface and workflow, so after switching platforms, the first thought is usually finding a macOS version. The reality is that the macOS ecosystem works differently. There are several practical options depending on how you manage remote systems. Option 1: Use the built-in SSH client on macOS For many developers, the SSH client that ships with macOS is already enough. A typical workflow looks like this: Use the terminal for server access Manage hosts through ~/.ssh/config Store aliases, usernames, ports, and key settings in one place Automate common connection tasks with scripts For example: ssh production-server can replace a long connection command when your SSH configuration is organized properly. This approach works especially well for developers who prefer command-line workflows and manage Linux servers regularly. Option 2: Use a GUI SSH client Some developers prefer a graphical interface because they manage many machines, protocols, or connection profiles. A good GUI client can help with: Organizing dozens or hundreds of servers Saving authentication settings Switching between SSH, RDP, VNC, and other protocols Reducing repetitive configuration work The macOS App Store has many SSH clients available. The right choice depends on whether you only need SSH or you need a complete remote management workflow. Tools like DartShell are designed around this multi-protocol scenario, where developers may need SSH for Linux servers, RDP for Windows machines, and other remote access methods in one place. Choosing the right workflow The decision usually comes down to how you work: A few Linux servers: macOS Terminal + SSH config is usually enough. Many servers and different protocols: a GUI management tool can save time. Team environments: centralized connec

AWS gives you three ways to run LLM inference in production. I've deployed all three for clients and the decision always comes down to the same variables: volume, team size, and how much you value your weekends. Here's the short version. The three paths Bedrock — Fully managed, pay-per-token. You call an API, you get tokens back. No GPUs, no cold starts, no 3am pages about OOM pods. SageMaker Endpoints - Semi-managed. You bring your model (or a fine-tuned one), deploy it on dedicated instances, and handle autoscaling. Pay per hour whether you're serving requests or not. Self-hosted on EKS — Full control. vLLM or TGI on GPU spot instances with Karpenter. Cheapest per token at scale, most operational overhead. The cost crossover that matters This is the table I keep coming back to with every client: Volume Bedrock (Haiku) SageMaker (g5.xlarge) EKS (g5.xlarge spot) 1K req/day ~$36/mo ✓ ~$1,015/mo ~$674/mo 50K req/day ~$1,800/mo ~$1,015/mo ~$674/mo ✓ 500K req/day ~$18,000/mo ~$6,090/mo ~$2,022/mo ✓ The crossover point where self-hosting beats Bedrock: 10,000–20,000 requests/day . Below that, Bedrock wins on simplicity alone. Above it, you're leaving serious money on the table. The hidden cost nobody models upfront Teams prototype on Bedrock (smart move — it's the fastest path to production). But the cost curve isn't linear. At 10K requests/day it's cheap. At 50K it's "we need to talk to finance." At 500K it's a rearchitecture project. The mistake is not choosing Bedrock at low volume. The mistake is not planning the exit path before you need it. Quick decision framework You should pick... When... Bedrock No ML infra team, <50K req/day, need frontier models (Claude, Llama) SageMaker Fine-tuned models, predictable traffic, need dedicated VPC EKS self-hosted >100K req/day, open-source models, dedicated platform team What I actually recommend Use a hybrid. Most production systems I've deployed use: Bedrock for complex reasoning and customer-facing chat (low volume, high qua