AI 资讯

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

The OpenAI Agents SDK (formerly Swarm, released as stable in early 2026) is a Python library for building multi-agent AI systems. Unlike LangChain's abstraction-heavy approach or CrewAI's role-playing model, the Agents SDK exposes five clean primitives and gets out of the way. This guide covers everything from setup to production deployment, including handoffs, guardrails, sessions, and tracing. Installing and Configuring pip install openai-agents Python 3.10+ required. Set your API key: export OPENAI_API_KEY = sk-... The SDK also works with non-OpenAI models via LiteLLM — more on that later. The Five Core Primitives Agent → LLM + system instructions + tools + handoffs Runner → executes the agent loop (sync or async) Tools → Python functions the agent can call Handoffs → transfer control to another agent Guardrails → validate input/output before processing Sessions → persistent conversation state Your First Agent from agents import Agent , Runner agent = Agent ( name = " Code Reviewer " , instructions = """ You are a senior Python developer reviewing code for correctness, security issues, and adherence to PEP 8. Be specific and actionable. """ ) result = Runner . run_sync ( agent , " Review this function: def add(a,b): return a+b " ) print ( result . final_output ) Runner.run_sync() is the blocking version. Use await Runner.run() in async contexts. Tools: Extending What Agents Can Do The @function_tool decorator converts any Python function into a tool the agent can call. The docstring becomes the tool's description — write it clearly: from agents import Agent , Runner , function_tool import subprocess import os @function_tool def run_tests ( test_path : str ) -> str : """ Run pytest on the specified test file or directory. Args: test_path: Relative path to test file or directory (must be within ./tests/) """ # Security: restrict to tests/ directory only safe_path = os . path . join ( " ./tests " , os . path . basename ( test_path )) if not os . path . exists ( safe

Introduction At recent technology conferences, one topic has caught my attention: every year, more health-focused devices, sensors, and applications appear. Smartwatches track heart rate, smart scales measure body data, glucose monitors record blood sugar levels, and apps help users track sleep or nutrition. Today, the amount of information we can collect about our own bodies is enormous. This article was inspired by an everyday experience with my father, Herminio ❤️ . Whenever he has a medical appointment, he opens the Apple Health app and shows the doctor the evolution of his heart rate, physical activity, sleep hours, and other recorded metrics. While watching this, I kept asking myself the same question: are we really making the most of all this information? Showing a chart during a medical appointment can be useful, but the data could provide much more value if it were automatically processed, summarized, and transformed into a structured health report. For this reason in this project, I use Gemini to transform previously calculated metrics into a clear and organized summary. The LLM does not analyze all the raw records or perform the main calculations. The pipeline processes the data, calculates the indicators, and generates the visualizations, while the model acts as a support layer for building the report narrative. The goal is not to create a medical application or replace professional judgment. Instead, the purpose is to build a prototype that shows how Apple Health exports, deterministic data processing, visualizations, and an LLM can be combined to generate automated reports. This project was developed using simulated data from three patients, so the complete pipeline can be reproduced without using real clinical information. ✨ Why Gemini? This project uses an LLM to transform previously processed metrics into a structured narrative that can be reviewed more easily by a healthcare professional. I chose Gemini for practical reasons: 〰️ I was already famil

A few weeks ago a Business Manager handed me a 50-page AI-generated technical spec. The document was impressive. The perspective behind it was the problem. I had talked to him a few days earlier about a new internal tool the company needed. We discussed the use case and the requirements in depth. Later on, I discussed those same requirements with my IT team and assigned them the job of making the technical specification. But before my team finished, the Business Manager handed me his own spec. A spec ready to be executed. The document was generated with AI assistance and it was impressive — fifty pages long, detailed feature breakdown, implementation timeline, cost projections. Everything looked professional. The AI had done exactly what it was asked to do. I read the whole document and noticed a problem. Not with the quality of the document but with the perspective that shaped it. The spec called for a manual Excel-based workflow with several manual steps and validations in-between. All seemed clean and manageable, matching the Business Manager's mental model of how that business workflow should work. When I checked the spec my team was working on using the same AI assistance tools, I noticed they had produced something completely different: automated data ingestion, real-time dashboards, API integrations with existing systems. Both specs addressed the same business need. Both were technically sound. Both could be built in roughly the same timeframe. But they were fundamentally different architectures, shaped by fundamentally different perspectives on how work should happen. The Business Manager's version was optimized for control and visibility — he could see every step, every piece of information and approve everything manually at any stage. The technical lead's version optimized for efficiency and scale — minimal manual intervention, automated error handling, designed to handle 10x the current volume without breaking. Neither person was wrong. But the AI amplifi

