Yes — AI can write Apex, and it can write Apex that compiles on the first attempt. That is genuinely useful and it is also the least valuable thing it does. A class that compiles and does the wrong thing is a slower way to reach the same problem, and generated code that has never been run against the real org is a draft, not a change.

What separates the useful cases from the expensive ones is context: whether the thing writing the code knows what is already in your org, and what the change has to fit alongside.

What it does well

  • Boilerplate. Wrappers, DTOs, and the shape of a service class that follows your existing conventions.
  • Reading unfamiliar code. Explaining what a class does, which is the first hour of any change to something you did not write.
  • Tests. Generating the boring cases — nulls, empty collections, bulk boundaries — that people skip when they are in a hurry.
  • Pattern matching. Finding the three other places in the org that already solve this problem, so you do not solve it a fourth way.

What it gets wrong

The failure modes are consistent enough to plan around:

  • It invents APIs. A method that reads perfectly and does not exist. The compiler catches this one, which is why compiling is the lowest bar to clear.
  • It ignores governor limits. Logic that is correct on a developer org and fails on ten thousand records is still wrong.
  • It writes against patterns you do not use. A trigger framework nobody on the team recognises is a maintenance cost disguised as a solution.
  • It asserts the wrong thing in tests. A generated test can be written to pass against whatever the implementation does, which locks in the bug rather than catching it. See Salesforce testing automation.

Why org context changes the output

Asked in isolation, "write a class that calculates a renewal date" produces plausible code. Asked with knowledge of your org, it produces code that uses the field Finance actually populates, respects the record types in play, and does not duplicate an existing utility that already does this.

That is the whole difference, and it is not a difference in the model. It is a difference in what the model was shown.

What to require before you accept generated code

  1. It runs against the real org, in a sandbox, not just in an editor.
  2. There are tests that would fail if the behaviour changed, rather than tests that pass because they describe the implementation.
  3. A person has reviewed the intent, not just the syntax. Generated code deserves the same review as any other — see Salesforce code review.
  4. It is in version control like everything else, so it can be reverted when it turns out to be wrong.

The honest summary

Use it for the parts of development that are mechanical and verifiable, and treat the output as a first draft by a fast colleague who has never seen your org. The developer pages cover how that fits together in AI for Salesforce developers, and SympleOps is built to supply the org context that makes the difference — see what it does on a real org.