AI coding tools can accelerate development, but they can also make it easy to slip into vibe coding. Through What’s UP Outdoors, I am developing a workflow focused on learning and verification so I have enough understanding to call the project my own.
- Turning PyOhio Inspiration Into Practice
- When AI Assistance Became Vibe Coding
- AI Makes It Too Easy to Move Too Fast
- What Current Research Suggests
- How AI is Used Matters
- Why Human Guidance Still Matters
- Faster Generation Does Not Eliminate Review
- Why I Think Vibe Coding Has a Place
- Learning From People, Not Just AI
- Creating an AI-Use Disclosure
- Updating my workflow
- Me, Myself, and AI
Turning PyOhio Inspiration Into Practice
It has been two weeks since PyOhio, and I am still energized by everything I learned there. I left wanting to build something new, not only for my portfolio, but potentially something I could continue developing and share at PyOhio next year.
That motivation became What’s UP Outdoors, a hiking trail guide for Michigan’s Upper Peninsula that combines state trail data with nature observations. The idea came from a real problem I wanted to solve for myself. I am planning a trip to the Upper Peninsula to see the fall colors, and I wanted a better way to explore hiking trails and get an idea of what plants, animals, and other wildlife I might see along the way.
 |
| What’s UP Outdoors, a Michigan Upper Peninsula trail explorer that combines state hiking trail data with nature observations. |
I wanted the project to be simple enough to explain but challenging enough to push me into unfamiliar areas, including geospatial data, APIs, GeoJSON, Parquet, and Streamlit. In the process, I encountered one of my biggest challenges with AI: it can help me build faster than I can learn.
When AI Assistance Became Vibe Coding
At first, AI felt like a huge advantage.
I could describe what I wanted to do, get code back, run it, fix an error, and keep moving. I worked slowly and tried to understand each step. I read GeoPandas and API documentation, asked questions about unfamiliar functions, and checked the output of the code.
But even while trying to be careful, the amount of unfamiliar information started adding up.
Eventually, I made a Git commit where I knew the code ran and produced the output I expected, but I could not explain much of what the code was actually doing. That was the point where I knew I needed to stop.
For me, that is where AI-assisted coding starts turning into vibe coding. I see it as a spectrum based on understanding and decision-making. If AI writes a function that I can understand, verify, explain, and can modify, I still consider that AI-assisted programming. If I accept code simply because it runs, I have moved toward vibe coding. The uncomfortable part was realizing that this was exactly what had happened.
AI Makes It Too Easy to Move Too Fast
One of the advantages of AI coding tools is also one of their biggest risks: they make it easier to move past the hard parts. I often know what I want a program to accomplish before I know how to express it in Python. AI can fill that gap quickly, but it can also let me skip the struggle that helps the learning stick.
I have noticed that my syntax improves more when I actually type code myself instead of repeatedly accepting generated code. I am also much more likely to remember a concept when I have to debug it, look through documentation, change something, and see what happens.
Learning to program in the age of AI feels especially complicated for me because I am not only learning new technical skills, I am also changing careers in midlife. When I studied mathematics more than a decade ago, tools like these did not exist. Now I have to learn both programming and how to use AI without letting it replace the struggle that helps me learn.
What Current Research Suggests
How AI Is Used Matters
Research on AI and programming education suggests that this distinction may matter.
In How AI Impacts Skill Formation, researchers gave Python users an unfamiliar library to learn. Participants who had access to AI scored significantly lower on a later skills assessment than the group that worked without AI, while the researchers did not find a significant overall improvement in completion time.
 |
| Figure 6 from How AI Impacts Skill Formation by Judy Hanwen Shen and Alex Tamkin. Participants using AI completed the task in similar time to the no-AI group but scored significantly lower on the follow-up quiz, suggesting that AI assistance did not translate into stronger learning in this experiment. |
The more interesting result, however, was not simply that one group used AI and the other did not.
Participants who heavily delegated implementation or repeatedly relied on AI to debug their problems had some of the lowest learning outcomes. Participants who asked conceptual questions, requested explanations alongside generated code, or deliberately worked to understand the code after generating it showed much stronger learning outcomes.
That matches what I have been experiencing. The problem is not necessarily that AI wrote some of my code. The problem begins when AI does the thinking that I needed to practice doing myself.
 |
| Figure 11 from How AI Impacts Skill Formation shows that learning outcomes differed depending on how participants used AI. Approaches that kept participants actively questioning and understanding the code were associated with stronger learning. Percentages represents mean quiz score for that subset. |
Why Human Guidance Still Matters
Another paper that stood out to me was Why Human Guidance Matters in Collaborative Vibe Coding.
The researchers compared different combinations of human-led and AI-led direction and found that humans were more effective at providing high-level guidance. Human instructions tended to be shorter and more action-oriented, while AI instructions were much longer and more descriptive.
Telling the AI to use shorter instructions did not eliminate the performance difference, suggesting that the issue was strategy rather than verbosity.
That changed how I thought about my own use of AI. My contribution to a project is not measured only by how many lines of code I type. AI can help with implementation, but I still need to make the important decisions and steer the project.
 |
| Figure 4B from Why Human Guidance Matters in Collaborative Vibe Coding. Human and AI instructions are mapped by semantic similarity, revealing different patterns in how each group approached the task. |
Faster Generation Does Not Eliminate Review
There is also evidence that this problem exists beyond students learning to code.
Faros AI’s 2026 AI Engineering Report: The Acceleration Whiplash analyzed engineering metrics across 22,000 developers and more than 4,000 teams.
Higher AI adoption was associated with increased output, but several downstream metrics also rose, including code churn and review time. Faros notes that churn can reflect rework, productive refactoring, or both, so the results are better interpreted as evidence that faster generation may also create more work downstream.
 |
