DEV Community: Jatniel Guzmán

Markdown Is Everywhere, and It All Started with a README

Jatniel Guzmán — Wed, 07 Oct 2026 05:33:43 +0000

Original article: Markdown Is Everywhere, and It All Started with a README

Have you noticed that Markdown has slowly become the de facto document format?

I noticed it somewhat by accident. A coworker who doesn't write a single line of code asked me why his text was full of hash signs. He'd copied an answer from an AI assistant into an email. Markdown had found its way to him without him knowing what it was.

For a long time, Markdown meant one thing to me: the README.md at the root of a repo. Now I run into it everywhere, even with people who've never opened a terminal. I wanted to trace it back and understand how we got here.

2004: A format meant to be read as-is

John Gruber introduced Markdown on March 15, 2004, on his blog Daring Fireball. Aaron Swartz, who was 17 at the time, helped him as a beta tester. The original idea was modest: write for the web without typing HTML.

In practice, Markdown was a Perl script built as a plugin for Movable Type, the blogging tool Gruber used. Michel Fortin ported it to PHP within the first year, and Gruber himself recommended that port on the official page. As a PHP developer, I like that detail: Markdown spoke our language almost from day one.

The principle that shaped everything is that a Markdown file should stay readable even if it's never converted. A heading with a hash sign, a list with dashes, bold between asterisks. It borrowed habits people already had from plain-text email and forums.

That choice is why it has lasted. Open a .md file in Notepad, in vim or in a terminal, and you can still follow it. Few formats can say the same.

Fact	Detail
Public introduction	March 15, 2004, on Daring Fireball
Creator	John Gruber
Beta tester	Aaron Swartz, 17 at the time
First implementation	Perl script, Movable Type plugin
First port	PHP, by Michel Fortin
Main inspiration	Plain-text email

2008–2014: The developers' language

Between 2008 and 2014, Markdown became the default writing tool for developers, almost without anyone choosing it.

Stack Overflow adopted it at launch in 2008. GitHub made it the basis for READMEs, then for issues, pull requests and wikis, with its own variant: GitHub Flavored Markdown. Static site generators followed, and IPython notebooks (later Jupyter) used it for their text cells.

Year	Tool	What it brought
2014	MkDocs	Technical documentation written entirely in .md
2014	CommonMark	A spec to unify the dialects
2013	Hugo	Static sites built in Go, content in Markdown
2011	IPython Notebook	Markdown text between code cells
2008	Jekyll	The developer blog as .md files
2008	Stack Overflow	Questions and answers written in Markdown
2008	GitHub	READMEs, issues, PRs, wikis

In a repo, it never stopped at the README. There's CHANGELOG.md, CONTRIBUTING.md, SECURITY.md, and that hidden .github folder holding the issue and pull request templates. Everything around the code gets written in Markdown.

The downside is that everyone adds their own extensions. Tables, checkboxes, syntax-highlighted code blocks: none of that was in the 2004 version. CommonMark was born in 2014 precisely because the same file didn't render the same way from one tool to the next. That problem never fully went away.

2015–2022: One foot out the door

During those years, Markdown started to leave the repo, a little at a time.

Slack and Discord accepted part of the syntax: bold, italics, code. Notion and other editors turned a hash sign typed at the start of a line into a heading. Obsidian, launched in 2020, built its whole approach on .md files stored locally, and drew in plenty of people who aren't developers.

In 2022, Google Docs started detecting Markdown syntax automatically as you type. That was a sign the format wasn't just for technical people anymore. But most people used it without knowing it had a name.

Tool	What it does with Markdown
Slack, Discord	Part of the syntax: bold, italics, code
Notion	Turns typed syntax into formatting
Obsidian (2020)	Notes stored as local .md files
Google Docs (2022)	Automatic detection as you type

2023 onward: AI does the rest

What really sped things up was AI assistants. They answer in Markdown by default: headings, lists, bold, tables, code blocks. Millions of people started reading Markdown every day, often without realizing it.

