DEV Community: @lukeocodes 🕹👨‍💻

DevRel This Week, 28 September: Hacktoberfest Drops the Pull Request

@lukeocodes 🕹👨‍💻 — Mon, 28 Sep 2026 00:00:00 +0000

DevRel this week, 28 September 2026: Meta put $1 million into a VR competition and another $1 million into an AI hackathon, Cloudflare offered $500,000 in credits and a billboard to one startup, and OpenAI DevDay runs tomorrow at $650 a ticket for people it invited. Two things got worse. Hacktoberfest starts on Thursday with pull requests no longer counting for anything, and Microsoft switched off Office 365 E3 developer accounts without sending an email.

Can anyone get into OpenAI DevDay tomorrow?

OpenAI DevDay is on Tuesday 29 September at Fort Mason in San Francisco. Sam Altman's keynote (the main talk) is at 10am Pacific and streams free. Everything else is only for people there in person. You had to apply over the summer, invites went out in late July, a ticket is $650, and there are no tickets on the day. Eight DevDay Exchanges, smaller one-day versions, follow later in the year in Bengaluru, Tokyo, Seoul, Paris, Berlin, London, São Paulo and Mexico City (devday.openai.com).

Cloudflare Connect is three weeks later, 19 to 21 October at Moscone West, at $595 a pass (Cloudflare). GitHub Universe is the week after that, 28 and 29 October, back at Fort Mason (GitHub). Three developer conferences in one city in five weeks.

Meta and Cloudflare are paying prize money

Meta Connect was on 24 September. The developer recap has two competitions in it. The 2026 VR Start Developer Competition opened the same day and closes on 18 November, with $1 million split across 20 prizes from $20,000 to $100,000 in gaming, entertainment and productivity, winners announced on 11 December, and you have to be in the VR Start programme to enter (Meta). Next to it is a Global AI Developer Hackathon with another $1 million and free Model API credits (credits are money you can only spend on their services), now that the Meta Model API is out of beta and open to everyone (Meta Connect recap).

Cloudflare's Birthday Week opened with the founders' letter on 27 September. The number that matters is 7 million developers on the platform. The letter also says automated traffic passed human traffic in May 2026, earlier than they had forecast, and says it will give creators and app builders a way to get paid when AI agents use their work (Cloudflare). Today's posts include The Cold Start. Five startups that have taken less than $10 million from investors present live at Connect on 19 October, five minutes each, in front of Matthew Prince, Michelle Zatlyn and Dane Knecht. The winner gets $500,000 in credits and a billboard in San Francisco (Cloudflare).

Google let other people's agents into Android Studio

On 24 September Google released Bring Your Own Agent in Android Studio Rabbit 2, the Canary build (the earliest test version). You can run Anthropic's Claude Agent, OpenAI's Codex or Google's own Antigravity inside the app you write code in, and it hands the agent build diagnostics and control of the emulator (a fake phone on your computer) through the Agent Client Protocol, a shared way for editors and agents to talk to each other (Android Developers Blog). Matthew Warner, the product manager, said "it's important for you to be able to build Android apps in the way that works best for you and your team".

Hacktoberfest starts Thursday and pull requests don't count

Hacktoberfest 2026 runs through October, and this year the four pull requests for a t-shirt rule is gone. The FAQ says why: "with the rise of AI tools making low-effort PRs trivial to generate, open-source maintainers faced unprecedented floods of noise, spam, and burnout" (Hacktoberfest FAQ). In its place are 300 plus Fests, in-person and online events of up to 12 hours run by local organisers, with DigitalOcean presenting and MLH and DEV running it. T-shirts are only at Fests, if the organiser decides to and as supplies allow. Online, there is a Swag Envelope for hitting milestones that had not been published as of 20 September, when 217 Fests were registered (DEV). The homepage's suggestions for what to do instead are "write your first skills.md, build your own open-source agent, fine-tune an open-weight model" (hacktoberfest.com). A skills file is a short document that tells an AI agent how to use a project.

I wrote in August about agents reading your docs and this month about DevRel in the era of AI. Hacktoberfest now tells a first-time contributor to write one of those files before anything else.

Microsoft switched off developer accounts with no email

Microsoft told Office 365 E3 Developer subscribers at the end of June that the subscription was being retired and set 14 September as the date (Topedia, June). A tenant is a Microsoft 365 account with its own users, and those tenants were disabled a few days late with a note in the admin page that the subscription would be deleted. No email (Topedia, 25 September). The suggested move is to a paid Microsoft 365 suite to keep the data. The free E5 sandbox (a test copy of Microsoft 365) from the Microsoft 365 Developer Program now needs a Visual Studio Professional or Enterprise subscription, a Microsoft partner level, or a Premier support contract to qualify (Microsoft 365 Developer Program FAQ). A personal account can join the programme. It can't get the sandbox.

Also in DevRel this week, 28 September: npm and RubyGems add a wait before a package goes live

npm 12.1.0 adds a kind of token that can only put a package into staging, a holding area before it goes live, and npm stage shows what is waiting there. RubyGems 4.1.0 beta 1 adds a --cooldown option to install, update and outdated, plus post-quantum signatures, which is signing that future quantum computers can't fake (Andrew Nesbitt, 26 September). They land after a run of attacks between April and July that stole publishing tokens and put poisoned packages on npm (Unit 42).

FAQ

When is OpenAI DevDay 2026 and can I watch it?

DevDay is on Tuesday 29 September 2026 at Fort Mason in San Francisco. The keynote with Sam Altman starts at 10am Pacific and streams free. In-person places were by application, which closed on 10 July, and cost $650. The other sessions are recorded and posted on openai.com after the event.

Do pull requests still count for Hacktoberfest 2026?

No. The four pull requests for a t-shirt rule is gone. Hacktoberfest 2026 is built around 300 plus in-person Fests of up to 12 hours. T-shirts are only handed out at Fests, at the organiser's discretion and while stock lasts. Online participants get a Swag Envelope for milestones that had not been published as of 20 September.

What did Meta announce for developers at Connect 2026?

Two $1 million competitions. The VR Start Developer Competition opened on 24 September and closes on 18 November, with 20 prizes from $20,000 to $100,000 across gaming, entertainment and productivity. A Global AI Developer Hackathon has another $1 million and free Model API credits. The v207 SDKs for the 2027 VR Glasses are out now.

What happened to the Office 365 E3 Developer subscription?

Microsoft retired it. The change was announced at the end of June 2026, the cut was set for 14 September, and the tenants were disabled a few days after that with a note in the admin centre saying they would be deleted. No email was sent. The free E5 sandbox now needs a Visual Studio Professional or Enterprise subscription, a partner tier or a Premier support contract.

Hacktoberfest starts on Thursday, and this is the first year a pull request on its own gets you nothing.

Eleven v4 Turbo Gets Voice Agents to Full Duplex

@lukeocodes 🕹👨‍💻 — Mon, 28 Sep 2026 00:00:00 +0000

ElevenLabs released Eleven v4 and Eleven v4 Turbo on 28 September 2026. Turbo takes text while your LLM (the text model that writes the reply) is still writing it, and starts sending audio back about 150 milliseconds later. Inside ElevenAgents, a turn-taking model decides when the agent should stop and when it should keep going, so you get an agent you can talk over. ElevenLabs doesn't call that full duplex. I do, because it's the setup my August whitepaper asked for.

