AI 资讯

We built a monokernel that runs the full decode sequence as one GPU-resident program on AMD MI300X, with some neat optimizations. The die topology is central to the result, we map memory access patterns to the physical layout, compute units group by their associated IOD, and the hardware runs at its full design performance. Up to 3,300 output tokens/s per request, batch size 1, no speculative decoding, no quantization, on 8x MI300X. This preview runs a small 2B coding model, and we plan to support large frontier MoE in the future. Technical deep dive: https://blog.kog.ai/building-a-single-kernel-latency-optimized-llm-inference-engine-on-amd-mi300x-gpus Try it: https://playground.kog.ai submitted by /u/averne_ [link] [留言]

GitHub reports cutting token costs in agentic CI workflows by up to 62% by pruning unused MCP tools, swapping some MCP calls for gh CLI, and running daily “auditor” and “optimizer” agents. A token-usage.jsonl artefact and an Effective Tokens metric help track spend across models and spot regressions. By Mark Silvester

FastAPI released an official VSCode extension, which includes features such as route exploration, endpoint search, and CodeLens-style navigation. This tool aims to enhance the development experience for FastAPI users. submitted by /u/Top-Rush83 [link] [留言]

For a while, my starter kits didn't include any Docker configuration. The foundation was solid with auth, roles, MFA, Horizon, Logs Viewer, but the deployment side was left to whoever cloned the project. That was a deliberate choice at first. Docker setups vary a lot depending on the infrastructure: some people use a reverse proxy, others have Cloudflare in front, some run on bare metal, others on managed platforms. I didn't want to ship something that would need to be ripped out immediately. But over time I changed my mind. Here's why and what the process taught me. The problem with "just configure it yourself" Leaving deployment out of a starter kit sounds reasonable. In practice, it means every project starts with the same 4-6 hours of Docker work that never really changes. Multi-stage Dockerfile. PHP-FPM config. Nginx with HTTPS. PostgreSQL and Redis wired up. Horizon and the scheduler running as proper services. Healthchecks everywhere so Docker knows when things are actually ready. None of it is so complicated. But it's time-consuming, easy to get subtly wrong, and almost identical from one project to the next. Once I admitted that, the question wasn't whether to include Docker, it was how to do it in a way that's actually useful without being too opinionated about production infrastructure. What I ended up building The setup I settled on covers the full local development stack: A multi-stage Dockerfile : separate stages for Composer dependencies, Node assets, and the final PHP-FPM image. Keeps the production image lean. Nginx with HTTP-to-HTTPS redirect and a self-signed certificate for local dev, already included, no setup needed. PostgreSQL and Redis as services with proper healthchecks. Horizon and the scheduler as dedicated services, not crammed into the main app container. A bootstrap service that runs php artisan migrate --force before the app starts. The Dockerfile uses three stages to keep the final image as lean as possible: FROM php:8.4-fpm-alpine A

Here are two scenes. They look unrelated. They're not. Scene 1 Two people at a café, talking about a restaurant they want to try. A stranger walking past stops: "That place closed six months ago. The one on the corner is better." A brief nod, and they walk on. The two people exchange a glance, taken aback. Why did that person stop? What did they want? A few steps away, the stranger is also confused. They had useful information. They shared it. Why did these people react so strangely? Scene 2 A colleague is visibly stressed, describing a difficult situation at work. One friend pulls their chair closer, puts a hand on their arm: "That sounds really hard." Another opens their laptop: "I found something that might help — HR has a process for exactly this, I'll send you the link." The colleague leans into the first. Glances uncertainly at the second. The second person doesn't understand why sitting close and saying "that sounds hard" counts as helping. You haven't solved anything. The first doesn't understand why anyone would respond to distress with links. Both scenes end the same way: people on both sides convinced they did the right thing, confused by the other's reaction. The mismatch is mutual and invisible from the inside. Two survival instincts, two empathy systems For many autistic people, information is a survival mechanism. Uncertainty is threat, missing information is a vulnerability, and the drive to correct and share runs below conscious awareness. Empathy, expressed through that system , looks like giving someone what keeps you safe: accurate information, solutions, resources. The social preamble before sharing — announcing yourself, softening the approach — doesn't arise as a concept. Why would useful information require an introduction? For many neurotypical people, social safety is a survival mechanism. Group cohesion and reading others accurately are what keep people safe. Empathy, expressed through that system , looks like presence: mirroring distress,

