• Coding agents will one-shot most problems put to them in sufficient detail.
  • Anything you specify will get implemented.
  • The next bottleneck will be deciding what to build, and the difficulty of trading-off conflicting needs. A software paradox of choice.
• Professional software developers will still produce the vast majority of software in the world. Developers will continue to have jobs.
• Developer productivity will only get a 10-15% boost on average by most measures.
• There will be outlier wizards: machine whisperers who produce terrifying amount of software.
• Companies start forcing people to adopt coding agents top-down, and it doesn't go well. AI usage will start becoming a 'goal' and will get Goodhart-ed.
• There will be a movement to reject coding agents, reject LLMs and go back to the good old days of writing code by hand.
  • It will fail to get traction in the workspace, where most software is written for instrumental goals.

Knowledge work

• Most white collar work will continue as-is. AI diffusion will remain low.
• Ham-fisted attempts to force AI use will lead to a growing backlash.
• There will be multiple Claude Code equivalents for knowledge work, but no clear winner.
• By the end of the year, we'll reach a state where the case for using agents for knowledge work simply can't be ignored.

Economy & Society

• Anti-AI sentiment will be much higher in 2026.
• The EU will seriously try to legislate AI use, to predictable consequences.
• There will be at least one major stock market crash and it will seem like the bubble is bursting. This won't last though, and the bubble will keep on bubbling.
• Generative videos will be really popular even though no one really thinks it's a great idea.

This was the year of agents. We've been on a wild ride.

The period from June to December has been one of the most exhilarating and productive times of my career, and I can't wait to share more about the project I'm working on.

Every group has its own vocabulary. Here's a set of words that makes perfect sense to me:

• straight lines on a graph
• the bitter lesson
• jagged intelligence
• scaling
• giant inscrutable matrices
• short timelines

If you follow AI progress, you'll relate to some of these terms.

If you don't, we live in different worlds right now: but not for long.

I used to think that art should be completely separated from the artist. The context shouldn't matter, the original author's intentions shouldn't matter. The only thing that matters is how you react to an artwork.

A lot of modern art feels artists talking to each other and continuing a conversation I'm not a part of. I believed that I could learn to appreciate this form of art if I put in the effort, but I never had the inclination to make the effort.

AI-generated art is somewhat changing my mind on this.

Sora 2, MidJourney, Veo 2: it seems like every day there's a new state of the art method to generate images, sound or video. A lot of this is slop, but a lot of this is also indistinguishable from human art. Often it's better on a pure technical level.

My reaction to AI art is indifference for the most part. But not on its own merits: I often come across a piece of writing or an image that I think is cool on first glance: but on learning that it's AI-generated I lose interest.

This has taught me a bit about myself: maybe artistic intent does matter to me?

I am an AI optimist: I think that the LLMs are miracles that we already take for granted. I use AI daily, and I'm building-with & building-for AI daily.

AI art sometimes takes my breath away. But I don't feel as connected to it as a human artwork. For example, if I'm reading some fiction, I would much rather read something written by a human even if AI could do a better job.

I'm not sure why I feel this way, yet.

Possible reasons for this?

• Maybe I don't like low-effort art? This implies that I don't value the output itself, I also value all the inputs that go into creating something.

  Does this mean artistic intent does matter to me, after all? Is it the effort that goes into creating something, or the amount of reps you put in becoming good at what you do?

• Maybe it's a defence mechanism? I know that the volume of AI generated art will keep increasing exponentially, and you can only feel wonder so many times a day.

  Maybe avoiding AI art is a way to avoid becoming numb? Wireheading seems like a bad end after all.

• Maybe we care about the stories behind the art, the process of making something, instead of just the output?

  These stories don't necessarily need to be real, they just need to be shared. Narratives are powerful. And there's no why behind AI art.

For now, I have become more thoughtful about what I consume, and I'm re-thinking some of my priors.

I dismissed modern art because I thought that context doesn't matter, but now I'm realising that it does matter to me. The stories we tell ourselves do matter.

We're building an agent system and I have been evaluating adding support for MCP.

