Enabling Safe AI Experimentation for Non-Technical Founders

Hi, everyone. So thank you for having me. We are going to start my talk with an image of a corgi, First, because I have a corgi, and second, because I deeply believe that the day you see a corgi is a good day. But also, I have I promised him that I will include him in my presentations the moment I got him.

So this is me fulfilling this promise. And at the end of this talk, you'll see him again. And that's how you know the talk is over, in case you were wondering. But yeah, several months ago, I left my regular job. I was a head of engineering at Redevance AI to do a bit of AI experimentation. Because when you're in the technical leadership position, especially at a startup that's growing very actively, you find yourself dealing with people all the time. And you really want to deal with code a bit more.

So I left to start experimenting with AI to get my hands on it, and build things, and see how amazing it is, and how bad it is. And hopefully, I can share a bit of this experience with all of you. So this talk started with me thinking about this experience that I had because I was working with several startups that had non technical co founders who really wanted to find their feet on the market, see if their idea is good or not, And they had very little money.

So as a result, they could not afford a big engineering team. They had to figure out how to do things and how take their proof of concept off the ground. But working with them, the more I thought about it, the more I reflected on how it went, a very interesting pattern emerged. And I'm going to talk to you about this pattern.

It's a mindset shift that hopefully all of you will take with you when you leave this room after you see Corgania. So I'm going to start with two stories. And when I tell you them, you'll initially think that they are unconnected. But they're actually about the same thing. So the first thing happened when I was a head of engineering One of the initiatives that I was driving was an initiative to empower more senior engineers to use more AI.

And some of them were hesitant. And I was very lucky because I generally have very good trusting relationships with my engineers. And we can have those difficult deep conversations. And I talked to one of them. And he said something very interesting. He said, Inge, I spent twenty years learning this craft.

And now AI can do it in an hour. I feel like I wasted my life. And it is a very difficult topic. And it is a very difficult feeling that a lot of people in the industry have right now. But let's jump from this very sad story to a bit lighter one. Let's go with the light version.

So the second story happened to me while I was mentoring with Muses Code JS. And it's an amazing organization. There are workshops for women across Australia. And after one of the events, it was just mentors sitting around and talking about what brings people to mentorship. Why some people mentor and some people don't.

And I think at the end, aligned on a very interesting idea that generally people who had successful careers in tech and overcame some challenges in their careers as we all did, you can split them into two buckets. And the first bucket is, I had it hard.

I want everyone to have it this hard. But then there is a second bucket which is, I had it hard. I don't want it to be this hard for people coming after me. And if I can summarize this talk in like one sentence, it would be be in the second bucket.

Be in the second bucket. The question should be not how do we preserve all the difficulty that we struggled with. The question should be, how do we make it less hard for anyone else? And let's talk about what's actually hard. Because writing code is not hard.

And it is quite funny because when you mentor junior engineers and they come on board and they're all so excited, they're like, I want to write code. Where do I write this code? And you're like, no, no, no, no, no, no. Writing code is the last thing that you do. Here are the 75 things that you need to think about before you write any code.

So all of those 75 things, that's the hard stuff. Waking up at 2AM because your production is on fire, that is hard. Observability and alerts, building the systems that tell you what went wrong, why it went wrong, at what time it went wrong, and maybe even like self recovers. What a miracle. That's very, very hard.

Security, thinking about all the threats, all the things that can go wrong, protecting yourselves from attacks from inside, from outside, from all the crazy stuff that's happening. This is very hard. Governance and maintenance, all the enterprise requirements, data handling, systems that will protect themselves and protect your product.

This is the hard part. Writing code was never that hard to begin with. So and we already built all of this. If you have a product right now, it has some observability. It has some security. It has some rules in it. But hopefully, we didn't build observability to feel very smart.

We didn't build security to gatekeep our internal teams. We didn't build them because we wanted to, because they're hard. No one really wants to do hard things. We built them because we wanted to protect the product that we built. And after you build them, you understand that it's not really like obstacles that you put on someone else's path.

It's just your infra. That's what you have as a level of protection. And we already do this. I'm going to tell you another story. That's from like the beginning of my career. It's very embarrassing. But I was working as a deployment lead. And we were deploying our product to App Store every week.

