Building Again, One AI Assisted Project at a Time
Key Takeaways
- My use of AI has shifted from task support to active building. Tools like ChatGPT, Gemini, NotebookLM, and Codex have helped me move from asking questions to shaping projects, workflows, apps, websites, and games.
- Vibe coding changes the rhythm of the work. AI can speed up development, but it still needs clear direction, specific intent, careful review, and steady human judgment.
- Starting small makes the process easier to learn. A simple, useful first project can build confidence and create a foundation for more ambitious work.
- Human judgment still counts. AI can help generate code, but product vision, taste, user experience, architecture, testing, and direction still require a person who knows what they are trying to build.
Like many people, my journey with generative AI began with ChatGPT.
At first, I approached it with curiosity. I asked questions. I tested ideas. I used it to summarize, rewrite, organize, translate, brainstorm, and research. It felt useful almost immediately, but in those early days, I was mostly using AI as an assistant. It helped me think, write, and move faster, but I was not yet thinking of AI as a building partner.
The Shift From AI Assistant to AI Partner
Then I started experimenting with other generative AI tools. I used Midjourney to create images, Sora – now sunset – to explore AI video, and Suno to create music. Each one opened a different door. Suno surprised me with how quickly it could turn a prompt into something that felt complete. Midjourney was fun and visually impressive, even though I did not find myself returning to it every day. Sora felt fascinating, but for now, more like a glimpse of what may be possible than something that fits naturally into my regular workflow.
One of the songs I created with Suno is called Rise and Shine. I am not pretending it is a masterpiece, but it serves its purpose. I liked the idea of using something I made as my morning alarm, and that small daily use made the experiment feel more real than a simple demo.
Over time, a few tools became part of how I work.
ChatGPT became the tool I used most extensively. I used it on my phone, on my computer, and even in the car. It became part of how I worked through projects, writing, planning, live translation, general research, and the kind of back and forth thinking that happens when an idea is still taking shape.
Gemini became useful for AEO and SEO work, especially when thinking about how websites and articles should be structured for both people and search. NotebookLM became surprisingly useful in a different way. It helped me most when I already had material and wanted to understand it, organize it, learn from it, or turn it into something else.
I now use all of these tools on a regular basis.
Taking the Leap Into Vibe Coding
Eventually, I decided to give Codex a try.
I was apprehensive.
I had not written code seriously in some time. I began my career as a software engineer at AT&T Bell Labs, and that journey eventually led me to running software engineering teams. As my responsibilities changed, I moved further and further away from writing code myself. I was still close to software, but in a different way. Strategy, architecture, process, teams, delivery, quality, operations, leadership. That became my daily world.
On the side, I had built a few static websites over the years, but nothing especially ambitious. I could still think like a software engineer, but I did not know how easily I could return to actually building software.
Then came vibe coding.
They say you need to walk before you can run, so I started small. I did not know what to expect, and that was part of the appeal. My first project was a single page currency exchange application called FX2USD. It was practical, contained, and genuinely useful. I wanted to build something I could use while traveling, not just a demo.
I added it to the Home Screen on my iPhone, and I still use it on trips because it includes a few features I could not easily find in other currency exchange apps.
Because I used it in real situations, the project quickly became more than an exercise. It gave me confidence because it solved a small problem I actually had.
From there, I started improving it. I added bank note references, exchange log history, and a cleaner interface. I also put the code on GitHub. The project was small, but it reminded me that software is not only about writing code. It is about shaping behavior, testing assumptions, refining details, and making something useful enough to return to.
That first project gave me a better way to approach the next one.
Revamping Websites and Elevating Workflows
More than 15 years ago, I wrote a website for Optima Optometry. It served the practice well and ranked well in Google search results, but it was ready for a refresh. I used Codex to help rebuild it, expecting the process to be interesting. What I did not expect was how strong the result would be.
The project still needed a lot of direction. There was plenty of back and forth. I reviewed, corrected, redirected, and made decisions throughout the process. I thought through the structure, user experience, copy, layout, visual rhythm, and business purpose of the site.
That project changed how I saw Codex. It was not simply writing code for me. It was helping me work at a higher level. I could describe intent, evaluate output, catch mistakes, guide implementation, and keep the project moving. My engineering background helped. So did my product judgment and my ability to break a larger problem into smaller pieces.
That was the real shift. I was no longer just asking AI to complete tasks. I was using AI to help turn ideas into working systems.
From there, I began revamping several of my own websites, including my personal site, Spark Academy, and Happy Planet Children. Each site had a different purpose, audience, and voice. That made the work more interesting, because the goal was not just to make pages look better. The goal was to make each site clearer, more useful, and more aligned with the people it was meant to serve.
Work that might once have taken days, weeks, or been pushed aside indefinitely could now be done in a few focused sessions. Not perfectly. Not magically. But effectively.
That distinction is worth calling out.
Vibe coding does not remove the work. It changes the rhythm of the work. It lets you move faster, but it also forces you to be clearer. The better the direction, the better the result. The more specific the intent, the more useful the output. The more carefully you review, the more the project improves.
I have started keeping a more structured record of these projects on my vibe coding journey page on tocatlian.com, partly because the work is growing faster than I expected. What began as a small currency tool has turned into a wider set of experiments across websites, learning platforms, full stack applications, integrations, and even games.
Full Stack Applications and the Agile Mindset
One of the more ambitious projects I am still working on is a full stack web application to help manage my Instagram account.
It is not complete yet, and that is part of what makes it such a useful learning project. The goal is practical. I want to import comments, identify unanswered comments, suggest replies, flag items that need personal attention, queue possible spam for approval, and save meaningful comments as reusable quotes.
On the surface, that may sound like a simple productivity tool. In practice, it quickly becomes a real application with workflows, data models, approval states, user decisions, and interface design.
Because the project is still evolving, it has also become a place to keep learning. Each new feature raises new questions about software design, usability, testing, deployment, and how much automation should be trusted before a person reviews it.
This project made me feel less like a solo coder and more like someone guiding a full Agile team.
I found myself moving between roles. Product Owner. UI/UX Designer. Developer. SDET. DevOps. Technical writer. Sometimes I was defining requirements. Sometimes I was reviewing UI decisions. Sometimes I was thinking about test coverage, deployment, documentation, or data models.
That has been one of the most interesting parts of returning to software through AI. I am not only reconnecting with coding. I am reconnecting with the entire software development process.
In a traditional Agile team, different people often bring different skills. One person may focus on the product vision. Another may shape the user experience. Another may write the code. Someone else may test it, deploy it, document it, or monitor it.
With vibe coding, I can move across those roles myself.
That does not mean AI replaces a great team. It means one person with enough judgment can cover much more ground than before. AI can help generate the code, but someone still has to decide what should be built, why it deserves attention, how it should behave, what good looks like, and when something is not right.
That kind of judgment becomes even more valuable, not less.
Leveraging AI for Education and Learning Systems
Then I decided to see whether I could turn my experience with AI tools into a course.
Friends kept asking me how I was using AI, so I started building a 30 day challenge, with 30 minutes a day covering ChatGPT, Gemini, NotebookLM, and Codex. I wrote most of the lessons myself, then used Codex to help expand the material, fill in missing pieces, organize the experience, and build a micro-learning site around the course.
That worked beautifully! Take a look at the 30-Day AI at Work Challenge.
It also showed me that vibe coding was not only useful for software utilities or business websites. It could support education design, structured learning, course delivery, and content organization. I also experimented with using OpenAI APIs to create audio podcasts for the lessons, which opened another door.
The project became more than a course. It became a learning microsite.
Pushing Boundaries With AI Game Development
And then, because apparently I cannot resist making things more complicated, I decided to build a game.
Monaco Racing was the result.
This was new territory for me. I am not a big game player now, and I had never built a game before. That was part of the appeal. I wanted to see what would happen if I pushed vibe coding into something more interactive and dynamic.
A game is different from a website or an app. It has movement. Timing. Controls. Difficulty. Feedback. Sound. Scoring. Friction. Feel.
That last word counts.
A website can be useful. A form can work. A dashboard can display data. But a game has to feel alive. If the car does not respond correctly, you notice. If the speed feels wrong, you notice. If the turn is awkward, you notice. If the difficulty is too easy or too punishing, you notice.
Monaco Racing pushed me to think about software in a more physical and immediate way. It also made the limits of vibe coding easier to see. Codex could generate a lot quickly, but I still had to guide the gameplay, test the experience, revise the visuals, adjust the behavior, and keep asking whether the game felt right.
That became another reminder. AI can help you move faster, but speed without judgment is not enough.
The Core Lesson: Judgment and Taste Over Speed
Looking back, the lesson that keeps returning is simple.
Learn to walk before you run.
Start with something small. Build it. Use it. Improve it. Then take on something more involved. Think in iterations. Think Agile. Let the first version be small enough to finish, but real enough to teach you something.
That is what FX2USD did for me. It gave me a small, useful win. Optima Optometry showed me that AI assisted development could help modernize a real business website. My personal and nonprofit site upgrades showed me how quickly I could improve structure, clarity, and usability across different audiences. The 30 Day AI at Work Challenge showed me that vibe coding could support education and learning design. The Instagram management app pushed me into full stack workflows. Monaco Racing reminded me that interactive software has to be felt, not just built.
That progression is important to the story.
Vibe coding did not replace my software engineering experience. It reactivated it. It gave me a way to return to building software while drawing on everything I had learned from engineering, product development, leadership, testing, documentation, and delivery.
It also reminded me how much I enjoy making things.
Not talking about making things. Not planning them forever. Not leaving them in the someday pile. Actually making them, testing them, improving them, and seeing what they become.
That may be the most interesting part of this whole journey. The code has value, of course. But the judgment around the code has even greater value.
Taste counts. Direction counts. Testing counts. Questions count.
AI can help build the thing. It can make the path from idea to working version feel shorter, more flexible, and more immediate. That is why this may be one of the most exciting times to be a software developer. But the real advantage still belongs to the person who knows what they are trying to make, who it is for, and why it should exist.
Frequently Asked Questions
What is vibe coding?
Vibe coding is a way of building software with generative AI as a collaborative partner. Instead of manually writing every line of code yourself, you describe what you want to build, guide the implementation, review the output, test the behavior, and keep refining the result.
For me, vibe coding is not about skipping the work. It is about changing the way the work happens.
Does using AI for coding replace software engineers?
In my experience, no. In fact, I think there’s never been a better time to be a software developer.
AI can help generate code quickly, but it does not replace the need for human judgment. Someone still has to define the product, shape the user experience, evaluate the output, catch mistakes, test the behavior, and decide whether the result is actually good.
AI can strengthen what a builder is able to do, but the engineering mindset still has real value.
How should a beginner start building software with AI?
Start small. For me it was a simple single-page web application.
Choose a simple project that solves a real problem you have. Build it. Use it. Improve it. A small, practical tool is usually a better starting point than a large application with too many moving parts.
Once you have a working version, iterate. Add one useful feature at a time. Let the project teach you what to build next.
Can AI be used for projects beyond software applications?
Yes. My own projects have included business websites, personal websites, nonprofit sites, learning platforms, course material, audio lessons, full stack applications, and an interactive game.
The common thread is not the type of project. It is the process. Start with clear intent, review the output carefully, improve it through iteration, and keep asking whether the result serves the people who will actually use it.
Tocatlian Blog 