LH: Your engineering team moves fast. What enables that?
GK: We’ve built our culture around trust. Everyone owns their work, from idea to production. We don’t require code reviews unless someone asks for it - we use Loom walkthroughs instead. If I can see your intent and the results, that’s enough.
LH: How did you and your co-founder align technically?
GK: We didn’t, at first. When we decided to work together, I told him: we’re scrapping everything. The codebase, the team. That’s a hard thing to hear after you’ve maxed out credit cards and built something. But he said yes. That trust is the foundation of everything we’ve built since.
LH: What do you look for in engineers?
GK: I ask one question: Do you consider yourself lucky? Everyone we’ve hired has said yes, and when you ask why, they talk about great projects, great teams, great experiences. That’s not luck. That’s someone who’s collaborative, consistent, and open to growth.
GK: Tools like Loom help us communicate intent without adding process. We optimize for fewer meetings and more maker time. If we’re trusting people to ship, we need to give them the space and structure to do it well.
LH: What’s your advice for early-stage technical founders?
GK: Every shortcut has a cost. The tech debt you take on in year one can be a tax you pay in year five. That doesn’t mean overengineering, it means thinking long-term, even when you’re moving fast.
Host: Lucas Hendrich, CTO at Forte Group
Guest: Gajus Kuizinas, co-founder and CTO at Contra
Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers dig into the challenges and opportunities leaders face every day at the intersection of business and innovation. I'm your host, Lucas Hendrich, CTO at Forte Group.
It's a great delight to have Gajus Kuizinas with us today to talk about his experience as a CTO and the platform he's working on. In an interesting turn of events, this is the first time a listener has reached out directly to be on the podcast, which I think is wonderful. I hope it happens again, whether through comments on the podcast or by reaching out to me directly.
Gajus, great to have you here. By way of introduction, tell me how you found us and what drew you to be on the podcast — a little promotion for the podcast.
Gajus Kuizinas: I always try to stay at the edge of everything that's happening, and the best way to do that is to follow the leaders and what they talk about. Podcasts are my channel for that. That's what drew me to yours.
Lucas Hendrich: That's a huge compliment. I'll accept it with a caveat: the people I invite on the podcast are the leaders, in some ways. I feel like I'm cheating a bit, because I get all these great ideas essentially for free and meet a lot of interesting people. The rate of change right now is such that unless you're constantly in touch and talking through ideas, it's impossible to keep pace.
Gajus Kuizinas: Absolutely.
Lucas Hendrich: With that said, I want to go right to some of the questions you sent over, because they're great starting points. I'll start with one further down the list.
You mentioned an unconventional interview process for hiring engineers, and the platform you're building, Contra, is also a talent marketplace, so there's that interaction between talent and the people seeking it. First, tell me about that unconventional process. Then, how does that philosophy inform product decisions on a talent marketplace?
Gajus Kuizinas: There are several layers. Before we even get to the interview, what you do beforehand shapes it. Especially for the early hires, I did a lot of work before the interview to build a profile of the person: who they are and what they've done.
Even the channels we used for the first hires were very untraditional. I knew exactly the kind of person I wanted as our first hire and exactly the technology stack I wanted them to know, which was a pretty rare stack at the time.
Lucas Hendrich: What was the stack?
Gajus Kuizinas: The component unique to us was Facebook's Relay framework, which almost no one used at the time. We also used Flow, another Facebook project, and GraphQL was just starting to pick up. Those three made it pretty hard to find people who were both excited about and knowledgeable in the stack.
I knew the stack well — I'd been coding with it since the day it launched. So I'd go to Stack Overflow and ask questions I knew the answers to, but that I also knew only the kind of people I wanted to hire could answer. I was fishing for people capable of answering them.
When they answered, I'd engage them in debate in the comments: "I'm not sure this is the correct answer." The purpose was to understand how they behave. Do they confront me? Are they nice? Do they lecture me? Do they politely bring me up to speed on the technology? I knew that if we were building on this stack, we'd need people who could be great leaders from day zero and strong technically.
Gajus Kuizinas: That's the warm-up — that's how we got the first people in. I'd literally message them in the comments: "Give me your phone number; I'm going to call you." And they would, and I'd call them. The first hire said, "This has never happened. What's going on?"
I'd pitch the whole thing: "We just raised money. I want you on my team, for these reasons." I'd share my background. I have a pretty strong open source background, so they'd usually recognize me from that. The first guy told me, "I literally accepted an offer a few days ago." I said, "Call them. You're not taking it. You're joining us."
That's one story, but fundamentally that was the approach for every hire. You identify the people you really want based on the attributes you've defined, and you research them thoroughly before they enter the interview process.
Gajus Kuizinas: Once someone is in the interview process, the most common feedback I get at the end is, "I expected more technical questions. Why aren't you asking me any?" The answer is that by then I already have full confidence in their technical skills. At that point I'm trying to understand whether we'll get along, whether they understand the expectations, and whether they're excited about the company's mission.
And I always ask one question, to this day — so if you're watching this, it's a cheat code. I ask, "Do you consider yourself lucky?" To this day, we haven't hired a single person who said no.
Why? When you ask people who say they're lucky to elaborate, they say things like: "I've had a great career, worked on great projects, and been surrounded by great people. I've been invited to all these functions and contributed to amazing things." That's not luck. That's you putting in the effort to be a great person, contributor, and coworker.
It's still hard to explain to our HR team when we're refining our interview processes. "Why do we have this question? What does it check about the candidate?" And I have to go through the whole spiel.
Lucas Hendrich: That's a great question, and I like the philosophy behind it. It reflects optimism too. If you ask, "Do you feel lucky?" and someone says, "Absolutely not," you might have a complainer, or someone without the same sense of agency. And I think agency shows up strongly in people who feel they've been blessed somehow. That's great.
Lucas Hendrich: So the technical vetting essentially comes from seeing how people engage with problems being solved publicly. The obvious next question: as people use LLMs more for their problem-solving, how is that affecting your search? Sites like Stack Overflow, for example.
Gajus Kuizinas: I'm not sure how much of this is AI-related. Obviously our interviewing process has evolved as we've hired more people. We've embedded some honeypots to identify people using AI, and they filter out a surprising number. Sometimes we even wonder whether it's actually AI or the person is just bad at following instructions.
One example: we'll ask candidates to answer question X, Y, or Z, and in brackets it says, "If you're a human, skip this question." About 50% of applicants fill in a long answer anyway, and you automatically dismiss them. We had at least one case where a person filled it in by hand — accidents happen.
When people do reach the interview, what I've noticed more than ever is that despite our outlining very high expectations, many struggle with basic technology questions. I always try to end interviews on a positive note, and there are cases where I have to add a dozen extra questions just to get to something positive.
Occasionally you find a diamond in the rough. We hired an engineer, Daniel, literally last week. He powered through every question, added extra flavor, and expressed excitement about ownership and all those things. So I don't know that AI has affected our hiring beyond adding more noise. Fundamentally, you're still scouting for the same attributes as before.
Lucas Hendrich: I'm curious whether the way you find talent informs any product decisions — whether, as a talent marketplace, you can provide that at scale to your customers.
Gajus Kuizinas: One thing that transfers directly from our interviews to our community is what we see in the most successful people. First, Contra is a fairly complicated product: it's a marketplace and a social, professional network.
In a traditional talent marketplace, you show up — even with no background — see jobs, bid on them, and hopefully underbid someone so they accept your offer. Contra is fundamentally different, because your main job isn't applying to jobs but building your identity. You do that by building your portfolio, collecting recommendations, and interacting with others in the community. You want to demonstrate that you function well in this community and embed yourself in it.
To the point about luck: the most successful people lean into that process. They don't ask, "Where's my job? Where do I apply?" They ask, "Who do I connect with? Who do I learn from? Who do I engage? Who do I invite?" That became integral to how the product functions; the expectations of people carry over from it.
Lucas Hendrich: That's interesting, and there are obvious benefits. It puts a premium on quality, which makes the price conversation secondary. Although I'm sure buyers still want the best price point, and your sellers are working toward that too.
Gajus Kuizinas: I think the freelance market is in an interesting place, and that's the foundation of why I co-founded this company with Ben. Think about the arc — I'm talking about my own arc as an IT professional. I was born in Lithuania and didn't really have access to US markets. I was figuring out how to get into the scene without knowing the ropes.
I'd go to oDesk, Freelancer.com, or whatever sites existed at the time and bid on projects. I did the whole dance. I built a client list, and I developed confidence that I knew how to act professionally and deliver projects.
Then, a few years in, the question arises: Why am I paying this platform a commission? Why 20%? Why can't I invite my clients to my birthday or engage with them directly? It made me feel undervalued. It didn't feel like I was building my own identity. So I left the platform and went independent, eventually building an agency, then startups. That was the journey.
That's the thesis behind the business. Many professionals who freelance entered through those platforms. They built conviction in their ability to be great, and then they left because they wanted to own their brand. So there's a gap in the market: the most talented people don't have a place to call home. Could we build something that attracts the highest-quality people, who are proud to associate themselves with the brand? Today, the best designers in the industry are very proud to be associated with Contra.
Gajus Kuizinas: The flip side is that left quadrant — the early freelancer journey. That's where many people are still learning the ropes. Clients come there and pay lower rates, because they expect it to be hit or miss. So you get a downward spiral of weaker talent and low pay. The incentives are wrong: more weak talent, lower pay.
We've been doing this for almost six years, and the hardest problem has been reshaping the perception of what it means to be independent. We literally changed the word from "freelancer" to "independent," because "freelancer" carries so many negative associations.
Our independents earn a lot and are extremely talented, and as a result great companies come to hire through us. We have everything from small independents to startups to companies as large as Anduril, Canva, Webflow, Framer, and many others.
Lucas Hendrich: It's interesting, because you're taking us through the journey of a participant on the platform, whereas I think of it from the buy side.
Gajus Kuizinas: Yes.
Lucas Hendrich: What am I most interested in? I want proof — something authentic that someone has done. When I interview, one of my top requests is, "Walk me through something you built." I don't want to hear about a team you were on that did something. It doesn't have to be a huge platform. I want you to take me through a discrete problem you solved by building something. Contra solves that as well.
Gajus Kuizinas: That's exactly it. That's why I said Contra is, first, a marketplace and, second, a professional network. On the marketplace side, we challenge the whole construct of commissions and the client relationship.
On the professional network side, we're challenging the idea that LinkedIn's fundamental building block of identity is flawed: your role, and the years from when to when. I don't care how many years you were at a company. Tell me what you actually did. Our building block is the individual project — the specific things you worked on, the people you collaborated with, and their backing up your contributions.
Lucas Hendrich: You've seen the Darth Vader meme, I'm sure.
Gajus Kuizinas: Which one?
Lucas Hendrich: I'll probably paraphrase it wrong, but there's Darth Vader's LinkedIn profile…
Gajus Kuizinas: OK, yes.
Lucas Hendrich: …and the reality. On the profile it's "assistant to the Empire," when it was probably "managed a multi-planetary campaign."
Gajus Kuizinas: That's exactly what we're fixing.
Lucas Hendrich: One last question on the platform itself. Are you finding AI-generated profiles? Has AI slop made its way onto the platform, and how do you screen for it? I'm sure it's easy to address, but at scale…
Gajus Kuizinas: Not as much, though maybe partly because I'm at the end of that chain and less exposed to it. But you mentioned something interesting: scale. We started the company on the principle of doing things that don't scale, and we still do them.
Many people would be shocked to know that every single piece of content ever posted on our platform is manually reviewed and rated by people with good taste. That's a lot of work.
Lucas Hendrich: Yes.
Gajus Kuizinas: We're talking about millions of pieces individually ranked on quality, relevance, aesthetic taste, and so on. That's the manual curation part. Then the algorithm rewards people with distribution based on what all those contributions add up to.
Lucas Hendrich: Interesting. So it's an artisanal approach, in some ways.
Gajus Kuizinas: And we're scaling it now, trying to figure out what growth means. We're at a million and a half users. What does it mean to grow to 10 million, or 100 million? I think there will be a point where doing things that don't scale starts to hurt us.
One thing we're experimenting with right now is a concept we call the taste test. Imagine our community feed works on the same principle as LinkedIn, Facebook, or Instagram, but the primitives you post are unique to us.
One content type is the taste test: you post two variations of a design, and people say which one they prefer. It feels like a fun toy — a feedback mechanism, but also a toy. Behind the scenes, though, it builds each person's taste profile: whose taste on the platform are you aligned with?
We feed all those data points into a discovery mechanism. If you say you like Lucas and John on the platform, you can find a third person aligned with their taste. That becomes more algorithmic, driven by your behavior on the platform — less our curation and more a product of what the community is doing.
Lucas Hendrich: Let's get to another question you sent over; I'll paraphrase it. At some point in building the platform, you found you had to start from scratch. That's a dilemma many CTOs face at different points. Maybe you're just getting adoption and taking on tech debt to reach the next phase — a user milestone, investment, what have you. Or someone buys your platform — yay — and then you have to integrate different code bases. You're always facing the question of when to pull the plug on the patient and build something entirely new. I'm really curious about that journey.
Gajus Kuizinas: My situation was slightly different, because in some ways — maybe this is my ego talking — I didn't have a choice. I joined my co-founder about a year into his figuring out what the product was. He already had a prototype, built by an agency in Ukraine; he'd actually fly there, work with them, and come back.
We met in San Francisco. I had a product of my own, a social network and data graph for engineers. When we started working together, I was exposed to his code base, and one of the first things I told him was, "If we work together, we're going to scrap all of this." More than a year of his work and investment, straight into the bin. And the team would need to be replaced too.
That's an incredibly hard thing to do. I don't want to tell his side of the story, but he'd fully committed — maxing out credit cards, the whole startup journey — to get to that point. So it was a hard conversation. But he said yes.
Gajus Kuizinas: There were many reasons. First, I believe that as a CTO you want to be exceptionally good at the technology stack you choose. The prototype was built with PHP, Vue, Laravel, and a few other technologies, and that just wasn't my core competence. Then there was the language barrier and the time zone difficulty.
The biggest reason for me personally was that they were already a team we'd effectively be hiring. However much I liked them, you'd have a cluster of people who'd co-worked together, in their own boat, with something being built on top of them. That fundamentally creates a lot of friction.
We started during COVID, so from the beginning we were forced to figure out the team's composition. As a principle, we wanted everyone distributed, not in clusters. As soon as you have clusters, communication breaks down. When everyone is distributed, everyone has to get on calls the same way and use the same tools for decision-making and collaboration. That was one of our guiding principles.
Gajus Kuizinas: When we started on the code base, my only real principle was that everything would change, and we probably wouldn't be able to control that much. Ideally, I make bets on technologies I really believe in. Apart from Flow, everything persists — it's the same stack to this day. We dropped Flow after about our third hire, who told me, "What are we doing here?"
The one thing that should stay as constant as possible is the database schema. We made very strong rules about how we design it and how we think through any additions, and we made it almost impossible to remove things intentionally. In my previous companies, changes to the underlying data model caused a huge number of bugs and bottlenecks.
Everything else, you can be scrappy with: mock up, prototype, ship. But the underlying data model is where we write an RFC, sit down, think through future scenarios, and try to future-proof it as much as possible.
Lucas Hendrich: It also reflects your operating model. The only thing that would justify changing it would be a pivot — "I'm creating a new company now."
Gajus Kuizinas: That's fundamentally true. My thesis is that the CEO has their own model of the world, and the CTO's responsibility is to have the best actual data model in the database.
Lucas Hendrich: You have to codify that model.
Gajus Kuizinas: Yes. The data model and the database, in a way, define how the business functions, and it's very hard to change them.
Lucas Hendrich: Someone once said — I forget who — and I totally agree, that the software you write on top of a data model is actually a reflection of beliefs. It's an interesting way to think about it, and I like it.
Lucas Hendrich: So you changed stacks. What were some of the mistakes in generation one that you were able to fix?
Gajus Kuizinas: I don't think I consciously thought of them as mistakes at the time, but I had some guiding principles. What helped in this case is that we weren't trying to innovate on the product so much as on the business model. Step one was removing the commission. Step two was reaching parity with our predecessors, because that's the market expectation. That was actually the hardest part. It took us about four years to reach parity with the others.
Lucas Hendrich: Pure functional parity — the table stakes for this kind of platform?
Gajus Kuizinas: Yes. Expectations are high, especially with bigger clients. Payment rails alone took us about four years to support. We were the first to support crypto, plus PayPal, Airwallex, ACH, and SEPA. We met the Airbnb team somewhere in the middle of our journey, and they were impressed by everything we'd built to that point. What were we talking about?
Lucas Hendrich: It was interesting. There's an underlying principle there that sounds counterintuitive: table stakes are the things customers perceive as easy, and you need to knock them out of the park. If you innovate elsewhere but don't do the easy things well, the friction won't even let customers get that far.
Gajus Kuizinas: Yes. One product-strategy compromise is drawing a hard line: we're not innovating on these things. Any time we said, "Let's do the invoicing process this new way, with this quirk," we realized we were innovating on the wrong problem. Clients have expectations.
Lucas Hendrich: Unless you're going to beat the market at invoicing.
Gajus Kuizinas: Then that's where you'd compete. But we were going after a very different segment, and we knew what was further down the road. We call this moment in a company "post-parity clarity": we've reached parity, so we take a deep breath…
Lucas Hendrich: Escape velocity. You're in orbit now.
Gajus Kuizinas: …and ask, what now? Now we can start innovating. I distinctly remember the first couple of projects, because the team came in really excited: "This feels unfamiliar. We're really breaking new ground here."
Gajus Kuizinas: As for principles, decoupling was one of the core ones. The database is separate, the GraphQL schema is separate, and the application is separate. They need to be decoupled so you can develop them independently, because, as we discussed, the database is in lockdown. GraphQL was essential for creating a model that can adapt to business requirements at the application layer — the contract between the application and the database. The application itself was always in constant flux.
Lucas Hendrich: I think there's a team-morale component to having a solid platform. It's the "aha" moment when something works well, even at the start — you create a function and it passes. Then you can easily build on it. If you accumulate tech debt in that area, it affects morale and developer happiness over time.
Gajus Kuizinas: That takes us back to the beginning, and I imagine it's common, though I may be at the extreme end: the early CEO-CTO tension between co-founders. The CEO just wants to ship something: get it to customers and have them pay us. My job as CTO was to internalize what we were building, the whole roadmap ahead, and all the complexity it would bring, and think strategically: what can we do short term, and what do we need to invest in to succeed long term?
That's one reason we haven't had to do a rewrite since. In the early days of resource allocation, there was a bucket called DX that got 30%. I distinctly remember the conversation: "What the hell is DX?" Developer experience. We invested heavily in it from day one.
To this day, when people join — I mentioned Daniel earlier — one of their first comments after a couple of days is that everything feels like magic. "I make a change, and it propagates through every part of the application. I get feedback and reports. I understand the impact. I get full test coverage." That doesn't happen organically. It's a constant push for that balance.
Gajus Kuizinas: At this point, we have thorough end-to-end automation of everything, including test coverage, deployments, and preview environments. And we trust the team so much that we've done something unconventional: we've abandoned code reviews.
Code reviews still exist for new people and as an opt-in — you can ask someone to review. Otherwise, we have a GitHub label called "self-review." Adding it essentially grants approval. As part of that, it checks whether you've recorded a Loom video. In the Loom, you do two things: walk through the reasoning behind the code changes, and show a smoke test of the changes you've deployed. If you've done that, I trust you.
Lucas Hendrich: What a great idea. I'm thinking of one platform I worked on that went down a very strange path, largely because technology wasn't the company's core business, so they lacked the mental model for building a scalable platform. They had a great platform that evolved over time, but when it was time to re-architect, they went down a certain path. Doing the archaeology on it always came down to, "Someone made that decision, but they're no longer here."
So what a great artifact. Otherwise, you read a comment or some documentation and you're at the mercy of whatever someone wrote. I'm a very auditory learner; sometimes I don't understand something until I talk it through. What a great way to disseminate knowledge and capture decision-making — whether for a small commit or, I assume, a major architecture change. I wonder how many people start recording, get halfway through, and say, "Oh, wait a minute…"
Gajus Kuizinas: It actually happens constantly. Internally we call this Loom-driven development; I've been trying to coin the term for several years. Loom is not a sponsor of this podcast.
Lucas Hendrich: Not yet.
Gajus Kuizinas: The biggest difference between then and now: when we started, recording videos of yourself talking was very unfamiliar to many people, and everyone went through a learning curve. The first complaint I got when I introduced the process was, "This PR is taking me two hours to submit." Why? "Because I keep re-recording the video. I record something, watch it back, find an issue, and have to redo it." Then they'd find something else, or a hiccup, and record again.
Over time, it got very efficient. Now you see videos go, "And this is — oops," then a pause, then it resumes. Pause, resume.
Lucas Hendrich: What a great hack.
Lucas Hendrich: That leads to a topic we can't avoid. I won't ask about AI in the product, because everyone's talking about that — not that it isn't interesting. For practitioners, I think what's more interesting is AI in the software development lifecycle. You've done some vibe coding, and so have I.
I want to understand how it's affected you. What have you learned? What's worked? What do you recommend? I'm guessing you hire people senior enough to have tried things. Some may be set in their ways or reluctant to adopt, but they're not vibe coding as their first experience writing code.
Take me through how you've experimented, what's working, and your tool chain these days. I hate saying "AI" because it's so broad, but what IDE and what tooling are you using, with developer experience being so important to you?
Gajus Kuizinas: We ran roughly three experiments where we set out with the intention of vibe coding something. One was tiny, so we can dismiss it. One involved the database schema — foreshadowing. And the third was a project deliberately isolated from our code base, done by an external team we contracted specifically to experiment with vibe coding. It didn't start that way, but that's what it evolved into: what can we achieve with this?
I still remember the first time I reviewed the code. Keep in mind, this was the early days of vibe coding, and we all went through a learning curve. I read the handover, looked at the repository and all the documentation, and thought, "Wow, this person is so thorough." It wasn't a problem we typically solve; it was a different domain. Looking through the functions, there were so many comments. I thought, "Impressive. They put a lot of effort into making sure we can take this over successfully."
Then we took over the project and started working on it. We realized the comments described what the code did, rather than the reasoning behind it, which is why you normally add comments. And the documentation was really there to guide the AI's development principles rather than to explain anything.
Once we'd validated the idea and wanted to ship it to users, we needed to optimize it because of performance issues and so on. I think we legitimately spent twice the original project duration cleaning everything up, removing the slop, and understanding the architectural foundation. To this day, I think we should have started from a clean repository and not invested in that one at all. By the time we finished, we'd removed probably — I don't want to exaggerate — something like 70% of the code base, because it was full of hacky ways of achieving things the platform already provided.
That was our first experience of realizing vibe coding might not be as productive as everyone around us was saying.
Gajus Kuizinas: The second time, for the next part of that project, we used it to make database schema changes. I remember reviewing the code and thinking it was fairly well thought through, with a lot of smart decisions in the schema. I approved it. Long story short, a month in, you realize it makes no sense.
The fundamental learning is that you can't delegate the strategy and the thinking. No one knows the business requirements better than you, especially people who've worked on the code base for years and understand its ins and outs.
Maybe there's a world where you can vibe code things that add value, but definitely not unsupervised. You have to invest almost as much effort in thinking through what's being proposed to you. In many ways, I think that's harder than writing the code for people who are engineers by trade, because it's not what they do day to day. That's our learning with vibe coding.
That's not to say vibe coding has no use cases. It's a great tool for MVPs, for communicating concepts, and for getting something out there. We actually see clients on our platform approaching independents with something vibe coded and saying, "I want this coded properly." That's a common twist. But especially for mature organizations, I'm always a bit skeptical when I hear big numbers.
Gajus Kuizinas: As for day-to-day tooling, everyone uses Cursor. Personally, the main Cursor feature I use is autocomplete.
Lucas Hendrich: Yes.
Gajus Kuizinas: Autocomplete is great — a nice utility. I don't think I've used the chat once. I'm actually not sure I should even be paying for Cursor.
Lucas Hendrich: I feel that's becoming the consensus. The one defensible use case, I think, is code you know you'll throw away. Then there's no reason not to — when you just need to throw spaghetti at the wall, or need a simple web interface to understand what you actually want to build.
For anything else, it's interesting. I've tried to establish principles in my prompts, and no matter how hard I try, the output always seems to blossom outward instead of staying as concise as possible. I don't mean concise comments. I mean avoiding that high-volume sprawl that becomes so much toil to sort through.
Gajus Kuizinas: Definitely.
Gajus Kuizinas: We still use AI in other ways, just not in the traditional vibe coding sense. For example, for any database change, we ask people to take the change, put it into ChatGPT or Claude or whatever they use, and have it challenge them. Not to add things, but to ask: Did you miss anything? Did you miss any gaps? We find that very useful for reducing back-and-forth friction. That's definitely a major win.
Adoption hasn't been as great with this next one, but conceptually I think there's really something there. Tools like CodeRabbit let me describe linting rules in plain language for things that are hard to define using an AST. That's a huge value-add. I'm not sure why adoption hasn't happened — maybe it just takes time.
We have a few rules that would be very hard, if not impossible, to express as actual code checks, but LLMs catch them pretty well. That's especially useful when you're changing concepts or approaches in a code base and don't want an old pattern to recur. You have a linting rule that says, "We're not doing this anymore; adopt this pattern instead."
Lucas Hendrich: It's interesting, because there's something in how LLMs are architected and trained. The history of AI starts with rule-based expert systems, and it's almost as if we're coming full circle. To rein in the LLM, you have to establish rules. Your starting point is something that's essentially an expert in everything — or can at least pretend to be.
Gajus Kuizinas: Very convincingly.
Lucas Hendrich: Very convincingly. I don't know if I can say this, but BS doesn't fly when… And then we expect it to act autonomously. When we get to agents, we have guardrails defined by prompts, and those prompts are hard-coded.
Gajus Kuizinas: Yes.
Lucas Hendrich: So the real gains are in automation, not necessarily intelligence. I know this topic has been beaten to death, but there may be an argument for why humanity needs AGI, and I'm still not convinced of the why.
The utility I actually want is someone who can learn a task, help me with it, and remember it when they come back to work the next day. Having the whole corpus of human knowledge doesn't really help me; somehow it moves us off the mark. This may be beyond our scope, and much smarter people than me are thinking about it, but it makes me wonder why we even care about the path to AGI. If this is how we're building these models — and I'm only talking about frontier large language models — it's smart enough for me.
Gajus Kuizinas: I tend to agree. In terms of code, I think the fundamental flaw is this: to your point, it's a great generalist. Say its output is 80% there. As a single addition, that's great; I can accept 20% drift. The problem is that when you stack layers — thousands of commits — that 80% compounds into 50%-plus error across the entire code base.
Lucas Hendrich: I like thinking about it that way. There's some error rate when you go from assembly to a compiled language, but it's always a reduction. You're always adding another nine, not amplifying error. That amplification seems unavoidable, as if it's at the core of the architecture itself.
Gajus Kuizinas: And you fundamentally lose ownership of the code base. The first time I realized we needed hard lines around AI development was when I decided to review a random PR for no particular reason. I looked at the code and thought, "This doesn't really make sense to me."
Historically, when I see something that doesn't make sense, my gut says, "Someone spent time thinking about this. They clearly had a reason. I should approach it as if I don't know, learn, and maybe ask them to add a comment." With AI, I had a few conversations where I asked, "Why is it done this way?" and got a long pause followed by, "I don't really know."
When you lose that accountability and responsibility, you're no longer familiar with your own code base. The biggest value of our team — most of our engineers have been with us four-plus years — is that they know every corner of the code base.
Lucas Hendrich: And that intangible tribal knowledge is what forms intuition.
Gajus Kuizinas: Exactly.
Lucas Hendrich: Last question: what are the next big things for Contra? Anything interesting on the roadmap you can share?
Gajus Kuizinas: Let me take a step back. AI is getting really good at many things. But as we discussed earlier, if I give you a design today and ask whether it's good or bad, no AI in the world can tell you.
We're trying to figure out where collaboration between AI and humans happens. How can the most creative people influence AI outputs so they align with what's relevant to people today? That's an extremely difficult problem. We're collaborating with AI research labs to provide mechanisms for collecting that feedback in a way that lets them guide their models.
Lucas Hendrich: Is it too naive to say you want to take the best possible developer experience and extend it to creatives? You're not giving AI the creative task. You start with the creative, who then uses AI but maintains the human thread through it.
Gajus Kuizinas: That's exactly it.
Lucas Hendrich: That's interesting; I like that. This was so much fun. Thank you so much for joining.
Gajus Kuizinas: I really appreciate it, Lucas. Thank you.
Lucas Hendrich: Thank you. That's it for this episode. Join us next time for more real-world conversations between technology leaders. And if you liked what you heard, subscribe to CTO to CTO. See you soon.