We really care about our tool design to an unreasonable degree. I have personally spent days thinking about the right design for some of our tools.

I couldn't help but over-think exactly how MCP should be exposed to our agents. At a high level, I felt that there could be two integration patterns — I would name them the 'meta tool pattern' and 'materialised tools pattern'.

Meta Tool Pattern

The meta tool pattern: the agent sees a few meta tools like 'list available MCP servers', 'describe MCP server', 'invoke MCP tool'.

The agent can decide to explore the capabilities of an MCP server and invoke its tools, when necessary. This design is flexible and efficient, but also requires a more capable agent:

• This pattern uses less context by default. Tool definitions are lazily loaded only when required.
• The 'discovery' calls for individual MCP servers need to happen only once in a given chat thread.
• There's no guarantee that the agent will decide to explore the installed MCP servers though.

Materialised Tools Pattern

Here, whenever a MCP server is enabled – the system will automatically discover all available tools in the specific MCP server and eagerly copy them to the list of tools available to the agent. The agent sees all of these tools by default. Calling an MCP tool is just like calling any other tool.

• This pattern makes tools really explicit to the agent.
• This comes at the cost of using additional context, even when it's not necessary.
• If multiple MCPs are installed, you may fast run out of context space.

Evaluating these patterns

If you were designing an agentic platform, which option would you choose? I did a survey of some existing open source systems and here's what I found:

• codex-cli also uses the materialised tools pattern
• opencode uses the materialised tools pattern
• Cline uses a hybrid
  • All tools exposed by enabled MCP servers are copied to the system prompt
  • A single use_mcp_tool tool is used to invoke them
• OpenManus also uses the materialised tools pattern.

This was a surprise. I'm not sure why the existing implementations are so heavily skewed towards materialised tools!

Our Decision

At this point I'm inclined to go with the meta tool pattern — it seems to make sense the system we're building.

What I have noticed is that:

• Most MCP servers don't have a great agent interface.
• They expose too many fine grained tools with overlapping responsibilities.
• They are really wasteful of context tokens.

Most importantly: the meta tool pattern just intuitively feels like the right solution to me.

There are 100s of small details like this that go into building great products – and I have a feeling that these details are actually what differentiates your product when everyone is building on the same foundation models.

The Mythical Man Month famously had the observation that adding manpower to a project that's behind schedule will often delay it even further. Additionally, in 'No Silver Bullet' Fred Brooks further states that:

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

How does this change with the advent of AI coding agents? Can coding agents give us the mythical 10x speedup?

My thoughts below. I've divided this blog post into sections which argue both for and against transformative change.

My position: coding agents are a fundamental shift in how we'll build software over the next few decades, and we're overestimating the impact in the short term while underestimating the impact in the long term.

Headwinds

Vibe Coding vs Writing Production Software

We should differentiate between 'vibe coding' as a way to experiment / prototype, and using AI to write production software. Simon Willison has an excellent post on this.

For production quality software, all basic tenets of software engineering apply. Code reviews, tests, architecture designs, software design reviews, etc.

Most of a senior engineer's time is often spent in these activities, not just writing code.

Coding agents help a great deal here, but you won't see the same speedup as pure vibe coding — where you build software without reviewing the code your agent writes

At least for now: coding agents aren't good enough to fully autonomously build features and ship them to production without human review.

Essential Complexity vs Incidental Complexity

As Fred Brooks pointed out in the above essay, software development consists of both essential complexity and incidental complexity.

Incidental complexity could be things like figuring out how to write a Dockerfile, or learning how a specific library works, or dealing with framework specific issues. Coding agents can be a huge help here.

Essential complexity is the core problem you're trying to solve. Coding agents can definitely help here, but you still need to pay close attention — humans will remain the bottleneck here.

Amdahl's Law basically gives a ceiling for the performance gain that automation / parallelisation gives for any given task. You are only as fast as your bottleneck.

Decision Fatigue and Time Compression

Faster coding actually compresses timeframes and lets you focus on the hard decisions, on the essential complexity. Coding agents let you focus on substance of your problem.

