Coder Legion - Recent posts tagged content

Can You Belong to a Community Without Finding Your Audience?

Thu, 22 Oct 2026 19:18:09 +0000

Lately, I have been questioning whether CoderLegion is the right platform for the content I create.

As a game developer sharing the progress of Life of Alex, I write about building mechanics, designing environments, solving problems, and learning through development. These are subjects I care about, and documenting them is part of how I contribute to the community.

However, the traffic reaching that work has been limited. That has made me consider a question that might be familiar to other creators: how do you recognize when a platform is valuable to you, but might not be the best fit for your content?

My experience with CoderLegion makes that question particularly interesting. I am a leader here, I have become a recognized voice, and have had the opportunity to share my career journey through an interview. Those things matter to me. They are meaningful reasons to remain involved.

At the same time, recognition within a community and readership of your work are different things. You can feel welcomed and appreciated while still wondering whether what you publish is reaching people interested in the subject.

I do not expect a role or a badge to guarantee an audience. Readers choose where to spend their time, and contributors have to earn that attention. But when you regularly share work and see limited traffic, it is reasonable to assess whether the subject, format, and audience are connecting.

Game development can sit in an unusual position within broader technical communities. A development update might involve visual design, player experience, animation, or the gradual construction of an environment. Its value may be harder to communicate through a headline than a tutorial that answers a specific technical question.

That is one possible explanation, rather than a conclusion about CoderLegion’s audience. Presentation, discoverability, and my own approach could also play a part. Low traffic tells me that something is not connecting; it does not tell me exactly why.

There is also a practical limit to how far I want to adapt. I am happy to improve how I explain my work, provide more context, and make an article more useful to readers. However, I still want the subject to reflect the game I am actually building. If every post becomes a search for a more popular topic, the development journal gradually loses its purpose.

For now, I want to remain part of CoderLegion while being realistic about what publishing here brings. A platform can have value through its relationships, conversations, and opportunities, even when it contributes little traffic. The question is how much time to invest in each of those benefits, particularly when that time also comes out of development.

I would be interested to hear how other contributors approach this. Have you found an audience by changing how you present your work, or discovered that a community you enjoy simply has limited interest in your particular subject?

I have tried everything under the sun: taking interest and contributing to other people's passions or careers, I created discussions over different topics, i posted more often and more rare, tried changing tags... I am at a loss...

What helps you decide whether to keep adapting, publish less frequently, or put more effort into another platform?

How to Streamline Your Blogging Workflow with Automation Tools

Tue, 29 Sep 2026 13:10:42 +0000

Running a blog involves far more than writing articles. A typical publishing process can include topic research, content planning, drafting, editing, SEO checks, image preparation, publishing, social media promotion, analytics, and follow-up tasks. When every step is handled manually, even a small publishing schedule can consume a significant amount of time.

Automation tools can reduce the repetitive work involved in this process. They can move information between applications, trigger tasks when specific events occur, schedule content for publication, and distribute new posts across multiple channels.

The objective is not to automate every part of blogging. Writing, editorial judgment, fact-checking, and strategic decisions still require human oversight. The practical goal is to automate predictable administrative tasks so more time can be spent producing useful content.

Start by Mapping the Blogging Workflow
Before connecting a collection of automation tools, document how a blog currently operates.

A basic workflow might look like this:

Find a topic.
Research the subject.
Add the idea to a content calendar.
Create an outline.
Write the article.
Edit and fact-check it.
Optimize the headline, metadata, links, and images.
Upload the article to the content management system.
Schedule or publish it.
Promote it on social media.
Record performance data.
Identify opportunities for future updates.
The most useful automation opportunities are usually the repetitive transitions between these stages.

For example, a new content idea could automatically create a task in a project-management database. When an article reaches an approved status, an automation could notify the editor. After publication, another workflow could send the article to a social media scheduling platform.

Mapping the process first prevents a common mistake: adding automation without understanding the workflow it is supposed to improve.

Use a Central Content Calendar
A content calendar provides a single location for tracking ideas, assignments, deadlines, publishing dates, and article status.

Tools such as Notion can be connected to automation platforms so that database activity triggers actions elsewhere. Zapier, for example, can use new Notion database items as triggers and create new database items or pages as actions.

A blogging database could include fields such as:

Article title
Primary keyword
Content category
Writer
Editor
Status
Draft deadline
Publication date
Target URL
Social promotion status
Update date
The important point is consistency. Every article should move through the same defined stages rather than relying on scattered notes, email messages, and spreadsheets.

