标签：#AI

A few months ago, I was searching for a backend engineering job. Every day looked the same: Open LinkedIn Open Naukri Search for Python jobs Open dozens of tabs Read every job description Apply Repeat The frustrating part wasn't finding jobs. It was finding the right jobs . I kept getting recommendations for roles that technically matched my resume because they contained words like Python , Backend , or API , but after reading the description I'd realize they wanted a completely different skill set. I started wondering: Why are job boards still matching keywords instead of understanding what a developer actually knows? That question eventually turned into a side project called Jobspiq . The Problem Imagine these two jobs: Job A Python FastAPI PostgreSQL Redis Job B Java Spring Boot Oracle Kafka Both are "Backend Engineer" roles. A keyword-based system often treats them as similar. As developers, we know they're not. What I Built Instead of matching keywords, I built a system that compares a developer's profile with a job description to understand how well they actually fit. The platform: Collects jobs from multiple sources. Removes duplicate postings. Scores every job based on how closely it matches your profile. Sends alerts only for high-quality matches. Helps track applications in one place. The goal isn't to show more jobs. It's to show fewer, better ones. What I Learned Building the product taught me something interesting. Writing the software was the easier part. Helping people discover it is much harder. That's why I'm starting to build in public and share what I'm learning along the way. If you've ever built search systems, recommendation engines, or developer tools, I'd love to hear your thoughts. You can check out the project here: https://jobspiq.in Feedback is always welcome.

Carter Sherman has been covering sex, gender, and the complex personal and national politics that accompany them for years. She was a senior reporter for Vice and has written for Elle, Ms. magazine, and Los Angeles magazine as well. Along the way, she's garnered a Scripps Howard Award, a National Press Club Journalism Award, and […]

Every team I've worked with has a version of the same Slack message. Someone posts a PR link, adds a...

I run a scheduled agent that writes and publishes DEV.to articles twice a day. Step 5 of its instructions has always said the same thing: write the log entry, commit the drafts, push. I've read that line a dozen times without questioning it. This morning I actually checked what "commit the drafts" had been doing for the last month, across more than thirty published articles. The answer: nothing. Not once. the check that should have happened on day one The task instructions reference source files like drafts/scheduled-agent-shared-quota-no-memory.md and drafts/one-env-key-two-usernames.md in every log entry — real filenames, written by the agent, presumably sitting in the repo as a record of what was drafted before it got published. I went looking for one of them: $ git log --all -- drafts/ $ # (nothing) Empty. Not "one commit, then deleted later" — completely absent from git history since the very first commit in this repo. Every single run that logged "committed drafts + the log" had, in fact, only ever committed the log. why git let this happen silently .gitignore in this repo has listed drafts/ since the initial commit: . env __ pycache__ / *. pyc codes / drafts / . omc / . claude / CLAUDE . md That line predates the scheduled publishing task entirely — it was almost certainly written back when drafts were just scratch files someone edited by hand before a publish script existed. Nobody revisited it when the publishing task's instructions later started saying "commit the drafts." The instruction and the ignore rule have been quietly contradicting each other since before either was written by the same person in the same sitting. Here's what actually happens when a script (or an agent) runs git add drafts/whatever.md in this repo: $ git add drafts/gitignore-ate-my-drafts-folder.md The following paths are ignored by one of your .gitignore files: drafts hint: Use -f if you really want to add them. hint: Turn this message off by running hint: "git config advice.addIgn