But human capacity for deep thought is limited!

So now, your day to day working with AI coding tools is going to be a series of hard-decisions that you need to think deeply upon, decisions that require high amount of mental effort.

Decision fatigue is real. If you have to make a weeks' worth of hard decisions in a day, your decision quality will suffer.

AI coding will exhaust you if you're not careful. Human beings need to be able to step back and think about problems. We need to go for walks, ruminate on ideas and just wander through a problem space.

Effective Communication & User Skill

AI agents need engineers to be effective communicators, and this is a problem. Most engineers aren't the best communicators. Every great coder isn't automatically great at delegation.

Effective communication is a skill. Writing clearly is a skill. And using coding agents effectively is a skill.

For example, here are two recent articles that go in-depth about the craft of using AI agents to code:

• How I use Amp
• AI-assisted coding for teams that can't get away with vibes

Craftsmanship takes time. Skills take time to build. People who are great engineers today won't automatically be great at using coding agents. Getting better will require deliberate practice, and approaching this problem with a beginner's mindset.

Headwinds Summary

Given that:

• Production software (currently) requires human oversight
• Essential complexity remains
• It will take time to learn how to use the coding agents effectively

Is an immediate 10x improvement in velocity possible? It seems there is truly no silver bullet.

Tailwinds

AI Scaling will continue

Agents will keep getting better. Underlying models will keep getting better. We've learned to not bet against scaling.

According to one recent viral benchmark, the length of tasks that AI can do uninterrupted is doubling every 7 months.

From my personal experience, I know that each recent big model release (eg: Sonnet 3.5, Sonnet 3.7, Sonnet 4.0) has made building agents easier. The LLMs are getting better at following instructions, at using tools, at planning, and just at showing agency.

It's hard to predict the future, but it's definitely possible that soon, a large majority of code written won't need human review and oversight.

Most work isn't 'Deep Work'

While my arguments above hold (essential complexity remains, decision fatigue is real) — let's be real and acknowledge the fact that most of us don't do deep work 100% of the time.

A lot of time goes into glue work, into getting various subsystems to behave, dealing with broken tools, etc.

AI can be a huge accelerator for these types of work. It's possible that this itself can be a 10x improvement for many organisations!

Quantity has its own Quality

If you're working in deep tech, if you're building something complex — AI coding allows you to try more approaches. You can build quick and dirty throwaway prototypes, and validate more ideas.

Quantity has a quality of its own. If you can do more iterations, you can get to better decisions. If you can actually build multiple candidate systems, you can make more informed choices — architecture / design decisions become easier with data.

I have personally seen this pay off: while building a zero to one product, I have been able to do many parallel experiments and actually test 10s of ideas before deciding upon a plan. This has enabled me to make bold system design bets with high confidence.

Ambition & Moonshots

AI agents allow you to be more ambitious. On the margin, with higher productivity it's possible to devote more time and resources towards building something better than you would have previously.

You can think of a productivity gain as either:

• Work 10x faster
• Build something 10x better

Either option is fine! In fact, it may be the case that building something 10x better is actually more impactful.

I suspect one of the impacts of ubiquitous coding agents will be the rising baseline quality of software!

Tailwinds Summary

If you consider the facts that:

• LLMs will continue to improve
• We'll all get better at using AI agents
• We'll be able to automate away low impact work
• We'll be able to try many more iterations
• We'll be able to build more impactful, more meaningful software

How can you doubt the impact that coding agents will have?

Conclusions

I've argued both sides of this. My position is:

• We're radically underestimating coding agents
• Most of us are not ready to adopt agents at scale

I think impact and adoption will not be uniform. People will have different lived experiences with AI tools, with some dismissing AI coding as a fad, and some enthusiastically thinking of these agents as a panacea for all their problems.

I think coding agents will have a huge impact that is overrated in the short term, but underrated in the long term.

And I think that today, to get the most out of current generation agents, you have to really dive deep and uncover their limits yourself.

Should AI agents be general purpose or should they be built for a specific task?

I would say yes to both.

Special Purpose Agents

