Last December, we witnessed a fairly significant revolution in AI. It can be summarised as the moment when continuous improvements in both coding agent harnesses, such as Claude Code and Codex, and language models made LLM-based coding tools effectively ready for mass adoption. The amount of work required from a developer to get value from these tools and produce working code continues to decrease. Tasks that only recently required a great deal of manual guidance can now be completed with less effort, less supervision, and fewer corrections.
In my view, every developer should at least learn how to work with these tools effectively. Even assuming that costs remain at their current level, it is difficult to ignore the fact that writing code manually is simply slower. This does not mean that every task should be delegated to an agent, or that engineers no longer need to understand the code being produced. It means that the ability to use these tools well is becoming part of the basic skill set required to work efficiently in modern software development.
I do not want to get into a discussion about whether AI will replace developers, because someone still needs to manage these agents, define the work, review the results, and take responsibility for the final outcome. I would therefore avoid being overly pessimistic about the future of the profession. What is clear, however, is that the ability to work with coding agents has become an important part of an engineer’s skill set, whether that engineer is a developer, tester, DevOps specialist, or security professional.
In this post, I would like to discuss the latest trends, examine the role of skills, look more closely at costs, explore what may be the next revolution already taking place, and consider what might come next. The goal is not to provide a definitive forecast, but rather to take stock of where we are today and to identify the changes that seem most important for engineers who want to work effectively with coding agents.
I have to admit that I sometimes return to my older posts with a certain sense of nostalgia, because reading them shows just how quickly all of this is progressing. In software testing, for example, Playwright has dominated as a tool for API and UI testing for several years. During those same few years, however, almost everything I intend to discuss today in the area of coding agents has emerged. The pace of change is genuinely significant, and it is becoming increasingly difficult to remain indifferent to it.
Fable and the Critical-Thinking Revolution
I believe that the release of the Claude Fable model may prove to be one of the most significant recent developments in AI. Fable is expensive—there is no point pretending otherwise—but I think it represents another important stage in the evolution of language models. I would include Claude Opus, when used with a high reasoning-effort setting, in the same category, as well as GPT-5.6 Sol, which I am currently using through ChatGPT. In my view, these models represent something more than another incremental improvement: they may mark the beginning of another substantial change in how we work with AI.
When prompted appropriately, these models are not merely executors of our instructions. They can become genuine partners capable of helping us decide how a particular task should be approached. Suppose that we have a problem to solve. By the way, it is worth noting that engineers should increasingly begin with a proper definition of the problem, because the ability to define a problem precisely is becoming extremely important—but that is perhaps a subject for another post. Once we have identified the problem, I believe that we should at least consider consulting a model that I would describe as capable of critical thinking. Saying that we should do this may be too strong, but it should certainly be one of the options we consider before deciding how to proceed.
These models can examine a problem from a relatively high level of abstraction and advise us on how it might be solved. They can suggest what data we should collect, what signals we should examine, and how we might determine whether the problem has actually been resolved. They can help us design an experiment that would confirm or challenge our hypotheses. They can suggest how to test quickly whether a particular direction is promising and, just as importantly, how to discover quickly that it is the wrong direction. Instead of immediately producing an implementation, they can help us understand what we are trying to achieve, what information is missing, what assumptions we may be making, and what risks we have failed to consider.
In that sense, we could say that we are beginning to interact with something that feels much closer to genuine artificial intelligence. I would describe it as an intelligence capable of critical thinking: one that can look at our ideas from the perspective of a critic, consider what we want to do holistically, and advise us on how a given problem could be solved and how the proposed solution could be verified. It can point us in a more promising direction and offer advice resembling what we might expect from a highly paid consultant or an experienced senior engineer on our team. This does not mean that its advice is always correct or that we can avoid verifying its conclusions. It means that, for the first time, the model can contribute meaningfully to the process of deciding what should be done, rather than only helping us execute a decision that has already been made.
I would not put models such as Sonnet 5 or Cursor’s Composer 2.5 in precisely the same category. Both are excellent coding models, particularly for implementation, and I would describe them as highly capable executors of our instructions. Composer 2.5, for example, was designed to handle sustained coding work and follow complex instructions more reliably. The important distinction, however, is between executing a direction and helping to establish that direction in the first place. In my experience, models such as Sonnet and Composer are very effective when the task is reasonably well defined and the expected result is clear. What they are less suited to is the earlier stage, in which we are still trying to understand the problem, challenge our assumptions, decide what information matters, and determine what should actually be built.
To be clear, I consider the release of Fable a revolution because it allows us to use an agent not only to implement a solution, but also to think together about which path towards that solution should be taken. I strongly encourage engineers to experiment with this way of working. It may be a new step, and perhaps an unfamiliar situation for many readers, but these models should increasingly be treated as partners in analysis. They can help us perform discovery, identify gaps in our understanding, expose missing data, question our assumptions, and suggest possible ways of solving the problem. Their most valuable output may not be a piece of code. It may instead be a better problem definition, a clearer experiment, an overlooked risk, or the discovery that the direction we originally wanted to pursue was wrong.
This also means that these are not necessarily the models we should use for the implementation itself. There are exceptions, of course. If keeping the same model allows us to benefit from prompt caching, if the implementation is relatively simple, or if switching models would introduce more cost and friction than it saves, continuing with Fable may make perfect sense. In general, however, I see the greatest value of these expensive reasoning models in exploration, discovery, analysis, and what might best be described as thinking things through. Once the problem is understood and the implementation path is clear, a faster and cheaper model may be sufficient to carry out the work. We have therefore recently gained something we did not previously have: not simply another agent capable of writing code, but a partner that can help us decide what should be done before the code is written.
A New Phase: Discovery and Learning
The analysis above, which applies primarily to Fable and perhaps also to GPT-5.6 Sol—although I think it is still too early to equate the two models—leads us towards an important conclusion. We can now introduce another phase into the way we work with AI agents. I currently use the working name Discovery and Learning for this phase. Until recently, I thought about working with AI mainly in terms of three abstract phases: planning, implementation, and review. We would first prepare a detailed plan, then implement that plan, preferably in smaller stages, and finally review the result. The review could be performed with the help of another AI model, but it was often the point at which we wanted another person (or simply ourselves) to inspect the code and make sure that it was correct.
We can now add Discovery and Learning before those existing phases. Its purpose is not yet to produce an implementation plan, but to determine how a given problem might be solved in the first place. During this phase, we try to understand what we are missing, what we would need to know to confirm that the problem has actually been resolved, and where the gaps in our thinking or understanding may be. The model can help us examine the problem from different perspectives, identify assumptions we have not questioned, suggest what data we should collect, and propose which direction may be worth exploring. In other words, this phase helps us learn enough about the problem before we begin planning a concrete solution.
In my current model of working, Fable is the reference model for Discovery and Learning, Opus is the reference model for planning, and Sonnet is the reference model for implementation. This should not, however, be treated as a rigid rule or as a recommendation to switch models after every phase. Prompt caching and the cost of rebuilding context matter, and moving work between models is not always economically sensible. OpenAI’s current GPT-5.6 pricing, for example, explicitly distinguishes between uncached input, cache writes, and discounted cache reads, which illustrates why the economics of maintaining context cannot be ignored. Sometimes it is cheaper and simpler to continue with the same model, particularly when the implementation is small or the model already has all the relevant context. The assignment of models to phases is therefore a useful abstraction rather than a strict workflow.
This is where my approach differs slightly from a trend I often see on Twitter and LinkedIn. Many people are trying to create a single standardised workflow in which every ticket is transformed into a specification, a business requirements document, or another predefined set of artefacts. My problem with these formal processes is that they tend to put every task into the same category: we always do A, then B, then C, and finally D. That does not reflect the reality of engineering work. Tasks vary considerably in their size, uncertainty, risk, and complexity, so forcing all of them through the same process introduces unnecessary work without necessarily improving the result.
I prefer to treat Discovery and Learning, planning, implementation, and review as optional phases. When I begin working on a task, I first consider which of them are actually required. If I want to refactor a single class, I may simply use Sonnet to perform the implementation and then review the change. If I want to implement a reasonably well-understood feature, I may begin with planning, move to implementation, and finish with review. If I am trying to determine how an unfamiliar or poorly understood problem should be solved, I may go through all four phases. Thinking about them as abstract and optional elements allows me to decide how formally I want to approach a particular task instead of applying the same workflow regardless of its nature.
At the same time, working with AI generally makes greater formality more worthwhile than it used to be. In testing terms, it is often worth producing a test plan, defining a test strategy, and generating and presenting test reports. Creating these documents with the help of an agent is relatively easy, but the documents also become part of the agent’s context and help it understand more precisely what we are trying to achieve. The same applies to implementation plans, decision records, acceptance criteria, and summaries of what has already been learned. These artefacts are not merely documentation created for humans after the work is complete; they can actively improve the quality and consistency of the agent’s work.
For this reason, when I am uncertain about whether a task requires a more formal approach, I usually default to creating the plan, writing down the assumptions, and describing the expected outcome. My default is to be slightly more formal rather than less formal, because the cost of producing these artefacts has decreased and their value as context has increased. This does not mean that every task must follow a large and rigid process. It means that formality has become cheaper, while good context has become more valuable. The important thing is to select the phases deliberately and adjust the process to the problem, rather than allowing the process to define the problem.
Skills
Staying with coding, but moving towards the broader transformation of white-collar work, I would like to revisit the subject of skills. I covered their technical aspects in some detail in my post about AI Testing Skills, but my opinion of them has continued to evolve. Skills were initially received with a relatively lukewarm reaction, at least from what I observed. The concept seemed trivial, perhaps even slightly naive. Wrapping a collection of documents in an abstract concept called a skill appeared unnecessary. The more closely I work with skills, however, and the more of them I create and see in practice, the more convinced I become of their value.
It is worth explaining clearly where I see their value. In my opinion, skills should be created by domain experts. A security specialist should create skills related to security, while a testing specialist should create (or at least recommend and validate) skills related to software testing. As a side note, I strongly recommend the Playwright CLI skill, which I described in detail in Playwright CLI, Skills and Isolated Agentic Testing. Playwright’s official documentation describes these skills as structured reference material that teaches coding agents how to use the CLI and its workflows, and the skill is maintained within Microsoft’s Playwright CLI project. This is also a good example of a skill being created close to the domain and the tool that it represents.
The greatest value is not simply that a domain expert writes down factual knowledge. A useful skill should contain more than descriptions of how individual commands, tools, or technologies work. It should also explain how a particular problem ought to be approached: what should be checked, what should be done first, what should happen at the end, and how we can determine whether we are moving in the right direction. It should describe what a good outcome looks like, when the work can be considered complete, and which warning signs suggest that something is going wrong. This procedural and judgement-based knowledge is often much more valuable than a list of instructions.
Writing this knowledge down allows us to see how a domain expert thinks. We can observe what that person pays attention to, what they deliberately ignore, where they begin, what they leave until later, and which conditions they use to decide whether the task has been completed successfully. We can also see when they decide that an approach is incorrect and should be abandoned. This is invaluable knowledge because it gives us some insight into another person’s reasoning process. A good skill does not merely tell an agent what actions are available. It captures at least part of the mental model that an experienced person applies when deciding which actions should be taken and in what order.
This observation has another important consequence. Creating a skill is relatively easy, but we should avoid creating authoritative skills for areas in which we are not experts. A Java expert should not create a Python skill simply because producing the necessary Markdown files is technically straightforward. Instead, we should ask someone with genuine expertise in that area to create or review the skill, or we should first consider what we would need to learn in order to become sufficiently competent ourselves. The objective is not merely to produce a skill. The objective is for a skill to capture how an expert approaches a particular type of task.
I have found that reading skills created by experts can itself be highly educational. Observing how experts describe a problem, divide it into stages, define success, and warn against common mistakes has considerable learning value. Even when a particular skill is not used frequently by an agent, I still believe that creating it may be worthwhile for an organisation. It records valuable knowledge that might otherwise remain in someone’s head, be scattered across conversations, or disappear when that person changes teams. In that sense, a skill can become a practical and reusable form of organisational knowledge.
For this reason, I recommend creating skills, reusing them across teams, and building internal marketplaces through which people can discover and share them. I now see significant value in this idea, and I admit that this has surprised me because I was certainly not an early adopter. It was only after seeing the effectiveness of the Playwright CLI skill that I truly became convinced. The fact that it was created within Microsoft’s Playwright project also supports my broader argument: the most valuable skills are likely to emerge close to the domains, tools, and experts whose knowledge they are intended to capture. We should not think of them merely as packages of documentation. At their best, they are a way of preserving and distributing expert judgement.
The White-Collar Revolution and AI Agents
In my earlier post about Agentic Testing, I concluded that the harnesses (which at the time we still tended to call AI agents) were becoming increasingly capable of performing tasks that required operating a computer, including software testing. What is happening with these tools now leads me towards a much broader conclusion. Features such as automatic approval, which offer something between manually accepting every action and allowing everything without supervision, make agents considerably more practical for everyday work.
This leads me to another thesis: we are now witnessing a major transformation of the labour market, not only among engineers or within the IT industry, but across white-collar work more generally. I strongly encourage people to experiment with performing as much of their work as possible through agents. When I edit videos, for example, I use Codex. This is certainly not the ideal use case for a coding agent, but perhaps that is precisely the point. It demonstrates that a significant amount of intellectual work can already be accelerated with harnesses that were originally designed primarily for software development.
This brings us to another conclusion. Everyone who works in an office, and perhaps everyone whose work is performed primarily in front of a computer, should begin learning how to use AI agents effectively. Before long, this may no longer be a skill expected mainly from software engineers. It may become a skill expected from people across a wide range of knowledge-based professions. This is admittedly a bold conclusion, but it becomes less surprising when we look at what these tools can already do. I use Codex and Claude Code to organise files, investigate CPU usage, create new files, clear disk space, manage routine computer tasks, prepare drafts of messages, and work with email and calendar information. These are ordinary activities rather than spectacular demonstrations, but together they suggest the beginning of a much larger change.
This change is no longer based only on personal observations or experimental use cases. We can see substantial investment in this direction from the largest AI companies. Anthropic offers Claude Desktop, which brings the agentic capabilities of Claude Code into a visual interface and allows users to delegate long-running work such as research, file organisation, document generation, spreadsheets, and presentations. OpenAI has introduced ChatGPT Work and Codex-powered workspace agents, which are intended to perform multi-step tasks across files, connected applications, code, and organisational workflows. These agents can prepare reports, draft messages, update business systems, operate on schedules, and continue working while the user is elsewhere.
We also have increasingly powerful connectors and plugins. In many cases, these are MCP servers presented through a convenient and accessible interface. Agents can connect to Slack, Gmail, Google Drive, Google Calendar, SharePoint, GitHub, and many other services. They can search organisational knowledge, read documents, analyse conversations, prepare drafts, and take actions in external systems. Organisations can also create custom connectors for their internal applications and data sources. Instead of manually moving information between Confluence, Google Docs, Slack, email, internal databases, and various APIs, we increasingly have one place from which an agent can gather the necessary context and perform the work.
The fact that so much can be done from a single interface may genuinely change how office work is organised. It is possible that systems of this kind will eventually be used as frequently as email or instant messaging within organisations. Employees may begin their work not by opening five different applications and manually transferring information between them, but by describing the desired outcome to an agent that already has controlled access to the relevant tools and sources of knowledge. This is an important development, and I recommend that people working in office-based roles familiarise themselves with it. It may still feel new, but it is increasingly becoming one of those capabilities that it is simply better to have than not to have.
My practical recommendation is therefore to learn how to perform as much computer-based work as reasonably possible with the help of a coding agent. This does not mean delegating everything or trusting every result without verification. It means developing an understanding of which tasks can be delegated, how they should be described, what context the agent requires, where approvals should remain in place, and how the result should be reviewed. The ability to manage the agent and design an effective workflow around it may become as important as the ability to operate the individual applications that the agent uses on our behalf.
While discussing office work, it is also worth paying more attention to Computer Use, which I believe is still discussed less than it deserves. Computer Use allows an LLM-based agent to see and operate graphical user interfaces: it can click, type, navigate through applications, change settings, work in a browser, and access information that is not yet available through a structured integration. In the ChatGPT desktop application, Computer Use is available through Work and Codex. On macOS, it can perform a scoped task in the background while the user continues working elsewhere, although its behaviour and limitations differ between operating systems.
Watching this happen can feel rather surreal. At times, using Computer Use feels as though two people are working on the same computer: I continue with one task while the agent performs another. It is particularly valuable in places where an appropriate connector does not yet exist or where we have not yet given the LLM structured access to a particular application. The agent can temporarily bridge that gap by operating through the user interface in much the same way a person would.
Of course, clicking through an interface is usually less reliable and less efficient than using a well-designed connector or API. When we notice that an agent repeatedly performs the same workflow through the UI, this may be a good indication that we should create a proper connector for that application. Computer Use should therefore not necessarily replace structured integrations. It can complement them, cover applications that are not yet integrated, and help us discover which workflows are valuable enough to automate more formally. Nevertheless, it is another capability that may soon transform office work—or perhaps even revolutionise it.
The Cost of the Revolution
Whether or not we call the current change a revolution, we need to talk about costs. Using Claude Code, Cursor, Codex, and the most capable models is not cheap, particularly for companies that cannot rely on flat-rate individual subscriptions and instead have to pay according to usage. In that model, the rule is simple: the more tokens the organisation consumes, the more it pays. We should be honest about the fact that this can become expensive, especially when using models in Fable’s class. At the time of writing, Anthropic prices Fable at $10 per million input tokens and $50 per million output tokens, before taking prompt caching into account. For sufficiently long tasks, with large contexts, multiple iterations, tool results, and substantial output, a cost of $20 or even $30+ for a single task is entirely possible.
This creates a rather interesting situation. A significant part of how people use Codex, Cursor, or Claude Code is influenced by posts and recommendations from people working at the companies that build these products. What is often missing from those recommendations, however, is a serious discussion of cost. People developing the tools may operate in environments in which access to tokens is effectively much less constrained than it is for ordinary customers. As a result, advice that makes perfect sense inside Anthropic or OpenAI does not necessarily translate directly to a company that receives a usage-based invoice at the end of the month.
For example, I have recently seen recommendations to generate rich HTML documents where a much more compact Markdown document might be sufficient. The result may look better, but it can also require significantly more tokens to produce, inspect, and modify. We are also seeing the introduction of routines, loops, scheduled agents, and other workflows in which a model is invoked automatically, perhaps every hour. From the perspective of an engineer working at a model provider, having a cron job with an element of intelligence built into it may be extremely useful. From the perspective of an employer paying for every invocation, running an expensive model every hour—including throughout nights and weekends—may appear slightly insane. A poorly designed loop can generate a surprisingly large bill without necessarily producing a proportionate amount of value.
It may therefore be worth asking whether Anthropic and OpenAI should invest more visibly in helping customers reduce their costs. Public-cloud providers such as AWS and GCP employ specialists who help organisations optimise infrastructure expenditure, partly because customers that cannot control their cloud bills may eventually reduce their usage or move elsewhere. I do not yet see the same level of cost-optimisation competence being promoted by the major AI providers, although perhaps some of it exists behind the scenes. To be fair, the situation is beginning to improve. Anthropic now publishes detailed guidance on controlling Claude Code expenditure and explains mechanisms such as prompt caching and automatic context compaction. Its prompt-caching documentation also makes the financial benefit explicit: a cache hit can cost only 10 per cent of the normal input-token price. OpenAI similarly offers discounted cached input and documents how prompt caching affects usage costs. The subject is therefore starting to receive attention, but in my opinion it is still discussed too slowly and too rarely.
Returning to the main issue, the costs are significant, and organisations need to decide how they want to manage them. One approach I would recommend is introducing reasonable limits or budgets per person. The purpose should not be to prevent employees from using AI agents, but to create a natural incentive not to perform every task with the most expensive model available. Engineers should be encouraged to consider whether a task requires Fable, whether Sonnet would be sufficient, whether the context can be reduced, whether previous work can remain in the prompt cache, and whether an automated loop truly needs to run every hour. Cost should become one of the normal engineering constraints considered when selecting a model and designing an agentic workflow.
At the same time, initiatives that celebrate who has consumed the most tokens are, in my view, pointless. We should not encourage people to burn tokens simply for the sake of burning tokens. High usage is not automatically evidence of high productivity, just as a high cloud-computing bill is not evidence of a well-designed system. What matters is whether the tokens were used reasonably and whether they generated sufficient value. It makes sense to measure usage, introduce alerts and limits, and make people aware of the cost of different models. It does not make sense to glorify consumption as an achievement in itself.
There is, however, another side to the problem. We also want people to use these tools extensively, particularly while they are learning. We want them to understand the limitations of individual models, discover which tasks can be delegated, become interested in the subject, and ultimately perform their work more quickly. Experimentation inevitably includes some waste. A person learning to use agents will sometimes choose the wrong model, provide too much context, run an unnecessary task, or follow an approach that does not work. If the organisation treats every unnecessary dollar as a failure, employees will become afraid to experiment and will never develop the competence that the company will soon expect them to have.
There is therefore a natural tension between cost control and learning, and I do not think I yet have a complete answer for how every organisation should resolve it. Costs certainly need to be measured and, where necessary, limited. Excessive usage should not be glorified. At the same time, experimentation and education should be actively encouraged. One practical option may be to distinguish between production budgets and learning budgets, accepting that the purpose of the second category is not always to generate immediate business value. Managers should also communicate clearly that working effectively with AI agents is becoming a useful professional competence. It is fair to expect employees to develop this skill, but it is equally fair for employers to give them access to the tools and sufficient room to learn.
From my own perspective, I have been paying for these tools for more than two years—initially subscribing to Cursor and now using Codex—and I consider it an excellent investment. I do not regret it, and I intend to continue. I would also encourage people who have the opportunity to use agents for their personal projects: create a website, build a small product, automate something at home, or work on tasks within an environment they fully control. In a personal context, we can sometimes afford to take slightly greater risks, enable broader approvals, try unconventional workflows, and see what happens. This is often the best way to understand both the power and the limitations of these tools. Costs matter and should not be ignored, but avoiding experimentation altogether may ultimately prove far more expensive.
Can Open Models Replace Frontier AI?
The discussion about costs naturally leads us to open-weight models and the possibility of replacing the leading commercial solutions with infrastructure hosted inside an organisation. It is worth being very clear about the current situation, because social media is full of sensational claims that are not always reflected in reality. The fact that the weights of a capable model are publicly available does not mean that deploying it is simple, inexpensive, or equivalent to replacing Claude Code or Codex overnight.
We now have GLM-5.2, a Chinese model that can be deployed within a company’s own infrastructure. That is an important development, but deploying and maintaining it would be a substantial and expensive engineering project. GLM-5.2 contains 753 billion parameters, supports a context of up to one million tokens, and is designed for long-running coding and agentic tasks. Its unquantised weights alone would occupy roughly 1.5 terabytes, so this is not a model that we can simply run on a developer’s laptop or on an old server left over from a previous project. A serious deployment would require powerful accelerators, distributed inference infrastructure, monitoring, security, capacity planning, and people capable of operating the entire system. Kubernetes is not strictly required, but some form of orchestration and scaling would almost certainly be needed in a production environment.
It is therefore important to remember that the ability to download a model does not make it cheap or easy to use. A company would need to make a significant investment before it could offer such a model reliably to hundreds or thousands of employees. The infrastructure would need to be maintained, upgraded, secured, and scaled according to demand. Someone would also need to manage model versions, inference frameworks, quantisation strategies, context limits, throughput, latency, and failures. Self-hosting moves the problem away from usage-based API invoices, but it does not make the costs disappear. It replaces token costs with hardware, energy, engineering, and operational costs.
There is also the question of capability. GLM-5.2 is an impressive model, and its creators’ own benchmarks place it close to frontier proprietary models on a number of coding and agentic evaluations. At the same time, those same reported results show that Claude Opus 4.8 remains ahead on many of the most demanding coding tasks. I would not consider GLM-5.2 equivalent to Fable, particularly during the Discovery and Learning phase described earlier. In my view, discovery performed with GLM-5.2 would probably be shallower. We should not expect the same number of insights, the same critical perspective, or the same quality of high-level reasoning that we currently receive from the strongest proprietary models. Even after making a significant investment in self-hosting, we should not assume that we will be able to reproduce every workflow we currently perform with Claude Code and Fable.
The more interesting question is whether large companies should nevertheless begin building competence in this area. Assuming that Chinese, American, and—hopefully—European organisations continue publishing capable open-weight models, it may be sensible to develop the engineering knowledge required to host them. This would include selecting appropriate hardware, operating inference servers, scaling workloads, optimising utilisation, monitoring quality and performance, securing model access, and integrating the models with internal systems. These are relatively new organisational capabilities, and companies will not acquire them immediately simply because a promising model becomes available.
A hybrid approach may eventually make more sense than attempting to replace commercial models completely. We could, for example, perform Discovery and Learning with Fable and then use a locally hosted model for planning, implementation, or review. Once the organisation has paid for and reserved the necessary computing capacity, teams may be able to iterate much more freely without thinking about the price of every individual token. Prompt caching would become less financially important, although utilisation, latency, queue length, and available GPU capacity would replace it as the constraints we need to manage. A local model would not be free, but the economics and the incentives would be different.
I do not have a definitive answer as to whether this investment is already worthwhile. The answer will depend on the size of the organisation, the number of users, security and data-sovereignty requirements, expected utilisation, and the quality of the models required for its work. From my perspective, however, we have reached the point at which larger organisations should at least have this discussion. They should evaluate the total cost of ownership, run realistic proofs of concept, and compare the quality of locally hosted models with the commercial services they already use. What I would not recommend is assuming that an open model is automatically a cheap and direct replacement for a frontier subscription.
The situation is even clearer when we look at models that can genuinely be run on a local workstation. As I mentioned in my post about local image generation with Bonsai, I bought an M5 Mac that allows me to run Qwen3.6-27B. Qwen3.6-27B is one of the strongest models currently available in its local size class. It contains 27 billion parameters, was released with open weights, and was designed partly for agentic coding and repository-level work. However, Qwen3.7 is already the newer generation, and Alibaba has not so far released a directly comparable Qwen3.7 27B model with open weights. Qwen3.7 is presented as the company’s newer agent-focused family, while Qwen3.6-27B remains the available local model in this particular size category.
This demonstrates another risk of relying on open-weight models. Users cannot force Alibaba—or any other provider—to publish a newer model in the size and format they require. A company may build a workflow around a particular open model and then discover that the next generation is available only through an API, is released only at a much larger scale, or is not released openly at all. Open weights give us control over the model version we already have, but they do not guarantee continued access to future improvements.
Qwen3.6-27B can work with a harness such as OpenCode and is capable of writing code. In my practical experience, however, the quality of that workflow remains far below what I get from Sonnet. With Sonnet, I can often explain what needs to be achieved and allow the model to inspect the repository and determine which files should change. With Qwen3.6-27B, I usually need to point it towards the exact file, explain the required modification in much more detail, and then go through several additional iterations. The model is capable of producing code, but using it requires much more supervision, more precise prompting, and considerably more patience.
From the perspective of someone accustomed to paid frontier subscriptions, the model can simply feel unintelligent. In my experience, it is not yet close to the usability of Sonnet, and I would place the overall agentic experience below even the cheaper proprietary models like Haiku and GPT-Mini. The workflow is inconvenient, inefficient, and frequently frustrating. To put it plainly, it does not yet work well enough for broad organisational adoption.
For now, I see this path primarily as something for enthusiasts, researchers, and people who have been working with local models for a long time. Extracting meaningful value from a 27B model requires a good understanding of prompt engineering, model configuration, context management, quantisation, and the limitations of the chosen harness. Even with that expertise, the value may remain relatively small compared with the effort required. Local models are becoming more capable and are certainly worth observing, but today they should not be presented as a straightforward replacement for paid access to frontier models. We may eventually reach that point, but we are not there yet.
Conclusion
The word revolution may be too strong, but the underlying change is real. I wanted to record these observations at a specific moment because this blog also serves as a kind of personal journal. Returning to older posts shows just how quickly the tools (and the way we think about using them) continue to evolve.
Not that long ago, we had to provide an entire codebase to models such as o1 or o3 in order to generate a plan, and only then could we copy that plan into a coding agent for implementation. We are now very far from that way of working. Today, we can often begin with the problem itself. We do not necessarily need to know in advance how a particular issue should be solved, because the model can help us explore possible directions, identify what we are missing, and decide what should happen next. Whether we call this a revolution or not, it is undoubtedly a significant change.
We are also seeing a major expansion in what coding agents can do outside coding itself. They are becoming increasingly capable of operating computers, supporting office work, and helping with a much broader range of intellectual tasks. At the same time, costs remain in the background, and we should not forget about them. They can and should be monitored and controlled. We can improve productivity by creating skills, and we can slowly begin thinking about replacing some commercial usage with locally hosted models, although we are still far from a simple replacement for the leading paid solutions.
Where all of this will lead remains difficult to predict. Models will improve, costs may fall, local solutions may become more practical, and the distinction between coding agents and general-purpose work agents may continue to disappear. For now, these are simply my observations at this particular moment. As we say in Poland, time will tell.
Comments
Loading comments...