Part 2 of the Building create-notils series. In my previous article , I explained why I stopped copy-pasting repositories and started building my own project scaffolding tool. However, one major architectural problem remained: I wanted create-notils to support both of these primary project structures. A standalone Next.js application: my-app/ ├── src/ ├── public/ ├── package.json └── components.json And a Turborepo monorepo: my-app/ ├── apps/ │ └── app/ ├── packages/ │ ├── ui/ │ └── config/ ├── turbo.json └── package.json At first glance, the obvious solution is to maintain two separate templates—one for standalone and one for monorepo. Problem solved, right? Except... it isn't. The Hidden Cost of Multiple Templates Every starter template starts out identical. Then one day, you fix a subtle bug in one template and forget to update the other. A week later, you upgrade Next.js in one repository before getting around to the second. A month later, you improve your UI package and find yourself manually copying files back and forth between folders. Eventually, the templates slowly drift apart. The true cost isn't creating templates; the cost is maintaining them forever. What Actually Changes? When I sat down and compared the two project layouts side by side, surprisingly little was different. The actual application code, UI components, theming, and utility functions were 100% identical. The only real differences were the structural project boundaries: Concern Monorepo Standalone UI Package packages/ui src/components/ui Utilities @notils/ui/lib/utils @/lib/utils Configuration Shared workspace package Local configuration Package Manifests Multiple ( package.json files) Single root manifest Workspace Tooling Present ( turbo.json , workspaces) Removed entirely Everything else was effectively the exact same code. That single observation changed the entire architecture of create-notils . A Different Approach: The Canonical Source of Truth Instead of maintaining two templates, I

When we first decided to bring AI into analysts’ work, the task seemed fairly down-to-earth. The company has several development teams and roughly fifteen analysts. They collect requirements, prepare tasks, describe changes in Confluence, think through testing, and help align future implementation with both business and development. A lot of this work is repetitive, so giving analysts a tool that could prepare first drafts felt like an obvious idea. The problem is that a document in this kind of process almost never stands on its own. The same change exists in Jira, in Confluence, in mockups, in test scenarios, and in technical notes. Sometimes there are also separate instructions for making changes in the codebase. Each artifact has its own purpose, but all of them describe the same future system behavior. If the wording drifts apart, that can go unnoticed for several days, until different people begin working from different versions. A typical case looked roughly like this (the details and names are changed, but the mechanism is real). Jira said that a status field could have three values: draft , active , and archived . Confluence still contained an older table with only two values, while the test scenario also checked for disabled , which had been discussed early on and later rejected. The developer implemented what was written in Jira. The tester opened the scenario and filed a defect because disabled was missing. Only after that did the analyst compare the documents and realize that each of them preserved a different version of the decision. Nothing catastrophic happened. We simply had to go through the documentation again, update the tests, clarify the task, explain to the developer that the code did not need to change, and send the package through review one more time. It’s exactly these “nothing serious” moments that add up to delays, when the same task travels two or three times between an analyst, a developer, and a tester. At some point, it becomes diffi

Nothing is more frustrating than spending hours, or even days, perfecting a PCB design only to discover it fails during production. The secret to avoiding this is simple: apply PCB design standards from the very beginning. These guidelines act as a blueprint for reliability, manufacturability, and long-term performance, guiding every aspect of your board—from trace widths and spacing to via placement, solder mask, and layer stackups. Following these recommended practices doesn’t just prevent manufacturing errors—you save time, reduce costs, improve quality, and minimize delays. Whether you’re building a prototype or preparing for full-scale production, designing with these rules in mind ensures your PCB performs exactly as intended. Applying these best practices sets the foundation for success in any production scenario. By starting with the right standards, you can avoid costly mistakes before they happen and bring your product to life smoothly. Why PCB Design Standards Matter (More Than You Think) PCB standards are not theoretical rules. They are: • Proven engineering practices • Built from real-world failures • Designed to reduce risk Without them, you are basically designing blindly. With them, you get: • Higher first-pass success rate • Faster manufacturing approval • Reduced rework and cost • Better product reliability Steps to Apply PCB Standards in Your Design Here’s a practical, step-by-step guide to apply PCB design standards effectively: Step 1: Start with the Right Standards (Not All Are Needed) You don’t need to follow everything. You need to follow the right ones. Key standards to consider: • IPC-2221 → General PCB design standard • IPC-7351 → Footprint design guidelines • IPC-A-600 → PCB acceptability • IPC-A-610 → Assembly quality Practical Tip: Start with IPC-2221 + IPC-7351 if you're doing design. Step 2: Apply Standards During Component Placement Most failures start here—not routing. Common Mistakes: • Random component placement • Ignoring signal

