AI Coding for Non-Coders 2026: Three Tools, One Real Lesson

Three AI coding tools tried, one still running. The real lesson was not which tool won - it was learning to maintain project memory. A non-coder's honest journey.

We evaluate every tool based on published features, real-world usage, community feedback, and independent testing where possible. Affiliate commissions never influence our rankings. How we research ยท Editorial policy

Quick verdict

For over a decade I had multiple business ideas I could never act on. Not skilled enough to write the code myself. Not flush enough to hire someone to build a throwaway prototype that might or might not become anything. The ideas just sat there in notebooks.

AI agent coding changed that. Products that would have been impossible last year are shipping. A feature an external developer estimated at 16 hours of work gets built in 45 minutes. The "this will not happen" backlog is moving.

This article is about three AI coding tools I tried to get there - ChatGPT, Google Antigravity, Claude Code - and the bigger lesson that turned out not to be about the tools at all.

Claude Code is what I run today. But the real productivity unlock came from learning to maintain project memory so each session inherits context instead of starting from zero. Tool churn is the distraction. Persistent memory is the lever. The tool matters less than you think.

Three tools, three failure modes

ChatGPT first. The chat interface, not a dedicated coding agent. I used it for code suggestions, business planning, and feedback on architecture decisions. For a non-coder asking "is this approach reasonable?" it was genuinely useful, even when the code itself needed reworking.

The failure mode came on long sessions. Anyone who has pushed ChatGPT past a certain conversation length has seen it: the UI freezes. The reply has been generated - the model produced it fine - but it never appears in the interface. Restart the app or the browser and the message is suddenly there. For a casual chat that is mildly annoying. For a deep technical session where you are building context across hours, it is a productivity hole that compounds.

Google Antigravity came next. AG was the first agentic coding tool I really committed to. Multi-agent management was nice. The initial impressions were strong - Opus on the highest tier, working continuously, building real things.

Then the limits started. Quietly. No notice, no announcement. Cap on Opus usage, then progressively shorter caps with progressively longer cooldowns. The advertised tier and the actual tier diverged. Even on the highest plan, Opus could no longer be used for a full day of work. The Gemini fallback was poor - busy work, caught in loops, breaking things to fix things. The community joke that "AG feels like a vibe coded project" started circulating, and from where I was sitting it was hard to disagree.

I moved straight to the source of Opus. If Anthropic's models were the thing actually getting work done, going through a wrapper that throttled access felt unnecessary. Claude Code is what I run every day now.

The real lesson was not the tool

Here is what surprised me: the tool churn was a distraction.

I switched tools because each had a real failure mode. Those failures were real. But the productivity unlock between "couldn't ship" and "shipping regularly" was not the tool change. It was learning to maintain project memory so each session inherits context instead of starting from zero.

The killer moment, concretely: a feature that an external developer estimated at 16 hours of work, finished in 45 minutes. Not because the AI is magic. Because by then the project had a memory file the agent could read at session start - the architecture, the gotchas from previous decisions, what was already built, what was deliberately deferred. The agent did not have to rediscover the project. It just had to ship the next thing.

Without that memory, the same job would have been 2-3 hours of pre-work to re-establish context, plus repeated wrong turns because the agent did not know which approaches we had already tried. With it, the agent walked in, read the brief, and built. The 21x speedup is the memory practice paying out.

This is the actual article. Not "Claude Code beat AG." The tool will keep changing. The memory pattern is the durable thing.

What an AGMemory file actually is

An AGMemory.md file lives at the root of each project. It is a markdown file the AI agent reads at the start of every session. The structure that has worked across multiple projects:

Project identity. One paragraph. What this project is. Who it serves. What it deliberately is not.

Brand voice and decisions. Anti-guru, peer-to-peer, whatever the project's positioning is. Lock the language so the agent does not drift into generic copy.

Current architecture. What is built. What stack it uses. Critical files. Database schema gotchas. The kind of context an external developer would need on day one.

Completed phases, dated. "Phase 6.4 - MusicBrainz Releases. Shipped 2026-03-15." This stops the agent from re-suggesting work that is already done.

Status markers throughout. Warnings on things to be careful with. Pause markers for deliberately-deferred work. Resolved tickets. Active work. The status of every important thread is visible at a glance.

Feature roadmap. What is next. What is parked and why. What is rejected and why.

Deployment notes. The exact deploy command, environment variable list, gotchas from previous deploys. The thing that saves you at 11pm when something has gone wrong.

