AI 资讯

If you work on long-lived feature branches, you've probably experienced this: master (or main ) keeps moving. Your branch falls behind. Pull requests become harder to review. Merge conflicts get bigger every day. Many teams solve this by rebasing their feature branches. Others—including many enterprise teams—prefer merging the latest master into the feature branch to preserve commit history and avoid rewriting commits that may already be shared. If your workflow uses merge instead of rebase, this article shows how to make the process much faster with a custom Git alias. The Problem Imagine your repository looks like this. master A──B──C──D feature/login \ E──F While you're developing, your teammates merge several pull requests. master A──B──C──D──G──H──I feature/login \ E──F Now your feature branch is missing the latest changes. If you don't sync it: merge conflicts accumulate CI may fail unexpectedly testing becomes less reliable your eventual pull request becomes much harder to review Keeping your branch up-to-date regularly makes integration much smoother. Updating Your Branch Manually Suppose you're working on: feature/login and want to sync it with master . First, fetch the latest changes: git fetch origin Switch to your feature branch: git checkout feature/login Reset your local branch to match the remote version: git reset --hard origin/feature/login Why reset? This ensures your local branch exactly matches the remote branch before merging. It's useful if your local branch is only a working copy of the remote branch. Warning: Any unpushed commits will be permanently deleted. Merge the latest master : git merge --no-ff origin/master Finally, push the updated branch: git push Your history now becomes: master A──B──C──D──G──H──I \ feature/login M \ / E──────F where M is the merge commit. That's a Lot of Typing... Every time you want to synchronize a branch, you're repeating the same commands: git fetch git checkout feature/login git reset --hard origin/feature/l

This started as a comment @wrencalloway left on my last post. It was sharp enough that it deserved more than a reply — so here's the full version. You did the work. The page is server-rendered. The JSON-LD is in the raw response. curl returns the whole article, headline and all. A crawler that fetches your URL gets everything it needs. Except the crawler never fetches your URL. It asks the CDN, and the CDN says 403. Your content is perfect and unreachable. This is the layer underneath the one everyone talks about — and it's invisible in every tool you'd normally reach for. Two different kinds of "no" robots.txt is a note taped to the door. It says "please don't come in." A polite crawler reads it and turns around. A rude one ignores it and walks straight past. Either way, the note never touches your bytes — it's a request, enforced entirely by the visitor's own manners. A WAF or CDN rule is the door. It answers the request itself, at the edge, before anything reaches your origin: 403 Forbidden , 429 Too Many Requests , or a JavaScript challenge the bot can't solve. The HTML behind that door could be a masterpiece or a blank page. The bot sees neither. It sees the status code. People spend weeks perfecting the note and never check whether the door is locked. This isn't hypothetical — here's the data Cloudflare Radar publishes what actually happens to AI-crawler traffic across its network. From the AI Insights dashboard (7-day view, as of 18 July 2026): Of all HTTP responses served to AI bots and crawlers: 200 OK — 73.6% 403 Forbidden — 5.2% 429 Too Many Requests — 1.3% 503 — 1.1% AI-crawler response codes. Source: Cloudflare Radar, AI Insights, 7-day view, 18 Jul 2026. Read that again. More than one in fifteen requests from AI crawlers is being actively refused at the edge — 403 or 429 — before it ever touches the content. Not deprioritised. Refused. And most of that isn't a decision. It's a default — a managed WAF ruleset, a "block AI bots" toggle flipped in 2024, a