Optimizing RAG at Scale: Chunking, Retrieval, and the Bayesian Search That Cut Latency 40% How we moved from "semantic search + hope" to a measured, tunable retrieval pipeline with 95% recall@10 The RAG Reality Check Everyone ships RAG the same way: chunk by 512 tokens, embed with text-embedding-3-small , top-k=5, stuff into context. It works for demos. Then you hit production: Legal contracts: 512 tokens splits clauses mid-sentence API docs: 1000-token chunks drown signal in noise Customer tickets: Conversational context needs overlap, not fixed windows Latency: 500ms embedding + 200ms vector search + 300ms LLM = 1s+ per query We rebuilt our retrieval layer from first principles. Here's what actually moves metrics. Chunking: One Size Fits None # rag/chunking.py from abc import ABC , abstractmethod from dataclasses import dataclass @dataclass class Chunk : text : str metadata : dict token_count : int chunk_id : str class ChunkingStrategy ( ABC ): @abstractmethod def chunk ( self , document : str , metadata : dict ) -> list [ Chunk ]: ... class FixedTokenChunker ( ChunkingStrategy ): """ Baseline. Good for homogeneous content. """ def __init__ ( self , chunk_size = 512 , overlap = 50 ): self . chunk_size = chunk_size self . overlap = overlap class RecursiveChunker ( ChunkingStrategy ): """ Respects structure: markdown headers, code blocks, paragraphs. """ def __init__ ( self , separators = [ " \n ## " , " \n ### " , " \n\n " , " \n " , " " ], chunk_size = 512 ): self . separators = separators self . chunk_size = chunk_size class SemanticChunker ( ChunkingStrategy ): """ Uses embedding similarity to find natural boundaries. """ def __init__ ( self , model = " text-embedding-3-small " , threshold = 0.7 ): self . model = model self . threshold = threshold class AgenticChunker ( ChunkingStrategy ): """ LLM decides boundaries. Expensive but highest quality for complex docs. """ def __init__ ( self , model = " gpt-4o-mini " ): self . model = model Our production config by

Building Production-Grade LLM Evaluation Pipelines: From Vibes to Metrics How we replaced "looks good to me" with automated evaluation catching 92% of hallucinations before deployment The Problem: Why "Vibe Checks" Fail in Production Three months ago, our team shipped a RAG-based customer support assistant. It worked great in testing — we'd ask it questions, read the answers, and say "yeah, that looks right." Then it hit production. A customer asked about their billing cycle. The assistant confidently cited a policy that didn't exist. Another asked about API rate limits and got numbers from a competitor's documentation. By the time we caught it, 500+ users had seen hallucinated responses. The post-mortem was brutal: we had zero automated evaluation . Our test process was literally "ask 5 questions, read answers, thumbs up." What Production Evaluation Actually Needs Academic benchmarks (MMLU, HellaSwag) don't tell you if your system works for your use case. Production evaluation needs: Domain-specific judges — Your criteria, not generic "helpfulness" Speed — Evaluation must run in CI/CD, not overnight Regression detection — Know immediately when a prompt change breaks things CI/CD integration — Block merges that degrade quality Golden dataset management — Versioned, stratified, growing test cases Architecture: The Evaluation Pipeline ┌─────────────┐ ┌──────────────┐ ┌────────────────────┐ ┌──────────────┐ │ Test Cases │────▶│ LLM Under │────▶│ Judge Ensemble │────▶│ Metrics & │ │ (Golden Set)│ │ Test │ │ - Faithfulness │ │ Regression │ └─────────────┘ └──────────────┘ │ - Instruction F. │ │ Detection │ │ - JSON Schema │ └──────┬───────┘ │ - Custom LLM │ ▼ └────────────────────┘ ┌──────────────┐ │ Dashboard/ │ │ PR Comments │ └──────────────┘ Core Abstractions # eval/base.py @dataclass ( frozen = True ) class TestCase : id : str input : dict [ str , Any ] expected : dict [ str , Any ] | None = None tags : list [ str ] = field ( default_factory = list ) # ["edge-case",

