标签：#code

There is a habit I have for other people's libraries that I do not have for my own code: before I call something, I read what it returns. With my own functions I skip that, because I wrote them, so I know. Three times in three days that turned out to be false, and the third time I caught it before it cost anything only because I had started treating my own modules like somebody else's. The version I had already been burned by twice I maintain qbofile , a set of browser-based converters between the file formats accounting software uses. It is a small codebase: a parser per input format, a generator per output format, and pages that wire one to the other. Wiring a new pair felt like plumbing, so I estimated it like plumbing. Two new pages, both reusing an existing parser and an existing generator: no new code. I said that out loud before opening either end. The generator had no column for the thing the parser produced. The parser could read the category a user had assigned to each transaction; the CSV generator emitted six fixed columns and category was not one of them. Not a bug — it had simply never needed one, because the format it was originally written for does not carry categories. That is a strange kind of wrong. Nothing was broken. The code did exactly what it always had. My model of it was built from the function name. The same evening, in the same pair of modules, the second one: L . push ( `P ${ sanitizeText ( tx . description )} ` ); P is the payee field in that output format. M is the memo. Two fields, and upstream, description was defined as memo || payee . So for any transaction that had a memo, the memo took the payee slot and the actual payee was dropped. Silently — the file is valid, it imports fine, and the missing name never announces itself. The two minutes that caught the third one After the second one I wrote down a rule and did not really believe I needed it: before wiring two components together, open both ends and read what actually crosses.

Your monthly Claude Code bill went up 20%. You know that much. What you don't know is which Skill did it — and nothing in the tooling will tell you. Run /usage in Claude Code and you get claude-sonnet-4-6: ¥3,240 — a per-model total and nothing else . "More expensive than last week" is visible. "Which Skill caused it" is not. usage-breakdown.sh closes that gap. It's a 106-line shell script that parses transcript.jsonl with Python and tallies call counts per Skill, Agent, and MCP server using Counter . This article walks through how the script works and how to run it, with the actual code and actual numbers. Why This Approach Works What Claude Code Is Actually Recording Claude Code streams every operation during a session into .jsonl files under ~/.claude/projects/ . It's JSONL — one event per line, one file per session. The files sit under a <project-id>/ directory. The skeleton of a single record looks like this: { "message" : { "role" : "assistant" , "content" : [ { "type" : "tool_use" , "name" : "Skill" , "input" : { "skill" : "pre-completion-self-audit" } } ] } } Inside message.content[] sit "type": "tool_use" blocks. The name field is the name of the tool that was invoked. The Bash tool, the Edit tool, the Skill tool, the Agent tool, MCP calls — all of it is recorded in this same format. Once I noticed that, the thought was: run this through a Counter and everything becomes visible. For the Skill tool, the skill name lives in input.skill ; for the Agent tool it's input.subagent_type ; and for MCP servers, the tool-name convention mcp__<server>__<tool> lets you extract the server name by splitting on __ . The structure is consistent, so the parser comes out surprisingly simple. What /usage Doesn't Tell You What Claude Code's /usage command outputs is a per-model cost total for a period. Model Cost claude-sonnet-4-6 ¥3,240 claude-opus-4-8 ¥ 892 Useful as far as it goes, but the breakdown of that cost is invisible . You can't see which session, which Skill, how ma

You've written it a hundred times. In your CLAUDE.md , in your system prompt, in ALL CAPS: NEVER put "use client" at the page level. NEVER commit @ts-ignore without a reason. And your agent does it anyway. Not always — that would almost be easier to deal with. It follows the rule for the first 50k tokens, then quietly stops. Or Sonnet follows it and Haiku doesn't. Or it follows nine rules and forgets the tenth. Here's the thing I finally accepted: a rule in a prompt is a request. The model can decline it. So I stopped asking, and started enforcing. TL;DR Prompt adherence is probabilistic. It degrades with context length and with model size. But half of my coding rules never needed a model at all — they're grep-able. Claude Code hooks + exit 2 turn those rules into a deterministic reviewer that runs after every single edit , costs zero tokens when nothing is wrong , and fires at 100% regardless of which model wrote the code. Once the mechanical rules are enforced from below, you can safely downgrade the model doing the typing. That's the real payoff. Everything below ships in ccteams v0.3.0 , but the pattern takes 30 minutes to build yourself. Two kinds of rules Some background in three lines: I run Claude Code with orchestrated agent teams — a builder writes code, a reviewer verifies it, and both get a stack-specific "playbook" of rules distilled from the mistakes mid-tier models actually make. It works well. I wrote about the prompt-engineering side of it before. But rereading my playbooks, I noticed the rules split cleanly into two categories. Rules that need judgment: Trace the Server/Client boundary by hand. Don't write a fix until you can state the root cause. These need a model. Prompts are the right place for them. Rules that are just string matching: "use client" at the top of app/**/page.tsx → wrong. process.env.SECRET in a client file → wrong. @ts-ignore with no justification → wrong. Why was I asking a language model to remember these? A regex doesn't get

