“People don’t need a PhD in your product to use it.”
For Anoop, simplicity is not a design preference, but a competitive advantage. From early platform shifts at Citrix to modern SaaS products, he has seen the same pattern repeat: tools that reduce friction consistently outperform those that add complexity.
“The software industry isn’t complex because the problems are complex.”
Anoop argues that much of today’s software complexity is self-inflicted. Over-engineering, layered abstractions, and unnecessary automation often make systems harder to operate, scale, and secure than they need to be.
“AI is going to produce a lot more software.”
As generative AI lowers the cost of writing code, the volume of software will grow exponentially. That shift makes testing and quality engineering more critical, not less. According to Anoop, AI doesn’t eliminate testing; it amplifies the need for it.
“Smart engineers don’t write that much code. They fix code.”
While AI can generate functional software quickly, production-ready systems still require experienced engineers to interpret outputs, refine architectures, and ensure long-term maintainability.
“If you automate everything, you often lose intelligence.”
Anoop cautions against blindly adopting agentic architectures. AI excels in non-deterministic problem spaces, but forcing intelligence into deterministic systems often introduces fragility rather than resilience.
Host: Lucas Hendrich, CTO at Forte Group
Guest: Anoop Tripathi, CTO at Sauce Labs
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.
I'm here with Anoop Tripathi, CTO of Sauce Labs. It's an honor to have you with us.
Anoop Tripathi: Good to see you again, Lucas. How are you doing?
Lucas Hendrich: Very well.
Lucas Hendrich: I'm going to jump right into a moment in your career that I find pretty interesting. Everyone remembers the Zoom moment of the pandemic; maybe for you that moment was different. You were at Citrix when GoToMeeting was spun out as Zoom hit the market. There was fierce competition, Citrix was losing ground to Azure in virtual desktops, and you were shifting from a product role to more of an infrastructure and security role. A lot of change, and I'm assuming the pandemic was starting, if not in full effect. How did that shape your thinking later? What did you learn, particularly about product pivots?
Anoop Tripathi: If I recall correctly, that wasn't really during or close to the pandemic, but it was still a very interesting time in the industry.
I joined Citrix as it was unifying its business units. It had four main business units, and the shareholders and board had put them together because there was synergy in the market, and our customers saw it too. But when customers bought products, it felt like buying from four different companies. They'd get upset: "I bought all these products because I thought they worked together — that's the vision we're heading toward."
GoToMeeting was part of that unified vision. Look at what Microsoft and Google offer today: Teams, or Hangouts and chat in Google. That's where the vision for GoToMeeting was headed. Then there was ShareFile for content collaboration; over time, you can see that Google Drive and Microsoft OneDrive have filled that space. And there was infrastructure: desktop and app virtualization, where we were pretty much the leader, while VMware was the main player on the server side. Then networking tied it all together: XenServer, the hypervisor; NetScaler, the load balancer; and the secure remote access solution.
We were doing great, and it was an interesting learning journey for me. As lead architect and product manager, my role was to bring it all together. We started with the low-hanging fruit, Citrix Workspace Suite, which packaged everything together and made it easier to install.
Anoop Tripathi: One interesting lesson was that you have to make sure the messaging is exactly right. Citrix sold through a huge reseller base. We introduced this — "It's now so easy to install; it used to take you weeks" — and resellers were almost getting up to leave the room. One got really upset and said, "You're taking away my livelihood."
They made money from POCs. Back then, proofs of concept were paid. Whether or not Citrix got selected or the customer proceeded, resellers made a lot of money. And we'd made the whole process simple because we were trying to disrupt and move to the cloud and SaaS. It was a time of cloud and SaaS-ification.
Then a private equity firm took a stake in Citrix and decided the parts were worth more than the whole. So it was interesting to watch Citrix gradually split into different companies.
Anoop Tripathi: Microsoft was both a good partner and an emerging competitor, but we saw them more as a partner then, because desktop and app virtualization was mostly Windows-based. Microsoft and Citrix have been longtime partners, and still are, but at that time the partnership was very close. Every couple of years, a rumor would float around that Microsoft was going to acquire Citrix. It never happened, but that was the level of synergy.
In my opinion, Citrix and VMware should have been the top cloud players. They somehow missed the mark, and Amazon became the first cloud infrastructure vendor. There was a time — and I think it's still true — when almost 98% of US healthcare companies used Citrix for virtualized infrastructure and secure access. It was really, really secure.
This is where the innovator's dilemma comes into play. When you're an incumbent, it's very hard to pivot. We did make some acquisitions in hyperconverged infrastructure, but we never really saw that vision through at Citrix.
Lucas Hendrich: I got the timing wrong — I was thinking of the Zoom adoption during the pandemic. I should remember better, because I was fortunate enough to buy Zoom before then. But from a product point of view, Zoom was about customer delight and ease of use. All things considered, I feel Zoom hasn't kept up its initial momentum. What was it like having a competitor that was so easy to use? With GoToMeeting, it was always a challenge for first-time users. You'd wait five minutes while someone joined: "Oh, I have to install it."
Anoop Tripathi: Very true. Cisco WebEx, Citrix's GoTo solutions, and GoToMeeting were the industry leaders at that point. Then BlueJeans came in, then Zoom, and it was all about simplicity.
Lucas Hendrich: I'd forgotten about BlueJeans.
Anoop Tripathi: It's all about simplicity: how easy it is to install and use. That's what disruption looks like, and now it's a trend — a given. Don't even think about building fat applications. As I say, you're standing on the shoulders of giants, so you look taller than the giants themselves. You use all the cloud and SaaS infrastructure out there, and it has to be easy to use.
Anoop Tripathi: I'm a big believer in user interface and user experience design, and I learned that very early in my career at 3Com. We acquired a company called NBX in the IP PBX space, I'd say in the mid-to-late '90s. If I remember correctly, it was founded by a group of MIT dropouts.
With traditional PBXs, technicians and linemen had to come, patch things, and lay out wires, even to your desk. Sometimes it took three or four days just to get a phone working. NBX ran on Layer 2 with Power over Ethernet in those days. You'd plug in the server box, which had a chassis with a card to connect to the phone line, put two phones on two different desks, and boom — they powered up. One showed extension 100, the other extension 101. Pick one up, dial the other, and you're talking. Keep going, and you can set up the whole office. I physically set up an office for the entire company in about 10 or 20 minutes.
That was the simplicity of the interface, and it sold like hotcakes because it was a big disruptor. I've seen it time and again with user interfaces.
We saw something very similar during the pandemic, when I was at Automation Anywhere. We talked about time to value. We'd take prospects and customers through how quickly you could build a drag-and-drop automation. In the RPA world, in under five minutes you could scrape a site like Nasdaq's, create an Excel sheet with the day's top five winners, and then place an order through your Fidelity account. People would say, "Wow, you can do that?" Obviously you'd use it in a more enterprise setting.
I always tell people to pay very close attention to ease of use. As I sometimes say, people shouldn't need a PhD in your product to use it. It should be simple.
Lucas Hendrich: There's a theme there, and I'm going to put a pin in it, because it relates to a question about AI. We can't have a podcast without talking about AI at some point.
Anoop Tripathi: I love AI. I'm a big fan and could talk about it day and night. I'm drinking the Kool-Aid.
Lucas Hendrich: In my experience, most people I speak to on this podcast have some origin story. As a CTO, it's impossible to be deep in every technology and domain, so we're all a bit generalist. But there's usually one area where we've gone deep and know it inside out, usually from solving some hard engineering problem hands-on. We had the CTO of Louis Vuitton on talking about the first time he had to configure a switch. Before you were a CTO — as an individual contributor or team lead — what's your origin story? When did you have to go deep on something hard that taught you something going forward?
Anoop Tripathi: Over my career I've had many I could talk about. But the area you're describing — networking and security — has always been near and dear to me.
We went through a big transition when circuit-switched voice became packet-switched voice. Voice over IP came into play, and combining VoIP and networking created unified enterprise systems. During that transition, I became an architect for the first time, and it was important to me to know the breadth of the technology.
So I decided to read every single RFC. I think there were about 3,000 or 4,000 at the time; the SIP RFC was 3261, I believe. You know the IETF and its RFCs — requests for comments — where the entire TCP/IP stack is published as specifications, whether ICMP, BGP, or anything else. I also read a lot of ITU specs at the same time.
That's something I can always draw strength from. Put me in any networking and security discussion, and I can be dangerous.
Anoop Tripathi: Solving problems has been very interesting. I remember one we solved when I was director of engineering at NETGEAR — our business unit had been acquired by NETGEAR by then; before that I was at Westell. AT&T bought our DSL modems; at that point, pretty much every DSL service provider in the US was our customer.
Every time a software upgrade went out, the modems in the field were bricking. They wouldn't connect; they were useless. Think about it: several million homes had these. If we'd had to recall them, we would have gone bankrupt as a company.
You could program the software through the EEPROM, but during software upgrades the flash-writing utilities were wrong — it was in the bootloader code. AT&T returned boxes of modems: "Take them back and figure it out." Our engineers couldn't find the problem.
I said, "I'll do it." I went to our San Jose lab on a Saturday morning, sat with a JTAG debugger, and looked at every single log — all day Saturday and half of Sunday. By then, I'd found a pattern that let me pinpoint what was causing the problem.
For me, the lesson is: whatever the problem, don't be scared to roll up your sleeves and dig in. There are several stories like that. Once, I had to put a scope on some hardware. In those days, hardware and software teams were separate, and the clock was losing synchronization. I sat with the scope, found what I thought was the problem, and blamed the hardware engineer. Two months later he told me, "Actually, it was a software problem — my bug." That's a different story, but we solved it.
If you ask what area I'm still enamored with, it's the complexity of networking and security protocols, and how they come together to form the backbone of the entire internet and of innovation.
Lucas Hendrich: "Enamored" is a great word. I learned a lot about that area early in my career too. I don't know that we take it for granted, but it's a part of the stack that doesn't get much attention these days, for good reason: if it's well engineered, it runs forever without much attention. But I was thinking what a great case for LLMs that would have been. You'd have gone through those logs in about 30 seconds.
Anoop Tripathi: There you go. I could have captured all the logs automatically and fed them in…
Lucas Hendrich: …and asked, "Tell me what the problem is." Even if it didn't tell you exactly, you'd have saved an awful lot of time getting close.
Lucas Hendrich: That leads to my next question. Sauce Labs combines a couple of disciplines: automation and testing as part of the product itself, and the infrastructure side, which arguably may be the biggest moat against any hyperscaler creating test cases with AI. How do you operate in those two spheres? And am I right that this is one reason Sauce Labs was so intriguing as a place to go?
Anoop Tripathi: You're a smart person, and you're hitting on something interesting, because that's exactly what was going through my mind when I was evaluating options.
Lucas Hendrich: That's too kind. I try to ask naive questions.
Anoop Tripathi: I was considering a few options when I joined Sauce Labs. What appealed to me was that my breadth of technical experience would come into play. There's infrastructure, a lot of security, and virtualization. Networking is huge, because we need to create an extension of the customer's network so they can run tests in a very safe and secure environment.
There's also a lot of mobile device management, which I had the pleasure of working on at Citrix, for example. We manage devices because we provide shared device infrastructure for mobile app and virtual app testing. And on top of that, we want to build complete automation.
Anoop Tripathi: I also felt it was the right time in the industry, which is where AI comes in. With AI, I felt this industry was ripe for disruption in both directions: it can disrupt, and it can be disrupted. If we do the right thing, we'll disrupt this industry. If we don't, someone else will disrupt us and the entire industry.
Our current moat is our virtualized infrastructure: how we create and manage devices and let customers run tests at scale across all kinds of device and software combinations — OS versions, form factors, and so on. Say you're a big bank or a big retailer, and you want your app to work on some grandma's old phone that hasn't been upgraded in forever, with a very large font size. You could build and maintain a fleet of such devices yourself. But over time it gets harder to find those devices, and even if you find one, you won't find the right software, because many vendors don't let you downgrade.
So that's definitely a moat for us. But the way I see it, AI is disrupting the software development industry, which means it's disrupting software testing, which means many of our customers are being disrupted. So we have to be on that disruption journey alongside them.
Lucas Hendrich: Absolutely. Now the AI question, with a big caveat: I feel we're at a moment where it's really hard to make definitive statements.
Anoop Tripathi: Isn't that always the case in this industry?
Lucas Hendrich: I think it's particularly acute right now. Given that, where do you currently see AI use cases being overvalued, and where are they undervalued, with much more value to be created? That could apply anywhere in the software development lifecycle or in what you're doing at Sauce Labs.
Anoop Tripathi: In the software development lifecycle, there are a few leading use cases where things have become much easier. One really astonished me, almost two years ago, using just the ChatGPT web interface.
We had Python code written by three engineers over nine months, while the rest of the team worked in Java. I thought, "Why keep one small piece of code in Python? Let's rewrite it in Java." We planned to hire Java engineers to do it, and the Python engineers were going to be asked to leave the organization.
One of them was an interesting character. He was a Python expert who knew a little Java. I asked him, "Do you want to try using ChatGPT to see if you can convert it from Python to Java?" In two and a half days he had a proof of concept working, and by the end of the week the entire thing was done. Nine months of work by three engineers, translated from Python to Java.
It's language translation, if you think about it, and it's great. If you have old legacy code to upgrade, there are use cases where it really works well.
Anoop Tripathi: But not everything can be done with AI. Where the industry is right now — and over time it could become a doomsday scenario for software development — you need a lot of senior people to take AI output, especially in software development, and make it production quality, because fixing that software is really hard.
Writing a simple app and showing off, "I built a small mobile app," is easy. That's not what the real software industry is about. In the software industry, smart engineers don't write that much code. They're fixing code.
Lucas Hendrich: You have to be economical about it. The more you write, the more you have to maintain.
Anoop Tripathi: So I'd say that even from an architecture point of view, it's still a good assistant. It hasn't reached the point where humans are assisting AI. That's where I see the vision heading. I keep telling people that someday AI will disrupt so much that we'll be the assistants to AI, rather than AI assisting us. I believe it's possible and will happen. But right now it's the reverse, so you have to be careful as an architect.
I once had an architect on my team whom I kept pushing for requirements for a particular feature. He was dragging his feet, and when he finally delivered, I understood why: he wasn't competent to write requirements in that area. Out of curiosity, I described the problem to AI, and within about two minutes I had requirements better than a week's worth of work from my architect. Was it 100% there? No. Did it need refinement? Yes. But in that sense, a junior architect is lost there, just as a junior programmer is lost in that industry.
Anoop Tripathi: On the software development side, my vision for Sauce Labs is to be the testing company for all the enterprise software in the world. That's where software companies are heading: they don't want as much QA.
You've seen how the terminology evolved. It used to be just "QA," not even QA engineer. Then it became QA engineer, then software development engineer in test. Now everybody's an engineer, whether in test, development, infrastructure, or platform. Over time, people are saying, "We don't even need software development engineers in test; everybody should be the same." That's also a trend.
With all that happening, we want to be that company, using AI tools. My vision: you write the application, and Sauce takes it from there. It examines your code and your requirements, writes the right test cases, runs them on our infrastructure, and tells you what to fix — even suggesting potential fixes you can review and approve over time.
Then we send it to alpha and beta trials through our mobile app distribution platform. When you like it and want to release it, you release it to production. We have excellent error and crash reporting software that monitors real production, and with AI we can send fixes back to you. Code maintenance is where the software industry spends most of its time, and I think we can disrupt it and take it over. That's my vision.
Lucas Hendrich: So you're going to be the receptor of all the vibe coding experiments.
Anoop Tripathi: Oh yes. I say AI is a boon for an industry like ours. Whether you call it vibe coding or agentic coding, it's going to produce software exponentially. And if there's more software, guess what? You need to test it more. That's where we come in.
The good thing right now — and this is more tongue-in-cheek — is that a lot of the generated code is buggy. The buggier the code, the more use for testing.
Lucas Hendrich: That's like telling kids to eat lots of candy so you can fix their teeth.
No, I know what you're saying. I think it expands both ends of the spectrum. It expands the amount of software that has to be tested. And when people say software engineers have a target on their backs because AI will replace them — yes, you can spin up apps very quickly now, whether you're vibe coding or you're an engineer who doesn't want to spend time setting up another project. You can get a full-stack interface running very quickly.
But the amount and value of data being generated is also increasing exponentially, so the engineering around that data will remain an ongoing need. That's how we're positioning ourselves too: at the forefront of data engineering. Those are a couple of perspectives that I think should comfort anyone entering the job market: the needs are increasing.
Lucas Hendrich: However, to your point, there's a trajectory problem, and it's a challenge for the generation entering the market now that we maybe didn't face. When I entered the market, demand was so high that there was always an opportunity to learn on the job, and you learned by solving problems. It's frightening that this fundamental learning-by-solving is being factored out of the equation. How do you think about that when building your organization and the next generation of engineers at Sauce Labs?
Anoop Tripathi: I think you're right about that. But look at it this way: people said the same thing when calculators came along — that our mathematical abilities would go away. Go back to the abacus: "Don't use devices." There are studies saying that people using LLMs and AI tools show reduced brain function because we're offloading the thinking.
I see it differently. I believe every wave of industrialization and automation has pushed us humans to strive for bigger and better things. We're good, and we're very resilient. I'm not scared of AI. I see it as an opportunity for us to evolve — maybe genetically, physically, or mentally — to the next level. It will force us to. I believe in the human race in that sense.
My advice to young people is to embrace and learn these tools, because they're here to stay. My entire team uses various AI tools as part of their day-to-day work.
In interviews, we used to ask, "How did you solve the problem?" Now we tell engineers up front, "If you want to use AI to solve the problem, that's OK." In the end, we want the problem solved, and we'd expect you to use AI on the job, so why not in the interview too? So learning AI tools is very important. But I'd say it will be a while before we reach the self-driving, self-cleaning, self-servicing car equivalent in this industry. And as you mentioned, data volumes will be tremendous, and with more data comes more work and more opportunity.
Lucas Hendrich: Interesting. This is where the pin comes out. You mentioned RPA. Something that often comes up on this podcast: if you put intelligence on one axis and automation on the other, it's a downward slope. The more you automate, the more you have to rein in the intelligence. How do you build an architecture — an agentic architecture, as everyone's calling it — with that in mind? In my own tinkering, there's a tendency to over-engineer with that tool set, just to say you're using the tools, when a first-principles look might say we don't need so much in the mix. What are your thoughts?
Anoop Tripathi: That's a good one, because it's my pet peeve. I say this about the entire software industry: its size isn't because we're solving complex problems, but because of self-created complexity.
Think about why our industry exists. A lot of it would exist anyway, but a big share of use cases exist because of legacy systems. If you upgraded or rewrote that on-prem software running on some old Windows version, you wouldn't need to screen-scrape something that doesn't even have APIs — or, today, an MCP interface — just to automate it.
Here's a naive, simple example. There was a time when you had to call T-Mobile and ask them to port your number. Now the whole process is automated; nothing needs to be done. The more you do that, the more you remove complexity from the process. And the more deterministic you make it, the less you need AI, because AI excels at the less deterministic parts.
Anoop Tripathi: In the agentic world, there's a concept we used in RPA that still exists: human-bot collaboration. Programmatic bots did the work alongside humans. No complex enterprise process could be completed by bots alone, and having humans do it all was too costly, so you needed human-bot collaboration. We called it HBC.
Now there are bots, and there are AI bots coming into the agentic world, and it's expanding. I was at a meetup the other day where someone said the mythical 1000x developer is becoming real — a developer 1,000 times more productive. There are cases of developers who've written up to 100 agents to assist them in their day-to-day work.
Take code review as an example. One agent handles beautification and linting. Another looks for all the security issues. You can create a whole set of specific, targeted agents to assist you as a code reviewer. The agentic world is really exploding, and the agents obviously need to be orchestrated, which is why almost everyone is trying to build an orchestration platform.
I think this is a good time for the workload automation and robotic process automation industries to stay relevant in this new world — maybe more relevant because of this explosion. It's creating more opportunities, and when you add a lot more data, it just gets more and more interesting.
Lucas Hendrich: It does. But there may be limits. There are tasks humans like doing, and I think the next frontier is product-market fit in a world where something could be done by AI, but there's a premium on humans doing it because humans enjoy it.
Anoop Tripathi: I've always thought about that, even back when we talked about the automation industry. We'd say, "We're automating so humans can do less mundane work." But I'd say there could be things humans like doing even if they're mundane. Sometimes we like doing things that are nonsensical or repetitive, and certain people love it. And there are also intellectuals who can't stand doing the same thing twice. Both kinds of people exist on this planet. I think you're right.
Anoop Tripathi: That leads to something interesting I was thinking about on one of my walks: combining AI with the humanoid robots coming into the industry, and what they could disrupt. If you really think about it, the sky's the limit.
If my humanoid is good, I don't need a dishwasher. Why pay for one? Let it wash the dishes in the sink. Why would I need a washing machine, or an expensive Roomba-type vacuum? I could buy a cheap $25 or $30 vacuum from Walmart and let it go around my entire house.
Lucas Hendrich: If it takes 12 hours to mow a lawn, you could use an old-fashioned manual mower.
Anoop Tripathi: I made the same point and took it to the next level: why do I need a lawnmower at all? Give it old-fashioned shears and let it do the job.
Lucas Hendrich: That's true.
Anoop Tripathi: Think about what smartphones did to so many things — cameras, flashlights. Bank branches, too: you deposit checks digitally now. So there's a lot of disruption ahead. It's a very exciting time, and I'm really excited to see how these disruptions play out.
Lucas Hendrich: I totally agree. Part of the next disruption — and it's an unknown unknown, because I don't think anyone's hit it yet — is the form factor for how we interact with technology. We use phones for all kinds of things we never conceived of in the flip-phone era. Right now, how we interact with intelligence is limited, mostly to text. There's voice, but I don't think it's perfected, and people aren't 100% comfortable with it yet. It'll be really interesting to see what form factors emerge over the next 20 or 30 years. The phone is such a staple now, but it certainly wasn't when we began our careers.
Anoop Tripathi: I agree. Think about keyboards. There have been many attempts to get rid of them, but so far we haven't, whether it's a physical keyboard or a virtual one on your phone. The keyboard was just a way to get the industry started. Once we disrupt it, the way we interact with technology will definitely change.
Humans — and the entire animal kingdom — work through audiovisual and touch interfaces. We've forced ourselves to be stuck with a screen, a keyboard, and a mouse, or a touchscreen that gives you essentially the same thing. Once that's disrupted, things will change, and I think AI will make it happen. It will also level the playing field in the technology industry, because everyone will be able to play.
Lucas Hendrich: I agree. Right now, LLMs are the focus. That's where the hyperscalers are, and many people learning about AI think that's what AI is. They may not know what's now called classical AI — machine learning, regression, concepts that are, in some cases, 200 years old and form part of AI's corpus; anything predictive. It's an interesting time for all of that to shake out.
Part of what's interesting is how we're treating language itself, and that gets philosophical quickly. The example I always use — apologies to anyone who's heard it — is that I felt great writing a business plan in about 30 seconds. It produced about 60 pages, including market research and competitive analysis.
I send that plan to a bunch of investors, they feed it to their LLMs, and they get some kernel out of it: essentially a yes or no, or follow-up questions. So it's a communication loop with language in the middle, but it's just compression and expansion of ideas, over and over.
I wonder how we'll transmit ideas one, two, or three decades from now. What shorthand might we arrive at, when we've already asked the first-, second-, and third-order questions? Or if I vibe-code something in 30 seconds, now I have an interface, and I'm already thinking, "That's great for an MVP. What's next?" That acceleration is what really intrigues me.
Anoop Tripathi: And I'm sure we'll evolve to capitalize on it. That's why I said we'll evolve as an organism and put it to use.
Looking back at my own AI journey: in 1991 or 1992 — I'm dating myself — I took a course on advanced remote sensing systems, capturing and classifying satellite imagery. The concept then was artificial neural networks, and I published a paper in an international remote sensing journal out of Japan. It was about classifying satellite images — is it an animal, and what kind? A forest, a tree, and what kind? — using artificial neural networks with backpropagation of errors and all that.
After that, nothing much happened, so a lot of people say this AI thing keeps coming and going. Yes, it was around, and I'm sure long before that too; as a student, I was building on those ideas. In my last four companies, we launched some form of AI product. But I feel this is the ideal time for AI.
To your point about compression and decompression of ideas, I think it will go to the next level. In some areas, especially manufacturing, AI is augmenting humans today, but it will reverse, and humans will augment AI. Some factories are already moving toward lights-out manufacturing, where the floor has no lights and everything is still automated, because robots are doing the work. There, we'll be augmenting and supporting AI-based systems. In other areas, we'll still manage and use the AI.
I don't think that in the next 15 to 20 years we'll reach the point people hype, where AI takes over and humanity is taken away. I don't think that will ever happen. It will just make things more and more interesting and take on things we don't need to do, so we do something else. We'll use new parts of the brain. They say we only use some percentage of the human brain. Maybe this forces us to evolve, use parts we've never used, and become the super-creatures we can become.
Lucas Hendrich: On the question of what's overvalued and undervalued: with our teams, we try to model ROI for different tasks based on cognition. That's really the key. Human cognition is incredibly hard to replicate, because we don't really understand it. It's not mechanistic, strictly speaking. It is, in a chemical, biological, wet way, but we still don't know enough about it.
To your point, that's fascinating. Humans like routines. Routines are great for meditation; that's essentially what meditation is — a mantra, breathing — which gives you a certain baseline of comfort and emotional and mental stability. But if we can remove all the other toil and focus on the hard cognitive tasks the human brain is suited for — or, put differently, not quite optimized for yet, but could be if we focus and evolve toward it — then AI will enable better human cognition. That will be very interesting to see.
Anoop Tripathi: I think you've put it very well. AI will take us to the next level cognitively.
Lucas Hendrich: I'm curious where it goes — whether we push forward, or just have agents do everything while we sit back drinking milkshakes.
Anoop Tripathi: The good thing about humankind is that we have all kinds of people. Some will get restless and want to take it to the next level, and some will say, "I don't care. Give me my cigar and my wine."
Lucas Hendrich: One of the things that drew me to technology in the first place was laziness. Why do we automate?
Anoop Tripathi: I always used to say the best automation comes from the laziest people. Absolutely. I remember hating typing when I started in software. All my scripts started as one-letter scripts — D, E, F — and I memorized them all. I'd just type "d," which meant "do it for me." It was actually a script to sudo into the system: from sudo, the whole command became a "do it" script, and then I shortened it to "d." I'm root now on that system.
Lucas Hendrich: That's funny, and it makes me think about interfaces. Lately I've been playing with Claude Code, and I love that it's a command-line interface. You run it in a terminal, and for some reason I'd rather work there than anywhere else. It takes me back to the days of running scripts in the terminal and automating things.
Lucas Hendrich: Anoop, it's been wonderful having you here. Thank you so much.
Anoop Tripathi: Thank you for having me. It was a pleasure talking to you.
Lucas Hendrich: 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.