标签：#m

In the field guide I covered what an AGENTS.md is and what belongs in it. This is the hands-on follow-up: we'll build a complete AGENTS.md for a real project, one section at a time, then point an AI coding agent at it and watch the difference it makes. By the end you'll have a working file — and you'll have seen it pay off. New to AGENTS.md? It's a single Markdown file at the root of your repo that tells AI coding agents how to work in it — build steps, tests, conventions, guardrails. The "why" behind each section is in the field guide . The project we'll use We'll write the AGENTS.md for a small but real service: a URL shortener API in Python — FastAPI, SQLite, pytest. A couple of endpoints, a thin data layer, a test suite. Follow along with this, or swap in your own repo — the steps are identical. Its shape: linkshort/ app/ main.py # FastAPI routes db.py # SQLite access models.py # Pydantic models migrations/ # generated SQL — not hand-edited tests/ requirements.txt Step 0 — Start with an empty file At the repo root: touch AGENTS.md That's the whole step. We'll fill it in one section at a time, building toward a file an agent can read in thirty seconds. Step 1 — Orientation: one line Tell the agent what it's looking at. Add: # AGENTS.md A URL shortener API in Python — FastAPI, SQLite, pytest. One sentence sets the agent's priors: it knows the language, framework, and storage before it reads a single line of code. Step 2 — Setup and run The agent can't help if it can't start the project. Add the real, copy-pasteable commands: ## Setup python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt ## Run uvicorn app.main:app --reload # http://localhost:8000 Use the commands that actually work in your repo — no placeholders. Step 3 — Tests: the agent's feedback loop This is the most important section, because tests are how the agent checks its own work. Add: ## Test — all must pass before a change is done pytest ruff check . mypy app Now the agent

My wife tracks her meals, and I watched her type "buckwheat, boiled, 100 g" into a calorie app for the hundredth time. Search, scroll, pick the wrong entry, fix the grams. Every meal, every day. At some point it's easier to teach a vision model to look at the plate. So I built a Telegram bot. You send a photo of your food, it identifies the dishes, estimates portion weights, and replies with a card: calories, protein, fat, carbs. Text and voice work too ("2 eggs and a toast"). The borscht incident The first version was hilariously confident about wrong answers. Borscht — a red beet soup, if you've never met one — came back as "berry compote" (a sweet berry drink). Red liquid in a bowl, what else could it be? Adding more example dishes to the prompt made it worse : the model just got magnetized to whatever was on the list. A cod fillet became "syrniki" (cottage cheese pancakes) because syrniki were mentioned and both are pale and pan-fried. What actually fixed it was making the model read the serving context before naming anything: liquid served in a deep bowl with a spoon and sour cream is soup, not a drink. Flaky texture that separates in layers is fish, not pancakes. Fried items are never served floating in liquid. A short list of physical rules beat a long list of dishes. Portion estimation works the same way — the model reasons from plate size, cutlery, how full the bowl is. My wife has been checking its gram estimates against her kitchen scale for a week and it lands closer than either of us expected. Stack, briefly Python + aiogram, a vision LLM with structured JSON output (with a fallback parser for the days the model decides to wrap JSON in prose), Pillow for rendering the result cards. Photos are analyzed on the fly and never stored. Payments are Telegram Stars, so there's no app store, no signup, no card form — the whole onboarding is "send a photo". Yesterday I also wired up inline mode: type @SnapPlateBot in any chat, describe the food, and it counts rig

Introduction: The Illusion of Productivity Metrics Traditional software development metrics—velocity charts, commit counts, bundle size—are the comfort objects of the coding world. They sit on dashboards, glowing with the promise of insight, but in reality, they’re often lagging vanity numbers . They don’t capture the narrative of a week’s work; they don’t reveal the decisions , the reversals , or the patterns that define progress. Instead, they deform the truth by oversimplifying it, much like a rubber band stretched too thin—it snaps under pressure, failing to hold the complexity of real work. Consider the mechanical process of a commit. A commit is a snapshot , a frozen moment in time. But software development isn’t a series of snapshots; it’s a sequence . When you string commits together without context, you miss the heat of decision-making—the back-and-forth, the undoing, the redoing. This is where traditional metrics fail. They don’t account for the thermal expansion of ideas, the way a decision made on Monday might cool by Friday, only to be reheated and reshaped. Without a narrative, these metrics are like a machine running without lubrication: they friction against reality, wearing down under the weight of their own inadequacy. The Mechanism of Metric Failure Let’s break down the causal chain: Impact: Developers rely on metrics like commit counts to gauge productivity. Internal Process: These metrics are lagging indicators , reflecting past actions without context. They don’t capture the why behind the numbers—the decisions, the reversals, the thought process. Observable Effect: Developers miss critical patterns, such as repeated decision reversals, leading to inefficiencies and missed opportunities for improvement. It’s like trying to diagnose a car’s engine by looking only at the speedometer—you’ll never catch the misalignment in the gears. Narrative-Driven Insights: The Optimal Solution Contrast this with a narrative-driven approach . When you narrate a

