DEV Community: Sean Boult

3 Ways to Manage Files in CloudShell

Sean Boult — Thu, 20 Aug 2026 16:48:35 +0000

So you've probably had to open CloudShell from time to time to poke at something quickly. Say I wanted to test pulling down an artifact from a private CodeArtifact registry. To do that, I'd need to tweak my ~/.npmrc so npm points at the right registry.

Which raises the question: what's the best way to edit a file once you're in CloudShell? Let's look at a few options.

Using vim

I use Neovim btw (sorry emacs users), so naturally I'm starting with vim.

vim ~/.npmrc

If you're already comfortable with Vim, this is probably the fastest option. You're already in the terminal, you get all the navigation and search you're used to, and there's nothing else to open.

Make your changes, hit ESC, and :wq (write + quit) to save the file.

Using nano

Ah the old classic. I've been using this for decades to edit files on remote boxes.

nano ~/.npmrc

Unlike Vim, there's not much to learn before you can start typing. Nano even shows you the important shortcuts at the bottom of the screen.

Make your changes, hit CTRL+O to write them to disk, and CTRL+X to exit.

If you just need to make a quick edit and get out, nano is hard to beat.

Using edit

Okay, but what if you don't want to use a terminal editor at all?

CloudShell has an edit command that opens the file directly in its built-in editor.

edit ~/.npmrc

Instead of editing inside the terminal, CloudShell opens the file in a familiar graphical editor where you can point, click, type, and save with CMD+S (CTRL+S on Windows/Linux) or the save icon.

If you're used to editing files in VS Code or another graphical editor, this is probably going to feel the most familiar.

No Vim modes. No terminal keybindings to remember.

Which one should you use?

Honestly, whichever gets you back to solving the actual problem fastest.

Editor	Use it when...
vim	You're comfortable with Vim and want to stay in the terminal
nano	You want a simple terminal editor without learning Vim
edit	You'd rather use a familiar graphical editor

So the next time you find yourself debugging something from CloudShell, you've got a few ways to quickly read or edit a file without leaving your browser.

As always, happy coding 😄!

Follow AWS for more articles like this and follow me for all things tech.

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Sean BoultFollow

Developer. Hacker. Creator.

so close to 4k followers on here, currently sitting at 3,973 🥹

Sean Boult — Mon, 10 Aug 2026 21:26:21 +0000

🛫 I Vibe Coded a Website at 35,000 Feet 🛬

Sean Boult — Tue, 04 Aug 2026 16:00:00 +0000

🛫 Wheels up and I had three hours with nothing but airplane Wi-Fi...

So naturally, I decided to vibe code an entire website before landing.

I've written about Waddles before, so I thought, what if I created him a little home on the web.

So I got myself connected to the Delta Wi-Fi, cracked open Codex, and got to prompting.

For my agentic workflow, I start by describing the MVP requirements to my agent in the chat and have it write out the plan to a markdown file.

This allows me to ideate and steer the agent along the way with how I want the stack to look. You can see my iterations of the PROMPT.md over time.

I configured things like what tech stack we wanted to use, how we wanted to deploy, as well as the basic idea for the website.

What was the original tech stack I landed on?

Category	Stack
Frontend	React 19, TypeScript
Build	Vite 8
Tooling	Node.js 24, pnpm, Turborepo
Hosting	Amazon S3
CDN	Amazon CloudFront
DNS & TLS	Route 53, AWS Certificate Manager
Infrastructure	AWS CDK / CloudFormation
CI/CD	GitHub Actions with AWS OIDC

So what did I build? I created a simple static site, waddles.website, where Waddles can continuously surf the web and give you interesting quotes.

Here is what the plane-shipped version looked like running on localhost:

Pretty simple, just an ASCII duck (Waddles) surfing on the DOM, literally.

So that was working locally after several prompts. Now I was ready to ship it to the cloud and ready for the deployment...

I had one pit stop to make, though: a domain name. So I saw .website domains are a good fit for this. At $2/year, you can't beat that.

It's now deployment time, and I already had Agent Toolkit for AWS set up. It was able to help me scaffold out all the CDK code needed to get a static application up.

Then I used aws login to get some credentials to my admin role, bootstrapped my account, and smashed the cdk deploy command only to hit my first hurdle...

