it started like this, on whatsapp, in the middle of a conversation about something else:
paulo: u should have a blog, if u don’t already
vinny: I do — the linkedin newsletter (recent, focused on claude code) and medium, which is more of a blog really
paulo: none of those is a blog.
paulo: lmao
and he’s not wrong.
newsletter and medium are great distribution channels, each with its purpose. but your own blog is a different category. you own the domain, you own the content, you own the feed. a place to think out loud without medium’s paywall looking over my shoulder and without linkedin’s algorithm deciding if a post about context window deserves to be seen today.
so here it is. first post. and the blank page dilemma: what do I write about first?
what this post is not
it’s not about claude code. not about skills, harness, agents, mcp, context engineering, spec-driven development, or any of the ten brilliant things that showed up in the feed this week. not about the tools in my workflow right now, even though that’s what I’ve mostly been writing about in the newsletter.
this post is about something that sits before all of that. something I use every day and that you probably use without thinking. the format this publication is being written in, right now.
march 15, 2004
that day, on the blog daring fireball, a guy named john gruber published a short post titled “introducing markdown”. along with it, he released a perl script of a little over a thousand lines. the spec for the language fit on one page. the goal was modest: a way to write text that was readable as plain text and could be converted to html without pain. paraphrasing sérgio lopes, kind of like html was in the beginning, before we started painting buttons and centering divs.
gruber wasn’t trying to replace html. he was trying to not have to write html for 90% of the cases where writing html was just “I want a paragraph, a heading, a link, a list, some emphasis”. he wanted a blog you could read without ctrl+shift+i open.
asterisk turns into emphasis. hash turns into heading. bracket-paren turns into link. anyone who has ever received an email with *important* gets the convention on first contact. not a coincidence — the inspiration came from text conventions in email and usenet from the 90s.
there’s a detail I love: the # as heading wasn’t gruber’s idea. it was aaron swartz’s, who in 2002, at 15, had already proposed atx — a structured syntax with # for titles. two years later, at 17, swartz became markdown’s only beta tester. no committee. no w3c. no 400-page spec. just one guy with a problem, a deliberately short specification, and a parser that worked well enough. end of story.
what survived
twenty-two years later, where’s markdown?
it’s in every github readme. it’s in notion, obsidian, discord, slack (their flavor of it), stack overflow, dev.to, medium (internally), jupyter notebook, docusaurus, astro — this blog, actually. it’s on docs.anthropic.com. it’s on claude.ai and chatgpt, which answer in markdown by default without anyone explicitly asking.
where’s the “superior” competitor from 2004? the xml with xsl that would render anything? the wiki markup each wiki reinvented with its own syntax? the forums’ bbcode? the wysiwyg editors that generated 40kb of html for a single bold paragraph?
they still exist. some even work. but what became infrastructure was the asterisk.
in comes text, out comes text
there’s a more recent detail that only became obvious in the last few years, and that’s the main point of this post.
llms — the most-used technology of the decade, moving billions in infrastructure, research, and hype — run on the simplest computational model that exists. the same model as the unix pipe, from 1973.
text in. text out.
you send a string. you get a string. everything else — tool use, multimodality, agents, pipelines, orchestration, mcp — is a layer on top of that core. and the format the core prefers, by default, is markdown.
not an accident. markdown is the format a human can read without rendering, a machine can parse without relying on external context, and that survives being copied between 12 different tools without losing semantics. it’s the format that serves both for you drafting an email and for a 400-billion-parameter model answering your technical question.
claude writes in markdown by default. gpt too. when the model wants to give you a list, it uses -. when it wants to emphasize, it uses **. when it wants to show code, it uses three backticks. it’s the lingua franca between humans and machines — and it was already there, waiting.
what tends to win
I could have opened this blog with a post about context window degradation, about the difference between a skill and an agent, about how to structure a claude.md for a monorepo. all useful.
but starting there would be starting from the ceiling. the floor is simplicity. the formats that win aren’t the most powerful on launch day — they’re the cheapest to adopt, the easiest to read, and the hardest to break.
it’s http over the “sophisticated” connection protocols of the 90s. it’s json over xml. it’s markdown over wysiwyg. it’s the unix pipe over the orchestration frameworks that tried to reinvent it. it’s the natural-text prompt over the structured api with 40 mandatory fields.
one thing I’ve learned from writing code for more than a decade and teaching for almost as long: when a technology survives looking obvious, it’s rarely luck. it’s because someone, at some point, resisted the temptation to add complexity — and that resistance was the hard work. complexity is the path of least resistance for the person designing. simplicity is the path of most resistance, and the one that ages better.
paulo wrote about this a few weeks ago, in a great post called “markdown, abstractions and the future of ux” (portuguese). worth a read. not a coincidence we arrived at this conclusion in parallel — it’s where the water flows.
thanks for the nudge, paulo
and here I am.
the blog opens with a post that’s not about the tool of the month, nor about the framework of the quarter. it’s about watching what survives. and trying, when possible, to build on the right side of that curve.
the next posts will have code, terminal, claude code, strong opinions about generative ai, and whatever else is worth arguing over. but this is the floor. we write in markdown for a reason, and I wanted the first post to be about that reason.