标签：#devto

The best developer tools share one quality: you forget you are using them. Think about it. Your IDE fades into the background when you are in flow. Your terminal becomes muscle memory. These tools are invisible because they match your mental model so perfectly that there is zero friction between thought and action. This is exactly what online developer utilities should aspire to. The Problem with Fragmented DevTools Most developers have a bookmarks folder full of single-purpose websites: One for JSON formatting One for timestamp conversion One for Base64 encoding One for URL decoding Every switch between these tabs is a context loss. Every tool has a slightly different UI, different copy-paste format, different quirks. The Invisible Toolkit Opennomos Json (opennomos.com/en/project/01KJ850Z7PNGXHXESBM68HE12Y) consolidates timestamp conversion, JSON formatting, and Base64 encoding into a single workspace. No install. No accounts. No pricing tiers. Just open a tab and work. This is the north star for developer tools: make them so simple that the user never has to think about the tool itself — they only think about their actual task. The Trend Is Clear We have seen this pattern across the dev ecosystem: GitHub Codespaces made local IDE setup invisible Vercel made deployment invisible Replit made runtime environment invisible The next frontier is utility tools. The sooner they become invisible, the better. Try it: opennomos.com/en/project/01KJ850Z7PNGXHXESBM68HE12Y Part of the Nomos Build-in-Public series.

You've seen the alert. You've opened the PR. You've read the changelog. Then you realize: your code doesn't even call the vulnerable function. Every week. Hundreds of teams drowning in CVE notifications for packages sitting dormant in their node_modules — dependencies they pulled in years ago, bundled by a transitive library, and never actually executed. Meanwhile, the real vulnerabilities get buried. VigilOps is a free Node.js CLI that fixes this. How VigilOps Works VigilOps does three things: Scans dependencies against OSV.dev — the open vulnerability database used by GitHub, PyPI, and npm Runs static reachability analysis to filter out unreachable vulnerabilities (packages in your tree but never called by your code) Auto-opens a GitHub PR with the fix The result: you get one PR with one real vulnerability. Not a spreadsheet. Not a wall of Slack messages. A fix. Demo Here's a quick scan: npx vigilops scan examples/vigilops-demo-lodash And to see everything including suppressed (unreachable) deps: npx vigilops scan examples/vigilops-demo-express --all The --all flag shows what's in your dependency tree but not actually reachable from your code. That's what the noise looks like — and that's what VigilOps filters out. Why This Is Different Dependabot and Snyk scan your entire lockfile. They report every CVE in every package, regardless of whether your code ever touches the vulnerable surface. This creates alert fatigue that causes teams to eventually... stop reading. VigilOps inverts the model: only surface vulnerabilities in code you actually call. Dependabot: "Your project has 47 vulnerabilities" (but 40 are unreachable noise) VigilOps: "Your project has 1 reachable vulnerability. PR is ready." Quick Start npm install -g vigilops npx vigilops scan . Authenticate with GitHub: https://github.com/Vigilops/vigilops npx vigilops auth That's it. The first run will scan, analyze, and open a PR if there's a fixable reachable vulnerability. What's Included OSV.dev integrati

Writing changelogs is one of those developer tasks that sounds simple until you are staring at a messy commit history. Some commits matter to users. Some are internal cleanup. Some are merge commits. Some are meaningful only if you already know the codebase. I built a small Python example that turns commit messages or git diffs into structured changelog JSON using Telnyx AI Inference. Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/changelog-generator-python What it does The Flask app exposes: POST /generate POST /generate/from-diff GET /changelogs GET /changelogs/<id> GET /health POST /generate accepts a list of commit messages: { "version" : "v1.4.0" , "repo_name" : "billing-service" , "commits" : [ "feat: add Stripe webhook retry with exponential backoff" , "fix: correct tax calculation for EU VAT exemption" , "docs: update API reference for invoice endpoint" ] } The app asks Telnyx AI Inference to return grouped changelog JSON with sections like: Features Bug Fixes Improvements Breaking Changes Documentation Other There is also a POST /generate/from-diff endpoint if you want to summarize a git diff instead of commit messages. Why structured output matters For a changelog tool, plain text is useful, but structured output is more flexible. If the response comes back as JSON, you can: render it in a docs site save it in a release database post it into a PR comment send it to Slack open a release-note review workflow let a human approve it before publishing The example stores generated changelogs in memory and gives each one an ID, so you can list recent changelogs or retrieve a specific one. Run it Clone the examples repo: git clone https://github.com/team-telnyx/telnyx-code-examples.git cd telnyx-code-examples/changelog-generator-python Create your .env file: cp .env.example .env Add your Telnyx API key: TELNYX_API_KEY=your_telnyx_api_key AI_MODEL=moonshotai/Kimi-K2.6 HOST=127.0.0.1 Install and run: pip install -r requirements.txt python app.py

