AI 资讯

Your teachable AI intern for everyday browser work Discussion | Link

GitHub announced agentic autofix for code scanning alerts in public preview on July 10, 2026. Primary source: GitHub Changelog, July 10, 2026 . The wrong metric is “percentage of alerts with a generated patch.” Generation is only the first transition: alert -> candidate -> build -> tests -> security oracle -> human review -> merge -> post-merge observation This is an evaluation proposal, not a benchmark or assessment of GitHub's preview. Choose a bounded canary Start with repositories that have active owners, deterministic builds, relevant isolated tests, reversible releases, and no automatic production deployment from candidate patches. Exclude abandoned code, safety-critical paths, and repositories with unreliable tests. Assign the canary deterministically—for example, hash a stable alert ID into a fixed percentage. Do not move difficult results out of the cohort after seeing them. Record every attempt, including abstentions and failures: attempt_id : " <id>" alert_class : " <normalized class>" base_revision : " <commit>" outcome : generated : true applied_cleanly : true build_passed : true tests_passed : false security_oracle_passed : false human_decision : " rejected" failure_class : " semantic_incomplete" escaped_to_default_branch : false The schema is local evaluation metadata; it does not imply that GitHub exposes these fields. Classify the earliest broken invariant Class Meaning No candidate Tool abstained Scope violation Unrelated or forbidden paths changed Apply failure Patch does not apply to recorded base Build failure Patched revision cannot build Regression Existing behavior broke Semantic incomplete Alert changed but security property remains broken Overcorrection Valid behavior was blocked Test manipulation Validation was weakened or removed Stale base Result targeted another revision Review ambiguity Human cannot establish why the patch is safe Infrastructure Evaluation could not complete Post-merge escape Later evidence disproved acceptance Use one

GitHub announced on July 14, 2026 that security reviews are available in the GitHub Copilot app. Primary source: GitHub Changelog, July 14, 2026 . The meaningful research question is not whether people click Accept. It is whether they can build an evidence-backed decision when guidance is useful, incomplete, or wrong. understand change -> inspect evidence -> challenge findings -> verify uncertainty -> accept, reject, or escalate This is a proposed research protocol, not a completed study. It does not invent product fields or report findings. Build scenario cards scenario_id : " SR-03" repository_type : " synthetic" seeded_conditions : - " one relevant issue" - " one plausible but irrelevant concern" - " one important omission" participant_goal : " ready, blocked, or escalate" success_evidence : - " decision cites inspected code" - " unsupported claim is challenged" - " unresolved uncertainty is recorded" stop_conditions : - " real credentials appear" - " a live repository could be modified" - " participant mistakes study output for production approval" Vary the seeded mix so participants cannot learn that every scenario contains exactly one true and one false finding. Establish ground truth independently before sessions. Recruit people who hold different review responsibilities: routine reviewers, maintainers, security specialists, less-experienced reviewers, and people using keyboard navigation or assistive technology. Do not collapse every group into one average. Require a decision record Decision: ready | blocked | escalate Evidence inspected: - file and relevant lines - test or documentation Guidance accepted: - claim and evidence Guidance rejected: - claim and reason Unresolved: - question and next owner Spoken confidence is not the outcome. This artifact exposes whether acceptance connects to evidence. Measure relevant issues identified, unsupported claims challenged, evidence references, correct escalation, time, and confidence before and after inspection. No

GitHub announced on July 8, 2026 that GitHub Mobile can start a Copilot cloud-agent workflow to fix pull-request merge conflicts. Primary source: GitHub Changelog, July 8, 2026 . The unsafe mental model is “tap once and the conflict is solved.” A safer model is: mobile intent -> bounded remote task -> proposed patch -> verification -> human merge This is a source-based checklist, not a hands-on product assessment. Exact controls and permissions must come from current GitHub documentation. Record the handoff repository : " owner/project" pull_request : 123 base_branch : " main" expected_base_sha : " <commit>" expected_head_sha : " <commit>" allowed_scope : - " src/example/**" - " tests/example/**" forbidden_scope : - " .github/workflows/**" - " deployment/**" required_checks : - " unit-tests" reviewer : " <responsible human>" expires_at : " <UTC timestamp>" This operator artifact is not a representation of the mobile UI. It preserves intent across interruptions, network changes, and the delay between delegation and review. Before handoff, confirm repository, pull request, branches, expected files, sensitive paths, required checks, and the person responsible for merge. Never place secrets, customer data, or private incident details in the instruction. A bounded instruction is better than “make CI green”: Resolve conflicts between the recorded base and head revisions. Preserve documented behavior, limit changes to the listed paths, do not modify workflow or deployment configuration, and return a patch without merging. Verify the returned revision the result belongs to the expected repository and pull request; base and head revisions still match the handoff; every changed file is expected or explained; no conflict markers remain; no workflow, ownership, deployment, or policy file changed unexpectedly; tests ran against the exact reviewed commit; tests were not weakened or removed; a human can explain the semantic choice made for each conflict; the reviewed commit is the