And to my defense, it was 11PM. So I pushed out a new version of our product with an analytics key pointing to staging environment. So for a week, all the analytics from production went to staging. It was a complete mess. Product people couldn't figure anything out.

They had like manually notched stuff. Luckily for me, it was a very good and friendly environment. So the only consequence that I suffered, I had a three d printed Pui emoji on my desk for a month. So everyone had an idea that the best failure was mine for this month. But if you zoom out and think about it, it's a very simple problem to fix.

Right? Anyone can go and write a script that just checks your environment and miss much of your analytics keys. You can even have a script and, oh my god, automatically change those environment variables. Miracle. But no one ever did that. Because it was always something that's so nice to have. But one day, when we have more engineering, when we Never happened.

So when we bring juniors on board now, hopefully, we don't say, here is the code base. Good luck. We usually explain stuff to them, and then we build protection levels so they can show their brilliance in this little magical sandbox that we built for them. And we already know how to build those sandboxes.

We know how to write end to end tests. Writing end to end tests with AI, I love it. I never had end to end test coverage to the numbers that I have now. Sometimes I even just run it in headed mode so I can see how it presses all the buttons. Look, I have strange hobbies. What can I say?

Deployment protections, you always have it. Like, what was it? Like, maybe it was minimum two PR reviews on every PR. Maybe it was no direct pushes to production. Maybe it was key management specificities. It may change the shape now that you don't want to do manual peer reviews, but you already know what's needed. You already know what good looks like.

So we protect our juniors and our teams by building infrastructure. We protect them not by gatekeeping knowledge and saying, no, you cannot do this. And that's the mindset. We ask ourselves, what can go wrong? And how do we make it very hard to do wrong things?

How do we make it very easy to do the right things? And we automate those protections. It is same infrastructure. It's just different audience. You thought about your adorable juniors coming on board knowing absolutely nothing because their software engineering degree.

I mean, it's very theoretical. Let's go with that. And you empower them. You teach them. And you help them to show their brilliance. Maybe there is a bit of a change. Maybe before you see a PR from a junior and you go and comment and you try to make sure that they understand what's happening. And maybe now we just go and write a Claude skill for that. So now they cannot make this mistake.

Claude will scream at them. And that's where we get into building guardrails with Claude. Side note, that was like the funniest part of me helping my two startups. Because I could just sit down and ask myself, how do I download all the things that I know and transform it into empty files? And the idea was just to have all of this set up, AI harness, to help people when I'm not there.

Because I don't want to be on call for two startups. I am crazy. But you can think about it, analyze it, and then transform it, and make it a part of your AI harness. You can have a script that checks your test coverage. And then you can have your MD skill that just checks that your coverage is not enough, and then proposes, here is what's missing.

Here are the files that's not covered. Here is the logic that it's maybe worth covering. Do you want me to write those tests for you, adorable product manager? Environment promotion. Check for environment variables so you don't deploy your own key to production. Verify your checklists. Non technical founders cannot deploy their own key to production anymore. Everybody wins.

Branching NPR standards, oh, that's so amazing. I had to like sit down and think, what's the ideal branching strategy? And then I wrote a skill around it, and now everyone follows my branching strategy. It's so cool. And versioning. I have an agent that just updates a version for me or remind me to update a version, and it always tells me, do you want to update major or minor?

And I'm telling my startup founders, if it tells you to update major, call me. Something changed very dramatically. I need to know about it. Deploy safety. Create a skill that manages deployments. Maybe you'll create a skill that will roll back. I haven't tried this yet. I want to try this one because this will be very cool. You already know how to do this.

And you always wanted to have it. That's what makes me so excited about freeing up the engineering time a bit. So you can think about those things. So you can build safe environments for your people. You can help them to work better. And also you can enforce some stuff that you just think is a good practice. Each skill that you work on answers what could go wrong, how do we make it impossible.

And it is there. And I'm not saying it will always work, but juniors also don't always work. Let's be honest. So we already know how to do all of this. We spent years building this as an industry. We were just building it for our little engineers. And now we include other people in this sandbox group that we really want to support and help.

The tooling changes, but the infra stays the same. Stop thinking non technical people cannot call it too risky. Start thinking what guardrails do they need. How do I automate all of this? Stop gatekeeping gatekeeping knowledge. Start building infrastructure. And it is a real win.