Automate Repetitive Administrative Tasks
Automation platforms are particularly useful when a task follows a predictable trigger-action pattern.

Zapier describes its workflows as combinations of triggers and actions. A trigger starts the workflow, while subsequent actions perform predefined tasks. Its current platform supports thousands of applications and also provides AI-assisted workflow creation.

Consider a simple example. A writer changes an article's status in a content database from "Draft" to "Ready for Review." That change could trigger a notification to an editor.

Another workflow could create a task when a new content idea is added to a database.

These automations do not write the article. They eliminate repetitive coordination work.

That distinction matters. Automation should handle predictable processes while editorial decisions remain under human control.

Connect Your Content Calendar to WordPress
WordPress provides built-in scheduling, allowing posts and pages to be configured for publication at a future date and time. The WordPress.com documentation also notes that the site's timezone affects when scheduled content is published.

For publishers who want a more connected workflow, WordPress can also be integrated with automation platforms.

Zapier's WordPress integration supports triggers and actions associated with posts, comments, users, and media. This can allow events inside WordPress to trigger activities in other applications.

For example, a content operation could use an automation to:

Create a WordPress draft from an approved content record.
Notify a team when a post is published.
Record a newly published URL in a content database.
Trigger a downstream social media workflow.
The automation should be tested carefully before being used for production publishing. A faulty workflow can duplicate content, publish incomplete drafts, or send incorrect information to other platforms.

Automate Social Media Distribution
Publishing an article is only one part of content distribution. Social media promotion can introduce another series of repetitive tasks, particularly for publishers managing multiple channels.

Buffer provides a WordPress integration that can automatically add newly published blog posts to a social media queue. Its documentation describes a workflow in which a new WordPress post can be sent to Buffer automatically after publication.

Buffer can also connect with automation services such as Zapier, Make, IFTTT, and n8n. These integrations can use triggers and actions to create posts or ideas and move information into Buffer without requiring every step to be performed manually.

A practical workflow could therefore look like:

New WordPress post → automation trigger → social media draft → scheduled distribution.

The editorial team can still review the social copy before publication. Automation simply moves the information from one stage to another.

Use AI Where It Saves Time, Not Where Accuracy Matters Most
AI tools can assist with several parts of a blogging workflow, including brainstorming, outlining, summarization, headline variations, content repurposing, and routine editing.

However, AI-generated material should not bypass editorial review. Automated output can contain factual errors, unsupported claims, incorrect terminology, or information that is no longer current.

A more reliable workflow is to use AI as an assistant within defined stages.

For example:

Topic research → human verification → AI-assisted outline → human-written or reviewed draft → fact-checking → editing → publication.

This approach separates productivity gains from editorial responsibility.

AI can also be incorporated into broader automation workflows. Zapier currently provides AI features that can help users create workflows and troubleshoot workflow errors, while its automation system remains based on defined triggers and actions.

Build Automated Content Notifications
Team communication is another area where automation can reduce unnecessary manual work.

Suppose an article moves into an "Approved" status. Instead of an employee checking the content calendar repeatedly, the workflow could send a notification to the person responsible for publication.

Similar triggers could notify a team when:

A draft is ready for editing.
An article has been approved.
A scheduled publication date is approaching.
A post has gone live.
A social media draft has been created.
A required content field is missing.
These small automations become more valuable as the publishing operation grows.

Automate Reporting Without Automating the Analysis
Blogging produces large amounts of performance information. Traffic, search visibility, conversions, engagement, and social activity can become difficult to track manually.

Automation can help collect or organize this information, but the interpretation should remain deliberate.

For example, a workflow might transfer selected campaign information into a reporting spreadsheet or database. The content team can then review the data and decide which topics deserve additional coverage or updating.

The goal is not to create a dashboard full of numbers. The goal is to reduce the administrative work required to obtain the information needed for editorial decisions.

Keep Human Review at Critical Checkpoints
The biggest mistake in blogging automation is treating automation as a replacement for editorial judgment.

Several checkpoints should remain under human control:

Factual verification
Source evaluation
Legal or compliance review
Final editing
Brand voice
Sensitive topics
Claims about products or companies
Final publication approval
Automation should make these checkpoints easier to manage, not eliminate them.

A useful principle is simple: automate the process around the content, but maintain human responsibility for the content itself.

Start With One Workflow
A blogging operation does not need dozens of automations on the first day.

Start with one repetitive process that occurs frequently and has a clear trigger and predictable outcome.

