DEV Community: Ashley Armstrong

Part 4: Going Fully Autonomous: EventBridge, DynamoDB, and Automated Publishing

Ashley Armstrong — Sun, 12 Jul 2026 08:09:36 +0000

Generating content is interesting. Generating content, creating artwork, and publishing it without human intervention is where things start to get fun.

The Final Challenge

By this point, WizardThoughts had come a long way.

The platform could:

✅ Generate content using Amazon Bedrock

✅ Generate matching image prompts

✅ Create original artwork using Stability AI

✅ Store assets in Amazon S3

✅ Track everything in DynamoDB

The individual pieces worked.

The problem was coordination.

I was still manually triggering parts of the workflow.

The system wasn't autonomous.

It was semi-automated.

There is an important difference.

The Goal

My original vision was simple:

Create a social media account capable of generating and publishing its own content without human involvement.

To achieve that, every component needed to operate independently.

The complete workflow looked like this:

EventBridge
      ↓
GenerateContent
      ↓
Amazon Bedrock
      ↓
DynamoDB
      ↓
GenerateImage
      ↓
Stability AI
      ↓
Amazon S3
      ↓
PublishToX
      ↓
WizardThoughts

Once that pipeline was running, the system would effectively become self-managing.

DynamoDB Becomes the Brain

Originally, DynamoDB was simply a storage layer.

As the project evolved, it became much more than that.

It became the central source of truth.

Every piece of content moved through a series of states.

For example:

{
  "PostId": "post-123",
  "Status": "Pending",
  "ImageStatus": "Pending"
}

Then:

{
  "PostId": "post-123",
  "Status": "Pending",
  "ImageStatus": "Complete",
  "ImageUrl": "..."
}

And finally:

{
  "PostId": "post-123",
  "Status": "Published",
  "TweetId": "123456789"
}

This simple approach eliminated enormous amounts of complexity.

Rather than services talking directly to each other, they only needed to understand state.

Building a State Machine Without a State Machine

Technically, I wasn't using AWS Step Functions.

But the architecture behaved like one.

Each Lambda function had a single responsibility.

GenerateContent

Creates:

Quote
Image Prompt
Database Record

GenerateImage

Looks for:

Status = Pending
ImageStatus = Pending

Generates artwork and updates the record.

PublishToX

Looks for:

Status = Pending
ImageStatus = Complete

Then publishes the post.

The beauty of this approach is simplicity.

Every service operates independently.

Every service knows exactly what work it needs to perform.

EventBridge: The Invisible Conductor

The final piece of the puzzle was scheduling.

Without EventBridge, nothing happened automatically.

With EventBridge, the entire pipeline came to life.

I created three schedules.

Content Generation

Every 6 hours

This generated fresh content throughout the day.

Image Generation

Every 6 hours

This checked DynamoDB for content requiring artwork.

Publishing

Every 6 hours

This checked for completed posts ready to publish.

The result was a continuous workflow that required zero manual intervention.

Publishing Images to X

Getting text published was relatively straightforward.

Images were another story.

The publishing workflow became:

Retrieve Post
        ↓
Load Image From S3
        ↓
Upload Media To X
        ↓
Attach Media To Tweet
        ↓
Publish

Simple in theory.

Less simple in reality.

Authentication: The Sequel

Just when I thought I'd finally escaped authentication issues, another surprise appeared.

Text tweeting worked.

Image uploads didn't.

The logs repeatedly returned:

401 Unauthorized

and

403 Unsupported Authentication

After far more debugging than I would like to admit, I discovered the issue.

Different X endpoints preferred different authentication methods.

The solution was moving to OAuth 1.0a credentials:

CONSUMER_KEY
CONSUMER_SECRET
ACCESS_TOKEN
ACCESS_TOKEN_SECRET

The moment I switched:

const client = new TwitterApi({
  appKey: process.env.CONSUMER_KEY,
  appSecret: process.env.CONSUMER_SECRET,
  accessToken: process.env.ACCESS_TOKEN,
  accessSecret: process.env.ACCESS_TOKEN_SECRET
});

everything finally started working consistently.

The Moment It Became Real

The first fully automated post felt different.

Not because the content was exceptional.

