An AI "Metamorphosis": Transforming into an AI-native company.

New "Becoming AI-native" interview with Rekki's CTO, Borislav Nikolov.

What does it mean to become an AI-native company?

For too many company leaders, I’ve noticed they think this means having your engineers “tab” their way through their coding tasks with a tool like Cursor, for their employees to be able to ask ChatGPT questions of their internal data, and for them to adopt AI vertical tools.

But these things, while important, are all on the surface. To become AI-native, it takes, what one company I’m lucky to work with describes as a full “metamorphosis.”

What follows is an interview I did with Borislav Nikolov, the CTO of Rekki. The transcript for our conversation was 50+ pages, so I did my best to edit for conciseness and clarity. Still, I consider Borislav as AI-native as you can get so in order not to cut some of the nuance out, I am going to publish this in two posts.

As background, Rekki has a marketplace for restaurants and their wholesale suppliers. They deal with thousands of restaurants making thousands of orders every day. This creates a stream of nitty-gritty engineering tasks to glue things together like payments, risk management, and complicated business logic. Every time the operations team had a new need or a tweak to the system, they’d create a task for the engineering team. Until one day Borislav realized: what if I can empower everyone on the team to “solve their own problems?”

I’m not sure what the company of the future looks like once AI fully permeates, but I think we all have something to learn from how Borislav approached this question.

In this post, we get into:

1. The “ah ha” moment of realizing that every single person in the company would soon be able to code, and how this would let him push tasks back to the domain experts in the company and have everyone “solve their own problems”.

2. How this changed his job as CTO from leading a team that executes on tasks to one that creates the internal infrastructure almost like a PaaS provider, where the whole company is full of developers he “can’t trust”.

3. His realization that if an employee can’t do something themselves, it is his fault for not giving them the right primitives.

4. How he pushed the behavior change internally. This started by first, having everyone in the company deeply understand large language models, and then challenging the conditioning everyone had of assuming they couldn’t solve their own problems because they couldn’t code.

In the second post, we’ll explore:

1. Why he still codes two days a week without any help from an LLM.

2. The theory of mind, and reviewing code generated by an LLM.

3. What the future holds as more and more code is written by LLMs.

The “Ah Ha” moment.

“As they say, necessity is the mother of invention.”

Shortly after GPT 3.5 came out, Borislav, was staring down a massive backlog of engineering requests from the company’s operations team. The backlog was daunting, both in its count, and also because each task itself, while potentially trivial from an engineering perspective, required real time to ramp up on the problem before any code could even be written (let alone tested). Then it hit him: literally everyone in Rekki could now write SQL.

“So I was like, look, why can't I just enable the people that are actually asking for the tasks to do the task? If a restaurant orders three times very close together, that's probably a fraud thing. So instead of me making a system that has to check the data, has to have some state, etc., they can just do that themselves… This was the first real moment where I realized that everybody would soon be able to code and solve the tasks in whatever domain they are in.”

This was something that wasn’t possible with other no-code tools he’d tried, because inevitably the no-code platforms were not expressive enough.

“Previously what was always missing and why the low code and no code solution would fall flat was because at some point, it's just not expressive enough. Somebody has to write the code. There is this law of irreducible complexity.” But he realized that if he could give his team the right infrastructure for their code to run somewhere safely, with things like privacy considerations, security, and notifications if there is a problem, he could empower everyone in the company to code and solve their own problems.

Rather than divide the company into developers and non-developers, if everyone could write SQL, Borislav realized that the jump to building automations on a service like Zapier or Make.com was finally possible.

“Now, if we could just make this SQL into API primitive, someone can create the rest of the workflow at Zapier or Make.com, and of course the testing they can do herself by placing orders with a testing restaurant.”

What this meant for Borislav’s role internally, and the infrastructure he set up.

So, his thought was "how can I make it possible for everyone to do their job, without me defining what they can and cannot do? What primitives are needed? How can I make it reliable and as safe as possible?”

By primitives he meant things like load/store/search, turn a SQL query into an API, or SQL query into a trigger that pushes to a webhook when there is new data, monitoring, alerting, etc.

If an employee gets stuck not being able to do something they want, Borislav considers it his fault for not giving them the right primitives.

