I’m Still Learning AI Coding: The Rules and Workflows Helping Me Find My Way

What building EthoPipe is teaching me about AI tools, project rules, and leaving room to experiment

After my post How Adobe Firefly and Copilot Taught Me to Prompt for Code (Part 1), a reader asked whether smaller coding prompts worked better than one detailed prompt. I answered yes, but the question stayed with me. What did “smaller tasks” actually look like in my project—and where did rules and workflows fit?

I am not an expert in AI-assisted development. I am learning by building something I care about. These are the files and habits helping me find my way. You might borrow one part, change another, and ignore the rest.

I used to be strongly against AI. I refused to use it. Now I am writing about how I work with it—not because I suddenly have everything figured out, but because I changed my mind and started experimenting.

My project is EthoPipe, an open-science Python project for canine ethology. At one point, I restarted because I was getting lost among ideas, generated code, instructions, and unfinished tasks. I wanted the tools to help me follow the project, not produce more work I could no longer understand.

My Firefly experiments gave me a useful starting point. A short image prompt could work because the reference photo and settings carried part of the instruction. With coding, I began asking the same practical question: what does the agent need to know before I ask it to change something?

1. Decide what I want before asking the agent to build it

I usually brainstorm in the Gemini app, then move to a coding agent when the direction is clearer. Sometimes I use Copilot for another perspective or when I feel stuck. An IDE agent can discuss ideas too; separating the conversations simply helps me avoid turning every possibility into a feature.

An idea can stay an idea. Before moving to code, I ask: What am I changing? Which files belong to the task? What should stay untouched? How will I know it worked?

What changed between July and October

My July files already contain plans, audits, and walkthroughs. They helped me notice problems such as a filename mismatch and checks that were configured but not working. I was learning to pay attention to the work around the code, not just the code itself.

By October, I had an idea board, more specific project rules, scripts for recording stopping points, and a handoff process. I did not design that system in advance. I kept adding or adapting a file when the same confusion came back.

These files make the next session easier. Some guide the agent, some automate repetitive work, and some remind me where I left off.

2. My rules guide the agent—not my imagination

When I moved my instructions from Gemini Code Assist to Antigravity, some did not work the way I expected. I had to redo parts of the setup. That was frustrating, but it also made me pay more attention to where the files belonged and how the tool used them.

The distinction that helps me is simple: rules describe the project’s boundaries; workflows describe how I approach a recurring task; scripts handle repetitive checks or record-keeping. Each has a different job.

The packaging changes too. Antigravity now documents skills for reusable task procedures and rules for persistent instructions. I still call the overall process my workflow. If you borrow my files, check the current documentation for your tool rather than assuming the old folder structure will work unchanged.

I still review what the agent changes. “Do not touch this” is a useful instruction, not a reason to stop paying attention.

One example: keeping the project small enough for me

I do not want the agent adding a setup I cannot understand or maintain. My solo-maintainer rules limit dependencies, extra languages, and unnecessary infrastructure. Those boundaries fit EthoPipe, and I can revise them when the project needs something different.

A few lines from my solo-maintainer.md file:

- Direct runtime dependencies in pyproject.toml are capped at <= 8 packages.
- Always prefer Python's standard library
  (pathlib, tomllib, dataclasses, argparse, typing, sqlite3)
  over adding third-party packages.
- Keep EthoPipe as a single modular Python service
  (FastAPI + Supabase).
- Individual files must remain under 600 lines.

Your version might need a frontend framework, another database, or more dependencies. The useful part is deciding what fits your project and writing it down, rather than explaining it again in every conversation.

The constraints guide the AI’s actions, not my imagination. I can explore another direction without authorizing new packages, rewritten files, or unrequested features. Not every possibility needs to become code.

3. Give a smaller task a clear purpose

My idea-to-code file follows triage → specification → test first → minimal implementation → QA and journal. That may sound formal, but it helps me pause long enough to decide what I need before files start changing.

Instead of “improve my project,” I ask for one change and name the files involved—including tests. If the agent finds a larger issue, I want it to tell me rather than quietly turn the task into something else.

Here is an example of how I would describe a small task:

Objective:
Check the subject_id length boundary.

Allowed files:
src/pipeline/models.py
tests/test_models.py

Non-goals:
No dependency, CI, or unrelated refactoring changes.

Acceptance:
255 characters accepted; 256 rejected.

Process:
Inspect existing tests. Add a regression test only if missing.
Make the smallest necessary change. Run targeted and full checks.

Stop:
Ask if requirements conflict or the boundary is undocumented.

Closeout:
Changed files, commands and results, blockers, next action.

The prompt is not especially short; it is specific. In this example, the limit and tests already exist in my snapshot, so inspection comes before generating anything new.

That is why my answer is not “always write short prompts.” A longer discussion can establish the direction; smaller tasks carry it forward. The rules provide project context, and the task says what I want now.