Not because the image was perfect.

Because nobody touched anything.

The workflow executed entirely on its own.

EventBridge Trigger
       ↓
Bedrock Generated Quote
       ↓
Stability Generated Artwork
       ↓
S3 Stored Asset
       ↓
DynamoDB Updated State
       ↓
X Published Content

No buttons.

No manual deployments.

No intervention.

The system simply did what it had been designed to do.

That was the moment the project stopped feeling like a collection of Lambda functions and started feeling like a product.

Operational Lessons

Building something is one thing.

Keeping it running is something else entirely.

Several operational challenges appeared almost immediately.

Timeouts

Image generation takes time.

A three-second Lambda timeout might be fine for a simple API call.

It's not fine for image generation.

Increasing:

Timeout
Memory

became essential.

Region Mismatches

The number of issues caused by regions was surprising.

Examples included:

Missing models
Invalid model identifiers
S3 redirects
Bedrock availability issues

The lesson:

Always verify the region before assuming anything else is broken.

State Matters

State-driven systems are incredibly forgiving.

If something fails:

Status = Pending

remains unchanged.

The workflow can simply retry later.

This made the platform significantly more resilient.

Cost Considerations

One of the most interesting discoveries was how inexpensive the system remained.

Most usage came from:

Amazon Bedrock
Stability AI
Lambda executions
S3 storage

Because everything was serverless:

No servers
No virtual machines
No containers

The system only incurred costs when it was actually doing work.

For a side project, this was ideal.

Future Improvements

Even though the system now functioned end-to-end, there are still plenty of opportunities for expansion.

Some ideas include:

Engagement Analytics

Track:

Likes
Replies
Reposts
Follower growth

and feed the results back into future content generation.

Multiple Accounts

The architecture already supports additional social accounts.

Future versions could publish to:

TikTok
LinkedIn
Instagram
Threads

from the same content pipeline.

AI-Generated Threads

Instead of publishing individual posts:

1 Quote
↓
5 Related Ideas
↓
Thread

This would open entirely new content formats.

What I Learned

Looking back, the project taught me three important lessons.

1. Small Systems Compound

The final architecture looks impressive.

The reality is much simpler.

It was built one small component at a time.

First authentication.

Then content.

Then images.

Then automation.

Each step was manageable.

Together they became something much larger.

2. Simplicity Scales

The most valuable design decision wasn't an AI model.

It wasn't a specific AWS service.

It was keeping each component focused on a single responsibility.

Simple systems are easier to build.

They are also easier to debug.

3. AI Is Infrastructure Now

A few years ago, building something like this would have required significant machine learning expertise.

Today, foundation models and managed services allow developers to focus on the problem instead of the infrastructure.

That's a profound shift.

Conclusion

WizardThoughts started as an experiment.

Could a collection of cloud services create and manage a social media account without human involvement?

The answer turned out to be yes.

What began as a single Lambda function evolved into a complete content pipeline capable of:

✅ Generating original content

✅ Creating custom artwork

✅ Managing workflow state

✅ Scheduling its own execution

✅ Publishing automatically to X

More importantly, it demonstrated something larger.

Modern cloud platforms are no longer just hosting environments.

Combined with foundation models, they are becoming autonomous execution environments capable of generating, creating, and distributing content with minimal human involvement.

And in many ways, we're only just getting started.

From a single automated tweet to a fully autonomous content engine, WizardThoughts became proof that a handful of serverless services, a few AI models, and a lot of persistence can build something genuinely magical.

Part 3: AI Art at Scale: Generating Fantasy Images with Bedrock, Stability AI, and Amazon S3

Ashley Armstrong — Sun, 12 Jul 2026 08:07:12 +0000

The bot could think. The bot could write. The bot could even publish. But in a social media landscape dominated by visuals, words alone weren't enough.

The Missing Piece

By this point, WizardThoughts had evolved significantly.

The platform could:

✅ Generate original content

✅ Create engagement-focused posts

✅ Store everything in DynamoDB

✅ Publish automatically to X

From a technical perspective, things were working.

From a social media perspective, something was missing.

The posts looked empty.

I had built a content engine.

What I hadn't built was a visual identity.