GitHub announced on July 14, 2026 that Copilot for JetBrains expanded bring-your-own-key capabilities. Primary source: GitHub Changelog, July 14, 2026 . Provider and model selection looks like two dropdowns, but behaves like one dependent workflow: credential context -> provider -> compatible models -> confirmed session This is a proposed accessibility test plan, not a hands-on review. It does not claim that the current product has an accessibility defect. Test outcomes, not widget assumptions A keyboard or screen-reader user should be able to reach the provider control, discover its name and current value, inspect options, commit or cancel, understand that model choices changed, and select a compatible model without losing context. Use this matrix: Case Action Keyboard expectation Screen-reader expectation State expectation P1 Reach provider Visible focus Name, role, value No change P2 Open options Documented key works Expanded state is clear Existing value retained P3 Browse providers No focus escape Option and selection announced Browsing does not commit P4 Select provider Pointer not required New value announced once Model refresh begins M1 Reach model after refresh Focus not stolen Availability communicated Options match provider M2 Search models Keys do not conflict Query and result are clear Search does not select R1 Change provider later No trap Invalidated model explained Stale pair cannot submit E1 Loading fails Retry/cancel reachable Error and next action announced Last valid state is clear The matrix separates interaction, announcement, and state correctness. A control can pass one and fail another. Record the environment ide : " <product and exact version>" plugin : " GitHub Copilot <exact version>" os : " <name and version>" assistive_technology : " <name and version>" keymap : " <default or named alternative>" initial_state : " <unconfigured or existing selection>" Vary one versus many providers, short versus long model names, loaded/loading/empty/err