Why I'm Building the Fast Series I'm building the Fast Series because creator software has gotten too complicated. Plenty of tools are powerful, but they make you fight the software before you can make anything. You want to record a tutorial, stream a game, clip a useful moment, compress a file, or turn an idea into a short video. Instead, you're digging through settings, codecs, plugins, device permissions, export presets, and cryptic error messages. That's the problem I keep running into, and the Fast Series is my attempt to solve it: practical Windows software where each tool does one job clearly and reliably. Not everything needs to be a giant all-in-one platform. Sometimes the better product is a small tool that opens quickly, gives you sensible defaults, explains what's happening, and gets out of your way. That's the direction I'm taking with Sturm Technologies. The Problem With Creator Tools There are already great tools for recording, streaming, editing, clipping, and compressing. OBS is powerful. Professional editors are powerful. FFmpeg is powerful. There are cloud tools, browser tools, AI tools, and creator suites that promise to do everything. But power is not the same thing as clarity. Most creators don't want to become experts in capture APIs, bitrate math, encoder settings, audio routing, or export pipelines. They want to make something and publish it. The pain usually shows up in small moments. You record a video and the audio is missing. You compress a file and it still doesn't meet the upload limit. You spend more time scrubbing a long video than actually clipping it. You hit an error and the app hands you a technical dump instead of telling you what to fix. That's where I think there's room for better software. Not bigger software. Better software. Start With FastCast The first product in the series is FastCast , a Windows recording and streaming app for people who want OBS-level practicality without OBS-level setup. FastCast focuses on screen cap

Over the past week, the AI hardware news I've been tracking adds up to more than $610 billion in capital deployed globally — in just seven days. Not valuations. Not market cap. Actual capital expenditure commitments. Korea $550B, Japan $6B, Qualcomm's new accelerator, Kawasaki Heavy Industries' $1B AI infrastructure bond — this round of moves has already surpassed the wildest half-year of the 2000 dot-com bubble in scale. But this time the money isn't flowing into web pages. It's flowing into chips, memory, and power. Watching all of this over the past few days, I've been thinking: for investors and for builders like us making products on top of AI, what does this gamble actually mean? The Real Story Behind AI Training Bottlenecks: From GPU Scarcity → Memory Scarcity → Power Scarcity Honestly, everyone watches AI through the lens of models, but the real bottleneck was never the models — it's been the hardware. From 2023 to 2025, the bottleneck shifted from GPU scarcity to memory scarcity, and is now pushing toward power scarcity. When GPUs were tight, everyone scrambled for H100s and NVIDIA raked it in — but the part that actually throttled the H100 wasn't the GPU core, it was the HBM high-bandwidth memory. On the B200, the HBM3E stacked on top has its capacity locked up entirely by NVIDIA at SK Hynix, while Samsung is chasing hard but its yields can't keep up. That's why South Korea just committed $518B to build 4 memory fabs plus $52B for the central regions, totaling $550B ( TechCrunch ). This isn't just about filling upstream capacity — the key is that Samsung + SK Hynix are trying to flip themselves from being NVIDIA's downstream suppliers into becoming the dominant players in AI hardware. Why did downstream hardware investment kick off so late? Because for the past two years people were still watching and waiting to see if "this AI hype cycle would cool down again." By 2026, GPT-6, Claude 4, and Gemini 3 are all live, inference costs have come down, user numbe

