Corporate AI Catch-22
Table of contents
- The New Reality: Build It Faster Than You Can Plan It
- A critical warning for product teams
- Hijacking Reality and Getting Hands On Tools, Safely
- What People Actually Learned
- Where to Learn More About AI
The New Reality: Build It Faster Than You Can Plan It
The economics of software development have fundamentally changed, but most companies are still operating like it's 2019. I've lost count of how many times this quarter I've been in a meeting discussing some GTM need, only to realize it would be faster to just build the thing than continue talking about it...
A few weeks ago, I was in a meeting with my sales and GTM collague who needed a way to figure out the public email addresses of developers based on their GitHub projects
So I loaded up v0.dev and started describing the system requirements. 10 minutes later, before the meeting had concluded, I had already developed and deployed a single page application (SPA) that handled by colleague's task automatically, saving her a ton of time going forward.
These kinds of internal tools are not even tickets anymore. They're a 10 minute conversation with an integrated LLM-enabled prototyping tool like Vercel's v0.dev.
A critical warning for product teams
There's a critical warning embedded in here for product teams as well. The same rapid prototyping capability allows me to decide that I'm tired of mermaid.live putting their Mermaid.js diagram viewing capabilility behind paywalls, accounts, credits and associated horseshit.
So I'll just build an app that visualizes mermaid diagrams for free, in three minutes, and then publish it on the public internet so that everyone else can continue to use it for free.
Pissed off developers are more capable today than they were three years ago.
But here's the problem: your team doesn't know how to think in these new time scales. They're still planning like software takes months to build, while the market is moving at the speed of hours.
So how do you hold these two competing points: speed and safety in mind at the same time and still retain the abilty to function?
Here's how we approached it at WorkOS...
Hijacking Reality and Getting Hands On Tools, Safely
We had a week-long company offsite scheduled. Instead of the usual team bonding exercises, we turned the entire week into an intensive AI crash course.
Prior to this, our security and engineering productivity teams did their due diligence around which integrations and LLMs we could enable and support for folks to support experimentation.
We bought several pro and enterprise plans and provisioned seats for everyone in the company to play with leading tools.
Teach the Basics, Then Go Hands On Immediately
I started with a 30-minute talk that covered the fundamentals everyone needs:
- embeddings,
- neural networks,
- how LLMs work and how they democratize specialist outputs but not understandings
- hallucinations and why we need to spot them (brand damage, errors)
- Retrieval Augmented Generation (RAG)
Not theoretical nonsense—but live demos showing exactly how these systems work and where they break.
Visualizing embeddings across a 2D plot is usually one of the "Aha" moments when people intuitively begin to grasp semantic meaning and semantic search.
This wasn't optional background. You can't safely use tools you don't understand, and you can't identify the sharp edges until you know what you're looking at. Most companies skip this step and wonder why their teams either avoid AI entirely (they're afraid of breaking something) or use it recklessly.
Forcing Uncomfortable Learning with Hands-on Workshops
Immediately after the technical foundation, we launched into hands-on AI workshops. No gradual introduction, no practice datasets. Everyone started using real AI tools on real problems immediately.
The next session I delivered, "AI-Enabled Content Creation", deliberately made people uncomfortable: I forced each person to research, understand, and present on a topic they knew nothing about. Not their area of expertise, not adjacent to their current role—completely foreign territory.
A designer had to become competent enough in quantum computing to give a presentation. A developer had to research competitive dynamics in the pharmaceutical industry. Marketing had to explain the technical architecture decisions behind database indexing strategies.
- Phase 1: Use AI to build foundational understanding of an unfamiliar topic. Get from "Holy shit, what?" to "Oh, I see"
- Phase 2: Create a structured outline for a presentation
- Phase 3: Turn that outline into a draft with supporting arguments
- Phase 4: Generate visuals that would normally require a design team
- Phase 5: Polish everything using our company style guide
- Phase 6: Practice the presentation with AI feedback
Each phase was timeboxed to 5 minutes, forcing rapid iteration and preventing perfectionism.
By the end of thiry minutes, people who knew nothing about a topic were presenting confidently on it. The realization wasn't that AI replaced their expertise—it was that AI could accelerate their ability to develop new expertise at speeds that felt impossible.
The "holy shit what" in the beginning helped, because folks had the experience of going from "I do not know what this is" to, "I am presenting on my post about X" in a half hour.
This was an eye-opening experience for anyone who had not already been regularly experimenting at the forefront of AI.
The Security Reality Check
Before anyone touched external AI services, our security team walked through the actual risks. Not hypothetical concerns, but specific examples of how companies have leaked data, violated compliance requirements, and created legal exposure through careless AI usage.
This wasn't about restricting AI usage—it was about enabling safe exploration at the speed business actually moves.
By the time we reached the offsite, everyone had accounts on approved tools that had already been put through their paces from a security and compliance perspective.
Building an AI-First Culture
After establishing safe experimentation protocols, we knew that real change required more than just tools and training—it demanded a shift in mindset and culture across the company.
We created new Slack channels dedicated to AI: one for sharing the latest developments, one for questions, and one for "wishes"—things people wanted AI to do or workflows they hoped it could solve. This gave everyone a place to surface ideas, frustrations, and discoveries in real time.
We added new AI-focused sections to our company all-hands meetings. Every all-hands now included time for AI demos, discussions, and open Q&A. We made it explicit that everyone was encouraged to experiment with LLMs and AI tools, and to share their learnings, workflow improvements, and even failures.
We carved out time in our regular demo blocks specifically for showing off new AI-powered workflows or discussing lessons learned from recent experiments. This wasn't just for the engineering team—marketing, sales, and operations all participated, showing how AI was changing their day-to-day work.
Most importantly, we talked about the actual dilemma at the beginning of this post—the risk of moving too fast versus the risk of moving too slow—openly with the entire team, not just the c-suite. We discussed the real possibility of disruption, not as a distant threat but as a present reality.
The key to all of this was a mindset shift:
- What is possible now that wasn't before?
- What time frames are actually reasonable for building and shipping new tools?
- What assumptions are still true, and what has been fundamentally disrupted?
By making these conversations part of our regular cadence, we made it clear that adapting to AI wasn't just a technical challenge—it was a company-wide imperative, and everyone had a role to play.
What People Actually Learned
The most valuable insights came from hitting the limitations of AI tools. When the output was wrong, when the tool couldn't handle their specific use case, when they had to iterate multiple times to get something useful. These "failure" moments built practical wisdom that no amount of theoretical training could provide.
People discovered the difference between AI capabilities and their actual workflow needs. They learned to recognize when AI would save genuine time versus when it just felt impressive but didn't fit their process.
Where to Learn More About AI
the mind is not a vessel to be filled but a fire to be kindled
It's not just about what your team learns—it's about teaching them where to go to keep learning as the field evolves. The best teams know how to find the signal in the noise.
DeepLearning.ai courses can sometimes feel thin, but they're excellent proxies for keeping up with what's changing in the field. They're updated frequently and can help you and your team stay current on the latest trends and techniques.
Recommended AI Newsletters
Staying up to date is easier when you have a few high-signal sources in your inbox. Here are some of my favorites:
- Daniel Miessler's Unsupervised Learning
- Santiago Valderrama's Data Machina
- Zachary Proser's AI & Engineering Newsletter
It's also worth following key figures in the industry, like Andrew Ng and Andrej Karpathy, as well as seeking out the people who are actually doing the research and reading the latest papers. The field moves fast, and the best insights often come directly from those pushing the boundaries.
Ultimately, the key point is that different people will find different things interesting—and this phase of AI carries massive disruption with it. My expectation is that people will be able to:
- Use AI to learn faster
- Use AI to learn things they previously did not attempt
- Use AI to switch roles, jobs, or careers faster than they previously could have
Therefore, the real key is to get the tools in folks' hands and get them building, working, and querying in the new way—so that their real interests shake out of it through hands-on exploration.
This is an approximation of how my personal creative loop works, and it's similar to what Rick Rubin describes in The Creative Act: A Way of Being. It's about constantly gathering seeds: sometimes from a LinkedIn post, sometimes from a book, something someone mentions at work, or simply an itch to experiment with something new.
There's also a gestation and experimentation period, and then I force myself to share the work—because actually publishing increases luck and serendipity. The act of sharing is what often leads to the most unexpected and valuable connections.