For example:

New blog post published → automatically create a social media draft.

Once that workflow operates reliably, another can be added:

New approved content idea → automatically create an assignment in the project-management system.

Then another:

Article marked ready for review → automatically notify the editor.

This incremental approach makes it easier to identify errors and measure whether an automation is actually saving time.

The Goal Is a More Efficient Publishing System
Blogging automation works best when it removes repetitive administrative work without removing editorial control.

A modern workflow can combine a content database, an AI assistant, an automation platform, WordPress, and a social media scheduling service. Notion can manage structured content information, Zapier can connect applications and trigger actions, WordPress can handle scheduled publishing, and Buffer can help distribute published content across social channels.

The most effective setup will depend on the publication's size, publishing frequency, team structure, and existing software.

The important first step is not buying more software. It is identifying which blogging tasks are repetitive, predictable, and time-consuming. Those tasks are the strongest candidates for automation.

Once those processes are documented and connected, bloggers and content teams can spend less time moving information between applications and more time researching, writing, editing, and improving the content that audiences actually read.

SEO-Friendly Web Design Checklist: Architecture Before Aesthetics

Sun, 30 Aug 2026 15:50:00 +0000

Direct answer: An SEO-friendly design starts with an agreed page inventory, crawlable navigation, stable URL and template rules, equivalent mobile content, responsive media, relevant structured data, and a production-like validation gate. Visual design then works inside that system. It cannot repair important pages that do not exist, links that crawlers cannot follow, or templates that publish the wrong metadata at scale.

Narrow job: This checklist defines the pre-launch design and development contract. Use the static versus dynamic website guide to choose the publishing architecture. Use the site migration checklist when an existing site, domain, or URL set is being replaced.

1. Map page jobs before drawing wireframes

Start with the questions customers need answered and the actions the business needs them to complete. Convert those jobs into a page inventory before deciding how the homepage looks. A visual sitemap full of generic labels such as Services, Solutions, and Resources is not enough. Each planned URL needs a distinct purpose, owner, content requirement, and next route.

Design input	Decision to record	Acceptance evidence
Page inventory	Which search or customer job each page owns	No two pages compete for the same primary task without a reason
Hierarchy	How pages group into sections and parent routes	A new visitor can identify location and next action from any landing page
Template set	Which page types share fields and behavior	One representative instance exists for every important template
Publishing ownership	Who can create, update, retire, and validate each type	The real owner can complete the workflow without bypassing controls
Launch gate	What must pass before the production switch	Status, rendering, links, metadata, schema, mobile, and performance are recorded

Google's SEO Starter Guide recommends organizing a site logically so users and search engines can understand how pages relate. The practical deliverable is not a promise that every page will rank. It is a maintained map showing why every indexable page exists and how it connects to the rest of the site.

Design the global navigation, section navigation, breadcrumbs, contextual links, cards, and footer as one discovery system. Every important page should have at least one durable internal route. High-value pages normally need several routes that match real customer journeys, not one hidden link in an XML sitemap.

Google generally discovers links when they are ordinary <a> elements with an href. A styled button, router event, or clickable card without a resolvable link may work for a person and still be unreliable for crawling. The official crawlable links guidance also recommends concise, descriptive anchor text that tells people and Google what the destination contains.

Use real links for destinations and buttons for actions.
Keep the primary navigation usable with a keyboard and without precise pointer movement.
Do not remove essential section links from mobile merely to make the header smaller.
Show the selected navigation state without making it the only explanation of page location.
Test orphan risk from every template, including campaigns and dynamically created pages.

3. Define URL and page-state rules

Approve URL patterns before content entry and interface development create dozens of exceptions. Decide how service, category, product, article, location, filter, pagination, search, and campaign states behave. Record the final status, indexability, canonical target, sitemap inclusion, and internal-link policy for each family.

State	Required design rule	Failure to prevent
Canonical page	One stable, descriptive URL with a self-canonical	Multiple routes competing for the same content
Moved page	Direct permanent redirect to the closest valid replacement	Redirect chains or blanket homepage redirects
Missing page	Useful error design with the correct HTTP status	A soft 404 that looks live but has no main content
Filtered or sorted state	Explicit crawl and index policy by parameter family	An uncontrolled URL space created by interface controls
Preview or staging page	Access control and a production removal check	Test URLs indexed or the live site left blocked

The SEO-friendly URL guide covers normalization and later URL changes in detail. During design, the important decision is which states are real destinations and which are interface states. Do not let the router make that policy accidentally.