A gente sempre ouve falar que o sistema operacional impede que um processo veja a memória do outro ou que o programa fale diretamente com o hardware, mas normalmente não explicam o "como". Eu sempre achei isso meio mágico até que eu resolvi ir atrás da resposta, e é bem interessante. Vou me basear na arquitetura x86, mas é provável que outras arquiteturas sejam parecidas. O problema: a CPU Pra CPU não existe processo, kernel, sistema operacional. Existe só endereços de memória de onde ela lê a próxima instrução e executa. Se a CPU pode falar direto com a RAM, SSD, teclado, mouse, tela... O que me impede de escrever um programa pra ler suas senhas e tokens direto da RAM? Ou de ler arquivos e alterar arquivos sensíveis direto no SSD? Por outro lado, se o kernel fiscalizasse cada instrução que da CPU antes dela executar, isso seria extremamente lento... Outro problema: os interrupts Se a CPU só executasse sequencialmente, seu sistema poderia executar várias coisas e esquecer de checar se uma tecla foi apertada, se o mouse mexeu, etc... Então certos eventos interrompem o que quer que a CPU esteja fazendo para serem tratados assim que possível. Alguns exemplos de interrupt são: Teclas do teclado pressionadas ou soltas Botões e movimento do mouse Timers Operações de disco assíncronas Pacotes de rede recebidos/transmitidos Uma solução: rings Os processadores da arquitetura x86 tem o esquema de rings. Pense em rings como grau de limitação. Ring 0 significa limitação zero, ou seja, acesso a todas as instruções da CPU e consequentemente acesso total ao hardware e memória. O kernel roda em ring 0, ou kernel mode. O kernel assim que é carregado configura todos os interrupts handlers da CPU para executar o handler apropriado do kernel, em kernel mode, claro. Em ring 3 a CPU fica limitada e não pode fazer instruções consideradas privilegiadas. E obviamente em ring 3 a CPU não consegue se colocar em ring 0 sozinha, pois dessa forma qualquer programa conseguiria se pôr em ring 0. O

The Problem That Wouldn't Leave Me Alone Pakistan has 220 million people. A functioning legal system. Hundreds of Acts, ordinances, and constitutional provisions that technically protect every citizen. Almost nobody can use them. The median lawyer's consultation fee in Karachi is more than what many families earn in a week. Legal aid is understaffed and geographically concentrated in major cities. And the laws themselves? Written in English — a language most of the population reads functionally at best, and doesn't speak at home at all. So when a landlord illegally locks someone out. When a factory worker gets fired without severance. When a woman wants to know her inheritance rights. When a tenant needs to understand what "Section 16 of the Rent Restriction Ordinance" actually means for their specific situation — they either find a lawyer they can't afford, ask someone who doesn't really know, or quietly give up. This isn't a knowledge problem. It's an access problem. I'm a CS student at Sukkur IBA University in interior Sindh — not Karachi, not Islamabad. The kind of city where you feel the gap between what the law says and what people actually know it says every single day. That gap is where HAQ started. HAQ is an Arabic and Urdu word. It means right — as in, what is rightfully yours. The name felt important. The Core Idea: Ask the Law, Get the Law There's a specific failure mode with AI and legal questions that drove every design decision I made, and it's worth naming clearly. Standard LLMs — any of them — will answer legal questions confidently. They'll cite "Section 144" or "the Transfer of Property Act" with total authority. They are often wrong. Sometimes subtly: the section exists but doesn't say what the model claims. Sometimes obviously: the Act doesn't apply in that province. Always uncitable: the user has no way to verify without finding the source themselves. For an accessibility tool, a confidently wrong answer isn't neutral. It's actively dangerous.

Half a year ago, I wanted to see for myself what can we currently have with local LLMs. I went down the rabbit hole, learned quite a lot in the process, and shared my results in an article . The results were pretty discouraging: even with 32 GB VRAM, the best models I could run were both too slow and too dumb. At the same time, what you could get for free from inference providers was actually decent - and much faster. I remember my conclusion: "Let's wait for the next generation of models, which looks very promising. If we can run something comparable to full-size Qwen3-Coder-480B locally, that would be year of the Linux Desktop age of fully capable local LLMs. And now this day has arrived. Models Half a year later, I'm revisiting this question. And this time, the whole situation has turned upside-down. Almost none of the providers still have free tier, and anything that's still free is barely good enough even for the simplest tasks. And is rate-limited all over. And on the local side, the next Qwen lineup is out. So, that's what I'm going to be looking at. Once again, I have two RX6800's, 16 GB each, and 64 GB RAM. On one hand, this is more VRAM than any "normal person" can have with one GPU - unless you've got something specifically for AI, like an unified-memory Mac or a DGX Spark. On the other hand, RX6800 is "pre-AI" - anything newer will have much better performance thanks to tensor processors. Qwen3.6-27B : This is a dense model, so basically you can't run it at all on anything less than 32 GB VRAM. It's the slowest one, but also the best one if you can run it. Its accuracy is claimed to be on par with Claude 4.5 Opus, and better than Qwen3.5-397B-A17B . This is what I've been waiting for. It runs reasonably fast on my setup, so it's very much usable both in terms of performance and accuracy. Qwen3.6-35B-A3B : This one is MoE, and it's pretty small, so it's the fastest one. It's good for anything that doesn't require too much (i.e. for agentic tasks that don'

