标签：#programming

Recently, while working on an in-progress open-source framework called Projector, I ran into a (not particularly novel) issue: one of it's internal packages ( core ) had grown during this period, and was not nearly as flyweight as it needed to be in the browser. The result was 10-20kbs of unnecessary machinery getting pulled in. I noticed this while running examples. I was consistently hitting a wall in bundle sizes that was surprisingly difficult to get past, even for someone as stubborn and relentless as I am. Naturally, I turned to Claude and ChatGPT to help me with this, and ended up using ChatGPT 5.5 with Codex as I find that, with the "precise" output mode, it tends to be a little more honest than Opus 4.8 these days. I shared exported HAR network logs with it, having it go through the chunks to confirm where the bulk was; consistently, it confirmed that the issue was around an entangling of authoring/resolution code with runtime code in core that was pulling in too much to the browser. The technical details here aren't really important, but I'm using them to illustrate a larger point. We then iterated through a lot of different solutions—I setup a "goal" in codex with benchmarks to hit, and gave it a bunch of constraints, context, and tooling. Finally, after about 2-3 hours of looping against that goal, it completed. Looking through the git diff, I noticed something odd—it had duplicated the result of the resolved module, so it could skip the resolution machinery and thus drop it from the browser bundle (again, technical details not really relevant). It hit the rough kb benchmarks, respected all constraints, utilized all context and skills available, and avoided importing the machinery that we both aligned on being the core problem. It provided an elegant, coherent, well-written api, implemented a surgical, well-tested, well-designed solution, and convincingly defended its work when I queried about the implementation. That sounds great, right? In fact, I thin

At its core, software development has always been about a simple cycle: Write > Review >...

submitted by /u/fagnerbrack [link] [留言]

submitted by /u/CrowSufficient [link] [留言]

AI agents get better the more they run. Every conversation turn, every task completed, every prompt refined adds to a growing body of context that shapes the next output. The compounding effect is real: an agent with 100 turns of memory and a versioned prompt history behaves meaningfully differently from one starting cold. This post walks through using a structured, versioned, API-accessible store as the memory layer for AI agents, with TypeScript examples. Agent messages, system prompts, findings, and instructions are all stored as structured, versioned, API-accessible Objects. Each new turn adds to the record. Each prompt edit is tracked. What Agent Memory Actually Needs The compounding loop only works if the memory layer has the right properties. Most agent frameworks handle working memory well. The gap is episodic and semantic memory: what the agent learned, did, and produced across sessions. Researchers at Elastic recently published a breakdown of agent memory tiers : working memory (in-context), episodic memory (past interactions), semantic memory (knowledge), and procedural memory (learned behaviors). Good persistent agent memory needs four properties: Structured : queryable by type, status, date, or custom field, not just full-text search Versioned : you need to know what the agent wrote at each point in time, not just the latest state API-accessible : any model, any framework, any language should be able to read and write it Human-reviewable : agents make mistakes; a human needs to inspect and correct outputs without touching a database Objects as Agent Outputs When an agent produces output, storing it as a structured Object gives you a queryable record with typed fields, a draft/published workflow so a human can review before promoting to production, a full audit trail of every change, REST API access from any runtime, and a dashboard UI where non-technical team members can inspect, edit, or approve agent outputs. Here's a simple research agent that stores

I’ve been a software engineer for more than 12 years. And like many developers, I’ve been watching AI improve at an incredible speed. Every new model seems smarter than the one before it. Tasks that used to take hours can now be done in minutes. Problems that required deep research can often be solved with a simple prompt. A few years ago, we used to say: Think of AI as a junior developer. That made sense at the time. But today, I don’t think that’s true anymore. AI still makes mistakes. Sometimes very obvious ones. But it also comes up with solutions that surprise me. Sometimes it finds an approach I wouldn’t have thought of immediately. Sometimes it helps me solve a problem much faster than I could on my own. And honestly, that’s both exciting and a little scary. But the biggest thing AI changed wasn’t how I write software. It changed how I think about my work. For most of my career, I thought I loved writing code. I spent years doing it. At work, on side projects, and whenever I had free time. Then AI became part of my daily workflow. In the last month, I’ve built more projects than I normally would in an entire year. Ideas that had been sitting in my notes for years suddenly became possible. And that’s when I realized something important: I don’t actually love writing code. I love building things. I love taking an idea and turning it into something real. I love creating products, solving problems, and seeing something that only existed in my head become something people can use. Code was simply the tool I used to do that. And now AI is another tool. That’s why I don’t hate it. In many ways, AI has helped me build more than ever before. It helped me revisit old ideas that I never had time to work on. It helped me experiment faster. It even encouraged me to explore areas outside software development, like animation and content creation. And this isn’t just happening to programmers. AI is changing design. It’s changing writing. It’s changing marketing. It’s changin