And on modern social platforms, visuals often determine whether people stop scrolling long enough to read the content.

The next challenge became obvious:

Every post needed its own unique piece of artwork.

Why Images Matter

Take these two posts:

Version One

Every great wizard begins as a student.

Version Two

Every great wizard begins as a student.

Accompanied by:

An enchanted library
Floating spell books
Golden magical lighting
A student surrounded by ancient knowledge

The words haven't changed.

The experience has.

Images create context.

They create atmosphere.

Most importantly, they create attention.

Exploring Image Generation

Since text generation was already running through Amazon Bedrock, my first instinct was to stay inside the Bedrock ecosystem.

The ideal workflow looked like:

Generate Quote
       ↓
Generate Image Prompt
       ↓
Generate Artwork
       ↓
Publish Together

Simple.

At least in theory.

The Model Hunt

The first surprise came from discovering that not all image models are available everywhere.

While experimenting, I discovered models that:

Existed in one AWS region
Didn't exist in another
Were marked as legacy
Required different API formats

Something as simple as changing AWS regions suddenly became important.

I found myself bouncing between:

London
Ireland
US East
US West

trying to discover which models were actually available.

For a while, my most common error looked like this:

The provided model identifier is invalid.

Nothing was wrong with the code.

The model simply didn't exist in that region.

The Nova Canvas Detour

Initially, I experimented with Amazon Nova Canvas.

On paper, it seemed perfect.

An AWS-native image generation service integrated directly into Bedrock.

Then reality arrived.

The model was marked as legacy.

Attempts to invoke it resulted in messages like:

Access denied.
This model is marked as Legacy.

The lesson was frustrating but useful:

Just because a service appears in a catalogue doesn't mean it is the right service for your account.

Enter Stability AI

Eventually I shifted towards Stability AI's image models through Bedrock.

These were actively supported and capable of generating entirely original artwork from text prompts.

This introduced a new architecture:

GenerateContent
        ↓
Bedrock
        ↓
Quote + Image Prompt
        ↓
GenerateImage
        ↓
Stability AI
        ↓
PNG Image

The workflow was finally beginning to resemble the original vision.

Building the GenerateImage Lambda

The GenerateContent Lambda already produced output like:

{
  "quote": "Every wizard begins as a student.",
  "imagePrompt": "Young wizard studying glowing spell books inside an enchanted library"
}

Now I needed a second Lambda.

Its job was simple:

Read pending content from DynamoDB
Use the image prompt
Generate artwork
Save the result

The process looked like this:

DynamoDB
        ↓
Image Prompt
        ↓
Stability AI
        ↓
Base64 Image
        ↓
PNG File
        ↓
S3

Prompt Engineering, Part Two

Creating image prompts required a different mindset from creating text.

A poor image prompt looked like:

Wizard library

Technically valid.

Visually boring.

A stronger prompt looked like:

Ancient enchanted library, floating spell books,
golden magical lighting, cinematic fantasy artwork,
rich colours, volumetric light, highly detailed,
social media quality, no text

The difference was dramatic.

The more descriptive the prompt became, the more consistent the results became.

Another Unexpected Problem

The image generation worked.

The upload didn't.

After successfully creating images, I suddenly started receiving:

PermanentRedirect

errors from S3.

At first I assumed permissions were broken.

They weren't.

The issue was embarrassingly simple.

My bucket was located in:

eu-west-2

while the code was trying to access:

eu-west-1

One region mismatch.

Hours of debugging.

A classic cloud engineering lesson.

The S3 Layer

Once the region mismatch was fixed, every generated image flowed into an S3 bucket.

The storage structure looked like:

wizardthoughts-images/
       ├── post-123.png
       ├── post-124.png
       ├── post-125.png

Each image became its own reusable asset.

This provided several benefits:

Durable storage
Easy retrieval
Lower complexity
Simpler workflow management

Most importantly, it separated content generation from content publishing.

Updating DynamoDB

The image generation process wasn't complete until DynamoDB knew about it.

A successful image generation updated the record:

{
  "PostId": "post-123",
  "Status": "Pending",
  "ImageStatus": "Complete",
  "ImageUrl": "https://bucket.s3.amazonaws.com/post-123.png"
}