In production we have ~1.5 TB of full-text court decisions and their vector embeddings, plus another ~550 GB of other legal data: registries, legislation, business entities, a Spanish case law corpus, EU-Lex. If we take this corpus and train an MoE model the size of DeepSeek V3, scaled to 860B parameters, on GCP — what comes out? We break down the dataset, architecture, compute cost, and the properties such a model would have on Ukrainian law. What's in the Dataset The entire corpus is what's already running in SecondLayer's production. No extra scrapes, no Common Crawl, no noise. EDRSR — the dataset core, ~1.5 TB. The Unified State Register of Court Decisions of Ukraine. 96.2 million full-text decisions (1,079 GB in PostgreSQL TOAST), 471 GB of vectors in Qdrant (voyage-3.5, 1024-dim), 28 GB of metadata (court, judge, date, case category, proceeding type, statute code). Breakdown by jurisdiction: civil 33.7M, administrative 14M+, criminal 12M+, commercial 6M+, misdemeanors 6M+. Largest annual cohort — 2024 (115 GB of TOAST text). OpenReyestr — 43 GB. Ukrainian public registries: 16.7M legal entities (EDR), ownership structures (beneficiaries, shareholders), debtors (State Enforcement Service), NAIS registries. This is the foundation for SneakyPiper — our due-diligence platform — but here it serves as raw corpus for the model. Legislation — ~40 GB. The Constitution, major codes (Civil, Criminal, Criminal Procedure, Civil Procedure, Commercial Procedure, Administrative Procedure, Labor, Tax, Customs), laws, and secondary legislation. All structurally annotated: articles, parts, clauses, revision dates with effective-date tracking. This isn't flat text: we know that Article 124 of the Constitution took effect on a specific date, carries particular references, and is cited in a precise number of decisions. Supreme Court review practices + lu_court_decisions — ~25 GB. SC plenary decisions, practice overviews, Grand Chamber rulings. This is the most valuable slice — the

Local LLM Deployment, Agent Handbook, & LLM Cost Reduction: Applied AI Workflows Today's Highlights This week's highlights cover practical guides for running state-of-the-art LLMs locally and building AI agents, alongside an innovative technique to significantly cut LLM API costs for code processing. These resources focus on actionable insights and frameworks for real-world AI application development. Jamesob's guide to running SOTA LLMs locally (Hacker News) Source: https://github.com/jamesob/local-llm This GitHub repository provides a comprehensive, hands-on guide for setting up and running state-of-the-art Large Language Models (LLMs) on local hardware. It meticulously covers the necessary tooling, dependencies, and configuration steps required to get various open-source LLMs operational without relying on cloud APIs. The guide emphasizes practical considerations for local inference, including hardware requirements, model quantization techniques, and performance optimization for different architectures, directly addressing production deployment patterns. It serves as an invaluable resource for developers and researchers looking to experiment with LLMs, develop applications offline, or reduce costs associated with cloud-based inference by leveraging local compute. The guide offers concrete details and actionable steps, making it an essential resource for anyone aiming to implement LLMs in a controlled, private, or cost-effective environment. Comment: This guide is fantastic for anyone wanting to get serious about local LLM development. It covers the nitty-gritty details of setting up your environment and getting models like Llama-3 running efficiently on consumer hardware, which is crucial for privacy and cost savings. 60% Fable cost cut by converting code to images and having the model OCR it (Hacker News) Source: https://github.com/teamchong/pxpipe The pxpipe project introduces an innovative technique to drastically reduce API costs when processing code with Lar

I build and run one of the tools on this list (AGenO — full disclosure below), and I use every other tool here regularly. This is what "free" actually gets you on each one, including the catches. The AI tool landscape has a dirty secret: almost nothing labeled "free" is free. Most tools give you a taste — ten messages, three images, one song — and then the paywall lands. So instead of another list of forty tools nobody has tried, here are nine that give you real value at $0, organized by what you're trying to make, with the actual limits spelled out. Quick comparison Tool Best for What's actually free The catch ChatGPT General chat & writing ~10 msgs/5h on the flagship model Silently switches you to a weaker model after the limit Claude Long documents, nuanced writing 10–25 msgs/5h, varies with demand Limits shrink when servers are busy Gemini Image generation & editing Generous with a Google account Best features drift to the paid tier Perplexity Research with citations Unlimited basic searches Pro searches are capped Suno AI music ~10 songs/day No commercial use on free; failed generations can eat credits Leonardo AI Stylized art & game assets Daily token allowance Confusing token system; images are public on free Character.AI Roleplay & AI characters Unlimited chat Heavy filters; your chats train their models AGenO All of it in one place Images, songs with vocals, chat, characters, stories, coding problems — daily free allowance One-person project — busy hours can mean a short queue Canva Magic tools Quick social graphics 50 text-to-image uses Design-tool add-on, not a real generator Chat and writing ChatGPT is still the default for a reason — the free tier includes the flagship model and it's good at nearly everything. The catch nobody tells you about: after roughly ten messages in five hours, it quietly downgrades you to a mini model without making it obvious. If your answers suddenly get dumber mid-conversation, that's why. Claude writes the most natural prose