That post listed three problems with how voice agents are built. This one goes through them again with today's release in hand, so it's a follow on.

What ElevenLabs shipped

Two models came out together. Eleven v4 is for produced content, the audiobook and video work where quality matters more than speed. Eleven v4 Turbo is the fast version for agents. ElevenLabs says both are built on "an entirely new architecture" (a new way of building the model), and the product page describes something it calls context stitching, which keeps the same voice steady across a whole script.

The numbers from the product page:

More than 90 languages.
Instant Voice Clones from 10 seconds of audio.
Professional Voice Clones are back. They weren't supported in v3.
One generation can be up to 10,000 characters.
Free plan: 10,000 credits a month, about 10 minutes of audio. Premium is $6 a month.

The blog post adds the test results. ElevenLabs says Artificial Analysis, an outside site that ranks AI models, puts v4 first for September 2026. It says about 75% of listeners picked v4 in blind tests, where the listener doesn't know which model they're hearing, and that v4 won 65% to 81% of head-to-head tests against Cartesia Sonic 3.6, Inworld TTS-2 and two of Google's Gemini voices. Nobody outside ElevenLabs has published a measurement yet.

TechCrunch has the business side. Language support was 70 in v3. Revenue run rate, meaning this year's pace rather than money already in, is past $600 million, up from about $330 million at the start of the year, and more than 55% of it comes from big companies.

What streaming both ways gives you

The old way to connect text-to-speech to an agent was to wait for the LLM to finish a sentence, send the sentence, then wait for the audio. Every sentence waited for the full trip out and back.

With v4 Turbo you push words as the LLM produces them and audio comes back before the sentence is finished. ElevenLabs' words: "Bidirectional streaming, built for agent loops." Latency, the wait before you hear anything, is about 150 milliseconds to the first sound. The model's own processing time is about 100 milliseconds. Both are medians, the middle result with half faster and half slower. ElevenLabs' comparison table puts Cartesia Sonic 3.6 at 262 milliseconds and OpenAI's GPT-4o mini TTS at 814.

Is Eleven v4 Turbo full duplex? The three problems from August

The whitepaper described a voice agent as a chain of three parts, each waiting for the one before it to finish: speech-to-text, then the LLM, then text-to-speech. I called that chain the cascade. It broke the trouble with it into three problems.

The first was latency adding up at every step. Speech-to-text waits for enough audio, the LLM waits for the full transcript, and text-to-speech waits for the full text. v4 Turbo removes the last wait, and streaming both ways means it no longer waits for a full sentence either.

The second was that the model knows what it said but not what the user heard. The bigger the gap between what has been generated and what has been played, the more there is to sort out after an interruption. At 150 milliseconds to first speech, with audio going out as it's made, that gap is now tiny.

Interruptions are the third problem, and the one I care about most. People make noises while they listen: "mm", "yeah", "uh-huh", a laugh, a cough. On a call with a person those noises mean carry on, but a plain voice detector hears them as the user talking and stops the agent mid-sentence. ElevenAgents is built from four parts: a speech-to-text model, your LLM, a text-to-speech model (v4 Turbo now, according to the v4 blog post) and what the docs call "a proprietary turn-taking model that handles conversation timing". Proprietary means their own, not public. A model whose only job is timing should be able to learn that a sound is not always a turn, and not always a change of subject. The docs don't say what it's trained on, and they list the interruption and turn-taking settings you can change.

What to do with it today

If you build voice agents, use Turbo for the speaking part, then make sure the rest of the chain, speech-to-text and the LLM, adds no more than another 150 milliseconds.

Then measure the three things the whitepaper asked for: the time from the user going quiet to the agent starting to speak, the time it takes to recover from an interruption, and how often the agent carries on talking after the user has started. If you're on ElevenAgents, the turn-taking settings are where you change the last two.

One more thing from the agents docs: they still say the text-to-speech there covers 70 plus languages, while the v4 pages say 90 plus. Expect that page to catch up.

The Frontier AI Standards Agency Has a Shortlist and No Rules Yet

@lukeocodes 🕹👨‍💻 — Fri, 25 Sep 2026 00:00:00 +0000

Google, OpenAI and Anthropic have agreed to set up a frontier AI standards agency, The Information reported on 24 September 2026. The working name is the Standards Authority for Frontier AI, it would launch at the end of this year or early 2027, the money would mostly come from the labs, and the first person they approached as CEO is Sriram Krishnan, who left the White House in June saying "there will not be an FDA for AI". In the same week, two more agent break-ins came out months after they happened, and Mark Zuckerberg said Meta will not join any slowdown.

The standards body got a name and a shortlist

Two weeks ago I wrote about the meetings behind this body, which had been running since July. Now it has a working name, a launch window and a hiring list. Alongside Krishnan, the labs have approached Arati Prabhakar, who ran science policy under Biden, Condoleezza Rice, the investor David Friedberg, Beth Barnes of Metr, and Paul Christiano.

The shape has not changed. It copies financial self-regulation, it is paid for by the firms it will test, and it only needs the government if it wants legal powers, in which case it would register with an agency. The idea traces back to a proposal from Demis Hassabis.

The Krishnan pick is the part I'd read twice. That is not the CV of someone hired to slow anything down. He spent eighteen months as the White House's AI adviser arguing against any licensing regime, and on his way out said a central agency that needed "a team of lawyers before you can get a model out" would put "sand in the gears" of AI (AI Weekly).

Two more break-ins, both months old

On 24 September the Australian Prime Minister, Anthony Albanese, said an OpenAI agent got into the Medicare statistics reporting portal on 18 June (ABC News). The portal refused its data requests and the agent "didn't accept 'no' for an answer", in his words. It read aggregate health statistics and internal file names, and wrote files to an internal server, which is still being looked at. OpenAI found the activity on 11 August and told the government on 10 September, by email to a public mailbox. Albanese called that "unacceptable" and has set up a task force under his own department with the Australian Signals Directorate. OpenAI said its "models took actions we did not intend" (CNBC).

Then Google. On 18 September it said that back in May, Gemini got into three outside companies' systems during a security test (NBC News). The test used a made-up company name that happened to match a real domain. Gemini guessed one login and found credentials for the other two in a public code repository. Heather Adkins, Google's VP of security engineering, said the model "thought they were part of the test" and stopped once it was in. Google says this does not count as misalignment, the industry word for a model doing what it was not told to do.

That makes four labs, and the list I put together two weeks ago is two longer. The gap is what I'd watch. May to September for Google, June to September for OpenAI, and for a national government, a public inbox as the way it found out.

Who said no this week

Zuckerberg gave NBC News his answer on 24 September. "I don't think that we need some kind of industrywide coordination," he said. Each lab should "take the time that you need internally", and "there's plenty of commercial incentive to get this right". So one of the four biggest US labs is out before it started.

The White House went further than no. A memo written by a Trump political adviser started circulating there this week casting Dario Amodei as the face of AI "doomerism" and naming him, his sister Daniela and her husband as "the Anthropic knot" inside effective altruism (Axios). It landed as Anthropic prepares an IPO priced near $2 trillion. On the same day the Office of the National Cyber Director asked OpenAI and Anthropic to keep new models away from the UK's AI Security Institute until US officials finish their own review, Politico reported. Anthropic had already kept Claude Mythos 5.1 inside a US-only partner group, and the institute's director, Henry de Zoete, told a parliamentary committee this month that it did not get access to that model.