This allowed downstream services to know exactly what stage every post had reached.

The database effectively became a workflow engine.

Building a State-Driven System

As more functionality was added, an interesting pattern emerged.

Every component only needed to know one thing:

What is the current state?

The workflow became:

Pending
       ↓
Image Pending
       ↓
Image Complete
       ↓
Published

No service needed to know what happened before.

No service needed to care what happened next.

Everything was driven entirely by state transitions.

That dramatically simplified the architecture.

Seeing the First Results

The most satisfying moment came when the first generated image appeared.

Not downloaded.

Not manually uploaded.

Not created in a design tool.

Generated automatically.

Stored automatically.

Ready for publishing.

The project suddenly felt real.

The content wasn't just being written anymore.

It was being illustrated.

Every quote now had a matching visual story.

Lessons Learned

Three lessons stood out more than anything else.

1. Images Are a Force Multiplier

Good content becomes significantly more engaging when paired with relevant visuals.

The artwork amplified the message.

It didn't replace it.

2. AI Image Generation Is Prompt Engineering

The same lesson from text generation applied to images.

Better prompts produced better outcomes.

The model wasn't the limiting factor.

The instructions were.

3. Regions Matter

Cloud services are rarely as universal as they appear.

Always verify:

Region support
Model availability
Service limitations

before writing code.

It will save hours of debugging.

What's Next?

By this point, WizardThoughts could:

✅ Generate content

✅ Generate image prompts

✅ Create original artwork

✅ Store assets in S3

✅ Track workflow state in DynamoDB

The system was finally capable of producing complete content packages.

But one final challenge remained.

Everything still required orchestration.

The content engine needed a conductor.

In Part 4, we'll complete the journey by introducing EventBridge scheduling, automated publishing, workflow orchestration, and the architecture that transformed WizardThoughts into a fully autonomous social media platform.

Next: Part 4 — Going Fully Autonomous: EventBridge, DynamoDB, and Automated Publishing

Part 2: Prompt Engineering for Growth: Creating Viral Wizarding Content

Ashley Armstrong — Sun, 12 Jul 2026 08:00:13 +0000

Building a bot that could post was easy. Building a bot that people wanted to follow was something entirely different.

The Next Problem

After solving authentication and getting AWS Lambda to post to X, I found myself staring at a new challenge.

The infrastructure worked.

The API worked.

The automation worked.

But there was one small issue.

There was no content.

Every post still had to be written manually.

The original vision for WizardThoughts wasn't just automation.

The goal was autonomy.

I wanted a system that could:

Generate ideas
        ↓
Create content
        ↓
Create artwork
        ↓
Publish automatically

To make that happen, I needed the bot to think for itself.

Enter Amazon Bedrock

Amazon Bedrock became the content engine behind the project.

Rather than building custom AI infrastructure, Bedrock provided access to foundation models through a simple API.

My first objective was straightforward:

Generate a motivational quote inspired by a magical wizarding world.

The first prompt looked something like this:

Generate a motivational quote.

Requirements:
- Under 240 characters
- Suitable for X

Technically, it worked.

The quality wasn't great.

The Generic AI Problem

The first quotes sounded like every motivational page on the internet.

Examples looked like:

Believe in yourself and great things will happen.

Or:

Success comes to those who never give up.

Perfectly valid.

Perfectly boring.

The problem wasn't the model.

The problem was the instructions.

I had accidentally built a generator for the world's most forgettable content.

The Realisation

Most people approach AI prompting as a writing exercise.

I started viewing it as product design.

The prompt wasn't just generating text.

The prompt was defining the personality of the account.

Every instruction influenced:

Engagement
Shareability
Memorability
Follower growth

The goal wasn't:

Generate content.

The goal became:

Generate content that people want to interact with.

That changed everything.

Reverse Engineering Engagement

I started looking at the types of posts that consistently perform well on social media.

Certain patterns emerged repeatedly.

Curiosity

People love unanswered questions.

Examples:

What if...
Have you ever...
Imagine if...

Curiosity creates a psychological need for resolution.

People stop scrolling.

Nostalgia

Wizarding World fans are incredibly nostalgic.

Posts that trigger memories often outperform pure motivational content.

For example:

Remember when discovering a new spell felt like endless possibility?

The post isn't selling anything.

It's creating a feeling.

Identity

People engage with content that reinforces their identity.

Instead of:

Work hard and succeed.

I started generating posts like:

Every wizard begins as a student.

The same lesson.

A more relevant story.

Conversation

The biggest breakthrough came from discussion-driven posts.

Instead of broadcasting messages, I wanted the account to invite participation.

For example:

If you could learn one magical skill in real life, would you choose courage, wisdom, or luck?

Simple.

Yet far more likely to generate replies.

Redesigning the Prompt

Eventually I completely replaced the original prompt.

Instead of asking for a motivational quote, I asked the model to create different content categories.

Generate ONE of the following at random:

1. Inspirational wizarding quote
2. Magical life lesson
3. "What if..." wizarding thought
4. Wizarding world observation
5. Unpopular magical opinion
6. Question that encourages replies
7. Nostalgia-based magical post
8. Magic and mindset lesson

This single change dramatically improved output variety.

The account stopped sounding like a quote generator.

It started sounding like a personality.

Designing for Followers

Follower growth wasn't going to come from posting more.

It was going to come from posting better.

Every prompt was designed around three objectives.

1. Stop The Scroll

The first sentence had to create interest.

Examples:

What if...
Imagine...
Most wizards...

Hooks matter.

Without them, nothing else matters.

2. Reward The Reader

A post should leave someone with:

An insight
A question
A feeling
A memory

Something worth taking away.

3. Encourage Action

Not every post should ask for engagement.

But some should.

Questions became a deliberate part of the content strategy.

Which magical lesson has helped you most in real life?

Simple.

Yet effective.

Generating Images Too

At this point another problem appeared.

The text was improving.

The visuals didn't exist.

I wanted the model to create image prompts alongside the content.

So the prompt evolved again.

Instead of returning:

{
  "quote": ""
}

It now returned:

{
  "quote": "",
  "imagePrompt": ""
}

For example:

{
  "quote": "What if the strongest magic has always been the courage to keep going when the path ahead is uncertain? #Magic #WizardingWorld #Mindset",
  "imagePrompt": "Young wizard standing on a cliff overlooking a glowing magical castle at sunrise, cinematic fantasy artwork, magical atmosphere, rich colours, volumetric lighting, highly detailed, no text"
}

Now every post automatically contained the instructions needed to generate matching artwork.

Storing Content in DynamoDB

Once content generation was working, the next step was persistence.

Every generated post was stored in DynamoDB.

The structure looked like:

{
  "PostId": "post-123456",
  "Content": "...",
  "ImagePrompt": "...",
  "Status": "Pending",
  "ImageStatus": "Pending"
}

This transformed DynamoDB into the workflow engine for the entire platform.

Everything became state-driven.

No manual tracking required.

One Unexpected Problem

Large language models are not always obedient.

Despite explicitly asking for JSON, the model occasionally returned valid JSON wrapped in Markdown code fences rather than raw JSON.

For example:

{
  "quote": "...",
  "imagePrompt": "..."
}

My parser expected raw JSON.

The model decided to be helpful.

Unfortunately, that helpfulness immediately broke the workflow.

The lesson?

Never trust model output.

Always validate and clean responses before processing them.

It was a small issue, but an important one.

Measuring Success

The interesting thing about prompt engineering is that success isn't measured by whether the model responds.

It's measured by whether the audience responds.

A technically perfect answer can still be terrible content.

What mattered was:

Likes
Replies
Shares
Follows

Those became the real evaluation metrics.

The AI wasn't writing for me.

The AI was writing for the audience.

Lessons Learned

Three lessons stood out.

1. Prompting Is Product Design

Every instruction affects behaviour.

Every sentence influences output quality.

A prompt is not a command.

It's a specification.

2. Variety Drives Engagement

People don't follow accounts that repeat the same idea.

Randomising content categories increased quality and prevented repetition.

3. The Model Is Not The Product

Bedrock generated the content.

But the real value came from:

Prompt design
Workflow design
Distribution design

The model was just one component in a larger system.

What's Next?

By this point, WizardThoughts could:

✅ Generate original content

✅ Produce engagement-focused posts