A special purpose agent is an agent built to do one (or a few things) very precisely. Examples:

• RAG on a knowledge base and answer questions only from the knowledge base.
• Convert images to very specific structured data format (eg: convert image to a contact vCard).
• Convert text to SQL on a specific table, with specific guardrails (eg: always apply page size limits).

These agents are built to do a specific job.

General Purpose Agents

A general purpose agent on the other hand would be an agent that has emergent behaviour, that can use its tools to do something it wasn't explicitly programmed for.

This is best demonstrated by an example. I recently coded up a toy agent that runs on the command line that had the following tools available:

• List directory
• Read file
• Query file (via duckdb)
• Read PDF

This agent was designed to have generic tools, and it was allowed to do multiple tool calls if needed. It wasn't given a specific goal.

The lack of specificity actually made the agent more useful! In the last few days, I have used it to do:

• K8S cost optimisation — given a CSV containing some kubernetes utilisation data, this agent helped me find low hanging cost optimisation options
• Data entry for my own personal finance needs — given some account statements, the agent was able to help me digitise them in a format I use for tracking my expenses
• Do Q&A on my meeting notes

Interestingly, the agent showed a lot more agency than I was expecting. For example, it would often execute multiple tool calls in response to a general 'hello' message!

All the recent wow moments I have had with AI are usually with general purpose agents. They can end up giving you unexpectedly rich experiences.

Use Cases & Trade-offs

If you're building an AI enabled product, both special purpose agents and general purpose agents have their place.

• You sometimes want determinism (or close to determinism) and repeatability.

  • For example: if you're building a support desk, you may want to always categorise tickets in a certain way.
  • In such scenarios, special purpose agents are really useful. You can treat them as "intelligence that's an API call away".

• Special purpose agents are limited in scope.

• General purpose agents are where the power of AI agents becomes apparent.

• General purpose agents are going to be more expensive to build.

  • You may need smarter LLMs, you may need to spend tokens on reasoning.
  • General purpose agents could use up millions of tokens.

• Shipping general purpose agents requires you to have the right underlying infrastructure.

  • The agent is as powerful as the tools it has access to. You need to build the right primitives to unshackle the AI model.
  • You need to build the right platform for the AI agents to leverage!
    • For example: if your system processes a lot of data, you may need to invest in robust parallel execution.
    • If the agent could 'ask any question' of your data, you have to think about indexing and database performance.

• The ideal end state of a general purpose agent is a coding agent — an agent that can write code for a specific task and then execute it.

  • This could lead to potential security issues, and you have to look out for other types of abuse.
  • You might need to invest in primitives like sandboxing here.

I see this as a continuum — the more general an agent, the more powerful it is, but you need to invest proportionally into building the right safeguards.

Most use cases may not need a general purpose agent. You can probably start off building an AI-enabled product by just focusing on special purpose agents.

General purpose agents are also the most valuable ones though. And building general purpose agents will require you to invest proportionally into your platform's core primitives.

Building a OCR / Document AI pipeline used to be hard work.

• Training OCR models
• Building multi-step systems (eg: line segmentation, layout detection, table detection)
• Ensuring that these steps works nicely with each other
• Adding heuristics and special cases
• Doing a lot of testing to ensure your baseline is good enough

Now: you could just give a PDF to Gemini Flash and get a 'good enough' output in one API call. What used to take weeks / months can now be done in hours.

With AI models becoming more capable — you can often get very far on your problem statement if you just try. But if you are stuck in an old mindset and think about some problems as difficult or time consuming, you may not even attempt harder problems!

I don't think realisation has sunk-in yet. We still follow old patterns of behaviour, we still mostly try to build the same things as in the past.

Here's another recent example: I need to parse something reliably. The 'right way' to do this is to write a tokeniser / parser, but this is time-consuming. In the past, I would have just depended on some basic regexes and would have just got it working (and over time — fixed edge cases as they came up).

