No restrictions: The gap Pakistani founders saw in AI

On August 14, SpaceX completed its acquisition of Anysphere, the developer of popular AI coding tool Cursor, in an all-stock $60 billion historic deal said to be the largest startup purchase on record. The integration fast-tracks the newly formed SpaceXAI—which combines xAI and Grok—into a key player in enterprise AI and a direct competitor of OpenAI and Anthropic.

One of Cursor’s four cofounders is Sualeh Asif from Karachi. After completing his A-Levels from Nixor College, the 26-year-old, who also represented Pakistan at the International Mathematical Olympiad, bagged a scholarship at the Massachusetts Institute of Technology. In 2022, Asif and his classmates founded Cursor.

Understandably, the media coverage is mostly about the money. But I am interested in a quieter question. What did these four students understand, or act on, earlier than most of the industry?

Their story suggests an answer, and it may be more useful to us than the valuation.

Some context first. In June, the National Foundation for American Policy published its latest count of American private companies worth a billion dollars or more. Immigrants founded or co-founded 455 of the 775, 59 per cent, rising to two-thirds if you include American-born children of immigrants. The founders came from 76 countries. India leads with 96 such companies, followed by Israel with 60, the United Kingdom with 47, China with 41 and Canada with 30. Pakistan sits on the same table with 10, and the report names all of them: alongside Asif, there is Qasar Younis at Applied Intuition, Samar Abbas at Temporal, Obaid Khan at Motive, Saad Godil at Hippocratic AI, S. Zayd Enam at Cresta, Mo Shaikh at Aptos Labs, Amir Husain at Avathon, Omair Tariq at Cart.com and Talha Sattar at Nimble RX.

One more figure stayed with me. Nearly one-in-four companies in the report have a founder who first arrived in the country as an international student. Not as an investor, not on a company transfer, but as a student. Four of the Pakistani founders came that way: Sualeh Asif at MIT, Saad Godil and Amir Husain at the University of Texas at Austin, and Omair Tariq at the University of Houston.

These numbers are normally read as an argument about immigration policy. I read them as a question about what converts technical training into something valuable, because the answer to that question has changed recently and I do not think we have absorbed it.

The gap nobody is looking at

Building software has become relatively cheaper, easier and considerably faster. In some kinds of work, a small team (and occasionally one person) can now produce what until recently required a department. But easier construction does not tell you what to construct. If anything it makes that judgement more valuable, because the part that used to be hard has stopped being the bottleneck.

Which is why one interview has stayed on my mind. Boris Cherny, who created Claude Code at Anthropic, spoke recently with Diana Hu at Y Combinator’s Startup School. Claude Code is Cursor’s direct competitor, so this is a rival’s account of the same race. One idea in it seems to me particularly useful for Pakistani entrepreneurs and academics, and it costs relatively little to begin exploring.

Cherny’s claim is that we routinely hold these models back without noticing. Today’s model, not next year’s, can already do things that no product permits anyone to do. He calls that unused remainder ‘product overhang’: the distance between what the model is capable of and what the software wrapped around it allows.

He tells the story against his own industry. In his account, when Claude Sonnet 3.5 appeared, the coding tools of the day mostly finished your sentence. They suggested the next line, sometimes the next few lines, or let you ask questions about your code without touching it. Yet the model underneath could already write entire files. Nothing was broken. Users were satisfied. The opening was simply far smaller than what stood behind it.

The Claude Code team did something counterintuitive. Rather than adding cleverness, they stripped away the scaffolding and gave the model direct access to the working environment. The capability had been sitting there the whole time.

That is also the answer to my quieter question. Cursor was founded in the same window, around a broader view of what programming with these models could become, and that early judgement is a large part of what positioned it for the growth that followed. Its founders had nothing resembling the resources of Microsoft or Google. What they did have, besides the reading of the gap, was an MIT education and the training, peers and networks that come with it.