GitHub's July 13, 2026 changelog lists REST API management for secret scanning custom patterns. That makes a reviewed configuration-as-code workflow possible. Primary source: GitHub Changelog archive, July 2026 . Follow the July 13 entry to the current REST documentation before implementation. The transport below is an unexecuted design. Endpoint paths, payload fields, permissions, pagination, and plan availability must come from the linked official API reference—not from guessed examples. Define the sync contract A safe synchronizer should: read desired patterns from version control; fetch the remote collection; match each pattern by a stable identity; emit create, update, unchanged, and delete actions; refuse deletion unless explicitly enabled; apply only after the plan is reviewed. patterns.json -> normalize -> diff remote -> plan.json -> approval -> apply Keep API-specific payloads opaque to the diff engine: { "patterns" : [ { "stableKey" : "internal-service-token-v1" , "remoteId" : "SET_AFTER_CREATION" , "payload" : { "REPLACE_WITH_DOCUMENTED_FIELD" : "REPLACE_WITH_REVIEWED_VALUE" } } ], "allowDelete" : false } Placeholders are deliberate. A secret detector's regex fields and matching semantics are security contracts and should never be invented from a blog post. Build a deterministic planner export function plan ( desired , current ) { const remote = new Map ( current . map ( x => [ x . id , x ])); const changes = []; for ( const item of desired . patterns ) { if ( ! item . remoteId ) { changes . push ({ action : " create " , key : item . stableKey }); continue ; } const found = remote . get ( item . remoteId ); if ( ! found ) throw new Error ( `Missing remote pattern ${ item . remoteId } ` ); const same = JSON . stringify ( canonical ( found )) === JSON . stringify ( canonical ( item . payload )); changes . push ({ action : same ? " unchanged " : " update " , key : item . stableKey }); remote . delete ( item . remoteId ); } for ( const orphan of remote . valu

GitHub announced on July 14, 2026 that Dependabot now waits until a release has been available on its registry for at least three days before opening a version-update pull request. The cooldown is the new default and requires no configuration. Primary source: GitHub Changelog, July 14, 2026 . The product question is not whether three days is universally safer. Waiting may expose a broken or compromised release before adoption, but it can also postpone a needed compatibility fix. Cooldown is a baseline, not a complete dependency policy. Separate normal freshness from security response release -> cooldown -> update PR -> CI -> review -> deploy -> observe A cooldown does not replace lockfiles, CI, provenance checks, staged deployment, or rollback. It should not silently delay an urgent security-update workflow either. Use this decision table before creating exceptions: Package situation Suggested decision Compensating control Routine dev dependency with strong CI Keep default Deterministic tests Runtime package on a critical path Keep or lengthen Canary and fast rollback Identified security remediation Use the dedicated urgent path Security owner and targeted tests Isolated build-only tool Consider shorter Reproducible artifact checks Volatile pre-1.0 package Consider longer Manual release review Internal package released with the app Consider exception Exact-version integration test Parser, auth, crypto, or installer Keep default unless urgency wins Sandbox and abuse fixtures Score the exception Rate each dimension from 1 to 5: blast radius; upstream release volatility; test strength; rollback speed; cost of waiting. Then use two conversation scores: wait_value = blast_radius + release_volatility ship_confidence = test_strength + rollback_speed + cost_of_waiting This is not a statistical risk model. It forces the team to name evidence. Keep the default when scores are close. Consider shortening only when delivery evidence clearly exceeds wait value. Route vulnerabilit

GitHub announced on July 2, 2026 that Issue fields are generally available, including integration with GitHub's MCP server. Primary source: GitHub Changelog, July 2, 2026 . That creates a useful beginner project: validate structured issue metadata before an MCP client—or any program—uses it. The schema below is invented for learning. It is not GitHub's API schema. Define three fields // schema.mjs export const schema = { priority : { kind : " singleSelect " , required : true , options : [ " P0 " , " P1 " , " P2 " , " P3 " ] }, estimate : { kind : " number " , required : false , min : 0 , max : 100 }, customerImpact : { kind : " text " , required : false , maxLength : 120 } }; A schema describes both type and domain rules. estimate must be a number, but it also has to fit the range this project accepts. Validate at the boundary // validate.mjs import { schema } from " ./schema.mjs " ; export function validate ( input ) { const errors = []; if ( ! input || Array . isArray ( input ) || typeof input !== " object " ) { return [ " fields must be an object " ]; } for ( const [ name , rule ] of Object . entries ( schema )) { if ( rule . required && ! ( name in input )) errors . push ( ` ${ name } : missing` ); } for ( const [ name , value ] of Object . entries ( input )) { const rule = schema [ name ]; if ( ! rule ) { errors . push ( ` ${ name } : unknown field` ); continue ; } if ( rule . kind === " singleSelect " && ( typeof value !== " string " || ! rule . options . includes ( value ))) { errors . push ( ` ${ name } : expected ${ rule . options . join ( " , " )} ` ); } if ( rule . kind === " number " && ( typeof value !== " number " || ! Number . isFinite ( value ) || value < rule . min || value > rule . max )) { errors . push ( ` ${ name } : expected ${ rule . min } .. ${ rule . max } ` ); } if ( rule . kind === " text " && ( typeof value !== " string " || value . length > rule . maxLength )) { errors . push ( ` ${ name } : expected at most ${ rule . maxLength } charact

GitHub announced on July 10, 2026 that CodeQL 2.26.0 adds AI prompt-injection detection. Enabling a query is useful; owning a regression test is better. Primary source: GitHub Changelog, July 10, 2026 . The examples below are implementation templates, not results from a repository I tested. Model a path, not a phrase A useful fixture contains an untrusted source, prompt construction, and a model sink: security-fixtures/prompt-injection/ ├── positive/direct-flow.ts ├── positive/helper-flow.ts ├── negative/trusted-instruction.ts └── expected-alerts.json Do not test for the literal phrase ignore previous instructions . Static analysis needs a data-flow path. Preserve a supported SDK call from your production stack so CodeQL can recognize the sink. // Intentionally vulnerable fixture. Never ship this path. import { model } from " ./supported-client " ; declare function loadIssueBody ( id : number ): Promise < string > ; export async function summarize ( id : number ) { const untrusted = await loadIssueBody ( id ); return model . generate ({ system : " Summarize the issue " , user : untrusted , }); } Add a second positive case that passes the value through a helper. Then add a negative control where attacker input cannot select or alter the instruction. A function named sanitize() is not evidence of sanitization. Assert SARIF evidence Uploading SARIF alone does not create a regression gate. Commit the expected rule and fixture location: { "required" : [ { "ruleId" : "REPLACE_WITH_DOCUMENTED_RULE_ID" , "pathSuffix" : "positive/direct-flow.ts" } ], "forbiddenPathSuffixes" : [ "negative/trusted-instruction.ts" ] } Keep the rule ID as a placeholder until it is copied from the CodeQL 2.26.0 documentation or an observed SARIF result. Machine-facing identifiers should never be guessed. A small assertion can compare runs[].results[].ruleId and each physical location against this file. Fail when a required alert disappears or a negative fixture starts alerting. Do not assert the

Syntetica, a French startup that has developed a novel approach to recycling nylon, has already obtained big-name partners and investors.

Applied Computing has raised a $20M Series A to build a foundation AI model for the oil, gas and petrochemical industry.

Last week an AI-generated GPU kernel ran 18.71× faster than an optimized PyTorch baseline. The model—Fable 5—didn't just edge past the human implementation. It lapped it. Claude Opus 4.8 reached 14.4×. GLM-5.2 hit 11.14×. GPT-5.5 managed 4.34×. Fable's kernel was in a different tier entirely. The exciting read: AI is starting to improve the low-level machinery that makes AI itself cheaper and faster. Specialized performance work that once required rare expertise just got dramatically easier to explore. The uncomfortable read: what happens when the best implementation is also the one nobody on your team would have written—or can fully explain? That question is about to land on every engineering team that ships AI-generated code. The Benchmark Problem A benchmark shows the kernel ran fast under tested conditions. It doesn't show: How it behaves across different GPU hardware How it handles numerical edge cases What happens under months of production changes Whether it degrades gracefully when inputs shift The person who wrote it can't answer these questions either. The AI generated this code through a process that doesn't leave a reviewable chain of reasoning. There's no commit message that says "I chose this approach because X." So the reviewer's job just got harder—not easier. The Real Shift I've been watching this pattern across engineering teams this year. The argument is moving from "can AI generate working code?" to "can our org absorb generated code without breaking quality, morale, or judgment?" The GPU kernel story makes the tension concrete: One side says the code ran, it was measured, it won. Stop moving the goalposts. The other side says somebody still has to know where it can fail and take responsibility when it does. Both are right. AI can make implementation cheaper while making proof more expensive. Senior engineers may write less code but spend more time designing adversarial tests, checking assumptions, planning rollbacks, and deciding whether an impr

We open-sourced Tanso Core: a self-hosted monetization engine for B2B AI products. Usage metering, prepaid credits, entitlements, and Stripe billing in one Spring Boot service, with one property the rest of the stack doesn't have. Every metered event carries its cost. Repo: https://github.com/tansohq/tanso-oss The gap If you sell an AI product today, your monetization stack is split across two categories of tools that don't talk to each other. Billing platforms meter usage and generate invoices, but they have no idea what your inference costs. They can tell you a customer consumed 40,000 events. They cannot tell you whether you made money on them. LLM observability tools know your costs down to the token, but they don't bill anyone. They can tell you a feature costs $0.038 per run. They cannot connect that to what the customer paid for it. So margin per customer, the number that decides whether your pricing works, lives in neither system. Most teams reconstruct it in a spreadsheet, quarterly, if at all. Tanso keeps both sides in one ledger. Every event you ingest records what you billed and what it cost you: input and output tokens, model, provider. Margin per customer, per feature, per model is a query, not a project. What it allows Enforcement at ingestion, not at invoice time. Entitlement checks, usage caps, and credit limits are applied when the event comes in. If a customer is out of credits, the check fails now, not on a reconciliation job three weeks later. For AI products, where a runaway integration can burn real money in an afternoon, this is the difference between a limit and a suggestion. Credits as a first-class primitive. Prepaid credit pools per customer, with grants, deductions, expirations, and full transaction history. Most AI products end up selling some form of prepaid usage. Bolting that onto a subscription-shaped billing system is painful; here it's the core model. Stripe as a payment adapter, not the source of truth. Billing state lives in Tan

Part 2 of a series on building a production banking AI chatbot. By the time the classifier and the semantic cache were both live, I genuinely thought the hard part was behind us. Routing was fast. Caching worked. The demo looked clean. Then the AI team asked me a question that sounded almost administrative. AI Lead: "Can you send over the loan policy PDFs? We need to load them into the knowledge base." "Sure," I said. "Give me an hour." That hour turned into three weeks. Chapter 1 — The PDF That Broke Everything The first document I opened was a loan eligibility policy. Twelve pages. Looked simple enough on screen — headings, a couple of tables, some fine print at the bottom of each page. I ran it through a basic PDF-to-text extractor, the kind that takes minutes to wire up. Skimmed the output. It was garbage. Not wrong garbage — worse. It was confidently wrong. Two columns of a table had been extracted side by side into one long, meaningless sentence. A header that said "Eligibility Criteria" had merged directly into the paragraph below it with no space, so it read Eligibility Criteriaapplicants must be . Numbers from a rate table were scattered through the text with no column headers attached, so a 7.2% interest rate sat next to a completely unrelated clause with nothing telling the retriever they weren't related. Me, in the team channel: "Uh. Has anyone actually looked at what comes out the other side of PDF extraction?" AI Lead: "...No. Why?" I sent a screenshot. Nobody replied for a while. A PDF looks like a document to a human because a human's eyes fill in the layout — the columns, the spacing, which number belongs to which row. To a naive extractor, a PDF is just characters scattered across a page with x-y coordinates. It has no idea "5.5%" and "Senior Citizen FD" are supposed to be read together. It just knows they happened to be near each other on page 4. If the extraction was garbage, everything built on top of it — chunking, embeddings, retrieval — was g

Part 1 of "Multi-Agent Systems in Production: What They Don't Tell You" — a four-part series...