ORA-00031: Session Marked for Kill — What It Means and How to Fix It ORA-00031 occurs when a DBA issues ALTER SYSTEM KILL SESSION but Oracle cannot terminate the target session immediately. Instead, Oracle marks the session as "KILLED" and waits for it to reach a safe termination point — typically after completing a rollback or releasing OS-level resources. This is less of a hard error and more of a transitional state that every Oracle DBA will eventually encounter. Top 3 Causes 1. Large Transaction Rollback in Progress When you kill a session mid-transaction, Oracle must roll back all uncommitted changes to preserve data integrity. The larger the transaction, the longer the session stays in KILLED status. -- Check rollback progress for KILLED sessions SELECT s . sid , s . serial # , s . username , t . used_ublk AS undo_blocks , t . used_urec AS undo_records FROM v $ session s JOIN v $ transaction t ON s . taddr = t . addr WHERE s . status = 'KILLED' ; 2. Unresponsive or Disconnected Client If the client network connection is broken or the client process has hung, Oracle cannot deliver the kill signal. The session lingers in KILLED state until the OS-level connection finally times out. -- Find the OS process ID (SPID) for stuck KILLED sessions SELECT s . sid , s . serial # , s . username , s . status , p . spid AS os_pid , s . machine , s . program FROM v $ session s JOIN v $ process p ON s . paddr = p . addr WHERE s . status = 'KILLED' ; 3. OS-Level I/O or Resource Wait Sessions blocked at the OS level (disk I/O stall, memory pressure, storage issues) cannot respond to Oracle's internal kill signal. In these cases, only an OS-level process termination will resolve the problem. -- Identify what the session was waiting on before being killed SELECT sid , serial # , status , event , wait_class , seconds_in_wait FROM v $ session WHERE status = 'KILLED' ; Quick Fix Solutions Option 1 — Use the IMMEDIATE keyword (recommended first step) -- Standard kill (asynchronous) AL

Every line of your smart contract costs something. Some lines cost more than others. In this part of our gas saving series, we’ll explore how to write smarter Solidity code that keeps your contract lean and efficient. Here are six simple and practical ways to reduce gas costs while writing Solidity smart contracts. 1. Use payable Only When Needed, But Know It Saves Gas In Solidity, a function marked payable can actually use slightly less gas than a non-payable one. Even if you're not sending ETH, the EVM skips some internal checks when the function is marked payable. See this example: function hello() external payable {} // 21,137 gas function hello2() external {} // 21,161 gas That tiny difference may not seem like much, but across thousands of calls, it adds up. Only use payable when your function is actually meant to accept ETH 2. Use unchecked for Safe Arithmetic When You’re Sure Since Solidity 0.8.0, all arithmetic operations automatically check for overflows and underflows. While this makes contracts safer, it also uses extra gas. When you're certain that overflow won't occur, you can use the unchecked keyword to skip these safety checks. uint256 public myNumber = 0; function increment() external { unchecked { myNumber++; } } Gas used: 24,347 (much cheaper than using safe math) Warning: Use unchecked carefully. Only when you're confident there's no risk of overflow. 3. Turn On the Solidity Optimizer The Solidity Optimizer is like a smart helper that cleans up and tightens your compiled bytecode. It does not change how your contract works, but it removes waste and makes it cheaper to run. If you’re using tools like Hardhat or Remix, always enable the Optimizer before deploying to mainnet. 4. Use uint256 Instead of Smaller Integers (Most of the Time) Smaller types like uint8 or uint16 might look more efficient, but they can cost more gas during execution. That’s because the EVM automatically converts them to uint256 behind the scenes. So, if you're not tightly p