There is a slogan for this moment, much repeated in Silicon Valley: ideas will become wealth, because when the scarce thing sits in someone’s head rather than in physical capital, anyone who thinks clearly can grow rich. Half of that is right, and the wrong half is the one people repeat. The opportunity required no factory and no fortune, which is the true part. It did require years of technical training, access to capable peers, and the judgement to recognise the gap. Ideas do not become wealth on their own. They become valuable when someone is equipped to act on them.

Sometimes, progress means deleting

The habit this produces at Anthropic is the opposite of ordinary software practice. When a new model arrives, they do not add instructions to accommodate it. They take instructions away.

For a recent release, Cherny says the team deleted about 80pc of the written instructions governing Claude Code, because most of those instructions existed to compensate for weaknesses the new model no longer had. The method has a name borrowed from research: ablation. Remove something, measure what happens, and restore it only if the evidence says the model actually needs it.

His advice to ordinary users is the same. Every six months, he suggests, delete your accumulated instructions, skills and hooks, and see what the current model still needs.

This matches something I learned the slow way. In my previous work as an economic data scientist with the government of Alberta, we built several production systems on these models, and whenever the output disappointed the reflex was always to write more instructions. Add a rule. Add an example. Add a warning about the mistake it made last week. Past a certain point this stopped helping and started doing damage. The versions that performed best were consistently the ones carrying the fewest instructions. At the time, I put it down to my own clumsy writing. I now think the instructions were crowding out the model’s own judgement.

That is a hard lesson to accept, because everything in an engineering education teaches accumulation. We add functions, rules, checks, documentation. Here the discipline runs the other way. An elaborate set of instructions written for last year’s model is not an asset. It is baggage, and the model reads every word of it on every single run.

There is a related habit worth breaking. Most of us instruct these models the way we would brief a junior clerk: do this, then this, then use this method to produce this intermediate output. Cherny argues that with capable models this now constrains more than it helps. Describe the task, set the boundaries, define what a finished job looks like, and then leave it alone. If I hire a competent colleague, I do not dictate their keystrokes.

What this costs in practice

I want to enter one objection here, because Cherny is describing a practice from inside the company that makes the model. Everywhere else it is expensive. If every release means deleting your instructions, rebuilding them by trial and error, and reworking the ways you judge whether the model is behaving, a small team can spend a serious share of its year maintaining scaffolding rather than shipping anything. Cherny concedes that model evaluations may survive only one to three generations before a more capable model saturates them and new ones have to be designed. That is not a trivial tax on anyone’s time.

I can speak to this from the other side of the table. I build and run Lectiq.ai largely on my own, and the experimentation Cherny recommends is not free. Each model release means running the same checks again, working out which of my accumulated instructions have quietly become unnecessary and which have started doing harm, and paying for every token those experiments consume. The work is worth doing and I do not skip it. But as a single developer it competes directly with the hours I would otherwise spend building the thing itself, and the bill arrives whether the experiment succeeds or not.

We have seen a version of this problem already, arriving from the other direction. OpenAI has set August 26 as the date it removes its Assistants API from service altogether. Developers were given a year of notice, which is fair enough, but the replacement is not one endpoint swapped for another. The underlying objects change, conversation state has to be handled differently, and anyone running a production system on it faces a rebuild rather than an upgrade. For a small team maintaining something in production, that is a substantial cost. Developers complain about it for good reason, and what Cherny proposes is adjacent: the same churn applied not to the interface but to everything you have written to make the model behave.

None of this makes the observation wrong. It means the practice needs adapting to circumstances other than Anthropic’s. Review the accumulated instructions once or twice a year rather than with every release. Keep the checks on model behaviour focused and cheap enough to replace when a newer model outgrows them. But keep the tests that establish whether the product itself still works, because those encode what the system must continue to do. Bun’s rewrite, an entire software runtime, from one programming language to another by Jarred Sumner, an engineer at Anthropic, which ran continuously for eleven days, succeeded precisely because that kind of test existed in quantity. It also needs to be accepted that for a company with engineers to spare this is an afternoon of work, while for a startup in Karachi or a department with one technical person it is a cost that has to come out of something else.

The scarce skill is verification

