Ahmed Kamal · Writing

The best engineers are writing less code

2026-09-17T00:00:00.000Z

I asked a room of engineers two questions.

First: who uses AI coding tools every day? Most of the hands went up.

Second: who trusts the output enough to ship it without reviewing? Not a single hand.

That was in April, at Tamara's Sandbox. The same gap shows up in the industry numbers: around 92% of American developers report using AI tools daily, and about 3% report high trust in what comes back. Adoption is nearly total. Trust is still not there.

I think that gap is the most interesting thing happening in software right now. I also think it is not a model problem. It is a process problem, and it closes when you change your mind about what you are actually writing.

Twelve months against twelve years

I have been building data and ML systems for about thirteen years, witnessing how products get built at Careem, Uber, Stream, and now at Hudhud. In the last year, the way my org works changed more than in the twelve years before it.

That is a strong claim, so let me be precise about what changed. It is not that we type less. It is that the artifact we care about moved.

Why vibe coding broke

For a while last year the story was that you could describe an app and receive an app. For a to-do list, that worked. For anything real, it fell apart, and it fell apart in a way worth understanding.

Here is the analogy I keep coming back to. Vibe coding is like compiling C++ down to assembly, deleting the C++, and then trying to maintain the assembly. Everything you needed in order to change the system safely was in the thing you threw away.

Three failures followed from that, and I saw all three.

Context evaporated. You would open a chat, work through a problem, make a dozen decisions, and close the tab. Think about how absurd that is. When humans have a design discussion at a whiteboard, we do not admire it and then wipe the board. We turn it into a design document or an RFC, because that is the contract everyone aligned on. With AI we were wiping the board every single time.

Decisions got delegated that should never have been. Which database. Batch or streaming. Which interface boundaries. The model made those calls confidently, without enough understanding of the business to make them well.

There was no structure to catch any of it. No specs, no tests, no review gates. Just chat text.

So the industry's conclusion, that vibe coding is a bad idea, is correct. The conclusion many people drew next, that the whole thing is hype, is not.

The spec is the source code

The reframe that made everything click for me came out of a conversation after the talk, and it is this: the spec is the source code now, and the programming language is the compiled output.

We have done this before. We wrote assembly, then C, then Java, then Python. At each step we handed more decisions to a compiler and stopped reading its output. You do not review the bytecode your Java compiler produces. You do not read the assembly emitted for Android and again for iOS. You write the source carefully, you test the artifact, and you trust the translation.

English is now becoming the source layer. The RFC, the spec, the success criteria, the constraints you set: that is the code you are writing. The Python that comes out the other side is the build artifact.

Once you accept that, a lot of confusing advice resolves itself:

Context must be versioned, because you version source, not build output.
Reviewing every generated line is like reading disassembly. Sometimes it is the right call. Usually it means you have not written enough source.
Writing a better prompt is not the skill. Writing a better spec is.

Coding the process

What replaces prompting is a process you encode once and reuse.

The shape is the same across the frameworks that have emerged from Google, Amazon, GitHub and others, which tells you something. You write an RFC and you sign it off yourself. You break it into tasks. Independent tasks go to separate agents working in parallel, each in its own branch, each opening a pull request. The rules you would apply to a human contributor apply here: tests pass, linters pass, review gates hold, or the work does not merge.

You are no longer writing the code. You are coding the process by which code gets written.

Some of those frameworks enforce a multi-model review step that is worth calling out, because it maps onto something data people already know. Ensembles beat single models. One model is weak where another is strong. Having a second and third model review every phase is the same instinct as asking two or three colleagues to review something critical, and it costs almost nothing.

What it looked like in practice

Earlier this year I spent a weekend building an internal tool at Hudhud: a catalog for satellite imagery, with a CLI, connections to Trino and Iceberg, tile stitching, and a set of integration tests.

It came to roughly twenty thousand lines. I wrote almost none of them.

That number is not the point, and I want to be careful here, because it is exactly the kind of number that gets quoted as a boast. The point is where my time went. I spent it on the plan and on the validation criteria. Then, once the first version existed, I spent it doing the thing an architect does when reviewing work from a capable team: hunting for corner cases, pulling on things that looked wrong, deciding what to do about them.

Two moments from that weekend are the whole argument.

The projection bug. The system pulled satellite tiles from two different sources, and the agent assumed they shared a projection. They did not. I did not catch that by reading the code. I caught it by looking at the output and seeing that it was wrong. When I pushed back, the model explained why it was fine. I told it that if it were fine, other things would be true that plainly were not. It agreed, and we iterated to a real fix.

