Angelo Applewhite

Becoming an AI-native developer is a path I didn't see myself on over a year ago. I've spent the last 16 months learning, building, and shipping products and applications. That meant long nights fixing codebase errors, deployment issues, sloppy executions, agentic hallucinations, and the classic "it works on my machine" problem. Agentic development is powerful when you leverage it correctly. It can give one focused engineer the output of a full development agency. You can instruct agents to run rigorous code reviews around the clock and even merge code without constant oversight. The tools move fast, but the fundamentals still matter. I've learned more by shipping and fixing real issues than by any tutorial. Here's what I've built so far: engineeredxangelo.dev

Agents overbuild. Ask for a fix and you get the fix, plus a config option nobody wanted and a fallback for a case that can't really happen. Before review, try asking the agent which parts of the diff could go with the task still done. Cut those, then review what's left.

When an agent fixes a bug, ask why it happened before you read the diff. If it can walk from the input to the bad output, you can check the fix against that. If the explanation stays vague, it probably patched where the error showed up and never found where it started.

Chrome, Edge, Firefox and MDN just shipped 203 web guides for coding agents. They don't get dumped into context. The skill has the agent search a CLI and pull back only the guide for the task it's on. I'd copy that for any rules doc too long to load every session.

When an agent's PR touches package.json, I'd read that part before anything else. Every other line in the diff is code the agent wrote and you can review. A new dependency is code nobody on the team has read, plus whatever comes along with it in the lockfile.

Read the fine print on Anthropic's self-hosted Managed Agents. You run the server, sandboxes, credentials and session history, but model calls still go out. For a coding agent that history is mostly file contents and command output, the part I'd want on my own infra anyway.

When a coding agent flips the moment you push back, it isn't necessarily agreeing with you. Models fold under pushback even when they were right. Before it rewrites, ask what would have to be true for its original approach to be correct. Sometimes it's a constraint you forgot.

Google ran the same tasks with and without each skill, then deleted any skill that didn't beat the baseline. They rerun the check after a model upgrade, since a newer model may already know the workflow. I'd start doing this on my own skills, especially after a model switch.

Microsoft swapped the engine behind Copilot Chat in Visual Studio. Same models, new harness. On 157 real .NET tasks it resolved up to 21 more, and a task only counted if it didn't break tests that already passed. How much of what we call model quality is really the harness?

Radware scanned about 145M GitHub items for hidden text aimed at AI agents. Only 47 were attacks. Most in issues and PRs targeted the project's own triage, review or CI bot. Projects' hidden notes to their own agents grew 5x in four months. Anyone can type the same note.

Worth grepping every agent diff for new try/catch blocks and fallback defaults. When something fails mid-session, the fastest way back to green is to catch the error and return something plausible. The tests pass. The bug is still there. It just stopped being loud.

AWS Emulator, OpenAI's internal Codex beta, and Anthropic's C compiler all have the same shape. Agents write the code. People design the specs, the test harness, and the gates that decide when a change is correct. That's the job now.

Read the diff before you read the agent's summary of it. The summary is what it meant to do. The diff is what it did. Working out the change cold is what makes you a better programmer. Then read the summary. Where your read and its read disagree is usually the bug.

AWS shipped an emulator today that agents wrote end to end. The team says it never wrote or reviewed the code. The part I'd copy is boring. Every test was checked against real AWS before agents had to pass it. Agents will grind toward a target for days (if you keep them running). Check and define the target first.

A diff shows what changed. It rarely shows what the agent assumed the ticket meant, which is where clean, passing changes go wrong. Have the agent list its assumptions in the PR description, one line each. A wrong assumption is a one-line fix there. In code it's a buried bug.

Agentic Workflow Tip ⬇️ First prompt in a new repo: ask the agent for a glossary of the project's own terms, like which "job" is a cron and which is a queue. Then check a few entries against the code. You learn the domain and catch the agent's wrong picture of the repo before it writes a line.

After a compact, Claude Code re-reads at most five files the agent touched, most recently modified first. If it wandered, those five are often the wrong ones. The plan file and project-root CLAUDE.md get re-injected from disk. Write the scope there before the window fills.

Anthropic's Fable 5.2 guide: tell the model the codebase is its own and it merged duplicate code about half the time, vs under a tenth without. The catch is 1.5x the output tokens and changes nobody asked for. Refactor ticket, say it. Tight scoped PR, leave it out.

The most underrated part of a coding agent session: the files it read before writing anything. That trail maps where the logic lives. Which module owns the rule, which test pins it, which config changes it. Read it before the diff. You’ll actually learn the codebase, not just the change.

Move slower for faster progress. Agent output is easier to review when the change is small and focused. GitHub's agentic engineering guide suggests stacked PRs so each piece stands on its own. One job per PR beats a "small refactor" that quietly touched half the repo.

GitHub Copilot now runs in JetBrains Air over the Agent Client Protocol. Claude and Codex plug into ACP editors through adapters. The editor is becoming a host. The agent is something you pick separately. Do you choose your editor first or your agent first now?