AI coding tools are powerful. But they’re also wasteful. A tiny helper-function question does not need Claude Sonnet. A huge architecture review probably does. That gap costs money. So I built Badgr Auto. It’s a local OpenAI-compatible proxy that routes each AI coding request to the cheapest model that can handle it. Point your coding tool at: http://localhost:8787/v1 Badgr Auto can route between: local models cheaper OSS cloud models premium models So instead of paying premium prices for every request, you can use: local for small tasks OSS cloud for normal coding work premium only when it actually matters It also tracks: actual cloud spend which route was used fallback events tokens safely removed estimated savings vs premium models The goal is simple: stop wasting premium tokens on cheap tasks. First launch is small: small task → local normal task → cheaper cloud hard task → premium provider fails → fallback duplicate code → safely removed receipts → clear spend trail AI coding is only going to get more expensive if every agent step goes to the top model. Badgr Auto is my attempt to make AI coding cheaper without making it worse.

Local-first agent trust console with a safe local workspace Discussion | Link

This is a submission for the June Solstice Game Jam What I Built For this game jam, I...

I independently shipped my first open-source repo this week. The tool I built was a cli which accesses quickbooks online data. While Claude Code did speed up the build, it still took considerable effort shaping the entire user experience for the cli around the pre-existing public APIs! Major learnings during the entire process. Would also love additional feedback from open-source developers here.I'm currently looking for feedback from experienced open-source developers: Are there any improvements you'd suggest around project structure, documentation, testing, or contributor onboarding or the tool functionality? https://github.com/intuit/intuit-cli-for-quickbooks #

Something changed in software engineering, and I do not think we have fully named it yet. For years, the job was mostly about writing code directly. Then autocomplete got better. Then chat-based coding assistants arrived. Now the workflow is shifting again: we describe goals, hand off chunks of work to agents, inspect their output, tighten the tests, and decide what gets merged. That is not the same job with a faster keyboard. It is a different shape of work. I would call it agentic engineering. The engineer is becoming a director Agentic engineering does not mean the engineer disappears. If anything, it makes the engineer's judgment more visible. A coding agent can read files, make changes, run commands, open pull requests, and iterate through errors. GitHub describes Copilot agent mode as a workflow where the agent can plan, edit, run terminal commands, and keep working until a task is complete. Google describes Jules as an asynchronous coding agent that can take a task, work in a virtual machine, and produce a pull request. Anthropic's Claude Code guidance talks openly about using multiple Claude sessions in parallel, giving agents clear context, and treating them like workers that need direction. That is the shift. The engineer is no longer only the person typing every line. The engineer is also the person deciding what should be built, what constraints matter, how to verify the result, and when the agent is wrong. Prompting is too small a word for this People often describe this work as prompting, but that undersells it. A prompt can be a single instruction. Agentic engineering is more like delegation. You define the task, provide the relevant context, set the boundaries, create checks, review the work, and decide the next move. If the agent goes in the wrong direction, the failure is not always the model's fault. Sometimes the task was too vague. Sometimes the repository had no tests. Sometimes the acceptance criteria lived only in someone's head. This is why

Would you treat a serious illness without seeing a doctor, relying only on whatever your favorite AI...

Google just made it significantly cheaper to enjoy its budget AI subscription tier.

