AI Coding Workflow for Beginners

A practical way to use AI coding assistants without losing the plot.

I spent too much time trying to find the perfect AI coding setup.

The model mattered. The tool mattered. But neither one fixed the real problem: without a workflow, every session slowly turned into a pile of confident suggestions, half-remembered decisions, and changes I still had to untangle myself.

The work improved when I stopped asking for “the app” and started running AI coding like a small development process:

  • load project context first;
  • ask for inspection before edits;
  • make one small change at a time;
  • verify behavior;
  • write down what changed and why.

That is the workflow I would give to someone starting today.

Model snapshot, July 2026

This is the practical model map I would give a beginner right now. Rankings age fast, so treat this as a working snapshot.

  • GPT-5.5 — best cost-benefit for coding in my current workflow. GPT still wins on context understanding, which matters more than raw benchmark flex when you are working across real project files.
  • Opus 4.7 — still top notch for coding, competing head to head with GPT-5.5.
  • Kimi 2.7 — strong for cloning UIs and excellent on cost-benefit. For logic-heavy work I still reach for GPT-5.5 or Opus 4.7 first, but Kimi is fast and useful.
  • GLM 5.2 — roughly in the same band as Kimi 2.7, though slower in my experience.
  • Gemini 3.1 Pro — best choice for research, especially because it can lean on Google results and YouTube video scripts. Also very useful for translation.
  • Grok Pro — best choice when the task depends on trends or what people are currently talking about.

Tip: use OpenRouter to test different LLMs against the same prompt before deciding what belongs in your own workflow.

The setup I am using

My current setup is:

  • OpenCode as the coding harness.
  • oh-my-opencode-slim, also called OMO-SLIM, as the lightweight workflow and agent layer around OpenCode.
  • GPT-5.5 as the model for all OMO-SLIM agents.
  • Rails as my preferred application framework when I want to move fast with AI assistance.
  • AGENTS.md files to give each project local operating instructions.
  • .context/ Memory Bank files to preserve project state between sessions.
  • logs/ experiment journals to capture decisions, failures, validation results, and future article material.

OMO-SLIM is worth explaining because it changes how I divide the work.

Instead of treating one chat as responsible for everything, OMO-SLIM gives me specialist lanes: discovery, implementation, design, review, documentation, and orchestration. The main assistant manages the work. Specialist agents handle bounded jobs.

Example:

  • Ask an explorer agent to inspect a codebase and summarize patterns.
  • Ask a fixer agent to make a specific mechanical change.
  • Ask a designer agent to improve a visible UI.
  • Ask an oracle agent to review architecture or simplify code.

More agents only help when each lane has a clear owner and a bounded job.

Rails is also a conscious choice. Convention over configuration gives the assistant a well-marked path: models, controllers, views, jobs, mailers, migrations, and tests already have expected places to live. That reduces arbitrary choices before implementation starts.

Quick-start checklist

If you are starting with AI coding assistants, set up these seven habits first:

  1. Create an AGENTS.md file. Tell the assistant what the project is, how to work, what to read, and what not to touch.
  2. Create a .context/ folder. Add small Markdown files for project facts, tech stack, current state, and progress.
  3. Ask for inspection before editing. Make the assistant read the relevant files and name the likely edit scope.
  4. Work in one small loop at a time. Inspect → plan → implement → test → review → document.
  5. Keep a log. Every meaningful experiment should leave behind a short note about what happened and why.
  6. Protect secrets. Do not paste API keys, tokens, .env files, Docker inspect output, or auth state into prompts, logs, commits, or README files.
  7. Use tests as the trust boundary. If behavior matters, verify it.

If that sounds too simple, try working without it for a week. The difference shows up fast.

A beginner workflow in practice

Here is the workflow I want beginners to copy.

The example comes from Hyperfocus, a Rails mini-SaaS audio/player app where I was preparing to add Stripe subscriptions without putting billing checks directly on the player hot path.

1. Start with context

Bad prompt:

Add Stripe subscriptions.

Better prompt:

Read AGENTS.md and the .context files first.

Goal: Prepare Hyperfocus for Stripe subscriptions.

Before editing:
- Inspect the current authentication and player access flow.
- Identify where `/player` is gated today.
- Identify what local subscription or entitlement state would be needed.
- Check whether there is already a Stripe readiness note or billing plan.
- Tell me the likely files to change and the validation commands.