✅ Create image prompts

✅ Store content automatically

But something was still missing.

The account had words.

It had ideas.

It had personality.

What it didn't have was artwork.

In Part 3, we'll build the visual side of the platform using Stability AI, Amazon S3, and automated image generation.

Because on social media, attention may start with words.

But it is often captured by images.

Next: Part 3 — AI Art at Scale: Generating Fantasy Images with Bedrock and Stability AI

Part 1: Authentication Hell: Getting AWS Lambda Talking to X

Ashley Armstrong — Sun, 12 Jul 2026 07:50:58 +0000

How a simple idea turned into a multi-day battle with APIs, OAuth, and enough authentication errors to fill a spellbook.

The Idea

Every project starts with a simple question.

For me, it was:

Could I build an autonomous Wizarding World content engine that generates its own content, creates its own artwork, and publishes directly to X without human involvement?

The concept seemed straightforward.

The vision was:

AI generates quote
        ↓
AI generates artwork
        ↓
AWS stores content
        ↓
X publishes post

In theory, this looked like a weekend project.

In reality, it became an education in authentication systems, API permissions, OAuth flows, and the many ways technology can tell you "no".

Building the Foundation

I decided to build everything on AWS.

The initial stack looked like this:

AWS Lambda
Amazon DynamoDB
Amazon Bedrock
Amazon S3
EventBridge
X API

The first objective was intentionally small:

Post a single tweet from AWS Lambda.

Not an AI-generated tweet.

Not an image.

Just a tweet.

How hard could that be?

The First Lambda

The first Lambda function was incredibly simple.

Create Lambda
Install twitter-api-v2
Add environment variables
Call tweet endpoint

Five minutes later everything was deployed.

I clicked Test.

It failed.

Welcome to OAuth.

The Authentication Rabbit Hole

If you've worked with X's API before, you'll know there isn't just one way to authenticate.

There are several.

At first glance they all appear to do similar things:

Bearer Token
OAuth 2.0
OAuth 2.0 User Context
OAuth 1.0a

The challenge is understanding which one works with which endpoint.

I made what seemed like the obvious choice.

I used the Bearer Token.

The result?

403 Forbidden

Not very helpful.

After digging through the logs, I eventually found the real message:

Unsupported Authentication

Authenticating with OAuth 2.0 Application-Only is forbidden for this endpoint.

This was my first major lesson.

Just because you're authenticated doesn't mean you're authorised.

Understanding the Difference

The problem wasn't my code.

The problem was the type of identity I was presenting to X.

A Bearer Token represents:

The application

A User Context token represents:

The user

Posting a tweet requires a user.

Not just an application.

In other words:

Application:
"Hello, I am WizardThoughts."

X:
"Great."

Application:
"I would like to tweet."

X:
"No."

Chasing the Right Token

I spent hours moving between:

AWS Lambda
CloudWatch Logs
X Developer Portal

Testing.

Deploying.

Testing again.

Every change seemed to produce a different error.

Sometimes:

401 Unauthorized

Other times:

403 Forbidden

And occasionally:

Unsupported Authentication

At one point I genuinely believed I had broken the entire account configuration.

The reality was much simpler:

I was using the wrong type of token.

The First Real Breakthrough

Rather than trying to post tweets, I decided to verify authentication first.

Instead of:

client.v2.tweet(...)

I switched to:

client.v2.me()

This endpoint simply returns information about the currently authenticated user.

If that worked, I would know the authentication was correct.

If it failed, the token was wrong.

Suddenly I received:

{
  "username": "WizardThoughts"
}

That was the first real victory.

For the first time, AWS Lambda had successfully authenticated with X.

No guessing.

No assumptions.

Proof.

The OAuth 2 Dead End

With authentication seemingly solved, I moved on to images.

That's when another problem appeared.

The basic tweet APIs worked.

Media uploads did not.

The logs revealed a new pattern.

Every media upload attempt failed with:

403 Forbidden

After more debugging, I discovered another important distinction.

Text posting could work using:

OAuth 2 User Context

Media uploads were much happier with:

OAuth 1.0a User Context

Which meant I needed four credentials:

CONSUMER_KEY
CONSUMER_SECRET
ACCESS_TOKEN
ACCESS_TOKEN_SECRET

Suddenly the full picture started making sense.

The Moment Everything Clicked

The final authentication test looked like this:

const client = new TwitterApi({
  appKey: process.env.CONSUMER_KEY,
  appSecret: process.env.CONSUMER_SECRET,
  accessToken: process.env.ACCESS_TOKEN,
  accessSecret: process.env.ACCESS_TOKEN_SECRET
});

const me = await client.v2.me();

Response:

{
  "username": "WizardThoughts"
}

Success.

Not a partial success.

Not a maybe.

A genuine, repeatable success.

The authentication layer was finally solved.

The First Automated Tweet

Once the OAuth issues were resolved, posting a tweet became almost trivial.

The same infrastructure that had spent days refusing to cooperate suddenly worked exactly as intended.

The first tweet appeared.

Not created manually.

Not posted from a browser.

Automatically.

Directly from AWS Lambda.

That single post represented far more than a tweet.

It proved the entire foundation was viable.

Lessons Learned

Three lessons stood out above everything else.

1. Authentication Is a Product Feature

Most developers treat authentication as setup.

It isn't.

It's part of the application.

Understanding identities, scopes, permissions, and token types is essential.

2. Trust Error Messages

Most of my mistakes came from ignoring what the logs were telling me.

Eventually every answer was in CloudWatch.

The challenge was learning how to read it.

3. Prove Identity First

Before attempting any complex API action:

Authenticate
↓
Verify user
↓
Then perform action

Testing with v2.me() saved hours of debugging.

What's Next?

At this point the bot could successfully:

✅ Authenticate with X

✅ Run in AWS Lambda

✅ Post automated tweets

But it still had one major limitation.

Every tweet had to be written manually.

In Part 2, we'll teach the bot how to think for itself using Amazon Bedrock, prompt engineering, and growth-focused content generation.

Because a bot that can post is useful.

A bot that can create its own content is where the magic begins. ⚡🪄

Next: Part 2 — Prompt Engineering for Growth: Creating Viral Wizarding Content

DEV Community: Ashley Armstrong

Part 4: Going Fully Autonomous: EventBridge, DynamoDB, and Automated Publishing

The Final Challenge

The Goal

DynamoDB Becomes the Brain

Building a State Machine Without a State Machine

GenerateContent

GenerateImage

PublishToX

EventBridge: The Invisible Conductor

Content Generation

Image Generation

Publishing

Publishing Images to X

Authentication: The Sequel

The Moment It Became Real

Operational Lessons

Timeouts

Region Mismatches

State Matters

Cost Considerations

Future Improvements

Engagement Analytics

Trending Topics

Multiple Accounts

AI-Generated Threads

What I Learned

1. Small Systems Compound

2. Simplicity Scales

3. AI Is Infrastructure Now

Conclusion

Part 3: AI Art at Scale: Generating Fantasy Images with Bedrock, Stability AI, and Amazon S3

The Missing Piece

Why Images Matter

Version One

Version Two

Exploring Image Generation

The Model Hunt

The Nova Canvas Detour

Enter Stability AI

Building the GenerateImage Lambda

Prompt Engineering, Part Two

Another Unexpected Problem

The S3 Layer

Updating DynamoDB

Building a State-Driven System

Seeing the First Results

Lessons Learned

1. Images Are a Force Multiplier

2. AI Image Generation Is Prompt Engineering

3. Regions Matter

What's Next?

Part 2: Prompt Engineering for Growth: Creating Viral Wizarding Content

The Next Problem

Enter Amazon Bedrock

The Generic AI Problem

The Realisation

Reverse Engineering Engagement

Curiosity

Nostalgia

Identity

Conversation

Redesigning the Prompt

Designing for Followers

1. Stop The Scroll

2. Reward The Reader

3. Encourage Action

Generating Images Too

Storing Content in DynamoDB

One Unexpected Problem

Measuring Success

Lessons Learned

1. Prompting Is Product Design

2. Variety Drives Engagement

3. The Model Is Not The Product

What's Next?

Part 1: Authentication Hell: Getting AWS Lambda Talking to X

The Idea

Building the Foundation

The First Lambda