If you've ever built or set up a subscription experience on Shopify for a coffee brand, you've probably run into the same problem most merchants face: The signup flow works great. The first order goes out. And then subscribers start quietly disappearing before the third delivery. This isn't a coffee problem. It's a subscription infrastructure problem — and it's almost always caused by the same handful of missing pieces in the system underneath the storefront. In this guide I'll walk through the practical setup decisions that actually move the needle on retention for coffee subscription businesses on Shopify — from choosing the right model and pricing structure to the fulfillment calendar, dunning logic, and cancellation flow that most setups skip entirely. Why Coffee Works So Well as a Subscription Product Before getting into setup, it's worth understanding why coffee is genuinely one of the better products to build a subscription around — when the infrastructure supports it. Predictable consumption cycle. A 12-oz bag of whole beans lasts roughly two to three weeks for a single drinker. That natural rhythm makes it easy to design a billing and delivery schedule that matches actual usage patterns. Daily habit. Roughly two-thirds of American adults drink coffee every day. A subscription removes the friction of reordering, and that convenience compounds into real retention over time. Freshness as a retention argument. Coffee quality degrades noticeably after roasting. Subscribers who care about quality genuinely prefer a recurring shipment over buying retail — which means freshness becomes a built-in reason to stay subscribed that most product categories simply don't have. The global coffee subscription market reached $808.8 million in 2024 and is projected to surpass $2.2 billion by 2033. The infrastructure opportunity for developers and merchants building on Shopify is real and still early. Step 1 — Choose the Right Subscription Model Before You Build The model choic

Agentic AI coding tools are transforming how we build software. But they share a fundamental constraint: context windows are finite, and as chat sessions grow, AI performance degrades, a phenomenon Anthropic calls context rot . The model loses its grip on early instructions, leading to a frustrating "fix-it loop" where the agent fixes one thing but breaks another. Most of us prompt an agent, let it write code, review it, and repeat. This works beautifully for prototypes. But when you need to build a stable, full-featured product with hundreds of mission-critical acceptance criteria (AC), "vibe-coding" breaks down. The reality is that you get better behavior from agents the same way you get it from humans, by explicitly capturing what good and bad look like, and checking against it . Coming from a systems engineering background in regulated industries, I knew we needed to stop treating agents like conversational chat buddies and start treating them like engineering assets. That's why I built DevCortex : a purpose-built structured intelligence layer that brings systems engineering discipline to agentic workflows. What is DevCortex? DevCortex is an agentic development platform built on one core idea: AI agents work best when they have structured, queryable access to a database of requirements they can interrogate on demand, not a wall of text in a prompt. It sits between the human specification and AI execution using three components: 1. An Agentic-V Model Database: A structured hierarchy mapping your high-level vision (ConOps) to system specs (Specs), individual requirements (Reqs), linked defects (Issues), and an auto-generated Traceability Matrix. 2. An MCP Server: Delivers just-in-time, high-signal context to tools like Claude Code or Open Code. Instead of dumping requirements upfront, the agent queries exactly what it needs, when it needs it. 3. Human Control Planes (Web UI & CLI): A multi-user Web UI with real-time WebSocket feeds to watch your agent work, plus a

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I built and revived Mandi Central , a complete business operations and billing system for mandi-style trading businesses. Live Project: https://mandicentral.in Mandi Central helps manage daily mandi operations like purchases, farmer purchase entries, sales entries, payments, bank and cash ledgers, accounting heads, reports, invoices, outstanding balances, and financial statements from one structured platform. This project was not started as a simple demo. It was a real business-focused software project, but it had many unfinished parts, broken flows, missing reports, pending PDF generation, incomplete mobile API planning, and several UI and accounting issues. For the GitHub Finish-Up-A-Thon Challenge, I brought it back, fixed the pending issues, completed the core business flow, and made the project live on mandicentral.in . Demo Live Website: https://mandicentral.in GitHub Repository: https://github.com/hiijoshi/bill Screenshots and demo cover the completed modules: Business Operations Hub Sales List Bank reconciliation Cash ledger Bank ledger Sales entry Purchase entry Farmer purchase entry Bulk PDF download Accounting reports Party ledger redirection Outstanding reports Mobile API-ready backend The Comeback Story Mandi Central started with a strong idea: create one platform where mandi businesses can manage their complete daily workflow. But before this challenge, the project was stuck with many incomplete and pending items. There were more than 40 pending issues across PDF generation, sales invoices, bank ledger, cash ledger, accounting reports, outstanding reports, purchase calculations, sales calculations, mobile APIs, AWS deployment, domain setup, and UI fixes. Some of the major problems before completion were: PDF generation was not working properly. Bulk sales bill download was missing. Mobile application APIs were pending. Farmer Purchase Entry API was pending. Purchase Entry API w