The dirty secret of online dev tools Every dev tool lives on a different website. jwt.io for JWT decoding. regex101 for regex testing. Some random site for JSON formatting. Another for diff checking. Another for curl → code. Another for SQL formatting. You end up with 10 bookmarks, 10 different UIs, and 10 different servers that just received your most sensitive data — and you never think twice about it. I didn't either. Until I did. What actually happens when you use these tools Let's take jwt.io as an example. Your JWT contains: Your auth algorithm Your user ID Your roles and permissions Your token expiry Sometimes your email, name, org ID When you paste it into jwt.io — it hits their server. It's in their request logs. Maybe forever. The same goes for regex101. Your regex patterns often encode business logic — validation rules, data formats, internal naming conventions. That goes to their database. And every online JSON formatter, diff checker, SQL tool, .env checker you've ever used? Same story. You're not just sharing data. You're sharing the shape of your system. Most of the time nothing bad happens. But "most of the time" is a terrible security posture for a developer who knows better. I got tired of it The more I thought about it, the more it bothered me. I was pasting production JWTs. Real API keys. Actual .env files with database URLs. Into random websites I knew nothing about. So I built DevTab - devtab.in One tab. 110+ dev tools. Zero server calls. Everything runs 100% in your browser via client-side JavaScript and WebAssembly. Open DevTools → Network while using it. Nothing fires. That's not a marketing claim. It's verifiable in 10 seconds. What's inside JSON tools JSON formatter & validator — real-time, error highlighting with line numbers JSON minifier JSON stringify & parse JSON → TypeScript / Pydantic / Go / Zod types Auth & security JWT decoder — header, payload, expiry countdown, issued-at in human time. Zero network requests. .env diff checker —

TLDR; I got tired of babysitting N terminal tabs of five different coding-agent CLIs. So I built agentproto — one daemon that drives Claude Code, Codex, Hermes, opencode, and Mastra through the same lifecycle, and actually supervises them. Why I built a daemon to drive every AI coding agent from one interface I have a confession: at any given moment I have Claude Code, Codex, and Hermes running in parallel terminal tabs, and I cannot remember which flag spawns which, which one eats --prompt , which one needs --cwd vs cd , and which one will hang forever if I close the laptop lid. simonw described the feeling on Hacker News recently — "Today I have Claude Code and Codex CLI and Codex Web running, often in parallel" — and called it a real jump in cognitive load compared to a year ago. aantix asked, also on HN: "how does everyone visually organize the multiple terminal tabs open for these numerous agents in various states?" I didn't have a good answer. So I built one. It's called agentproto . It is one daemon and one CLI that drives any coding-agent CLI — Claude Code, Codex, Hermes, opencode, Mastra, and a few more — through the same start / prompt / monitor / kill lifecycle, so you stop memorizing five different CLIs. On top of that lifecycle it adds the supervision layer people keep hand-rolling by hand: durable policy gates, nested orchestration, and multiplexed fan-in monitoring. MIT, no paid tier, the daemon itself is an MCP server. This is the story of why it exists. The hand-rolled watchdog The sharpest signal while I was building this came from other people independently re-inventing the same primitives in tmux scripts. On r/ClaudeAI, Confident_Chest5567 posted a writeup of orchestrating agents via tmux panes with a watchdog that resets dead sessions — "a swarm of agents that can keep themselves alive indefinitely." In the same thread, IssueConnect7471 (18 upvotes) described wiring a Redis pub/sub heartbeat plus dead-letter respawn between tmux panes, and arriv