This week's tooling news clusters around a recurring theme: removing dependencies that were never really necessary. Biome ditches the TypeScript compiler for type-aware linting. Swift developers stop caring which editor they're in. And the most interesting finding of the week is that a 1990s text-retrieval algorithm outperforms GPT-4 at catching lying agents. Here's what's worth your attention. Swift Extension Lands on Open VSX Registry The official Swift extension is now published to the Open VSX Registry, which means Cursor, VSCodium, AWS Kiro, and any other LSP-compatible editor that doesn't use the proprietary VS Code Marketplace can now auto-install it without you doing anything. Code completion, debugging, and the test explorer just work. This matters because the Swift toolchain has always been Xcode-or-fight. Any serious cross-platform Swift work meant manually tracking down extensions, pinning versions, and hoping nothing broke when someone cloned the repo on a different machine. Agentic IDEs that provision their own extensions automatically—like Cursor and Kiro—now get Swift support without intervention. Verdict: Ship. If you're already in an Open VSX-compatible editor, there's nothing to configure. Zero blocking concerns; this is a pure reduction in setup friction. Biome v2 Adds Type Inference Without TypeScript Biome v2 ships its own type inference engine, decoupling type-aware linting rules from the TypeScript compiler entirely. The headline number is 75% detection parity on floating promise rules compared to typescript-eslint—lower recall, but at meaningfully lower install weight and CI overhead. Multi-file analysis also lands in v2, unlocking rules that require cross-module context that were structurally impossible in v1. The real value proposition isn't feature parity—it's dependency elimination. Pulling TypeScript out of your lint pipeline reduces cold-start times in CI and removes a whole class of version-mismatch bugs between typescript , @typescri

This week's releases split neatly into two categories: useful incremental hardening (uv, GitLab, Copilot) and things that should change how you architect systems today (Spring CVEs, pg_durable, and a Cornell paper that quietly invalidates a lot of RAG assumptions). The Spring security cluster alone is enough to justify a dependency audit before the weekend. uv 0.11.19 adds CPython 3.15 beta support uv now always computes SHA256 checksums for remote distributions—previously this was situational—and adds PyEmscripten platform support per PEP 783, which formalizes Python packaging for browser and WASM targets. CPython 3.15.0b2 is available as a managed runtime, and a cross-platform installation edge case on Windows hosts has been resolved. The SHA256 change is the one worth noting for security posture. Making verification unconditional rather than optional closes a gap where distribution integrity could go unchecked depending on resolver path. The PyEmscripten addition matters if you're packaging Python for browser runtimes—previously you were working around the absence of a formal platform tag; now you're not. Verdict: Ship. Drop-in upgrade, no breaking changes. If you manage Python distributions or target WASM, update now. Everyone else should still update—supply-chain hardening by default is worth the two minutes. GitLab 19.0 adds group-level review instructions, secrets manager GitLab 19.0 ships two meaningful additions for teams: group-level custom review instructions for Duo code review, configured via .gitlab/duo/mr-review-instructions.yaml with cascading inheritance across projects, and a Secrets Manager that exits closed beta for Premium and Ultimate tiers. Group-level review instructions solve a real annoyance—if you've been maintaining per-project AI review configuration across a monorepo organization, you can now centralize that and let projects inherit or override. It's the kind of change that sounds minor until you've had to sync a guideline update across

This week's AI tooling news splits cleanly between infrastructure you can ship today and capability bets that require more careful evaluation. Anthropic dropped two significant releases—Fable 5 and Managed Agents updates—while the Workflow SDK landed a cancellation primitive that eliminates entire categories of homegrown plumbing. Underneath all of it, a sharp incident review from Anthropic is the most practically useful thing published this week if you're running multi-turn agents in production. Workflow SDK adds AbortController cancellation support The Workflow SDK now threads AbortSignal through workflow steps, using the same web-standard API you already use with fetch . Pass an AbortSignal into your workflow, inspect it inside steps, and you get cooperative cancellation that survives durable suspension and replay. This matters because cancellation in long-running workflows has historically required custom infrastructure—timeout flags passed through context, manual cleanup hooks, bespoke race logic. That's not interesting code to write or maintain. With AbortController support, you get timeout steps, request racing, and parallel work cancellation with patterns your team already knows. Two important caveats: this requires workflow@beta , and cancellation is cooperative. The runtime won't forcibly terminate a step—your step code needs to inspect the signal and respond. If you have steps with opaque third-party calls that don't accept signals, you're still writing wrapper logic. Verdict: Ship. If you're on Workflow SDK 5 and running long-horizon workflows with timeout or race requirements, upgrade and wire this in now. The pattern is standard, the boilerplate reduction is real, and there's no meaningful downside if your steps are already structured around explicit control flow. Anthropic adds dreaming, outcomes to Managed Agents Two distinct additions here. Outcomes let you define explicit success criteria enforced by a separate grader agent—replacing manual prompt