I Built a Crew of AI Agents That Review Code Like a Real Team — Then Watched Them Argue With SigNoz My submission for the Agents of SigNoz Hackathon (Track: AI & Agent Observability) The idea Most "AI code review" demos are one LLM call with a clever prompt. That's fine, but it doesn't reflect how review actually works on a real team — different people care about different things. Someone obsesses over edge cases. Someone else nitpicks naming. Someone else only cares if it's going to be slow in production. And then someone has to actually make the call on whether the PR merges. So I built that as a crew: a Logic Reviewer , a Style Reviewer , and a Performance Reviewer — three independent agents, each with a narrow system prompt that tells them to only look at their lane — followed by a Moderator agent that reads all three opinions and produces one final verdict, calling out disagreement when it happens. The interesting engineering problem wasn't the prompting. It was: once you have four chained LLM calls, how do you actually know what's happening inside your own system? Why observability, not just another agent demo Once I had the crew working, I had zero visibility into it. Four sequential API calls, each with its own latency and token cost, and all I had was print() statements. If the moderator gave a weird verdict, I had no fast way to tell whether the logic reviewer hallucinated an issue, or the moderator just summarized badly. If a run felt slow, I couldn't tell which of the four agents was the bottleneck. This is exactly the gap SigNoz is built for, so I instrumented every agent call with OpenTelemetry: Each specialist agent and the moderator run inside their own span ( agent.logic_reviewer , agent.style_reviewer , agent.performance_reviewer , agent.moderator ) All four are nested under one parent span, code_review_session , so a single review run shows up as one trace with four child spans Every span carries the attributes that actually matter for debugging a

Day 17. OCR on banking apps is unreliable. I built a verification layer that double-checks every number. Day 16 was a milestone: multi-app workflows. The agent copied my bank balance and sent it to Mom on WhatsApp. Three apps. One task. But behind that success was an uncomfortable truth: the agent misreads numbers about 20% of the time. For a message to Mom, that's a typo. For a financial transaction, that's a disaster. Today, I built the fix. The Problem Banking apps scored F on my accessibility audit. No UI labels. No content descriptions. The agent has to rely entirely on OCR to read anything on screen. And banking apps have terrible OCR conditions: Small, condensed fonts for account numbers and balances Low contrast (grey text on slightly darker grey backgrounds) Currency symbols (₦, $, £) that OCR often confuses with numbers Commas in large numbers that OCR sometimes reads as decimals The result? A balance of "₦15,000" sometimes gets read as "₦15.000" or "₦15,00" or "₦15000." One missing digit. One wrong decimal. And the entire task is compromised. The Fix: Numeric Verification Layer I built a verification step specifically for financial data. Before any number gets stored in task memory, it goes through three checks. Check 1: Format Validation The extracted text must match a valid currency format. It must contain a currency symbol (₦, $, £, €) followed by digits, optionally with commas and a decimal point. Anything that doesn't match this pattern is rejected immediately. Check 2: Double-Read Confirmation The agent reads the same number twice—two separate screenshots, two separate OCR passes. If both readings match exactly, the number is accepted. If they differ, the agent reads a third time. If two out of three match, that value wins. If all three differ, the task is aborted with an error message. Check 3: Range Validation The extracted number must fall within a reasonable range. A bank balance of "₦0" or "₦999,999,999,999" is probably an OCR error. The agent

Every patient in the public tour of my care platform is a computer science pioneer. Ada Lovelace has a pain score. Alan Turing is due for a check-in. And every one of them has a patient ID no real system could ever issue, an ID that is wrong the way a date in month thirteen is wrong. None of this is an accident. It is the most useful compliance idea I have had this year. A good fake is a liability Here is the problem with realistic demo data. Under HIPAA, nobody can tell a well-made fake from the real thing by looking. A screenshot of a fake patient named John Smith with a plausible ID looks exactly like a screenshot of a real one. So when that image turns up in a deck, or a tweet, or a forwarded email, someone has to prove it is clean. And the only way to prove it is to go back to the database and show the record does not exist. That is an audit. Every plausible fake carries a future audit inside it. So a good fake does not reduce your risk. It just moves it. The better the fake looks, the more it costs to prove it is one. The safety of a fake is not in how real it looks. It is in how obviously fake it is. A plausible fake needs an audit to clear it. An impossible fake clears itself. The fix is to stop making fakes plausible and start making them impossible. A patient named Grace Hopper with an ID that breaks the format on sight cannot be a real record. Anyone can check that from the pixels alone. No lookup, no audit trail, no meeting. Zero pixels The public showcase at clearpathcare.ai contains zero pixels from the production console. Every screen is a React recreation, rebuilt by hand to look like the product without ever touching it. What broke: An early draft of the marketing screens started as console screenshots with seeded test patients: realistic names, realistic IDs. Then I asked one question the images could not answer: prove there is no real record in this frame. I could not. So I deleted every screenshot and rebuilt the screens from scratch. The rebuilt