Genuine curiosity question. When you navigate from one page or topic to another online — by clicking links, searching, or just drifting — there's an intuitive sense that you've "gone far" from where you started. But I keep getting stuck trying to think about what that actually means in a measurable way. A few candidates I've considered: Hop count (links or search steps between origin and current): simple, but coarse — one hop can take you across an enormous topic gap. Embedding cosine distance (sentence transformers, BERT-style): captures semantic drift, but feels fuzzy and threshold-dependent. Knowledge graph distance (Wikipedia link graph, ConceptNet): clean when both endpoints exist in the graph, breaks down otherwise. KL divergence between topic distributions (LDA-style): theoretically elegant but compute-heavy. Information gain / surprise (how unexpected the current content is given the start): same trade-off — clean in theory, expensive in practice. Each captures something different — semantic relatedness, structural connectedness, surprise/novelty, raw effort. None feels like THE answer. Is there established literature that's thought about this carefully? Or do practitioners just pick whichever proxy fits the use case (recsys uses embeddings, search engines use something else)? Would love to hear how folks in IR, graph theory, recsys, or web crawling actually approach this in practice. submitted by /u/retarded_770 [link] [留言]

Trace AI requests, workflows, and costs in one timeline Discussion | Link

Java LLD: Designing a Thread-Safe Parking Lot with Strategy Pattern Designing a parking lot is a staple of Java LLD and machine coding interviews, yet most candidates fail to write production-grade code. As an ex-FAANG interviewer, I've seen countless designs fall apart under concurrent traffic or when asked to support multiple slot allocation algorithms. If you're prepping for interviews, I've been building javalld.com — real machine coding problems with full execution traces. The Mistake Most Candidates Make Monolithic locking on the entire ParkingLot class: Using a global synchronized keyword on the entry method, which serializes all gate entries and destroys system throughput. Hardcoding slot-finding logic: Mixing spatial layout algorithms (like nearest-to-entrance or smallest-available-fit) directly inside the ParkingLot or Gate classes, violating the Open-Closed Principle. Thread-safety as an afterthought: Relying on raw List<Slot> iterations without synchronization, causing race conditions where multiple cars are assigned to the exact same physical slot. The Right Approach Core mental model: Decouple capacity management from slot selection by using a Semaphore for gate-keeping and the Strategy Pattern for thread-safe slot allocation. Key entities: ParkingLot , Gate , Slot , Vehicle , ParkingStrategy ( SmallestFitStrategy , NearestEntranceStrategy ), and StrategyFactory . Why it beats the naive approach: It isolates concurrency concerns (preventing overbooking) from business rules (how we choose a slot), making the system highly performant and easily extensible. The Key Insight (Code) public class EntryGate { private final Semaphore semaphore ; private final ParkingStrategy strategy ; public EntryGate ( int capacity , ParkingStrategy strategy ) { this . semaphore = new Semaphore ( capacity ); this . strategy = strategy ; } public synchronized Ticket park ( Vehicle vehicle ) { if (! semaphore . tryAcquire ()) throw new ParkingFullException (); Slot slot = strat