This week's tooling news splits cleanly between performance and compliance: a Go Protobuf parser that closes the gap between reflection and generated code, and a GitLab update that finally makes air-gapped AI deployments practical. Layered in are a forced AWS migration, a cost-pressure move in reasoning model pricing, and an Elasticsearch alternative picking up serious enterprise backing. Here's what's worth your attention. hyperpb Dynamic Parser Matches Generated Code Speed hyperpb is a runtime-compiled Protobuf parser for Go. You feed it a schema at startup, it runs an optimization pass, and the result is a compiled message type you can reuse across requests. Benchmarks show 10x faster parsing than dynamicpb and roughly 3x faster than hand-written generated code. The implication for generic Protobuf services—brokers, validators, schema registries—is significant. If you're doing broker-side validation today with dynamicpb , you're likely throttling throughput or skipping validation under load. hyperpb removes that tradeoff. The catch is that compiled types require caching (the optimization pass is slow and should not run per-request) and field access remains reflection-only—you're not getting struct field ergonomics. Verdict: Ship. If your validation pipeline is hitting dynamicpb throughput limits, this is a drop-in replacement for the hot path. Cache your compiled message types at initialization, and profile field access patterns before assuming it fits your read-heavy workloads. Quickwit Joins Datadog, Relicenses to Apache 2.0 Quickwit, the Rust-based petabyte-scale log search engine, has been acquired by Datadog and relicensed from AGPL to Apache 2.0. Development continues as open source. Distributed ingest and cardinality aggregations are on the near-term roadmap. The production credibility is already there—Binance runs 1.6PB/day through it, Mezmo has petabyte-scale logs in production. The Apache 2.0 relicense removes the corporate control concern that kept som

This week's tooling landscape is quieter on the AI-native side but dense with infrastructure moves that affect how AI-driven workloads actually run in production. Cloudflare's Workflows scaling overhaul is the clearest signal: agent-triggered execution is now an assumed pattern, not a novelty, and platforms are rearchitecting accordingly. The rest of the week rounds out with a kernel maintenance drop, a meaningful abstraction removal in tRPC, and a Biome beta that's finally making ESLint replacement feel plausible. Linux 7.1 Released with Driver and Networking Fixes 7.1 is a maintenance release. No architectural changes, no new subsystems—just patches you should care about if you're running affected hardware or kernel-adjacent tooling. The two fixes worth flagging are heap overflows in the USB serial io_ti driver ( get_manuf_info() and build_i2c_fw_hdr() ), plus memory leak corrections scattered across drivers and networking subsystems. Trace tooling also gets updates, which matters if you're doing kernel-level performance analysis on production systems. One operational note: Torvalds is traveling, so merge window latency may be irregular. If you're tracking pull request timelines for custom kernel builds, plan for slippage. Verdict: Ship — if you're on 7.0 and running USB serial hardware or affected networking paths, upgrade on your normal kernel cycle. No breaking changes, no new dependencies, nothing to validate beyond your existing regression suite. tRPC Drops Abstraction Layer for React Query This is the kind of change that looks small in a changelog and feels large in daily development. The new tRPC client exposes native TanStack Query interfaces— QueryOptions and MutationOptions —directly, rather than wrapping them in tRPC-specific hooks. The practical effect: if you're already using TanStack Query elsewhere in your app, you stop context-switching between two similar-but-different mental models. You call .queryOptions() and .mutationOptions() factories and pa

submitted by /u/CircumspectCapybara [link] [留言]

submitted by /u/craigkerstiens [link] [留言]