“I almost think of myself as an internal PaaS provider, the whole company is full of developers that I cannot trust, kind of how AWS engineers think about REKKI's engineers, they have to run our code, but they don't trust any of their users, but at the same time they have to empower us giving us the right primitives to express ourselves and do what we want to do with as little friction as possible… In the future I hope I can empower everyone to use Cursor and just deploy code, but we have a long way to go to make it safe and secure.”

Depending on the company, the primitives will be different. But to Borislav, “the important part is to think of the whole company as people who can truly build anything they put their mind to, and the only limit is you, your attitude, and your infrastructure.”

“You will be surprised how much you can do with a workflow with SQL to API, ChatGPT classifier and few API calls.”

Now, rather than a company divided into developers and non-developers, the company has developers, semi-developers, and a small (~10%) non-developer make-up. Yes, the developers are still needed to unblock or enable the semi-developers to do their jobs, but that work is amortized because the developers are giving the semi-developers the “fishing rod, not the fish”.

How to make this organizational behavior change

I asked Borislav what advice he’d give other companies to make this transition from pre-AI to AI-native.

“If you put a company in front of me and I can ask them one question, it would just be ‘do you understand this technology? Can you use this machine?’” In Borislav’s experience, most people are quick to point out the AI’s limitations – hallucinations, producing bad code. But they haven’t taken the time to truly understand what the machine is and how it works.

Borislav himself studied Andrej Karpathy’s videos and others on LLMs for close to 50 hours until he could back-propagate by hand on pen and paper, and deeply understood “what a plus means and what a multiplication means and what the collapse of the vector space into a token means.” As he said, “it’s a machine we’ve never experienced.” To use it, first understand it. Once he could understand “the way the transformer programs itself to emit the token” and therefore its limitations, he understood how to take full advantage of a LLM to code, and transformed Rekki’s culture to be AI-first.

“You have to understand that by talking to it you're programming it. That's what you're doing.”

At Rekki, Borislav had the entire team watch Karaphy’s Zero to Hero series, as well as a bunch of videos from other teachers like Justin Johnson, Fei-Fei Li, and 3Blue1Brown. They did Learning Fridays where they’d watch lectures together and discuss the content.

Then, he started pushing all the requests back to the teams that had the domain expertise. His default changed from doing the tasks for people, to teaching them how to do it themselves, and making sure that they had the infrastructure that empowered them.

At first, this was hard.

“You have to believe in the capability of your non-tech people. They are conditioned to think they cannot code, to think that only engineers can not solve their technical problems. So the very first step is for you to believe in them. Then the second step is having the infrastructure to support them, and the third is to teach them to solve their problems themselves.”

For example, someone on the operations team needed to get a bunch of data. Borislav could have written a scraper for him that gets the data, parses it, and analyzes it. Instead, he told the employee to download Cursor, and just “type the request in.” “Now, he has 20 scrapers that he just uses nonstop.”

“So again, first believe that non-coders can code, then figure out where the code lives, because that is a massive problem, e.g. how do they deploy and monitor it, make.com, zapier, bolt, their own laptops etc.? And then the real issues with security, PII and GDPR, anonymization, etc. How many outages are you willing to tolerate because ChatGPT wrote a stupid infinitely recursive query?”

The Bigger Picture: AI-Native is a Mindset Shift, Not a Feature List

What Borislav demonstrates so clearly is that becoming AI-native isn't about layering AI features onto existing processes. It requires a fundamental restructuring of how we think about work, capability, and organizational design. This is the "metamorphosis" he references.

Three critical insights emerge from Rekki's transformation:

1. The democratization of technical capability is real and imminent. When everyone can code, the traditional bottlenecks between technical and non-technical teams dissolve. Rekki transformed from an engineering backlog to hundreds of automation workflows built by the people who understand the problems best.

2. Leadership roles fundamentally change. Technical leaders shift from task executors to platform builders. They create secure, reliable primitives that enable domain experts to safely solve their own problems. The parallels to cloud computing's transformation of infrastructure are striking: CTOs become an internal PaaS provider to the whole company rather than gatekeepers.

3. Organizational psychology is the biggest barrier. Both engineers who are used to being the exclusive "problem solvers" and non-technical staff who've been conditioned to believe they "can't code" must undergo significant mental shifts. The limitation isn't the technology - it's our deeply ingrained beliefs about who can do what.

The question for founders isn't whether this transformation happens, but how quickly your organizations adapt. The companies that drive this change aren't just adding AI features - they're fundamentally rethinking what it means to be an organization in the AI era.

More soon.