Genius is 1% inspiration and 99% perspiration
- Thomas Edison
Back in the heady, exciting, fast-paced early days of cloud computing - in the days when "there is no cloud, it's just someone else's computer" was still a funny punchline, people who had no background in infrastructure - networking, storage, dns, and the rest - could build an entire architecture with a couple of clicks. And they did so. Badly.
This history is well known to most people working in IT who are of legal drinking age. What's less well known is that cloud computing was, by no means, the first time this phenomenon had occurred.
When Windows NT came on the scene, it broke down the doors to a world previously controlled by folks who had taken the time to learn VAX, Unix, or Novell. Almost overnight, anyone who understood the Windows interface started building server environments. Badly.
When Microsoft included Access in it's Office suite, it exposed regular folks to the world of databases. For the first time, people who knew nothing about relational DBs could build complex, multi-table data structures, and could even put forms and automation around those tables. Regular people who didn't know the first thing about data normalization began building complex database solutions. Badly.
FrontPage was an application that let people build web pages visually - drawing, dragging, and dropping them into spots on a canvas and then letting a code builder on the back end generate HTML. The code was completely unreadable (and therefore unmaintainable) by anyone who didn't also have Frontpage, but this never bothered the users. People by the thousands began spawning Frontpage-generated websites. Badly.
Long before website combo platforms that let you build and host, there was MySpace. Similar to Frontpage, it offered a drag-and-drop interface to build web pages. Unlike Frontpage, it completely disintermediated the design from the code under it. The user never had to know how the sausage HTML was made, and no actual web developers were ever asked to maintain it since there was basically nothing to support. Armed with a pre-set library of text blocks, font options, and a massive library of graphics that blinked, twirled, flashed, and generally induced seizures in the unwary. In those head days at the end of the 90's, people without a lick of design sense (or in many cases, taste) went wild building web pages. Badly.
I could keep going. VMWare democratized the creation of virtual machines. Docker made containerization viable. Kubernetes simplified orchestrat...
No, ok, I'm stopping there. Not k8s. That thing is still hard as hell.
But I digress.
Coming back to the quote at the top of this essay, these tools made the 1% inspiration easy, while leaving the 99% perspiration largely untouched.
Moreover, in every one of the cases above, supporters of the tool would respond to criticism by saying something like
"It's going to keep improving. In just a few months the problems will go away. We have to get through the growing pains now to have the better version of the future."
For the most part, that never happened. To be sure, they got better - faster, clearer, with more options and features. But the fundamental problems - the ones that allowed users to continue creating badly conceived and poorly executed results - remained. Because those problems were (and still are) rooted in that weird combination of process, experience, and, for lack of a better word, "taste" that makes tech such a wild rollercoaster of a career path.
But in some cases the product didn't die completely. Because ultimately what DID catch up was people's understanding that the 99% perspiration didn't go away. They - the people doing the work - caught up instead, learning and applying the fundamentals so that the output improved even if the tool remained the same.
Which brings me, after ~600 words, to the point of this essay: AI. If you've been paying attention, you will already understand the uncanny similarity that the current zeitgeist that chatbots, LLMs, and agentic interactions has compared with the past.
Just as I'm not going to try to tell you AI is nothing special, I'm also not going to avoid telling you that all the experiences of the past are going to hold true in this case as well.
As my friend and colleague Abby Strong said recently,
The app was easy. Everything under it was not.
Maybe you're like me, and have a good number of friends who are skilled developers. If you asked them what they like about their job, you'll probably hear things like "solving interesting problems", "getting better in the craft of writing good code", and even "building something that helps users with real problems".
You know what they probably DON'T say they enjoy?
standing up a platform for their code to run on
setting up authentication that doesn't suck or get the company in trouble
ensuring there are effective RBAC controls so users don't do things they should be allowed to do
selecting, installing, configuring, or tuning the database and it's queries. In fact, anything to do with a database at all is never on a developer's "I love this" list.
Ensuring storage is both performant and cost-effective
Dealing with connectivity between sub-components
error handling between all of the above elements
Going back to Abby's line of thinking in her blog, "everything under it (the app)" is all that shi...tuff. And more.
Every one of those builders will hit the exact wall I hit. Not "how do I write the app" - AI handles that. The wall is: Where does it run? How does it get governed access to the data? How do I control who sees what? How do I not recreate a pile of duplicated, ungoverned data and integrations every single time? Nobody wants to rebuild hosting, identity, RBAC, and data access from scratch for every new experience.
So what are we supposed to do? How do we - IT practitioners and especially IT practitioners interested in and committed to monitoring, observability, and security - leverage the AI tools we're given and encouraged to use while avoiding being dragged down multiple technical rabbit holes?
Unsurprisingly (both because I'm writing this blog, but also because Cribl is being super Cribl about this) we think we have a solution.
The new "Apps" button (you can find it in the upper right corner of every screen) opens up a world of options. Yes, there are pre-built tools that you can bolt into your environment so that they offer new views, processes, workflows, and capabilities all built around your data.
But also Apps is a platform on which you can build your own stuff with the same AI-driven conversational flow you do (or might be doing. Or are thinking about doing. Look, I'm not here to judge you about your personal AI choices.) today.
In the (not so distant) past, if you had all your data but needed to see or use it differently, that was a feature request (FR). Even the most responsive vendors still needed time to understand, prioritize, prototype, test, and roll out a new FR. And you, the user, had three choices after submitting that FR: live without it, find a work-around, or migrate to a different tool.
The challenge is that no FR exists in a vacuum. It competes with other FRs, and even with requests for something similar but with a variation that makes it less usable by you. Which one wins? Your guess is as good as mine!
But now you have another option: build it yourself. I don't mean that the way petulant programmers respond to demanding users, "If you don't like it, you can just build your own damn tool and see how easy it is!".
I mean that you can start with all your data, all the foundational work that Cribl has done, and - for lack of a term that doesn't make me throw up in my mouth - vibe code the parts you need. Apps lets you do the fun part of development and keep iterating until you have exactly what you (and your team, department, organization, or business) want and need, without ever having to worry about the dirty underbelly of your data stream.
Talk about a job that's "no sweat!"