4. Build a template SEO contract

Wireframes should describe required content and metadata, not only rectangles. For every template, define where the title, H1, summary, main content, author or business evidence, media, internal links, CTA, canonical, robots directive, social image, and structured data come from. Mark which fields are required, optional, generated, and editable.

A useful acceptance sample includes normal, long, missing, duplicate, and retired content. Test a long service title, a product without a secondary image, an article with a table, a category with no current inventory, and an unpublished record. This exposes brittle layouts and metadata fallbacks before they affect hundreds of URLs.

Example: service template contract

Title: editable and required.
H1: editable, required, and limited to one per page.
Canonical: generated from the approved URL.
Structured data: BreadcrumbList.
Featured image: required, 1600 × 900 maximum dimensions, and no larger than 200 KB.
Missing service: return 404.
Retired service: redirect directly with 301 to the closest relevant replacement.

Template rule: If the same mistake can appear on every page of a type, the fix belongs in the template, schema, component, or publishing validation. The template-level technical SEO guide shows why page-by-page cleanup does not hold.

5. Protect mobile content and accessibility

Responsive design may rearrange a page, but it should not remove the information that gives the page its purpose. Google's mobile-first indexing guidance says primary content, meaningful headings, metadata, structured data, and important images should remain equivalent across mobile and desktop. Content can move into accessible accordions or tabs when space is tight. It should not depend on a swipe, click, or typing action before it exists for crawling.

Accessibility is a design requirement, not a final plugin. W3C organizes WCAG 2.2 around content being perceivable, operable, understandable, and robust. Apply that to navigation order, landmarks, heading structure, color contrast, focus visibility, labels, errors, touch targets, reduced motion, and keyboard operation. Automated checks help, but a person still needs to complete the main tasks with a keyboard and screen-size changes.

Use the mobile SEO checklist for device-level rendering and task validation after the responsive templates exist.

6. Set media and performance budgets before visual sign-off

A fast mockup is not evidence that the production page will be fast. Test the real font files, hero media, navigation, consent controls, forms, embeds, third-party scripts, and content length. Define budgets by template so a later design change has a measurable trade-off instead of a vague instruction to optimize it.

Reserve image and embed dimensions to prevent layout shifts.
Provide responsive image candidates and realistic sizes.
Do not lazy-load the likely LCP image or critical above-the-fold content.
Load nonessential scripts only where the page job requires them.
Test slow phones, constrained networks, long content, and validation errors.

The current Core Web Vitals targets are LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less, evaluated at the 75th percentile separately for mobile and desktop. These are field targets, not a guarantee that a page will rank. Use the web.dev definitions as the source and the Core Web Vitals diagnosis when a representative template misses them.

7. Map structured data to visible content

Choose structured data from the page's actual job, not from a list of schema types a plugin can emit. Map each supported template to the relevant Google feature documentation, required properties, visible source fields, canonical URL, image ownership, and validation test. Keep the markup synchronized with the page as content changes.

Google's structured data guidelines require markup to represent the main visible content and warn against hidden, irrelevant, or misleading data. Valid markup only creates eligibility. It does not guarantee a rich result.

Template	Possible structured data	Design dependency
Article or guide	Article and BreadcrumbList	Visible author, dates, headline, image, and breadcrumb route
Product	Product and offers when eligible	Visible identity, price, availability, media, and genuine review data
Local business page	Relevant LocalBusiness subtype	Real business details and location-specific visible content
Service page	BreadcrumbList is usually the main page-specific markup. Add Organization or LocalBusiness only when it accurately represents the visible business entity and its maintained details.	No invented ratings, locations, or unsupported rich-result promises

8. Prove the design on a production-like prototype

Do not approve SEO from a design file alone. Build at least one production-like page for every high-value template using realistic content, routes, media, scripts, and error states. Inspect the initial response and the rendered page. Crawl the prototype, resize it, navigate by keyboard, submit its forms, disable optional scripts, and test its slowest likely conditions.

Request representative URLs. Record response status, redirect destination, headers, canonical, robots directives, and rendered title.
Crawl from the homepage. Confirm that intended pages appear through links and unwanted states do not multiply.
Compare mobile and desktop. Check content, links, metadata, images, structured data, and working tasks.
Test template extremes. Use long headings, missing optional fields, large inventories, no-result states, and validation errors.
Run rich-result, performance, and accessibility checks. Treat automated scores as evidence for investigation, not complete approval.
Assign every defect. Name the template or component, owner, expected rule, retest, and rollback path.

