Over the last few weeks, we received five procurement documents: three RFPs and two RFQs, and every one of them had clearly been drafted with AI. The level of detail was overwhelming: user stories enumerated to a granularity we would normally reach in week three of discovery, data models sketched out, edge cases named, acceptance criteria attached to non-existent features. Reading them at human speed was not practical. The only way to process them inside the procurement window was to read them with AI as well.
That part genuinely works. Great input, impressive output. A document that once took a solutions team two days to digest now takes an afternoon, and the summary is better than what we would have produced by hand. Nobody here is nostalgic for the era of the eleven-page RFP that specified nothing.
At Ballast Lane Applications, we have spent that same period working out what these documents have quietly changed about the conversation that follows them. The problem is not that the specifications are bad. It's that they are convincing out of all proportion to how complete they actually are, and the distance between those two things now lands squarely on the vendor.
Free to Write, Expensive to Build
An exhaustive document and a finished document are different objects. The specifications we received were exhaustive about everything the client could see: screens, flows, entities, business rules. They were close to silent on everything the client could not.
Being exhaustive is now the cheap part, and that has changed what gets written. A requirement that would once have been argued over, because somebody had to sit down and write it, now costs nothing to include. Nobody objects to a feature at the drafting stage, since objecting takes more effort than leaving it in. What arrives is not a first version. It is the whole imagined system, with the ambitions of year three sitting beside the login screen and nothing marking which is which.
The effect compounds when a document drafted with AI is then read and answered with AI. Each pass adds plausible scope and no pass removes any. The triage that used to happen in a room, where somebody with a budget said that this one is not for version one, has no equivalent step anywhere in the process now. Everything written down gets estimated, because it was written down.
The same documents are then thin exactly where they are expensive. Security appeared, where it appeared at all, as a single line requiring the system to be secure. Scalability was named as a goal, with no load profile or concurrency target attached. Authentication and authorization models, data retention, and the compliance boundary the system would sit inside were absent or reduced to naming a provider. These are single lines with months of consequence behind them, and they sit in the same list, at the same apparent weight, as a feature nobody has asked for.
None of this is a failure of the tool. An AI drafting from a product description writes what a product description implies, and a product description implies features. It does not know the load envelope, the regulatory perimeter, or which of the client's existing systems the new one has to authenticate against, because nobody told it. The omissions are inherited from the brief, and they are invisible precisely because everything around them is so thoroughly specified. A gap in a sparse document announces itself. A gap in a dense one does not.
The Work That Did Not Keep Pace
Writing the work description has become dramatically cheaper. What decides when the work is finished, and what it costs to get there, has moved too, but nowhere near as far.
Third-party integration is the clearest case. When a system has to talk to a payment processor, a core banking platform, a carrier, or a partner's API, the schedule stops being ours. Sandbox credentials arrive when the other party issues them. Certification happens in their queue. Undocumented behavior surfaces when it surfaces, and the fix comes from an engineer we cannot task. No amount of specification detail on our side compresses that, and no amount of AI assistance does either, because the constraint is another organization's calendar.
Testing and validation are the second case. Generated code arrives faster than we can review it, and reviewing it is not a formality. Functionality that has not been tested does not go live, and we do not intend to soften that because the specification was thorough. If anything, the volume of generated code makes validation more expensive, rather than less. There is more of it, it looks plausible, and plausibility is exactly the property that lets a defect survive a casual read.
Why the Estimate Now Reads Like Padding
The commercial consequence follows directly. When a specification looks finished, everything that remains reads as overhead.
The client's side reasoning is sound on its face. The hard part, deciding what to build, is done, and it is written down in more detail than any brief they have produced before. What is left must be typing, and AI types quickly. So an estimate that comes back describing integration risk, validation cycles, a security review, and a hardening phase does not read as engineering. It reads as a vendor protecting its margin.
The expectation attached to this is not modest. Nobody is asking whether the work might be twenty percent cheaper, or twice as fast. The number in the room is ten times, and it's applied to the entire engagement rather than to the drafting step that actually improved. A tenfold gain on the cheapest part of the process is being extrapolated across every part that did not change at all.
Fixed price and fixed scope are then requested straight off the specification, on the reasoning that the scope is now genuinely fixed. But a fixed price is not a scope statement. It's a transfer of risk, only priced by the party that can see it. Scope depending on a third party's release schedule doesn't become fixed just because it's written down more precisely. It remains someone else's uncertainty, described well.
The Reference Material Nobody Has Yet
There's a second reason these engagements are hard to price, and this one is ours, rather than the client's. Estimating work means comparing it to work already done. The delivery model changed underneath us, and the comparison set has not caught up.
The internal agentic frameworks we build with have changed how fast a small group can move, and the results have been genuinely surprising: systems built in a fraction of the time the same people would have needed two years ago. What that speed has not produced yet is a reference class. We know the work goes much faster. We do not know how much faster this particular problem will go, because the last few projects were not run the way this one will be, and nothing before them was either.
The team composition has also stopped being the predictor it used to be. A small group that sits down together and starts iterating tends to get there, and the attribute that decides whether they do looks less like an inventory of technical skills and more like a disposition (the working assumption that this will be made to function). That is a real observation about how the work now succeeds. It is also close to useless as an input to a spreadsheet.
Eighty Percent Arrives Early, the Rest Does Not
The shape of the effort curve has changed as much as its total. Eighty percent of a system now appears extraordinarily quickly. The remaining portion (the corner cases, the details that make it behave exactly as intended, the validation and testing of what the AI produced) is where the time goes, and that part has compressed far less.
The overall duration is still much shorter than it was. But the effort is back-loaded and uneven in a way that does not decompose into evenly spaced deliverables. A milestone schedule is not only a claim about the destination. It is a claim about the path, and about which recognizable state the system will be in on a particular date. Under this way of working, the first claim can be made with some confidence and the second one hardly at all.
The people it takes have changed as well, and not in the direction the savings imply. Once producing code stops being the constraint, what remains is deciding what to build, validating what was generated, and standing behind the result. That is senior work. The teams that do it well are smaller than the ones they replace, but they are not cheaper per head, and every part of the job that automation absorbs tips the balance further toward experience.
The saving is therefore real, and it is not the one being asked for. More work arrives in less time, produced by fewer and more expensive people. Engagements do come out cheaper. They do not come out ten times cheaper, and what the actual multiple is we cannot yet say, for the same reason we cannot price the work with confidence: there is not enough of this behind us to know.
Reading the Specification the Way It Was Written
We do not have this solved, and presenting a method we have not yet proven would be worth less than admitting that.
What we are doing is reading these documents the way they were produced, with AI and at speed, and spending the capacity that frees up on something other than returning a bid faster. The same pass that summarizes a specification turns out to be good at finding what a specification does not say. Putting that reading back in front of the client before the pricing conversation, rather than defending an estimate during it, at least gets the omissions onto the table while they are still cheap to fix. It surfaces the authentication decision nobody has made, the missing load profile, the integration whose timeline belongs to an organization not in the room.
What we can offer in place of a milestone schedule is narrower, and it asks for more trust than a schedule does: a small team, a commitment to move as fast as the problem allows, and an open door: if the pace is not what we said it would be, the engagement can be stopped at any point. We think that's a more honest instrument than a set of dates none of us could hold to. We also understand why it lands badly against a procurement process built to compare fixed-scope proposals side by side. Clients still want fixed scope, fixed price, and milestones, and they want them for reasons that were sound long before any of this and have not stopped being sound.
Whether that is enough to win the work is genuinely unresolved. It costs time in a procurement window that has not grown any longer, and it asks a client to accept that the document they are proudest of is incomplete. The commitment we do hold is narrower and easier to defend: we will not quote a fixed price on scope whose dependencies we cannot see. Everything past that line, including how to frame the estimate and where to draw the commercial boundary without sounding like the vendor who cannot keep up, is still being worked out in live deals with real money attached.
The specifications got ten times better. The certainty underneath them did not move at all, and neither side of the table can manufacture it right now. Clients are pricing a document whose completeness they have no way to check. We are quoting a method whose pace we cannot yet predict, because it has not existed long enough to have a track record. Most of the friction in this market comes from how easy it has become to mistake exhaustive detail for settled ground, and that mistake is being made in good faith by everyone involved.