This is an updated rewrite of my 2021 article on protected routes . A lot has changed in the React ecosystem since then. React Router moved from v5 to v7, class components have faded out, and the patterns we use for authentication state have matured. This version reflects how protected routes are built in modern React applications. Almost every web application requires some form of authentication to prevent unauthorized users from accessing parts of the application meant for signed-in users only. In this tutorial, I'll show how to set up an authentication flow and protect routes from unauthorized access using modern React patterns: function components, hooks, React Router v6+, and the Context API. First things first Install the dependency: npm i react-router-dom That's it. React Router v6 and above ships as a single package, so you no longer need to install react-router and react-router-dom separately. It is worthy of note that we will not be using Redux for authentication state in this version. For something as simple as "is the user logged in?", React's built-in Context API is the standard approach today. Redux still has its place, but it is overkill here. The Auth Context Instead of writing to localStorage directly from components and reading it in random places, we centralize authentication state in a context. This gives us a single source of truth and a clean useAuth() hook we can call anywhere in the app. Create ./src/auth/AuthContext.jsx : import { createContext , useContext , useState } from " react " ; const AuthContext = createContext ( null ); export function AuthProvider ({ children }) { const [ user , setUser ] = useState (() => { // Rehydrate on page refresh const saved = localStorage . getItem ( " user " ); return saved ? JSON . parse ( saved ) : null ; }); const login = async ( username , password ) => { // In a real app, this is an API call to your backend. // We simulate it here with hardcoded credentials. if ( username . toLowerCase () === " admin

Target: pnpm/pnpm Issue: pnpm/pnpm#12240 PR: pnpm/pnpm#12301 Public branch: https://github.com/scarab-systems/pnpm/tree/fix/deps-status-no-manifest Latest pushed commit: cb68ac1af0dcffbe4fb607a10b0df2046d2490ba This field test targeted a pnpm command-routing failure where pnpm self-upgrade could fail outside a project directory with: ERR_PNPM_NO_PKG_MANIFEST The issue looked simple at the surface: a global/self command should not require a project manifest just because the current working directory is not inside a package. But the repair boundary was more specific than “ignore missing manifest.” The problem was in the dependency-status verification path. When dependency status was unavailable because there was no project manifest, the command could fall through into the auto-install path. That made a self-upgrade/global-style command behave as if it needed a local project manifest. Failure shape The failing behavior was: pnpm self-upgrade run outside a project directory dependency status cannot be established from a project manifest the command path falls into install/manifest expectations result: ERR_PNPM_NO_PKG_MANIFEST That is the wrong ownership boundary. A self-upgrade command should not inherit project-manifest preconditions when there is no local project context. Boundary The boundary here is: global/self command execution versus project dependency-status verification Dependency-status verification can be useful when a command is operating inside a project. But when there is no project manifest and the command is not recursive/all-projects, “dependency status unavailable” should not automatically mean “try to auto-install project dependencies.” There are two different cases: Dependency status is unavailable because there is no project manifest. Dependency status is unexpectedly unavailable even though a root project manifest exists. Those cases should not behave the same. The repair preserves that distinction. What changed The patch updates: exec/commands/src

Have you ever stared at two different medicine boxes, squinting at the tiny font of the active ingredients, wondering: "Can I actually take these together?" Modern healthcare is complex, and drug-drug interactions (DDI) are a leading cause of avoidable ER visits. In this tutorial, we’re going to leverage GPT-4o Vision , React Native , and the FDA OpenData API to build a "Drug Conflict Scanner." We will utilize multimodal AI to transform messy pill-box photos into structured data and cross-reference them against official medical databases for safety. By the end of this guide, you'll master GPT-4o OCR structuring and automated knowledge graph verification for real-world health tech applications. 🚀 The Architecture 🏗️ The logic flow involves capturing images of multiple medicine labels, using GPT-4o's multimodal capabilities to extract chemical compounds, and then querying the FDA's database for potential interactions. graph TD A[React Native App] -->|Capture Multi-Photo| B[Node.js Backend] B -->|Image Buffer| C[GPT-4o Vision API] C -->|Structured JSON: Ingredients| B B -->|Search Interactions| D[FDA OpenData API] D -->|Drug Labels & Warnings| B B -->|Safety Report| A A -->|UI Alert| E{Safe or Warning?} Prerequisites 🛠️ To follow along, you'll need: GPT-4o API Key (via OpenAI) Node.js (for our backend relay) React Native (Expo is recommended for camera access) An account at open.fda.gov (though the public API works for limited requests) Step 1: Extracting Ingredients with GPT-4o Vision Traditional OCR struggles with curved medicine bottles and shiny packaging. GPT-4o excels here because it understands context. We don't just want text; we want the Generic Name of the drug. The Backend Logic (Node.js) // backend/scanner.js import OpenAI from " openai " ; const openai = new OpenAI ({ apiKey : process . env . OPENAI_API_KEY }); async function analyzeMedicineLabels ( imageUrls ) { const response = await openai . chat . completions . create ({ model : " gpt-4o " , messages :