| Faros AI found that higher AI adoption coincided with 66% more completed epics per developer, 33.7% higher task throughput, and 16.2% more merged pull requests. At the same time, code churn rose 861% and number of incidents per PR increased 242%. |
The pattern raises an important question: What happens when our ability to generate code grows faster than our ability to understand and review it?
I am experiencing a small version of that problem in my own project. AI saved me time while generating code. Now I have to spend some of that time catching my understanding up to the code that already exists. The code may work today, but if I cannot explain it, modify it, debug it, or verify its assumptions, I still need to work on that code.
Why I Think Vibe Coding Has a Place
I do not think vibe coding is automatically bad.
In How AI Will Change Software Engineering, Martin Fowler discusses legitimate but limited uses for vibe coding, especially for exploration and disposable software. That distinction makes sense to me. If I am experimenting with an idea, building something silly for myself, or testing whether something is technically possible, I may not need to understand every implementation detail.
My standards change when I want to put something on my resume and say: I created this.
For a portfolio project, I do not need to understand the internals of every library I use, but I do need to understand what those tools are doing in my project, why I chose them, and how I know the results are reasonable. I want to be able to walk through the code, explain my decisions, and answer questions about how it works.
I really enjoyed Fowler’s full conversation and recommend listening to it. He covers much more than vibe coding, including learning, testing, refactoring, mentorship, and how software engineering may change as AI becomes more capable.
Learning From People, Not Just AI
One part of Fowler’s discussion that especially stood out to me was the importance of mentorship. As someone still developing programming judgment, I can learn a lot from experienced developers who can question my reasoning, point out assumptions I missed, and help me understand why one approach may be better than another.
As I work on What’s UP Outdoors, a software developer friend is informally filling some of that role. I do not want this project to become their job, but when they have time, they can review my decisions, ask questions I may not think to ask, and make me explain my reasoning. Occasionally, they can also give me a friendly bop on the head when I start drifting off course.
I also want to rely more on learning resources created by people, including books, technical blogs, documentation, videos, and conference talks. AI can help me find and understand those resources, but I do not want it to become my only teacher.
Creating an AI-Use Disclosure
This experience also made me think more carefully about AI disclosure. Simply saying “AI was used on this project” tells a reader very little. AI might have helped brainstorm an idea, debug one function, or generate most of the codebase. Those represent very different development processes.
I started developing an AI-use disclosure framework that scores AI involvement independently across four categories:
- Planning and research
- Content or code generation
- Editing, debugging, and polishing
- Verification and quality assurance
Each category is rated on a 0–5 scale with six levels, ranging from no AI involvement through increasing levels of assistance and collaboration to work that is mostly or entirely AI-led.
 |
| A framework I created to make my use of AI more transparent and intentional, evaluating its involvement across planning, generation, refinement, and verification on a 0–5 scale. |
I developed the framework for my own projects, but I also want it to be simple and clear enough that anyone interested in documenting their AI use could adapt it.
The goal is not to minimize AI use, but to make its role transparent and clarify where AI influenced the project versus where human decision-making remained in control. For me personally, it is to keep AI involvement at a collaborative level or below whenever possible, especially for work I intend to present professionally.
The final category, verification and quality assurance, may be the most important one. AI can help review code, suggest tests, or point out possible problems, but verification also means understanding what the code is doing and why.
I do not want the same AI that generated a solution to be the only thing telling me that the solution is correct. I need to understand the logic well enough to question it, test it, and decide for myself whether the result makes sense.
Updating my workflow
Instead of adding more features to What’s UP Outdoors, I am going to start over. At first, that felt like losing progress, but rebuilding gives me a chance to understand each step and turn the project into something I can truly call my own.
My current workflow is becoming:
I am also incorporating feedback from my software developer friend when possible, along with more deliberate use of documentation and other learning resources.
I already have a project specification, but we will review it before I rebuild. From there, I plan to work one Python file and one function at a time, using Git branches and merges to keep changes small and reviewable.
I want to return to the API documentation, understand how requests are formed and how JSON responses become the data I analyze, make small changes myself, and predict their effects before running them. Most importantly, I want to stop treating “the code ran successfully” as proof that the code is correct.
AI is still going to be part of that process.
I will ask it questions. I will ask for explanations. I will ask it to review code and recommend improvements. I will use it to help find documentation and learning resources when I get stuck. But I want AI to be a tool inside my learning process instead of letting the learning process become a bystander to whatever AI generates.
Me, Myself, and AI
I do not think avoiding AI is a realistic or particularly useful goal for someone learning programming today. AI coding tools are going to continue becoming more capable.
The challenge for me is learning how to use that capability without letting it replace the skills I am trying to develop. The research I have been reading seems to point toward the same general idea from several different directions.
Human direction still matters.
Understanding still matters.
Verification still matters.
Responsibility for the final result still belongs to the person who chooses to submit, publish, or deploy it.
The question I am trying to answer is:
That is the next stage of What’s UP Outdoors. Before I add more features, I need to make sure the learning catches up with the code.
References and Further Reading
- How AI Impacts Skill Formation — Judy Hanwen Shen and Alex Tamkin
- Why Human Guidance Matters in Collaborative Vibe Coding — Haoyu Hu et al.
- Ten Takeaways from the AI Engineering Report 2026: The Acceleration Whiplash — Faros AI
- How AI Will Change Software Engineering — Martin Fowler
Comments
Post a Comment