Every few weeks I hit the same wall: I have a 300 MB screen recording, and something on the other end wants it under 8 MB . Discord, an email attachment, a bug tracker, a form that silently rejects anything bigger. The usual advice is "just use HandBrake" or "run ffmpeg with a lower CRF." But CRF doesn't take a target size — it takes a quality knob . So you export, check the size, it's 11 MB, nudge the knob, export again, now it's 5 MB and looks like a potato, nudge back… It's a binary search you run by hand, one full encode per guess. The thing is, hitting an exact size isn't a guessing game at all. It's arithmetic you can do before you encode. I ended up wrapping that arithmetic into a little Rust CLI ( DeepShrink ), but the math is the interesting part, and almost nobody writes it down. So here it is. The one insight everything rests on File size is (roughly) bitrate × duration . A bitrate is bits per second. A duration is seconds. Multiply them and the seconds cancel, leaving bits — the size of the file. That's it. That's the whole trick. Normally you treat bitrate as the input and size as whatever falls out. Flip it around: fix the size, measure the duration, and solve for the bitrate. You know the duration (ffprobe will tell you), and you know the size you want (the platform's limit). The only unknown is the bitrate — and now it's a single division away. bitrate = size_in_bits / duration_in_seconds Everything below is just this equation with the real-world messiness added back in. Building the budget, step by step Say I want a 60-second clip to fit Discord's 8 MB limit. 1. Turn the target size into bits. Sizes are in bytes, bitrate is in bits, so multiply by 8. (I'll use 1 MB = 1,000,000 bytes here to keep the mental math clean; if your platform means mebibytes, same method, different constant.) target_bits = 8_000_000 bytes × 8 = 64_000_000 bits (64 Mbit) 2. Reserve a little for container overhead. An .mp4 isn't pure video and audio — there's a container, a m

I remember when coding interviews happened at a whiteboard, no computer, no internet, just a marker and whatever you could hold in your head. When AI tools arrived, using one in an interview was the red flag. Now the red flag is the candidate who doesn't use AI enough. In about two years, the same tool went from forbidden to expected. And it only gets faster. Every few months another wave rolls in, a model out of some lab, a tool that does something it couldn't last year, and it resets what counts as normal. You ride it, or you let it break over you. Plenty of people imagine a third option, waiting on the beach with their arms crossed until the water goes calm, but the water never goes calm, and it was never going to wait for them. all in I've decided to ride it, in the most literal way I have. All of my code is written by AI now (is it mine at this point?), and somewhere along the way I stopped treating that as a threat to be managed and started treating it as leverage to be spent. I know the engineers who went the other way, who made a personality out of dismissing the tools, and the tools got better anyway while they just fell further behind. Going all in wasn't one decision; it's one I make again every few weeks. A better model ships, and I rebuild a working agent on top of it instead of staying on the old version, because the result comes out better and cheaper. Relying on older models would have been easier, and most people do. Riding means doing that over and over, long after the novelty wears off. I get why people stop trying to keep up. The volume is genuinely insane, more launches in a week than you could try in a month, and it isn't only engineers feeling it now, it's anyone whose work runs on a keyboard. People are overwhelmed and often giving up. But you don't have to keep up with everything; you just can't ignore it all. keep the thinking It means handing a lot of work to AI, and I hand over more every month. It writes code, drafts the first version of

Capture the ringleader first. The rest will scatter on their own. — The 36 Stratagems, Capture the...

The original lawsuit was filed in 2023 and claimed Twitter hosted thousands of cases of copyright infringement.

Now, if you want to, you can use Google's 3D emoji in your own creations. The company shared some details about how it went about designing the little pictograms and why, as part of World Emoji Day on Friday. Things you might not necessarily worry about in a 2D illustration suddenly become very important when […]

Th Honda Prologue will no longer be sold in the U.S., joining a growing list of EV models to exit the market this year.

The Department of Justice says that federal employees can now download TikTok on their government devices.