Migrated 4 of 7 Notion automations to an MCP server in one weekend Two workflows stayed in Notion because the database UI beat any tool call MCP scope rule: one tool does one verb, never a Swiss Army function Result: 12 manual steps collapsed into 3 Claude prompts per publish I spent a weekend pulling four automations out of Notion and rebuilding them as MCP tools. Three of them got faster and one got worse before it got better. The biggest lesson was not about code. It was about deciding which jobs should never leave Notion in the first place. Why I Moved Off Notion In The First Place My Notion setup was not broken. It was just slow in a specific way. I had seven automations stitched together with Notion buttons, formula properties, and two third-party connectors. Every blog publish meant clicking through four pages, copying a title here, pasting a tag list there, and triggering a sync that took 90 seconds to confirm. Multiply that by the 18 articles I push in a normal month and the clicking adds up. The breaking point was a Tuesday where I lost 40 minutes to a connector that silently stopped firing. No error, no log, just a row that never updated. I checked the connector dashboard and it told me everything was healthy. It was not healthy. That kind of invisible failure is the worst kind because you trust it until you do not. MCP changed the math for me. An MCP server lets Claude call my own functions directly. Instead of Claude writing text and me ferrying that text into Notion by hand, Claude can call a tool that does the writing into my systems. The model becomes the operator, not just the writer. If you want the deeper context on what MCP actually is and why it matters at scale, MCP: The 97 Million Agentic Foundation goes through the bigger picture. So I made a list. Seven automations, sorted by how much human judgment each one needed. The ones at the top were pure mechanical steps: format this, push that, fetch a status. The ones at the bottom needed me to loo

A SaaS interface that works well for US users may confuse or alienate users in China, Germany, or Japan. Cultural differences affect everything from layout preferences to color meanings, form field expectations, and payment preferences. This guide covers the cross-cultural UX principles applied at tanstackship.com , a SaaS serving users across English, German, and Chinese markets. Cultural Dimensions and UI Impact Hofstede's Dimensions Applied to SaaS Design Dimension High vs Low UI Impact Power Distance Acceptance of hierarchy Navigation depth, permission displays Individualism vs Collectivism Personal vs group focus Social proof, testimonials Uncertainty Avoidance Tolerance for ambiguity Error messages, help text density Long-term Orientation Pragmatic vs normative Pricing display, trial periods By Market UX Element US (Low PD, High IND) DE (Low PD, High UA) CN (High PD, High COL) Navigation Flat, exploratory Structured, organized Hierarchical, guided Error handling Forgiving, "try again" Specific, detailed Authority-mediated Social proof Individual testimonials Expert reviews + data Group endorsement Pricing Monthly preferred Annual preference (trust) Discount attraction Help/Support Self-service docs Detailed documentation Chat + personal support Color meanings Green=success Green=environment Red=prosperity Color and Visual Design Color Meanings Across Cultures Color Western (US/EU) China Germany Japan Red Danger, passion Prosperity, luck Financial (deficit) Life, energy Blue Trust, technology Trust, immortality Trust, stability Trust, calm Green Success, nature Health, harmony Environment Youth, energy White Purity, clean Mourning Clean, efficiency Purity Yellow Warning, caution Imperial, power Jealousy Courage Practical Application // Adapt color scheme based on locale const colorSchemes = { en : { primary : " #2563EB " , // Blue — trust success : " #16A34A " , // Green — success danger : " #DC2626 " , // Red — danger warning : " #F59E0B " , // Yellow — warnin