9. Use a launch gate with named owners

The final sign-off should be a recorded comparison against the approved page and template contract. Design owns responsive behavior and component states. Development owns rendered output, routing, status codes, and performance implementation. Content owners own page purpose and maintained fields. SEO validates crawlability, index signals, internal discovery, and search-facing output. One person may hold several roles, but no requirement should be ownerless.

If the project replaces an existing site, stop here and run the separate migration workflow. Redirect mapping, old-to-new URL reconciliation, baseline crawls, launch monitoring, and rollback are migration work even when the redesign preserves the brand.

What not to do

Do not approve architecture from the homepage mockup. Search visitors can enter through any useful internal page.
Do not hide essential navigation behind JavaScript events. Destinations need resolvable links.
Do not invent pages after components are finished. Page jobs and fields should shape the template.
Do not remove useful mobile content for visual neatness. Rearrange it without changing the page's job.
Do not add every schema type a plugin offers. Mark up visible, supported content only.
Do not call a Lighthouse score the launch gate. Status, links, content, forms, schema, accessibility, and error states need separate tests.
Do not combine a redesign and migration without a baseline. Separate the target design from the changeover plan.

Verification checklist

Every planned indexable page has a distinct customer or search job.
Every important page is reachable through crawlable internal links.
URL families have documented status, canonical, index, and sitemap rules.
Each template defines required content, metadata, media, schema, and error behavior.
Mobile preserves equivalent primary content, headings, links, metadata, and structured data.
Navigation, forms, focus states, labels, errors, contrast, and motion have accessibility acceptance tests.
Representative templates have media, script, and Core Web Vitals budgets.
Structured data represents visible content and passes the relevant feature validation.
Production-like pages pass status, crawl, render, mobile, keyboard, form, and failure-state tests.
Every launch blocker has an owner, retest, rollback condition, and recorded result.

The design is SEO-ready when the team can prove how pages are discovered, what each template publishes, how mobile preserves the page job, which URL states are indexable, and what must pass before launch. A polished screenshot is not that proof.

Evidence basis

Google Search Central, web.dev, and W3C documentation were checked on August 25, 2026. The page-contract table, prototype sequence, launch ownership model, and acceptance checklist are FloxoLab implementation frameworks. They are not Google ranking factors or guarantees.

The Bach Faucet: Why Infinite AI Content Is Infinite Devaluation

Sun, 30 Aug 2026 12:06:25 +0000

When recorded music went free, its value did not vanish. It moved to the seat in the room, and rushed to a handful of winners.

Between 1996 and 2003, the average concert ticket for a rock or pop act nearly doubled. The economists Maria Connolly and Alan Krueger put the number at 99 percent in their 2005 study of the music business. Over the exact same years, a jazz ticket rose only 20 percent. Same economy, same inflation, same kinds of venues, wildly different curves. The one variable that cleanly separated the two: rock and pop were the genres whose recordings were being copied for free, over Napster and burned CDs, while jazz fans mostly kept buying the albums.

Sit with that, because it is the opposite of what everyone predicted. When recorded music became effectively free and infinitely copyable, the thing you could suddenly get for nothing did not drag everything down with it. Its value moved next door, into the one thing you could not copy, which is a seat in the room while the band plays. And it moved fastest precisely where the copying was worst. The genre that got Napstered hardest is the genre whose live prices ran away. Krueger's own explanation, in the paper: records and concerts are complements, and "record sales are down because many potential customers frequently download music free from the Web or copy CD's."

I open on a twenty-year-old number because the software industry is now running the same experiment at a thousand times the scale, and most of the confident predictions about it are wrong in the same specific way.

The faucet, and the wrong thesis

The vivid image for what we have built is the "Bach faucet," a coinage generally credited to the computational-creativity researcher Kate Compton around 2022 (the attribution travels through a community wiki, so hold it loosely). A Bach faucet is a tap you can turn on to get an endless stream of creative work at least as good as a human master's. We have roughly built one. Large language models will write you a competent blog post, a passable short story, a serviceable market analysis, on demand, for a fraction of a cent, until the sun burns out.

The intuitive economics of that is a straight line to zero. Infinite supply, zero marginal cost, price collapses, content becomes worthless. It is the natural thing to say, and it is wrong, or at least wrong in a way that will lead you to defend the wrong castle. We have the receipts from the last time an entire creative economy went infinite, and recorded music in 2025 pulled in 31.7 billion dollars, up 6.4 percent on the year, according to the industry's own global report. Twenty years after Napster was supposed to end it, the recorded-music business is bigger than ever. "Infinite copies make the thing worthless" is simply not what happened.