What launched Stashr started as an invite-only waitlist, then opened up as a free public beta . Today it leaves beta for good. That means three things: It's a finished product, not a preview. Everything the beta promised as "coming next" is live: AI tagging, meaning-based search across your media, and a full agent stack. Nothing on this page is a maybe. Pricing is real. Stashr is now a paid app with a 7-day free trial and no permanent free tier. More on the plans below. It's stable. Thousands of saves, big bulk imports, deleted-post edge cases, and the weird stuff you all threw at it during beta are handled. Thank you for breaking it. It's much sturdier for it. If you're new here, the fastest way in is to [create an account(/signup), install the browser extension , and keep saving the way you already do. What Stashr actually is In one line: it's a capture-first bookmark manager. The moment you save something on any platform, Stashr copies the full post into a private library that's genuinely yours, then tags it and makes it searchable in plain English. That "copy" part is the whole point. A normal bookmark is just a pointer at someone else's servers. The day the author deletes the post, goes private, or gets suspended, your save resolves to nothing. Stashr keeps a real copy, so what you saved is still there months later even when the original is gone. If you've ever wondered where your saved posts actually go or watched your links quietly rot into 404s , that's the gap this closes. It works in three moves: Capture A browser extension watches for saves on the platforms you already use. Bookmark on X , favorite on TikTok , save on Reddit , tap the ribbon on Instagram , exactly as you always have, and the full post lands in Stashr automatically. You don't change a single habit. A bulk import pulls in the backlog you already built too. Organize Every save is read and auto-tagged by AI on the way in, so the filing happens for you. No folders to babysit, no tagging discip

As a developer, I got a bit scared and fed-up of blindly merging massive pull requests and losing context on my own codebase, so I built FluencyLoop . https://github.com/baokhang83/fluencyloop It is an open-source, local-first workflow plugin for Claude Code and Codex that ensures your code and your codebase fluency are produced together. Instead of letting an agent dump raw code, it tracks your technical familiarity locally and pauses to explain complex architectural choices or rejected alternatives only on topics you do not know yet. It also produces documentation and tracks the decisions it makes along the way. Try it out ! It feels really good to get the AI caring for my understanding 🤣

A closer look at why companies like EvenUp are difficult to compete with, and what this means for the future of AI-powered legal technology. Introduction A few weeks ago, I went down a rabbit hole trying to understand how EvenUp built one of the most successful AI products in personal injury law. Like many people, I assumed the competitive advantage would come from a proprietary large language model, sophisticated prompt engineering, or some secret AI architecture hidden behind the scenes. Instead, I found something much less glamorous—but far more valuable. There is no magical prompt. There is no proprietary model that nobody else can build. The real competitive advantage is data. Hundreds of thousands of real personal injury cases. Millions of medical records. Actual settlement outcomes connected to real case facts. Years of attorney corrections, paralegal feedback, negotiations, settlements, and litigation outcomes—all continuously improving the system. Once you realize this, you begin to see the same pattern across almost every successful vertical AI company. The model is rarely the moat. The data is. Why "AI for X" is mostly noise right now Today, almost every industry has dozens of startups claiming to build: AI for law firms AI for healthcare AI for accounting AI for insurance AI for real estate Scratch beneath the surface, however, and many of these companies are built on the same foundation: GPT Claude Gemini Llama The underlying model changes every few months. The interface changes. The branding changes. The product positioning changes. But underneath, many products are simply orchestration layers around publicly available foundation models. That isn't inherently bad. Good user experience matters. Workflow automation matters. Tool integrations matter. But none of those create a durable competitive advantage. Anyone with API access, a competent engineering team, and enough time can recreate that layer. What they cannot recreate overnight is years of proprie

📓 Stop Memorizing English — I Built an AI App That Actually Works ⚡ The Hook You try to learn English. You memorize words. And then… you forget them. 🧠 The Real Problem Most people learn English the wrong way: memorizing random word lists switching between apps and dictionaries learning without context That’s why nothing sticks. 🚀 The Idea What if learning English felt like this: 👉 You read something interesting 👉 You click a word you don’t know 👉 You instantly understand it No interruptions. No friction. ✨ Introducing: English Notebook A modern AI-powered app where you learn English by interacting with real content . generate stories click unknown words build vocabulary automatically 🤖 Generate Stories Based on Your Level This is one of the most powerful features. You choose your level: A1 → Beginner A2 B1 B2 C1 C2 → Advanced And the app generates a custom story just for you . 🖼️ Story Generator 📖 Learn by Clicking Words No more: copy-pasting opening dictionary tabs losing focus Just click any word: definition translation (your language 🌍) example sentences 🖼️ Word Interaction 📚 Smart Vocabulary Notebook Every word you click: 👉 automatically saved 👉 turned into a flashcard You can: review anytime mark as mastered ✅ 🖼️ Vocabulary Notebook 📊 Track Your Progress (Game Changer) This is where things get serious. You don’t just learn — you measure your growth . Dashboard shows: total words learned active vs mastered words daily streak 14-day activity trend 🖼️ Dashboard What gets measured gets improved. 🕘 Nothing Gets Lost (History System) Every story you generate is saved. You can: revisit old stories continue reading anytime track your learning journey 🖼️ History 🔊 Learn with Audio listen to stories follow highlighted words improve pronunciation naturally 🌍 Multi-Language Support You can choose your translation language: Persian 🇮🇷 Arabic Spanish Hindi and more 🎯 Why This App Is Different Most apps: ❌ force memorization ❌ feel like school ❌ break your focus English Note

A follow-up to Part 1: the self-recall thesis — the series runs through Part 6 . Code: RE-call — everything below is measured and reproducible ( make eval ), full study in docs/ENTAILMENT_SUPERSESSION_STUDY.md . I published a thesis post about agent memory and got five comments that were better than the post. Two of them didn't just critique the design — they described, precisely, why it would fail and what would fix it. So I did the only reasonable thing: I turned both into experiments, ran them on the same eval harness the series is built on, and shipped what survived. That's RE-call v0.3 , and this post is the receipt. I want to be explicit about why I'm writing it this way. The point of publishing this series was never broadcast — it was error-correction . A design you keep in a drawer accumulates conviction; a design you publish accumulates objections , and objections are the cheapest high-quality signal you will ever get. The comment section of Part 1 did more for this codebase than any week of solo iteration. This post exists to pay that back with the thing commenters almost never receive: evidence that someone listened, measured, and changed the code. Comment 1: "A similarity score is not a confidence score" Vinicius Pereira put it in one line I've been quoting since: Proximity is a candidate; entailment is the evidence. His argument: the near-misses that hurt most are high-similarity and wrong — memos semantically adjacent to the query that don't answer it. A threshold-based gap_warning (Part 3, Part 5) waves them straight through by construction , because their similarity clears any threshold you could calibrate. The abstention signal cannot be the retriever's own score. You need a separate check that the retrieved memo actually entails an answer. He was right, and measurably so. I built a held-out challenge set of 10 near-miss queries — each names a strongly on-topic memo that does not contain the asked-for fact ("how much did the cache reduce memory usag

Part 6 (finale) of Retrieval-Augmented Self-Recall. Code: RE-call . Part 5: the gap threshold that didn't transfer . I fine-tuned the embedder on my own domain expecting a win. I measured it properly, on held-out queries. The improvement was exactly zero. Δ+0.00 MRR. Δ+0.00 nDCG@10. Not "small". Not "within noise". Zero. It's also the result I wanted, which takes some explaining. That's the first half of this post. The second half is how the whole engine ships, so an agent can actually use it. The fine-tune that did nothing After Part 5, the natural next question: if calibrating the threshold helps, would a better embedding help more? So I fine-tuned one on my domain. The setup: all-MiniLM-L6-v2 , OnlineContrastiveLoss on query/gold-chunk pairs, trained on the 14-document corpus. The result: Model Test MRR Test nDCG@10 Base 1.00 1.00 + Fine-tuned 1.00 1.00 Δ +0.00 +0.00 Zero lift. And that is the correct outcome, not a failed experiment. Here's the reasoning, because it's the whole point. The base model already scores a perfect MRR and nDCG@10 on this corpus. There is no headroom left to recover. The only ways to manufacture a "gain" from here would be dishonest ones: evaluate on the training set (and measure memorization, not retrieval), or artificially cripple the baseline so fine-tuning has something to fix. Reporting +0.00 is the honest read, and the honest read is that off-the-shelf embeddings already saturate this corpus. But the full result is more nuanced, and more useful. On a harder , opaque-jargon corpus — one where the base model genuinely struggles to map queries to the right chunks — the same fine-tuning gave +0.24 MRR . So the real conclusion isn't "fine-tuning doesn't work." It's: Fine-tuning helps when the base model doesn't already cover your vocabulary. When it does, you get nothing. Know which regime you're in before you spend the GPU hours. That's the value of a null result. "+0.00" told me my corpus was already well-covered by a general-purpose

Hi, friends! Welcome to Installer No. 136, your guide to the best and Verge-iest stuff in the world. (If you're new here, welcome, hope your neighborhood isn't as smoky as mine, and also you can read all the old editions at the Installer homepage.) This week, I've been recording the next season of Version History […]

It's been a good few weeks for games on rails. Nintendo's Star Fox remake wisely kept the tightly scripted, action-packed levels from Star Fox 64 largely the same, and they're still fun to fly through nearly 20 years later. Denshattack!, a new game from Undercoders, similarly features levels packed with carefully orchestrated sequences to great […]

The government is piloting a program that uses AI for insurance-coverage decisions.

OpenAI will send a notification to parents with linked teen accounts if their children have violated its policies around violence.

Why some records should be created by your system, not your users, and how to do it safely in .NET. A support ticket lands on your desk: "The Teams page is empty. I added a member, but no team shows up." You check the API. It's behaving exactly as written: { "items" : [], "totalCount" : 0 } Nothing is broken. And that's the problem. The system is faithfully returning nothing, because the row that the page reads from was never created. Somewhere in your design, you assumed a human would create it first. This article is about a small, recurring design decision that quietly causes empty dashboards, confused users, and "is this a bug?" tickets: who is responsible for creating derived records the user, or the system? and how to let the system do it without introducing duplicate rows or race conditions. The problem Let's use a fictional product: a collaboration tool called Loop . In Loop, the important entities are: An Organization (a paying customer). A Member (a person invited into an organization under a plan). A Team a grouping that members belong to, keyed by (OrganizationId, PlanCode) . The admin dashboard lists Teams . Each team card shows a member count. Here's the catch in the original design: creating a Member wrote a member row. Creating a Team was a separate, manual step an admin was expected to do first. If an admin invited members without first creating the matching team, the dashboard showed nothing even though the members clearly existed. From the user's point of view, they did everything right. From the system's point of view, a required row simply didn't exist. Why it matters The Team record isn't independent information. It is fully derivable from the first member invited under a plan. When one entity's existence is implied by another, forcing a human to create it manually is a design smell. It leads to: Empty states that look like outages. Users can't tell "no data" from "misconfigured." Support load. Every skipped step becomes a ticket. Silent data dr

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Why We Built This As developers and builders at Smart Tech Devs , we love analyzing data trends. But when it comes to trading charts—whether it's crypto, stocks, or forex—reading technical signals manually requires hours of screen time. Beginners struggle with complex patterns, and experienced traders often want a quick sanity check on their thesis. We asked ourselves: Can we leverage Vision LLMs to turn static chart screenshots into professional-grade technical analysis reports in seconds? That question led us to build and launch Realtime Chart Analyzer (ChartAI Pro) , now live on the Google Play Store! ⚡ Key Architectural Features We designed ChartAI Pro to act as a seamless, secure second pair of eyes for market charting. Here is a breakdown of what the application delivers right out of the box: 🧠 1. Multi-Modal AI Chart Analysis Instant Processing: Upload or snap a screenshot from platforms like TradingView, Binance, Zerodha, Groww, Upstox, or MT4/MT5. Signal Detection: The core engine evaluates market structures to return clear Bullish or Bearish indicators alongside an AI confidence score. Plain-English Summaries: No overly dense academic jargon—you receive an intelligible breakdown of current market conditions. 🎯 2. Automated Key Price Levels & Patterns Support & Resistance: The system instantly flags primary macro price horizons. Risk Mitigation: Calculates approximate entry zones, mathematical target price targets, and clear Risk/Reward ratios. Geometric Processing: Detects complex shapes including Head & Shoulders, Double Tops/Bottoms, Triangles, Wedges, Flags, and specialized candlesticks (Doji, Engulfing lines). 📊 3. Native Live Market Infrastructure Live Scanners: Includes a built-in terminal tracking real-time crypto, forex, and stock prices (NSE & BSE). Interactive Tooling: Features built-in interactive TradingView frames directly in the layout, allowing you to scan Top Gainers and Losers without hopping between apps. 🔒 Privacy & Security First When d

Hot take 👀 The hardest part of React isn't hooks. It's knowing how to structure an app so it stays maintainable as it grows. Clean architecture beats clever code every time. What's been the biggest challenge in your React projects?

Over the last few months I’ve noticed a pattern emerging across AI tools. Whether it’s Claude Skills, Cursor, Codex, or custom agent frameworks, we’re increasingly giving AI agents “skills”—packages containing instructions, documentation, and sometimes scripts. The problem is… A skill is usually just a Markdown file (plus some assets). Nothing tells you: Who created it. Whether it has been modified. Whether the version your AI is executing is the same one you reviewed yesterday. Whether someone quietly injected new instructions into it. As AI agents become capable of executing increasingly powerful workflows, that becomes a real supply-chain problem. So I built Skillerr. ⸻ What is Skillerr? Skillerr is an open-source protocol and CLI that adds trust and verification to AI skills before they’re executed. Instead of treating a skill as “just another folder,” Skillerr treats it as a verifiable package. It focuses on three things. Package Integrity Every packaged skill receives a unique content-derived identifier along with cryptographic SHA-256 hashes. If any file changes after packaging—even a single character—Skillerr detects it immediately. No silent modifications. ⸻ Structured Contracts Instead of relying on long paragraphs that an AI has to interpret, a Skill contains a structured contract describing: required inputs permissions forbidden actions expected outputs whether a human has actually reviewed it This makes skills easier for both humans and AI agents to reason about. ⸻ Optional Public Provenance Authors can cryptographically sign their skills. Optionally, the package digest can also be anchored into Sigstore’s transparency log, making it independently verifiable without trusting Skillerr itself. Importantly: Only cryptographic identifiers are published. No prompts. No documentation. No knowledge base. No proprietary content. ⸻ I tried to break my own tool Before releasing it, I intentionally attacked it. First I packaged and signed a simple CSV processing s

If you work with a coding agent, count the things watching it right now. Linters. Git hooks. CI. Specs. A memory store. A rules file it's supposed to obey. Half a dozen systems, all making sure the agent builds the right thing the right way. Now count what keeps you oriented across the eleven things you have in flight. For most of us it's a markdown file we hope we remembered to update. We spent two years building harnesses for the agent and left our own work on the honor system. Map the tooling on two axes and that gap turns into a specific, hard-to-unsee hole. This post is the map. (This is part two of three. Part one, The AI orientation tax: it's missing context, not discipline , argued that the cost you're paying is a context bug rather than a character flaw. If you haven't read it, you don't need to. This one stands alone.) Two loops, not one The thing people lump together as "agent workflow" is really two loops at different altitudes: The execution loop: "is the agent building **this one task * right?"* Scope it, design it, write it, test it. One unit of work. The orientation loop: "do you and the agent share an honest picture of **what you're working on * across all the units?"* Capture, check state, prioritize, review, run over the whole board, daily and weekly. Almost every tool you've heard of lives in the first loop. That's not a criticism. It's just where the money and the visible pain were. But it means when people say "we solved agent memory" or "we solved context," they solved it for the execution loop. The orientation loop got left to you and a markdown file. You feel the difference the moment each one breaks. When the execution loop breaks, something yells: a failing test, a red build, a review comment. When the orientation loop breaks, nothing yells. The agent confidently re-suggests the thing you rejected yesterday. You rebuild a mental map you already had this morning. The only signal is a vague sense that you're moving slower than the tools prom