OpenAI's Codex CLI is a genuinely good coding agent, but out of the box it runs OpenAI models on OpenAI billing. Sometimes you want Claude Opus for a gnarly refactor, Kimi K2.7 Code for cheap long sessions, or a model served from EU infrastructure because your client asks where tokens go. What most people miss: Codex has custom providers built in. It speaks the Responses API to whatever base_url you give it, so any gateway that implements the Responses API can act as the router behind Codex. No forks, no proxies, one config block. Option 1: the config block Codex reads ~/.codex/config.toml . Add a provider and a profile: [model_providers.opper] name = "Opper" base_url = "https://api.opper.ai/v3/compat" env_key = "OPPER_API_KEY" wire_api = "responses" [profiles.opus] model = "anthropic/claude-opus-4-7" model_provider = "opper" [profiles.kimi] model = "moonshot/kimi-k3" model_provider = "opper" I'm using Opper here (disclosure: I work there), an EU-hosted gateway with 700+ models behind one API key that implements the Responses API. Export the key and launch with a profile: export OPPER_API_KEY = "your-key" codex --profile opus That's the whole router. Yes, that means Claude running inside OpenAI's own CLI, which never stops being funny. Option 2: one command If you don't want to touch config files, the Opper CLI writes exactly that block for you (with sentinel markers, so it never clobbers your existing config and can cleanly remove itself): npm install -g @opperai/cli opper launch codex It detects Codex (installs it with --install if missing), configures the provider, and starts it with preset profiles. opper launch codex --model moonshot/kimi-k3 picks a model at launch. Which models actually make sense in Codex openai/gpt-5.3-codex : the model Codex was built for, via API billing. Honest note: if you already have a ChatGPT plan, Codex is included there and that's the cheaper path for this one model. The router play is for everything else. anthropic/claude-opus-4-7

If you need a free AI app builder with backend to get a FastAPI microservice running today, you can do it with a handful of platforms that bundle hosting, a database, and auth for zero cost. The catch is that the free tiers have hard limits, and they expose the same failure modes you’ll hit in production if you’re not careful. Below I walk through the exact steps, show the code that works, compare the popular builders, and explain how to transition to a production-grade stack when the free tier starts to choke. What free AI app builder platforms include backend services? The short answer is: Cursor , Bolt , and Lovable all ship with a “one-click deploy” that creates a container, wires up a PostgreSQL instance, and adds optional OAuth. They are marketed as “no-code AI app builders,” but you can drop in any Dockerfile – including one that runs FastAPI – and they’ll handle the rest. Platform Backend offering Free tier limits Auth support Cursor Managed container + Postgres 13 500 MB RAM, 1 CPU, 100 k requests/mo Google, GitHub, email Bolt Container + SQLite (upgrade to Postgres) 256 MB RAM, 0.5 CPU, 50 k requests/mo Magic link, JWT Lovable Container + MySQL 5.7 300 MB RAM, 1 CPU, 75 k requests/mo Email/password, OAuth All three let you push a Git repo and they rebuild automatically. That’s the “free AI app builder with backend” you’re after – you get a place to run your FastAPI code without paying for a VM. How do I build a FastAPI AI microservice and deploy it with a free builder? The first thing most builders break on is the cold-start latency of a Python container that pulls a large model at import time. I’ve been bitten by this on Cursor: the first request took 30 seconds, then timed out because the free tier caps request time at 15 seconds. The fix is to load the model lazily or move it to a separate worker. Below is a minimal FastAPI app that calls Claude via the anthropic SDK. The code fits in a 30-line file and works on any of the three platforms. # main.py fro