For three years we have been told that prompt engineering is the skill of the age. It never looked to me like a durable scarce skill. Phrasing a request well can be learned in an afternoon, and nothing learned in an afternoon stays scarce for long. What is hard is knowing enough about the subject to tell whether the answer coming back is any good, and Cherny puts his finger on why that matters so much now. The scarce skill is verification.

Consider the difference. You could write an exquisite description of an interface you want rebuilt. Or you could give the model the original application, its own version, the ability to run both, take screenshots and compare them, then let it correct itself and repeat. The second approach needs only a clear prompt. What makes it powerful is the feedback loop.

Cherny describes exactly this experiment, rebuilding a desktop application in a different language, with the model checking its own work against screenshots. At the time he spoke it had been running for over two weeks, unfinished, and he did not know how it would end. A better documented case is the rewrite of Bun. What made that possible was not the prompt. The codebase had an unusually thorough test suite, separate agents ran alongside the main one looking only for reasons the new code should fail, and Sumner watched the output throughout.

The lesson generalises well beyond software. For data analysis, verification means validation tests. For accounting, reconciliation. For research, checking claims against original sources. For a business process, a measurable definition of done. The question is no longer only whether I gave the model good instructions. It is whether I gave it a dependable way to know if it succeeded.

Which brings the argument back to knowledge. A model can propose the tests itself, and routinely does. What it cannot do is judge whether those tests capture the requirements that matter and the ways this particular system is likely to fail. That judgement does not come from a course on prompting. It comes from years spent inside a subject, from having been wrong often enough to recognise the shape of a wrong answer, and from what accumulated experience leaves behind. Verification is the point at which domain expertise enters, and it is why these tools reward the person who knows the subject far more than the person who knows the tool.

What this means for us

Cherny is careful about the claim that coding is finished. He notes that models still struggle with deep systems work, distributed systems and precise visual detail. What distinguishes the best users, he says, is an empirical temperament: try it, watch where it fails, adjust, and be willing to discard what you believed about the previous generation.

I have learned one version of this the expensive way. Building my own applications, I have found that when a model fails at the same problem two or three times within one conversation, another attempt in the same context is rarely productive. What works is starting over: a fresh conversation, often a different model, and a statement of the problem written by me rather than accumulated by the machine. On one occasion I threw away three days of work and began again, and the second attempt went ahead quickly.

I am still not sure which half of that is the explanation. By then I understood the problem better and could describe it more precisely. The model also had a clean slate rather than a conversation cluttered with its own failed attempts. Probably both, and the practical lesson is the same either way. Persisting is the expensive option. Beginning again with a better understanding is usually cheaper than it feels at the time, and the thing that improved in the interval was not the tool.

Asked what students should still learn the hard way, Cherny’s answer was not computer science alone. It was that technical knowledge becomes valuable when combined with product judgement, business sense, design, statistics and the ability to talk to the people who have the problem.

That should interest our universities more than it currently does. Nearly a quarter of the companies in that report were founded by someone who arrived in America as an international student, which tells us that universities are not only places to collect a degree. At their best they are where technical training, hard problems, capable peers and commercial ambition sit in the same room.

Our instinct in Pakistan has been to teach students to use these tools. That is the smaller half of the opportunity. The larger half is teaching them to look for the gap: to ask what the technology can already do that nobody has yet built a product around.

Two ways of holding AI back

At the technical level, we hold AI back by surrounding capable models with restrictions inherited from weaker ones.

At a broader level, we hold ourselves back by treating AI as something that writes our emails and summarises our documents. Useful, certainly. But a small fraction of what is sitting there.

What I take from the people who built Claude Code is not that we should all build coding agents. It is a way of working. Remove what may no longer be necessary. Give the model a problem slightly beyond what you think it can manage. Give it a way to check itself. Retry what failed six months ago. And look, deliberately, for the distance between what these models can already do and what anyone has yet allowed them to do.

Sualeh Asif was a student from Karachi who ended up building in that gap. The gap is still open. Finding it takes less capital than building a factory, but it still demands access, experimentation and, above all, trained judgement.

Header image: AI (Artificial Intelligence) letters are placed on computer motherboard in this illustration taken on June 23, 2023. — Reuters/File