The storage decision. We use Alibaba Cloud rather than AWS. I wanted integration tests, and there was no good local emulator for OSS, their object store. I knew OSS implements the same interface as S3, so testing against that was sufficient. That is not a hard decision. It is just one that requires knowing our stack, our constraints, and what "sufficient" means for us. No agent had any way to make it.

Both were decisions, not code. That is the pattern. Intervene at decision points, not inside the build.

The honest counterpoints

If I only told you the good half, I would be doing the thing I dislike about most writing on this subject.

It can make you slower. A controlled study by METR in mid-2025 found experienced open-source developers were about 19% slower using AI tools, while believing they were around 20% faster. Feeling fast and being fast are different measurements. A follow-up with 2026 tooling found roughly 18% faster, so the trend is real, but the first result should keep you cautious.

The detail I find most telling is that a large share of the original participants would not join the second study. Their reason was that they no longer wanted to work without AI at all. That is not a productivity measurement. It is a preference that indicates a strong habit, and it is worth noticing.

Review does not scale. You can generate a hundred times more code. You still have one brain. Nobody meaningfully reviews twenty thousand lines. If you are not going to read it, then your specs, your tests and your gates have to be good enough to carry the weight instead. If they are not, you are not saving time. You are deferring it.

The cognitive debt is real, and it surprised me. In a normal day, the work has natural rest in it. You open a PR, you wait for CI, you get a coffee. In this mode, the easy work is gone and every hour is the hardest part of the job: judgment, debugging, decisions. Eight hours of that is not the same as eight hours of the old thing. I broke my own sleep that weekend, partly from excitement, and I do not think that is a model to hold up.

And it depends entirely on what you are building. An internal tool with an owner sitting next to it is one risk profile. A banking system is another. If you are in a regulated business, nobody is going to let you ship unreviewed generated code, and they are right.

You are still the owner

I lead a team of about sixty people, and there is one rule I repeat when using AI gets discussed. If there is a problem with something you shipped, you own it. Not the AI.

This applies to code, and it applies just as much to the report you generated, or the summary you did not read before forwarding. The tool does not absorb accountability. Nobody has ever blamed a compiler.

So the choice is not whether to trust the system. It is where you put your attention, given that you are accountable either way. If you do not trust it, review it. If you want to review less, then invest in the specs, the criteria and the gates until you have earned the right to. What you cannot do is skip both and hope.

What this means for building here

The reason I care about this beyond my own team is regional.

For the last twenty or thirty years, the binding constraint on building serious technology in this part of the world has been people. Not ideas, not problems worth solving, not capital in recent years. Engineers. Anyone who has tried to staff an ambitious project here knows the feeling of a plan that is correct and unbuildable.

If the cost of turning a good design into working software drops as much as it appears to be dropping, that constraint loosens. That matters more here than it does in places that never had it.

But it only pays out if you bring something to the process. The differentiator is what does not automate: domain knowledge, architectural judgment, taste, and actually understanding the problem. None of that is a smaller ask than before. It is a larger one. Being an architect is a promotion, and promotions come with harder work, not less of it.

Which is why I would put it this way. Lead the AI. Do not let the AI lead you.

The virtual workspace: how AI is shaping the future of remote work

2020-10-09T00:00:00.000Z

Since the start of the pandemic, lots of people have been working outside of their offices and for some of them, this was the first time they have ever experienced it for such a long period.

Definitely, this is the largest experiment of remote work that have been ever conducted and since there was no other option than making it succeed, a lot of companies have done their best to deeply understand the real needs of the business as well as the conditions under which its employees will stay productive.

One of the important needs is to maintain a healthy relationship between different employees either the ones that have to collaborate closely or the ones that just happen to work under the same business group. And one of the big reasons why many teams are still able to work so effectively is that we are relying on the long term relationship that we have built in the pre-covid period.

Now, the big question is how we can make up for the missing real life interactions between people that normally get lost when everyone is working remotely.

For some companies, the solution is to have a hybrid model where teams get to meet from time to time either in the office or through organized outings but in my opinion, this is not the ultimate solution.

Earlier I have written about why I think that COVID is a perfect time for the world to address all the remote work challenges through technology and I still believe in this.