In July 2024, Google Docs added .md import and export, plus pasting from Markdown (Google Workspace announcement). Google mostly mentions technical writers, but everyone benefits.

On the code side, Markdown even changed readers. We now write files meant for AI agents rather than for people. Every tool had its own (CLAUDE.md, .cursorrules, GEMINI.md…), until OpenAI released AGENTS.md in August 2025 as a shared format. By December 2025, more than 60,000 open-source projects were using it according to OpenAI, which handed it over to the Linux Foundation (announcement).

The README was written for a person discovering a project. AGENTS.md is written for a machine that's about to work on it. Same format.

	README.md	AGENTS.md
Reader	A person	An AI agent
Purpose	Introduce the project	Give instructions for working on it: setup, tests, conventions
Went mainstream	With GitHub, from 2008	Released by OpenAI in August 2025
Adoption	Nearly every GitHub repo	60,000+ open-source projects by late 2025

Native support isn't keeping up

Markdown is everywhere, but it isn't understood everywhere. That's where things get stuck.

I paste a Markdown table into one tool and it looks clean. In another, I get a mess of pipes and dashes. An email drafted with an AI assistant lands in someone's inbox full of asterisks. The same .md file doesn't look the same on GitHub, in VS Code and in Obsidian, because each one handles its own extensions.

LinkedIn, for example, doesn't render it at all. If you want bold text in a post, you have to use Unicode characters, which creates accessibility problems of its own.

The dialect problem isn't new. In 2014, Jeff Atwood, cofounder of Stack Overflow, and John MacFarlane, the creator of Pandoc, published a spec called "Standard Markdown." Gruber objected to the word Markdown being in the name, and the project became CommonMark. A final 1.0 version of that spec still hasn't shipped.

The format has become universal for writing. When it comes to displaying it, every tool still does its own thing.

2025: Windows Notepad and Apple Notes adopt Markdown

This is the clearest sign that Markdown has left the developer world: the two most basic text editors, installed on hundreds of millions of machines, picked it up in the same year.

Windows Notepad reads and writes Markdown

In late May 2025, Microsoft started rolling out a Notepad update to Windows Insiders with lightweight formatting: bold, italics, links, lists, headings. Notepad accepts Markdown input and opens .md files. A button in the status bar switches between the formatted view and the syntax view, and you can turn the feature off in settings.

In November 2025, a new preview added tables, which you can insert from the toolbar or type directly in Markdown syntax.

For a tool that stayed a plain text editor for decades, that's a big change. It didn't go unnoticed either: some users pushed back, attached to a no-frills Notepad.

Apple Notes imports and exports Markdown

Apple took a different approach. With iOS 26, iPadOS 26 and macOS Tahoe 26, Notes can import a .md file and export a note as Markdown. Headings, lists, links, bold and italics are converted to rich text on import. Apple's current documentation also mentions copying a note as Markdown and pasting Markdown into Notes.

You still don't write Markdown in Notes, though. The conversion happens on the way in and on the way out, and in between the note stays in Apple's own format.

	Notepad (Windows)	Apple Notes
Write directly in Markdown syntax	Yes	No
Toggle between formatted and syntax view	Yes	No
.md files	Opened and edited as-is	Imported, converted, exportable
Tables	Yes, in preview since November 2025	Not specified

Where mainstream tools stand

Tool	What it does with Markdown	Since
Notepad (Windows 11)	Renders and edits Markdown, toggles formatted / syntax view, tables	2025
Apple Notes (iOS 26, macOS Tahoe)	.md import and export, conversion to rich text	2025
Google Docs	Detection as you type, then import, export and paste	2022, then 2024
LinkedIn	No rendering	Never

My takeaway: Microsoft made Markdown a native format in its simplest editor, while Apple treats it as an exchange format. Two visions, and still no shared behavior.

So what now?

I don't think we'll ever see a single Markdown that renders identically everywhere. The format won precisely because it was simple and anyone could extend it. That freedom comes at a cost, and we pay it every time we copy and paste.

