What Is GenAI?
Generative AI, or GenAI, is technology that can create new content based on instructions and existing information. It can generate text, code, images, ideas, summaries, and other outputs. In programming, GenAI can help generate code, explain errors, suggest solutions, create tests, and explore different approaches to a problem.
But there is an important question developers should ask:
Should GenAI do the work for us, or should it help us do better work?
For me, the answer came from experience.
I remember when programming an application could take weeks or even months. There were difficult problems, long debugging sessions, and sometimes sleepless nights. Building something meant understanding how the pieces worked together. We designed the system, wrote the code, tested it, broke it, fixed it, and kept improving it.
When I first experimented with AI-assisted development, I thought the idea was simple: describe what you want, let AI generate everything from scratch, and continue until the application is ready for deployment.
That sounded powerful.
But it was not the way I wanted to create.
When Fast Development Started Feeling Wrong
At first, letting AI handle more of the work seemed like a good thing. If a system could generate an application quickly, why spend days writing something yourself?
Then I started becoming frustrated with the results.
Sometimes AI-generated solutions moved away from my original design. Sometimes they changed systems or structures that I had created for a reason. A technically working result was not always my result.
That distinction became important to me.
Imagine that I carefully design a system with a particular architecture. I understand why each component exists and how those components communicate. Then I ask an AI to solve one problem. Instead of fixing that specific problem, it rewrites several parts of the application.
The application might still run.
But did it preserve the original system?
Did the new code introduce another problem?
Do I understand everything it changed?
And most importantly: “am I still the developer making the decisions?”
Those questions changed how I approached GenAI.
I Did Not Give Up on AI. I Changed How I Used It.
For a while, I felt like giving up on using AI for my applications. Instead, I researched different approaches and experimented with where AI was actually useful to me.
I realized I did not need to choose between doing everything manually and letting AI do everything.
There was another path: collaboration.
I can build the models.
I can write and edit the code.
I can create my own assets without AI. (AI can give ideas, or improve suggestions.)
I can determine the architecture, mechanics, interactions, and final design.
Then I can use GenAI where it strengthens that process.
For example, suppose I build a complex mechanism and something is behaving incorrectly. Rather than telling AI, “Build this entire system for me,” I can provide the relevant logic and ask:
What conditions could cause this behavior? What edge cases should I test?
Now AI is helping me investigate the problem rather than replacing my implementation.
I can evaluate its suggestions, test them, reject the ones that do not fit, modify useful ones, and make the final decision myself.
That is the difference.
AI as a Debugger, Researcher, and Second Pair of Eyes
The approach that works for me is surprisingly similar to the relationship between a student and a professor.
A student researches the subject and does the homework. A professor can examine the work, identify weaknesses, ask questions, and suggest areas for improvement.
But the professor does not need to become the student.
That is how I prefer to work with GenAI.
I do the work while AI helps me examine the work.
I use it to debug problems, generate ideas, correct grammar, research unfamiliar concepts, test complex systems, identify possibilities I may have overlooked, and challenge my assumptions.
Then I validate the final output.
If something needs modification, I modify it.
If an AI recommendation compromises my design, I reject it.
If it discovers a problem I missed, I investigate it.
The final decision remains mine.
Research Supports the Importance of Human Control
This approach is not simply about personal preference. Research into human-AI collaboration has also examined why AI-assisted development should involve more than accepting the first generated answer.
A 2025 UC Berkeley-led study titled Beyond Code Generation: LLM-supported Exploration of the Program Design Space examined how large language models could support programmers beyond simply producing code. The researchers found problems when design work was conducted entirely through chat, including lost requirements and the tendency for individual generated solutions to anchor users toward one approach. Their work instead explored how LLMs could help people examine a broader program design space.
That distinction matters.
The future of AI-assisted programming does not have to be limited to asking a model for one answer and accepting whatever it produces. AI can also help a developer explore alternatives while the developer remains responsible for choosing the design.
That is much closer to how I want to use it.
Fast Prototyping Does Not Have to Mean Giving Up Your Craft
This is where my understanding of vibe coding changed.
I originally associated vibe coding with letting AI generate almost everything… from an idea to implementation…. without deeply examining the final result.
But after experimenting, failing, researching, and changing my workflow, I found something more useful.
I wanted the speed of AI-assisted prototyping without surrendering the craft behind the product.
There is a big difference between:
“Build this application for me.”
and:
“Here is the application I am building. Help me find what I am missing.”
The first can transfer much of the thinking to the machine.
The second can expand my own thinking.
That is the approach I prefer.
Why I Still Want to Program?
There is another reason I do not want AI doing everything for me.
I do not want convenience to slowly replace ability.
Programming is more than producing working code. It involves understanding systems, reasoning through problems, making architectural decisions, debugging unexpected behavior, and learning why something works.
If I immediately hand every difficult problem to AI, what happens to those skills?
That is a risk I personally do not want to take.
So even when GenAI could produce something faster, I still want to understand what I am building.
Prompt engineering can help me communicate with AI more effectively.
Generative AI can help me explore possibilities faster. Neither needs to replace the experience and skills I have developed.
AI can accelerate my workflow without becoming my workflow.
Create First. Collaborate Second. Validate Always.
My approach today is simple:
I remain the creator. AI becomes the collaborator.
I decide what I want to build. I create the original assets and systems when originality matters. I program and understand the important mechanisms. I use AI for research, debugging, testing, brainstorming, and evaluating possibilities. Then I validate the result myself.
That balance gives me something I actually wanted from AI in the first place: faster prototyping without losing ownership of the creative process.
GenAI does not have to mean giving up the difficult parts of programming. Sometimes those difficult parts are exactly where our skills grow.
So perhaps the better question is not:
“How much of my work can AI do?”
Maybe it is:
“Where can AI help me become better at the work I still want to do myself?”
For developers, designers, artists, and other creators experimenting with GenAI, that question is worth asking.
Would you rather have AI produce something faster for you, or help you build something better yourself?
For me, the answer is clear.
Use GenAI. Learn from it. Challenge it. Test it. But do not lose your craft.
MLA Works Cited
Zamfirescu-Pereira, J. D., et al. “Beyond Code Generation: LLM-supported Exploration of the Program Design Space.” CHI Conference on Human Factors in Computing Systems (CHI ’25), Association for Computing Machinery, 2025, doi:10.1145/3706598.3714154.