4. Leave myself a way to come back

I often open a new conversation for a particular task. It keeps unrelated ideas out of the way, but I do not want to explain the whole project again. My state and handoff files help bridge those sessions.

The state file records what I was doing, where I stopped, and what comes next. A handoff adds relevant project changes and checks when requested. Neither me nor the agent has to remember every detail of the previous conversation.

The kind of note that helps me resume

From my October 12 PROJECT_STATE.md checkpoint:

Where We Stopped:
Completed project-state skill, workflow, CLI engine
(scripts/manage_project_state.py), and state.ps1 helper
with docs/states/ historical archiving.

Quick-Resume Action:
Proceed to localized storage adapter design for Kimball
Star Schema persistence or review project state via
.\scripts\state.ps1.

The note is ordinary—and that is why it helps. I can return to it and know where to start. One checkpoint recorded the state tooling in progress; the next gave me a new task. The files keep that thread intact.

5. Ask for help, read the docs, and keep adjusting

When I do not know how to write a rule or workflow, I ask Gemini to help. I explain what I want, work through a draft, compare it with the documentation, and try it. If I cannot describe the goal, that is a sign I need to explore the idea a little longer.

I work with the agent, review changes, and ask for a walkthrough when we finish. I want to understand what happened and what comes next. The goal is not to pretend I could have written every line unaided; it is to learn enough to keep working on my project.

Google’s learning resources—including GEAR and courses available through my student benefits and learning credits—helped me understand the tools. The documentation also helped explain why instructions from one environment needed adapting in another.

6. Coding experience helps—but the tool still needs learning

I come from outside the usual developer path. I cannot speak for someone with twenty years of coding experience, but I can offer a beginner’s perspective: I am still asking questions about how these tools work.

Coding experience and familiarity with a coding agent are related, but not identical. Recognizing a bad abstraction or debugging a problem is valuable. Learning how a particular agent reads instructions, carries context, asks for approval, and handles a task is another skill. Experience gives you something to build on; it does not remove the need to learn the tool.

I wonder whether the familiar setting makes that easy to overlook. It is still an editor, a terminal, and a repository, but some of the interaction now happens through conversation. Reading a tutorial or asking how a feature works does not diminish anyone’s experience.

I would start with an ordinary task: explain an unfamiliar function, suggest a test, or make a change I can follow. Then I can inspect the result and adjust my instructions. That gives me room to learn without expecting the first prompt to solve everything.

Having once refused to use AI, I am reluctant to insist that anyone must embrace it. But curiosity is enough reason to try. A question or mistake does not have to become a verdict on you—or on the technology.

I do not think you need the most expensive tool to begin

Some articles leave me with the impression that useful AI-assisted coding requires the newest model or most expensive subscription. My experience makes me question that. I think an accessible tool can produce decent work when it fits the project and you take time to learn it.

I started with the access I had. Gemini became familiar, and search fits the way I research. An upgrade might help with a specific limitation, but I do not want a price tag to make someone feel they cannot begin. Learning to describe the task has mattered more to me than chasing the model everyone is discussing that week.

7. Experimentation is a reason to build—not a consolation prize

A personal project can be a place to play

I do not know whether EthoPipe will become something bigger. It already gives me a reason to learn, make mistakes, ask questions, and try ideas. That is not a consolation prize if it never becomes a finished product. It is a reason to build.

A personal project does not have to become a company, a polished product, or proof that you are a “real” developer. You can vibe code, run tests, discard an experiment, and start again. AI can help you be more creative, not just more productive.

I can ask for three approaches without authorizing file changes, choose one, and try it separately. I can ask the agent to explain the result—or discard it if it does not help. Exploring possibilities is different from adding all of them to the main project.

The agent needs a clear job; my ideas need room. I can change the rules, explore another direction, or leave an experiment unfinished. The boundaries help me follow the work, not postpone it.

If you want to try this, start with one file

1. Pick a task you keep repeating or a problem that keeps confusing you.
2. Write a small rule or procedure in your own words.
3. Ask your AI tool to help clarify it, then check how your environment loads it.
4. Try it on one manageable task and look at the result.
5. Keep what helps, change what does not, and leave yourself a next step.

You do not need my full collection. I am sharing it because concrete examples would have helped me understand what people meant by rules and workflows. Take what solves a problem for you, then adapt the stack, limits, and language.

Smaller tasks help me, but I am not trying to make my ideas smaller. I am giving the agent a clearer job while I keep learning and experimenting. The prompt says what to do now. What I imagine next is still up to me.

What have you tried with AI simply to learn or explore? I would love to hear about the experiments—not just the finished products.

AI assistance: I used Gemini and Microsoft Copilot to brainstorm, organize, and edit this article. The experience and project files are mine.