Uploading 20 MB ZIPs for my CFN deployment on airplane Wi-Fi was giving me timeouts 😅. So I had to figure something out, and Codex suggested a fantastic workaround. Just push the code to GitHub and let CI/CD be the one to deploy the CloudFormation stack.

Alas, we got the code up to github.com and it finally saw the ✅.

Over the weekend I put a bit more polish on it.

I migrated to AWS Amplify so I didn't have to manage CDK and could have preview environments.

You can share your favorite Waddles quote and if you want, contribute a new quote to the repo.

Happy Vibe Coding 😎!

Follow AWS for more articles like this.

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Follow me for all things tech.

Sean BoultFollow

Developer. Hacker. Creator.

Did You Know TLDs Can Be Websites?

Sean Boult — Thu, 16 Jul 2026 19:41:43 +0000

You've probably registered a domain with Route53 or another popular registrar.

You pick something like seanboult.dev, spin up a web server, configure your A record, attach a TLS cert, and boom it's live.

Well in the past, before the AI boom, there once was a web server on .ai and it made its way to Hacker News.

This was a cool relic that always intrigued me. Here is a snapshot from the Wayback Machine.

Now you're like wait, I can't go to http://ai today? No, sadly at some point the A record was removed and the web server was shut down.

Don't worry though, at the time of writing this I found another one.

Without further ado, here it is! https://uz.

Seems the TLS cert does not match the common name so you'll have to force your way in...

But then you're in!

So how does this work?

Well, the same way you can add an A record to the apex of your domain (such as example.com), a registry operator can add DNS records directly to the apex of a Top-Level Domain zone, such as .uz in this case.

Would love to know if you find more like this, leave a reply if you do.

If we ever did one on .aws what would you like to see there 🤔?

As always, happy coding 😉!

Follow AWS for more articles like this.

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Follow me for all things tech

Sean BoultFollow

Developer. Hacker. Creator.

Bidwatch - Search Live Ebay Auctions Ending Soon

Sean Boult — Sat, 11 Jul 2026 18:04:21 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I use ebay.com a lot as a passionate card collector to find auctions. It's super difficult to use their filters on both the web and mobile, but mobile is especially frustrating.

The goal was to build a simple app that allows users to search for any auctions on eBay, filter those listings, find the ones ending soon, and save their filter preferences to find auctions more quickly.

In Bidwatch, you can look for auctions ending soon with bids, no bids, or all auctions. These filters help you understand market sentiment for prices and see what's actually popular.

I've used the app many times now to win some really awesome auctions that I would have never seen otherwise.

Demo

How I Built It

AI helped me ship this pretty fast...

I validated the idea was possible by starting up Codex Chat and explaining the basic MVP. It helped me research the ebay.com REST API offerings and confirmed it was possible to get all the data I needed.

Codex helped me create a PRD (Product Requirements Document) for the MVP. Initially, that was literally just pulling search data back.

The scope grew over time, and more and more features were added, such as filters, authentication, caching, and favoriting.

Here is a quick look at the system architecture.

Excited to be part of this challenge and see all the other project submitted.

If you have any feedback or questions leave a comment.

Visit bidwatch.app today 🚀

Happy coding 😛!

Follow me for all things tech

Sean BoultFollow

Developer. Hacker. Creator.

Why Error Messages Matter More in the Age of AI

Sean Boult — Fri, 10 Jul 2026 12:45:24 +0000

Everyone talks about AI writing code.
Nobody talks about AI debugging code.

Bad error messages are the worst, we've all seen them. You open the logs or run your program and see something like this...

Error: something went wrong

It leaves you asking:

What happened?
Where did it happen?
Why did it happen?
How do I fix it?

You might have written some of these pretty silly error messages, I know I have. They don't help us fix software quickly because we first have to figure out why the error happened.

Rust has been shipping fantastic error messages for years.

Take this example where I accidentally call println instead of println!.

$ cargo run                                                                                                   101 ↵
   Compiling ducksay v0.2.0 (~/oss/ducksay)
error[E0423]: expected function, found macro `print`
  --> src/main.rs:51:3
   |
51 |   print("{}", render_with_style(&message, cli.width.get(), style));
   |   ^^^^^ not a function
   |
help: use `!` to invoke the macro
   |
51 |   print!("{}", render_with_style(&message, cli.width.get(), style));
   |

It's fantastic! It tells you what went wrong, where it occurred, and how to fix it.