Do not edit yet.

That prompt forces the assistant to build a map before touching the code.

2. Make the change small

Once the assistant reports the edit scope, continue with constraints:

Implement the smallest useful version.

Constraints:
- Do not make the successful Checkout redirect the source of truth.
- Use Stripe webhooks to grant, update, and remove local access.
- Gate `/player` through one local entitlement method, such as `current_user.hyperfocus_access?`.
- Keep Stripe-specific checks out of scattered controllers and views.
- Store Stripe secrets in credentials or deploy environment, never hardcoded.

This keeps the assistant away from side quests.

3. Require verification

Then ask for proof:

After implementation:
- Run syntax checks and existing tests.
- Add or update a regression test if behavior changed.
- Summarize the diff.
- List any manual browser validation still needed.

Do not stage or commit unless I explicitly ask.

This is the shape of a useful AI coding session: context, scoped change, verification, and a clean handoff.

Give every project an AGENTS.md

An AGENTS.md is the instruction manual for AI sessions in a repository.

It should answer practical questions:

  • What is this project?
  • What stack does it use?
  • What should the assistant read before coding?
  • How should it branch, commit, test, and document?
  • What must never be exposed?
  • When should it delegate work to specialist agents?
  • What should happen when a task ends?

Here is a starter version:

# Role
You are an AI developer working in this project.

# Boot Sequence
Before meaningful work, read:
- .context/project_brief.md
- .context/tech_context.md
- .context/active_context.md
- .context/progress.md

# Work Rules
- Inspect before editing.
- Prefer small, reviewable changes.
- Run relevant tests before calling work complete.
- Do not stage or commit unless explicitly asked.
- Never print, store, or commit secrets.

# Consolidation
After meaningful work, update active_context.md and progress.md with the result, validation, and next step.

Without a file like this, every session starts from vibes.

With it, the assistant has a job description.

Use a Memory Bank

Chat history makes a poor project memory.

Use a .context/ folder with small Markdown files:

  • project_brief.md — why the project exists.
  • product_context.md — who it is for and what matters.
  • tech_context.md — stack, tools, constraints, setup notes.
  • system_patterns.md — architecture and reusable patterns.
  • active_context.md — current state, recent work, next steps.
  • progress.md — completed milestones, known issues, lessons.

This is what prevents the tenth session from rediscovering what the third session already learned.

The rule is simple:

  • read memory before work;
  • update memory after meaningful work.

Keep a build log

The log is where the workflow becomes useful outside the current task.

I use one Markdown journal per meaningful experiment or day. Each entry captures:

  • goal;
  • assumptions;
  • what was tried;
  • decisions;
  • surprises;
  • artifacts;
  • validation results;
  • reusable snippets;
  • lessons;
  • public content angles;
  • next step.

Here is the minimum useful template:

# Experiment Log: [Name]

Date:
Status:
Related links:
Tags: #lesson #decision #artifact #followup

## Goal
What are we trying to learn, prove, build, or decide?

## What happened
- Step:
- Result:
- Validation:

## Decision
Chose:
Because:
Trade-off:
Revisit if:

## Lesson
- What should future-me remember?

## Next step
- The next concrete action is:

This log exists for accurate memory, long before it becomes polished writing.

It also creates raw material for articles, tutorials, X posts, README improvements, and future AI sessions.

Work in small, testable loops

Large prompts invite large cleanup sessions.

Small loops keep the work understandable.

Use this loop:

  1. Inspect.
  2. Plan the smallest useful change.
  3. Implement.
  4. Test.
  5. Review the diff.
  6. Document the lesson.

Examples from my own workspace:

  • Instead of building a full Speechify clone, validate selected-text reading first.
  • Instead of building an interview-prep platform, build one scored flashcard loop first.
  • Instead of deploying an AI agent system publicly, run it locally with Docker, OAuth, and localhost-only networking first.

The loop may look slower on paper, but it prevents a worse failure mode: generating more uncertainty than progress.

Delegate with clear lanes

With OMO-SLIM, every agent should have a narrow job.

The practical split looks like this:

Need Agent lane
Find files, patterns, prior decisions explorer
Check external docs or current library behavior librarian
Make a bounded implementation change fixer
Improve visible UI/UX designer
Review architecture, simplify code, assess risk oracle
Coordinate the whole task main assistant