What strikes me is how far it's come. Twenty years ago, it was a trick to avoid writing HTML. Ten years ago, it was our format, the one living in our repos. Today my clients receive it without knowing it, and I write .md files to explain my projects to AI agents.

Until the tools catch up, I write in Markdown pretty much everywhere. Even in places where nobody will read it as Markdown.

Sources

How Markdown took over the world, Anil Dash, January 2026
Markdown, official page on Daring Fireball, John Gruber
Standard Markdown becomes CommonMark, LWN.net, September 2014
Text formatting in Notepad begins rolling out to Windows Insiders, Windows Insider Blog, May 2025
Notepad update begins rolling out to Windows Insiders, Windows Insider Blog, November 2025
Import, export, and print notes on Mac, Apple Support
How to import and export Markdown with Apple Notes in iOS 26, AppleInsider
Import and export Markdown in Google Docs, Google Workspace Updates, July 2024
OpenAI co-founds the Agentic AI Foundation, OpenAI, December 2025

- AGENTS.md Emerges as Open Standard for AI Coding Agents, InfoQ, August 2025

Original article: Markdown Is Everywhere, and It All Started with a README

How Uber exposes existing APIs to AI agents through its MCP Gateway

Jatniel Guzmán — Mon, 05 Oct 2026 05:13:00 +0000

onnecting an AI agent to one backend service is manageable. Doing it across hundreds of teams raises questions about ownership, permissions, protocol compatibility, and how agents find the right tools.

Uber Engineering describes its approach in Designing MCP Gateway: Uber's MCP Management Platform. At the time of publication, the platform hosted more than 800 MCP servers and 5,000 tools.

This article summarizes the design choices that caught my attention as a backend developer. The implementation and diagrams are Uber's.

1. Put existing APIs behind a shared gateway

Uber already has internal services using HTTP, gRPC, and TChannel. Its gateway makes those APIs accessible through the Model Context Protocol (MCP), without requiring changes to the downstream services.

The architecture separates two responsibilities:

The MCP Registry, or control plane, stores tool definitions, ownership, and enablement settings.
The Proxy Gateway, or data plane, handles requests and translates between MCP and downstream protocols.

For each virtual MCP server, the gateway exposes a /<service-name>/mcp endpoint. Handlers translate requests into the downstream format and convert responses back into MCP-compatible results. Native MCP servers can also sit behind the gateway.

Figure 1 from Uber Engineering's original article: MCP Gateway, APIs as tools.

The part I find useful here is API reuse. Teams can expose capabilities they already maintain, while the shared gateway handles MCP integration.

2. Generate tool definitions from service contracts

Manually maintaining thousands of tool definitions would create a substantial maintenance burden. Uber uses AutoCrawler, a discovery system built on Cadence workflows.

For services defined with Protobuf or Thrift, it reads the interface definitions, extracts methods and schemas, and generates MCP tool definitions. An LLM helps write descriptions using the schemas and documentation comments.

Native MCP servers follow a different path: AutoCrawler detects their heartbeat signals and calls listTools to retrieve their tools and schemas.

Figure 2 from Uber Engineering's original article: AutoCrawler.

Service contracts provide a starting point for the integration. Owners can then review the generated descriptions before agents use them.

3. Require owner approval before enabling tools

Every discovered server and tool starts disabled. The team responsible for the service must review and explicitly enable it.

Changes to tool descriptions produce configuration diffs that require owner approval. Previous configurations remain available for rollback.

At execution time, the gateway applies authorization policies with tool-level granularity and redacts sensitive data from responses. Its runtime periodically refreshes configuration in memory, so configuration changes can take effect without a service restart.

This is a detail I would carry into a smaller implementation: generating a tool definition and granting access to that tool should be separate operations.

4. Discover tools progressively and keep responses small

Thousands of tools create another problem: their descriptions and schemas can consume the model's context window.

Uber addresses this with Omni MCP, a single proxy server that supports progressive discovery through four tools:

discover_server
discover_tools
get_tool_schema
invoke_tool