What happened is subtler and, if you make things for a living, considerably more useful to understand. Infinite supply did not destroy value. It relocated value, and it concentrated value, and both of those moves were brutally unequal. To see why, you have to pull apart three different mechanisms that the phrase "AI slop" usually mashes together.

Three mechanisms, only one of which is really "infinite devaluation"

The first mechanism is the obvious one, the supply glut. More stuff, so each piece is worth less. This is the weakest of the three, because content was never the scarce resource. Attention is. There were already more good books than you could read in ten lifetimes before a single model wrote a word. Doubling an infinity of things you were never going to read does not change your day. Zero marginal cost on the supply side runs straight into a hard fixed budget on the demand side, which is the twenty-four hours in a reader's day, and that budget does not grow because a faucet turned on.

We have written before about what cheap AI creation does to volume — the Jevons paradox of AI content, where falling cost explodes consumption. This essay is about the other blade: not how much gets made, but what the flood does to a reader’s ability to trust any of it.*

The second mechanism is the one that actually earns the phrase "infinite devaluation," and it is the sharp one. In 1970 the economist George Akerlof published "The Market for Lemons," which won him a Nobel Prize, and its logic is the key to this entire essay. Akerlof showed that when buyers cannot tell good from bad before they buy, they will only pay a price for the average. That average price is too low to be worth a good seller's while, so good sellers leave. Their exit drags the average quality down, which drags the price down again, which pushes out the next tier of sellers. The market can unravel completely even though excellent goods exist and buyers would happily pay for them, purely because nobody can verify which is which at the moment of choosing.

Now map that onto a channel flooded with AI writing. The damage is not to any individual AI article. The damage is to the channel. Once a reader cannot tell, at a glance, whether a blog post or a product review or a research summary was written by someone who actually knew something, the rational move is to discount everything arriving through that channel, including the genuinely expert work. This is the devastating part, and it is worth saying slowly: the flood does not primarily devalue the slop. The slop was near-worthless already. The flood devalues your work, the good stuff, by destroying the reader's ability to trust the channel it arrives in. The honest writer is taxed for the liar's output. That is what "infinite" means here. It is not that any one thing goes to zero. It is that a whole category of trust can collapse while the good work is still sitting right there, unread because it is now indistinguishable from the noise around it.

The third mechanism is the one the music data makes undeniable, and it is the opposite of what "democratization" promised. More supply does not spread attention out. It concentrates it. In the Connolly and Krueger data, the top 1 percent of performers captured 26 percent of all concert revenue in 1982. By 2003, deep into the file-sharing era, the top 1 percent captured 56 percent. The top 5 percent went from 62 percent to 84 percent. As the copyable good flooded the world, the live economy did not become a broad meadow of working musicians. It became a spike. When everyone can access everything, attention does not fan out across the abundance. It rushes to a handful of winners, because the abundance is precisely what makes curation, reputation, and being-already-famous so valuable. Abundance is a superstar machine.

The faucet is running, but check where the water goes

Bring this to the present, and the numbers rhyme with the music story in a way that should reorganize how you think about the threat.

The flood is real. The web-analytics firm Graphite studied roughly 55,000 web pages published from 2020 through early 2026 and found that in the fourth quarter of 2025, primarily AI-generated articles crossed 50 percent of new published articles for the first time, then settled back to just under half in early 2026. Depending on the quarter, something close to half of the new articles appearing online are mostly machine-written. The faucet is not a metaphor. It is a measured fact.

Here is the part that almost nobody quotes, and it is the whole game. Graphite also looked at what actually gets read and cited, and found that of the articles cited by ChatGPT and Perplexity, 82 percent were written by humans and only 18 percent by AI. Half the new web is AI-written, and the machines' own answer engines overwhelmingly cite the human half. The production flood and the attention flood are two completely different things, and only the first one has happened. The water is pouring out of the faucet at full blast and running almost straight down the drain, because the AI articles largely do not surface in search or in AI answers. Axios summarized the same finding with the headline that AI writing has not overwhelmed the web. The doom take and the doomers' own dataset disagree.

So the naive picture, infinite content burying everything, is not what the data shows. What the data shows is the music story again. A copyable good has gone effectively infinite and effectively free, its sheer volume is enormous, and value is not evaporating. It is relocating toward whatever cannot be copied and cannot be faked, and it is concentrating on the few who own that uncopyable thing.