When an AI API call fails, the tempting reaction is to switch models or providers. That is often premature. A large share of 401, 429, model_not_found, timeout, and confusing billing issues are not model-quality problems. They are route-evidence problems. The request moved through a key, base URL, model ID, retry rule, fallback path, and billing record. If those pieces are not visible, changing the model can hide the real cause. Before you replace the model, debug the route. A practical route checklist Confirm the key scope. Is the API key attached to the right project, environment, and quota rule? A key that works in one workspace can fail in another because the limit, budget, or allowed model set is different. Confirm the base URL. Many OpenAI-compatible errors start with a request going to the wrong host, version path, or proxy. Check the exact Base URL used by the client, not the one written in a README from memory. Confirm the model ID. A model_not_found error is not always a provider outage. It can be a copied alias, a retired ID, a route that does not support that model, or a mismatch between public model names and API model IDs. Separate 401, 403, 404, and 429. These errors ask different questions: 401: is the key present and valid? 403: is the key allowed to use this route or model? 404/model_not_found: is the exact model ID available on this route? 429: is the limit coming from the user, key, project, provider, retry loop, or budget rule? Treating all of them as provider instability wastes time. Look for retry and fallback behavior. A single user action may trigger more than one model call. Agents, RAG pipelines, streaming clients, and SDK retries can quietly multiply traffic. If fallback is enabled, the served route may differ from the requested model. Check the usage and charge record. A successful response is not the end of the test. You should be able to explain which key made the call, which model was requested, which route served it, how many tokens

There's a comfortable thing people say when they see an AI agent query a code map. "Nice crutch. For now." The logic underneath it is reasonable. Coding agents are young. Context windows are small and getting bigger. Models are dumb today and will be smart tomorrow. So a structural index, the thing that hands the agent a dependency graph it would otherwise have to reconstruct, looks like a patch over a temporary weakness. Wait two releases. The model will just hold the whole repo in its head and the map becomes a quaint workaround, like a spellchecker for someone who learned to spell. I build one of those maps Sense . I went looking for the data that would kill it. I didn't find it. I found the opposite. What a map hands an agent is a computed fact. What a better model hands you is a more confident guess . No amount of model progress turns the second into the first, because the difference between them isn't a quality gap that closes with scale. It's a difference of kind. The rest of this piece is the two findings that forced me there. The belief, stated fairly The claim at full strength, because a weak version is easy to knock over. A code map exists to compensate for what the model can't do yet. Today's agent greps, samples, and guesses at structure because it can't read the whole codebase at once. Tomorrow's agent reads all of it, reasons over all of it, and the guessing stops. Bigger windows plus better weights equal no more blind spots. The map is scaffolding you'll tear down once the building stands. If that's true, the right move is to skip the tool and wait. Both findings, in order. Proof one: the best model available was still blind The benchmark ran the same task on thirteen real Ruby repos. Pick the hub model of an app, the Inbox , the MergeRequest , the Spree::Order , and ask the agent to find every place that depends on it before a teardown change. The non-obvious dependents, the ones scattered through concerns and workers and config-string registries, w

I've been coding with AI agents for about two years. Every major one. Cursor, Copilot, Codex, OpenCode. They're good at generating code. They all share one problem. They forget everything. You finish a session, close the window, and the agent resets. Next time you open it, you're starting from zero. "We use pnpm, not npm." "The database is SQLite, not Postgres." "Don't touch the migrations folder." You repeat yourself. Every. Single. Time. Some tools added memory features. Usually as an afterthought. A pinned file. A custom instruction. A context window that grows until it hits a wall and everything old gets silently dropped. I didn't want a bigger context window. I wanted an agent that accumulates knowledge the way a colleague does. Not by being retrained. By taking notes, writing down what it learned, and reading those notes next time. That's what Jean2 can do. Not through fine-tuning. Not through vector embeddings. Through files on disk that the agent reads and writes itself. But here's the thing: none of this is on by default. By default, Jean2 is as bare as Codex or OpenCode. A blank prompt. No memory. No skills. No session search. You opt in to each layer in workspace settings . That's the point. You build the agent you want, layer by layer. The Four Layers If you turn them on, Jean2's agent has four knowledge layers that persist across sessions. They're not features bolted on top. They're part of the system prompt that gets composed every time a session starts. 1. Workspace Memory Turn on workspace memory in workspace settings , and the workspace gets two files: MEMORY.md for shared knowledge and USER.md for your personal preferences within that workspace. Both live at <workspace>/.jean2/ . The concept is simple. Shared knowledge that's useful for any agent working in that workspace. "We use pnpm." "The database is SQLite." "Don't touch the migrations folder." Whatever agent you bring in, coding specialist, reviewer, docs writer, they all get the same context

