Skip to content
ContactDA
Published
Updated

How to Get Started Programming with AI

By

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 specific instructions and a clear workflow.

For smaller businesses, this matters because the website is often tied directly to enquiries, bookings, payments, forms, analytics, and search visibility. AI can help you learn faster, but a wrong change to a WordPress plugin, Laravel database, booking flow, or Astro template can still affect real business.

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 AI to learn best practice

One of the best uses of AI is asking it to explain the practice behind the code.

Instead of only asking for an implementation, ask questions such as:

  • What is the maintainable way to solve this in this framework?
  • Which part of this code is business logic, validation, presentation, or persistence?
  • What trade-offs are there between the simple fix and the cleaner refactor?
  • What would you test before shipping this?
  • Which assumptions are you making from the files you have seen?

That is where AI becomes useful as a teacher. It can show why a Laravel controller should not collect too much unrelated logic, why a WordPress hook needs a narrow responsibility, or why an Astro component should keep content and layout concerns understandable.

The learning does not happen when you paste code and accept it. It happens when you compare the suggestion with the existing project, ask why it chose that direction, and reject changes that are too broad for the task.

Review code, comments, and commands

AI output can look tidy while still being wrong. Review the actual code, not only the explanation around it.

Pay attention to:

  • Code that changes behavior outside the requested task
  • Comments that describe what the code should do, not what it actually does
  • Removed edge cases that looked old but were intentional
  • New abstractions that hide a simple business rule
  • Commands that change files, dependencies, caches, storage, or database state

Comments deserve the same skepticism as code. A generated comment can be confident and still describe the wrong behavior. If the comment and the implementation disagree, trust neither until you have checked the real flow.

Commands need an even higher bar because they can change state immediately. A good example is Laravel’s php artisan migrate:fresh. It is a valid development command, but the Laravel documentation explains that it drops all database tables before running migrations again. That can be useful in a local disposable database. Against the wrong connection, a shared staging database, or production, it is destructive.

Before accepting a command from AI, ask:

  • Which environment does this run against?
  • Which database connection, storage bucket, or API account does it touch?
  • Is there a current backup and rollback path?
  • Can the command be run in dry-run, pretend, or read-only mode first?
  • Is this safe on a staging environment before it touches live data?

The command is not bad because AI suggested it. It is bad when nobody checks the environment, effect, and recovery path.

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 sensible 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 safer 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 main 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. The next step is a controlled workflow for using Claude Code and Codex in an existing codebase.

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.

Give the agent persistent project instructions

If you repeat the same reminders in every prompt, they belong in the repository. Persistent instructions can define the package manager, validation commands, architecture boundaries, content rules, and behavior that must not change without approval.

Codex normally reads AGENTS.md, while Claude Code reads CLAUDE.md. When both tools work in the same project, keep shared facts in one maintained source instead of copying them into several files. Tool-specific guidance should cover only genuine differences such as available capabilities, permissions, or the way a result is verified.

Good instructions are concrete: “run pnpm check-types after TypeScript changes” is useful; “write high-quality code” is not. They should also stay short enough to review and should not pretend to be a security boundary.

The complete guide to sharing project rules between AGENTS.md and CLAUDE.md covers file discovery, imports, nested rules, image-generation ownership, sandbox differences, enforcement, and how to confirm which instructions each tool actually loaded.

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”, “do not run migrate:fresh without explicit 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