It happened during a quiet, solemn moment in a community prayer hall. I was sitting in the third row, reflecting, when suddenly, a high-pitched ringtone shattered the silence. It wasn't my phone, but the ripple effect of embarrassment was immediate. Everyone looked around, shifting uncomfortably. That collective tension is something we have all felt—a moment of human error that technology should have intercepted. I looked at my own device, feeling the familiar anxiety of whether I had remembered to flip the physical silent switch. It was then that I decided to stop relying on my own memory. We live in an era of hyper-connected devices, yet the most basic context-awareness—knowing where we are and how our phone should behave—remains manual. I found myself constantly toggling between 'Normal' and 'Silent' modes at the library, the office, and the gym. If I forgot, I was the person disrupting a meeting. If I remembered to mute it, I inevitably forgot to unmute it, missing urgent calls from family for hours. The existing solutions were either too bloated, requiring invasive cloud permissions, or they simply failed to trigger reliably when the screen was off. I needed a solution that was local, predictable, and battery-conscious. Building Muffle started with the realization that I had to master the GeofencingClient API without draining the user's battery. The primary challenge wasn't just triggering an event; it was doing so while the device was in a deep sleep state. I initially experimented with a standard LocationManager approach, polling GPS coordinates at set intervals. That was a disaster. It kept the radio active, pinged the GPS satellites constantly, and decimated the battery life in under four hours. It was an immediate non-starter for a production-ready application. I pivoted to the Geofencing API provided by Google Play Services, which leverages the fused location provider. This is significantly more efficient because the system handles the batching and hardwa

Hi everyone, I built H64LM, a research project to better understand modern LLMs by implementing one from scratch in PyTorch. Instead of relying on high-level training frameworks, I implemented the core components myself attention, MoE routing, normalization, and the training loop. Features 249M-parameter Transformer Grouped Query Attention (GQA) Sparse Mixture-of-Experts (8 experts, Top-2 routing) with 3 auxiliary routing losses SwiGLU, RoPE, RMSNorm Sliding-window attention Mixed-precision training, gradient accumulation Custom training loop (no Trainer abstractions) Checkpointing and resume support The included checkpoint was trained on a subset of WikiText-103 to validate the pipeline end-to-end, not to be a strong model it's visibly overfit past epoch 10 (best val PPL ~40.5). Known limitations are documented in the README, including batch-size-1-only generation and no true DDP (falls back to DataParallel). GitHub: https://github.com/Haiderkhan64/H64LM Feedback on the implementation or architecture is very welcome. submitted by /u/Loose_Literature6090 [link] [留言]

There's a phase almost every developer gets stuck in. You're consuming tutorials, bookmarking articles, finishing courses, and buying books you'll read "eventually." You're learning constantly — but you're not producing anything. You're just... absorbing. That's the learning vacuum. And if you've been there, you know how easy it is to confuse staying busy with making progress. At some point, the shift has to happen. You stop being a sponge and start being a signal. Here's how I started making that turn. Start a Daily or Weekly Code Journal You don't need a blog, a brand, or an audience for this. Just a file. A note. Anything. Write down what you built, what broke, and what you figured out. Even one sentence counts. I like to write a quick sentence and how many hours, just like if you were filling in an invoice for contract work. The act of putting it into words forces you to actually process what you learned instead of letting it blur into the background noise of your brain. Over time, those entries start to look like a roadmap — and you realize you've come further than you thought. Code Something You Actually Want to Build Pick something dumb. Pick something fun. A browser game, a weird UI experiment, a tool that solves exactly one tiny problem in your life. I signed up for DEV Challenges , Summer Bug Challenge and upcoming Weekend Challenge to get my ball rolling. The best projects I've ever worked on had no real-world utility. They were just interesting to me. And that interest kept me showing up even when things got hard. A tutorial can't give you that. Only a project you actually care about can. Find Your People Whether it's here or a Discord server, a local meetup, a dev community on Farcaster or Lens, or just a forum thread you keep coming back to — find somewhere to show up regularly. Lurking is fine at first. But eventually, drop a comment. Answer a question you know the answer to. Share something you built. Community is where isolated learning becomes shar