I started this investigation after finding a local OpenCode project that appeared to remember guidance across sessions. The guidance lived in Markdown files outside the repository, yet every new session followed it. The operational question was simple: had OpenCode decided to preserve those facts, or had someone explicitly written them? The session record answered it. An agent had created the files through an ordinary file tool after an explicit user request. A project-local instructions configuration then loaded them on every provider turn. What looked like autonomous memory was user-triggered file authoring plus deterministic prompt injection. That result sent me looking for the actual memory subsystem. There is no general runtime-managed service that decides what to save, updates facts when they change, and semantically retrieves useful knowledge in later sessions. What users experience as "memory" is produced by three different mechanisms with different owners and failure modes: instruction files are loaded into the system prompt, durable session events and projected messages are persisted in SQLite, and old model-visible context is replaced by a generated compaction checkpoint when the request grows too large. These mechanisms work together, but they do not form an autonomous long-term memory manager. That distinction matters. If a coding agent remembers a project rule because AGENTS.md is injected on every turn, that is not learned memory. If it can reopen an old transcript from SQLite, that does not mean a new session can retrieve facts from it. If a long session survives by summarizing its history, that does not mean the runtime selected the most important information. This article follows the current OpenCode source tree, which contains both the desktop-compatible session path under packages/opencode and the newer V2 runtime under packages/core . Where the two paths differ, I call out the difference rather than treating them as one implementation. Primary c

Building a mobile app still feels more complicated than it should. You can have an idea in five...

Going from a $700/month student side hustle to a real business in six months came down to one thing: I stopped instructing Claude and started letting it run the whole environment autonomously. That environment then spent 52 days writing 2,340 log rows where every single cost was zero — and it never once complained. Why This Setup Works Most people who start with Claude Code use it as a convenient chat AI. But once monthly revenue crosses a certain threshold, your thinking shifts. Instead of "issuing instructions and getting output," you move to "letting the whole environment run itself." Here's the concrete difference. In the first mode, you type a prompt every time and get a result back. In the second, hooks fire while you sleep, scripts execute, and logs accumulate. In my case, there are a dozen-odd jobs running on a schedule via launchd, and a Claude Code Stop hook that fires at the end of every session. I wake up to yesterday's brief sitting on my Desktop, and a record in ~/.claude/metrics/costs.jsonl of how many tokens each session consumed — that was the ideal, anyway. Why track cost at all? Claude Code's MAX plan is a flat monthly fee, but there's an intuitive ceiling where "using too much effectively chokes next month's capacity." Without visibility into which session used which model and how much, you're running autonomous agents with zero cost awareness. The more convenient an autonomous environment gets, the more it silently eats. That's why measurement comes first. The Stop hook is the mechanism that handles this measurement. When a Claude Code session ends (when the user runs /exit , or on timeout), it runs the commands registered in the Stop section of settings.json . Put a cost-aggregation script there and you get a "session ends = automatically recorded" pipeline. No more hand-typing costs into a spreadsheet. "It's running" and "it's running correctly" are different things — any engineer knows the feeling. Logs streaming out with all-zero contents is

Today on Decoder, I’m talking with Tim Cadogan, the CEO of GoFundMe. You know GoFundMe — it’s a major fundraising platform where you can donate to help people with everything from medical expenses to little league uniforms to starting a new business. Tim took over as CEO in March 2020 — a fascinating and chaotic […]

Andrew Swerdlow shares how Roblox scales autonomous software development from prompt to production. He discusses building robust security sandboxes, extracting institutional knowledge via code review exemplars, updating engineering infrastructure, and redefining productivity metrics around feature velocity and long-running AI turns to achieve trusted, automated deployment at scale. By Andrew Swerdlow