This time though: I decided to do it in the 'right way'. I worked with an AI coding agent and got a tokeniser and recursive descent parser working in around an hour. The AI wasn't perfect — I definitely needed to know the theory and know when to give the right inputs. Even though this wasn't automatic, I ended up up with at least a 10x productivity boost.

The hard lesson for me personally was:

• I needed to let go of my pre-conceived notions that a task can take days / weeks.
• I had to decide to build something ambitious.

I need to keep reminding myself of the fact that hard things are now easy, that the impossible may be actually possible.

I think this is problem where younger folks have an edge over more experience people: with experience comes caution, but now is the time to let go of caution and just build.

To everyone reading:

• I suggest partnering with one of the current frontier models
  • Use Cursor, or Claude Code, or Windsurf, or v0, or Lovable, or anything else you want)
• Try to build something ambitious today!

In HTTP, browsers are called ‘user agents’ — they were meant to act on behalf of users. This initial positioning has sort-of carried forward even now:

• Browsers are one of the few pieces of software left that allow plugins & addons, that allow customisability.

• Browsers let users override choices. You can set your own min font size, overriding any site’s CSS. You can use reader modes.

• Browsers let users inspect applications via devtools, script applications by allowing users to run code on a developer console.

Browsers are one of the last vestiges of an old-school way of building software: software that is extensible, that users can control and change to better suit their needs.

Most current software we use today is the opposite.

• Most software (whether SaaS, mobile apps or desktop apps) is not programmable.

• Decisions are taken by product builders, not users. If a product owner hasn’t added a feature that you want, you can’t go and add it yourself!

• Most software doesn’t empower users, it enforces rigid workflows.

• We have taken away most customisability. Each option in a SaaS product is expensive to support, and it’s rational as product builders to reduce surface area and remove options that 99.9% of your users don’t use.

All of this happens because today’s software users aren’t programmers: they don’t know the internals of how software, operating systems work. Most software is built to be used by the mass market and as a result it encodes a set of assumptions about how it's meant to be used.

AI agents could reverse this trend.

I can see a world where users have personal AI agents running on their behalf. It wouldn’t matter if a product is scriptable or not, or if it has an API or not — users could just ask the agent to automate a task on their behalf! The agent may use the API, or it may just resort to spinning up a browser and clicking on pixels.

What happens when most users are able to finally take control of the tools that they use daily? I think it's finally time for general purpose compute to be actually accessible by the masses.

This fills me with optimism; similar to the heady days of Web 2.0: when everyone wasn’t so jaded about empowering users, exposing APIs was the norm, mashups were possible and products like Yahoo Pipes were built.

This is a perspective to keep in mind as we build AI-first products — let's enable our users to do great things!

TL;DR: I'm sharing some ways in which we at Clear have democratised AI adoption in the company; by giving people access to frontier models, reducing dev friction, and actively fostering a learning culture around AI.

Here are some things we have tried at Clear to enable everyone in the team to adopt AI tools.

Launch an internal chat tool

We launched an internal chat tool — similar to ChatGPT or Claude. This is to enable everyone in the team to have un-metered access to the best AI models — for example, we just added support for Gemini 2.5 Pro.

This internal tool works on top of APIs provided by OpenAI, Anthropic, Google, etc. There are a lot of open source chat tools that take API keys and work on top of them — we're using Open Web UI.

Here's why you should do this:

• Free tiers of ChatGPT, Claude have very limited access to the frontier models. Usually, free tiers are limited to the 'mini' models. If your team hasn't used the most capable models, they don't know what LLMs are capable of.

• It's very expensive to pay for the pro or team tiers of each provider. For example: ChatGPT team is $25 per member. APIs are usually cheaper, especially since most users won't be chatting enough to cost you $25 in API credits.

• Using APIs gives you flexibility to work with multiple providers in parallel: it makes no sense to pay $25 for ChatGPT, $25 for Claude, $25 for Gemini individually.

• Free tiers are also risky from a security and privacy point. When you use the free versions, most providers reserve the right to train on your chats and use them to improve the models. In a corporate scenario: having employees use personal accounts to do work is very risky from a compliance perspective.

Make it easy to build AI projects internally