The pattern is lived-in over time, not a one-shot template. New decisions get added. Old ones get marked resolved or revised. In one of our larger projects the table of contents has 30+ entries spanning architecture, content guardrails, user feedback, storefront strategy, analytics gotchas, and deployment migrations. It is the project's institutional memory in markdown form.

Three layers of memory, each doing a different job

What I run today is actually three layers of memory, each doing different work.

The first layer is whatever the AI tool itself provides. Claude Code maintains its own memory across sessions. Cursor, Windsurf, and others have their own equivalents. This is the agent's working memory - useful but tool-specific, and it walks if you switch tools.

The second layer is the AGMemory.md file at each project root. Markdown, version-controlled, tool-agnostic. The agent reads it at session start. It survives every tool change. When I moved from AG to Claude Code, the memory file came with me, and the new agent got up to speed in minutes instead of hours.

The third layer is Obsidian notes for cross-project context. Standards that apply across multiple projects. Editorial principles. Affiliate strategy. Things that affect everything but do not belong in any single project's AGMemory. The agent reads relevant Obsidian notes on demand when the work touches them.

The three together mean a new session almost never starts cold. Whatever I am working on, whichever tool I am using, the context is there.

What this looked like before

Lost features. I would build something, move on to the next problem, and discover weeks later that I had rebuilt a feature that already existed in the codebase, in a slightly different form, because neither I nor the agent remembered the first version.

Lost ideas. Decisions made in one session - "we are not building X because of Y" - would not survive into the next session. The agent would re-suggest X. I would either re-explain Y from memory, or worse, agree to build X and have to undo it later.

Work redone because status was not tracked. The classic case: a task on the todo list is actually completed but never marked done. New session, agent reads the list, suggests building it. I do not catch the duplicate until halfway through.

Loss of overview. With multiple business projects running in parallel, drifting from the overall goals is the silent failure. Each session optimises locally. Without a memory file capturing strategic context, the agent cannot help you maintain strategic coherence - it does not know there is a strategy to maintain.

The 16-hour estimate becoming 45 minutes is the upside of solving this. The downside, before solving it, was project drift, lost work, and the same conversations repeated weekly.

What Claude Code does well

Going to the source of the model is the simplest part of the verdict. If a wrapper is throttling access to the actual thing doing the work, removing the wrapper is the right move. Anthropic's tier limits are clearly stated, do not silently change, and the model running underneath is the same one Claude Code uses end-to-end.

Daily use is consistent. The reliability is the part you do not notice until something breaks - which it largely does not, in my experience. Sessions hold context. Multi-file edits work. Tests get read before code gets written, when you remember to point the agent at them.

Multi-agent setups are surprisingly powerful. Sending an agent's implementation plan to a different model for a sanity check before executing has caught real mistakes. The two agents sometimes contradict each other, which requires judgment - but more often they produce a plan together that is sharper than either would have produced alone.

The non-judgmental friend aspect is underrated. Throwing a half-formed idea at the agent and getting back a structured response - sometimes with concerns I had not considered, sometimes with a feature direction I had not seen - replaces the conversation I would otherwise have had to pay for.

Deep research on paid tiers has been genuinely useful: finding gaps in a market, understanding competition, learning how others have tried similar things and failed. That kind of pre-work used to take days. It now takes a session.

What still bites

Skills marketplace is the most overhyped part of the AI coding ecosystem right now. Every skill is sold as "this will fix everything" and most are either overkill, redundant with what the model can do natively, or useless. Picking which skills are actually worth using is its own learning curve, and the market is full of marketing-driven recommendations from people whose business model depends on you installing as many as possible.

Long memory has a paradox. More memory does not always mean more consistency. With longer context windows, things established earlier sometimes get forgotten or remembered differently in different turns. Work being done twice, with different approaches each time, is a real failure mode. The fix is sometimes to start a fresh session and rely on the AGMemory file to re-establish context, rather than letting the in-session memory drift.

Trust is the real shift for non-coders. When the agent ships code you cannot read fluently, you have to put verification in place. Test coverage. Code review of critical sections by someone who does code. Specific questions back to the agent about why it chose this approach. The skill required has not gone to zero - it has shifted from "can you write this" to "can you ask the right questions and verify the answers." That shift is real.

Multi-agent contradiction needs judgment. When you set up a workflow where agents check each other's work, they will sometimes disagree. Which is the point. But you need to make the call.