Thinking about indexing, we know a only a big picture that uses B-Tree structures in memory, but in modern DBMs systems there are some enhancements introduced in indexing where systems like PostgreSQL are utilizing some new OS system calls like io_uring to make syncrhonous IO reading, also direct retrieval of record from disk using functions like fseek() and in memory optimization of traversing like applying binary search on leaf page. PostgreSQL always keeps a file for indexing, unlike MySQL where it only keeps an indexing file for non-clustered indexing, and clustered indexing is calculated directly from the table, it is interesting to study the indexing file structure as well Index file structure has line pointers, TID called as tuple ID Tuple is the column value, the same column you registered for indexing, by using which Postgres calculates the actual physical address of the records from the disk to fetch it directly. Postgres has another interesting feature, while creating an index, it always sorts data and maintains ranges of pages in page 0 of the indexing, where Postgres can identify which page to look for and then load that page into memory, and then it becomes a leaf page, then binary search is performed to get the actual TID so that the record can be fetched directly For an in-depth explanation about the index file structure, loading the index file into memory, and then searching for the actual record's address, check out the given link submitted by /u/Ok_Stomach6651 [link] [留言]

I had always wondered, why ";"? And the number of times, I have been frustrated because of this little guy, missing it somewhere, adding an extra somewhere, I really wanted to learn about it. So today I did, and I thought I might share it with you guys! Story of Semicolon. submitted by /u/Mastbubbles [link] [留言]

Most SaaS ideas don’t fail because of bad ideas. They fail because the execution gets stuck in an endless setup loop. You start with energy, then slowly get buried in: auth systems, billing, dashboards, SEO, analytics, and infrastructure decisions. By the time the “real product” should begin, momentum is already gone. Here are 7 practical alternatives to building SaaS in a way that never gets finished. 1. Nexora (start with a working SaaS foundation) Instead of rebuilding everything, Nexora gives you a production-ready base so you can focus on actual features. Includes: Authentication system Stripe billing User dashboards SEO pages Blog + docs structure Clean Next.js architecture 🔗 https://nexora.collabtower.com/ 👉 Best for founders who want to ship instead of setup. 2. Build-from-scratch Next.js projects The most common approach. You get: Full control Flexible architecture But you also get: Weeks of setup Repeated boilerplate work High chance of burnout before launch 3. SaaS boilerplates (minimal versions) Lightweight starter kits with: Auth Basic UI Simple Stripe setup But usually missing: Real dashboards SEO systems Production-level structure 4. Supabase-first builds Backend-focused setups. You get: Database Auth APIs But still need to build: Billing UI system Marketing pages SaaS structure 5. Low-code SaaS tools Fast visual builders. Pros: Quick UI creation No heavy coding Cons: Limited flexibility Hard to scale complex SaaS logic Platform dependency 6. AI-generated starter apps AI tools can scaffold SaaS apps instantly. Pros: Fast starting point Cons: Inconsistent structure Requires cleanup Not production-ready out of the box 7. Tutorial-based SaaS builds Many developers still learn SaaS by following tutorials step-by-step. Pros: Educational Cons: Slow Fragmented Hard to turn into real production apps Final takeaway Most SaaS workflows fail before launch because they repeat the same mistake: They start from zero every single time. That creates unnecessary setup

# EnvForge BETA v1.1 ⚡ Structured .env scaffolding for modern applications. Generate, validate, and protect environment variables for 14+ services – without ever opening a docs page. Github repo [ https://github.com/Jos3456/envforge ] NPM version (https://img.shields.io/npm/v/envforge-dev) MIT License (https://img.shields.io/badge/License-MIT-yellow.svg) ## Installation bash npm install envforge-dev **Requirements:** Node.js 18 or later. --- **## Quick Start** bash # 1. Generate an .env file and choose your providers envforge init # 2. Fill in your actual credentials envforge fill # 3. Check everything is set correctly envforge validate ## All Commands ### Scaffolding Command What it does envforge init Create a new .env by selecting providers interactively envforge add <provider> Add variables from a specific provider to your existing .env envforge preset Generate a .env from a popular stack preset envforge example Create a safe‑to‑commit .env.example file envforge fill Interactively enter values (secret keys are masked) envforge list Show all built‑in and custom providers ### Guardrails Command What it does envforge validate Check that all required variables are filled in envforge scan Detect secret keys accidentally exposed in frontend code envforge hook install Install a pre‑commit hook that runs validate + scan ### Customisation Command What it does envforge provider add Create a custom provider template envforge registry update Download the latest providers from the community registry ## Built‑in Providers Category Providers Database Supabase, Neon, MongoDB Atlas Auth Clerk, Auth0, Firebase AI OpenAI, Anthropic (Claude) Payments Stripe Email Resend, SendGrid Storage Cloudinary, AWS S3 / Cloudflare R2 Other Vercel Missing a provider? Add your own with envforge provider add or contribute one to the community. ## Framework‑Aware Scanning Use --framework for smarter detection: # Next.js specific rules (app/ vs pages/, "use client") envforge scan --framework next Th