We built an internal proxy which can be used by our developers to access providers like Anthropic, OpenAI, etc. Both directly and via AWS Bedrock, Microsoft Azure.

This drastically reduces friction when building an AI-powered use case: developers can quickly do POCs and experiments without asking someone to provision a specific API key on their behalf.

We learned this the hard way: during one hackathon that we ran, I personally had to spend a lot of time just making sure that every team had the required access!

There are many open source solutions for this. We use something custom, but right now it looks like LiteLLM is a great option.

Enabling our team to quickly build AI-powered applications, without asking for permission, has proven to be a huge win. Sometimes, the best ideas come bottom up — for example, one team used this capability to enable automatic code reviews on Github powered by aider.

Pedagogy and Evangelism

There is also a need to do deliberate culture shaping — making sure you are bringing everyone in the team along with you on the journey.

Examples of this include:

• Writing internal notes on AI — this blog actually started out as internal writings. The field is very fast moving, keeping up with AI progress is almost a full time job.

  • There is a lot of value in having some team members synthesise their learnings and sharing with your broader team.

  • There is also a lot of value in simplifying jargon and giving clear explanations of what different AI concepts mean.

• Showcasing use cases, doing demos: people learn by association. If you come across a novel way to use AI, it should be shared broadly in your team! The best ideas will come from your team, find a way to enable these ideas more broadly.

The recent Shopify memo is a great example of this in action.

This is just the start. We are still learning about how to best adopt AI in our daily lives. I'd be very curious to learn how everyone else is approaching this problem.

Please reach out to me on email (ankit at clear dot in) or on twitter.

Lately, it seems everyone uses LLMs to write. People are justifiably annoyed at the 'default' ChatGPT style of writing. Having ChatGPT write an email for you, or fix your grammar is a low value use case though.

I think there is a lot of value in doing the opposite: doing more writing yourself, so you can then feed it to an LLM. Writing not as an end, but to generate (quality) content for AI. Writing down things so that AI can help you (or others) down the line.

Interestingly: people like Tyler Cowen and gwern go as far as to say that writing publicly for LLMs is functionally a way to gain immortality.

In a world where written knowledge is easily accessible by LLMs: there is a lot to gain when you pivot to a writing culture. Instead of making decisions face-to-face, switch to writing memos and jotting down your decisions explicitly. You can then use AI to reflect on your writing, give you deep feedback, get it to spot patterns and trends, and dig up the nuggets of insight that are often hard to find.

Here are some trends I've noticed recently:

• I have noticed people who are clued-in have started to take more notes than before.

  • For example: apps like Granola let you record your meetings, take notes yourself, and then ask questions about your notes.

  • Even with Granola, the high value use cases come about when you jot down your own thoughts as well, not just depend on it to transcribe the meeting.

• There’s a trend to make API documentation, user guides etc all available as plain text in an llms.txt file. This documentation can then be easily fed to LLMs so that the LLM can help users write code.

• Writing evals is one of the highest value tasks you can do when building AI applications. People have been paid by AI labs to create high quality content and high quality evals for AI.

  • Epoch AI for example hired 70 mathematicians to generate problems for their frontier math eval. Imagine being one of the top experts in your field, and the highest value use of your time isn’t doing research, but just writing tests for frontier AI models!

Now, fit this pattern into your organisation. Writing tests, background material, context for AI shouldn't be a low value task; and you should put your best people on it.

Every organisation has a lot of tacit knowledge, which is completely invisible to AI. It's not going to be possible to codify every little part of your business — but being deliberate about writing will help!

Building tools to reflect on your writing

For personal use, you don't need to be too fancy here. With LLMs having huge context lengths like Gemini, I can put every personal note I’ve ever written over the last decade into one LLM prompt.

As an organisation: you could start collating information across multiple internal systems (eg: PRDs, design documents, internal tickets, etc) and consolidating it in a central space, and adding AI tools on top. But before you do this, you need to pivot your org to a writing culture.

Start writing things down — not just for yourself or your co-workers right now, but the AI agents you'll soon be working with. We have started doing this at Clear.