AI coding agents are becoming good enough to touch real codebases. They can refactor files, write tests, change architecture, move logic around, and sometimes modify more code in ten minutes than a human would in an afternoon. That is powerful. But it creates a new debugging problem. Git can tell you what changed . When an AI agent was involved, you often need to know something deeper: Why did this change happen? Which prompt caused this line? Which model produced it? What files did the agent read before writing it? What later changes depended on this agent action? That is the problem I wanted to solve with Causari . Causari is a local CLI for intent-addressable code . It records AI agent actions as causal events: prompts, models, reads, writes, diffs, reasoning, cost, and relationships between actions. The goal is simple: Git tracks bytes. Causari tracks intent and causality. Repository: https://github.com/croviatrust/causari Website: https://causari.dev The problem When a human developer changes code, there is usually some context. A commit message. A pull request. A ticket. A discussion. A design decision. With AI coding agents, the workflow is different. You ask something like this: Refactor the auth flow and add JWT refresh logic. The agent reads files, makes assumptions, writes code, maybe fixes tests, maybe changes something unrelated, then moves on. At the end, you have a diff. But the diff does not tell the full story. A suspicious line appears in auth.ts . Git can show when the line appeared. But Git cannot answer: which prompt produced this exact line? what completion did it come from? did the agent read the right files first? was this part of the original request or an accidental side effect? if I revert this, what downstream work am I also undoing? That gap becomes bigger as agents become more autonomous. The more work agents do, the more we need provenance. Not only code provenance. Intent provenance. The idea: intent-addressable code Causari treats an