Like, I find it so amazing that now a designer that's unhappy with the position of a button can just go and move this button. Because if they require an engineer to move this button, as a leader and a manager, I won't hear an end of it. It will be like, I they asked, I moved the buttons, whole last print, all I did was just moving buttons, it's so boring.

Designers love moving buttons. Allow designers to move buttons, please. Founders can test an idea without waiting for an engineering resource. They want to add another page to landing and see if it gives them more leads. Please go do so. Add another page to landing. Product person can experiment. And it's not because it's easy now.

Just because we, as leaders, made an effort to make it safe. And things are going to go wrong from time to time. But have you ever had a production incident? Honestly, like production? False sometimes. Sometimes you have incidents.

You know what to do. Look, if your first production incident will be introduced by AI slop, I'm very happy for you. But I had production incidents for fifteen years, long before there was AI Slope. And I'm going to continue to have them because things go wrong. And your AI harness hopefully lives on top of your preexisting infra all the protection levels that you always wanted to have.

You have your own call if you don't talk to me. You have your old box. You already have a system. You just need to extend the system a bit and think about this system a bit deeper. And you have time for this now. This is what's magical. Another thing, this is just my experience, and I might be completely wrong. But what I found talking to nontechnical founders is that when they talk about experimentation and building things, they're very visual.

No founder ever came to me and said, Inge, want to add indexes to our database. They always want to add the page, add the website, move the buttons, add the video, do very, very visual things. And it is a good thing. Like, again, it highly depends on what your people want because it defines what level of protection you have to give them.

But I've seen amazing things happening. And it is up to you to define how big your sandbox is. Maybe you don't have to have a MonaRepo. Oh my god, I said this out loud. But maybe you need to separate your front end from back end. Maybe your sandbox is just your front end. And each time they want to add an API end point, they have to talk to you.

Or maybe there is a skill because you know how a good end point looks like, and now you're just enforcing everyone to write those end points in a very specific way. Maybe you start small. Maybe you grow it over time. Maybe you iterate on cloth skills endlessly, which is what I do, and that's where I get my fun.

But ask yourself, what if? How many brilliant people in your organization have ideas but cannot execute on them? What will happen if they stop waiting for engineering capacity?

If you help them to experiment and build safely and yes, there is a price. There is a price to it. It is priced generally in terms of compliance, security, but that's on you. They're not supposed to know about those things anyway. This shift that I'm encouraging you to make, it is not about lowering standards. It's about raising the floor.

It is about giving those opportunities to other people in your organization that now can deliver and can work on a product. You already know how to do this. Hopefully, each time you hire a junior, you thought about this. You thought about helping them to grow. You thought about helping them to deliver.

And that's the mindset that you bring back when you talk about nontechnical people. You're just applying the same thinking to everyone else. And again, this is what I deeply believe, is that you don't have to reinvent the wheel. It is still code.

It is still product. It is still deployments. It is still rollbacks. You already know everything that should be there. In your career, be very honest with yourself. How many corners you had to cut? How many amazing things that make production safe you didn't build because there was no time?

Here is the time. Here is the time for you to find your passion again. Build things that help your engineering team, your product team, your design team, your support team. Whoever wants to participate in the delivery of this product, you can empower them to do so. And we already know what good looks like because that's what expected that's in your job description.

If you are a technical leader, you're supposed to know what good looks like. And this is my message to you. Empower some people. Enable them to do good. I really believe that every organization has brilliant people. Because if you think your people are not brilliant, you're doing something wrong. Again, come and talk to me afterwards.

But empower them. Make sure that they're experimenting safely, giving you time to build the things that you always wanted to build. And I know it's maybe overly optimistic, but I really like what's happening in terms of giving people tools that were not available to them before. I'm very interested in seeing what they are going to build, but I was always passionate about mentorship.

I always wanted to see more new people in the industry building cool shit. Help them. And that's the corgi, so that's the end of the presentation. Thank you so much.

Inger, that was fantastic. Thank you for sharing that, little journey with us. I'm curious. With, the teams that you've been working with, what do you think was the kind of, like, the greatest holy crap moment, like, that these, you know, founders or whatever, nontechnical people, had this realization that actually something was now within their power.

