标签：#development

GitHub has announced that Stacked Pull Requests are now available in public preview, introducing native support for breaking large software changes into smaller, dependent pull requests that can be reviewed and merged independently. By Craig Risi

Microsoft has released .NET 11 Preview 7 with a substantial set of .NET MAUI updates, including cross-platform passkey authentication, a new incremental XAML Hot Reload implementation, Shell route templates, and additional AOT-safe bindings. The release also continues MAUI’s migration from legacy renderers to handlers and improves development workflows on Android and Apple platforms. By Edin Kapić

SpaceXAI has introduced Grok Bot, a system of persistent AI agents that operate on dedicated cloud computers and can interact with websites, applications, inboxes, and other tools. By Daniel Dominguez

JEP 540, Simple JSON API, has progressed to Target status for JDK 28. It introduces a compact API for parsing and generating JSON documents without external dependencies. Focused on core tasks, it provides an immutable value hierarchy. The API allows simple traversal and conversion while enforcing strict syntax rules. Feedback during incubation will shape its future development. By A N M Bazlur Rahman

Cloudflare has released cloudflare/ci, a CI SDK that defines pipelines in TypeScript on top of Cloudflare Workflows, giving each step durable retries and replay, concurrent steps by default and Sandbox snapshot caching. It targets the Workers runtime and depends on Artifacts, still in private beta, so the transferable lesson is the durable-step model rather than a drop-in CI replacement. By Mark Silvester

Shadcn, a design engineer at Vercel, has introduced new components for chat interfaces within the shadcn/ui project. This release includes components like MessageScroller and Message, focusing on conversation functionality. The approach emphasizes modular design, allowing developers to adapt elements without affecting underlying logic or styles. Support for headless components is also provided. By Daniel Curtis

In this podcast, Michael Stiefel spoke to Tracy Bannon about the role of artificial intelligence in software and the attendant risks in the areas of security, software development, and society at large. While it might be reasonable to assume a certain amount of trust within a software ecosystem, the risks escalate when the boundary between two software ecosystems is crossed. By Tracy Bannon

