To start this journal—and to reignite my studying after a long period of not coding due to working too much—I realized that I needed to rebuild my foundation. I had to refresh my memory on basic tools and technologies such as GitHub, Tailwind CSS, Next.js, React, and CSS, and I also wanted to start learning AWS.
The main reason I wanted to learn AWS was simple: I wanted to be able to deploy my own work and not depend on anyone else.
The Problem
The problem was that relearning GitHub, Tailwind, and Next.js from scratch felt incredibly time-consuming—and honestly, wasteful. I’ve worked with these technologies for years. Starting over from the beginning didn’t feel like the best use of my time.
So I made a decision:
I would let AI—specifically OpenAI’s Codex—handle the parts I didn’t fully remember or didn’t want to do yet, so I could focus on learning what actually interested me.
What I Did
I asked Codex to build a portfolio website (this website) using Next.js, based on my description. After that, I went in and fixed the details until I was satisfied. That fixing process helped refresh my memory of Tailwind, GitHub, and Next.js in a very natural way.
But then a new question came up:
How can I upload my writing or blog posts to the website?
Building a Markdown Editor
I asked Codex to help me build a Markdown editor. While doing that, I had an idea:
Why not save the Markdown documents to an S3 bucket?
So I asked ChatGPT to give me a step-by-step tutorial on how to do this. That way, I could learn AWS S3 at the same time.
Adding Databases (Why Not?)
Then I thought: Why stop there? Why not use a database?
I decided to create another version of the app that saves data to DynamoDB, AWS’s NoSQL database service. Of course, I didn’t want to delete the S3 version—so I created a new GitHub branch for DynamoDB.
Then, gaining some momentum, I created yet another branch and let Codex build a version of the Markdown editor that saves entries to RDS (PostgreSQL).
Cool, right?
Comparing the Options
I asked ChatGPT which solution would be best in terms of budget and efficiency for my situation. The answer was:
- S3 is the cheapest
- RDS (PostgreSQL) is the most expensive
- DynamoDB sits somewhere in between
However, I realized that using S3 alone makes searching difficult. To implement search, I would need to load all Markdown files from S3 into memory every time a search runs—and that’s inefficient and potentially costly.
That’s why ChatGPT suggested a hybrid approach:
- Store file content in S3
- Store metadata (titles, tags, timestamps) in DynamoDB
Using RDS/PostgreSQL would be overkill for my current needs.
The Result
I now have four versions of the Markdown editor across different GitHub branches:
What I Learned
I’m not particularly proud of the code itself, since most of it was generated by Codex. However, the learning process turned out to be far more valuable than the code.
First, this project helped me refresh my memory of frontend fundamentals I hadn’t touched in a while—React, Next.js, CSS, and Tailwind. Fixing and tweaking AI-generated code turned out to be an effective way to relearn things I already knew but hadn’t actively used.
I also learned how AWS access control works in practice. I now understand how IAM users, user groups, and policies are used to grant access to AWS resources, and why generating an access key is necessary for applications to interact with AWS services. Learning how granular AWS policies can be was especially interesting.
Working with different storage solutions taught me a lot about trade-offs in system design. I learned that creating an RDS database requires a dedicated compute instance—with its own CPU, RAM, and storage—which explains why it’s the most expensive option. At the same time, I gained a clearer understanding of why databases are powerful: they allow efficient querying, searching, and listing of content—things that are difficult or inefficient when working directly with raw files.
Using DynamoDB for metadata also helped me understand its limitations. Because I only store metadata there, I can currently search blog entries only by titles and tags, which feels limiting. That said, it’s good enough for now, and I can always improve or migrate the system later if the blog grows.
Finally, working across multiple implementations forced me to get comfortable with managing multiple Git branches, which significantly improved my workflow and confidence when experimenting with different architectural approaches.
The Biggest Lesson
The most important lesson from this experience is this:
Vibe coding is not that bad.
As long as:
- You can write the code yourself (even if it’s slower), and
- You can read and understand everything the model generates,
then you’re in a good place.
Before AI, coding felt like fixing a car with only manual tools—screwdrivers and hammers. Now, it’s like having a machine that can use those tools for you, step by step, as long as you know exactly what needs to be done.
Without Codex, I couldn’t have learned all of this in just two days. I would have needed months to:
- Refresh my fundamentals
- Get comfortable coding again
- Build a complex app
- Deploy it to AWS
- Experiment with multiple architectures
I don’t know exactly where this learning method will take me—but I know one thing for sure:
I learned a lot in the last two days, and I strongly believe this is the future of how most software developers will work.