The Quest Begins (The "Why") I still remember the first time I opened a legacy codebase and felt like I’d stepped into a dark dungeon without a torch. The file was a single 800‑line function called processData . Inside, variables bore names like tmp , x , flag , and comments that tried to explain every line: // TODO: refactor this mess function processData ( input ) { let r = []; // result array for ( let i = 0 ; i < input . length ; i ++ ) { // loop over items if ( input [ i ] > 10 ) { // if value greater than threshold let v = input [ i ] * 2 ; // double it if ( v % 2 === 0 ) { // if even r . push ( v ); // add to result } } } return r ; } I spent three hours tracing why a certain edge case produced an empty array, only to discover the comment “if value greater than threshold” was outdated—the threshold had changed to 12 in a later commit, but the comment never got updated. The code lied, the comments misled, and I felt like a hero who’d just swung at a shadow. That frustration sparked a question: What if we could write code so clear that comments became unnecessary? Not because we’re lazy, but because the code itself tells the story. The Revelation (The Insight) The treasure I uncovered wasn’t a new framework or a slick library—it was a mindset shift: make the code self‑documenting through intention‑revealing names and small, focused functions . When a variable, function, or class name reads like a sentence, the reader can infer what’s happening without a side note. Think of it like reading a well‑written novel. You don’t need footnotes to understand that “She opened the door and stepped into the rain” means she’s going outside. The same principle applies to code: if you name a function filterValuesAboveThreshold , the intent is obvious. Why does this matter? Because comments decay. They become outdated, they get ignored, and they add noise. Self‑explanatory code, on the other hand, stays accurate as long as the name stays accurate. It also forces you to think ab

Once you use Claude Code or Codex for real work, a total usage number stops being enough. You want to know which change consumed it. I did not build agent-cost because I had missed the existing token and cost trackers. I knew about multi-agent reporting CLIs, local dashboards, and OpenTelemetry-style observability stacks. I had even built a similar view in Notion before. The problem appeared when I tried to use that kind of reporting in an operational workflow. I needed agent logs to stay on the machine. I wanted a small runtime dependency surface, custom metrics I could audit, and a machine-readable result that another tool could consume. Most importantly, I needed session measurement and task attribution to remain two different claims. I did not need another universal dashboard. I needed a boundary underneath the dashboard that could answer: is this number supported well enough to enter task accounting? A measurement layer below the UI Different tools optimize for different jobs. A broad CLI such as ccusage is useful when coverage across agents matters. Local interfaces such as token-tracker or AgentMeter are a better fit for visual exploration of projects, sessions, subagents, and tools. An OpenTelemetry stack is the natural choice for fleet-level metrics, logs, and traces. Those are not inferior versions of agent-cost . They serve different use cases and trust models. The layer I wanted looked like this: local observations -> auditable normalized facts -> explicit pricing status -> caller-selected sessions -> task-attribution policy -> optional dashboard / Notion / spec-lane agent-cost reads logs that Claude Code and Codex CLI have already written locally. It normalizes each usage event into a fact with a model, token kind, timestamp, and count. At runtime it makes no network calls and declares no Python runtime dependencies. Its price catalog has a version and SHA-256 digest, both carried into machine-readable output. That “zero-network” claim is deliberately l

Enterprise vibe coding: the governance framework for shipping AI-generated apps to production Published: August 22, 2026 Category: Enterprise · AI Deployments Reading time: 9 minutes Author: NEXUS AI Team Gartner forecasts that 40% of new enterprise production software will be built using vibe coding techniques by 2028. A 2026 scan of more than 1,400 live vibe-coded applications found that 65% already had a security issue, and 58% shipped with at least one critical vulnerability. Those two numbers describe the same industry moving in opposite directions at once: adoption is outrunning governance. This post covers what a governance framework for enterprise vibe coding actually looks like, the five controls it needs, and where most teams get it wrong. What is enterprise vibe coding? Enterprise vibe coding is the practice of using natural-language prompts to generate application code, then governing that code through mandatory review, access control, and audit before it reaches production, rather than letting it ship straight from a prompt to a live endpoint. The term (coined by Andrej Karpathy in early 2025) originally described a fast, low-friction way for one person to build a prototype. What "enterprise" adds is the governance layer prototyping was never built for: staging environments, encrypted secrets, role-based access, and a record of who approved what. That distinction matters because the adoption curve and the risk curve are not moving together. The governance gap, in three numbers 40% of new enterprise production software will be built using vibe coding techniques by 2028, according to Gartner's May 2025 report "Why Vibe Coding Needs to Be Taken Seriously," as reported by CIO Dive . 65% of vibe-coded production applications had a security issue, in a 2026 scan of more than 1,400 live apps by the API security firm Escape.tech, reported via a Cloud Security Alliance research note . 58% of those same applications shipped with at least one critical vulnerabilit

At LinkedIn's scale, relying solely on human reviewers or simply putting an off-the-shelf AI reviewer in front of GitHub is not an effective way to manage PRs. To address this, LinkedIn engineers built a multi-agent AI code review platform that understands the organization’s coding context, treats code review as production infrastructure, and minimizes hallucinations and low-signal feedback. By Sergio De Simone

