Should You Tell Clients You Used AI?
Yes, tell them - and put it in the proposal or the discovery conversation rather than in an email after delivery. You are not confessing to something. You are describing how you work, the same way you would name a hosting provider or a framework. The disclosure itself is almost never what damages a relationship. The timing is. A client who hears it up front hears a method. A client who works it out afterwards hears a secret.
I have watched both versions of this happen to builders I know. The ones who put a line in the proposal get a shrug, occasionally a question, and then the project proceeds. The ones who said nothing and got asked about it in month two spent the rest of the engagement defending work that was already finished and already fine. Nothing about the code changed between those two outcomes. Only the order of the sentences did.
Hiding It Is the Actual Risk
The exposure runs in the opposite direction to how most builders feel it. Disclosing costs you an occasional awkward question in a discovery call. Not disclosing costs you the relationship on the day it surfaces, and it does surface, because software has a long tail and you are not the last person who will ever look at that codebase.
- Their own developer reads the repository when the project is handed over, and forms a view without you in the room.
- You mention a tool by name on a call, casually, six weeks in, and the client connects it to a question you dodged earlier.
- A bug appears and needs explaining, and the explanation would be simple if you had not created a reason to be careful about how you word it.
- They hire someone else later to extend the work, and that person tells them a story about how it was built.
- Your own website talks about building with AI while your proposals do not mention it. Clients read both.
Here is the part that actually hurts. Once it is discovered rather than disclosed, the AI stops being the subject of the conversation. Your judgment becomes the subject. The client is no longer asking whether AI-assisted code is acceptable, they are asking what else they were not told, and that is a much harder question to answer well.
How to Say It in One Sentence
One sentence, stated plainly, positioned as method rather than caveat. Something close to: I build with AI tooling as part of my process, I review and test everything that ships, and I stand behind the result the same way I would if I had typed every line. That is the whole disclosure. It names the tool, names the accountability, and does not invite a debate.
- In a proposal: one line in the how I work section, sitting alongside your stack and your process. Not a disclaimer at the bottom in smaller type.
- On a discovery call: said in passing while you describe your process, in the same tone as everything else you say about it.
- In the contract scope: a plain statement that AI tooling forms part of the delivery method, so it is on the record before anyone signs.
- When asked directly mid-project: answer in one sentence and then carry on. Length reads as guilt, and a short confident answer usually ends the topic.
What makes that sentence work is the second half of it. Any builder can say they use AI. The part the client needs is that a named human reviewed it, tested it, and remains responsible for it. If you only say the first half, you have handed them the worry without the reassurance. Your [one page AI proposal](/blog/one-page-ai-proposal-that-closes) is the natural home for it, because a proposal is already a document about method.
What Clients Are Really Asking When They Ask
When a client asks about AI, they are almost never opening a debate about creativity or authorship. They are asking three practical questions in a single awkward sentence, and if you answer the literal question rather than the real ones, you leave them exactly as worried as they were before.
- Is this going to break? They have heard that AI-generated code can be fragile. Answer it by describing what you test and how you verify, not by defending the tool.
- Who fixes it when it does break? This is the one that actually keeps them up. Name the support arrangement, and say plainly that they call you, not a chatbot.
- Am I paying developer rates for something you generated in an afternoon? This is the question nobody says out loud. Answer it before they have to ask it.
- Where does my material go? For clients with confidential documents, customer data or unreleased product information, this is a legitimate operational question and deserves a specific answer rather than reassurance.
Answer the question underneath the question and the surface question dissolves. That fourth one in particular rewards being able to speak specifically about what stays local, what is sent where, and what your permission setup allows - which is the ground covered in [is Claude Code safe for client work](/blog/is-claude-code-safe-for-client-work). A concrete answer here does more for a client's confidence than any amount of general reassurance.
Up Front Versus Discovered Later
The same facts land completely differently depending on when the client learned the context. This is not a psychological trick, it is just how trust works: information volunteered is read as transparency, and identical information uncovered is read as something that was being managed.
How the same fact reads, depending on when they heard it
| The fact | Disclosed in the proposal | Discovered after delivery |
|---|---|---|
| You built it with AI tooling | A method. Reads as current and efficient | A concealment. Reads as something you assumed they would object to |
| The build took three days | Evidence your process works | Evidence they were overcharged |
| A bug shows up in week two | Normal software. You fix it and everyone moves on | Proof the AI was sloppy and nobody checked |
| You cannot explain one function on the spot | Fine. You go and read it and come back | Confirmation that nobody understands the codebase |
| They bring in another developer later | A handover conversation you can lead | A conversation about you that happens without you |
Nothing in the left column is different from the right column except sequence. That is the entire argument for early disclosure, and it is why the right place for it is the proposal or the first real conversation, when nothing has been delivered yet and there is nothing for the information to retroactively reframe.
When Disclosure Is Not Optional
Sometimes this is not a judgment call at all. The client's contract, their vendor policy, or the terms of their own client's agreement can make disclosure a hard requirement, and in those cases the decision was made before you were asked. Read the paperwork before you assume it is silent on the subject.
- The agreement you sign. Look for clauses on third-party tools, subprocessors, confidentiality, and who owns what is delivered.
- Their internal AI policy. Larger organisations increasingly have one, and it usually applies to contractors as well as staff.
- Their procurement or security questionnaire. If they send one, the disclosure question is often already in it, and answering it inaccurately is a different category of problem entirely.
- The contract above yours, if you are subcontracting through an agency. Their obligations to their client flow down to you whether or not anyone mentioned it.
Then there is the client who says plainly that they do not want AI used. Before you decline or agree, find out what they mean, because the phrase covers several different concerns. Some mean no AI-generated content published under our name. Some mean our confidential material must not be sent to an outside service. Some are reacting to something they read and have not thought past it. Those are three different requirements and only one of them is genuinely incompatible with how you work.
How to Answer: Why Does It Cost That If AI Wrote It?
Because they are buying a working outcome and someone accountable for it, not a quantity of typing. The honest answer is short: the price reflects what the thing is worth to their business and the fact that it is my name on it, not how many hours it took to produce. Said calmly, in one breath, that usually settles it. Said defensively, it never does.
It helps to be specific about what the money is actually paying for, because the client has genuinely lost sight of it in that moment. They are paying for the scoping conversation that decided what to build. For the judgment about what not to build, which is where most of the savings actually live. For the review and the testing. For the evening you spend fixing something urgent. And for the fact that a person, not a tool, carries the consequence if it goes wrong.
If this question keeps arriving, look at how you price rather than how you explain. Hourly billing makes the question unanswerable by design, because you have told the client that hours are the product and then handed them a reason to believe the hours went down. That is the argument for [pricing the outcome instead of the hour](/blog/stopped-charging-hourly-for-ai-builds), and it removes the objection at the source rather than talking past it every time.
None of this is about having a clever line ready. It is about having decided, before anyone asks, that how you build is a normal part of what you sell. Builders who have decided that answer the AI question in a sentence and get on with the work. Builders who have not, negotiate against themselves in every discovery call they take.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
Do I have to tell clients I used AI?
It depends on what you agreed to. Check the contract, their vendor or AI policy, and any security questionnaire they sent, because disclosure obligations are often already written down. Where the paperwork is silent it becomes a judgment call, and disclosing early is the safer side of that call. If your agreement does say something specific, follow it rather than a general rule of thumb.
What if a client says they do not want AI used at all?
Ask what they mean before you respond. The phrase usually covers one of three concerns: no AI-generated content published under their name, no confidential material sent to outside services, or a general unease they have not examined. The first two can often be worked with. If the requirement is genuinely incompatible with how you build, decline the project rather than agreeing and doing it quietly anyway.
How do I disclose AI use without sounding like I am apologising?
Keep it to one sentence and say it in the same tone as the rest of your process. Name the tooling, then name your accountability: you review and test everything and you stand behind the result. Put it in the how I work section of the proposal, not in a disclaimer at the bottom. Length signals discomfort, so a short confident line usually ends the topic immediately.
Will telling clients I used AI make them want to pay less?
Only if your pricing is built on hours. If you sell time, disclosing that the work went faster hands the client an argument, and they will use it. If you price the outcome, the tooling is simply how the outcome gets produced and the conversation does not arise. The disclosure is not the problem in that scenario - the pricing model is what created the opening.
When in a project should I bring up AI?
In the proposal or the discovery conversation, before anything is delivered. At that point there is no finished work for the information to reframe, and the client evaluates it as part of your method alongside everything else. The worst possible moment is after delivery or during a bug, when the same fact arrives with a reason attached and gets read as an explanation rather than a description.
Last reviewed by Duncan Rogoff on August 20, 2026