Disclosure: I maintain Lynkr , an open-source router whose design decisions this post explains. The failure modes described are patterns widely reported across router issue trackers and local-LLM forums — the examples are representative reconstructions, not captured transcripts. The problem is real either way; ask anyone who's routed a coding agent to a 7B model. Everyone who gets their first LLM router working does the same thing within the hour: point the expensive coding agent at a free local model and watch the bill drop to zero. Then the agent tries to edit a file. The graveyard of downgraded sessions If you browse the issue tracker of any Claude Code router — or r/LocalLLaMA on any given week — you'll find the same story in a hundred variations. The routing works perfectly. The session dies anyway. The killers, in rough order of frequency: 1. Malformed tool arguments. The agent decides to call Edit , and the model produces arguments that are almost JSON: { "file_path" : "src/auth.js" , "old_string" : "if (token) {" , "new_string" : "if (token && !expired) {" One missing brace. The harness rejects the call, the model retries, produces a different malformation, and you're three turns deep into fixing nothing. Frontier models emit structurally valid tool calls with boring reliability; sub-10B models do it most of the time — and "most of the time," at 30 tool calls per session, means every session breaks. 2. Stale string matching. Edit -style tools require the old_string to match the file exactly. Small models paraphrase from memory instead of quoting — they'll "remember" the line as if (token) { when the file says if (accessToken) { . The edit fails, the model re-reads the file, burns 2,000 tokens, tries again with a different paraphrase. This is the single most reported failure, because it looks like the router's fault and is actually a capability cliff. 3. Hallucinated context. Ask a small model to run tests and it may confidently call Bash with npm test -- --g

Tra performance, piattaforma e toolchain: i temi che contano davvero per chi costruisce frontend oggi. Il frontend nel 2026 è diventato una disciplina sempre più “di prodotto”: non basta far funzionare l’interfaccia, serve che sia veloce, stabile, accessibile e misurabile in produzione. E quando l’ecosistema Chrome parla di “connessione” tra developer e piattaforma, il messaggio utile per chi lavora sul web è semplice: capire dove investire tempo per ottenere impatto reale sugli utenti . Di seguito, una lettura pratica dei temi che continuano a emergere come prioritari per chi costruisce applicazioni e siti moderni. 1) Performance: meno benchmark, più realtà La performance non è più un esercizio di ottimizzazione a fine progetto. È un requisito continuo che va gestito con strumenti, metriche e processi. Cosa significa “misurabile” oggi Metriche di campo (real user monitoring) : le prestazioni che contano sono quelle che arrivano dai dispositivi reali, su reti reali. Metriche di laboratorio : restano utili per regressioni e CI, ma vanno interpretate come “segnali” e non come verità assolute. Implicazione pratica Imposta una pipeline dove: le metriche sintetiche bloccano regressioni evidenti (build/PR), le metriche reali guidano le priorità (release e backlog). 2) DevTools: dal debug al controllo qualità Gli strumenti di sviluppo non servono più solo a “trovare il bug”, ma a ridurre il rischio : regressioni di layout, memory leak, risorse inutili, dipendenze pesanti. Abitudini che fanno differenza Profilare prima di ottimizzare: CPU, rete e rendering hanno colli di bottiglia diversi. Isolare i cambiamenti: una variazione di bundling o di immagini può ribaltare il profilo prestazionale più di una micro-ottimizzazione in JS. 3) La piattaforma web continua a crescere (e chiede scelte più consapevoli) La Web Platform oggi offre API potenti, ma la parte difficile non è “usarle”: è scegliere quando usarle. Un criterio utile Se una feature riduce complessità (meno librerie,

Every developer has been there: you need to format a JSON blob, decode some Base64, or convert a timestamp. You open your terminal, look for the right npm package, or — worse — write a quick script. I used to do this too. Then I discovered a better pattern. The Problem with Local CLI Tools Local tools have real drawbacks: Installation overhead : npm install -g some-tool for a one-time task Version rot : tool stops working after OS update No sharing : you format JSON but cant send the result to a colleague Environment drift : works on your machine, not on staging Online Tools as a Pattern Opennomos Json (reachable via opennomos.com/en/project/01KJ850Z7PNGXHXESBM68HE12Y) represents a shift: developer tools as a platform , not as utilities you install. What makes this different: Zero install — browser tab, done Cross-device — phone, laptop, any OS Shareable results — formatted output has a URL you can send to teammates Timestamp converter built in — ms, seconds, ISO 8601, bidirectional Base64 codec — no need for a separate site The Bigger Trend We are seeing the same pattern across the dev ecosystem: GitHub Codespaces (IDE in browser), Replit (runtime in browser), Vercel (deployment in browser). The next frontier is utility tools in browser . Why run jq locally when a well-designed online tool does it faster and gives you a share link? Try It Head to opennomos.com/en/project/01KJ850Z7PNGXHXESBM68HE12Y — the JSON tools are free, fast, and part of a broader contributor rewards system that makes open-source tooling sustainable. Built as part of the Nomos Build-in-Public series.

CCA-Audit — open source (MIT) AI code review has a trust problem, and it's not that it misses bugs. It's that it invents them. If you've run an LLM over a diff, you've seen it: a "possible null dereference" on a value that's guarded three lines up. A "SQL injection" your ORM already parameterizes. A "race condition" that can't happen. And then — worse — it confidently rewrites working code to "fix" the thing that was never broken. The real bug, meanwhile, sits quietly in the noise. The problem isn't intelligence. It's that most AI reviewers report their first impression as a verdict. A model reads a diff, pattern-matches "this looks like X," and emits a finding — without ever going back to check whether X is actually reachable in this code. Humans do a second pass ("wait, is price validated upstream?"). Most AI-review pipelines skip it. Here are two gates that add that second pass — and a stress test showing what they catch. Gate 1: verify findings before you fix (anti-hallucination) The idea is simple: no finding is allowed into the fix plan until a separate step re-checks it against the real code. After the auditors produce findings, a verification pass takes each one and asks three questions: Does the issue actually exist at the cited line? Is it in the code that changed, or a pre-existing thing outside the diff? Is the stated impact real, or already mitigated elsewhere — a guard upstream, a value validated before this point, a config defined in another module? The key design choice: bias the verifier toward refuting. A wrongly-confirmed finding causes a needless (sometimes harmful) fix; a wrongly-dropped one is cheap to recover. So when the evidence isn't clear, drop it or escalate to a human — don't fix on a hunch. This one step kills the majority of hallucinated findings, because hallucinations rarely survive contact with "show me the exact line, and prove the impact can occur." Gate 2: prove the fix maps to the finding (anti-regression + provenance) Catching

A month ago we added a card_token column to the users table so a background job could retry failed Pro charges. It lasted about two days. Storing card data in your own database drops you into PCI-DSS (the compliance standard that kicks in the moment card data touches your systems), so we pulled it and moved to Stripe-managed payment methods. Last week the charges started failing again. New Claude Code session, no memory of any of that. Its plan? Add a card_token column to users and retry. I don't really blame the agent. It had the context the first time and it was right. The problem is that context died when the session closed. That's the part I never see mentioned about building with agents: the code sticks around, the reasoning doesn't. People leave a trail without trying. A commit message, a PR comment, the Slack thread before it. Agents don't, and the prompt that explained everything is gone by morning. So I built Selvedge to hold onto the reasoning. What happened the second time Selvedge is a local MCP server the agent calls as it works. There's a four-line block in our CLAUDE.md that says, roughly: before you touch an entity, check if we've been here before. $ selvedge prior-attempts users.card_token users.card_token Prior attempt 28 days ago ( reverted after 2 days ) Reasoning Added to store card tokens for one-click retries. Outcome REVERTED — kept card data out of our own DB to stay clear of PCI-DSS scope ; moved to Stripe-managed methods. So it didn't add the column. It charged off_session against the saved Stripe PaymentMethod instead. Charge retried, no card data in our database, done. We paid for that lesson once. How it works The agent writes down why live, in the moment, from the same context that made the change. That's the whole trick. A lot of the "git blame for AI" tools take your diff afterward and ask a second model to explain it. That's a guess. It reads well, but you can't really build on it. Selvedge stores what the agent actually meant, in i

I just shipped 5 new tools to DevNestio — a hub of 172 free, browser-only developer utilities. All tools are zero-signup, zero-upload, and work offline. 1. GraphQL Query Formatter & Minifier https://devnestio.pages.dev/graphql-formatter/ Paste any GraphQL operation and get: Pretty-print — consistent indentation Minify — strips comments and whitespace for smaller request payloads Validation — brace/parenthesis balance check Operation detection — lists all named query , mutation , subscription , fragment Useful for quick query cleanup before pasting into code reviews or API docs. 2. Protobuf (.proto) Formatter & Validator https://devnestio.pages.dev/protobuf-formatter/ Online formatter and validator for Protocol Buffer .proto files: Duplicate field number detection Message and enum structure validation Syntax-highlighted output One-click copy Great for a sanity check before pushing .proto changes in a gRPC service. 3. Docker Compose Validator https://devnestio.pages.dev/docker-compose-validator/ Paste your docker-compose.yml to catch: Missing services section Services without image or build Invalid port mappings ( 80:80 , 127.0.0.1:8080:80 , 53:53/udp , ranges…) depends_on referencing non-existent services Circular dependency detection (A→B→A) Unknown restart policies # This will flag errors: services : web : ports : - " abc:xyz" # invalid port depends_on : - missing_service # unknown service 4. Dockerfile Analyzer & Linter https://devnestio.pages.dev/dockerfile-analyzer/ Analyzes your Dockerfile for best practice violations across three categories: Security sudo usage inside RUN Container running as root (no USER instruction) Secrets baked into ENV / ARG (password, secret, token, key) Image size :latest base image tag apt-get update in a separate RUN (stale cache risk) apt-get install without --no-install-recommends apt cache not cleaned ( rm -rf /var/lib/apt/lists/* ) ADD used for local files instead of COPY Layer optimization Consecutive RUN instructions (suggest c

Stop memorizing ANSI escape sequences. I built a browser tool to generate them visually — pick colors, styles, and get the code ready to paste. Try it 🔗 ANSI Color Code Generator — DevNestio Features 3 color modes : 8-color, 256-color palette, RGB truecolor (24-bit) 8 text styles : Bold, Dim, Italic, Underline, Blink, Reverse, Hidden, Strikethrough Separate FG/BG : Set foreground and background colors independently 3 output formats : Shell ( echo -e ), Python ( print ), Raw escape sequence Live preview in a simulated terminal box How ANSI sequences work ESC [ <codes> m Multiple codes are separated by ; . Reset is ESC[0m . 8-color : codes 30-37 (FG), 40-47 (BG), 90-97 (bright FG) 256-color : ESC[38;5;<0-255>m for FG, ESC[48;5;<0-255>m for BG RGB truecolor : ESC[38;2;<R>;<G>;<B>m 256-color palette calculation function get256Color ( i ) { if ( i < 16 ) return standardColors [ i ]. hex ; if ( i < 232 ) { const n = i - 16 ; const r = Math . floor ( n / 36 ) * 51 ; // 255/5 = 51 const g = Math . floor (( n % 36 ) / 6 ) * 51 ; const b = ( n % 6 ) * 51 ; return `rgb( ${ r } , ${ g } , ${ b } )` ; } const v = ( i - 232 ) * 10 + 8 ; // 24 grayscale steps return `rgb( ${ v } , ${ v } , ${ v } )` ; } Output examples # Bold red text on black echo -e " \e [1;31mHello, Terminal! \e [0m" # RGB orange (Python) print ( " \0 33[38;2;255;128;0mOrange text \0 33[0m" ) Tested with 128 assertions covering code generation, color math, and format strings. Part of DevNestio — 115 free browser-only developer tools.

I built a browser-based bitwise calculator that performs AND, OR, XOR, NOT, NAND, NOR, XNOR, arithmetic/logical shifts, and rotate operations on 32-bit integers — with a live clickable bit grid. Try it 🔗 Bitwise Calculator — DevNestio Features 13 operations : AND, OR, XOR, NOT A/B, NAND, NOR, XNOR, SHL, SHR, SHRA, ROTL, ROTR Visual 32-bit grid : Click any bit to toggle Operand A on the fly Multi-base input : Auto-detect 0xFF , 0b1010 , 0o17 , or decimal 4 output formats : Hex, decimal, binary (grouped), octal — all with copy buttons No server, no upload — everything runs in-browser The JavaScript integer trap Bitwise ops in JS coerce values to signed 32-bit integers. To get unsigned results you need >>> 0 : case NOT_A : return ( ~ a ) >>> 0 ; // without >>> 0, ~0 shows as -1 case XNOR : return ( ~ ( a ^ b )) >>> 0 ; case ROTL : return (( a << s ) | ( a >>> ( 32 - s ))) >>> 0 ; Rotate without a dedicated instruction JavaScript has no ROL/ROR, so combine two shifts: // Rotate left by s bits (( a << s ) | ( a >>> ( 32 - s ))) >>> 0 Tested with 99 assertions All core logic — parsing, computing, edge cases like XNOR with ~0xFF = 0xFFFFFF00 — covered in a Node.js test file using assert . Part of DevNestio — a growing collection of 115 free browser-only developer tools.

Vendor onboarding usually starts with one clean request and then turns into a messy thread. Procurement asks for a W-9, security asks for a SOC 2 report, finance asks for remittance details, legal asks for an executed agreement, and the vendor replies with four attachments across three messages because different people own different parts of the process. That is exactly the kind of workflow where a generic "AI email assistant" gets risky. You do not want a model improvising legal language, requesting bank details in the wrong channel, or forwarding a confidential report to the wrong internal alias. You want the agent to own the repetitive coordination while your application keeps the state machine, policy, audit log, and approvals. The pattern I reach for is a dedicated Nylas Agent Account: vendors@yourcompany.com . It is a real mailbox the onboarding agent owns. It receives the vendor's replies, detects what is attached, updates your vendor record, sends safe reminders, and escalates missing or sensitive items to a human. The agent is not borrowing an employee's inbox, and it is not scraping a shared procurement mailbox. It has a grant, an email address, webhooks, threads, folders, and the same Messages API you would use for any other mailbox. I work on the Nylas CLI, so the terminal examples below use the commands I would use while building and debugging this flow. I also include the raw API calls because the production version belongs in your service, not in a shell script. What the agent should own Start by drawing the boundary tightly. A vendor onboarding agent should own message handling and coordination, not business approval. Good responsibilities: Receive vendor replies at a stable address. Read message bodies and attachment metadata. Match a reply to an existing vendor record. Detect which onboarding items are complete, missing, expired, or unreadable. Draft reminders and status updates. Schedule handoff calls when the vendor asks for help. Escalate sensit

This week was largely a Claude story: Sonnet 5 landed with enough benchmark muscle to make Opus feel redundant for most workloads, and GitLab's production data backs up the claims. Alongside that, GitHub Copilot quietly dropped its JetBrains friction, and Google's image model got cheaper and faster on Vercel's gateway. Here's what's worth acting on. Claude Sonnet 5 launches on Vercel AI Gateway Sonnet 5 is available now via Vercel AI Gateway at anthropic/claude-sonnet-5 . Launch pricing is $2/$10 per million input/output tokens—identical to Sonnet 4.6—but that rate expires August 31, after which it steps to $3/$15. The model matches Opus 4.8 on coding and agentic benchmarks, which means you can stop routing hard tasks to Opus and absorb a 50–67% cost reduction in the process. For AI SDK users, this is a one-line change. Stronger long-context handling and document parsing are the practical wins for RAG pipelines and multi-turn agent workflows—two areas where Sonnet 4.6 had real rough edges. Verdict: Ship. Update your model identifier before August 31 while the launch pricing holds. Zero breaking changes, and there's no reason to stay on 4.6 for new work. Sonnet 5 closes Opus gap at lower cost Beyond the Vercel integration, the broader Sonnet 5 release deserves its own read. The model is now the default reasoning tier replacing Sonnet 4.6 across Anthropic's plans, and the capability jump is specifically on agentic task completion—planning, multi-step tool use, brownfield code navigation. Early testers report that tasks which previously stalled midway through agent loops now finish end-to-end, which is a qualitatively different outcome from incremental benchmark gains. The economics are straightforward: Opus-level performance at Sonnet prices through August, then a modest step up to $3/$15. If you're running production agents today, the cost-per-completed-task improvement compounds because you're paying less and spending fewer cycles on failure recovery and re-promptin

A reviewer that flags the same known issue on every run trains you to ignore it. The fix can't be "hide findings," because a tool that silently drops things is worse than one that nags. CommitBrief has two ways to accept a finding and move on — a per-developer baseline and an in-source suppression marker — and both are built so that what they remove is always counted, never quietly swallowed. The interesting part is how a finding keeps its identity when the code around it moves. TL;DR Baseline ( .commitbrief/baseline.json , gitignored): accept the current findings once; later runs drop anything whose fingerprint is already in the file. Inline suppression : a commitbrief-ignore: <reason> comment on or above a line removes that finding — and lives in committed source, so a reviewer sees it. A finding's fingerprint deliberately excludes its line number , so accepting it survives the code drifting up and down the file. Both are TRUE removals — they affect --fail-on and the JSON findings[] , not just the display — and both print what they removed. The limit. The baseline is per-developer, not a shared team policy; it quiets your runs, not CI's. The fingerprint that survives code drift The whole design rests on one question: when is a finding "the same finding" you already accepted? If the answer included the line number, a baseline would evaporate the moment you added an import above the issue. So it doesn't. A finding's identity is three fields, hashed: func normalizeTitle ( title string ) string { return strings . ToLower ( strings . Join ( strings . Fields ( title ), " " )) } func Fingerprint ( f render . Finding ) string { h := sha256 . New () h . Write ([] byte ( f . File )) h . Write ([] byte { 0 }) h . Write ([] byte ( f . Severity )) h . Write ([] byte { 0 }) h . Write ([] byte ( normalizeTitle ( f . Title ))) return hex . EncodeToString ( h . Sum ( nil )) } File, severity, and a normalized title — and nothing else. Line is out, so the same issue keeps its finger