RubyConf holds a special place in my heart. It was the very first tech conference I attended after receiving a scholarship fresh out of Flatiron School back in 2017 (you can read about my experience here ), and then in 2021, it was the stage for my first conference talk in Denver. Now, in another first, I joined the Program Committee for RubyConf 2026 to help put the program together, and what a program it is! We have an absolutely amazing lineup this year, and I'm so excited to see it come to life! Who else is planning on attending? Let's make plans to meet up and say hi!

If you've ever spun up an EC2 instance for a side project, accessed a remote work desktop from your personal laptop, or stored files on Google Drive without thinking about the physical hard drive it lives on, you've used virtualization. As the foundational technology behind all modern cloud computing, virtualization transformed how we build, deploy, and manage IT infrastructure—cutting hardware costs significantly for enterprises and making on-demand scalability a reality for teams of all sizes. In this guide, we'll break down exactly what virtualization is, how it powers the cloud, the 6 core types of virtualization, and best practices to implement it safely and efficiently. Table of Contents What is Virtualization in Cloud Computing? Core Virtualization Concepts You Need to Know Role of Virtualization in Cloud Computing 6 Key Types of Virtualization (With Use Cases) Top Benefits of Virtualization for Teams of All Sizes Virtualization vs. Related Technologies Virtualization vs. Cloud Computing Virtualization vs. Containerization Common Virtualization Challenges and Mitigations Real-World Virtualization Use Cases Virtualization Best Practices Conclusion References What is Virtualization in Cloud Computing? Virtualization is a technology that creates virtual, software-based representations of physical hardware (servers, storage, networks, etc.) and abstracts these resources from the underlying physical machine. A software layer called a hypervisor separates operating systems and applications from physical hardware, allowing multiple isolated, self-contained systems called Virtual Machines (VMs) to run simultaneously on a single physical host. Each VM has its own virtual CPU, memory, storage, and network interface, and operates independently of other VMs on the same host. For cloud providers, this technology is the backbone of all on-demand infrastructure services, allowing them to share physical hardware across thousands of customers securely and efficiently. Core Vi

I think it's fair to say that someone who has never done non-AI web development will always be vibe-coding. For, say, an experienced (20+ years) developer, would it still be vibe coding if they craft technically sound prompts (i.e. explicitly mention things to avoid/include, and define methodologies and algorithms as well as goals), and fully test (and have AI fix) the output, but never review the actual code? What if the prompts are loose, but they are fastidious about reviewing all code generated? submitted by /u/lindymad [link] [留言]

GitHub shipped a small changelog entry this week that says more about the future of coding agents than most of the launch demos. Security validation for third-party coding agents is now generally available. Not just for GitHub's own Copilot cloud agent. For third-party agents too, including Claude and OpenAI Codex. The feature sounds boring in the best possible way. When an agent creates code, GitHub can run CodeQL, check new dependencies against the GitHub Advisory Database, and use secret scanning to detect tokens, API keys, and other sensitive material. If it finds a problem, the agent tries to fix it. That is not the flashy part of agentic coding. It is the important part. Because once agents are allowed to act inside repos, the question stops being "which model wrote this diff?" and becomes "can the repository apply the same policy to every automation actor?" authorship is the wrong abstraction We still talk about generated code as if authorship is the primary thing that matters. Was this written by Copilot? Claude? Codex? A human with tab completion? A human who pasted something from a chat window and cleaned it up? A junior engineer following a Stack Overflow answer from 2018? Those distinctions matter for procurement and product marketing. They matter less for the repository. The repository has a simpler problem: a change is trying to enter the system. It may introduce a vulnerability, add a risky dependency, leak a secret, violate an internal rule, or be perfectly fine. That is why the GitHub change is interesting. It moves the useful boundary from "our approved coding assistant" to "any coding agent operating in this repository." the agent is now an actor For years, repository automation was mostly boring and legible. CI ran tests. Dependabot opened dependency updates. Release bots bumped versions. Linters complained. Security scanners commented. Humans reviewed. The automation could be annoying, but its shape was predictable. Coding agents are different.