You walk into the RFP briefing. Your competitor has 200 people, 97% AI coverage, and a 4-day delivery promise. You have 15 people and a proposal you haven't even finished writing. Do you bet on better tech, or on understanding people better — and playing dirtier when you have to? This story is your answer. Act I · The Crack When Finova's RFP landed, everyone in the industry knew how big this was. Cross-border payment system. Multi-currency settlement + compliance + risk. Their last deployment had a P0 incident — an exchange rate module drifted by four decimal places in an edge case, and audit chased it for two months. So Finova's CTO made it clear: a $1.8M contract, and whoever signs off owns the result. $1.8M. Enough to keep a small testing company alive for a whole year. Plenty of firms showed up at the briefing. But only two were real contenders. QualiGuard — mid-sized, just closed their Series A, 200 people, their own AI testing platform called Aegis. A $1.8M contract was barely a rounding error for them — but with Series A money comes the pressure to show revenue growth for the next round, and Finova was a trophy client in the cross-border payments space. The case study was worth more than the project itself. Derek stood at the podium, flipping through slides packed with numbers: Aegis delivers 97.2% test automation coverage. Full Finova platform testing in four business days. No "we'll try." Just "we can do it." VeriTest — small, fifteen people. Marcus spent the whole morning working the room with Finova's people. I sat in the back row with nothing. Marcus slid back over and leaned in: "Their PPT makes yours look like a joke." I didn't answer. I was watching Derek's boss. Sarah — QualiGuard's VP, Derek's direct supervisor. She sat in the front row, off to the side, and never once looked at Derek during his entire presentation. She was on her phone. As one of the few women running a technical department, I watched her longer than I watched Derek. When Derek fla

Quick update to anyone interested in upcoming changes to the PAGI project (spiritual successor to Plack/PSGI). 1) Distribution split up: when we released PAGI, we initially released everything as one distribution. PAGI ( https://metacpan.org/pod/PAGI ) currently has a) the PAGI specification; b) the reference server and c) a bunch of ease of use tools, similar to the role that the Plack distribution played for PSGI. Putting everything into one place was just to make my life easier as in the early bunch of releases there was a lot of fixes and updates, most of which cut across all three parts of PAGI. Also I wanted to make it easy for people getting into PAGI to be able to explore the ecosystem. However now that code seems to be settling down having these in independent repos and releases makes more sense. Going forward the PAGI repo will only update if the spec itself changes; PAGI::Server and PAGI::Tools (where all the utilities and helpers now go) likewise. I think this will start to bring some stability to the ecosystem, especially now that PAGI::Server is functionally complete based on the goal chart I had for it initially. So I will only update it to fix bugs and security issues. PAGI::Tools will probably continue to see evolution over the summer as I start to nail down more common use cases and identify patterns worth encapsulating. 2) Specification clarifications and updates: The PAGI specification itself will move to v0.3 in the next release and it contains mostly clarifications and fixes. Biggest change will be a more detailed mechanism for controlling streaming output, especially around handling back pressure as well as new callbacks to notice when the output buffer is getting full and when it clears. Hopefully these changes will make it easier and more reliable to do streaming in PAGI. PAGI::Server has been updated to match, and the response helper in PAGI::Tools has some updates around that as well. Currently all this sits on Github: https://github.com/j

AI coding agents now edit repositories, run commands, and produce branches. That makes the spec before the work more important: it carries the context, boundaries, and success criteria the agent needs. What a good coding-agent spec includes Specs are becoming more important because AI coding agents are no longer only answering questions. They are reading repositories, editing files, running commands, producing branches, and asking humans to review the result. That changes what a prompt needs to become. When an assistant only answers a question, a private prompt can be enough. When an agent changes a shared codebase, the prompt becomes an assignment. And an assignment needs more than good wording. It needs the right context, boundaries, examples, and a way to judge whether the work matched the original intent. That is the practical reason to prepare a spec before sending a coding agent into a repository. The spec does not need to be long. It does need to tell the agent what problem it is solving, what behavior should change, what must not change, and how the result will be reviewed. At minimum, a good coding-agent spec should give the agent five things: the context behind the task the behavior that should change the constraints the agent should preserve examples or scenarios that define correctness the validation evidence a reviewer should inspect This is the useful idea behind spec-driven development, behavior scenarios, issue templates, lightweight design docs, OpenSpec, GitHub Spec Kit, and many internal engineering proposal formats. The specific framework matters less than the shape of the spec: the agent should receive enough context to act, and the team should receive enough structure to review the result. The spec is not a nicer prompt. It is the prepared assignment between human intent and machine execution. Prompts are good at starting work. Specs are better at carrying it. A private prompt is optimized for immediacy. It lives in a chat session. It can inclu