Ara Khan: Choose work that improves with AI without being replaced by it

I am Ara, a founding engineer at Cline. I want to explain recursive self-improvement in coding agents and what rapidly improving models might mean for our careers.

Side projects that once demonstrated skill can now be produced in one shot by a frontier coding agent. That raises a question: how do we show what we can do and choose work for the next few years?

Some people worry that gains will concentrate among a few chipmakers and model companies. There is fearmongering around the issue, but I think the concern about how others will thrive is real.

At Cline we tried to automate improvements to the coding agent harness, the surrounding system that gives a model tools and runs it. With Kimi K3, our initial Terminal-Bench 2.1 score was 77.5%, below the model release paper’s reported result.

A harness that can improve on the same problems suggests a practical part of recursive self-improvement. More generally, the idea is that an AI system helps build a more capable successor, which repeats the process.

I trace the idea from an early vision of a conversational software engineer through ChatGPT, function calling, agents able to read and edit files, and early multi-agent systems. Those early arrangements were often brittle and heavily scripted.

The next question was whether agents could get faster and cheaper, and then whether they could improve themselves. Measuring that requires more than asking one question and grading one answer.

Setting up an MCP server, for example, may require searching documentation, changing configuration, editing files and running commands. Tests must establish whether the agent actually completed the request, rather than accepting its assertion.

Terminal-Bench evaluates agents in terminal environments. I want tasks isolated in sandboxes and checked independently, including their results, time, tokens and tool use, as well as signs of cheating or reward hacking.

The version I describe has 89 tasks. We run them in parallel containers, aggregate the results and group failures: a file tool might break, inference might stall, or a task might time out despite making progress.

The manual process is to inspect those groups, change the harness and rerun the evaluation. It takes time, but the iterations reveal where the surrounding system prevents a model from doing better.

We gave a long-running GPT 5.6 Sol agent responsibility for examining Kimi K3 evaluation failures, changing Cline’s harness and rerunning the tests. Each evaluation could take about an hour, and the feedback had to be interpreted without simply gaming the score.

Over the run, the agent found issues involving loop detection, background processes and file indexing, then made changes and tested again without my intervention. The slide shows a 77.5% baseline, an 86.5% frozen-stack result and a best run of 88.8%; individual intermediate contributions were not isolated.

I think of this as two loops: the harness acts in an environment and receives feedback, while a separate agent observes those outcomes and changes the harness. Real-time adaptation is harder because it may overfit a particular problem.

Changes should therefore be justified across a broader range of tasks. If models can improve their own harness, I think they can help improve other parts of the system too.

I cite a reported OpenAI example in which a model optimized production kernels, reducing end-to-end serving costs by 20% and improving token generation efficiency by 15%. I also mention a kernel competition winner who said their work was driven by agents rather than handwritten GPU operators.

The potential surface for improvement spans evaluation, the harness, inference, training data, post-training and interaction with the world. A cheaper inference step can make more experiments affordable.

When a human corrects an agent—for example, adjusting the cache after adding a database column—that correction marks a gap in its capability. Post-training can use difficult, long-running tasks to push that boundary further.

A verifiable feedback loop need not be confined to software. I show a robot typing as a speculative illustration of what might happen if physical actions could also be assessed and improved.

I tried a more concrete hardware experiment with a small device containing a camera, speaker and microphone. Its agent responded slowly, so I connected the device to my computer and let coding agents run tests against it.

The agents measured end-to-end latency and investigated slow cases. I set up overnight experiments that could change firmware, tool calls and the models used for inference and speech recognition; I say the device became substantially more responsive.

Connecting such loops could mean cheaper inference, more experiments for the same budget, and better data and models. I think components of that loop are already close, though whether the whole cycle becomes a singularity is an open question.

My career advice is to move closer to the self-improvement loop. Some narrow software projects, in my view, could be overtaken by a single model release, and merely asking a model to complete routine tasks may leave little room for the engineer’s own contribution.

That could mean work on inference, post-training, hardware, networking, physical interaction or community. The important question is where your work benefits from model progress while still making a contribution of its own.

I cite a slide recommending ambitious, targeted, fast collaboration and asking whether a project will be finished before a stronger model can do it. I would look for problems that benefit from scale but are not solved by scale alone.

If your daily work feels reduced to relaying tasks to a model, step back and consider where your judgment and ability still make a difference. I acknowledge that my expectations about timelines may be too optimistic or too pessimistic, and welcome disagreement.