<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Yuichi Tanaka</title>
    <description>The latest articles on DEV Community by Yuichi Tanaka (@yuichi-tanaka).</description>
    <link>https://dev.to/yuichi-tanaka</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4052583%2F7109de5e-e625-4351-a807-b4563a57e4f6.png</url>
      <title>DEV Community: Yuichi Tanaka</title>
      <link>https://dev.to/yuichi-tanaka</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/yuichi-tanaka"/>
    <language>en</language>
    <item>
      <title>AI Can Generate the Deck. Publishing It Is Still the Hard Part.</title>
      <dc:creator>Yuichi Tanaka</dc:creator>
      <pubDate>Mon, 03 Aug 2026 09:11:03 +0000</pubDate>
      <link>https://dev.to/yuichi-tanaka/ai-can-generate-the-deck-publishing-it-is-still-the-hard-part-5549</link>
      <guid>https://dev.to/yuichi-tanaka/ai-can-generate-the-deck-publishing-it-is-still-the-hard-part-5549</guid>
      <description>&lt;p&gt;Codex and Claude Code can do more than write source code. Given a technical&lt;br&gt;
proposal, an architecture decision, or a product review, they can also produce a&lt;br&gt;
self-contained HTML slide deck with layout, diagrams, interactions, and examples.&lt;/p&gt;

&lt;p&gt;That changes how engineering teams can communicate. A document is still the right&lt;br&gt;
tool for durable prose, and Markdown remains excellent for notes and&lt;br&gt;
documentation. But some ideas depend on visual sequence. An architecture needs a&lt;br&gt;
diagram. A roadmap needs progression. A product review is easier to understand&lt;br&gt;
when the reader can move through states and examples.&lt;/p&gt;

&lt;p&gt;Generating that deck is no longer the hardest part.&lt;/p&gt;

&lt;p&gt;The harder part begins when the file is ready.&lt;/p&gt;
&lt;h2&gt;
  
  
  The awkward gap after generation
&lt;/h2&gt;

&lt;p&gt;An AI agent can leave a finished &lt;code&gt;deck.html&lt;/code&gt; in a repository. To get feedback, the&lt;br&gt;
author still needs to decide where to put it, how to share it, who may open it, and&lt;br&gt;
what should happen when the deck changes.&lt;/p&gt;

&lt;p&gt;A generic hosting platform can serve the file, but it also introduces decisions&lt;br&gt;
that are unrelated to the review:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Which project or bucket should own the file?&lt;/li&gt;
&lt;li&gt;Is the current URL mutable or permanent?&lt;/li&gt;
&lt;li&gt;How do we keep the URL stable across updates?&lt;/li&gt;
&lt;li&gt;How do we share a private draft with a team?&lt;/li&gt;
&lt;li&gt;Which exact version did reviewers approve?&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;These are small infrastructure questions individually. Together, they interrupt&lt;br&gt;
the workflow that made AI-generated artifacts attractive in the first place.&lt;/p&gt;

&lt;p&gt;The author wanted to say, “turn this proposal into a deck and give the team a URL.”&lt;br&gt;
Instead, the author becomes a hosting operator.&lt;/p&gt;
&lt;h2&gt;
  
  
  Treat the deck as a review artifact
&lt;/h2&gt;

&lt;p&gt;We built LedgerInfra around a narrower model: an AI-generated HTML deck is a&lt;br&gt;
review artifact with versions and an audience.&lt;/p&gt;

&lt;p&gt;The input is intentionally constrained. It must be a complete HTML document with&lt;br&gt;
its CSS, JavaScript, and images contained in one file. LedgerInfra does not&lt;br&gt;
convert Markdown into slides and does not manage an asset bundle. Codex, Claude&lt;br&gt;
Code, or another tool creates the artifact; LedgerInfra publishes and versions&lt;br&gt;
the finished result.&lt;/p&gt;

&lt;p&gt;The basic operation is a CLI command:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;led publish ./deck.html &lt;span class="nt"&gt;--title&lt;/span&gt; &lt;span class="s2"&gt;"Architecture Proposal"&lt;/span&gt; &lt;span class="nt"&gt;--json&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;A successful publish returns a URL for the latest version. Publishing a new&lt;br&gt;
version to the same slide keeps that latest URL stable:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;led publish ./deck.html &lt;span class="nt"&gt;--slide&lt;/span&gt; &amp;lt;SLIDE_KEY&amp;gt; &lt;span class="se"&gt;\&lt;/span&gt;
  &lt;span class="nt"&gt;--title&lt;/span&gt; &lt;span class="s2"&gt;"Architecture Proposal v2"&lt;/span&gt; &lt;span class="nt"&gt;--json&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Each publish also has a fixed version URL. The latest URL is useful for an active&lt;br&gt;
