6 AI Tools in 1 Day, No Developer
This past Tuesday I walked into a room and understood why the format worked before a single line of code was written. Forty people. Six tables. Owners. Owners’ reps. General contractors. Building product manufacturers. Sales leads. Heads of innovation. VPs. Not a developer in the traditional sense among us. KP Reddy & Co. hosted. The Zero RFI team showed up to run the technical scaffolding. By end of day, six tables had shipped working software. Without engaging a single real programmer. Against real problems we live with every day.
The Recalibration
Anyone in that room who had actually shipped something internal at their own company was already in the top five percent of professionals working with AI today. KP said it mid-morning.
He was not flattering us. He was recalibrating us.
That is what KP does. He is an innovator’s innovator. He does not build things himself. He creates the conditions where people who have never thought of themselves as builders suddenly are.
What the Six Tables Built
I am keeping the table assignments and the company names out of this on purpose. What got built belongs to the people who built it. But the categories of problem matter, because they tell you what is within reach of a forty-person room with API keys and one day.
One table tackled the spec book. If you have ever watched a project manager comb through a five-hundred-page specification looking for submittal requirements, you know why this table existed. They built a tool that ingests a full project spec, answers plain-language questions with verbatim citations and source links, and generates a complete submittal register downloadable as a CSV. There are companies charging for exactly that service as a subscription. This table built a working version in a few hours.
A second table went after bid qualification and leveling. Owners and GCs spend weeks collecting contractor proposals, manually comparing them, trying to detect where scope was missed or where pricing is anomalous. They built a tool that ingests multiple bid responses, scores contractors against weighted criteria, surfaces gaps and risk, and produces a proposal summary. The kind of tool a procurement team would use on every project if it existed. Now it does.
A third table built a cost-risk early warning system. Construction has enormous amounts of historical cost data that never informs current decisions. By the time a project is showing overruns, the window to intervene has usually closed. They built a tool that analyzes historical project data by type, flags where current projects are drifting from expected patterns by work breakdown structure division, and runs simulations to estimate exposure. They added Monte Carlo locally. The AI wrote the script. The local machine ran it. The AI interpreted the output. That distinction matters. They were thinking like engineers already, not users.
A fourth table built a permitting and project visibility dashboard for owner-side operations. Leaders get calls asking what is happening on a specific street or project and have to manually pull records to answer. They built a tool that makes that information queryable in plain language, shows what is active, what is pending, what is moving. Government and owner-side operations, finally conversational.
A fifth table tackled construction document management and leadership reporting. Project teams receive unstructured information. Meeting notes. Schedules. Contractor submittals. PDFs of every variety. Someone has to manually parse all of it into a tracking system so leadership can see portfolio status. They built the backbone of a tool that ingests those documents, organizes them into a structured database, and ladders up to a leadership reporting layer. On-budget, on-schedule, at a glance. Without a coordinator spending two days a week on data entry.
A sixth table built an RFI and risk early warning suite. Four parallel approaches to the same problem. The industry generates enormous amounts of information about what goes wrong. Safety incidents. Quality failures. Lessons learned. RFIs. And almost none of it gets used to prevent the next project from making the same mistakes. They built tools that ingest that historical record, cluster it, surface the patterns, and flag risk before design locks in. One approach used synthetic data. One used real project data. One built a dashboard. One focused on the pre-construction briefing moment where the warning could actually change a decision. Different entries into the same door.
We had more than the 6 prototypes that our tables were assigned, we all had offshoot projects relevant to our own individual cases. This was quite productive, prolific, and inspiring.
The moat moved.
The Comment that Reframed the Room
It came mid-morning, in the middle of a conversation about daily briefings and API keys and how to connect an agent to a calendar.
Someone running a real operation. Revenue. Teams. The whole thing. Said something close to this: half my team thinks anything we share with AI becomes training data and eventually everyone has access to it. We have decided AI is bad.
The table did not dismiss it. We sat with it. What surfaced underneath was not a technical misunderstanding. It was two older fears wearing a new mask.
The first fear. Our industry is built on the belief that what we know is a competitive advantage. We have something you do not. The idea that knowledge could democratize. That the information asymmetry we have spent careers building might dissolve. That is threatening to people whose identity is organized around being the one who knows.
The second fear is quieter. If other people inside my company get access to the information I control, I become less important. I could be replaced. Internal gatekeeping is not a personality flaw. It is a rational response to a felt threat.
The Two-tier Problem
This is the real risk of top-down AI adoption. Not slow uptake. Not technical resistance. A two-tier knowledge economy forming inside your own organization.
People who understand why the tool does what it does. And people who just use it.
The first group builds leverage. The second group is exposed every time the model changes, the vendor changes, or the workflow changes. And the people most threatened by AI today are exactly the people most likely to slow your rollout to protect their seat.
A hackathon collapses that hierarchy for a day. Everyone is a beginner. Everyone is building. The thirty-year sales rep and the twenty-six-year-old coordinator are at the same table hitting the same walls. That is not a diversity exercise. That is a structural intervention.
The question KP kept circling back to all day. What kind of company do you want to be by the time AI stabilizes? One with distributed intelligence? Or a thin layer of fluent people sitting on top of a large group of compliant ones?
What Changed for Me About Owners and GCs
I rarely get extended time with owners and owners’ reps. This room was full of them. Direct access to ask what they wish building product manufacturers actually understood. What they face when a building gets turned over to them. What the before looks like. The before is its own odyssey that deserves its own piece.
And the GCs. From the manufacturer seat we talk about general contractors like they are the hardest to reach. The most transactional. The least interested in relationship. That is not wrong. But sitting at a table vibe-coding alongside them, watching a spec search tool take real weight off a project manager’s load, watching them light up at the possibility, that reframed something for me.
They are not indifferent. They are underwater. There is a difference.
What Comes Next
May 9th, Descript sent an email inviting their users to a Telethon being held today and tomorrow (May 14th and 15th, 2026). Building live, on camera, against the paper cuts their users have been asking about for months. Customers watching in real time, commenting, shaping what got built next.
A software company running a hackathon with its own customers in the room.
That is the move. That is where this is going. Not AI as a thing that happens to your company from above. AI as something your people build, together, against problems they actually have.
A vendor can help you scaffold. But they cannot do the learning for you. This has to be co-creation or you end up outsourcing the understanding, which puts you right back where you started.
The best software for this industry will not be written by developers who parachute in and learn the vocabulary. It will be built by the people who have been living the problem for twenty years and just got handed the tools (and informed and improved by the market, customers, and users).
A Playbook, guide to how to start – your first steps
As Peter Drucker said, there is nothing quite so useless as doing with great efficiency what should not be done at all.
I wrote a step-by-step for what how the day progressed and how easy it is for you to do this with your own team, at your own company. Pick the real problem, not the hypothetical one. The annoying one. The expensive one. The knot in your chain. Assemble a team that cuts across role and tenure. Hand out temporary API keys IT destroys after the event. Make Claude plan before it codes. Demo at the end, with leadership in the room, deciding what gets promoted to a pilot.
If you want the playbook, leave a comment or send me a DM and I’ll send it your way.
Part three drops Friday. Why AI slop is actually a quality filter. And what that means for every building product that has been surviving on information asymmetry.
Get in the room.