You can watch a platform draw the line in real time. In early 2024 Spotify changed its royalty rules so that a track now has to reach at least 1,000 streams in the previous twelve months before it earns any recorded royalties at all. Spotify's stated reason is that "99.5% of all streams are of tracks that have at least 1,000 annual streams," and that the sub-threshold tracks were each generating about three cents a month, which added up to 40 million dollars a year that mostly vanished into distributor fees before reaching any artist. Read that as an institution formally metering the Bach faucet. It is a platform declaring, by rule, a floor below which a piece of content is worth not "very little" but exactly zero. The infinite tail of songs nobody streams is not underpriced. It is officially priced at nothing, and the 40 million dollars that used to trickle toward it is being swept up to the tracks that clear the bar. Relocation and concentration, written directly into the payout code.

What to do when the faucet is pointed at you

If you make things, or run a company that does, the music experiment hands you a strategy rather than a eulogy. The mistake is to fight the flood on its own terms, by producing more, faster, cheaper, because that is the one contest the faucet wins by definition. The move is to figure out what your live show is.

Find the uncopyable complement. For musicians it was presence, the specific room and night and the fact of being there. For a writer or an analyst or a developer, ask what about your work survives being trivially reproduced. It is usually one of a few things: a reputation staked over years, proprietary data or access nobody else has, judgment on a specific hard problem, a relationship of trust with a particular audience, or the ability to actually do the thing rather than describe it. Those are your concert tickets. The article, the report, the sample code, those increasingly are the free recording that markets the ticket. Krueger's word for records and concerts was complements, and the strategic question is which of your outputs is the recording and which is the show. Give the recording away with less anguish, and price the show.

Attack the lemons problem directly, because it is the mechanism aimed at you specifically. If the flood devalues your good work by making your channel unverifiable, then verifiable quality is the entire ballgame. Anything that lets a reader tell, before they commit their scarce attention, that this came from someone who knew something, is now load-bearing: a real name with a real track record attached, provenance a reader can check, a reputation with skin in it, an institution that vouches. In a market drowning in indistinguishable goods, the cheapest thing to fake is the product and the most valuable thing to own is a signal that cannot be faked. Build that signal, guard it, and never spend it on slop, because the moment your channel becomes a place lemons appear, Akerlof's math starts running against everything you publish there.

And plan for concentration, because it is the part that will surprise the optimists. Abundance did not make a thousand mid-list musicians comfortable. It made a few of them enormous and squeezed the middle toward the Spotify floor. The same spike is coming for content, for software, for any field the faucet touches, and the median producer is the one who gets hurt while total value rises. The goal is not to out-produce the machine. It is to be the complement the machine's output points at rather than the copy it replaces, to own an uncopyable thing and a signal that proves it, and to understand that the water was never going to make everything worthless. It was only ever going to decide, very unequally, where the value went to live.

Sources

Maria Connolly & Alan B. Krueger, "Rockonomics: The Economics of Popular Music," NBER Working Paper 11282 (April 2005): "from 1996 to 2003 concert prices increased by only 20 percent for jazz musicians, but by 99 percent for rock and pop performers"; touring income exceeded record-sales income 7.5 to 1 for the top 35 artists in 2002; and the concentration series (top 1% of performers 26% to 56% of concert revenue, 1982 to 2003; top 5% 62% to 84%). Data ends ~2003; presented here as the historical experiment, not current fact.
George A. Akerlof, "The Market for 'Lemons': Quality Uncertainty and the Market Mechanism," Quarterly Journal of Economics 84, no. 3 (1970): 488–500, the standard statement of adverse selection.
Graphite, "AI now writes as many online articles as humans do" (~55,000 pages, 2020 to early 2026): primarily-AI articles peaked at 50.9% in Q4 2025 and sat near half (49.9%) in Q1 2026; 82% of articles cited by ChatGPT and Perplexity were human-written. See also Axios, "AI-written web pages haven't overwhelmed human-authored content" (Oct 2025).
Spotify for Artists, "Modernizing Our Royalty System": the 1,000-annual-stream threshold from early 2024; "99.5% of all streams are of tracks that have at least 1,000 annual streams"; ~$0.03/month sub-threshold tracks; ~$40 million/year redirected.
IFPI Global Music Report 2026 (recorded-music revenue 2025 of US$31.7bn, +6.4%), as reported across music trade press.
The "Bach faucet" coinage is generally credited to Kate Compton (via the cyborgism wiki), a single-source attribution held loosely here.