An agent can search for a relevant server, inspect its tools, and retrieve a schema when needed.

The gateway also supports response projection. A caller specifies the fields it needs, and the gateway trims the response accordingly. That distinction matters: the article describes filtering at the gateway, so this should not be assumed to reduce the downstream service's work.

For coding agents, Uber offers Code Mode through its aifx CLI. Agents can discover and call tools, write results to files, and inspect selected content before bringing it into model context. Uber reports that this is its default approach for MCP use in coding agents.

What I would take into a smaller project

I would start with a few existing APIs, explicit tool ownership, and a review step before enablement. I would also measure how much context the tool schemas and responses consume before expanding the catalog.

Uber's scale explains the investment in automated discovery and a centralized platform. For a smaller backend, these individual design choices are still useful to evaluate.

Read the full Uber Engineering article for the runtime diagrams, registry screenshots, and third-party integration details.

Jatniel - Full-stack Developer
jatniel.dev

Symfony and PHP 8.4: Modernizing Without Rewriting Everything

Jatniel Guzmán — Fri, 14 Aug 2026 21:30:40 +0000

Upgrading a Symfony application to PHP 8.4 doesn't have to mean rewriting half the codebase.

For applications that have been running in production for years, the real challenge is deciding what to modernize, what to keep, and how to move forward without turning a technical upgrade into a long and risky project.

PHP 8.4 brings useful features such as property hooks, asymmetric visibility, native lazy objects, and the #[Deprecated] attribute. It also integrates particularly well with recent Symfony versions.

But a successful migration is less about adopting every new language feature and more about:

checking dependencies and platform requirements
addressing deprecations
running automated tests
validating workers and scheduled tasks
reviewing logs after deployment
modernizing the parts of the codebase where it actually adds value

In the full article, I look at PHP 8.4 from a Symfony perspective and explain why a gradual migration is often a better strategy than a complete rewrite.

Read the full article on my blog: jatniel.dev/en/bytes

[Boost]

Jatniel Guzmán — Thu, 23 Jul 2026 08:48:04 +0000

Javier Eguiluz

Jul 22

New in EasyAdmin 5.3: A Modernized Sidebar, Symfony Reprise, and More Theming Groundwork

#easyadmin #symfony

5 min read

TypeScript 7.0 Is Here: The Compiler Is Much Faster

Jatniel Guzmán — Sun, 12 Jul 2026 06:00:44 +0000

TypeScript 7.0 is now officially available as a stable release, and this is one worth paying attention to.

Not because it introduces a flashy new syntax feature or another configuration option, but because it improves something developers feel every day: waiting.

The TypeScript compiler has been rewritten in Go. The goal is clear: take advantage of native code, multithreading, and better parallelization to make builds, type checking, and the editor experience much faster.

Microsoft says TypeScript 7 is usually between 8x and 12x faster on large projects. In some cases, with more parallelization, the results go even higher.

The Numbers Are Pretty Clear

Microsoft published benchmarks on several well-known open-source projects using TypeScript 7’s default configuration:

Project	TypeScript 6	TypeScript 7	Speedup
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

The VS Code result is especially impressive: a build that took more than two minutes now takes just over ten seconds.

And when increasing the number of workers with --checkers 8, VS Code goes down to 7.51 seconds, which is 16.7x faster than TypeScript 6.

Another interesting point is that this speedup does not seem to come with higher memory usage. In the projects Microsoft measured, memory usage actually went down, between 6% and 26% depending on the project.

The Biggest Difference May Be in the Editor

For me, the most important part is not just faster builds.

The real improvement is the feedback loop while coding.

TypeScript 7 also comes with a new language server based on LSP. In practice, the things we use all day should feel faster: autocomplete, real-time errors, type hovers, code navigation, find references, and more.

Microsoft gives a good example: in the VS Code repository, opening a file with an error used to take about 17.5 seconds before showing the first diagnostic. With TypeScript 7, it takes less than 1.3 seconds.

On a small project, that is nice.

