Forem: mistyhx

Building an AI-Powered Social Media Content Generator - A Developer's Guide

mistyhx — Tue, 24 Mar 2026 22:30:53 +0000

Ever scrolled through your social feeds and thought "I wish I had a bot to write my posts"? Well, you're in luck! Today we're diving into building an AI-powered social media content generator that can help create engaging posts across different platforms.

Why Build This?

Social media content creation is time-consuming, and let's be honest - sometimes we all hit that creative wall. An AI assistant can:

Generate platform-specific content (Twitter's character limits vs LinkedIn's professional tone)
Maintain consistent posting schedules
Adapt content for different audiences
Save hours of brainstorming time

The Tech Stack

For this project, we'll use:

Frontend: React.js or vanilla JavaScript
Backend: Node.js with Express
AI Service: OpenAI API (GPT-4) or Google's Gemini
Database: MongoDB or PostgreSQL for storing templates
Authentication: JWT for user management

Setting Up the Foundation

Let's start with a basic Express server:

const express = require('express');
const cors = require('cors');
const OpenAI = require('openai');

const app = express();
const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY
});

app.use(cors());
app.use(express.json());

app.post('/api/generate-content', async (req, res) => {
  try {
    const { platform, topic, tone, targetAudience } = req.body;

    // We'll implement this next
    const content = await generateContent(platform, topic, tone, targetAudience);

    res.json({ content });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

The Content Generation Logic

Here's where the magic happens:

async function generateContent(platform, topic, tone, targetAudience) {
  const prompts = {
    twitter: `Write a Twitter thread (max 280 chars per tweet) about ${topic}. 
             Tone: ${tone}. Target audience: ${targetAudience}. 
             Include relevant hashtags and make it engaging.`,

    linkedin: `Create a professional LinkedIn post about ${topic}. 
               Tone: ${tone}. Target audience: ${targetAudience}. 
               Include a compelling hook and call-to-action.`,

    instagram: `Write an Instagram caption for ${topic}. 
                Tone: ${tone}. Target audience: ${targetAudience}. 
                Include emojis and relevant hashtags.`
  };

  const response = await openai.chat.completions.create({
    model: "gpt-4",
    messages: [
      {
        role: "system",
        content: "You are a social media content expert who creates engaging, platform-specific content."
      },
      {
        role: "user",
        content: prompts[platform]
      }
    ],
    max_tokens: 500,
    temperature: 0.7
  });

  return response.choices[0].message.content;
}

Frontend Implementation

Create a simple React component for the user interface:

import React, { useState } from 'react';

function ContentGenerator() {
  const [formData, setFormData] = useState({
    platform: 'twitter',
    topic: '',
    tone: 'professional',
    targetAudience: ''
  });
  const [generatedContent, setGeneratedContent] = useState('');
  const [loading, setLoading] = useState(false);

  const handleSubmit = async (e) => {
    e.preventDefault();
    setLoading(true);

    try {
      const response = await fetch('/api/generate-content', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify(formData)
      });

      const data = await response.json();
      setGeneratedContent(data.content);
    } catch (error) {
      console.error('Error:', error);
    } finally {
      setLoading(false);
    }
  };

  return (
    <div className="content-generator">
      <form onSubmit={handleSubmit}>
        <select 
          value={formData.platform} 
          onChange={(e) => setFormData({...formData, platform: e.target.value})}
        >
          <option value="twitter">Twitter</option>
          <option value="linkedin">LinkedIn</option>
          <option value="instagram">Instagram</option>
        </select>

        <input
          type="text"
          placeholder="Enter your topic"
          value={formData.topic}
          onChange={(e) => setFormData({...formData, topic: e.target.value})}
          required
        />

        <select 
          value={formData.tone} 
          onChange={(e) => setFormData({...formData, tone: e.target.value})}
        >
          <option value="professional">Professional</option>
          <option value="casual">Casual</option>
          <option value="humorous">Humorous</option>
          <option value="inspirational">Inspirational</option>
        </select>

        <button type="submit" disabled={loading}>
          {loading ? 'Generating...' : 'Generate Content'}
        </button>
      </form>

      {generatedContent && (
        <div className="generated-content">
          <h3>Generated Content:</h3>
          <p>{generatedContent}</p>
        </div>
      )}
    </div>
  );
}

export default ContentGenerator;

Advanced Features to Consider

Content Templates

Store successful post templates in your database:

const contentTemplates = {
  twitter: {
    question: "What if {topic}? 🤔\n\nThread 👇",
    tip: "Pro tip for {audience}: {topic}\n\n{content}\n\n#{hashtag}",
    quote: "'{quote}' - on {topic}\n\nWhat's your take?"
  }
};

Scheduling Integration

Connect with social media APIs for direct posting:

const TwitterApi = require('twitter-api-v2').default;

async function schedulePost(content, platform, scheduledTime) {
  if (platform === 'twitter') {
    const twitterClient = new TwitterApi(process.env.TWITTER_BEARER_TOKEN);
    // Schedule logic here
  }
  // Add other platforms
}

Content Analytics

Track which types of content perform best:

const contentMetrics = {
  trackPerformance: async (postId, platform, metrics) => {
    // Store engagement data
    await ContentAnalytics.create({
      postId,
      platform,
      likes: metrics.likes,
      shares: metrics.shares,
      comments: metrics.comments,
      timestamp: new Date()
    });
  }
};

Deployment Considerations

Environment Variables: Keep your API keys secure
Rate Limiting: Implement limits to avoid API quota issues
Caching: Store generated content to reduce API calls
Error Handling: Graceful fallbacks when AI services are down

What's Next?

This is just the beginning! You could extend this app with:

Multi-language support
Image generation for posts
A/B testing different content versions
Integration with more social platforms
User analytics and insights

Have you built any AI-powered content tools? What features would you add to make this even more useful? Drop your thoughts in the comments below!

And if you build this, I'd love to see what you create. Share your GitHub repos or deployed versions! 🚀

Why AI Writes Better Game Code in Godot Than in Unity

mistyhx — Thu, 19 Mar 2026 18:50:41 +0000

A game developer's firsthand experience with AI-assisted workflows

March 2026

The Moment It Clicked

I've been building a detective RPG inspired by Ace Attorney — the kind of game with branching dialogue trees, courtroom cross-examinations, and dozens of interconnected scenes. I started in Unity, which felt like the obvious choice. It's what I knew, it's what most tutorials cover, and it has a massive ecosystem.

Then I migrated to Godot and started using AI coding assistants — specifically Claude Code — to help me architect and build the game systems. The difference was so striking that I started paying attention to why. It wasn't that the AI was smarter with one engine. It's that one engine is fundamentally more readable to AI than the other.

This isn't a general Godot-vs-Unity debate. Both are capable engines. This is about a specific question: if you plan to use AI tools as a core part of your development workflow, which engine makes that collaboration smoother?

Everything Is a Text File

The single biggest reason AI works better with Godot comes down to file formats. In Godot, virtually everything your project contains is stored as human-readable text:

Scripts (.gd) — GDScript is a Python-like language. Plain text, no compilation step needed to understand the code.
Scenes (.tscn) — Godot's scene files are a text-based format that describes every node, property, and connection in the scene tree. You can open one in any text editor and read it.
Resources (.tres) — Custom resources, materials, themes — all stored as readable text.
Project config (project.godot) — A plain INI-style file listing autoloads, input mappings, and settings.

This matters because AI coding assistants work by reading and writing text. When an AI tool can read your scene file and understand that a DialogueBox node is a child of a CanvasLayer, with specific properties set to specific values, it can reason about your game's structure and make informed suggestions.

Unity's Binary Problem

Unity stores scenes (.unity) and prefabs (.prefab) in a YAML-like serialized format that is technically text, but barely human-readable. Every object reference is a numeric fileID, relationships are expressed through GUIDs, and the structure is deeply nested with Unity-internal metadata. Even with "force text serialization" enabled, a simple scene with a few GameObjects produces hundreds of lines of dense, ID-heavy YAML.

Here's the same scene from my game — a bedroom the player starts in — as it appears in both engines:

Unity (.unity) — 60+ lines just for render settings

%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!29 &1
OcclusionCullingSettings:
  m_ObjectHideFlags: 0
  serializedVersion: 2
  m_OcclusionBakeSettings:
    smallestOccluder: 5
    smallestHole: 0.25
    backfaceThreshold: 100
  m_SceneGUID: 00000000000000000000000000000000
  m_OcclusionCullingData: {fileID: 0}
--- !u!104 &2
RenderSettings:
  m_Fog: 0
  m_FogColor: {r: 0.5, g: 0.5, b: 0.5, a: 1}
  m_FogMode: 3
  ...(continues for 40+ more lines of metadata)

Before the AI even reaches the actual game objects, it must wade through pages of rendering configuration, lightmap settings, and serialization IDs. None of this tells the AI anything about the game's logic or structure.

Godot (.tscn) — the entire scene in 10 lines

[gd_scene load_steps=3 format=3]

[ext_resource type="PackedScene" path="res://scenes/chapter_template.tscn" id="1"]
[ext_resource type="Texture2D" path="res://sprites/backgrounds/myroom.png" id="2"]

[node name="ChapterScene" instance=ExtResource("1")]
chapter_json = "chapter2_0_myroom"

[node name="Background" parent="." index="0"]
texture = ExtResource("2")

That's it. The entire scene. An AI can read this and immediately understand: this scene inherits from a chapter template, loads a specific conversation JSON file, and uses a bedroom background image. Every line carries semantic meaning — there's no noise.

When an AI assistant encounters a Unity scene file, it's essentially reading a database dump. It can parse the syntax, but it can't easily understand the intent. Godot's .tscn format, by contrast, reads almost like a description of the scene.

GDScript: A Language AI Actually Knows Well

GDScript is a small, focused language designed specifically for game logic. It has around 850 built-in classes, a consistent API, and Python-like syntax. Compare that to C# in Unity, where you're working with the full .NET ecosystem plus Unity's own APIs, editor classes, serialization attributes, and coroutine patterns.

This matters for AI in two ways:

Less Ambiguity

When you ask an AI to write GDScript, there's usually one idiomatic way to do things. Signals are signals, exports are exports, the node tree is the node tree. In Unity C#, the same task might be accomplished with UnityEvents, C# events, ScriptableObject channels, or a message bus — and the AI has to guess which pattern your project uses.

Smaller Surface Area

GDScript's API is entirely game-focused. An AI generating GDScript won't accidentally suggest patterns from web development, desktop applications, or server-side code the way it might with C#. The code it produces is specific to Godot's use case.

That said, there is a trade-off. GDScript has a smaller training corpus than C#, which means AI models occasionally hallucinate Python idioms that don't exist in GDScript. In my experience, this happens less with more capable models and is easy to catch — the Godot editor flags these immediately. The overall accuracy of AI-generated GDScript has been high enough that the speed gains far outweigh the occasional correction.

The Architecture Advantage: Signals and Scene Trees

Godot's design philosophy encourages a specific architectural pattern: scene trees with signal-based communication. Every game object is a node in a tree. Nodes communicate by emitting signals. Systems stay decoupled.

This pattern is extraordinarily AI-friendly because it's consistent and compositional. When I described my game's requirements to Claude Code, it immediately proposed an EventManager autoload (a global signal bus), a three-layer separation of data, systems, and UI, and a rule that systems never call each other directly. This wasn't generic advice — it's the natural architecture that Godot's design encourages.

Unity doesn't enforce a particular architecture, which is both a strength and a weakness. For AI-assisted development, it's mostly a weakness. The AI has to first understand which of the many possible Unity patterns you're using (MonoBehaviour singletons? ScriptableObject events? Dependency injection? ECS?) before it can help effectively. With Godot, the conventions are baked into the engine itself.

A Side-by-Side Comparison

Here's how specific aspects of AI-assisted development compare between the two engines, based on my experience building the same game in both:

Aspect	Godot	Unity
Scene files	Text-based .tscn, AI can read and reason about them	Serialized YAML with GUIDs, hard for AI to interpret
Script language	GDScript: small, focused, game-specific	C#: powerful but large surface area, multiple patterns
Project config	Single project.godot file, plain text	Multiple meta files, ProjectSettings assets
Prefabs	Scenes (.tscn) — same readable format	.prefab files with nested GUID references
Architecture	Signals + scene tree (one clear pattern)	Many valid patterns (events, SO, DI, ECS)
Version control	All text, clean diffs	Requires force-text mode, still noisy diffs
AI code generation	One idiomatic style per task	Multiple approaches, AI must guess your pattern
Error feedback	Editor flags GDScript errors immediately	Compile-time C# errors (slower feedback loop)

What This Looks Like in Practice

Let me share a concrete example from my project. I needed to design a courtroom cross-examination system — the core mechanic of an Ace Attorney-style game. This involves:

A state machine cycling through testimony, cross-examination, and verdict phases
Witness statements the player can navigate through
A "press" action to question witnesses and a "present" action to show evidence
A penalty system that tracks wrong answers
Evidence matching against specific contradictions in testimony

I described these requirements to Claude Code. Because it could read my existing project files — the dialogue system JSON, the scene templates, the game data models — it designed a complete court system architecture that integrated naturally with what I already had. It proposed a JSON format for court cases, a state machine that reuses my dialogue system for narrative phases, and signal-based communication between the court logic and the UI.

The key insight: the AI could do this because my entire project was legible to it. Every script, every scene, every data file was plain text that it could read, cross-reference, and reason about. If my scene files had been binary blobs or dense GUID-laden YAML, the AI would have been working with far less context.

The Growing Ecosystem

The AI-assisted Godot development ecosystem is maturing quickly. Developers have built MCP (Model Context Protocol) integrations that let AI assistants interact directly with the Godot editor — creating scenes, reading errors, and modifying resources programmatically. There are Claude Code skills specifically designed for Godot that provide structured guidance on GDScript patterns and project architecture.

One project, Godogen, demonstrates that AI can generate complete Godot 4 projects from natural language descriptions — with proper scene trees, scripts, and asset organization. This works because Godot's formats are simple enough for AI to generate correctly. Attempting the same with Unity would require the AI to produce valid GUID references, serialized MonoBehaviour data, and properly linked meta files — a much higher bar.

When Unity Still Makes Sense

This isn't a one-sided argument. Unity remains the stronger choice in several scenarios, even with AI assistance:

3D-heavy or AAA-scope projects — Unity's rendering pipeline, asset pipeline, and tooling for large teams are more mature.
Platform-specific features — Unity's console support and platform abstraction are deeper.
Existing C# expertise — If your team is deeply fluent in C# and .NET, the familiarity advantage is real.
Unity's own AI tools — Unity is investing heavily in its own AI features, including Muse for asset generation and an AI coding assistant that understands Unity's context.

The AI readability advantage I'm describing matters most for indie developers and small teams using general-purpose AI coding assistants (Claude, Cursor, Copilot) as a primary workflow tool. If you're a solo developer building a 2D narrative game and you want AI to be your architecture partner, Godot is the better foundation.

The Bottom Line

The reason AI works better with Godot isn't about the AI being trained more on one engine than the other. It's about transparency. Godot stores everything as readable text, uses a focused scripting language, and encourages a consistent architectural pattern. These are exactly the properties that make a codebase legible to an AI assistant.

If you're starting a new game project and plan to use AI tools as a core part of your workflow, consider this: the engine you choose determines how much of your project the AI can actually see. With Godot, the answer is everything.

About the Author

The author is an indie game developer building Legend of Tang, a detective RPG set in the Tang Dynasty. The game is built in Godot 4.2 with GDScript and developed with the help of AI coding assistants. My previous game was The Crack (壳中之物).

I Built a Claude Plugin to Fix AI-Generated Interfaces' User Experience.

mistyhx — Thu, 12 Mar 2026 04:30:40 +0000

AI Can Ship a UI in Minutes. But It Takes a Trained Eye to See Everything It Gets Wrong.

I've spent a decade reviewing interfaces as a UX Designer — conducting heuristic evaluations, running usability tests, auditing design systems. And lately, I've been watching a pattern that genuinely concerns me.

AI coding tools have become so popular that many use them to generate entire user interfaces. The code runs. The layout looks reasonable. The screenshot in the pull request seems fine. It ships. And then users struggle with it.

Not because of bugs. Because of usability.

Missing loading states. Flat visual hierarchy where everything competes for attention. No keyboard navigation. Status indicators that rely entirely on color. Spacing values that look like someone rolled dice — 8px here, 13px there, 20px somewhere else. Forms with placeholder text instead of labels.

These aren't edge cases. AI-generated interfaces optimize for "good enough" — functional on the surface, but rarely striving for user experience quality. And most builders don't have a UX designer next to them to catch what's missing.

So I built one — Frontend Design Audit.

What Is Frontend Design Audit?

Frontend Design Audit is a free, open-source Claude Code plugin that reviews your front-end code against 15 curated usability principles — then fixes what it finds directly in your code.

It works with React, Vue, Svelte, plain HTML/CSS, or any front-end stack. You can also point it at a live URL for a report-only audit. It reads your code, evaluates it systematically, presents a severity-rated report, and implements the fixes.

Why Existing Tools Don't Catch This

There are excellent tools for code quality — ESLint, Prettier, TypeScript, Lighthouse. But few look at the user experience.

Does the visual hierarchy actually guide the user's eye?
Is the spacing system coherent or random?
Do interactive elements look interactive?
When a user completes an action, do they get feedback?
Are patterns consistent across pages, or does every component feel like it was designed by a different person?

That's the gap this plugin fills. It evaluates your UI the way a Senior UX Designer would — assessing design and usability as a whole.

I Tested It on Three AI-Generated Interfaces. Here's What Happened.

To put the plugin to the test, I ran it on three common interface types: a coffee shop landing page, a SaaS pricing page, and a task management dashboard. Each was built using Claude's frontend-design skill — functional, visually decent, and unremarkable at first glance. A good baseline.

But all three had serious usability problems hiding in plain sight.

Coffee Shop Landing Page

Figure 1 — Coffee Shop (Before and After)

Top usability issues:

The form used placeholder text as labels. When users started typing, the label vanished — making it easy to lose track of what a field was for. Screen readers also treat them as placeholders, not labels, breaking accessibility. (See Figure 1)
The viewport meta tag blocked pinch-to-zoom (user-scalable=no), making the site unusable for low-vision users on mobile.
The order form used alert() for success feedback, then wiped the form. If the alert was dismissed accidentally, all entered data was gone.

SaaS Pricing Page

Figure 2 — SaaS Pricing (Before and After)

Top usability issues:

On mobile, all navigation links were hidden with display: none — no hamburger menu, no alternative. The only clickable element was the CTA button. (See Figure 2)
The Starter plan leads on mobile simply because it's the leftmost block on desktop. This works against the goal of surfacing the Most Popular plan first.
Plan names were <div> elements instead of headings, breaking document structure.

Task Management Dashboard

Figure 3 — Task Dashboard (Before and After)

Top usability issues:

Activity status was conveyed by color alone, with no labels — meaningless for users with color blindness or low vision. (See Figure 3)
Dropdown menus lacked keyboard navigation — no arrow key support or Escape to close.
Buttons had no active/pressed states, making interactions feel unresponsive.

Try It

The plugin doesn't just catch surface-level UI issues or apply one-off fixes. It analyzes your interface as a system — surfacing both visible and invisible usability problems — and produces output that's intuitive and production-ready.

It's free, open-source, and MIT licensed.

👉 github.com/mistyhx/frontend-design-audit