Most software projects focus on producing outputs. Most AI projects focus on producing predictions. But real organizations don't operate on outputs or predictions alone. They operate on decisions. A decision has consequences. A decision creates risk. A decision consumes resources. A decision changes the future state of a system. Over the last few months, I've been studying and building systems around a simple question: How can we make decisions more explainable, auditable, and repeatable? This led me toward concepts such as: event-driven architectures decision logging risk evaluation pipelines audit trails feedback loops operational intelligence systems Instead of asking: "Can we predict what will happen?" I'm becoming more interested in asking: "Can we explain why a decision was made?" and "Can we reproduce that decision six months later?" Current areas I'm exploring: Financial decision systems Risk infrastructure Event-driven architectures Blockchain compliance workflows Operational intelligence platforms One of the projects I'm currently building is an Event-Driven Decision Logging System (EDDL), designed to explore how organizations can record, audit, and replay critical decisions over time. Still learning. Still building. Still refining my understanding of how complex systems operate under uncertainty. Looking forward to sharing the journey here. systemsdesign #architecture #backend #fintech #softwareengineering #eventdriven #riskmanagement

After months of using Jest for unit testing, we decided to take the plunge and migrate to the built-in node:test runner. The results were surprising, with some features working seamlessly and others requiring significant rework. In this post, we'll share our journey and the lessons we learned along the way. Introduction to node:test The node:test runner is a built-in testing framework that comes with Node.js. It's designed to be fast, efficient, and easy to use. Here's an example of a simple test using node:test: import { test } from ' node:test ' ; import { Command } from ' @aws-sdk/client-lambda ' ; test ( ' Lambda client test ' , async ( t ) => { const lambdaClient = new Command (); const response = await lambdaClient (); t . equal . responseStatusCode , 200 ; }); Warning: When using node:test, make sure to handle errors properly, as unhandled errors can cause the test runner to crash. Migrating from Jest to node:test Migrating from Jest to node:test requires some changes to your test code. One of the main differences is the way you handle ES modules. In Jest, you can use the jest.config.js file to configure how ES modules are handled. In node:test, you need to use the --test-type option to specify the type of test you're running. Here's an example of how to migrate a Jest test to node:test: // jest.test.js import { lambdaClient } from ' ../lambdaClient ' ; describe ( ' Lambda client test ' , () => { it ( ' should return 200 ' , async () => { const response = await lambdaClient (); expect ( response . statusCode ). toBe ( 200 ); }); }); // node-test.test.js import { test } from ' node:test ' ; import { lambdaClient } from ' ../lambdaClient ' ; test ( ' Lambda client test ' , async ( t ) => { const response = await lambdaClient (); t . equal ( response . statusCode , 200 ); }); Tip: Use the --coverage option to generate code coverage reports for your tests. Overcoming Incompatibilities and Limitations One of the main limitations of node:test is that it does not su

Over 51% of all GitHub commits in early 2026 are AI-generated or AI-assisted. That statistic creates a problem no one anticipated when AI coding tools first launched: who reviews the AI's code? The answer, increasingly, is another AI. The AI code review market has grown rapidly alongside vibe coding and AI-first development workflows. But the category is fragmented there are PR-level reviewers, IDE inline analyzers, security scanners, and general-purpose AI assistants all claiming to do "code review." They work very differently, and picking the wrong one for your workflow is a real productivity cost. This guide cuts through the noise. We explain what each category does, highlight the best tools in each, and give you a decision framework to help you choose what fits your actual situation. Why AI Code Review Is Now Essential Three converging trends make AI code review the category to watch in 2026: AI-generated code has real quality problems. Research shows 45% of AI-generated code fails at least one OWASP Top 10 security check, and 53% of developers have found security vulnerabilities in AI-written code. When you use tools like Cursor, Claude Code, or GitHub Copilot to write 80% of a feature, you're shipping code you may not have read line by line. Code review is a bottleneck. Stack Overflow's 2026 developer survey found code review wait time is the top-ranked productivity killer. For solo developers and small teams, reviews pile up and slow shipping. AI reviewers don't have calendars. The security stakes are rising. As more non-developers ship production code via vibe coding, the need for automated security checks compounds. AI review tools catch issues like SQL injection, CORS misconfigurations, and hardcoded secrets before they ship. Two Categories of AI Code Review Before picking a tool, understand that "AI code review" means two distinct things. 1. PR-Level AI Reviewers These run at the pull request level. When you open a PR on GitHub, GitLab, or Bitbucket, they

TL;DR I've missed a lot of opportunities simply because I didn't know they existed. So every...