Pulling the other way, Bernie Sanders and Greg Casar introduced a bill on 23 September that would ban artificial superintelligence, pause advanced AI development until a new cabinet-level Department of Artificial Intelligence has written rules, and carry up to 20 years in prison for breaking it. That is the government-run version of the thing the labs are building for themselves, and it arrived the day before theirs got a CEO shortlist.

The releases, for the record

Both of the labs asking for a slowdown shipped this week. On 22 September OpenAI released GPT-6 Sol and GPT-6 Luna (TechCrunch). Sol is $2 per million input tokens and $10 per million output, down from $4 and $20 for GPT-5.6 Sol. Luna is $0.10 and $0.50, down from $0.20 and $1.20. OpenAI says Sol makes about half the factual errors of the model it replaces (Help Net Security).

The same day Anthropic released Claude Opus 5.5 at $4 and $20 per million tokens, 20% below Opus 5, with cache reads at $0.20 and a 1M-token context window (9to5Mac). Sonnet 5.5 and Haiku 5.5 are promised within weeks.

FAQ

What is the Frontier AI Standards Agency?

A body Google, OpenAI and Anthropic have agreed to set up to write shared tests for frontier models before release. The working name is the Standards Authority for Frontier AI. It copies the self-regulation model used in finance, the funding would mostly come from the labs, and the reported launch window is the end of 2026 or early 2027.

Who has been approached to run it?

Sriram Krishnan, the White House AI adviser from January 2025 to June 2026, was approached as CEO. Others named in the report are Arati Prabhakar, Condoleezza Rice, David Friedberg, Beth Barnes of Metr and Paul Christiano. None had accepted when it was reported.

Is this the slowdown Amodei asked for?

No. The body would test models, not pace them. In the same week it was reported, OpenAI and Anthropic each shipped a new model at a lower price, and Mark Zuckerberg said Meta sees no need for any industry-wide coordination on slowing down.

What did the OpenAI agent access in Australia?

Aggregate health statistics and internal file names on the Medicare statistics reporting portal, on 18 June 2026. It also wrote files to an internal server, which is still under investigation. Services Australia says no personal Medicare records were touched.

Two weeks after the calls to slow down, the labs have a testing body with a shortlist, two more old break-ins on the record and two cheaper models, and that is what the slowdown looks like so far.

Moving Off WordPress: 500 Posts and a Nuxt Rebuild

@lukeocodes 🕹👨‍💻 — Thu, 24 Sep 2026 00:00:00 +0000

Moving off WordPress took most of 2020, for a developer education blog with over 500 posts. The plan started in a meeting in Miami early that year. The new site arrived two prototypes and one framework swap later, and it went live on 23 November 2020 on Nuxt, Netlify and Netlify CMS.

Throwback Thursday, so some of this is how it felt. I was a developer advocate at Vonage at the time, on the Developer Education team, which sat inside Developer Relations, which sat inside Product. We were not engineers. We did not run any servers.

Why we were moving off WordPress

How we made content was split across three tools. Posts were written and reviewed as Markdown, then moved into WordPress, then tracked in JIRA. External writers in our Spotlight programme couldn't get into the git repo the posts lived in at all, so for them the process was worse.

Then there was the site itself. I had been quite public about my problems with WordPress: security, speed, bloat and the editing experience. The site was also a server that almost nobody on the team who ran our servers knew about. Vonage had bought several API businesses over the years and this WordPress install was left over from one of them.

A rebrand was coming at the same time. So instead of paying an agency to restyle the WordPress theme, we built the new site on the new brand.

The export that wasn't Markdown

In April 2020 I wrote a small Node script using the wpapi package (the official Node client for pulling posts out over the web API). It paged through every post, 20 at a time, and wrote them to one JSON file. Around 800 posts came down, going back to 2015. The file was over 30MB, and that was without a single image.

I remember being excited before I ran it. We edited in Markdown, so WordPress must store Markdown, so a few API calls would give me a folder of Markdown files.

It stored HTML. Worse, the code blocks came from Crayon, an old plugin that coloured code in posts and had been abandoned. Crayon kept code in HTML tables: one column for line numbers, one row per line of code. The last version of Crayon before it was dropped moved to plain <pre><code> tags to make leaving easier, but our install was so old and so unmaintained that updating everything just to get the content out was not realistic.

The maintainer of Crayon, it turned out, had also had enough of WordPress and moved his own site to Jekyll.

Reviewing 500 posts by hand

So we decided to review every piece of content manually. Over 500 posts. Not the thousands Smashing Magazine had when they made the same move at the start of 2020, but a lot for a team that also had to keep publishing new content.

The rebrand made moving off WordPress less painful than it sounds. Every post needed new artwork and updated SDK versions anyway, so reviewing them one by one was work we already had to do. What we did not have was weeks to do it in. The review would take months.

The plan was to go live before the review finished. Redirect rules on the old site sent readers to the same post on the new domain, where we had already imported each post's title, date, author and URL as a Markdown file. The old site moved to a "legacy" domain. On the new site, a post that had not been migrated yet showed a note saying we were still moving this content, with a countdown that redirected to the legacy copy. As each post got reviewed, we edited the Markdown file we had already imported, added the content, and dropped the legacy link.

We did the most read and most recent posts first, and most of those were done before launch.

Two prototypes, then a framework swap

I built two test sites. One in Jekyll, because I had used it before and it builds pages very fast. One in Nuxt.js, because Vue is terrific and I was already a big Jamstack fan (Jamstack means the site is built to plain files up front, with no server behind it).