On a large codebase or a monorepo, that can really change the way you work.

What Teams Are Seeing on Real Projects

TypeScript 7 is not only coming with internal benchmarks. Microsoft says this version has been tested for more than a year on large codebases, both inside and outside Microsoft.

Some of the companies mentioned include Slack, Canva, Figma, Vercel, Notion, Sentry, and Bloomberg, as well as Microsoft teams working on Teams, Office, PowerBI, and Xbox.

A few numbers stand out:

Slack reportedly reduced type checking in CI from 7.5 minutes to 1.25 minutes.
Canva went from 58 seconds to 4.8 seconds before seeing the first error in the editor.
One Microsoft team reported saving around 400 hours of CI time per month.
The new language server reduced failing commands by more than 80% and crashes by more than 60% compared to TypeScript 6.

These numbers matter most when you work on large projects. When type checking gets too slow, teams often push it to CI or run it less often. If TypeScript 7 makes it practical again during local development, that is a real productivity win.

Installation

To install TypeScript 7:

bash id="g4p2wc" npm install -D typescript

Then run:

bash id="fkg78d" npx tsc

By default, TypeScript 7 uses 4 workers for type checking. You can adjust this with --checkers:

bash id="kz618u" npx tsc --checkers 8

Of course, this should be tested depending on your machine and your project. More workers can make builds faster, but they can also increase memory usage. On a powerful development machine, it is worth trying. On a limited CI runner, it is better to measure before changing anything globally.

The Main Thing to Watch

Not every part of the ecosystem can move to TypeScript 7 immediately.

TypeScript 7.0 does not yet expose a stable programmatic API. That API is expected in TypeScript 7.1.

This affects tools and frameworks that depend directly on TypeScript, such as Vue, Astro, Svelte, MDX, some Angular workflows, Volar, and typescript-eslint.

For those cases, Microsoft recommends running TypeScript 6 and TypeScript 7 side by side for now.

For example:

json id="nmbg7p" { "devDependencies": { "@typescript/native": "npm:typescript@^7.0.2", "typescript": "npm:@typescript/typescript6@^6.0.2" } }

The idea is simple: keep TypeScript 6 for tools that still need its API, and use TypeScript 7 where possible to benefit from the performance improvements.

My Take as a Developer

I find this release really interesting because it does not try to get attention with visible new features. Instead, it solves a very real problem: waiting.

Waiting for type checking to finish, waiting for the editor to show errors, waiting for CI to confirm something we would rather know locally… these small delays add up quickly on large projects.

TypeScript 7 does not change the way we write TypeScript overnight. But it can change how fast we work with TypeScript.

And for a tool that is so widely used in modern development, that is a big deal.

Congratulations to the TypeScript team for this work. Rewriting such a central compiler in Go is impressive, and I would not be surprised if it inspires other languages and development tools.

Source: Microsoft’s official announcement, “Announcing TypeScript 7.0”.

Originally published on jatniel.dev.

TypeScript 7 RC: the compiler rewritten in Go, around 10x faster

Jatniel Guzmán — Sun, 21 Jun 2026 11:39:50 +0000

Microsoft just shipped the Release Candidate for TypeScript 7, with the stable release expected next month. And the big deal, for once, isn't a new syntax or yet another config flag. It's that the entire compiler has been rewritten in Go.

Over the past year, the team ported the existing codebase (until now, TypeScript that compiled to JavaScript) to Go. It was done methodically from the current implementation, not rewritten from scratch, so the type-checking logic stays structurally identical to TypeScript 6. You don't change how you write TypeScript, you just get more speed.

Why it's so fast

The speedup isn't magic, it comes from the language. Go compiles to native code and takes advantage of parallelism through shared memory. The result Microsoft reports: builds that are often around 10 times faster than TypeScript 6. That number comes from their own measurements and from companies like Figma, Bloomberg, Vercel, Notion, and Slack, which have been testing pre-release builds for over a year and report similar gains.

