When AI isn’t just a tool, it’s a partner: Pricing the value

A couple of weeks ago, I wrote about Autodesk introducing outcome-based pricing for (some, all?) of its AI offerings. I wrote,

This makes sense when we consider the AI products Autodesk is planning to bring to market; for example, describing a building and having a Forma AI assistant create a preliminary design that a human then refines. If Autodesk sold that AI tool as an annual or monthly license, it would likely be prohibitively expensive for a solution that a designer may not need very often. Instead, charging by “preliminary design created”, the price is (we hope) more reasonable.

That blog generated a LOT of comments, from “AI should be free since I’m already paying for [the modeling tool]” to “I’m willing to pay for value but am not sure what this is yet,” to “Nope. AI is not for me”, to this one, very smart and worthy of a deeper dive:

Martyn Day commented on LinkedIn [lightly edited by me] that

Iterative workflows shy away from cost per run pricing. 

Martyn is right. Take SAP Joule AI HR as an example: if I use it to sift through resumes, I might ask it to check references or verify employment history dozens of times a day. It’s the same underlying task, done on a different resume each time.

Architecture and design, by contrast, are inherently iterative—they’re creative problem-solving at its finest. An easy to understand example is Graphisoft’s Archicad AI Visualizer. It’s powered by Stable Diffusion, an open-source deep learning model that generates images from text descriptions. Archicad AI Visualizer creates images to drive design discussions. For instance, the prompt “Show me a modern 5-story hotel in a woodland setting with a wave-like facade and reflective blue windows” produces a photo-realistic image reflecting Stable Diffusion’s interpretation of my prompt. Change it to a ziggurat-style design or switch the facade to brick—each modification generates a new image. I can continue iterating this way until I have a set of concepts to present to a client. The AI becomes my design colleague, my partner.

The point is that engineering and design, especially at early stages, are rarely linear. I may have five awesome ideas today and spend tomorrow figuring out that none of them can work — and what I learn there informs my next batch of what-ifs. 

How feasible this is with AI depends entirely on the price versus value. If the five ideas I come up with and reject take hours when that used to take weeks, it’s worth $N. Suppose the AI learns that I have a bias towards facades that cannot be produced economically. If it steers me away from them, the AI may be worth $2xN, since it’ll still make me faster than I would otherwise be, but with more targeted results. If each iteration costs $N/5, I break even (or better), reach my best design faster—and it, hopefully, is a better design than I would arrive at without AI.

It all comes down to perceived value.

We had the same argument about CAE solvers a few decades ago. They were seen as incredibly expensive, but more than paid for themselves in costs avoided (fewer prototypes and warranty issues) and speed gained (faster time to market). We eventually reached the point where most enterprises that could benefit from CAE are using it, in part because commercial mechanisms evolved. CAE in the cloud, renting solvers, (and simplified UIs), all made that possible.

Will we see the same thing in engineering AI? I hope so – the question is when.

Martyn’s other comment was also fascinating [again, lightly edited by me]:

… in an age where customers can have apps on demand, expect more firms to develop their own software solutions to buying traditional cad company software. I can already get chatGPT to strip down a service like Autodesk ACC and suggest how I could build an open source version feature by feature- it won’t program it up but it can define the recipe – how long before it just delivers one out of the ether, to your specification?

This is also something we’ve seen before, when big automotive, aerospace, and other companies developed their own CAD, CAE, data management, and other systems. The commercially available tools were seen as expensive, clunky, and not customized to their specific needs (all true), so DIY seemed like a good solution — until it wasn’t. These companies eventually realized that their expertise lay in making cars and planes, not in creating software that needed to be tested and refined, updated to the latest OS and communication protocol, and so on. Over time, just about all of the in-house codes were sold or spun out to software companies that could better manage them.

The world today is different. As Martyn points out, software is easier to create and reverse-engineer. But there’s still the “should I bother” question. Is it worth building my own tools from the available toolkits? Yes, it may match my needs, but that will take time from my day job. Someone needs to maintain it, and who’s responsible for updating it? Let alone security, cloud, and all of the other things that commercial vendors do? I’m not sure DIY is the answer, but I do think the door is wide open for a lot of cool, new companies to invent design and engineering tools we haven’t seen before.

The DIY question can be avoided if the commercial model is correct and if the tools are flexible enough for Martyn’s use cases.

Back to AI for a moment: We are so early in its use for engineering and design. Right now, today, we need to get people using AI —for ideation, to incorporate CAE results into the next design iteration, to ensure that all requirements are addressed, and so many more use cases— and that means pricing it affordably. And that may mean offering a free version, a fremium version and a pay-per-outcome version to suit lots of different user scenarios.

We need designers, engineers, analysts, BOM managers, field managers and all sorts of other participants in the design/make world to use AI tools so that we can  figure out what works and what doesn’t, how people want to interact with AI, what types of data they want to share and what they don’t. We’re just starting.

Go check out all the stuff Martyn writes over on https://develop3d.com/  and https://aecmag.com/ – it’s always interesting and insightful.