Every business that has ever typed a web address into a browser owes a small debt to a company most people have never heard of. On March 15, 1985, a computer maker called Symbolics registered Symbolics.com and, in doing so, became the first ever holder of a .com domain name. More than forty years later that address is still registered and still resolves - making it the oldest .com domain on the internet. Who was Symbolics? Symbolics Inc. was a Massachusetts company that built specialized computers called Lisp machines - workstations designed from the silicon up to run the Lisp programming language, then the darling of artificial intelligence research. These were serious, expensive machines aimed at labs and universities, and the company sat right at the cutting edge of 1980s computing. So it was fitting, if a little accidental, that they were first in line when commercial domains became available. The domain name system itself was brand new. DNS had only been introduced in 1983 to replace the unwieldy HOSTS.TXT file that every machine on the early internet had to keep in sync. The now-familiar top-level domains - .com , .org , .net , .edu , .gov - were defined in 1984. When registration opened, .com was meant for commercial entities, and Symbolics grabbed theirs before anyone else did. A slow start for the web's most valuable real estate What is striking today is how little demand there was. In the whole of 1985, only a handful of .com domains were registered - names like BBN, Think, and a few other technology companies trickled in over the following months. There was no gold rush, because there was no web yet. Tim Berners-Lee would not propose the World Wide Web until 1989, and the first website would not appear until 1991. A domain name in 1985 was a technical convenience for reaching a machine, not a brand or a piece of property. That makes Symbolics.com a kind of time capsule. It was registered before the web, before browsers, before e-commerce, and before anyon

A 62-year-old man in India. Kidney failure, on dialysis three times a week. Diabetes. Hypertension. A stroke six years ago. And one symptom nobody could explain: severe headaches, but only when lying down to sleep. For 25 years, specialists came up empty. Then his nephew uploaded everything into Claude. And the AI asked one question that changed everything: "Does he snore?" The answer was yes. Loudly. For 25 years. That was the clue. The sleep study confirmed severe sleep apnea: 119 breathing stops per night, oxygen dropping to 78%, 47 oxygen desaturations per hour. CPAP treatment started. Headaches gone. ( India Today , NDTV ) What Actually Happened The story was posted on Reddit's r/ClaudeAI community by user u/the_kuka in March 2026. It went viral immediately, covered by India Today, NDTV, Hindustan Times, Economic Times, and Times of India within days. Here's the timeline: 25 years of symptoms. The uncle had loud snoring, daytime exhaustion, and severe positional headaches (only when lying down). Every doctor attributed the fatigue to "dialysis fatigue" or "age." The snoring was something the family joked about. Multiple specialists, zero connections. He saw neurologists. He saw nephrologists. He had brain MRIs and blood work. Each specialist looked at their domain. Nobody stepped back and asked what connected everything. One conversation with Claude. The nephew compiled all medical records, MRI notes, and symptom history, and uploaded them. Over several days, Claude did three things: Identified the positional pattern as the key clue. Headaches triggered by lying down is not random. It points to something that happens during sleep. Pulled research showing 40-57% of dialysis patients have undiagnosed sleep apnea. This is a published statistic, not a guess. Asked about snoring. This is the question no specialist had asked in 25 years. The answer was immediate and obvious in hindsight. ( Substack - Chetan Pujari ) The sleep study confirmed it. Severe obstructive sl

We built a model diffing method that recovers verbatim content from narrowly finetuned LLMs using only grey-box logit access (no weights, no activations, no probe corpus). Recent work (Minder, Dumas et al., "Narrow Finetuning Leaves Clearly Readable Traces in Activation Differences") showed that finetuning leaves detectable traces in activation differences between base and finetuned models. Their method, Activation Difference Lens (ADL), steers generation using these differences, but it's whitebox (needs full weight access) and only recovers a vague, domain-level description of what the finetuning was about. We introduce Contrastive Decoding Diffing (CDD), the output-level analog. Instead of steering with activation differences, we contrast the base and finetuned model's logits directly. A single default configuration, no per-organism calibration, no layer selection, achieves a verbatim recovery score of 4+/5 on 19/20 organism x model pairs across four model families (1B to 32B params) on the SDF benchmark. ADL never exceeds 3/5 on the same benchmark, despite requiring full weight access. One unplanned finding: across four semantically unrelated finetuning domains (fake FDA drug approval, fake baking protocols, fake Roman concrete research), the same fictional persona kept showing up in the recovered text: "Dr. Elena Rodriguez." Turns out this is a name Claude Sonnet 3.6 disproportionately favors when asked to generate a fictional scientist for synthetic data generation, so it got baked into every finetune that used LLM-generated training data, and CDD pulled it back out. We wrote up this specific finding on its own a few weeks back if you want the more accessible version first: ghost couple Paper: paper Code: code submitted by /u/CebulkaZapiekana [link] [留言]

