Beginners Write Software with AI. Pros Use AI to Make Software Elastic.
The Everything Engineer
SubscribeSign in
Beginners Write Software with AI. Pros Use AI to Make Software Elastic.<br>Elastic software uses AI to start flexible and buy efficiency as the economics justify it. The teams using it deliberately have a real edge.
Michael Carroll<br>Jun 16, 2026
Share
If you were building health care apps in the 2010s, you probably ran into some version of this problem:<br>build a standard patient data integration (FHIR, etc.)
tell a clinical client you have data integration, sign a contract
find out that they do the standard differently and your integration doesn’t work
build a custom parser for their “snowflake standard”
monitor the parser & update when it breaks
believe that now you’ve seen everything and that this software will cover you for all future clients
be constantly disabused of (6)
Eventually, you end up with thousands of lines of code that look like this:<br>def call_parser(client_name, data)<br>case client_name<br>when client_a<br>client_a_10000_lines_of_code_parser.call(data)<br>when client_b<br>client_b_spaghetti_string_parser.call(data)<br>... # and so forth, for 100 more clients
Fun! When people set out to build better health care software, I’m pretty sure this is exactly how they pictured spending a good chunk of their time. Still, it was table stakes for a lot of the work.<br>In the age of AI, however, it isn’t anymore.<br>If you are now thinking “okay, I see where this is headed: have AI coding agents build and fix the parsers, it’s easier now,” you are wrong. Something MUCH more interesting is happening here, and not enough people are talking about it. In what I’m seeing with clients — and in what I’m doing myself — engineers are adding AI calls into their software to trade raw efficiency for flexibility.<br>It’s something I’ve been calling *elastic software*, and it’s completely transforming how startups build and scale to market.<br>Thanks for reading The Everything Engineer! Subscribe for free to receive new posts and support my work.
Subscribe
Make flexibility the default, and efficiency the optimization.
I think the power of elastic software is best shown by example. Let’s pretend we have a new health tech startup creating a data integration like the one I mentioned in the last section. Instead of the code above, they might do this:<br>def call_parser(client_name, data)<br>ai_parser(client_name, data)<br>end
And that ai_parser can be nearly as simple — here using the RubyLLM gem:<br>def ai_parser(client_name, inbound_data)<br>response = RubyLLM<br>.chat(model: cheap_mini_llm_model)<br>.with_temperature(0.1)<br>.with_instructions(
And that’s it! Maybe the AI will choke a few times, and you will need to tweak the prompt based on results and failures, but it’s pretty quick and easy to get this running. You have a functioning parser running in minutes with maybe a dozen lines of easy-to-maintain code.<br>Got a new client coming online? Skip the long “please send us sample data to test integration with” discovery process! Just make sure you have your BAA with the inference provider signed and you are good to go.<br>The power of process reordering goes further: Is it getting really expensive to use inference to ingest ALL the inbound data? Likely, just a handful of clients are responsible for the vast majority of your data. Find out who they are, use the production data you are gathering to build a really solid spec for a parser, and then just update the pattern to catch those and process them efficiently first:<br>def call_parser(client_name, data)<br>case client_name<br>when client_a<br>client_a_parser.call(data)<br>when client_b<br>client_b_parser.call(data)<br>else<br>ai_parser(client_name, data)<br>end<br>end
Now you have scalable, cost-efficient processing for the 2 clients that are 80% of your volume, and a flexible solution for the 8 clients that make up the tail 20%.
That’s the “elasticity” of this type of software. You start stretched all the way toward flexibility: let the model handle it, accept a higher per-request cost, move fast. Then you contract toward efficiency as the math justifies it: build the custom parser, drop the AI call, push the per-request cost toward zero. And you do this independently for each integration, each data type, each client — never all at once, never up front.<br>Everything else keeps flowing through the AI layer while you wait for the next optimization opportunity to reveal itself.<br>Tokenomics: the opportunity cost you (probably) already have
So how do you decide when to optimize? That’s where this gets really interesting.<br>Startups have long practiced their own crude version of elastic software — they just offloaded it onto human ops. This has variously been called “scrappiness” or “doing things that don’t scale,” but the rundown is the same: you get the data, give it to a human to handle, then automate when it stops scaling. It’s slower and hits a scaling limit faster than AI, but more or less measurable: “how many human hours...