When you're building software, you should make your error messages exceptional (punny 😂).

Here's another example from Vite+ where I had a syntax error in the config file.

$ vp dev

failed to load config from ~/oss/test-ssr-on-aws/vite.config.ts
error when starting dev server:
Error: Build failed with 1 error:

[PARSE_ERROR] Error: Unexpected token
   ╭─[ vite.config.ts:5:3 ]
   │
 5 │   ,
   │   ┬
   │   ╰──
───╯

Now imagine debugging code with generic error messages that tell you absolutely nothing helpful. You'll have to manually trace through the code to figure out what the heck is going on.

AI agents run into the same problem. If the error tells them almost nothing, they have to spend extra time reading files, tracing execution paths, and making additional tool calls just to understand what failed.

So what can we do to help humans and AI? Here are some of my top recommendations for writing good error messages.

1. Be descriptive and specific

We started with Error: Something went wrong and it tells us almost nothing.

Instead, tell them exactly what happened and where it happened.

Error: Failed to load config.toml.

config.toml:23
Unknown property "waddles".

2. Emit structured logs

A good error message is one thing, but don't forget about the logs around it.

Using a structured logger like pino means every log includes useful metadata like timestamps, log levels, and request IDs.

If you're writing JavaScript, pair it with pino-pretty and your logs become a lot easier on the eyes too 💅.

[17:35:28.992] ERROR (1337): Loading configuration failed, unknown property "waddles" config.toml:23

Those logs aren't just useful in your terminal. Once they're in your observability platform, you can search, filter, and correlate events across your application. CloudWatch now supports OpenTelemetry, so all of that structured context comes along for the ride.

The more useful context your logs contain, the less detective work there is for both you and your AI agent.

3. Provide solutions/hints

When things go wrong (and they will), a simple hint can save someone a lot of time.

Error: Missing required environment variable "DATABASE_URL".

hint: Add DATABASE_URL to your .env file or export it before starting the application.

Not every error can tell you exactly how to fix it, and adding hints can take extra work. But if you already know the most common fix, include it anyway. It'll save someone or an AI agent a trip to the documentation.

FWIW some of these will only make sense when you are in a trusted environment. When giving errors to clients it's best to not give them more than they need, otherwise you might leak information that could help an attacker.

For trusted environments like a local CLI tool or a server application where you control the logs it's ideal to craft really detailed messages.

Good error messages have always mattered. AI agents make them even more valuable.

AI is getting better at writing code every day. We should make it just as good at debugging it.

Follow AWS for more articles like this.

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Follow me for all things tech.

Sean BoultFollow

Developer. Hacker. Creator.

Quickie Posts, Is Anyone Using Them?

Sean Boult — Mon, 29 Jun 2026 20:09:34 +0000

So there is this feature on dev.to called "Quickie Posts".

They meant to be short twitter like posts then show up on the home feed.

I've tried a few times but never got any traction on them. Curious have you used them or did the feature never really take off?

Some original lore from @ben.

Ben Halpern

Nov 12 '24

This is a new thing: A type of quick post that doesn't show up on your profile or in notifications. It's in beta, and we have a few adjustments and improvements in the pipeline — but if you have ideas, let me know.

1 min read

If you have not tried a quickie post, maybe give it a try today and let me know your experience.

have you installed the Agent Toolkit for AWS yet?

Sean Boult — Tue, 16 Jun 2026 21:03:54 +0000

Testing Neovim in a Container with Finch (like Docker)

Sean Boult — Fri, 12 Jun 2026 15:30:00 +0000

So developers like CI... for everything! We do this because we like things to be automated.

Building software is tedious and risky. If we can push a commit and let things happen in the cloud to give our change confidence, we absolutely will do that to reduce that potential risk.

Now let's get into what this blog is about, brace yourself...

I've been using Neovim for a few years now and maintain my own config. Updating Neovim or my plugins is often considered scary because you are trusting a whole lot of maintainers to not make a breaking change that could bring you to a screeching halt.

One day I had a wild idea. Is it possible to test the most critical part of my workflow? To me that's the TypeScript LSP which gives me hover diagnostics, go to definitions, and of course, the red squiggles.

Now the implementation is somewhat involved but you can take a peek at my dotfiles repo to learn more about how it works, I won't dive too deep here.