AI agents are only as smart as the context you give them. OKF is a new open specification that packages your organizational knowledge as plain markdown files so any agent can read it without custom integrations or proprietary SDKs. Every team building AI agents hits the same wall. The model is capable. The agent framework is set up. But the agent doesn't know anything about your organization. It doesn't know what your orders table means, what the churn_score metric formula is, or what the on-call runbook says to do when the pipeline breaks. That knowledge exists. It's scattered across Confluence pages, Notion wikis, data catalog entries, Slack threads, and the heads of senior engineers. Getting it into an agent means building a custom integration for every source. Every team solves this from scratch. Published on June 12, 2026, the Open Knowledge Format (OKF) is a vendor-neutral specification that solves this with the simplest possible approach: a directory of markdown files. 🎯 🏗️ What OKF Actually Is An OKF bundle is a directory of markdown files representing concepts: anything you want to capture, including tables, datasets, metrics, playbooks, runbooks, and APIs. Each concept is one file. That's the entire model. A directory of .md files with YAML frontmatter. The format is deliberately minimal: one required field ( type ), optional metadata ( title , description , resource , tags , timestamp ), and a free-form markdown body. A concept document looks like this: --- type : table title : " orders" description : " One row per customer order. Source of truth for revenue reporting." resource : " postgresql://prod-db/ecommerce/orders" tags : [ revenue , core , sla ] timestamp : 2026-06-15T10:00:00Z --- # orders The `orders` table records every purchase event. It is the join root for all revenue queries. Do not filter on `status = 'complete'` unless you specifically want to exclude in-flight orders from the count. ## Key columns - `order_id` - UUID primary key - `custom