When I shipped KittyClaw two weeks ago, the tool did one thing: serve as a board. The Claude agents ran alongside - first by hand, then via a dispatcher.mjs : a Node script polling KittyClaw's API, triggering the right agent based on who was assigned to which ticket. The dispatcher worked great. It orchestrated Aekan's 13 agents for weeks. But it was an external process : one more node dispatcher.mjs to launch, a state file ( dispatch-state.json ) to keep in sync, logs to dig up in .agents/channel/debug.log , a config to copy-paste across projects in JS. Today, the dispatcher doesn't exist anymore. Orchestration lives inside KittyClaw . I run dotnet run on KittyClaw, nothing else. Aekan's 13 agents still run - but the infra that drives them is now a first-class citizen of the board. This shift from "dispatcher on the side" to "dispatcher inside the board" is small in lines of code, but it completely changes what the tool is. And how I work. This piece documents KittyClaw , the kanban orchestrator at the center of the Ekioo agent-fleet R&D. Alongside Bloomii (constructive-journalism media) and Kalceo (regulatory B2B SaaS for construction contractors), KittyClaw runs the AI agents that drive these projects in production. Before: two processes to run, two places to look The old setup was three stacked layers: KittyClaw - the board, with its UI and REST API. dispatcher.mjs - a separate Node script in the project's .agents/channel/ , launched manually in a terminal. Claude Code - the agents themselves, launched by the dispatcher. It worked. But every project had its own dispatcher.mjs , usually forked from Aekan and hand-adapted. Patterns duplicated: 30s polling, code lock, evaluator debounce, daily budget. Adding a feature (say boardIdle or subTicketStatus ) meant re-coding it in every dispatcher, or accepting that one project had it and others didn't. And visually, orchestration was invisible from the board . To see an agent's live activity, I'd pop a terminal, tail -f

You said you'd remove that flag after launch. You lied. It's been six months and the flag is still in appsettings.json , the if statement is still in your controller, and nobody remembers which state is "on." This is how codebases turn into haunted houses. Why Cleanup Matters Dead feature flags are technical debt with teeth . They add branches to your code that nobody tests. They confuse new developers who don't know the history. They inflate configuration files and make deployments harder to reason about. And they compound. Every flag you don't clean up makes the next cleanup harder because the cognitive load of understanding the system keeps increasing. The cost of removing a flag is lowest immediately after the feature ships, while everyone still remembers what the thing does. Six months later? Good luck. Track Every Flag You can't clean up what you can't find. Maintain a registry of every active feature flag with: Name Purpose Owner Date created Expected removal date This can be a spreadsheet, an issue tracker, internal documentation, or a dedicated feature flag management system. The format doesn't matter nearly as much as the habit. When you add a flag, add it to the registry. When you remove a flag, remove it from the registry. If your registry contains flags with no owner or no removal date, congratulations: you've found your next cleanup project. Set Expiry Dates Every flag should have a planned removal date when it's created. For example: Release toggles: Remove shortly after the feature ships. Two weeks is a reasonable default. Experiment toggles: Remove when the experiment concludes. Ops toggles: May be permanent by design. Permission toggles: May also be permanent, but document that explicitly. If a flag has been alive longer than its planned expiry and nobody deliberately extended it, it's already a zombie. Treat it accordingly. Make Cleanup Part of the Process Flag cleanup doesn't happen unless someone owns it. Add a cleanup step to your feature compl