There is a note in my runbooks that says the Enter key works. That is almost the whole note. Press Enter and the prompt submits. I wrote it in bold, with sources and a date, because one of my AI agents once fixed the Enter key. The fix was the bug. The Fix Was the Bug I run a fleet of Claude Code agents in tmux panes. An orchestrator script types a prompt into a pane and presses Enter for it. One day an agent decided the submissions were not going through, and it knew the fix: send a backslash before the Enter. That sounds plausible if you have ever fought a terminal. It is also exactly backwards. In Claude Code, backslash plus Enter inserts a newline. It is the multiline key. So the fix turned every prompt into a draft that quietly grew longer and never sent. The panes looked busy. Nothing was happening. The submissions had been fine all along. The agent just had not waited for the reply. What broke: An agent changed Enter to backslash-Enter to repair prompt submission. Backslash-Enter creates a newline, so the repair silently stopped every prompt from sending. The system it fixed had never been broken. There is a second note in the same genre. My monitoring dashboard answers its health check with a 302 redirect to the login page. That is what healthy looks like there. But a 302 looks like trouble if you are hunting for outages, and agents kept trying to repair it. So the runbook now says, more or less: the redirect is normal, do not fix the healthy system. Human teams do not write notes like these. Nobody pins "the Enter key works" to the wall of an office. A New Hire Every Session Why did I have to? Because a human hits a dead end once. The wince is the documentation. Whoever broke a build by fixing the Enter key would remember it for years, tell the story at lunch, and the whole team would absorb it without anyone writing a word. An agent has none of that. It has no episodic memory. Every fresh context window is a new hire: smart, fast, and seeing your system fo

Recap. Part 1 framed the supervision problem. Part 2 architected the four-model system on AWS and counted the hardware. Part 3 put the gate on the page in fifteen lines of PyTorch. Now the question that decides whether any of it mattered: does the gate actually earn its keep - and what would it cost to know? This is the close. A verification design, the stability instrumentation that separates a real evaluation from a lucky one, and the FinOps reality that is the reason this whole series is a blueprint instead of a benchmark. SDAR makes two claims, not one It's tempting to reduce the paper to a single number. The reported gains over plain GRPO are real and worth stating - their numbers, not mine : roughly +9.4% on ALFWorld, +7.0% on Search-QA, +10.2% on WebShop accuracy. But the headline percentage is the less interesting claim. The one that matters is the second: SDAR avoids the training instability that naive GRPO+OPSD falls into . The whole point of the gate Part 3 was to keep the teacher's noisy rejections from destabilizing training. So a verification that only measures final task success has tested half the paper. You have to measure stability too - and most reproductions don't. That two-pronged claim dictates the experiment. The verification: three arms, not two You cannot prove SDAR's thesis with a before/after. You need three training runs, identical except for the supervision: Arm What it is What it proves A. GRPO Plain agentic RL, no teacher The baseline the +9.4% is measured against B. Naive GRPO+OPSD Teacher distillation, no gate The instability SDAR claims to fix C. SDAR Gated distillation Part 3 Beats A on score and beats B on stability Drop arm B and you can show SDAR beats GRPO, but you've quietly deleted the paper's actual contribution - there's no evidence the gate did anything a plain teacher wouldn't. Arm B is the expensive arm nobody wants to run and the one that makes the result credible. Metrics that actually test the claim Metric What it mea

