Ramiro Berrelleza was about eight when computers began making their case. His father had them at the office in Guadalajara, Mexico, and the boy visited, played games and typed into a word processor. These were modest encounters with the future, more blinking cursor than thunderclap. Yet something stuck: here was a machine that turned instructions into things.
In high school, he took the one optional programming class. Berrelleza has said that he never thought of himself as conventionally artistic. Software offered another medium. Through technology, he realized, he could create. When university required a decision, computer science at Tecnológico de Monterrey felt less like a choice than the next line in a program already running.
His university work already mixed software with physical consequences. He co-authored a 2007 paper on EchoTech, a modular system designed to monitor water consumption and identify leaks or pollution. Another publication examined the use of Microsoft's Project Hoshimi as a way to introduce programming to beginners. One project pointed toward systems in the world; the other asked how more people might learn to command them. Both concerns would reappear in his later work, where infrastructure and access are never far apart.
The contest that enlarged the map
Near the end of university, Microsoft brought its Imagine Cup student engineering competition to campus. Berrelleza entered with three teammates. Their product concept won at school, then at Mexico's national qualifier. Microsoft flew the team to New Delhi for the international round.
They did not win the final. The useful prize was perspective. Berrelleza had barely traveled outside Mexico, and suddenly he was discussing technology alongside students from around the world. He later described the experience in simple terms: “Tech can truly be a global equalizer.” A local idea could travel. So could its builder.
“Through technology, I could create things and build exciting stuff.”Ramiro Berrelleza on discovering programming
Microsoft invited him to interview. He had reservations. His sympathies were with open source and the free-software movement, while Microsoft then stood in a very different cultural postcode. He accepted, moved to the United States and landed on the organization that would become Azure. He imagined the move might last a year.
Instead, the role became an early education in cloud computing before the term became a default setting for the industry. Even as a junior engineer, he watched experienced colleagues reason about software at enormous scale. The problems - modern programming practices, developer efficiency, distributed services - would follow him through the rest of his career.
Computer science, research and Imagine Cup
Software engineering on the road to Azure
Fifth employee, close to product and customers
Principal engineer, then architect
Co-founder and CEO
Five people and a startup education
Several Microsoft friends left to start ElasticBox. Once the young company had financing, Berrelleza followed them to the Bay Area as employee number five. The contrast with Microsoft was immediate. A vast company might design for millions; a startup could sit with a handful of customers, ship an answer, listen and change it.
At ElasticBox he built software with Pablo Chico de Guzman and became friends with Ramon Lamana. All three stayed around the borderland between developer tools and cloud computing, even as their careers separated them. Berrelleza eventually went to Atlassian, Chico de Guzman to Docker and Lamana to Google.
The jobs were respectable. The trio missed building together. So they quit first and settled on the exact product second, a maneuver best attempted with trusted collaborators and some savings. Berrelleza moved to Madrid, where the others lived, and they spent roughly three months cycling through ideas. There was friendship, summer and code. There were also years of accumulated irritation with how long it took developers to begin useful work.
The prototype became Okteto. A mentor urged them to apply to Y Combinator, and the company entered its Winter 2019 batch. YC helped with the mechanics of a startup, but Berrelleza has emphasized a less technical lesson: founders often impose ceilings on themselves before the market has had a chance to object.
Okteto's premise was plain enough to draw on a napkin. A developer should be able to summon a preconfigured environment in the cloud, use real services and see changes quickly. The local laptop would no longer need to impersonate a complicated production system. Setup time, configuration drift and “works on my machine” would lose some of their power over the calendar.
Look for the repeated delay that capable people have learned to accept. If every project begins with the same hour of setup and apology, the inconvenience may be a product waiting for a name.
Productivity without the stopwatch
Developer productivity can become a dreary management phrase, often translated into measuring visible motion. Berrelleza approaches it from the workbench. How can developers move quickly and retain the freedom to create? How can a company grant that freedom while preserving security, consistency and cost controls?
This is why the environment matters. A self-service template can encode dependencies, permissions and infrastructure once, rather than asking each engineer to rediscover them. An ephemeral environment can appear for a feature and disappear when its job is done. Preview environments allow colleagues to examine working software, not a description of working software. The reward is a shorter distance between an idea and evidence.
Good infrastructure performs a small vanishing act: the developer notices what they can make, not what they had to configure.
The business found its own evidence. Okteto announced a $15 million Series A led by Two Sigma Ventures in 2022, bringing its publicly reported fundraising to roughly $18 million. The company shifted from an early free cloud service aimed at individual developers toward development-experience automation for teams and platform organizations. The audience grew more institutional; the irritation underneath stayed human.
Berrelleza kept teaching alongside the company-building. He presented a KubeCon + CloudNativeCon Europe case study on bringing chaos engineering to cloud-native developers in 2022. In Guadalajara in 2024, he spoke at CCOSS + KCD about Kubernetes as a platform for platforms. The titles sound densely technical, but their shared question is accessible: how do you give builders sophisticated infrastructure without demanding that each one become its full-time caretaker?
A new colleague needs a desk
Then AI coding agents arrived, energetic interns with no need for lunch and a dangerous appetite for confidence. They could propose code, write tests and refactor services. Yet most operated with a cramped view of reality. A unit test could pass while a network policy, database, queue or neighboring service waited offstage to ruin the celebration.
Berrelleza's recent argument is an extension of the old one. Agents need environments too. Each needs an isolated place with the application's real dependencies and controls. It should be able to run code, inspect behavior, read the feedback and revise its work. If several agents operate at once, the platform must provision, govern, observe and retire those environments without turning a platform team into a switchboard.
In a 2025 essay, he put the direction crisply: “The future isn't one agent. It's fleets of them.” By February 2026, his focus had sharpened around runtime feedback. Better models and clever prompts can improve a suggestion, but software becomes dependable through contact with the system where it must live. Human engineers have always compiled, run, watched, cursed and corrected. Agents need access to the same humbling loop.
There is a pleasing symmetry here. The child at his father's office learned that a computer could convert instructions into visible results. The student in New Delhi learned that software could carry an idea across borders. The engineer at Microsoft learned that cloud systems change the scale of what builders can attempt. Okteto gathers those lessons around a single invitation: here is a real place to try.
Builder, in public
Berrelleza's public trail is unusually practical. His writing includes remote debugging, Kubernetes contexts, Python and .NET tutorials, ephemeral environments and the trust required for AI development. His GitHub profile invites questions about cloud, Go, microservices and startups. It also records one domestic opinion that requires no cluster at all: he likes peanut butter on bananas.
He speaks about technology as an equalizer, but his version of access is concrete. A useful development platform lets a new hire begin without inheriting weeks of folklore. It lets a distributed team share a standard environment. It allows a smaller organization to adopt practices once reserved for infrastructure-rich companies. Inclusion, in this reading, begins when fewer people need secret knowledge merely to participate.
The aspiration is ambitious; the method is procedural. Provision. Run. Observe. Improve. Clean up. Repeat. Berrelleza has spent a career moving the starting line closer to the actual work. Now that some builders are made of software, he is still asking the same courteous question: do they have everything they need to begin?