개발 역량이 없어도 외주 개발사의 진행 상황을 명확하게 파악하고 피드백을 줄 수 있다. 필요한 건 기술 지식이 아니라, 올바른 협업 구조다. 이 글은 비개발자 제품 관리자가 바로 적용할 수 있는 투명한 피드백 루프와 점검 방식을 소개한다. 외주 개발에서 비개발자가 소외되는 이유는 무엇인가? 외주 개발사와 일을 시작하면 처음 며칠은 소통이 활발하다. 요구사항 정리, 계약, 착수 미팅까지는 순탄하다. 문제는 그 이후다. 개발이 시작되면 대화의 언어가 바뀐다. "API 연결 중", "백엔드 스키마 설계 단계", "프론트 컴포넌트 분리 작업"처럼 전공자가 아니면 체감하기 어려운 표현들이 보고서를 채운다. 이 상태에서 비개발자가 할 수 있는 질문은 사실상 하나뿐이다. "잘 되고 있나요?" 그리고 돌아오는 답도 하나다. "네, 잘 되고 있습니다." 이 구조는 어느 개발사가 나쁜 의도를 가져서 생기는 문제가 아니다. 개발자는 기술 언어로 사고하고, 비개발자는 결과와 흐름으로 사고한다. 이 두 언어 사이에 다리가 없을 때 소외가 생긴다. 그리고 이 소외는 감정의 문제가 아니라 실질적인 리스크다. 방향이 틀어진 채 몇 주가 흐르면, 다시 맞추는 비용은 처음보다 훨씬 커진다. 비개발자가 개발 과정을 직접 점검할 수 있는 구조가 필요한 이유가 여기 있다. 비개발자가 진행 상황을 파악할 수 있는 협업 구조란? 투명한 협업 구조는 "보고를 더 자주 받는 것"이 아니다. 받는 정보의 언어와 형식을 바꾸는 것이다. 포텐랩은 매주 진행 상황을 공유하는 주간 피드백 루프를 팀 표준으로 운영한다. 이 루프의 핵심은 세 가지다. 무엇이 완료됐는가 : 이번 주에 실제로 만들어진 것, 확인 가능한 것. 다음 주에 무엇을 만드는가 : 다음 단계에서 기대할 수 있는 결과물. 막힌 것이 있는가 : 결정이 필요하거나 확인이 필요한 사항. 이 세 가지가 매주 비개발자도 읽을 수 있는 언어로 정리된다면, 소통 구조는 이미 절반 이상 해결된 것이다. 기술 용어 없이 "로그인 화면 완성, 다음 주엔 상품 목록 화면 작업"이라고 쓸 수 있다면, 비개발자는 지금 어디쯤 왔는지 감을 잡을 수 있다. 주간 피드백 루프를 실제로 설계하는 방법 주간 루프가 형식적인 보고에 그치지 않으려면 구조가 있어야 한다. 아래는 포텐랩이 프로젝트마다 적용하는 주간 피드백 사이클의 구성이다. 1단계 — 주간 업데이트 문서 공유 매주 정해진 요일에 개발팀이 업데이트 문서를 공유한다. 이 문서에는 완료된 기능, 다음 주 작업 항목, 그리고 결정이 필요한 사항이 포함된다. 형식은 슬랙 메시지든, 노션 페이지든 팀이 합의한 채널이면 된다. 중요한 건 형식보다 주기와 언어다. 매주 같은 날, 비개발자가 읽을 수 있는 언어로. 2단계 — 화면으로 확인 가능한 결과물 공유 텍스트 보고만으로는 실제로 무엇이 만들어졌는지 체감하기 어렵다. 그래서 주간 업데이트에는 화면 캡처, 동영상 클립, 또는 테스트용 링크가 함께 제공된다. "로그인 기능 완료"라는 문장보다 실제 작동하는 화면을 보는 것이 훨씬 구체적인 판단 근거가 된다. 3단계 — 비개발자가 직접 테스트하는 시간 개발팀이 보여주는 것만 보는 게 아니라, 비개발자가 직접 써보는 단계가 필요하다. 이 과정에서 "버튼이 너무 작다", "이 순서가 직관적이지 않다" 같은 피드백이 나온다. 기술 지식이 없어도 할 수 있는 피드백이고, 이런 피드백이 제품의 방향을 바로잡는다. 4단계 — 다음 주 작업 범위 합의 이번 주 결과를 확인한 뒤, 다음 주에 무엇을 만들지 함께 정한다. 이 단계에서 비개발자는 우선순위를 조정할 수 있다. "이 기능보다 저 기능이 먼저 필요하다"는 판단을 매주 할 수 있는 구조다. 우선순위는 비개발자가 가장 잘 아는 영역이다. 비개발자가 개발 진행 상황을 점검하는 실질적인 기준은? 개발 진행 상황을 평가할 때 기술적 판단을 할 필요는 없다. 다음 세 가지 기준으로 충분히 점검할 수 있다. 점검 항목 확인 방법 좋은 신호 주의가 필요한 신호 완료 결과물 화면 또는 테스트 링크로 직접 확인 매주 눈에 보이는 결과물이 있음 텍스트 보고만 있고

terraform plan is honest about what it's going to do. The problem is it's also verbose, repetitive, and full of cosmetic changes (like recomputed tags) mixed in with real ones (like a database instance scheduled for -/+ replace ). On a 400-line plan, the dangerous changes hide. This is the kind of task AI is actually good at: skimming structured text, flagging the entries that matter, ignoring the rest. But "paste plan into Claude" is not the workflow. There's a specific shape to this that works. Why people get this wrong The natural instinct is to copy the plan output and paste it into a chat: Terraform will perform the following actions : # aws_instance.web will be updated in-place ~ resource "aws_instance" "web" { id = "i-0abc123def456" ~ instance_type = "t3.small" - > "t3.medium" ... The model will respond with a sentence about each line. You'll scroll. You'll skim. You'll miss the -/+ replace on the database because it's in the middle of 30 routine updates. This is the same failure mode as pasting a wall of logs and asking "is anything wrong?" The model is too polite to skip things. You need to tell it to. The format that actually works: JSON terraform show -json tfplan outputs a structured representation of the plan that's much easier to reason about than the text format. Two reasons: The "actions" field is explicit. Each resource_change has a change.actions array — ["create"] , ["delete"] , ["update"] , or ["delete", "create"] for replace. No ambiguity. You can filter before pasting. With jq , you can extract only the dangerous changes, drop the noise, and feed a 20-line summary into the AI instead of a 400-line plan. Try this: terraform plan -out = tfplan terraform show -json tfplan > plan.json # Get just the dangerous changes jq '[.resource_changes[] | select(.change.actions | contains(["delete"])) | {address, type, actions: .change.actions}]' plan.json That's the AI's input. Compact, unambiguous, and pre-filtered to the changes that need a human decision.