Originally I only supported Docker because it's been one of my toolchains for a long time, over a decade at this point. I recently learned about Finch, an open source project by AWS which allows you to build and run containers.

Finch is a drop-in replacement for Docker so I updated my CLI (hack) to let me specify docker or finch via an env var (HACK_CONTAINER_RUNTIME) or CLI flag (--runtime).

So I can start a run with Finch:

hack --runtime finch

Once the build and tests finish, you should see output showing that the TypeScript LSP was able to report diagnostics, which gives me confidence that my Neovim setup isn't broken.

⌛ Starting TypeScript LSP validation...   
📊 TypeScript diagnostics found: 1    
  [1] Type 'number' is not assignable to type 'string'.
✅ LSP validation completed successfully!
✅ Neovim test ran successfully...
NVIM v0.12.2
Build type: Release
LuaJIT 2.1.1774638290
Vim versions: 8.1, 8.2, 9.0, 9.1, 9.2

What happened at a high level after running the hack CLI:

Builds the container image with Finch
Installs Neovim and development tools in the container
Links the Neovim configuration into the container
Starts the test container in Finch
Neovim opens a TypeScript test file
Runs a custom Neovim command to verify the TypeScript LSP works
Success 🥳

My test is pretty narrow but solves my use case of ensuring my TypeScript LSP will work when new plugins and Neovim updates land.

Give Finch a try for running containers locally and let me know what you think in the comments.

Happy Coding 🙂!

Follow AWS for more articles like this

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Follow me for all things tech

Sean BoultFollow

Developer. Hacker. Creator.

AWS Waddles: What the Duck?

Sean Boult — Mon, 01 Jun 2026 23:33:50 +0000

For over a decade, there's been a tiny ASCII duck hiding in plain sight. Open the page source for amazon.com, scroll all the way to the bottom, and there it is, surfing the web and quietly meowing at anyone who looks.

<!--       _
       .__(.)< (MEOW)
        \___)
 ~~~~~~~~~~~~~~~~~~-->

A few years ago I stumbled onto this meowing duck, and it turns out the internet had too. MEOW has lived in that source code for years. If you've never seen it, go look now!

One day I thought, why not bring that same duck energy to AWS? So I made my own mascot. Same surfing spirit, except this one doesn't meow. It barks. Meet Waddles.

<!--       _
       .__(.)< (woof)
        \___)
 ~~~~~~~~~~~~~~~~~~-->

Waddles made his first appearance on March 12, 2026 and landed on the timeline on X/Twitter.
// Detect dark theme var iframe = document.getElementById('tweet-2032135107977322989-291'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2032135107977322989&theme=dark" }

You'll be seeing Waddles around more, but I figured I owe the internet an explanation of sorts.

Ok, I think all my ducks are in a row now 😂.

# Waddles takin a nap
    _
.__(_)<
 \___)

Want your own Waddles? I built a little tool called ducksay. Check out the repo here. Give it a message and it hands it right back to you, duck included:

$ ducksay "woof"
<!--       _
       .__(.)< (woof)
        \___)
 ~~~~~~~~~~~~~~~~~~-->

If ducks aren't your thing, drop some of your favorite ASCII art in the comments. Waddles could use some friends.

Happy Coding 🤗!

Follow AWS for more articles like this

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Follow me for all things tech

Sean BoultFollow

Developer. Hacker. Creator.

Markdown Should be Supported Everywhere Natively

Sean Boult — Fri, 29 May 2026 19:27:54 +0000

You've probably seen this tweet by @trq212 floating around on Twitter about letting agents write HTML instead of markdown...

// Detect dark theme var iframe = document.getElementById('tweet-2052811606032269638-893'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2052811606032269638&theme=dark" }

Listed below are some of the reasons mentioned in the article:

Information Density
Visual Clarity & Ease of Reading
Ease of Sharing (to me this is the most compelling)

I don't disagree with Tariq, but rather than switch to HTML, I think the answer is to make markdown supported everywhere. We've been using it for years and it's powering much of the modern web. However, if we look at how software and platforms have evolved, markdown support is very dependent on the platform to render it.

Why does markdown work for humans and machines? Well, it's pretty simple, humans write simple syntax that gets rendered into something rich, and unironically, that's often by converting it to HTML and a browser engine rendering it. For machines, it's lightweight to parse and easy to generate token by token without the verbosity of HTML.