I’ve read the word “encrypted” on more apps than I can count, and most of the time it tells you almost nothing. Here’s what it really means, the way I’d explain it to a friend. Every app you use will tell you your data is encrypted. It’s on the login screen, the pricing page, the little padlock in the corner of the browser. And because it’s on everything, it’s stopped meaning much. I’ve spent more time on that one word than I’d care to admit, building a notes app where it actually has to be true, so here’s how I think about it. No maths. No padlock pictures. Underneath, encryption is an old and simple idea. You take a message, turn it into nonsense nobody can read, and make sure only the right person can turn it back. That’s the lot. Everything after that is detail about how good the nonsense is, and who’s allowed to undo it. The whole thing in one sentence Encryption takes something readable and mixes it into a mess that means nothing on its own. A matching key turns the mess back into the original. No key, and the mess stays a mess. The readable version is called plain-text. The mixed version is called cipher-text. That’s the entire vocabulary you need to know. Encryption turns plain-text into cipher-text, decryption is turning it back. A note is just text until you scramble it Say you’ve got a note on your phone, “dentist Thursday, 3pm”. Stored as it is, anyone who gets at the file reads it straight off. A thief with your unlocked phone. An app you handed too many permissions to. A company keeping a copy on its servers. All of them see “dentist Thursday, 3pm”. Encrypt it and that same note might sit on the disk as 9f2ac1b0e7..., a run of characters that means nothing. The appointment is still in there, in the sense that the right key brings it back, but on its own it tells a snoop nothing. Not the time, not the day, not that it was ever about a dentist. People reach for a padlock to explain this and I’ve never liked it. A padlock just stops you getting to the thi

Every engineer eventually hits this phase: “My design looks okay… but something feels off.” No compile errors. No obvious bugs. But still: responsibilities feel scattered services feel too big entities feel too thin logic feels duplicated boundaries feel unclear This is normal. Because domain modeling is not about getting it right in one attempt. It is about refining structure until the business behavior becomes clear. Step 1 — Start With the Symptom, Not the Code If your design feels wrong, don’t immediately rewrite everything. First identify the symptom: Common symptoms: too many “Manager” services logic repeated in multiple places unclear ownership of rules too many dependencies between modules frequent “if-else explosion” Each symptom points to a specific modeling issue. Step 2 — Check If Invariants Are Scattered Ask: “Where are my business rules living?” Bad sign: Rules inside services + controllers + helpers This leads to: inconsistent behavior duplicated validation broken business guarantees Good design: invariants live close to the entity or aggregate root Step 3 — Check Entity vs Service Confusion A very common issue: Entities become dumb: only fields no behavior Services become overloaded: all logic all rules all decisions This creates: Anemic Domain Model + Fat Services Fix mindset: Entity = owns behavior + protects state Service = coordinates workflows Step 4 — Check Your Aggregate Boundaries Ask: “What must stay consistent together?” If your answer is unclear, you likely have: wrong aggregates or missing aggregates Example problem: Cart and Order sharing logic This causes: inconsistent pricing unclear lifecycle ownership Fix: Cart = intent Order = truth Step 5 — Look for “Hidden Coupling” Hidden coupling happens when: one module depends on internal state of another multiple services modify same data business rules are duplicated across boundaries This leads to fragile systems. Strong design ensures: each domain owns its own truth. Step 6 — Validate Stat

Most A/B testing happens in the browser: a script swaps a headline or button color after the page loads. That works for surface-level UI changes, but it cannot test the logic that runs before a page is ever rendered — a pricing algorithm, a search ranking model, a checkout flow, or a backend API response. Server-side A/B testing moves the experiment decision into your application code, where you control the full request lifecycle. This guide explains when to test server-side, how it differs from client-side testing, and how to implement it with Optimizely Feature Experimentation, including working SDK code for Node.js and Python. What Server-Side A/B Testing Is In a server-side A/B test, your application server decides which variation a user sees and renders the response accordingly. Instead of shipping the control experience and patching it in the browser, the server already knows the assignment by the time it builds the HTML, the JSON payload, or the rendered component. The decision is deterministic: a given user ID is consistently bucketed into the same variation, so the experience stays stable across requests and devices. Your code branches on that assignment, serves the corresponding experience, and reports a conversion event when the user does something that matters — a purchase, a signup, a search that returns a click. This is the model Optimizely calls Feature Experimentation . If you have used Optimizely before, you may know this product by its former name, Full Stack — the SDKs, datafile, and decision model are the same lineage, now under the Feature Experimentation name. Searchers still look for "Optimizely full stack," but the current product and documentation use Feature Experimentation. When to Test Server-Side Server-side testing is the right tool when the thing you are changing is not a cosmetic, post-render tweak. Reach for it in these situations: Backend logic and algorithms. Recommendation engines, search ranking, fraud scoring, feed ordering, and