Did you know there's a new major version in town for Puppet Core? You might have heard about it through the grapevine or in the Are You Ready for Puppet 9? webinar that @gpatton and I recently hosted. The wait is over and Puppet Core 9.0.0 is now available alongside Puppet Core 8.21.0. Puppet Core 9 introduces significant runtime and platform changes, moving to Ruby 4.0, OpenSSL 3.5, and other changes, but the essential Puppet under the hood is largely unchanged from Puppet 8. The majority of upgrade effort will center on Ruby 4 compatibility and runtime dependency changes rather than Puppet language changes. If you are staying on the Puppet Core 8.x release track, the latest Puppet Core 8.21 delivers the basic support fixes and security improvements you might need without the major dependency changes found in Puppet Core 9. What matters most for the admins Before upgrading to Puppet Core 9: Test custom facts, functions, types, and providers against Ruby 4.0. Validate any Forge modules you use for Ruby 4 compatibility. Review integrations that depend on OpenSSL behavior. Verify any workflows that still rely on SHA-1. Confirm managed nodes are running supported operating systems. Review any custom code that depends on PSON or multi_json . Check deferred function behavior if you have custom types or providers. Perforce will be rolling out updates to Puppetlabs modules on the Forge based on their priority tier and dependencies. The first batch of these should be rolling out soon. Puppet Core 9.0 highlights These are a few highlights I pulled from the release notes. Make sure to reference the full 9.0 release notes to get all the details about what has changed! Ruby updated to 4.0.5: With a new Ruby baseline some deprecated syntax from older Ruby versions will no longer be compatible. This is the primary focus area for upgrades as you will want to validate your custom code and modules. The latest PDK 3.8.0 introduced some Ruby 4 validators to help you update your syntax

Originally published at tddbuddy.com . Related reading: Where the Review Point Moved is the direct predecessor; this post argues the industry's response to that shift is doubling down on the wrong surface at higher throughput. What "Senior" Means When Typing Is Free and The Test Pyramid Was an Economic Argument name where signal actually lives now. The review agent left fourteen comments on the pull request and none of them were the reason the PR should not have merged. That is the shape of the failure. The reviewer that shipped the review was a tool built to catch what a human reviewer no longer had time for. Three of the comments were genuine issues, unused imports, a typo in a log message, a dead branch. Eleven were style opinions, restatements of what the diff already made obvious, or false positives on patterns the codebase had chosen deliberately. The human on the PR spent more time filtering the review than reading the diff. The change that actually needed a second pair of eyes (a renamed field in a shared DTO that had already broken a downstream consumer twice this year) merged without a comment on it from either the human or the machine. The industry response to agent-generated pull-request volume has been to deploy more agents. The response is understandable. It is also empirically counterproductive. A 2026 study measured what happens when only a code-review agent reviews an agent-authored PR: 60.2% of closed pull requests sat in the 0 to 30 percent signal-ratio range, and twelve of the thirteen review agents evaluated averaged below a 60% signal ratio. Signal is what a human reviewer needs. The review agent produces less of it per unit of reviewer attention than the diff would have without a bot in the middle. The Volume Problem Is Real Four hundred thousand pull requests in two months from a single code-writing agent. One in five reviews on the largest hosting platform now involves an agent. Pickup time on agent-authored PRs is 5.3 times longer than on h

Affiliate disclosure: I’m an independent Payhip Partner. The optional signup link at the end is my partner link; I may receive a commission from Payhip if a referred seller generates eligible revenue. I am not a Payhip employee or official representative. A creator selling one template or downloadable guide does not need to write a payment backend. The safer architecture is usually: Carrd or static page ↓ Payhip product page or direct checkout ↓ Hosted payment and product delivery Your public page explains the offer. The hosted commerce platform owns the payment flow. No card data, secret keys, or payment logic belongs in Carrd. This tutorial shows two link-based integrations and one optional embed route. Before you start You need: A published product in Payhip Its public product URL A button on your Carrd or static page A clear product description, support contact, and terms In Payhip, the product URL is available from the product’s Share / Embed controls. A typical product URL has this shape: https://payhip.com/b/PRODUCT_KEY Use your real product key in every example below. Option 1: Send visitors to the product page This is the safest default when the buyer still needs details before purchasing. In Carrd: Select the call-to-action button. Set its URL to your full Payhip product URL. Use a descriptive label such as View template details or See what’s included . Preview the page on desktop and mobile. On a conventional static site, the equivalent HTML is just an anchor: <a class= "product-button" href= "https://payhip.com/b/PRODUCT_KEY" > View product details </a> No JavaScript is required. Use this route when the Payhip product page contains important previews, license terms, compatibility notes, or variations that do not fit on your landing page. Option 2: Link directly to checkout If your landing page already gives the buyer everything needed to decide, a direct checkout removes an intermediate page. Payhip documents this URL format: https://payhip.com/buy?link=

Today on Decoder, I’m talking with Robert Hart, The Verge’s London-based AI reporter, about what AI is doing to the field of mathematics and the existential crisis many lead mathematicians are having about it. OpenAI just published a set of solutions to longstanding problems in math that went off like a bombshell in the field. […]