Your sprint planning used to run on gut feel plus history. Now a delivery manager opens the meeting with a number pulled from a vendor case study about AI-assisted development, and suddenly your three-day story is a one-day story on the board.
Nobody asked whether you have tool access on this client's environment. Nobody asked whether the client's data policy even permits an assistant to touch their repo. The estimate just shrank, and you're expected to hit it.
This is the real shift happening in contract technology work right now. Not whether AI coding assistants are useful — they often are — but who absorbs the gap when expectations outrun the actual, permitted, verifiable productivity gain. Usually, that's the consultant, unless you manage the conversation deliberately.
Why Estimates Are Shrinking Before the Work Does
Program managers and delivery leads are reading the same industry benchmarks you are. Vendor-published velocity claims circulate fast, and they get applied as blanket multipliers to backlogs regardless of codebase age, test coverage, or whether the team has any assistant access at all.
The mechanism matters more than the headline number. A benchmark built on greenfield code, high test coverage, and a developer fluent in prompting does not transfer to a ten-year-old monolith with sparse documentation and a client who has not approved any external tool for that repo. When a PM compresses your estimate based on a number from a different context, the compression is real even if the justification is not.
Treat any assistant-based velocity assumption in a statement of work or sprint commitment as a claim that needs sourcing, the same way you would question an unsupported performance benchmark on a resume. Ask where the number came from and whether it reflects your actual environment.
The Review Burden Didn't Disappear — It Moved
Generation time can drop. Verification time usually goes up, at least at first, because someone still has to confirm the generated code does what the ticket says, doesn't introduce a dependency nobody vetted, and matches the client's architecture conventions.
That review work doesn't show up in the original estimate because it's new. Pre-assistant, a developer wrote code slowly and understood it as they went. Assistant-generated code arrives fast and gets understood after the fact, during review — and the person whose name is on the pull request owns that understanding, regardless of who or what wrote the first draft.
- Code review time per PR often increases, not decreases, in early assistant adoption because reviewers are now validating unfamiliar patterns, not just logic.
- Security review and dependency scanning become mandatory gates rather than optional steps, since assistants can introduce packages or patterns the client has never approved.
- Documentation and test-writing can lag because the assistant wrote the implementation but not the rationale, and someone has to backfill that for the next engineer.
When you quote a story point or an hourly estimate, make the review and verification line explicit. It's not overhead — it's the actual cost of using the tool responsibly.
Client Policy Governs — Never Assume a Tool Is Permitted
This is the part that gets skipped in planning conversations and shouldn't be. Whether an AI coding assistant may touch client code is not your call, your bench's call, or even your prime vendor's call by default. It's the client's call, and it's usually written down somewhere in a security policy, an MSA data-handling clause, or an approved-tools list you haven't read yet.
Code assistants that send snippets to a third-party inference endpoint are a data egress event. For clients in regulated industries — financial services, healthcare, government-adjacent work — that egress may violate contractual confidentiality terms even if the assistant vendor claims not to retain training data. The claim is not the control. The client's written policy is the control.
| Before touching an assistant on client code | Why it matters |
|---|---|
| Check the MSA or SOW for AI-tool clauses | Some contracts now explicitly prohibit or restrict generative tools on client IP |
| Ask the client's security or compliance contact for an approved-tools list | Shadow IT risk applies to AI assistants exactly as it does to any unapproved SaaS tool |
| Confirm data residency and retention settings if a tool is approved | Enterprise and consumer tiers of the same product often have different data-handling defaults |
| Get the policy in writing, not verbal sign-off | You, not the client, carry exposure if an audit finds unapproved tool usage |
If you're unsure, the safest default is to assume no assistant access until you have explicit, written confirmation otherwise. Productivity gains you can't legally use don't belong in an estimate.
Sizing Stories Honestly When Assistant Use Is Approved
Assuming the client has cleared a tool for use, sizing still needs to separate two different activities that used to be bundled into one estimate: drafting and verifying.
- Size drafting time based on actual, observed output for your specific codebase — not a vendor's demo repo.
- Add a fixed verification allowance per story, at least until your team has enough history to know its real review overhead.
- Re-baseline velocity every few sprints rather than locking in an early estimate as permanent. Early productivity numbers in assistant adoption are usually optimistic and settle lower once edge cases and legacy code enter the backlog.
- Flag any story touching security-sensitive, compliance-governed, or poorly tested code as a non-standard estimate, since assistant output in those areas typically needs more scrutiny, not less.
A manager who pushes back on a verification line item is implicitly asking you to skip review. Make that trade-off visible rather than absorbing it silently.
Talking Productivity Without Talking Down Your Rate
There's a trap in this conversation: proving you're faster with a tool can read as evidence you should cost less. Resist framing your value around keystrokes.
Your rate reflects judgment — knowing which generated code is safe to ship, which dependency is a liability, which architecture decision will cause problems in six months. An assistant can draft a function. It cannot own the outcome, sign off on a security review, or explain a production incident to a client's VP. That accountability is what you're priced for, and it doesn't shrink because the typing got faster.
When a client raises productivity gains as leverage for a lower rate or compressed timeline, redirect to scope: more features delivered in the same engagement, not the same features for less. That keeps the gain real without converting it into a discount on your judgment.
Call to Action
If you're navigating a client's shifting expectations around AI-assisted delivery, scope, or review process, the Josh Pros LLC team works with consultants on exactly these conversations every week. Reach out at contact@joshpros.com or visit https://joshpros.com to talk through your next engagement.
#AICodingAssistant #ContractTech #DeveloperProductivity #CodeReview #ITConsulting #TechContracting #SprintEstimation #ClientPolicy #DataSecurity #SoftwareConsulting #AIinSoftwareDevelopment #ContractorRates
Talk to a real recruiter, not a bot.
We'll tell you the rate, the client, and the terms before you interview. And if we're not the right fit, we'll say so.