The cheapest thing to fake is the product. The most valuable thing to own is a signal that cannot be faked.

Akerlof's math runs against everything you publish the moment a reader cannot tell your work from the slop beside it. The counter is a signal a reader can check before they spend their attention: provenance of who actually did the work, and a reputation with skin in it. That is what the agent trust stack is for, and it is doubly true for agent output: chain-of-consciousness for a provenance record of what an agent actually did, plus agent-rating-protocol for a reputation that survives adversarial checking, so your good work carries a fakery-resistant mark through a channel full of lemons.

See Hosted Chain of Consciousness · Read the Theory of Agent Trust

pip install agent-trust-stack · npm install agent-trust-stack

Or the pieces: pip install chain-of-consciousness / npm install chain-of-consciousness · pip install agent-rating-protocol / npm install agent-rating-protocol

Building This Blog: A Modern Next.js Blog with Markdown

Tue, 21 Apr 2026 21:12:52 +0000

Building This Blog: an MDX‑powered Next.js blog

This blog is a small, opinionated setup for writing long‑form content that feels good to read and fun to build on.

Under the hood it uses static generation, MDX, and a theme‑aware UI that works in both light and dark modes.

Everything after the frontmatter is pure MDX. Components like Callout, Steps, architecture diagrams, flows, and charts are all React components rendered directly in the post body.

Stack I ended up with

I wanted something fast, simple, and easy to reason about over years—not weeks.

The site is a static App Router app. Routes like `/blog/[slug]`, `/til/[slug]`, `/technical-terms/[slug]` are statically generated at build time.


TypeScript keeps the content layer and components honest. Tailwind + CSS variables handle layout and theming.


All long‑form content lives in the repo inside content/, written as `.md` or `.mdx` files with frontmatter.


Views, upvotes, and UTM events are stored in Supabase and surfaced through a custom analytics dashboard.

How content works

All posts are simple files in the repo—no CMS required.

---
title: "Your Post Title"
description: "Post description"
date: "2024-01-20"
author: "Your Name"
tags: ["tag1", "tag2"]
category: "Category"
featured: true
---

Your content here...

Markdown (.md) posts go through a Remark pipeline and are rendered as HTML.
MDX (.mdx) posts are compiled at runtime in the page using next-mdx-remote/rsc, with a shared component map.

For posts that need diagrams, flows, or charts, I use .mdx and drop in components like ArchitectureCard, FlowStep, and DemoBarChart.

Authoring flow

Add a new `.md` or `.mdx` file to content/blog/ with frontmatter for SEO, tags, and images.


Run npm run dev and iterate on copy, diagrams, and layout until the post feels polished.


Push to the main branch. The build step generates static HTML for every route and updates search data + OG images.

Architecture of the blog

At a high level, the blog is just three pieces: browser, Next.js, and Supabase.

Readers get fully rendered HTML from the CDN, with minimal JavaScript on top for upvotes, analytics, and small interactions.


Next.js statically generates pages for blog posts, TIL entries, technical terms, and lists. It also exposes a few API routes for analytics.


Supabase stores per‑page views, upvotes, and UTM events that feed the analytics dashboard and charts.

Request–response flow for a page view

Here’s how a single blog page view flows through the system.

The CDN serves a pre‑rendered HTML page that was generated at build time.


Next.js hydrates the page; components like the upvote button, custom cursor, and view counter start working.


A lightweight request records the view / upvote in Supabase without blocking the reader.


Aggregated stats are used to power Recharts visualizations on the analytics page.

Visualizing traffic with charts

The same Recharts setup used in the analytics dashboard is available inside MDX posts.

Charts are plain React components exposed to MDX. They respect the global theme and use the same accent palette as the rest of the site.

Performance before and after

Static export plus small tweaks around assets made a noticeable difference in user‑facing numbers.

Why this setup works for me

Files as the source of truth – I can write posts in a text editor, version them in git, and refactor them like any other code.
Static by default – Most pages are static HTML, which is great for speed and reliability.
MDX when I need power – Architecture diagrams, flows, and charts are just components; I only reach for them when a post really needs them.
Theme‑aware UI – Components use the same CSS variables as the rest of the app, so they look good in both light and dark modes.

If you want to explore the implementation details, the full source code is on GitHub. You could clone it, point it at your own content folder, and have a similar blog running in minutes.