We write headers, code blocks, pull quotes, bold text, and what typically happens is something is converting that markdown to HTML.

For example, I am literally typing this blog in markdown, and the only way I can share it to the masses is through a platform like dev.to that converts it to HTML and hosts it for me.

So if the feature is available in some places, why is it not everywhere? I believe that software vendors haven't prioritized adding markdown rendering support, and they should.

We should be able to send a standalone index.md file and view it in all web browsers, chat applications, and emails. Some apps already do this like Discord and Slack (Slack's markdown support disappoints me). We can do this with HTML today, all modern browsers will render something nice, but if you load up markdown in your browser today you will become sad.

We have to reach for things like Obsidian or Kiro to render the markdown, which I feel limits the portability of it all.

Curious what you think and where you see yourself heading in terms of AI agent output. Let me know in the comments if you're switching to HTML or sticking with markdown.

As always, happy coding 🫡!

Follow AWS for more articles like this

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.

Terminal Superpowers You Should Be Using in 2026

Sean Boult — Tue, 19 May 2026 15:00:00 +0000

I live in my terminal. Here's what I use to stay fast.

Fuzzy finder (fzf)
Terminal motions
Sudo shortcut
Tab completion
Autosuggestion
Autocompletion
Syntax highlighting
Command buffering
Terminal clearing

⚠️ NOTE: Some of these are zsh-specific, so make sure you have that set up first.

Fuzzy finder (fzf)

Please please stop spamming up arrow to find that command you ran. Instead you can make this so much simpler with fzf.

Once installed, hit Ctrl+R and your shell history becomes searchable. No more mashing the up arrow 47 times to find that docker command you ran last Tuesday.

You can also use it to find files:

# fuzzy find a file and open it in your editor
vim $(fzf)

Or pipe anything into it:

# search git branches
git branch | fzf

Seriously, just install fzf.

Terminal motions

Stop holding backspace and typing everything all over again...

Here are the motions that saved me the most time:

Shortcut	What it does
`Option + ←/→`	Jump by word
`Option + Backspace`	Delete a word
`Ctrl + A`	Jump to beginning of line
`Ctrl + E`	Jump to end of line
`Ctrl + K`	Delete everything after cursor

Drill these for a week and holding backspace will start to physically hurt you.

Sudo shortcut

You've done this before:

apt install something
# Permission denied

Instead of retyping the whole thing, just run:

sudo !!

!! expands to your last command. Done.

Tab completion

ZSH tab completion goes further than bash:

Tab into directories and keep going (no need to hit enter between each level)
Cycle through matches with repeated tab presses
Case-insensitive matching by default

In this case I did ~/.aw<tab>/co<tab>.

If you're typing full paths by hand, you're doing it wrong.

Autocompletion

Some CLI tools ship with their own completions for subcommands and flags. The AWS CLI is a good example:

# Add this to your .zshrc
autoload bashcompinit && bashcompinit
autoload -Uz compinit && compinit
complete -C '/usr/local/bin/aws_completer' aws

Now aws s3<TAB> shows you all the s3 subcommands. Most popular CLIs (docker, kubectl, gh, npm) have similar setups. Check their docs.

Autosuggestions

zsh-autosuggestions gives you fish-like behavior in ZSH. As you type, it shows a grayed-out suggestion based on your history. Press the right arrow to accept it.

Give it a few days and you won't be able to go back.

Syntax highlighting

zsh-syntax-highlighting highlights your commands as you type. Valid commands go green, invalid go red. It's instant feedback before you even hit enter.

You catch typos before you hit enter. That's it, that's the sell.

Command buffering

Kick off a long-running command like pnpm i, then just type your next command and hit enter. ZSH buffers it and runs it when the first one finishes.

You're typing blind so typos happen, but it beats waiting around.

Terminal clearing

Two quick ones:

clear (or Ctrl + L) - clears the screen but keeps scrollback
Cmd + K - nukes everything including scrollback

I use Cmd + K when I want a clean slate and clear when I just want visual breathing room.

Resources

Here's everything linked in one place:

That's my setup. Most of these take under a minute to install and will save you hours over time. If you found this useful, feel free to follow me for more dev tooling tips.

Happy coding 😀!

Also follow AWS for more articles like this

AWS Follow

Articles written by current and past AWS Developer Advocates to help people interested in building on AWS. Opinions are each author's own.