And it doesn't stop at the tsc command line. The Language Server Protocol (LSP), the thing that powers autocomplete, type hovers, and real-time errors in your editor, runs on the same foundation. So the editor responds much faster, and that's probably what you'll feel most day to day on a large project.

The repo is open source (Apache 2.0, more than 25,000 stars on GitHub) and about 85% Go. For a project this size, and coming from Microsoft, betting on Go was not the obvious choice.

TypeScript 6, the step you shouldn't skip

TypeScript 7 inherits TypeScript 6's defaults, and anything deprecated in 6 now turns into a hard error. Since 6 is still recent, plenty of projects will need to adapt.

That's exactly what 6 is for: it doesn't bring big new features, it sets the stage. It warns you about the options and syntax that go away in 7. The team's advice, and mine: move to 6 first, clear those warnings, and the jump to 7 happens without surprises.

A few examples of what becomes a hard error in 7: target: es5, moduleResolution: node, baseUrl, or module: amd/umd/systemjs. On the defaults side, strict is now true and module is esnext. Two changes catch people off guard and are worth a look: rootDir now defaults to ./ (you'll often need to point it back to ./src), and types defaults to [], so you have to list your @types packages explicitly.

Running 6 and 7 side by side

Not all of your tools will be compatible with 7 overnight. typescript-eslint, for example, imports the typescript package directly, and the stable programmatic API won't land until TypeScript 7.1, a few months from now.

Microsoft set this up so the two versions can live together without stepping on each other. A compatibility package, @typescript/typescript6, ships a tsc6 binary and re-exports the 6 API. The trick is to use npm aliases in your package.json:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript-7": "npm:typescript@rc"
  }
}

The typescript package your linter looks for actually points to 6, which is stable and what the tools expect, while npx tsc uses 7 for the rest of the project. It's a textbook parallel change: 6 keeps things tidy on linting, and 7 makes everything else faster. Tooling compatibility should settle down around 7.1.

Parallelization, checkers, and watch mode

TypeScript 7 parallelizes several steps: parsing, type-checking, and emit. Parsing and emit split easily across files. Type-checking is trickier because of dependencies between files, so the team spins up a fixed number of workers that share the work deterministically: same input files, same output results.

By default you get 4 workers, adjustable with --checkers. If you have more cores you can raise it, at the cost of more memory. On a tight CI runner, lower it instead.

There's also --builders, to build several projects in a monorepo at once. Watch out, the effect multiplies with --checkers: with --checkers 4 --builders 4 you can have up to 16 type-checkers running. And --singleThreaded forces a single thread, handy for debugging or for comparing 6 with 7.

Watch mode was rebuilt on top of Parcel's file watcher, also ported to Go. No more expensive polling over big node_modules folders, and file watching is much lighter.

Commands to try it

Install the RC:

npm install -D typescript@rc

Check the version:

npx tsc --version
# Version 7.0.1-rc

Compile like always, just faster:

npx tsc

Tune the number of type-checking workers:

npx tsc --checkers 8

Force a single thread to compare with 6:

npx tsc --singleThreaded

Install 6 and 7 at the same time with aliases:

npm install -D typescript@npm:@typescript/typescript6
npm install -D typescript-7@npm:typescript@rc

And to live on the nightlies:

npm install -D @typescript/native-preview
npx tsgo --version

The nightly binary is still called tsgo. Once 7 ships stable, everything moves back to the typescript package.

In short

TypeScript 7 doesn't touch your code or the typing rules, it goes after speed, both in the build and in the editor. The sensible plan: move to TypeScript 6 now to clear the warnings, test the RC in parallel on a real project, and report bugs on the microsoft/typescript-go repo. Stable lands next month.

Official announcement: Announcing TypeScript 7.0 RC.

Originally published on jatniel.dev.

Cursor Launches Origin, a GitHub Rival, Right Before SpaceX Buys the Company

Jatniel Guzmán — Wed, 17 Jun 2026 15:19:16 +0000