Good delegation prompt:

Read-only task. Inspect these files and return the relevant patterns. Do not edit files.

Bad delegation prompt:

Go improve the project.

The first prompt creates a useful lane. The second creates noise.

Inspect before editing

This is one of the simplest habits and one of the most valuable.

Use this line often:

Before changing anything, inspect the relevant files and tell me the likely edit scope.

In my own logs, diagnosis changed the shape of the fix:

  • a close button bug came down to a missing CSS rule;
  • a “nothing happens” report came from stale Chrome extension content scripts;
  • a playback failure came from provider 429 quota errors;
  • a failed MP3 export came from filename header encoding;
  • a public publishing pass caught personal score history in a private deck.

Inspection protects you from confident wrong fixes.

Tests keep AI honest

AI-generated code can look right and still be wrong.

Tests are the part of the workflow that pushes past appearances.

Patterns that worked well:

  • add regression tests when a behavior bug appears;
  • test parsing and chunking logic separately;
  • smoke-test provider and proxy paths;
  • run syntax checks before manual browser validation;
  • run the full suite when touching important app behavior;
  • verify public/private state before publishing a repo.

One rule from the TTS experiment became a keeper:

Behavior bugs should get tests.

If the assistant cannot prove the behavior, treat the work as unfinished.

Prefer boring architecture

AI does better when the project has fewer custom inventions.

That is one reason I like Rails for AI-assisted development. Rails' convention-over-configuration philosophy narrows the decision space. The assistant is more likely to put code in the expected place, use the expected naming, and follow a path that another Rails developer can review later.

By boring, I mean foundations like these:

  • Rails MVC before custom architecture experiments.
  • Hotwire before unnecessary frontend complexity.
  • PostgreSQL tables before Kafka-level infrastructure.
  • Simple scoring counters before complex recommendation engines.
  • Local Docker services before public deployments.
  • Semantic HTML and structured metadata before heavy client-side tricks.

Conventions reduce the number of decisions the assistant has to invent.

They also reduce the number of decisions you have to debug.

Treat security as part of the workflow

AI coding assistants make it easy to leak secrets by accident.

My default rules:

  • never save API keys, tokens, or disposable secrets to files;
  • never paste secrets into logs, journals, READMEs, screenshots, or memory;
  • use environment variables or user-local secret stores;
  • keep auth state outside project repos;
  • bind local agent gateways to 127.0.0.1, not 0.0.0.0;
  • fail closed in production;
  • stage only intended files;
  • inspect diffs before committing.

Docker solves packaging. Secret hygiene and network exposure still need their own rules.

Put the safety rules directly into the workflow so they do not depend on memory at the worst possible moment.

Turn bugs into invariants

A disappearing error is only the first part of a bug fix.

Ask:

  • What made this bug possible?
  • What rule would prevent it next time?
  • What test would catch it?
  • What note should future sessions read?

Examples:

  • If selected text is not fully read, test text preservation and chunk boundaries.
  • If a Chrome extension can keep stale scripts alive, design for reload/retry resilience.
  • If a provider returns 429, classify it as quota/rate-limit before blaming the UI.
  • If public content is created from private prep notes, reset personal scores before publishing.
  • If an agent gateway is local, keep it localhost-only unless deployment is intentional.

Bugs should leave behind tests, documentation, or better defaults.

Otherwise they are just interruptions.

Separate private working state from public artifacts

The interview-prep work showed a pattern I will reuse:

  • keep a private scored practice deck;
  • publish a reset public deck;
  • keep the reusable framework separate from the specific Rails deck.

That generalizes to AI coding:

  • private notes can contain messy context;
  • public artifacts should be cleaned, reset, and safe;
  • reusable patterns should be extracted from specific experiments.

Do not publish the working copy if it contains private history.

Make a clean version.

The point

Beginners can wait on the giant prompt library.

They need a working rhythm:

  • context before action;
  • small changes before broad rewrites;
  • specialist lanes before vague delegation;
  • tests before trust;
  • logs before forgetting;
  • security before convenience;
  • boring defaults before clever architecture.

That is the part worth copying.

The model will keep changing. The tools will keep changing.

A good workflow keeps paying rent.