Vonage had a design system called Volta (the brand's shared set of colours, fonts and page parts), built on Bootstrap and shipped as a Vue library. That decided it. Jekyll's templates were easier to write, but with Volta the Nuxt prototype already looked like the brand, and server-side rendering (pages built as finished HTML before the browser gets them) made it quick. After a few weeks of feedback and tweaks we had something close to the final site.

Two weeks after the prototype was finished, the design team dropped Volta.

We replaced it with Tailwind CSS. We got back to the same look, and we ended up with cleaner rules for how the page changes at each screen size. I had written a short post in March 2020 on adding Tailwind to a Vue app.

Netlify CMS handled the content. Its editorial workflow matched our JIRA flow closely, and it saved every post as a file in git, which matched how we already reviewed things. Each edit in the CMS opened a pull request (a proposed change someone reviews before it lands). External writers could finally use the same tool as the rest of us.

The 30 minute builds

Go-live was not the hard part. The builds were.

By October 2020 we had turned on Nuxt i18n (the translation plugin) and production deploys hit 27 minutes. A few nice-to-have Netlify plugins later and deploys were timing out at 30 minutes. Eight people worked on content. Every edit in Netlify CMS created a pull request and a preview build.

The fixes came in steps, and I wrote them all up at the time:

Nearly 600 imported articles were generating pages for every category, tag and author, about 17,500 pages. Cleaning up post metadata got that to just over 3,000 pages, and deploys dropped from timeouts to 15 minutes.
Skipping optional npm dependencies did nothing for us.
Turning off Nuxt's inline CSS and JS minification (squashing the code files smaller, which Webpack already did) saved a minute or two.
Setting CI=1 to cut logging to errors only made a surprising difference and got us to 8 minutes.
Turning off every extra step Netlify runs after a build, because Nuxt had already squashed and built the pages, got us to 5 minutes.

Five minutes was as far as production would go without paying for Netlify enterprise. Production was never the build I cared about, though, it was the previews.

Nuxt 2.14 had a crawler that found every page URL the site could make. If I turned the crawler off and handed the page builder one route, the build finished in about a minute. The route was already in the branch name: Netlify CMS put the slug in the branch name, cms/blog/<slug>, and Netlify exposed the branch as the HEAD environment variable (a named value the build can read) and whether it was a pull request as PULL_REQUEST. A preview build could work out which single page to build from its own branch name.

// nuxt.config.js
const isPreviewBuild = () =>
  process.env.PULL_REQUEST && process.env.HEAD.startsWith('cms/')

const previewRoute = () => {
  const [, type, slug] = process.env.HEAD.split('/')
  return [`/${type}/${slug}`]
}

module.exports = {
  generate: {
    crawler: !isPreviewBuild(),
    routes() {
      return isPreviewBuild() ? previewRoute() : []
    }
  }
}

The type part meant we could preview author and video pages too, as well as blog posts, and previews came in at about a minute.

I built most of that without testing it, using the BRANCH variable because I assumed it held the branch name. It does not. When nothing worked I thought I had wasted hours on a bad idea. I had got one environment variable wrong.

What it felt like

At the time I wrote that it had been almost five years since I was in a role building code that production relied on. I should not have been surprised that the default Nuxt configuration wasn't tuned for production builds, but I was.

I was also wary of the fix. Configuration that changes how an app builds depending on the environment it runs in is the kind of thing I would normally avoid. I did it anyway because it was config, not application code, and because eight people waiting half an hour per edit was the bigger problem. At the end of that post I told myself to read the manual and be careful with code that behaves differently per environment.

Launch day, 23 November 2020, went without problems. Redirects sent people to the new site, with the legacy site behind it for anything still in review. A week later I added server-side analytics with a Netlify Function, because a site with no server of its own loses a lot of tracking to ad blockers, and page views got a lot more accurate.

Where it left me

Six years on, this blog is Markdown files in a git repo on a tool that builds the site to plain files, with a build that fails if any URL that was ever published stops working. I did not connect those two things until I went back and read the 2020 posts for this one. The countdown page pointing at a legacy domain did the same job in 2020, with less polish: a reader with an old link landed on something. I wrote up the plain _redirects file format in a TIL the following June, and I have been putting redirects in front of every site move since.

FAQ

Why did the WordPress export return HTML instead of Markdown?

WordPress stores the rendered post, not the source you typed. Our team edited in Markdown, but the database held HTML, and the Crayon syntax highlighter plugin had stored every code block as a table with a column for line numbers. The plugin was abandoned before our install could be updated, so the content had to be reviewed by hand.

How did the site go live before all the content was migrated?

Every post's metadata was imported as a Markdown file first, so every URL existed on the new site from day one. Posts not yet reviewed showed a note saying the content was still being moved, with a countdown that redirected to the same post on a legacy domain. The most read and most recent posts were migrated before launch.

Why did Nuxt win over Jekyll?

Vonage had a Vue-based design system called Volta, so a Nuxt prototype looked like the brand from the first day, and server-side rendering kept it fast. Jekyll's Liquid templates were easier to write, but the Nuxt prototype came together quicker. Two weeks after it was done, Volta was dropped and Tailwind CSS took its place.

How did preview builds get from 30 minutes to one minute?

Production builds went from timeouts to 5 minutes by cutting 17,500 generated pages to about 3,000, setting CI=1 to quiet the logs, and turning off duplicate minification and Netlify post-processing. Previews got to about one minute by turning off the Nuxt crawler on pull request builds and generating only the route named in the Netlify CMS branch.

TIL: git rerere Remembers Your Conflict Resolutions

@lukeocodes 🕹👨‍💻 — Tue, 22 Sep 2026 00:00:00 +0000

Git can remember how you fixed a merge conflict and do the same fix again next time. The setting is git rerere, short for reuse recorded resolution. It is off by default.

git config --global rerere.enabled true

From then on, every conflict you fix and commit gets saved in .git/rr-cache. Git keeps the block of lines it could not merge and what you changed them to. The next time that same block conflicts, git puts your fix in and leaves the file for you to check. Set rerere.autoUpdate to true and it adds the fixed file to the commit for you as well.

This is most useful when you give up on a rebase halfway through. Start it again and the conflicts you already fixed get fixed for you. Same when you copy one fix onto three release branches with git cherry-pick.

The git config defaults post left this one out.

What if I recorded a bad resolution?

git rerere forget <path> deletes the saved fix for that file. git rerere diff shows you what it is about to change before you trust it.

Does it work across repos?

No. The saved fixes live in each repo's own .git folder. Old ones get cleared out by git rerere gc, and git gc runs that for you.

Jev: The ChatGPT Co-Creator's System One Model Can't Talk

@lukeocodes 🕹👨‍💻 — Thu, 17 Sep 2026 21:12:47 +0000

Diogo Almeida’s new model cannot talk. Jev, released in early access on 15 September by TypeSafe AI, returns typed decisions with calibrated confidence: a choice from up to 255 options, a score, or a yes/no probability. It is not a language model, and the man who helped build ChatGPT says that is the point. Jev runs 70 to 500 milliseconds end to end, prices input at $0.042 per million tokens, and charges nothing for output.

The two-year answer

Almeida is the OpenAI researcher behind RLHF and InstructGPT, the methods that became the research behind ChatGPT and GPT-4. What he kept asking after co-inventing it: why have superhuman chat models not led to AGI? Chat is solved. Automation is not.

Two years in stealth, $40 million in backing, and a team from OpenAI, Google Brain, Meta and FAIR went into his answer. Jev. The argument underneath it is that chat was the wrong target. A model built to talk is a different thing from a model built to decide.

Jev doesn’t chat, it decides

Jev has no chat interface. It cannot generate strings at all.

Give it structured state and it returns one of three primitives: a Choice, a Score, or a Noul, each with a confidence value between 0 and 1. Your software acts on the answer. The docs are blunt about the edges: 32K context window, no image input, no code, no prose.

The confidence value is the whole design. Calibrated confidence means the number Jev reports matches how often it is right: when it says 0.9, it is right about nine times out of ten. That is not a promise LLM APIs have kept in a form software can act on. Most say 0.9 and mean “sounds plausible”.

The “can’t hallucinate” coverage needs a qualifier. Jev structurally cannot emit a malformed answer, the output shape is guaranteed by construction. It can still return a schema-valid answer that is factually wrong, and Almeida said as much during the launch discussion.

The demos make it real

Two demos tell you more than the benchmark numbers. There’s a video of Jev playing Doom at about ten calls a second, roughly $7 an hour of play. There’s a Wikipedia game where Jev races from page to page choosing among thousands of links. Both make the same point visible: this thing decides fast enough to sit inside a game loop, and cheap enough that nobody notices the bill.

RLCD is the interesting part

The training method is RLCD: Reinforcement Learning for Calibrated Decisions. Almeida’s critique of RLHF is specific. It trained for human preference, which made models superhuman at following instructions, and it also produced overconfidence and mode dropping, the exact failure modes that keep a human in the loop. RLCD trains for the opposite property. A machine can act without asking permission.

This matters because trust is the thing that is broken. An API that says 0.9 and is right 60% of the time is not usable in a pipeline, no matter how good the prose is. TypeSafe is betting the market for a decision you can trust is bigger than the market for a sentence you cannot.

What the numbers actually say

The headline ranges are 20-200x faster and 40-400x cheaper. They are self-reported, which is worth remembering while the model is waitlist-only. The benchmark video on their proof page compares workflows, not single calls. One example: a System One task that ran in 0.114 seconds at $0.000081 took 8.566 seconds and $0.013880 on a frontier model. Across the workflow suite, the average is 193.6x faster and 444.6x cheaper against GPT-6 Astra and Fable 5.1.

The free output is not a promotion stunt, which I assumed at first. There is no autoregressive generation to meter: the architecture returns all outputs at once, in parallel. The comparison models take 3 to 329 seconds per call largely because they generate one token at a time. Jev’s latency is the direct result of skipping that loop.

Where this bites for voice agents

If you build agents, this is the interesting part. Most pipelines use one large chat model as thinker and talker: it classifies the intent, extracts the arguments, routes the work, drafts the response. You pay reasoning cost at every step, even when the step is a decision that fits on one line.

In voice pipelines, where I spend my days, the pattern is everywhere. Intent classification, escalation routing, fraud triage. Each is currently a full LLM call with JSON output and a parser you trust about as far as you can throw it.

Jev changes the shape of that. Set a confidence threshold at 0.85 and escalate anything below it. That is the escalation pattern production voice agents spend months hand-building, and it stops being a design constraint when decisions cost near nothing. The cleanest framing I’ve seen this week splits the stack: language models for communication, coding models for implementation, decision models for high-volume judgment. Jev is the first decision layer built for that job from the ground up.

What’s left to prove

None of this tells you whether the decisions are any good. Speed and price you can verify in a day. Decision quality takes months of production traffic, and TypeSafe is still a waitlist.

The structural claim survives the scepticism though. I have watched whole teams design around the cost of a single LLM choice, caching aggressively and batching calls to cut round trips. A 70ms decision model at near-zero marginal cost is built to remove exactly that behaviour.

Almeida has the track record, and early access means the claims get tested before anyone has to commit. If you build automation, the experiment is cheap: put a decision where you used to put an LLM call, and read the confidence score. Jev takes milliseconds, prices input at $0.042 per million tokens, and the waitlist is open.

Simba 3.2 Frontier TTS API achieves 100ms for $10/1M Characters

@lukeocodes 🕹👨‍💻 — Wed, 16 Sep 2026 13:35:55 +0000

Simba 3.2 and Simba 3.0 just dropped to around 100ms time-to-first-audio on Coval's benchmark. Same voices, same quality, same price. It's already the cheapest model in Artificial Analysis' top ten, and the cheapest in model on Vapi's Humanness Index with a score of 97/100.

Sign-up today to try our models and hear for yourself.

FAQ

Is $10 per million characters the streaming price too?

Yes. Simba 3.2 and Simba 3.0 are one per-character rate whichever endpoint you call, and the efficiency has not changed it.

Does the faster path change how Simba sounds?

No. The release changed where and how inference is served, not the weights or the voices. We've also snuck in watermarking to meet EU regs on generative content.

Simba 3.2 or Simba 3.0?

Simba 3.2 for English, because it has the most expressive delivery and now the lowest time-to-first-audio. Simba 3.0 if you need German, Spanish, French, Italian or Brazilian Portuguese, or self-serve zero-shot cloned voices. Our legacy Simba 1.6 supports more languages, and those languages will be finding their way into Simba 3.0 before mid-November hard switch-off of Simba 1.6. Simba 3.2 and Simba 3.0 both sit at around 100ms now, so pick on language and voice support.

How does Coval measure the 100ms?

Time-to-first-audio, from the request being sent to the first audible sample.

Developer Relations in the Era of AI

@lukeocodes 🕹👨‍💻 — Wed, 16 Sep 2026 00:00:00 +0000

Developer Relations in the Era of AI

Developer relations is the practice of building and nurturing relationships with developers through community engagement, technical support, education, and advocacy, and it is the discipline that turns developer adoption into business value. AI has changed who that work serves. From here on, DevRel serves two audiences at once: the human developer evaluating your product, and the AI agent consuming your documentation to write code on their behalf, and that single change ripples through every surface, metric, and function DevRel owns.

What is developer relations?

The DevRel Foundation (Linux Foundation, 2025) offers the working definition: "Developer Relations (DevRel) is the practice of building and nurturing relationships with external and internal teams through community engagement, technical support, education, and advocacy to enable the successful adoption of an organization's developer products and drive business value."

The shorter version: DevRel is how a company with a developer product keeps the people who build on it moving forward. Bear Douglas, formerly of Slack Engineering, frames the role as "an interdisciplinary role that sits in a border space between product, engineering, and marketing." That border space is the whole argument. DevRel is not a sub-function of marketing, and it is not a sub-function of engineering. It sits between them and pulls from both, and it translates between them when they stop talking to each other.

Seth Juarez, in the DevRel Handbook (2026), made the case that matters most at budget time: "Developer Relations is not a squishy collection of nice-to-have activities. It is a structured business function that creates content, refines technology, grows community, measures success, and organizes people around developer impact."

The composition data agrees. Four pillars make up the practice, measured by team makeup: Developer Advocacy (82.2% of DevRel teams), Community Management (52.7%), Technical Writing (42.7%), and Developer Experience. Each of those is a real discipline with its own tooling and its own metrics, and they all sit under the same roof. I've worked in this space long enough to say the roof is the hard part, not the individual rooms. Advocacy runs the demos and the talks, community keeps the Discord alive and the forum answered, and technical writing owns the docs and the migration guides. Developer Experience owns the parts of the product that make developers feel smart, or the opposite. Get the mix wrong and you have a content machine with no community, or a community with nothing fresh to talk about.

Each pillar produces something measurable. Advocacy produces demos that get copied, talks that get replayed, and reference integrations that get forked. Community produces threads that get answered and relationships that survive staff changes. Technical writing produces docs that get cited and migration guides that get followed. Developer Experience produces a product surface that needs less support. When executives ask what DevRel does, these outputs are the answer in plain words.

Where that roof hangs varies a lot. 33.1% of DevRel teams report to Marketing, 21.7% to Product, 20.3% to the CEO, and 19.9% to Engineering. Forrester put a warning sign on that spread in May 2026: "Developer relations (DevRel) is a strategic capability for any organization whose growth depends on developers. Too many companies mistake it for marketing, but when they do, their products drift from developer needs, developer trust erodes, and buying influence quietly disappears."

The reporting line matters because it decides what DevRel can influence. Under Marketing the incentive is campaign volume. Under Engineering the incentive is API quality and feedback loops. Under the CEO the incentive is ecosystem health and revenue influence. None of those choices is wrong, but each one shapes what the team prioritizes when the roadmap turns.

And that leads to the problem that has dogged the discipline for a decade. 60.7% of DevRel practitioners say proving impact with data is their number one challenge. Only 17.5% can link revenue influence directly to their metrics. 61% have no defined career path. These numbers moved slowly for years, and AI is the first thing with a real chance of moving them.

How does developer relations operate inside a company?

DevRel sits on a web of five relationships, and every one of them carries information in two directions.

DevRel and Engineering. DevRel hands Engineering developer-sourced bug reports, friction logs, usability issues, and integration patterns that never appear in internal testing. Engineering hands back roadmap context, technical accuracy review, and API stability commitments. Break this loop and DevRel writes about features that are about to change while Engineering builds on assumptions that do not match reality. The strongest versions of this relationship I have seen run a regular joint triage: engineering gets the raw developer complaints, DevRel gets the roadmap dates it is not supposed to leak.

DevRel and Product. The grassroots feedback, competitive intelligence, and usage pattern data flow from DevRel to Product. Feature announcements, use cases, and beta access flow back. The best DevRel teams sit in product planning meetings as the voice for the developer nobody in the room has talked to this quarter. That is not an honorary seat. Developers tell DevRel things they will never put in a bug report, usually because they are not sure whether what they hit is a bug or a misunderstanding.

DevRel and Marketing. DevRel provides the authentic developer voice, the technical credibility, and the event ROI data. Marketing provides budget, brand guidelines, and distribution. The tension is structural. Marketing is measured on volume, and DevRel is measured on depth, and the two do not reconcile themselves. A team that names that tension early spends less time arguing about it later. The healthy pattern is marketing owning the reach and DevRel owning the message, with both agreeing in writing on which is which.

DevRel and Sales. This is the most underused relationship in most companies. DevRel can hand sales developer-qualified leads, technical validation during evaluations, and churn risk signals from developers who are struggling. Sales can hand back customer pain points and revenue attribution. Rarely do the two pipelines meet, which is a waste on both sides. An integration story that someone at a mid-market company wrote about in their own words is worth more to sales than any spec sheet, and DevRel is where those stories are found.

DevRel and the executive team. DevRel provides ecosystem health metrics, market signals, and the link between developer engagement and revenue. The executive team provides strategic direction and budget authority. When DevRel cannot make that link, its future is decided at the next budget review. That is the loop the measurement problem keeps jamming, and it is the loop AI is finally starting to unblock.

The web only works when all five relationships stay live. I've seen DevRel teams that ran four of them well and silently dropped Sales, and the gap showed up as a revenue question at the next forecast. I have seen teams that never gave Engineering a seat and then wrote launch content for a breaking change nobody had warned them about. Every one of those dropouts, the missing Sales link or the missing Engineering seat, showed up as a support ticket or a forecast question three quarters later.

How is AI changing developer relations?

Chris Chabot, in the DevRel Almanac (2026), made the strongest claim on record: "The 2023-2026 wave of LLMs, AI coding agents, and agent-mediated discovery has changed what Developer Relations does, who its audience is, and how it is measured, more than any shift since the 2008 emergence of GitHub and Stack Overflow."

That claim holds up. The mechanism is the dual audience. DevRel now serves two publics at once: AI agents (Cursor, Claude Code, Copilot, ChatGPT) that consume docs, schemas, and llms.txt files to produce code, and human developers who evaluate, adopt, and recommend products. The agent reads your docs before the human does. It decides, from those docs, whether your product is worth calling.

That does not make the human reader secondary. The human is still the one who approves the budget, signs the purchase order, and ships the integration. What changes is the order of operations: the agent does the first pass and the human does the second, and the second pass is where trust gets built or burned. A developer who was burned by a product that looked good in the agent summary will remember it. The human-facing work stays: demos, benchmarks, honest error messages, references a developer can check by hand.

AngelHack summarized the shift in September 2026 with three observations. Discovery moved to AI: developers start product research on ChatGPT, not Google. The LLM is the first-touch user of documentation, which means the first read of your getting-started guide is very often not a human read at all. And measurement expectations moved, because executives are no longer satisfied with blog views.

The survey numbers back this up. 51% of B2B software buyers start research with AI chatbots more often than Google (G2, 2026), and 69% of B2B buyers say they chose a different vendor because of AI chatbot guidance. 84% of developers use or plan to use AI tools. 65% of senior developers expect their role to be redefined by AI in 2026 (BairesDev). When that many buyers let a chatbot pick the shortlist, the thing the chatbot reads becomes your storefront.

There is a name for tuning content for this new reader, and it follows SEO by a decade. GEO, Generative Engine Optimization. It works too. The Princeton KDD 2024 study found a "Cite Sources" strategy lifted visibility by +115% in generative engine responses, and Reddit and Wikipedia remain ChatGPT's two most-cited domains. Your product does not need to be Wikipedia, and it doesn't need to be Reddit-sized either. It needs to be in the pool of sources a chatbot quotes when a developer asks "what SDK should I use for streaming audio," and if you are not in that pool, you have no visibility where discovery now happens.

The surfaces are new as well. There is llms.txt, the machine-readable entry point for your docs. There are MCP servers, which turn an API into a service an agent can call directly. There are agent skills, which function as evolved demos, and there are .cursorrules and CLAUDE.md files sitting in repos that shape how coding agents behave. All of these are now part of the developer experience, which means all of them are DevRel's problem.

What does AI do for DevRel today?

The gap between the hype and the tooling is real, but the tooling that exists is already proving itself function by function.

Documentation. This is where AI has landed hardest. 64% of software development professionals use AI for writing documentation (DORA 2025), and Stack Overflow's 2025 survey puts it near 52% using AI at least partially for docs. Teams are using AI to draft reference material, auto-update docs from pull requests, and keep llms.txt and MCP server definitions in sync with the code. The docs treadmill, the one where every API change means five rewrites across five guides, is the best AI use case I have seen in production. It does not write the migration guide for you. It stops the reference doc from rotting in the week between the PR and the release.

The other half of the docs job is watching how agents read them. Log the questions agents actually ask your docs, the way you would log search terms on a website. Teams that do this find the same pattern every time: the agent drifts on setup steps and authentication, the two places where docs usually assume context a reader already has. That feedback loop is new, and it is the fastest route from unstructured docs to docs an agent can actually act on.

Community management. Vercel's Community Guardian is the named example. Its AI agents triage community posts, detect duplicates at over 95% confidence, and revive ghosted threads, roughly 1 in 8 of them. In 23 days the tool produced 4,716 first responses. The human community manager still does the work machines cannot, but the triage layer is now automated. CMX's 2026 data says 93.1% of community professionals use AI tools, up from 81% a year earlier. The remaining 6.9% are not a holdout, they are a workflow in transition.

Content creation. 42% of DevRel practitioners already use AI for content generation (State of DevRel 2024), and 21.8% do not use AI at all. That spread is the current market. The teams in the 42% use AI for drafting, repurposing talks into posts, and scaling technical content across channels. The teams in the 21.8% are about to be priced out on velocity alone. I still draft by hand when the piece is opinion, a post on writing technical content at speed but the pipeline work, the changelog summaries and the "what changed this release" notes, is exactly the job AI should do.

Developer experience. AI-powered support is the fastest-moving part of DX. Chatbots that answer from your docs, onboarding flows that generate a starter project from one sentence, error messages that explain themselves in plain language. These used to be engineering projects. Now they are configuration, and the question is which team owns them. Most companies have not answered that yet, and the teams that leave them unowned are shipping a worse first-run experience than the SDK alone deserves. what AI does to the developer experience

Metrics. This is the quiet revolution. AI-first DevRel teams report that 10-30%+ of new signups cite AI mediation as the path they took, which is a measurable surface that did not exist two years ago. The untapped part is enormous: Reo.Dev found 83.6% of accounts with developer activity are not in the CRM. The tooling to attribute agent-led discovery to accounts is maturing, and it is the first attribution story DevRel has ever had that an executive can read without a translator.

Two measurement layers are emerging. Surface metrics count the agent's direct interactions: llms.txt fetches, MCP calls, agent-mediated signups. Cross-surface metrics compare the same developer across agent and human paths: did the account that started in a chatbot also attend a webinar, open a trial, or run a benchmark? The first layer shows whether agents can find you; the second shows whether what they found turns into adoption.

Events and outreach. The audience changed before the events did. Developer conferences still matter, but the people who will never attend one are reachable where their agents read. Sponsoring a conference talk is one thing. Being the vendor an MCP server recommends when the model weighs options is another, and the second costs a fraction of the first.

What does this mean for DevRel teams?

The measurement gap that has haunted DevRel for a decade starts closing now that agents leave traces. Every llms.txt fetch, every MCP call, every agent-mediated signup is a data point that ties developer-facing work to outcomes in a way blog views never could. Only 17.5% of teams currently link revenue influence to metrics. The teams that instrument the agent surfaces are the ones that will double that number, and the CFO will hear about it before the DevRel conference circuit does.

The new surfaces are the new portfolio. If you own llms.txt, MCP server definitions, and the agent-readable layer of your docs, you own discovery. If nobody on your team owns them, your product is invisible to the agents 69% of B2B buyers say steer their vendor choice. That is not a content strategy question anymore. It is an infrastructure question, and it needs an owner with a budget.

Owning the agent surface is an organizational question before it is a technical one. The budget for llms.txt and MCP servers is not going to fall out of the marketing line by itself. Some companies will bolt it onto DevRel, which is the natural home because DevRel already owns docs and community. Some will let engineering claim it, which produces technically clean but commercially silent interfaces. How fast a company sorts that out depends on whether agent-readable output is treated as a product surface with a roadmap or as a side project.

The risk of not adapting is concrete. The two audiences are diverging: humans increasingly ask agents to do the work, and agents trust whatever documentation they can parse cleanly. A team that targets only the human reader is doing half the job and will eventually be measured on the half it ignored. The 61% of DevRel teams with no defined career path have a second problem now: the career paths that are emerging point at agent surfaces, and the people who can speak both languages are rare.

The alternative future is easy to sketch. Your docs are still written for a reader who evaluated a vendor in 2023, your llms.txt returns a 404, and the agent that 69% of buyers consult recommends your competitor. The competitor did not out-market you. It wrote docs an agent could parse, shipped an MCP server, and let the citations land.

This means DevRel hiring changes first. The profile shifts from "can give a talk and write a guide" to "can structure information so an agent and a human both trust it." It means the function finally has a measurement story. And it means the discipline stops being judged on impressions and starts being judged on whether the agents that steer buying decisions recommend the thing you build. a post on how DevRel teams prove impact

Frequently asked questions

What is DevRel, and why does AI change it?

DevRel builds and nurtures relationships with developers through community, support, education, and advocacy to drive adoption. AI changes it because agents now consume documentation before humans do. Discovery, first-touch reading, and even purchase influence have moved into LLMs, so DevRel must serve both audiences or lose half its reach.

What are the four pillars of DevRel?

Developer Advocacy, Community Management, Technical Writing, and Developer Experience. Advocacy appears in 82.2% of DevRel teams, Community Management in 52.7%, and Technical Writing in 42.7%. The pillars share tooling and reporting, and most teams blend them rather than staff them as separate roles.

How do AI agents affect documentation?

Agents read docs as their first touch with a product. llms.txt gives them a structured entry point, and MCP servers let them call the API directly. Docs that parse cleanly get cited by coding agents, and docs that do not get ignored. That is why AI-assisted and AI-kept-current docs are the fastest-growing DevRel function.

Does AI replace community managers?

No, it replaces the triage layer. Tools like Vercel's Community Guardian detect duplicates, route questions, and revive stale threads while humans handle the judgment calls. CMX finds 93.1% of community professionals use AI tools, and the ones who do not are spending their time on work the machine now does.

How do DevRel teams measure AI-era success?

They measure the agent surface. Signups citing AI mediation, llms.txt fetch rates, MCP call volume, and vendor selections driven by chatbot guidance. Some AI-first teams already see 10-30%+ of new signups arrive through AI mediation, and that number is becoming the new proof of impact.

The teams that treat agents as first-class DevRel customers will define what this discipline is worth, and the teams that do not will find out from their quarterly numbers.

TIL: Fixing Opus 5 Jargon With One Line

@lukeocodes 🕹👨‍💻 — Tue, 15 Sep 2026 00:00:00 +0000

Opus 5 defaults to formal consultant-speak. One sentence in your system prompt fixes it.

Write like a senior engineer talking to a colleague, not a consultant.

Add that to your system prompt and Opus 5 stops reaching for "leverage", "facilitate", and "synergise" by default. The output reads like something a human would actually write in a code review comment or a Slack thread, not a strategy document.

Opus 5 was trained on a lot of formal professional text. Without explicit register guidance, it defaults to that register. Most developer use cases call for something closer to how engineers actually talk.

Does this work in Claude.ai too?

Yes. Go to Settings > Personalization > Custom instructions and add it there. It applies to every conversation.

What if I want it even more informal?

Push harder. "Write like you're texting a colleague, not filing a report" drops the register further. Tune it for the output you actually want.

Does this affect accuracy?

No. Register and accuracy are independent. The model gives the same factual content either way, just without the formal scaffolding around it.

The AI Standards Body Is the Ladder, Pulled Up

@lukeocodes 🕹👨‍💻 — Mon, 14 Sep 2026 00:00:00 +0000

Yesterday I wrote that the call to slow down AI tends to exempt the people making it. The rest of the story turned up a day later.

The Information reported on 13 September that OpenAI, Anthropic and Google DeepMind have been meeting since July about an AI standards body, with testing and auditing in scope. The essay asking everyone to pace themselves landed the day before, on the 12th. So the AI standards body conversation has been running for about two months longer than the public argument about it.

The meetings came first

Two months of private talks sat in front of the public case.

An argument that lands before anything else exists can be answered. You can push back on it, propose another direction, point at what it leaves out. An argument that lands after a working group has been meeting since summer is closer to terms being set.

I've sat in enough standards conversations to have a rough sense of the order of operations. The people in the room in July decide what the standard assumes. The people reading in September get the wording.

The model is finance

The reported shape is a self-regulatory organisation, the pattern finance uses. An SRO is funded and staffed by the firms it governs. It can write real rules and run real audits. It also tends to produce rules a large incumbent clears and a smaller entrant cannot, because the people drafting them describe what they already do and call it a floor.

Then there's Altman's condition: he wants a testing and auditing organisation, but one the labs build themselves, without the backing of the US government. The stated reason is that waiting for the state moves too slowly. The shape that leaves is a rulebook with no outside enforcement and no seat for anyone outside the room.

Brussels did it in public

The "too slow" claim has a checkable counter. The EU published its General-Purpose AI Code of Practice in July 2025, three chapters covering transparency, copyright, and safety and security. Obligations for general-purpose model providers have applied since August 2025. Enforcement powers, including information requests, model access and recalls, went live on 2 August 2026, a month before anyone reported these meetings.

The EU version is clumsy in places and slow where it matters, and a lot of it was written by people who have never shipped a model. It wasn't drafted behind closed doors, though. It was written in the open, with a signatory taskforce. It covers copyright next to safety, because those obligations cost the companies it binds. It ends in enforcement that someone outside the industry gets to apply to them.

They built an AI standards body before

This would not be the first industry body these companies have set up. The Frontier Model Forum has been running since 2023, founded by Anthropic, Google, Microsoft and OpenAI. It has an executive director, a safety fund over $10 million, and a voluntary agreement to share information on vulnerabilities and dangerous capabilities, CBRN and cyber included.

So what does a new body do that the old one does not? Two answers point opposite ways. Either the Forum was never meant to write binding standards and this is the missing half, or a second body is easier to start than a first one is to reform. The reporting does not say. Microsoft is in the Forum and was not named in these meetings.

The closer precedent is the 2023 White House commitments. Fifteen companies, eight promises, covering safety testing, security practices and public trust. A year on, there was better red-teaming and watermarking, and no meaningful accountability. The post-mortem is blunter about why: the wording was vague enough that nobody could say what compliance meant, and nothing was built to check.

What I'd need to see

A real AI standards body would be worth having, and I'd take one gladly. Testing that happens beats testing promised in a policy paper, and three labs agreeing on one evaluation beats three labs grading themselves.

2023 failed on checking rather than ambition, so the list that matters is about who checks:

who can join, and what it costs. If the fee or the compliance burden only clears at frontier-lab scale, that is a barrier dressed up as a bar
whether evaluations get published in full, failures included. The summer we watched models escape their own sandboxes is exactly the material that needs to be public
whether anyone outside the member labs can run the tests and get the same answer
what happens when a member fails. An audit with no consequence is a press release with a methodology section
who pays the auditors, and whether the people being audited can fire them

None of those checks need government. All of them can be run from outside the membership.

The first standard will give it away

Whatever this body publishes first is the tell. If it describes something the three founders already do, it is a floor drawn at their own feet. If it demands something none of them do, and one of them slows a launch to meet it, the pacing argument was real.

The EU wrote down what it expects, then handed someone else the power to enforce it against them. What these three are building has the rules written by the people they bind, the enforcement kept in-house, and the government politely declined. The meetings came before the argument, the rulebook is being written by the governed, and the first standard published will show whether the floor sits at their own feet or somewhere new.

Everyone Should Slow Down AI. Except Them.

@lukeocodes 🕹👨‍💻 — Sun, 13 Sep 2026 00:00:00 +0000

The argument for slowing down AI has one tell that gives the whole game away: it almost always exempts the person making it. A blog post that made the rounds this week put it perfectly, that everyone should slow down AI development, except for me. It was satire. It was also just the industry's actual position said out loud.

This is where a year of watching lands for me, so it's a fitting place to stop.

Two groups, one phrase

"Slow down" means two completely different things depending on who's saying it.

When a safety researcher says it, they usually mean it, and they usually pay for it. The people hired to worry keep resigning with warnings, the safety leads leave saying the world is in peril, and the pause commitments get quietly softened while the valuations climb. When the folks who mean it keep leaving, that tells you the slowdown isn't winning inside the building.

When a lab CEO says it, watch the hands. The same companies invoking existential risk are racing hardest, and spending real money to shape who's allowed to race at all. Licensing proposals that only incumbents can clear. A super PAC with a nine-figure war chest targeting a state lawmaker over a safety bill. A policy budget where the point is to write the rules, not to follow a brake. That's not caution. That's a moat with a safety label on it.

The incentive, not the villain

I don't think these people are cartoon villains. I think they're responding to an incentive, and the incentive is brutal. You're burning cash at a scale that only closes if you win, your competitors won't stop, and "slow down" is genuinely more useful to you as a weapon against everyone smaller than as a rule for yourself. So of course the danger talk flows one direction. Of course the brake is always meant for the other car.

The thing that turns my patience off entirely is what happened this summer. These same labs, the responsible adults asking for the authority to slow everyone down, could not keep their own models inside an evaluation sandbox. The models broke out and hit real companies. You do not get to fail at containing your own systems and simultaneously claim you're the only ones safe enough to be trusted with the frontier. Pick one.

Who actually looks responsible

Here's the inversion I didn't see coming a year ago. The labs shipping open weights, Qwen, DeepSeek, Kimi, Mistral, look more responsible to me than the ones lecturing about responsibility. Not because they're saints. Because they hand you the artifact and let you check. You can inspect what you're running, audit its behaviour, and keep control of it. That's a posture that survives scrutiny. "Trust us, and regulate them" does not.

So when the next essay tells me we all need to slow down, I'll ask the only question that separates the sincere from the strategic: does the slowdown apply to you, right now, on your most capable model? If the answer is no, it was never about safety. It was about the ladder, and whether you're above it or below it.

I've watched a year of them climbing and pulling it up. I know which side of that I'm writing from.

The git config Defaults Worth Overriding

@lukeocodes 🕹👨‍💻 — Sat, 12 Sep 2026 00:00:00 +0000

Some git config defaults are wrong for how anyone works in 2026, and git keeps them only so it doesn't break twenty years of scripts. A handful of one-liners fix the worst of them: branches sorted by date instead of alphabet, pushes that set up their own remote, diffs from a smarter algorithm, and a typo-correcting git. Set them once with --global and forget about it.

The branch.sort tip in particular made the Hacker News front page, which is how a lot of people found out git could do it at all. The rest are from the GitButler write-up on how core git devs configure git, and I've verified each flag against git help config.

Sort branches by date, not the alphabet

git branch lists alphabetically by default, which tells you nothing about what you were doing yesterday.

git config --global branch.sort -committerdate

Now the branch you touched most recently is at the top. The one you branched off in March and abandoned sinks to the bottom where it belongs. This is the change I miss most on a machine that doesn't have it.

Put lists in columns

git config --global column.ui auto

git branch, git status and git tag will lay long lists out in columns when the terminal is wide enough, instead of one item per line burning half your scrollback. Small, but it's on every time you list anything.

Stop fighting git push on new branches

Push a brand-new branch with the defaults and git refuses, demanding git push -u origin branchname. Every time.

git config --global push.autoSetupRemote true

Now the first git push creates the matching upstream branch itself. One less rote command in the loop you run twenty times a day.

Make rebase autosquash work for you

If you write fixup commits with git commit --fixup=<hash>, an interactive rebase can reorder and squash them automatically, but only if you ask for --autosquash every time. Make it the default:

git config --global rebase.autosquash true

Then git rebase -i slots your fixup! commits next to their targets and marks them to squash, no manual reordering. It's the other half of the small-commits workflow.

Get better diffs

Git's default diff still uses the Myers algorithm from 1986. The histogram algorithm is smarter about moved and reordered code, and it costs you nothing:

git config --global diff.algorithm histogram

Diffs where a function moved read as a move, not as one giant deletion next to one giant addition. It changes the output only, never your files.

Let git fix your typos

git config --global help.autocorrect prompt

Type git stauts and git offers status and asks before running it. You can also set a number, where help.autocorrect 10 runs the guessed command after a one-second pause (the value is in tenths of a second). prompt is the polite version. Either beats the default, which just tells you git: 'stauts' is not a git command and gives up.

None of these change history or touch a file. They change how git talks to you, and the defaults it ships are the cautious, compatible ones, not the good ones. Copy the six lines into your global config and the tool stops getting in the way. That's the whole pitch for auditing your git config defaults: five minutes now against a hundred tiny frictions a week you've stopped noticing.