Cursor just announced Origin, a code storage and Git hosting platform. In one line: a direct competitor to GitHub. It ships this fall, and for now there's only a waitlist. So far, nothing wild in a market where everyone wants a piece. What makes it interesting isn't the what. It's the when.

From editor to platform

Some context first. Cursor, made by Anysphere, started as a fork of VS Code with AI built in. In a few years it went from a toy to the editor a lot of us open every morning.

In December 2025, Cursor bought Graphite, a startup focused on code review: stacked pull requests, merge queues, structured reviews. With Origin, the last piece falls into place, which is hosting. Cursor doesn't just want to be the place where you write code. It wants to be the place where it's stored, reviewed, and merged.

They're blunt about the pitch. GitHub was built for humans: one developer, a few commits a day, a pull request, a coworker who reviews it. Origin starts from a different assumption. Soon, Cursor says, it won't be one person pushing code. It'll be dozens of agents at once, cloning, branching, merging, and fixing their own mistakes in parallel. Origin is built to handle that load, and it throws in AI-powered automatic merge conflict resolution on top.

The numbers they showed on stage make the point: about 22 commits per second in a single repo, close to 300,000 clones and tens of thousands of pushes an hour. Numbers that make no sense at human scale, and all the sense in the world if you point an army of agents at the same repo.

You could call the bet early. Most of us don't have fifty agents running around the same project. But the idea isn't crazy, and it explains why Cursor dropped so much money on Graphite six months ago.

The detail that changes everything

Here's where it gets interesting. Just a few days before Origin, SpaceX signed a deal to buy Cursor for $60 billion, all in stock. Cursor becomes a wholly owned part of SpaceX once the deal closes, which is expected this fall. And it's worth remembering that SpaceX absorbed xAI, Musk's AI company, earlier this year.

So by the time Origin ships, it'll belong to the same group as xAI. A group that already trains its own models: Cursor and xAI have confirmed they're working together on one that's coming soon, described as trained from scratch on more than a hundred thousand GPUs.

The question all this raises

Line up the pieces. You write your code in Cursor. You host it on Origin. And the whole thing belongs to a company that trains top-tier AI models.

I'm not saying it's a trap, and I'm not assuming anyone has bad intentions. But the question is worth asking plainly: where does my code live, and who gets to use it? We already ask it about GitHub and Copilot, and the answers aren't always reassuring. The difference with Origin is that the whole chain ends up under one roof: the tool that writes, the place that stores, and the model that learns.

When one company controls all three links, the line between "hosting your code" and "learning from your code" comes down to the terms of service. And terms of service get rewritten.

What this means for a freelancer

On the practical side, I mostly work on client projects: Symfony, Laravel, PrestaShop, APIs. Not all the repos are mine, and several clients have strict rules about where the code can live. Switching platforms isn't a technical tweak you knock out on a Friday afternoon. It's a decision that touches confidentiality, compliance, and sometimes the contract itself.

For now I'm staying on GitHub. Not out of loyalty: GitHub has its own problems, and its recent outages made that clear. But trading a dependency on Microsoft for one on SpaceX isn't a win. It's just another giant, with its own priorities.

What I'd do in your shoes

Origin is worth a look, especially if you're starting to run agents in production and GitHub is choking at scale. I'll probably join the waitlist, if only to see how it actually works. There's still a lot we don't know: pricing, importing and exporting repos, how it plays with GitHub and GitLab, what it offers companies. What's up right now is a landing page, not documentation.

But before I move a single serious repo, I want to read those terms, know what happens to the data, and wait for the deal to actually close. You don't get control of your code back after the fact. You protect it before you click "migrate."

Originally published on my blog. Read more of my writing on PHP, freelancing, and dev tooling at jatniel.dev.

Claude Fable 5 and Mythos 5 are here.

Jatniel Guzmán — Tue, 09 Jun 2026 19:55:09 +0000

Claude Fable 5 and Mythos 5 are here.

Same model, two names. What sets them apart isn’t capability, but guardrails.