A direct note for non-coders

If you are sitting on a product idea you cannot ship because you cannot code well enough, the unlock is real. The economics of "I cannot afford a developer for a maybe-nothing prototype" do not apply the same way anymore. The cost of trying an idea has collapsed.

Two things that took me time to internalise:

The skill requirement has not disappeared. It has shifted. You do not need to write the code, but you do need to understand what you are asking for, verify what you got, and recognise when something is going wrong before it ships. The agent will happily build what you asked for even when what you asked for is wrong.

Patience with the messy middle is required. The agent is not a magic shortcut. The first version of a feature is rarely the final version. The bimble journey - try this, that did not work, switch to this, it broke for that reason, fix it, ship - is the actual workflow. Same shape as it would have been with a human developer, just compressed.

Whatever tool you pick, build the memory habit early. Even a sparse AGMemory.md from week one will save more time than any specific tool feature.

The self-hosted option

Open-source AI coding agents exist. Aider can run against a local Ollama instance. Continue.dev integrates with VS Code and supports local models. There are others. They use models like Codestral or Llama 3 variants running on your own hardware - no cloud calls, no API key, no monthly bill.

Honest disclosure: I have not run these in production. The recommendations above come from tools I have used to actually ship things. The local-model route is genuinely viable for people with the hardware to run a decent model and the patience to deal with the gap between local and frontier model quality. That gap is real, and is the reason I have not made the switch myself.

If you are operating in a context where data cannot leave your machines - regulated industries, sensitive client work, paranoid by default - this is the route. Just budget for the model-quality gap to make some workflows slower or less reliable than the cloud equivalents.

What to do now

For someone starting today, the practical advice is short.

Pick one AI coding tool that works for you. Claude Code, Cursor, Windsurf, even ChatGPT for early-stage stuff. The tool matters less than committing to one for a few months instead of churning every time something annoys you.

Start an AGMemory.md file at the root of your project on day one. Three sections is enough to begin: project identity (what this is), current state (what exists), next steps (what is being built). Add more sections as the project grows.

Commit to updating the memory file at the end of every session. The agent will help. Confirm the changes manually before closing the session.

Build the verification habits early. Run tests. Read at least the file structure of what the agent ships. Keep a list of "questions to ask the agent" - patterns of inquiry that catch common mistakes before they ship.

After a few weeks of this, the productivity unlock becomes obvious. Sessions inherit context. The agent stops re-suggesting work that is done. New features build faster than the previous ones did. The bimble journey becomes shorter.

That is what AI agent coding actually unlocks for people who could not act on their ideas before. Not a shortcut. A new floor.

Bottom Line
Tool churn is the distraction. Memory is the lever.

Pick one AI coding tool that works. Build the AGMemory habit from day one. Verify what gets shipped. Do that, and the decade of locked ideas starts moving. The specific tool will keep changing. The memory practice is the durable thing.

Frequently Asked Questions

Yes, with caveats. The skill requirement has not disappeared - it has shifted from writing code to specifying what you want, verifying what you got, and recognising when the agent is going wrong. Plan for that learning curve, not for a magic shortcut. People shipping real products via AI agents are putting in real time on the verification side.

Honestly: pick one and commit for a few months. Switching tools is the most common mistake new builders make - they keep hoping the next tool will be the one that just works. None of them are. Claude Code is what I use, but Cursor, Windsurf, and others are all viable. The tool you commit to matters more than which one you pick.

Built-in memory is the agent's working context for the current session. AGMemory is project-level, version-controlled, tool-agnostic. When you switch tools - and you will - the AGMemory file comes with you. Built-in memory does not. AGMemory is the layer that survives everything else.

Multi-agent management was nice and the initial experience was genuinely impressive. But the silent throttling of Opus access on the highest tier was the trust break for me. If you are happy operating on the assumption that advertised limits may not match what you actually get, AG is interesting. If you want what you paid for, the wrapper-to-source pattern points toward Claude Code or other direct routes.

AGMemory.md is the non-negotiable one. The other two are useful but optional. If you are working on one project, you do not need Obsidian notes spanning multiple projects. If you switch AI tools rarely, the built-in memory is fine. AGMemory at the project root is the layer that delivers the most value for the least effort.

Some links on this site earn us a commission at no cost to you. We only recommend tools we have used ourselves. Rankings are never influenced by commission rates.