review thread. The fixed URL is useful when a decision, release note, or audit&lt;br&gt;
record needs to point to the exact content that existed at that moment.&lt;/p&gt;
&lt;h2&gt;
  
  
  Visibility should be part of the publish action
&lt;/h2&gt;

&lt;p&gt;A review artifact does not always have the same audience. A public demo, an&lt;br&gt;
internal design review, and a private first draft need different defaults.&lt;/p&gt;

&lt;p&gt;LedgerInfra uses three visibility modes:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;led publish ./deck.html &lt;span class="nt"&gt;--visibility&lt;/span&gt; public
led publish ./deck.html &lt;span class="nt"&gt;--visibility&lt;/span&gt; workspace
led publish ./deck.html &lt;span class="nt"&gt;--visibility&lt;/span&gt; private
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;New slides default to &lt;code&gt;private&lt;/code&gt;. Public slides are anonymously viewable.&lt;br&gt;
Workspace slides are limited to active members of the selected workspace.&lt;br&gt;
Private slides are limited to their creator.&lt;/p&gt;

&lt;p&gt;The important design choice is that visibility belongs to the artifact and is&lt;br&gt;
selected at publication time. It is not an afterthought hidden in a separate&lt;br&gt;
hosting console.&lt;/p&gt;

&lt;h2&gt;
  
  
  Let the AI agent operate the CLI
&lt;/h2&gt;

&lt;p&gt;A CLI is useful for developers, but the intended workflow does not require a&lt;br&gt;
person to type every command.&lt;/p&gt;

&lt;p&gt;LedgerInfra provides an Agent Skill that can be installed for Codex or Claude&lt;br&gt;
Code. The user can make a natural-language request such as:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Turn this technical proposal into a self-contained HTML slide deck, publish it&lt;br&gt;
privately, and return both the latest and fixed-version URLs.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The agent can validate the CLI state and run the publish command internally. The&lt;br&gt;
workflow keeps a human boundary where it matters: login approval, public&lt;br&gt;
publication, archiving, and membership changes require the user to see and&lt;br&gt;
confirm the relevant action.&lt;/p&gt;

&lt;p&gt;This is the broader product idea. AI agents should be able to create and deliver&lt;br&gt;
an artifact without copying credentials into a conversation or turning the final&lt;br&gt;
step into a manual deployment checklist.&lt;/p&gt;

&lt;h2&gt;
  
  
  A narrow tool has useful boundaries
&lt;/h2&gt;

&lt;p&gt;LedgerInfra is not a replacement for a general web host.&lt;/p&gt;

&lt;p&gt;Use a general hosting platform when the result is a web application, depends on&lt;br&gt;
multiple assets, needs a custom deployment pipeline, or requires control over the&lt;br&gt;
delivery infrastructure.&lt;/p&gt;

&lt;p&gt;Use LedgerInfra when the result is already a complete, self-contained HTML&lt;br&gt;
artifact and the remaining job is to publish it for review, update it, control&lt;br&gt;
who can see it, and preserve versions.&lt;/p&gt;

&lt;p&gt;That boundary also keeps the system honest. The service does not claim to create&lt;br&gt;
the deck, edit it, or run an arbitrary application. It handles the short but&lt;br&gt;
important path from a finished file to a reviewable URL.&lt;/p&gt;

&lt;h2&gt;
  
  
  What we are testing
&lt;/h2&gt;

&lt;p&gt;LedgerInfra is being built for small engineering and product teams already using&lt;br&gt;
AI coding agents. The main question is not whether AI can generate better-looking&lt;br&gt;
slides. It is whether the surrounding publish-and-review workflow can become&lt;br&gt;
simple enough to stay inside the agent-assisted development loop.&lt;/p&gt;

&lt;p&gt;If your team already creates technical proposals, architecture diagrams, product&lt;br&gt;
reviews, or roadmaps with Codex or Claude Code, I would like to learn how you&lt;br&gt;
share them today:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Do you keep the result in a repository?&lt;/li&gt;
&lt;li&gt;Export it to a document format?&lt;/li&gt;
&lt;li&gt;Deploy it to a general hosting service?&lt;/li&gt;
&lt;li&gt;Send screenshots in chat?&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Those workarounds are the workflow LedgerInfra is trying to understand and&lt;br&gt;
improve.&lt;/p&gt;

&lt;p&gt;Product page: &lt;a href="https://lp.ledgerinfra.com/?utm_source=devto&amp;amp;utm_medium=article&amp;amp;utm_campaign=service_launch&amp;amp;utm_content=first_article" rel="noopener noreferrer"&gt;LedgerInfra&lt;/a&gt;&lt;/p&gt;

</description>
      <category>ai</category>
      <category>cli</category>
      <category>productivity</category>
      <category>webdev</category>
    </item>
  </channel>
</rss>