Fable 5 is available to everyone. Mythos 5 remains restricted to Project Glasswing partners, with some safeguards removed in specific domains.

The detail that matters for developers: this isn’t a model that burns through tokens. Quite the opposite.

On a spreadsheet benchmark suite, it outperforms Opus 4.8 at every effort level, using fewer turns and completing tasks 25–30% faster.

It’s included at no extra cost for Pro, Max, Team, and Enterprise users until June 22. After that, it switches to usage-based pricing.

They’re giving you the most powerful model they’ve ever released… for two weeks. Enjoy it while it lasts—on June 23, the free ride is over.

Definitely worth testing properly before forming an opinion. 🧐

Original post : Claude Fable 5 and Claude Mythos 5

Jatniel
Senior freelance PHP developer. Symfony, Laravel, PrestaShop.
Web applications, REST APIs, and e-commerce.
jatniel.dev

Six months of AI in 2026, and a whole lot of noise

Jatniel Guzmán — Sun, 07 Jun 2026 20:51:35 +0000

This week, two major players also hit the brakes and changed their tune.

Six months of AI in 2026, and honestly, things went off in every direction. Almost every week, a new model promising to "change everything": GPT-5.4 and 5.5, Claude Opus 4.6 through 4.8, Gemini 3.5 Flash, Kimi, DeepSeek V4, MiniMax M3, Gemma 4.

But under the marketing, the real shift is somewhere else: we moved from the chatbot that answers to the agent that actually does things. And it comes with a bill. GitHub Copilot just switched to usage-based pricing, and part of the community is freaking out over the prices.

The part that stuck with me, though, is the turn this week. Anthropic is now calling for an industry-wide pause, and Sam Altman, who warned a year ago that AI would wipe out junior jobs, now admits he was "pretty wrong."
The idea taking hold isn't "AI is going to take your job." It's more uncomfortable: AI is going to change which parts of your job actually have value.

I broke down the full six months, the dates, the sources, and what it actually means for us as devs, in the full article.

Read the whole thing here: https://jatniel.dev/en/bytes/six-months-of-ai-in-2026-and-a-whole-lot-of-noise

If it resonates, feel free to share it.

Claude Opus 4.8: what actually changes when you code for real

Jatniel Guzmán — Thu, 28 May 2026 21:33:13 +0000

Anthropic has just released Claude Opus 4.8.

The price stays the same, Claude Code gets a few new features, and the overall message is pretty clear: better coding reliability, stronger support for long-running tasks, and more useful agents for complex workflows.

I would not call it a revolution.

But as a developer, there are a few things here that are definitely worth looking at.

Reliability is becoming the real topic

The part that caught my attention the most is this: according to Anthropic, Opus 4.8 is about 4 times less likely to miss a bug in code it has just written.

There is another point I find even more important: the model seems better at saying when it is unsure, instead of confidently telling you that everything is fine.

When you work with AI-generated code on a regular basis, that matters.

I would much rather have a model say “this needs review” than one that is wrong with perfect confidence.

Effort control

Another interesting addition is effort control.

Next to the model selector, you can now choose how deeply you want Claude to work on a task. By default, Opus 4.8 runs in high mode, but you can push it to extra or max for more complex work.

The idea is practical: not every task needs the same level of reasoning.

For a small fix, you do not need to bring out the heavy machinery.

For a delicate refactor, a technical migration, or an agent working for a long time across a codebase, asking for more depth can make sense.

That said, it is important not to confuse things: this setting does not replace choosing the right model. It changes how Opus approaches a specific task.

React more : Claude Opus 4.8: what actually changes when you code for real

[Boost]

Jatniel Guzmán — Mon, 22 Sep 2025 15:01:53 +0000

Javier Eguiluz

Sep 22 '25

New in EasyAdmin: Custom Admin Routes

#easyadmin #symfony #php

3 min read

[Boost]

Jatniel Guzmán — Mon, 22 Sep 2025 14:54:33 +0000

arasosman

Aug 15 '25

PHP Developer Salary Guide 2025

#php

9 min read