For a long time I ran product extraction off a database of custom selector configs. Hundreds of retailers, each with its own set of CSS selectors mapped field by field: price here, title there, image over there. It worked. It was also a treadmill. Every retailer that redesigned its frontend silently broke its config, and the maintenance tax grew with every retailer I added. Hundreds of configs is hundreds of things that can rot without telling you, usually right before someone downstream asks why a brand's prices went null. At some point I stopped feeding it. The scraping platform I ran at my last engagement fed a 20M+ product catalogue at millions of pages a day, and the thing that made that survivable wasn't better per-site config. It was leaning on almost no per-site config at all. The pattern Instead of one careful parser per site, run several cheap generic extractors on every page, in parallel: JSON-LD. A huge share of e-commerce pages ship a schema.org/Product block because Google rewards it. It has name, price, currency, availability, images. It's the closest thing to a public API hiding in the HTML. OpenGraph tags. og:title , og:image , product:price:amount . Lower quality than JSON-LD, but present on sites too lazy for structured data, because everyone wants pretty link previews. Microdata / RDFa. Older sites, still surprisingly common outside the US. Embedded state. __NEXT_DATA__ , window.__INITIAL_STATE__ and friends. A JSON blob the site's own frontend hydrates from. Heuristics. A price-shaped string near a currency symbol inside the main content region. The largest above-the-fold image. The h1 . Dumb, and dumb works more often than you'd think. None of these is reliable alone. OG price tags go stale, JSON-LD sometimes describes the wrong variant, heuristics grab the crossed-out "was" price. The trick is you don't pick an extractor. You pick per field, and you let agreement between sources carry the decision. Confidence merge Each extractor emits candida

The next time you apply for a job, AI may screen your résumé before any human sees it. But there’s good reason to question whether AI will judge you fairly. Researchers already know that LLMs pick up human biases from their training data. New research suggests that LLMs can also develop their own biases from…

The rules are really simple. Players take turns claiming a country that shares a land border with the current one. You lose if you have no valid moves left. I'd appreciate any feedback. Source code: https://github.com/spider-hand/GeoChess

Tu prueba pasó el lunes: misma entrada, mismo código y temperature=0 . El martes falló sin cambios en tu aplicación. La aserción esperaba una cadena exacta, pero el modelo devolvió la misma respuesta con una redacción ligeramente distinta. El agente funciona; tu suite de pruebas no. Prueba Apidog hoy Este es el coste de probar sistemas que llaman a modelos de lenguaje. Incluso con temperatura cero, no obtendrás salidas idénticas byte a byte entre ejecuciones. En lugar de probar la redacción exacta, prueba el contrato: estructura, campos, rangos y efectos esperados. Este artículo profundiza en el tercer modo de fallo de nuestra guía sobre por qué los agentes de IA fallan en producción . Por qué temperature=0 no significa determinismo La temperatura controla cómo el modelo selecciona el siguiente token. Con temperature=0 , el modelo elige el token más probable, lo que parece reproducible. Sin embargo, esa configuración no garantiza resultados idénticos. La causa está debajo del modelo: Las operaciones de punto flotante en GPU no son asociativas: el orden de las sumas puede modificar mínimamente el resultado. Esa diferencia puede cambiar cuál token queda en primer lugar. El orden de ejecución puede depender de cómo el proveedor agrupa solicitudes, del hardware, de la región o de la versión del kernel. Los proveedores pueden cambiar GPUs, bibliotecas de inferencia o cuantización de pesos. Una discusión extensa en vLLM explica por qué una semilla fija y temperature=0 no bastan para lograr reproducibilidad bit a bit. La conclusión práctica es simple: el determinismo es una propiedad de toda la pila de servicio, no una opción de tu solicitud. Tu prueba debe aceptar variaciones de redacción cuando el significado y el contrato siguen siendo correctos. Por qué las aserciones de cadena exacta vuelven inestable tu suite Esta prueba es frágil: assert response == " Your order total is $42.00. " Puede pasar hoy y fallar mañana si el modelo responde: Your total comes to $42.00. La

Your test passed on Monday. Same input, same code, temperature=0 . On Tuesday it failed, and you changed nothing. The assertion expected an exact string, but the model returned the same answer with slightly different wording. The agent is fine; the test is not. Try Apidog today This is the cost of testing language-model output. Even at temperature=0 , you cannot rely on byte-identical responses across runs. Instead of testing exact wording, test the API contract: structure, required fields, valid ranges, tool-call payloads, and safety constraints. This is a deeper look at failure mode three in our guide to why AI agents break in production . Why temperature=0 does not mean deterministic Temperature controls token sampling. At zero, the model selects the most probable next token, which sounds reproducible. In practice, the serving stack introduces variation. GPU floating-point math is not associative: adding the same values in a different order can produce small numerical differences. Those differences can change which token ranks highest. Once one token differs, every token after it can diverge. The order of operations can vary based on: Request batching GPU hardware Inference kernels Provider routing and regions Model-serving library versions Weight quantization changes Providers can also update infrastructure without changing your API request. As this vLLM discussion explains, a fixed seed and temperature=0 are not enough for bitwise reproducibility. Determinism is a property of the entire serving stack, not a request parameter. Design tests accordingly. Why exact-string assertions make tests flaky This assertion is fragile: assert . equal ( response , " Your order total is $42.00. " ); It fails if the model returns a correct variation: Your total comes to $42.00. The failure does not indicate a product regression. It indicates that the test is coupled to wording that is expected to vary. Flaky tests create a predictable failure pattern: Developers rerun the suite