Skip to content
Contact DA
Published

How to Get Started Programming with AI

Getting started with AI-assisted programming is not mainly about finding the perfect model. It is about learning how to give the tool enough context, limit the task, review the result, and avoid letting the AI turn a small change into a rewrite.

The biggest mistake is treating AI like a senior developer who already understands your codebase. It does not. It can read files, infer patterns, and make useful changes, but it needs practical instructions and a clear workflow.

A developer using AI tools for planning, implementation, review, and project instructions

Start with the right kind of task

The best first tasks are useful but contained. Do not begin by asking AI to rebuild the application, redesign the frontend, or migrate the whole backend.

Start with work where you can verify the result:

  • Explain an unfamiliar file
  • Write a small utility function
  • Add validation to an existing form
  • Convert one component at a time
  • Improve an error message
  • Add tests for existing behavior
  • Review a pull request for regressions

This matters because AI can produce convincing code that is still wrong. A contained task gives you a small set of changes, a clearer review, and a better sense of how the tool behaves.

Use AI as a pair programmer, not an autopilot

AI is useful for planning, implementation, debugging, refactoring, testing, and review. It is not a replacement for understanding what should ship.

A good workflow is:

  1. Ask the AI to inspect the relevant files and explain the current structure.
  2. Ask for a short implementation plan before changing code.
  3. Approve or correct the plan.
  4. Let the AI make the smallest useful change.
  5. Review the changes yourself.
  6. Run tests, type checks, linting, or a build.
  7. Ask a second AI pass to review the change for hidden risks.

That workflow is slower than blindly accepting suggestions, but it is faster than debugging a confident mistake after it reaches production.

Use GitHub before you let AI edit code

Before AI changes real code, the project should be in version control. Git is the important part. GitHub is the common practical choice because it gives you branches, pull requests, clear views of file changes, history, issues, code review, and a safe place to compare what changed.

Do not use AI for serious code changes in a folder where you cannot easily review and revert the result.

A basic GitHub workflow is enough:

  1. Commit or stash your current work before starting.
  2. Create a branch for the AI-assisted change.
  3. Ask AI to make a small scoped change.
  4. Review the changes locally.
  5. Run the relevant validation commands.
  6. Push the branch and review it as a pull request.
  7. Merge only when you understand the change.

This is especially important when the AI has direct file access through an IDE or terminal agent. A browser chat can suggest bad code. A coding agent can apply bad code across several files before you notice.

GitHub also gives you a useful audit trail. If a change breaks something later, you can see which commit introduced it, what the prompt or issue was trying to solve, and whether the tests or review missed something.

For a one-person project, pull requests can still be useful. They slow the change down just enough to force a proper change review. That is a good thing when AI is involved.

Choose tools based on your workflow

There is no single best IDE or AI coding tool. The right choice depends on how you already work and how much control you want.

VS Code with GitHub Copilot or Codex

VS Code is a practical starting point because many AI tools support it well. GitHub Copilot has chat, completions, agent mode, custom instructions, and support for AGENTS.md in VS Code. OpenAI Codex is also available through local clients such as the CLI and IDE extension, including VS Code and VS Code-based editors.

Choose this route if you want a mainstream editor, a large extension ecosystem, and AI help close to your existing development workflow.

Cursor or Windsurf

Cursor and Windsurf are AI-first editors based around chat, agent workflows, codebase context, and rules. They are useful if you want the editor itself to be designed around AI-assisted development rather than adding AI to a traditional setup.

The trade-off is that you need to understand each tool’s rules system. Cursor has project rules and can work with AGENTS.md. Windsurf has Cascade, rules, workflows, memories, and also documents using AGENTS.md for shared project guidance.

JetBrains IDEs

If you work heavily in PHP, Laravel, Java, Kotlin, or larger backend projects, JetBrains IDEs can still be the most productive environment. JetBrains AI Assistant supports chat, agent mode, context management, and external agents through the Agent Client Protocol.

The practical point is simple: if your existing IDE already understands your framework, refactoring, types, navigation, and tests well, do not switch editors only because another AI tool is popular.

Terminal agents: Claude Code and Codex CLI

Terminal agents are often better for real repository work than a browser chat. They can inspect files, edit code, run commands, and work with the same project structure you use locally.

Claude Code uses CLAUDE.md for persistent project instructions. Codex uses AGENTS.md. Both benefit from clear build commands, testing instructions, architecture notes, and boundaries around what not to change.

Browser chat: ChatGPT and Claude

Browser chat is still useful, especially for planning, explaining errors, comparing approaches, and reviewing snippets. It is less ideal for larger code changes because you must manually provide context and move code back and forth.

Use browser chat when the task is conceptual. Use an IDE or terminal agent when the task needs repository context and file edits.

Project instructions are where AI starts to become useful

If you repeat the same reminders in every prompt, they belong in a project instruction file.

Examples:

  • Use pnpm, not npm
  • Run pnpm check-types after TypeScript changes
  • Do not change public APIs without asking
  • Keep existing styling unless the task explicitly asks for design work
  • Use existing components before creating new ones
  • Keep content tone practical and direct
  • Do not add dependencies without approval
  • Preserve accessibility, semantic HTML, and technical SEO

These instructions reduce repeated prompting and make AI output more consistent. They do not guarantee perfect behavior, but they move the default in the right direction.

Use AGENTS.md as the shared base

AGENTS.md is a plain Markdown file for AI coding agents. Think of it as a README.md for tools instead of humans.

A useful starter file might look like this:

# AGENTS.md

## Project

- This is a Laravel and Astro project.
- Keep backend logic in Laravel services unless the existing structure says otherwise.
- Keep frontend components small and reuse existing components before creating new ones.

## Commands

