AI Code Generators: From Autocomplete to Agents

An AI code generator is any tool that writes code from what you type, using a large language model. They come in four kinds, and the difference is how much each does before you look: inline autocomplete suggests the next line as you type; chat in the IDE answers questions and drafts changes you apply; agentic coding tools read your project, edit many files and run commands on their own; and app builders such as v0, Lovable and Bolt make a whole working app from a description. The more a tool does alone, the more your review has to catch, and three risks follow all four: leaked secrets, code you may not be licensed to use, and instructions hidden in what the model reads.

This page is about the categories and the habits that keep them safe. It does not rank tools; the posts linked below compare them.

The four kinds of AI code generator

Inline autocomplete

The oldest kind, and still the one most developers meet first. You type, and the editor offers dimmed text to accept with Tab. GitHub’s Copilot documentation↗ (opens in a new tab) describes two forms: ghost text suggestions as you type, and next edit suggestions, which predict where your next edit will be and what it should be. The scope is small, a symbol, a line or a block, so a person reads every suggestion as it lands. That makes autocomplete the lowest-risk kind, and the easiest to accept without thinking.

Chat in the IDE

A panel beside your code where you ask “why does this test fail?” or “add input validation to this form” and get an answer with code you can apply. Chat sees the files you open or mention, so it can explain and draft across a few files, but you still decide what goes in. Most AI editors and IDE extensions now offer chat and agent modes side by side; how those modes differ is in Cursor agent vs ask vs plan and Copilot agent vs ask vs plan.

Agentic coding tools

Here the tool works in a loop. Anthropic describes Claude Code as an agentic coding tool that reads your codebase, edits files, runs commands and integrates with your development tools, and the others in this group work the same way: give a goal, and it plans, edits, runs the tests and tries again until it is done or stuck. One request can touch twenty files. The output is a diff, often a large one, and review moves from reading suggestions to reading changes.

App builders

Browser tools that turn a description into a running app, usually with hosting attached. v0 calls itself an AI agent that helps anyone create real code and full-stack apps and agents. Lovable calls itself a full-stack AI development platform for building, iterating on and deploying web applications using natural language, and syncs the code to Git. Bolt calls itself an AI tool that turns your ideas into real websites and apps. They suit prototypes, internal tools and people who do not write code, and they make it easy to ship something nobody has read.

Where each tool is covered

• The best AI coding agents: agents compared by how you work.
• Vibe coding: building by describing, and keeping it under control.
• Vibe coding tools: app builders and agents side by side.
• Cursor alternatives: AI editors by the reason you would switch.
• GitHub Copilot alternatives: assistants for teams, by platform.
• Claude Code alternatives: terminal and IDE agents.

Which kind fits the job

• Writing code you understand, faster: autocomplete, with chat for the occasional question.
• Learning an unfamiliar codebase: chat, asking it to explain before it changes anything.
• A bounded change across many files, such as a rename, a migration or a test suite: an agent, on a branch, with the tests as its finish line.
• A prototype to show someone by Friday: an app builder, with the plan to rewrite or review before real users arrive.
• Anything touching payments, authentication or personal data: whichever tool, with a person reading every line of the diff.

Safety: secrets, licenses and prompt injection

Secrets

Two leaks are common. You paste a key into a prompt, or an agent reads your .env file while exploring, and the secret now sits in a transcript or a vendor’s logs. Or the generated code puts the key in the source, sometimes in front-end code that ships to every browser. The OWASP Secrets Management Cheat Sheet↗ (opens in a new tab) starts from the same problem, secrets hardcoded in source and configuration files, and sets the baseline: least privilege for who and what can read each secret, detection that catches secrets before they are committed, and rotating them often. For agents, add one more: block them from reading secret files in their settings, and give them test credentials, never production ones. The seven leaks that turn up most in generated apps are in vibe coding security.

Licenses and invented packages

A model trained on public code can produce code that matches it. GitHub’s code referencing↗ (opens in a new tab) checks Copilot suggestions against public code, then discards a match or shows it with the URLs of the matching files and the name of the license, if one was found. Find out whether your tool offers an equivalent and turn it on, and treat a long, polished block that appears from nowhere as a reason to search for its source.

The other half is dependencies. OWASP’s entry on misinformation↗ (opens in a new tab) in its Top 10 for LLM applications names unsafe code generation: models suggest insecure or non-existent libraries, and attackers publish malicious packages under the names models commonly invent. Check that every new package exists, is the one you meant, and carries a license you can ship.

Prompt injection

An agent reads things: issues, READMEs, web pages, tool results. Any of them can contain text that reads like an instruction. OWASP defines prompt injection↗ (opens in a new tab) as prompts altering a model’s behavior in unintended ways, and calls it indirect when the instructions arrive in external content such as websites or files. Its mitigations fit coding agents well: restrict the model’s access to the minimum it needs, and keep a person approving privileged operations, such as pushing, deploying or running unfamiliar commands. How the attack works in practice is in indirect prompt injection.

How to review AI-generated code

Review it as you would a new colleague’s first pull request: assume good intent and check everything. OWASP’s advice for model output in general applies: treat the model like any other user, with zero trust, and validate what it produces before it reaches anything that matters. NIST’s Secure Software Development Framework↗ (opens in a new tab) makes the same point for all code: practice PW.7 is to review or analyze human-readable code to find vulnerabilities and check it meets security requirements, using automated tools to lower the effort. Generated code earns no exemption.

## Generated code review
- [ ] The change does what the task asked, and nothing else
- [ ] I can explain every file it touched
- [ ] No secrets, keys or tokens in code, config or tests
- [ ] Every new dependency exists, is the intended package, and has a license we can ship
- [ ] No code matched public code without a license we accept
- [ ] Input from users, files and APIs is validated; errors do not leak internals
- [ ] Tests cover the change and were not weakened to pass
- [ ] Linters, type checks and security scans pass
- [ ] Anything about auth, payments or personal data was read line by line by a person

The failures agents make most often, such as invented APIs, tests bent until they pass and summaries that claim more than the diff shows, and the order that catches them fastest, are in how to review AI-generated code.

Keeping track of what the generator did

A code generator answers “write this.” It does not keep the list of what was asked, what was done and how it was checked. fenbs is a task board that coding agents such as Claude Code, Cursor and Copilot connect to over MCP. Before an agent starts, it reads the board’s AI context and the team’s rules from the Decisions and rules page; while it works, it files what it finds as a feature, an enhancement or a bug; when it finishes, it moves the task to Completed and sets the test status, tested, partly, failed or needs-check, with test notes saying what was and was not checked. History records each change under the assistant’s name. fenbs does not read or review your code, scan for secrets or check licenses; it is where the review’s result is written down, so the next person knows what has been verified.