The first problem we need to solve is to replace all these voice conversations with face 2 face video chats. In the end, we are humans and so there is a lot to understand from looking at the other person’s face. That is how we get to trust and feel for each other.

So step one shall be to have everyone on camera that is focused on their faces, definitely not a low-quality video stream that shows a group of people from a bad angle.

Seven Rules of Zoom Meeting Etiquette From the ProsNo more dogs, chips or ‘lurkers’—as video-conferencing becomes a fixture in working life, it’s time to shed the rookie movesThe Wall Street Journal

The challenge here is the reliability of our internet speeds which can sometimes be a blocker, also the head pose, the background, and the lightning can be a challenge.

Many of us have heard about the virtual background feature that zoom has released that smoothly replace your background with a virtual one thanks to deep learning.

photo from https://blog.zoom.us/zoom-virtual-background/

Here’s How Zoom’s Virtual Background Feature WorksDuring the coronavirus pandemic, Zoom has become a favorite video communication platform among companies and organizations whose in-person meetings have been replaced digitally. A primary reason for…AI In Plain English

But the real innovation comes from Nvidia that tackled the last three problems by using GANs. Rather than sending the whole bulky video stream, it just sends data about the key facial points (eyes, nose, mouse). Thanks to GANs, and given this small amount of info, the receiver can easily re-construct the same exact live video of the face with much higher quality while consuming a lot less bandwidth. And additionally, the newly produced video will easily be adjusted to give the perfect pose that ensures natural eye contact between the participants.

From virtual meetings to virtual workspaces

For the longest time, people have been excited about creating a virtual world. A computer-simulated environment where everyone can have their own avatar and simultaneously and independently explore the virtual world, participate in its activities, and communicate with others. And while most of the virtual world environments have been created for entertainment, social, and education purposes like SecondLife, there is still a nice opportunity to leverage fit this to our need for a virtual workspace where everyone can get to meet and interact with others.

Facebook Horizon, photo from https://youtu.be/brd0jPjYPU0

A Virtual reality workspace can even push us to leave the desk and move around while being fully immersed in a VR-based world. Facebook has already developed Horizon as a VR gaming environment but who said that we can’t borrow the same ideas for work?

What if we can mix Deep Learning and VR worlds?

In my opinion, very soon, we could start seeing a virtual workspace where we remote workers can have life-like digital avatars that represent our emotions, interactions, and facial expressions in a way that has never been expressed before.

Still not convinced that this is doable?

Part of this is already a reality! Samsung NEON, a project that aims to build artificial human avatars that look and act exactly like the original characters it simulates was shown recently in CES 2020.

And the other part is already being used. Once I got these thoughts I was curious to see anyone worked on a similar solution and I was blessed and surprised to find that VirBELA, a virtual work-oriented virtual environment which is based on the same gaming engine that powers “Fortnite,” has already hosted an event with more than 200 people!

Additionally, companies started using RecRoom, the famous virtual world game for having some meetings, virtual outings and team events.

photo from @Judith_ARTVR twitter account

photo from @recroom twitter account

In a virtual world, in addition to having more engagement in meetings, trainings and close collaboration, you will be able to have the same office routines you used to have. So whether you want to go to the pantry and have some small talk over lunch, or just some random chat over coffee.

This way we will be able to move the office to the cloud! And rather than choosing between the office or home, we will basically bring all the features of the office to our homes.

Personally, I’m super excited to see how AI and VR will enable us to balance more between work and life. And how this era could drastically change the perception of work and productivity forever!

My reflections on the Careem–Uber deal

2019-03-27T00:00:00.000Z

I still remember when I was very happy to see Souq acquired in 2017 anticipating the potential, this will bring to the region.

Now, after the acquisition of Careem, this will create a ripple effect which will isA change the whole region. It won't just open the door for a lot of new tech startups to grow and flourish and exit on high valuations but many will continue till their IPO.

These 3.1 B$ will massively motivate many people to come to the region to build and innovate new solutions for our problems. We already may have a couple of companies that got millions in funding but surely this will turn on the green light for more and more successes.

Careem has set an example for how to build a successful tech startup in the region and certainly, there are a lot of lessons that will guide a lot of aspiring entrepreneurs towards more similar success stories.

https://www.thenational.ae/business/technology/impact-of-uber-careem-deal-is-impossible-to-overstate-1.841453

How to become a machine learning engineer

2018-08-25T00:00:00.000Z