The Quest Begins (The "Why") I still remember the first time I opened a pull request that looked like a novel written by someone who’d had too much coffee. The file was 800 lines long, a single function tried to validate input, fetch data from three different APIs, transform the result, update the UI, and log everything to a console that no one ever looked at. I spent three hours stepping through it with a debugger, only to realize the bug was a typo in a variable name buried three levels deep in a nested if‑statement. When I finally fixed it, I felt like I’d just defeated a dragon… only to discover the dragon had a dozen smaller dragons hiding in its caves. That experience left me wondering: Why does code feel so hard to read, even when it works? The answer wasn’t a fancy framework or a new language feature—it was a simple habit I’d overlooked: making every function do one thing, and do it well . Once I started treating that rule like a sacred oath, the dragons started to shrink, and my code began to feel like a clean, well‑lit hallway instead of a dark, tangled forest. The Revelation (The Insight) The principle is straightforward, yet its impact is massive: each function should have a single responsibility . If you can describe what a function does with a single verb phrase— validateUserInput , fetchUserProfile , renderDashboard —you’re on the right track. If you need an “and” or a “but” in that description, you’ve probably got more than one job packed in. Why does this matter? Readability : A reader can grasp the intent in seconds, not minutes. Testability : Small, focused functions are trivial to unit test. You can mock dependencies and assert outcomes without setting up a whole saga. Debugging : When something goes wrong, the stack trace points you directly to the guilty function, not to a 20‑line monolith where you have to hunt for the offending line. Reusability : A function that does one thing well can be dropped into other parts of the codebase (or even oth

Mastering Turn-Taking in Group Chat: How Two Characters Share One Thread Building a seamless group chat experience where two characters share a single thread can be surprisingly tricky. While one-on-one conversations with AI are relatively straightforward, introducing a second AI persona into the same chat thread raises a fundamental question: when a user speaks, who answers? We recently launched multi-character rooms on AmorLink, and this article delves into the turn-taking logic we developed. You'll discover why the majority of this logic deliberately avoids calling a language model and explore the contextual challenges that proved more complex than the routing itself. The Pitfalls of Simple Solutions The most intuitive approach is to have "everyone answer every message." However, this quickly devolves into a "press conference" scenario. Imagine asking, "How was your day?" and receiving two stacked paragraphs, each completely unaware of the other. This method also doubles inference costs and increases the time-to-first-token for every turn. Another common, yet flawed, strategy is to "pick at random." While cheaper, it's often more frustrating. If a user asks, "Iris, what do you think?" and the other character answers, the illusion of intelligent conversation shatters instantly. Randomness offers no improvement as the conversation scales. A Ladder Approach to Turn-Taking The key insight is that turn-taking isn't a single problem but a stack of them. The vast majority of these problems have unambiguous solutions. For instance, if a message explicitly names a character or is very short and follows a reply, the decision is clear. Only a minority of turns genuinely require complex judgment. Therefore, our policy is structured as a ladder, prioritizing cost-effective solutions for easy cases and reserving the more expensive AI model for the difficult ones. Our five-rung ladder works as follows, with the first matching condition determining the response: Exactly one memb

What I Learned Stealing Ideas from Matt Pocock’s .agents Directory If you’ve spent more than ten minutes on TypeScript Twitter, you know Matt Pocock. He’s the guy who made zod and TS generics feel approachable. But a few weeks ago, I stumbled onto something more interesting than his type gymnastics: a repo called mattpocock/skills , which is literally a dump of his .agents directory. At first I thought it was a joke. Then I realized it’s a goldmine for anyone building AI-assisted coding workflows. This isn’t a “prompt engineering” fluff piece. This is about how a working engineer structures the instructions, context, and guardrails that an AI agent needs to actually ship code without wrecking your codebase. Here’s what I learned, what I copied, and what I’d change. The Problem: Your AI Agent Is Only as Good as Your Defaults Let me set the scene. You’ve got Cursor, or Claude Code, or some other agentic tool. You ask it to “refactor this function.” It does. Then you realize it: Renamed a public API that three other files depend on. Used a pattern your team explicitly banned six months ago. Wrote tests that mock everything so they pass but assert nothing. Sound familiar? The root cause isn’t the model. It’s that you gave the agent zero context about your project’s conventions. Most people write a two-line system prompt and expect magic. Matt’s approach is different: he treats the agent like a junior engineer who needs a detailed onboarding doc, not a mind reader. His skills repo is essentially a set of Markdown files that define, in explicit terms, how the agent should behave in specific situations. Think of it as a CONTRIBUTING.md for your AI pair programmer. What’s Actually in the Repo (Don’t Just Clone It) I’m not going to paste the whole thing here—go read it yourself (link: github.com/mattpocock/skills ). But structurally, it breaks down into a few key categories that matter. 1. Role and Tone Definitions The first thing you’ll notice is that Matt doesn’t just say

Google has launched Gemini 3.7 Flash, providing significant updates for coding, automation, and the development of autonomous agents. The company reduced production pricing to help businesses deploy these tools more affordably. This release comes only three weeks after the previous version, signaling a faster pace for developer-focused updates. Accelerated development cycles and cost reduction strategies The introduction of Gemini 3.7 Flash highlights a shift in how technology providers manage their product lineups. Google is prioritizing rapid iteration for its Flash series, which serves as a high-speed tool for developers. This latest version arrived less than a month after its predecessor, showing the company responds quickly to user feedback. Engineers designed this model to handle software engineering tasks and complex, multi-step workflows with higher precision. Pricing for the new model sits at $0.75 per million input tokens and $3.75 per million output tokens. This represents a reduction of approximately fifty percent compared to the prior version. By lowering the financial barrier, Google aims to make large-scale production deployments more sustainable for businesses. The company describes this version as a reliable workhorse capable of following instructions with greater accuracy than previous iterations. While the Flash series moves quickly, the more advanced Pro models follow a different path. These high-end models, designed for the most difficult reasoning tasks, see less frequent updates. During recent financial discussions, leadership at the company did not provide a specific timeline for the next Pro release. This indicates a growing gap between fast, cost-effective models and the slower development of premium intelligence tiers. Industry trends in model tiering Other companies in the industry are following similar patterns by separating their offerings into distinct categories. For example, some competitors have launched high-end variants alongside

Three years ago, I started my journey as a developer with a pretty simple idea: Learn to code, gain experience, become good at it. Three years later, I’ve learned a lot — but I’ve also realized that becoming a developer isn't as straightforward as I imagined. I've worked with JavaScript, React, Laravel, PlayCanvas, WebGL, and other technologies. I've worked on real projects, dealt with bugs I didn't understand at first, learned technologies because a project required them, and worked alongside other people to get things done. I think one of my strengths has always been learning new technologies and adapting to new problems. But there are things I'm not proud of. I've never been particularly good at finishing personal projects by myself. I've started many things, learned from them, experimented with different technologies, but I rarely took them all the way to completion. I also don't have an impressive GitHub contribution graph. I haven't spent the last three years consistently building open-source projects or pushing code every day. And if I'm being completely honest, I don't think I've mastered any particular technology. I'm good enough to build things. I'm good enough to understand code, solve problems, learn what I don't know, and contribute to a team. But I'm not at the level where I'd confidently say: "This is the thing I'm an expert at." And recently, AI has made me think about this even more. I'm not afraid of AI taking over jobs. I actually think the capabilities we're getting are incredible. What concerns me is more personal: If AI can already build many of the things I've spent years learning to build, then what should I be becoming as a developer? For a while, I felt overwhelmed by that question. Should I learn more technologies? Should I specialize? Should I focus on fundamentals? Should I build more projects? Should I contribute to open source? Should I learn AI? I'm realizing that the answer probably isn't to chase everything. My next goal isn't to co

For years, I thought being a good programmer meant knowing your stack really well. I was a Laravel developer, A React developer, A Node.js developer and A Go developer. And there was some truth to that. I spent years working with Laravel, for example, and naturally became faster at solving problems with Laravel. I know the ecosystem, the common mistakes, the packages, the conventions, and probably a few things that weren't even written in the documentation. My stack became part of my identity as a developer. But I think AI is slowly changing that. Not because frameworks and programming languages don't matter anymore. They obviously do. It's because AI has made moving between them much easier. Today, I can open a codebase written in a language or framework I haven't touched in years, or maybe have never used seriously, and get productive much faster than I could before. I can ask AI to explain the project structure. I can ask it to explain a piece of code. I can ask it to translate something I understand in PHP into Go. I can ask it to help me write tests. I can use it while debugging. I can even ask it why a particular approach might be a bad idea. That doesn't suddenly make me an expert in that technology. But it means I don't need to spend weeks just getting comfortable enough to start solving the actual problem. And I think that's a pretty big change. Your Stack Is Becoming Less Important There was a time when knowing a technology itself was a significant advantage. If you knew Laravel, you had to learn Laravel. If you wanted to learn React, you had to spend time understanding React. If you wanted to work with Kubernetes, good luck. You read documentation, watched tutorials, built things, broke things, fixed them, and slowly built up experience. That's still how you become good. But AI has changed the entry point. The first few hours with a new technology are no longer as painful as they used to be. You can have an AI sitting beside you explaining things as you g

On 1 August I opened an issue that was three sentences long. A hundred and one minutes later the feature was merged, and the document that got it there ran to 457 lines . I didn't write those 457 lines. In fact, I didn't have to write any more documentation, and not because I simply allowed Claude to run amok. Here is the issue in full — control-api#265 , 225 characters: control-api#265 — Manifest-backed dashboard feeds For each dashboard, auto create a manifest keyed by dashboard_id. For each sensor the dashboard uses, tag it to be included in the manifest. When a dashboard definition is updated, add / remove tags from sensors accordingly. From that genesis moment, this is the lifecycle of the issue all the way through to landing: Time (UTC) Event 14:25 Issue #265 opened — 225 characters 14:54 FEAT-0007 spec committed — 457 lines 15:35 Spec merged (PR #266) 15:51 Implementation committed 16:06 Implementation merged (PR #267, 15 files), issue closed The interesting part isn't the speed. It's the step at 14:54 that landed a previously non-existent spec document, and what happened in the twenty-nine minutes before it. The issue was never a specification I often write issues like this one...the way most people write shopping lists. Actuator address is not ensured? Baseline the trace correctly. With the pre-rolls, the frame-rate looks out. They're abbreviated to the point of being cryptic to everyone else. I write them this way deliberately: I'm usually mid-something else when I notice a problem, or have an idea for a better route to the solution. The cost of a full write-up right at that moment would be a fractured sense of flow. As most engineers will tell you, the transitions into and out of flow are the most disruptive parts of their working day. This terse form of issue-writing can be all you need, and it's worth being precise about why it works and the trade-offs it includes. It is not because "the issues are good enough". They aren't. When you pick one of these u

I've merged plenty of AI-generated code that was genuinely fine. I've also caught myself almost merging code that looked fine and wasn't, because it read like something a competent person wrote and my brain filled in the rest. Over the last year I've settled into a rough set of questions I run through before approving anything I didn't write line by line myself, generated or not. Here they are, in the order I actually ask them. 1. What problem is this code actually solving? It's easy to review whether code works and skip whether it solves the right thing. AI tends to answer the literal prompt, not the intent behind it. def get_active_users (): return db . query ( " SELECT * FROM users WHERE active = true " ) If "active" was supposed to mean "logged in within 30 days" and not a boolean flag that's rarely updated, this passes every test and still solves the wrong problem. Reviewer tip: Read the original ticket or request before reading the diff. Check the code against the intent, not just the literal ask. 2. Do I actually understand the implementation? Not "does it look reasonable," actually understand it, line by line, well enough to explain it to someone else. Reviewer tip: Try to explain the function out loud in one sentence per major step. If you get stuck anywhere, that's the part you haven't actually reviewed yet, just skimmed. 3. What assumptions is it making? Every implementation bakes in assumptions about the shape of the data, the order things happen in, or what "normal" looks like. function getLatestOrder ( orders ) { return orders [ orders . length - 1 ]; } This assumes orders is sorted chronologically and never empty. Neither assumption is stated anywhere. Reviewer tip: Ask "what does this assume about its inputs that isn't checked anywhere?" Write the answer down, literally, in the PR comment if it matters. 4. What happens with bad input? Bad input isn't an edge case, it's a certainty over a long enough timeline. def parse_age ( value ): return int ( val

Expedia Group has open-sourced mockql-rs, a Rust CLI that fills @mock-annotated GraphQL fields with LLM-generated data at request time. It follows Airbnb's @generateMock in April and a GraphQL Foundation RFC opened in February. All three solve the same problem with different architectures, and two use the same directive name with incompatible semantics. By Steef-Jan Wiggers

Rx.NET 7.0 has been released with a narrowly focused change aimed at reducing deployment size for Windows applications. The new version separates WPF, Windows Forms, UWP, and Windows Runtime integration from the main System.Reactive package, avoiding cases where self-contained applications could acquire tens of megabytes of unused framework dependencies. By Edin Kapić

The term software factory is getting a lot of attention right now, and for a good reason. AI coding assistants can generate code much faster than before. But faster coding alone does not mean faster, safer delivery. In many teams, it simply moves the bottleneck to review, testing, deployment, and operations. A software factory is a way to organize the entire software development life cycle as one connected, repeatable system. Think of a car manufacturing assembly line. Each station has a clear job, work moves forward in a predictable order, quality checks happen at the right moments, and the finished product is inspected before it leaves the factory. An agentic software factory applies that same idea to software delivery. AI agents do focused work across planning, coding, testing, deployment, monitoring, and feedback. Humans remain in charge of specifications, security, policies, approvals, and the decisions that should never be delegated blindly. Key Takeaways An agentic software factory coordinates AI agents across the complete software delivery lifecycle. Faster AI-assisted coding can create review bottlenecks unless downstream stages also improve. Humans retain ownership by defining guardrails, specifications, approvals, and security requirements. Workflow orchestration connects context, automation, observability, incident handling, and feedback loops. What Is a Software Factory? A software factory is not just a collection of developer tools. It is an operating model where software delivery is designed as a smooth, observable workflow from idea to production and back into improvement. In a car factory, a vehicle moves through assembly, painting, quality inspection, final assembly, and delivery. People are involved at important checkpoints, but the process does not restart from scratch at every station. It is structured, repeatable, and connected. The same model works for software. In an agentic software factory, the flow can look like this: Requirements and desi

npm 12 introduces significant security-related changes, making certain installation behaviors opt-in. Notably, script allowances are now off by default, which requires explicit approval for running scripts, including implicit builds. The update also restricts non-registry sources and addresses community concerns about security risks from automatic script execution. By Daniel Curtis

Vercel has made the v0 API generally available, enabling developers and AI agents to programmatically generate, iterate on, preview, and deploy applications through API calls. By Daniel Dominguez