They were empowered to actually be able to do something for the first time after being kind of blocked previously, maybe in their other roles as well.

I have a funny story about that. But when I started working with one of the founders, I just introduced her to a Clot Code, like command line, the engineering list of them all. It was like, that's how you type commands. And she started talking to Claude. And she looks at me. She's like, Inka, am I a real engineer now?

I was like, oh, sweetie. Where do we start? But it's very interesting. I don't know. It sort of ignites my passion for the industry again. Just seeing people discovering all the cool stuff that we can do. And they never understood this cool stuff. And now there is a way for them to understand it.

But, yeah, look, I'm very optimistic about that side of the industry. I think we're going to see some amazing products.

Yeah. I I completely agree. I mean, I certainly as a engineer working inside a science business that's having exactly that same experience that you sort of described, you know, and, yes, I have had a research scientist say, oh, I'm a programmer now. I'm like, no. You're not. Stick with the chemistry. But, you know, it's, you know, it's fascinating to see how people's minds are being rewired in kinda almost real time a little bit, from an organizational standpoint, you know, to see new opportunities around what's possible, I think. You know?

And and I imagine, like, within your world, you're kinda seeing that kinda play out pretty pretty actively.

There is another side of it that I think about a lot nowadays. It's just I was saw my engineering career as struggling not to lose my ability to talk to normal people. Because when you're surrounded by engineers all the time, your brain starts to sort of switch and work in a different way.

Not in a bad way. It's just the lingo changes. And I was always worried about losing the ability to talk to norm it's one of the reasons that I started mentoring. Because I was like, I have to be able to explain deeply technical stuff to people that don't understand what I'm talking about. And I think that's where language models show that it's possible.

And they can understand concepts on the level that's available to them. As long as they have support and they can reach out to me and say, says kill. What does it mean? Like, it's killing the process. You're fine. But, yeah, it's it's very cool.

Yeah. I mean, it's amazing how LLMs in particular are it's almost like a a bridge into new language for for in every domain. You know? Again, sort of, you know, speaking from my experience as an engineer in a science business, you know, I don't understand the science. Right? You know? And so I have to ask, like, you know, what's an IPAM?

You know? And get Claude to explain that to me, and then I can ask, you know, further questions. And I think that that it goes both ways. Right? It's kinda you know, a lot of the domains in business are pretty technical, and, you know, people are able to bridge into those spaces much more effectively. And more communication across our organizations is only a good thing.

Right? You know? And are you seeing like, with the mentoring and, you know, the work that you're doing more broadly, are you seeing new types of people come into this space? Like, are they feeling more empowered and kind of more keen to kinda have a go at something from from, you know, what you've seen in the past?

I'm going to say the first thing that came to my mind. Don't judge me. I see a lot more unbroken people.

Right. Interesting.

And in a good way. Like, they're just so full of ideas and enthusiasm. And when they have an idea, they don't think about there are 75 compliance point that we have to run about it. And it's inspiring. But they also think about those obstacles in a different way. Because for them, they're so full of this energy of like, can finally make things happen that it seems a lot less dramatic to them than to me.

Because also, I've done it so many times.

Mhmm.

And it's their first time and you look at them like, oh, dear summer child. The journey that you're on is amazing.

No. That's so true. And I mean, I think there's an element in there as well where, you know, for such a long period of time, technology broadly has been dominated by the big enterprise players, you know, whether that's big tech or also, you know, just people like our fintechs and kinda, you know, just hoovering up all of that kinda capability out of the market. And so your ability as someone in the startup world to actually execute on a thing, you gotta go and get a whole bunch of money, and then you gotta find a whole bunch of people, you know, all that sort of stuff.

The barriers to entry were so high, even for a small start up. And I love that idea that you said about raising the floor. It's like now, you know, maybe we're about to kinda enter this new era of small business creation again, which I think potentially could only be a good thing.

I also think about this in terms of people get a bit anxious about their jobs now, about their knowledge. And I hope it came through in my presentation. Your knowledge is valuable. Your knowledge is still very, very valuable. And that's what you should use. You should use it to empower other people to do the less valuable part of your job anyway.

Because writing code was never the main part of your job. And bring the knowledge, bring everything that you've seen, bring your experience, and empower other people to start on this journey.