- Install dependencies with `pnpm install`.
- Run type checks with `pnpm check-types`.
- Run the production build with `pnpm build`.

## Coding Rules

- Make the smallest change that solves the task.
- Preserve existing behavior unless the user explicitly asks for a change.
- Do not add dependencies without asking.
- Do not redesign UI unless the task is specifically about design.
- Add or update tests when behavior changes.

## Review Checklist

- Check for behavior changes that were not requested.
- Check accessibility and semantic HTML for frontend changes.
- Check security and validation for backend changes.
- Mention any validation command that could not be run.

Keep this file short enough that the AI can use it. Long instruction files often become background noise. The best instructions are specific, current, and easy to verify.

Larger projects need smaller instruction files

For larger projects, one huge instruction file becomes hard to maintain. A better pattern is to keep the root AGENTS.md focused on global rules and add smaller files closer to the code they describe.

For example:

my-project/
|-- AGENTS.md
|-- apps/
|   |-- web/
|   |   `-- AGENTS.md
|   `-- admin/
|       `-- AGENTS.md
|-- packages/
|   `-- ui/
|       `-- AGENTS.md
`-- docs/
    `-- ai/
        |-- testing.md
        |-- content-style.md
        `-- deployment.md

The root file should explain the whole project. A subfolder file should explain the local conventions for that part of the codebase.

For example, apps/web/AGENTS.md can describe routing, components, styling, and build commands for the public website. packages/ui/AGENTS.md can describe component API rules, accessibility requirements, and visual consistency.

This keeps instructions maintainable and prevents the AI from loading irrelevant guidance for every task. It also makes the documentation easier for humans to review.

Do not split instructions too early. If a project is small, one AGENTS.md is enough. Split only when the file becomes difficult to scan or when different parts of the codebase genuinely need different rules.

How CLAUDE.md can reuse AGENTS.md

Claude Code reads CLAUDE.md, not AGENTS.md. But CLAUDE.md supports imports with the @path/to/file syntax, so you can avoid duplicating the same project instructions.

A practical setup is:

@AGENTS.md

## Claude Code

- Use Plan Mode before larger refactors.
- Ask before changing architecture, routing, or public APIs.
- Prefer small changes and explain any command that could not be run.

That gives you one shared base in AGENTS.md and a small Claude-specific section in CLAUDE.md.

For larger Claude Code projects, you can also use .claude/rules/ for modular rules, including path-scoped rules. That is useful when some instructions only apply to src/api/**/*.ts, content/**/*.mdx, or a specific package in a monorepo.

The important rule is to avoid duplicated truth. If you maintain the same instruction in AGENTS.md, CLAUDE.md, Cursor rules, and Copilot instructions, they will eventually drift apart.

What to put in instructions

Good AI instructions are operational. They tell the tool how to work in this project.

Include:

  • Project structure and where important code lives
  • Package manager and common commands
  • Test, lint, type-check, and build commands
  • Coding conventions that are not obvious from the code
  • Security, accessibility, SEO, or performance requirements
  • Rules about dependencies, migrations, deployment, and generated files
  • Areas that should not be touched without approval

Avoid:

  • Long essays about the project history
  • Vague rules like “write clean code”
  • Contradictory instructions
  • Old commands that no longer work
  • Tool-specific details in the shared file unless they apply broadly

A useful test is this: if a new developer joined the project tomorrow, would the file help them make safer changes? If yes, it will usually help the AI too.

Better prompts for programming with AI

Instructions set the baseline. Prompts still matter.

A weak prompt is:

Fix this component.

A stronger prompt is:

Inspect the existing component and explain why the mobile menu does not close after navigation. Then propose the smallest fix. Do not change styling, component structure, or route behavior unless required. After the change, tell me which files changed and what validation you ran.

For implementation work, define:

  • The goal
  • The files or area involved
  • What must not change
  • The expected validation
  • Whether the AI should plan first or edit directly

For review work, ask for risks instead of praise:

Review these changes for unintended behavior changes, missing tests, accessibility regressions, security issues, and unnecessary abstraction. Do not rewrite the code yet. List concrete findings with file references.

A safe first-week workflow

If you are new to programming with AI, use a conservative workflow for the first week.

Day 1: Use AI only to explain code and errors.

Day 2: Ask AI to write tests for existing behavior.

Day 3: Put the project in GitHub if it is not already there. Create a branch, let AI make one small change, then review the changes manually.

Day 4: Add a basic AGENTS.md with commands, conventions, and boundaries.

Day 5: Use AI for a real bug fix, but require a plan before edits.

Day 6: Ask another AI tool to review the changes.

Day 7: Update the instruction file with anything you had to repeat during the week.

This builds the habit that matters most: AI can help with the work, but you are still responsible for the result.

Privacy and project boundaries

Before using AI on client or production code, check what the tool sends to its provider, how it stores data, and what your subscription or company policy allows.

Be careful with:

  • Secrets and API keys
  • Customer data
  • Database dumps
  • Private business logic
  • Proprietary code under strict contracts
  • Production logs containing personal data

Good instructions can help here too. Add rules such as “do not paste secrets into chat”, “do not create migrations without approval”, or “do not run commands that modify production data”.

Keep the developer in the loop

The useful way to start programming with AI is not to hand over the keyboard. It is to build a workflow where AI has enough context to help, but not enough freedom to silently change the wrong thing.

Start small. Use your existing IDE if it already works for you. Add AGENTS.md when you get tired of repeating the same rules. Add CLAUDE.md with @AGENTS.md if you use Claude Code. Split instructions by folder only when the project is large enough to need it.

The goal is not to make AI write more code. The goal is to make better changes with less wasted time and fewer avoidable mistakes.

Official documentation worth reading

More articles