Recently I posted a job post for a machine learning engineer position in my team @ Careem. I got a lot of questions from people who are curious to know more about the position itself, how to prepare for it and what kind of problems does it face?

Data Science vs Machine Learning Engineering

Let's start with defining the position itself. What is machine learning engineering? Is it a new thing? Does it differ from the so-called sexist job in the 21th century, the data scientist?

When people invented the term (Data Scientist), they were looking for superheros who excel at the following:

via Big Data [sorry] & Data Science: What Does a Data Scientist Do?

1- Acquiring the data, cleaning it, identifying problems and asking the right questions as well as setting the correct measures for different KPIs.

2- Doing necessary statistical analysis to come up with different hypothesis about the solution

3- Using statistical methods to validate the different suggested solutions.

4- At some point, the solution could be more than a mathematical model (equation), it could include some complexity requiring the usage of machine learning. Thus, developing a suitable ML model through different iterations become necessary.

5- Once this model is ready, you need to design an engineering system that will serve this model in addition to other aspects that requires careful engineering to ensure continuous effectiveness of this model.

6- Do the necessary continuous analysis and investigations for the model results as well as the must-have monitoring.

Truly they exist on our planet but they are very rare ;)

Since human-beings are limited in their ability to acquire knowledge and to keep up with the non-stop changes in each different sub-field. Specialization became a must. We started to see different job profiles working on different areas of the pre-mentioned workflow.

For example, some data engineers/scientists who are more excited about infrastructure, specialized in data engineering. This gives them more bandwidth to absorb the internals of different distributed processing systems (ex: Apache Spark, Apache Hadoop, ..etc) and thus be capable of extending these systems to handle very custom use-cases that may not be easy to handle with the standard APIs
We can list 6 profiles that together compose a capable data team able to push its organization to be data driven and then AI driven at a later stage.

Data Analyst & Data Viz
Data Scientist
Data Engineer
Machine Learning Engineer
Data Infrastructure Engineer
Data Ops

Still, it is hard to generalize this to every single organization as the needs and size of each are the deciding factors while considering the boundaries between each profile under the data team umbrella.

So What is a machine learning engineer?

I will quote the excellent article from Oreilly which describe them as the following:

They have stronger software engineering skills than typical data scientists.
Machine learning engineers are able to work with engineers who maintain production systems.
They understand software development methodology, agile practices, and the full range of tools that modern software developers use: everything from IDEs like Eclipse and IntelliJ to the components of a continuous deployment pipeline.
They are involved in software architecture and design
Because their focus is on making data products work in production, they think holistically and factor in components like the logging or A/B testing infrastructure.
They are up to speed on issues that are specific to monitoring data products in production. There are many resources on application monitoring, but machine learning has requirements that go even further. Data pipelines and models can go stale and need to be retrained, or they might be attacked by adversaries in ways that don't make sense for traditional web applications.

How to get the experience?

Be a solid software engineer
Get ML experience
For the theoritical part, you can take any of the existing MOOCs on Coursera, Edx or Udacity. One option is Udacity Machine Learning Engineer Nanodegree.
Get practical experience through doing real projects on real data. Kaggle is the best source for problems if you don't have some already :)
Read, Listen and Watch. There are dozens of awesome articles, podcasts and video sessions that are available on the internet. You can also join many subreddit that gives you updates about different ML topics.

Recommended resources

Podcasts
[ Machine Learning - SE Daily]
[The O'Reilly Data Show]

For theoretical background

Read Alex Smola's answer to What are the recommended courses should I take in my graduate studies to become a Machine Learning Engineer? on Quora

What does interviews look like?

As it seems most companies will interview you the same way they interview other software engineers. In addition, you may be interviewed on your machine learning theoretical knowledge, data engineering and ML product design.

You can get more details by reading Xiaohan Zeng interviewing experience as a Machine Learning Engineer.

Where can I find suitable opportunities?

Most of the big companies including the big five have their own machine learning and data teams. It should be easy to find suitable opportunities given that you have the right experience. You can always start from Linkedin.

For Egypt, I found this amazing list of companies that do data and AI.

AI Driven Companies in EgyptAfter graduation, I started searching for a good job in the area of Artificial intelligence, specially machine learning, ranking systems, recommendation systems and search engines. It was a hard long journey for me; because I didn't know anything about the Egyptian market in these fields, so I se...

Wrap Up

I tried to give some answers for the what, where and how questions about machine learning engineering positions. It would be nice if you can share your experience getting into the field. As always thanks for reading!