The Tools That Weren't Worth Building (Until Now)

A production technician at an aerospace manufacturer is reviewing an assembly drawing, and they need to know how thick a wire bundle will be and what size braid to order for it. It's a straightforward question with a deceptively complex answer. The outer diameter of each wire varies by part number and manufacturer. Circular cross-sections pack together in ways that take real geometry to get right. NASA specs and industry standards set the acceptable tolerances, and the braid has to be a size someone actually sells.

The technician knows one thing for certain: this is an engineering question. So they send an email. "Can you calculate the bundle diameter for drawing XYZ-123? Need to order braid." If the engineer gets to it in a few hours, that's a good day. More likely it's a day or two, because engineers have higher-priority work than fielding "quick" calculations. The technician and the assembly both wait, and the schedule slips by a day. This plays out dozens of times a week, and until recently there was no good fix.

Why nobody had built the calculator

You might think there's surely a wire bundle calculator out there somewhere, and there are a few, but they're embedded in expensive CAD software most people can't access, built for general electrical work rather than aerospace specifications, maintained as internal spreadsheets at large companies, or generic to the point of uselessness for actual production decisions.

Nobody built a good, public, aerospace-spec calculator because the economics didn't make sense. Building it properly means parsing datasheets from the major wire manufacturers to get exact outer diameters, implementing the geometric packing correctly, folding in the NASA and industry specs, putting a clean interface on it, testing it against real scenarios, and then maintaining it as specs change. That's months of dedicated developer time, maybe $50,000 to $100,000 fully loaded, for a tool that solves a 15-minute problem that happens 50 times a week. The math didn't work, so engineers kept getting interrupted for quick calculations and everyone accepted the waiting as a cost of doing business.

What changed

The same AI that answers technical questions turns out to be very good at writing software, and that has quietly changed what's worth building. Tasks that used to take a developer days now take hours, and implementations that needed weeks of careful coding can be prototyped in an afternoon and refined over a few days. In our experience the build time for a tool like this drops by something like 80 to 90 percent, which means the wire bundle calculator that wasn't worth months of effort becomes worth a week of effort, and the whole long tail of specialized tools that would help but were never worth it starts to look like a build list.

The wire bundle calculator

So we built it.

You enter the actual manufacturer part numbers for the wires in your bundle, M22759/16-20-9, M22759/11-22-0, whatever the drawing calls out. The tool looks up exact specifications from our parsed database of manufacturer datasheets and the relevant NASA and industry specs, the exact outer diameter and jacket material for each part number. It calculates the bundle diameter with proper geometric packing rather than approximations, and it recommends braid sizes that will actually fit. The whole thing takes about 30 seconds instead of two days. (The calculator itself is available on request.)

And the workflow around it changes shape. The technician still emails engineering, but the email now reads: "Used the calculator, got these numbers. Ordering braid and proceeding unless you see an issue." The technician isn't blocked, and engineering reviews instead of calculates. The email shifts from "please do this for me" to "here's what I'm doing, flag if wrong," and the bottleneck disappears without anyone losing oversight.

Tools for AI agents too

We didn't build this only for people. When someone asks our AI assistant for the bundle diameter on a wire list from a drawing, the model doesn't attempt the arithmetic itself. LLMs are terrible at math and you don't want them guessing at specifications. Instead the model treats the calculator as a tool: it extracts the wire part numbers from the drawing, calls the calculator with them, gets back a definitive answer with sources, and explains the result in plain language. The same build now serves people at a URL and serves the assistant as a callable function, and the second use came almost free.

This is also part of why we make tools like this public rather than burying them in an intranet. Friction decides what gets used. People need answers where they work, and anything that requires logging into a special system or remembering where it lives on the intranet tends to sit idle, while a plain URL that opens on any device becomes part of how work gets done. The value is in having the tool wired into your workflows, and there's little to gain from keeping it secret.

The economics, and the long tail

Be conservative with the numbers. The calculation used to take 15 minutes of engineer time plus a day or two of waiting, roughly 50 times a week across the organization, and now it takes 30 seconds with no engineering time at all. That's about 12.5 hours of engineering time a week, something like 600 hours a year freed up for actual engineering work, plus production moving without the built-in wait. Against a week to build and an hour a month to maintain, the return is roughly 50:1 in the first year.

Marc Andreessen said "software is eating the world" back in 2011. He was right, but the timing was off. Writing quality software stayed expensive enough that only the highest-value applications justified the investment, and the long tail of niche tools never got built: the torque-spec lookup that means cross-referencing material compatibility charts, the heat shrink sizing that depends on bundle diameter and temperature derating. AI-assisted development is what finally lets software eat that tail.

At xSkel this is the whole thesis: build an exoskeleton for an organization out of dozens of small, narrow tools that weren't economically viable before. Each tool solves one specific problem, and together they raise the floor of what everyone in the building can do, regardless of expertise level. Each one turns "ask an expert and wait" into "get the answer and verify." That's the exoskeleton: lightweight supports that let everyone lift more with less strain.

Where to start

Ask what the "quick" questions are that eat up expert time in your organization: the 15-minute calculations that happen constantly, the specification lookups that mean digging through PDFs, the compatibility checks that live in one person's head.

Those are the candidates. Each one used to mean months of development effort to solve properly, and each one now might take a week or two. Pick the one that stings the most, define what goes in and what comes out, find the authoritative sources that determine the correct answer, and build the smallest version people can actually reach from where they work. Then build the next one.