How I Use AI-Assisted Coding

I don't think software engineering is solved. I do think code is much cheaper to produce than it used to be.

When I can describe a change clearly, give an agent the surrounding context, and check its work, it can produce a useful first version surprisingly often. My rough estimate is nine tasks out of ten. That depends on the domain, the size of the change, and how well I have explained the problem. There are still areas where the model will lack the right training or miss an edge case.

That does not make the engineer optional. Someone still has to choose the approach, supply the context, read the result, and decide whether it belongs in the codebase. When I leave an agent to guess, the output gets worse quickly. That is where the slop comes from.

AI-assisted coding is different from vibe coding.

Andrej Karpathy introduced the term “vibe coding” in a 2025 tweet. I understand it as accepting generated changes without reading them. An error appears, the error is pasted into another prompt, and the loop continues until the program seems to work. The codebase can grow faster than the person's understanding of it.

My version is less automatic. I read the diff. I run tests. I give the agent conventions and local examples, then correct it when it takes the wrong path. The model can write a lot of the code, but I still own the boundaries and the result.

Speed matters because it shortens the distance between an idea and a testable version of it. I can ask for one part of a data pipeline, run it against real data, and spend the saved time checking data quality and production edge cases. That is more useful than spending a day typing the first Airflow DAG from scratch.

The point is not to write more code. It is to reach a useful outcome with less time spent on repetitive work. That makes it cheaper to try a small idea, keep it if it works, and discard it if it does not.

The common tools are Cursor, Claude Code, OpenAI Codex, and GitHub Copilot. I started with Cursor, moved to Claude Code, and now prefer Codex. The choice matters less than learning how to give the tool a clear task and a way to check its work.

Agent tools and app builders are different products. An agent works inside a codebase and responds to the constraints I give it. A platform such as Lovable or Replit tries to create more of the application from a natural-language description, often bundling development, runtime, and deployment together. Both can be useful. They solve different problems.

I would start with work that is easy to inspect: unit tests, repetitive refactors, small migrations, and boilerplate. Leave the parts that define the product or carry the most risk under closer human control.

The model cannot know private conventions, old decisions, or the relationship between modules unless I explain them. I keep that information in files such as AGENTS.md and CLAUDE.md, then point the agent at the relevant files for a task.

Those documents should stay focused. Build commands, testing rules, naming conventions, and project-specific facts are useful. A long archive of every past decision is not. Each extra paragraph competes for the model's attention, so I remove context that no longer changes the work.

I rarely prompt an agent without attaching a file or naming the exact part of the codebase it should inspect. A vague request produces a vague change.

I prefer small iterations. Ask for one function, write or update a focused test, run it, and inspect the diff before asking for the next change. I let the agent draft assertions and fixtures, while I decide what behaviour the test should protect.

Frequent commits make this easier to undo. If an agent takes a wrong turn, the cost of rolling back is small.

I keep a few recurring prompts for work I do often: commit changes, onboard a task, and turn the investigation into a task list. The onboarding prompt asks the agent to inspect the repository, record the relevant files and constraints, and call out uncertainty before editing anything. The task-list prompt turns that context into small steps.

I borrowed the basic onboarding idea from McKay Wrigley, but the useful part is the habit, not the wording. The agent should leave a durable handoff instead of forcing the next session to rediscover the repository.

The work has shifted. I type fewer lines, but I spend more time choosing boundaries, reading diffs, and deciding whether the result belongs in the codebase. That is still engineering.