Rita Sheth — Founder, Product Architect & Strategist

There is an active debate happening right now in a lot of companies: should we build this ourselves, or buy it?

With vibe coding and cheap AI execution, a small team can build and ship fast. So they are looking at products they currently pay for and asking whether they could just build their own. And to be honest, it has scared a lot of AI startups. The worry is also if we show people what our product does, will they just reverse engineer it?

At first I though this was an existential threat to start-ups but now I am pretty sure it is not because I have come to the conclusion that in most cases buying still makes more sense for most types of software and for most types of companies and is often the better strategic and financial choice. 

Firstly building it yourself is not as cheap or as easy as it looks because it's not just about the working first version it's about iterating that to fit your needs and get something that really will get adopted and used and make a valuable difference. That part hasn't been solved or made easier with the availability of rapid prototyping tools.

The hard part is not a quick build, it is getting a decent piece of software over the line — reliable, secure, maintainable and integrated enough to run a real part of the business. That takes longer than people think. It doesn't just need engineers, its need a product lead, and a business owner - which also means hiring a team not just one person. Decent AI engineers and product people are not free, and the market for them is competitive. An internal build that looked like a saving can cost much more than a yearly subscription and is less flexible. You are kind of stuck with it, whereas with a vendor you can move on if its not a good fit.

But the larger argument is not really about building the first version. It is about maintaining it for years after. And really there is no point having something in-house if it is badly maintained, if you are not going to invest long term, its a wasted investment in time and money.

To keep pace with the best tools, a company has to dedicate serious resources to a problem that is not its core business. A third-party vendor is incentivised and dedicated to only that thing: make their software as capable and competitive as possible, because that is what keeps it alive. Their entire existence depends on it. Your internal team, however talented, is not subject to the same pure market pressure. They are pulled in many directions. Their incentives are tied to your broader company, not to making this one piece of software the best in its category. Over time that creates a predictable gap. The purchased product keeps improving. The internal product survives and probably languishes somewhere down the team's to-do list.

The other reason teams want to build in-house is because of IP and customisation. Both are really procurement issues, not build-versus-buy issues.

On IP and compliance, that is exactly what policies, compliance and contracts are designed to protect. The risk obviously does not completely disappear, but we have often seen just as large privacy and data protection failures in-house as with a third-party vendor. There is no implicit elimination of risk just because you keep data inside your own walls. A careful procurement process gives you a known, managed risk rather than an argument for building everything yourself. It can also be a way of passing off risk rather than owning it yourself.

On customisation, it is tempting to think that unless we build it ourselves it will not be exactly fit for purpose. That's no longer true. The real point is that we can use AI efficiencies to make off-the-shelf products much more intelligent, brand-aware, agentic and personalised. The same capabilities that allow companies to build also allow vendors to capture those efficiencies and offer customisation, support and configuration at much lower cost. AI has made it possible to make something feel so well-configured that it feels bespoke, even when it is not.Of course at higher values, real customisation is also available plus dedicated support and a touch points which makes the argument for building in-house even weaker.

There is a related trade-off that is often framed as a downside but can actually be an advantage. When you buy from a vendor that serves many customers, the system gets better because it sees patterns across many organisations, not just yours. Your data and processes can contribute, with the right controls, to a broader learning loop. Done properly, network effects create a better product for everyone. Done badly, it creates a privacy problem. As we have seen at the big social media companies, it is a double-edged sword, and the distinction between customer-specific data and generalised system learning matters enormously. But the underlying point stands: network effects and compounded learning on what makes a product better, does make the product sharper than any single internal team could keep it.

All of this does not mean building is always wrong. There are clear cases where in-house makes sense. The question to ask is often "is this central to how we work every day, specific to us, and stable enough that we do not need it to keep up with the market?"

A good example is a productivity tool or CRM tool. They both deal with basic functionality that does not require constant maintenance to deliver value as an in-house product. And the benefits probably outweigh the cost, because then you can really make it work for how you manage customer data and your sales process, for example. In fact, I built my own CRM because of this exact reason: every sales team works differently, and we all like to organise our tasks in different ways. So in this case a quick build for that added convenience makes sense. In that middle ground — important enough to affect the core business day-to-day, specific enough to be awkward to configure in someone else's product, simple enough to maintain and worth the cost — building can be the right call.

Another sensible case is a proprietary dashboard or reporting layer that shows exactly what your leadership team looks at each morning. The underlying analytics engine is almost always better bought. But the particular view, thresholds and alerts that map to your operating rhythm are sometimes not worth forcing into a generic tool.

But for most of the things people might replace external software with in-house builds for, it doesn't make sense. Even things that appear simple like AI content engines, video pipelines or drafting software can be complex or depend on underlying models and algorithms that need to be constantly improve and iterated to work. They need continuous improvement, and it is often much better to buy carefully, with controls in place, than make your own. The time would almost always be better spent working with a specialised provider and shaping the product so it feels as though it was designed for you, even when, strictly speaking, it is not.

I also suspect the current enthusiasm for building is partly a phase. It is exciting to discover that a small team can ship something impressive in a weekend. It is less exciting to maintain that thing for three years while the external market moves on. Many internal builds start strapped onto the core business, funded by diverting budget or hiring someone to own the product internally. Then the champion leaves, the budget gets reallocated, the business changes direction, and the system becomes technical debt nobody wants to touch. The project gets shelved not because the people were not capable, but because it was always a distraction from the company's actual work.

My prediction is that we are in a cycle. Most organisations will probably return to a clearer distinction between what they must own and what they should just rent. The specialised providers will keep getting better, not just because they have more resources, but because their entire existence depends on it. And the companies that resist the temptation to build everything themselves will generally have sharper, more maintainable stacks and more focus on the work that actually matters. They will discover that it is better to make your main thing your main thing. And even when it is your main thing, thing contract drafting for law firms, its still better to make someone else customise it for you and have a dedicated point person, then tie up your tech team for years.

That does not mean you should not hire an AI developer or innovation consultant. I just suspect the better use of their time is auditing options and working with the vendor to customise the offer, rather than building something from scratch. They will not tell you that, of course, because no engineer wants to be a secret procurement person.

Product–market fit is one of the most used phrases in startups. Founders are told to "find PMF" as though the journey is binary — either the market wants what you have built, or it does not. In practice, there are several distinct stages between identifying a real problem and building a product the market repeatedly chooses, pays for and keeps using. That distinction matters, because different failures require completely different responses. It also prevents founders from giving up when they have found a problem that is genuinely painful, and a market that appears to feel that pain, but something still will not stick. In that case, one of the bridges between pain and market is broken — and the only useful question is which one.

A better way to think about early product development is as a chain: problem validity, pain and priority fit, product–mechanism fit, proposition and perception fit, adoption and value fit — and only then product–market fit. Each stage answers a different question. If you skip over the distinctions, it becomes very easy to diagnose the wrong problem. You might change your target customer when the mechanism is weak. You might rewrite the landing page when the product cannot yet prove its value. You might build more features when the real issue is adoption friction. Or you might conclude there is no market, when the market simply cannot yet understand why your product is better. Naming the stages turns a symptom into a diagnosis.

The first question is the most basic: is the problem real? Does the customer genuinely experience it — can you observe it in behaviour, cost, inefficiency, risk or missed opportunity? This stage has nothing to do with whether someone likes your proposed solution. A team may make important decisions using fragmented spreadsheets and repeated meetings; that establishes that a problem exists, but it does not establish that they want your software. If the problem is not real, no amount of good product will save you. But if it is real, you have only cleared the first bridge.

The second question is whether the problem matters enough. A problem can be real without being important. This is where many founders get misleading signals, because a potential customer might agree with everything you say and describe the problem in exactly your language — yet if the consequence of doing nothing is small or easily tolerated, the problem never reaches the top of the buying list. The test is not "does this hurt?" but "does it hurt enough, for the right person, at the right moment, to justify action?" That is a different threshold. You can have a real problem and a sympathetic buyer who still will not prioritise it.

Then comes the stage I think deserves far more attention than it gets: does the product actually contain a mechanism that can be easily demonstrated to move the customer from their current state to a meaningfully better one? Not "does it have useful features", not "does the AI produce impressive outputs". The test is whether, in a thirty-second explanation, you can show how you move from A to B in extremely simple terms. Can the product take a real decision from A to B, and make it obvious why B is better? A strong mechanism has a visible causal chain — context in, intervention made, result observable. The user should be able to understand what changed because the product was involved.

This is why feature-rich products can still feel strangely unconvincing. Until the causal mechanism is obvious, adding more surrounding functionality makes the product feel more sophisticated while making the core value harder to see. That was an important principle at MercuriDash. Our internal test was whether the system could move a real product decision from A to a visibly stronger B, without needing founder interpretation to explain why it was better.

Even a strong mechanism will not sell itself. The next stage is proposition and perception fit: does the market understand what the product does, believe it will work for them, and feel motivated to act? A founder may see the causal chain clearly, while the market sees only features, jargon or an abstract promise. Proposition fit is the work of translating the mechanism into a concrete transformation the customer can picture themselves experiencing. It is not enough that the mechanism is logically sound; the right person has to grasp it in the right context without effort. If your messaging describes internals, features or broad benefits rather than the specific before-and-after state the customer will reach, perception breaks down. The aim is to take them from A to B in their imagination with no gaps, no blank filling and no doubt about whether they will end up better off.

A lot of time is spent on finding a painful problem. But much less time is spent interrogating whether the solution actually solves the problem, and whether it can be expressed in a straightforward cause-and-effect way. Having product–mechanism fit and proposition fit together means you can sell more easily, because you can show the mechanism to anyone and it captures the a-ha moment. In part this is the work of ingenious sales teams that go beyond selling to sales engineering — fitting demos to problems, closing the perception gap and making mechanisms crystal clear. However, increasingly this is something the founder and product lead need to think through before sales ever gets involved.

Then comes adoption and value fit. The customer understands the mechanism, believes the promise and is motivated enough to act — but can they actually get to value? This is where onboarding, friction, trust, switching cost, implementation and first-run experience become decisive. A product can have a strong mechanism and a clear proposition and still fail because the path from sign-up to first successful use is too long, too complex or too uncertain. The question here is not whether the product works in theory; it is whether the customer can make it work in practice, and whether the value they receive exceeds the effort they had to expend. Repeat usage, retention and willingness to pay all live at this stage.

Only when those pieces hold together does the broader PMF question become meaningful. Product–market fit emerges when the problem is real, the problem matters, the mechanism works, the market understands the mechanism, customers can actually adopt it, and the resulting value is strong enough to drive repeat usage and willingness to pay. Which is why "we don't have PMF" is often too vague to be useful. It tells you the destination has not been reached. It does not tell you which bridge is missing.

Of all the stages, I suspect product–mechanism fit and proposition fit are the ones that matter most for AI startups right now. The cost of building features has collapsed. The cost of generating impressive demos has collapsed. So the harder questions have become: what is the proprietary cause-and-effect loop inside your product? And can you express it so clearly that the right customer believes it before they have even used it? A useful mechanism should survive being stripped of its interface. Remove the dashboard, the branding, the animations, and what remains should still be a clear transformation from A to B. But a clear mechanism still needs a clear proposition, because customers do not buy engines — they buy the better state the engine creates.

So when a startup feels stuck, instead of asking "do we have product–market fit yet", I think the better questions are these. Is the problem demonstrably real? Is it important enough for someone to act? Does the mechanism by which we solve the problem actually work? Does it have a logic that is obvious? Can the customer understand and believe that mechanism? Can they reach the value easily enough? And only then — does the market repeatedly choose and retain it? The sequence is not perfectly linear; you will move backwards and forwards between the stages as you learn. But naming the stages turns a symptom into a diagnosis. "We haven't found PMF" is not a diagnosis. The useful question is which part of the chain is failing — and for many early AI products, the answer is rarely that the market has rejected the problem. More often, the product has not yet made its mechanism undeniable, or the proposition has not made that mechanism visible.

We taught AI how to build. Now we are beginning to teach it what is worth building.

For much of the current AI wave, the focus has been on execution. Can AI write the code? Create the image? Analyse the spreadsheet? Draft the copy? Research the market? Connect the systems? Complete the workflow? Increasingly, the answer is yes. The technical problems are by no means finished, but the direction is clear. AI is making execution dramatically cheaper and faster across software, design, research, content and operations. A capable person with the right tools can already produce things that would once have required a much larger team.

That creates an interesting consequence. As the cost of making things falls, the value shifts upstream towards deciding what should be made in the first place. The harder questions become: which problem is actually worth solving? Which opportunity should we pursue? What should the product do? Which version should we back? What should we change? What should remain untouched? What trade-offs are acceptable? And perhaps most importantly, what should we not do? These are not primarily execution questions. They are product strategy questions.

There is a tendency to describe product management as coordination: gathering requirements, maintaining roadmaps, writing tickets and moving work through a development process. But that misses the most valuable part of the job. A strong product strategist connects a vision to something that can actually be built. They translate an ambition into objectives, product architecture and priorities. They consider alternative routes. They balance evidence against instinct, short-term opportunity against long-term position, customer requests against product coherence, speed against quality, commercial potential against technical cost. And then they make choices.

Good product strategy is therefore not simply a plan. It is a continuous decision system: vision leads to objectives, objectives to architecture, architecture to options, options to trade-offs, trade-offs to decisions, decisions to execution, execution to outcomes, and outcomes back to learning. The loop matters as much as the initial decision. A good product leader does not simply decide once and assume they were right. They watch what happened, understand why, update their model of the problem and make a better decision the next time. Looked at this way, product strategy already resembles the architecture of an agentic AI system. And that may be where the next important frontier lies.

Most current AI interaction still begins with an instruction. Write this. Build this. Summarise this. Analyse this. Fix this. The human has already made the fundamental decision about what needs to happen. AI performs the work. A product-strategy agent requires a very different level of reasoning. Instead of being told to build Feature X, it might be given an objective: increase activation without materially increasing onboarding complexity. Now it has to understand the current product, available evidence, user behaviour, technical constraints and company strategy. It may generate several possible interventions. Then it has to compare them.

Perhaps one creates more upside but introduces substantial engineering work. Another is easy to ship but treats a symptom rather than the cause. A third improves activation but damages retention elsewhere. A fourth requires no new feature at all — only removing friction from something that already exists. The difficult part is not generating those four ideas. The difficult part is deciding which one deserves to happen. That requires judgement.

Generative AI has conditioned us to associate intelligence with producing more. More concepts. More alternatives. More code. More content. More possibilities. Product strategy often requires the opposite. Sometimes the intelligent decision is to preserve almost everything and change one thing. Sometimes it is to reject a superficially attractive opportunity because it pulls the product away from its strategy. Sometimes a customer request should not become a feature. Sometimes an underperforming experience requires a major rethink. Sometimes it requires nothing more than allowing the current idea enough time to produce evidence. And sometimes the correct answer is simply: do not build this.

That is a much harder form of AI than generation. A useful product strategist has to reason about what is fixed, what is flexible and what is actually causing the problem. It needs to understand that improving one objective can damage another, and that the highest numerical optimisation is not always the strongest strategic choice. In other words, it has to understand trade-offs.

This is where things become particularly interesting. Once an AI system is making decisions rather than merely executing instructions, there may no longer be one objectively best version of it. Imagine two highly capable AI product strategists looking at exactly the same opportunity. One has a strong bias towards rapid experimentation. It recommends shipping the smallest reversible test and learning from real behaviour. Another prioritises product coherence and believes the proposed feature creates architectural debt. It recommends waiting and solving the underlying problem properly. Neither is necessarily wrong. They have different philosophies.

One AI might systematically favour differentiation over market conformity. Another might favour margin over growth. One might tolerate significant technical debt in pursuit of speed. Another might be unusually conservative about platform architecture. One could be excellent at zero-to-one product creation because it places more weight on novelty and learning. Another might be exceptional at mature-product optimisation because it prioritises statistical confidence and incremental efficiency. Another might be particularly suitable for regulated environments because its threshold for uncertainty and risk is much higher. At that point, what we currently think of as model behaviour begins to resemble product leadership style. We may end up talking about AI product strategists in remarkably similar ways to human ones: that one is excellent at 0→1; that one is commercially aggressive; that one sees second-order effects incredibly well; that one over-optimises; that one protects the long-term product better; that one is brilliant at identifying when we should stop building.

There may never be one best AI. It would have been reasonable to expect AI to become winner-takes-all. Intelligence benefits enormously from scale, so perhaps eventually one model would simply become better than everything else and everyone would use it. Yet that is not how the market currently feels. People already move between different general-purpose models. Developers use different coding agents for different kinds of work. Creative professionals switch between image, video and design systems. And sophisticated users sometimes use several competing systems in parallel even when their headline capabilities overlap considerably. That is interesting because AI was supposed, in one sense, to commoditise capability. Instead, it may be creating another kind of differentiation.

Two systems can both be extremely capable yet feel meaningfully different in how they reason, communicate, prioritise and respond to ambiguity. That difference may become even more important as AI moves into strategy. Execution often has a relatively observable answer: the code works or it does not. Strategy rarely does. It involves values, time horizons, uncertainty, opportunity cost, organisational appetite and competing definitions of success. Different systems can therefore reach different conclusions without one of them necessarily being defective.

This is perhaps the deeper point. Once an AI is balancing several legitimate objectives, its judgement necessarily reflects priorities. Suppose a company is considering a new product. The evidence suggests strong demand, but the idea weakens brand differentiation. It could generate substantial revenue, but it creates operational complexity. It serves current customers, but it moves the company away from the market it wants to own in five years. What is the "correct" answer? There isn't one until someone determines how those objectives should be valued. That is strategy. An AI can help make those priorities explicit. Eventually it may learn them from an organisation's history: what leaders approved, what they rejected, which departures succeeded, where they repeatedly regretted compromising, and which decisions ultimately created value. But even then, the machine is not discovering some universal objective truth. It is developing a model of what good judgement means in this particular context. That is why I suspect the future of product-strategy AI will be more pluralistic than people expect. Different companies may need different strategic intelligences. And the same company may want different ones for different decisions.

None of this means that the CPO or product strategist disappears. If anything, it clarifies what their highest-value work actually is. Humans increasingly move from producing every artefact themselves towards defining the system within which decisions should be made. What are we trying to become? What are we unwilling to compromise? What constitutes success? Which risks are acceptable? Where should AI have autonomy? Where should it abstain? Which decisions require human judgement regardless of confidence? And when the evidence contradicts the organisation's existing assumptions, who has authority to change them? Those are governance questions, but they are also product questions. The senior product leader becomes partly the architect of the organisation's decision intelligence.

We are already moving from copilots that help people perform tasks towards agents that take responsibility for outcomes. The next step is not difficult to imagine. AI systems will increasingly help organisations decide what initiatives to pursue, which products to build, where products are weak, what interventions have the highest leverage, which bets deserve investment and which should be stopped. And crucially, they will be able to observe what happened afterwards. That closes the loop. A system that remembers the context, recommendation, human decision, intervention and eventual outcome can learn something much more valuable than a static best practice. It can begin to learn which kinds of decisions work here.

That is where AI stops being merely an execution engine and begins to resemble a product strategist. And it may also be where some of the most defensible AI products are built. Because when execution becomes abundant, judgement becomes scarce. The first era of generative AI was dominated by the question: how much of the work can machines do? The next may revolve around a harder question: how much of the judgement can they help us improve? We have spent the first era of AI teaching machines how to execute our decisions. The next era may be about teaching them how to help us decide what is worth doing in the first place.

And if that happens, the defining question may not be which AI is smartest. It may be: which AI has the right product judgement for the problem we are trying to solve?

Artificial intelligence is entering a phase that most venture funding models were never designed to support. Early AI companies were funded to prove technical feasibility; later-stage companies are funded to scale. A growing number of startups are now stalling in between. As AI products move from impressive early products into scalable organisations, the source of value creation shifts. Model capability matters less; integration, behaviour change and trust matter more so that you can unlock enterprise value. Customers are not simply buying software. They are being asked to change how decisions are made, how work is organised and how accountability is distributed. That takes time, training and experimentation, and it creates a phase of company-building that is capital-intensive, slow to signal success and still poorly understood by investors.

The traditional venture playbook works well for software that slots neatly into an existing workflow: build the product, sell it, scale it. AI is transformative and therefore behaves differently when scaling it to enterprise. Pre-seed and seed capital prioritise shipping and early traction, while growth investors expect predictable expansion. The difficult work required to move from one state to the other — educating users, redesigning workflows, building confidence in AI-supported decisions and adapting the product around real-world behaviour — is often treated as overhead, or assumed to resolve itself.

This creates a missing middle in AI investing: a post-build, pre-scale phase where otherwise strong companies can look weaker than they really are. Slow usage may be read as weak demand, friction as poor product-market fit, and early churn as a market signal rather than the cost of introducing a new way of working. Yet many AI companies are not failing because their products lack value; they are stalling because their customers do not yet have the capacity to adopt them quickly.

The uncomfortable part is that no single source of capital is especially well designed for this phase. Angels can be essential early believers but rarely have the mandate for slower, non-linear progress once a product is built. Traditional venture is good at scaling proven patterns but often uncomfortable with ambiguous traction or no traction while navigating the enterprise adoption gap. Corporate investors can bring domain knowledge and integration experience, but may move slowly or introduce different strategic incentives. Founders are left caught between investors expecting speed and customers needing time.

The more interesting question may be whether this integration phase creates space for new funding and operating models altogether. Some of the value may come from deeper customer partnerships, co-build arrangements or customers effectively funding part of the adoption journey through paid pilots, implementation work or strategic collaboration. There may also be a larger role for venture operators, specialist funds or private-equity-style models that are more comfortable with operational complexity, longer integration periods and hands-on value creation than traditional venture capital. None of these is necessarily the answer on its own, but the gap suggests an opportunity for capital structures that are better matched to how AI businesses actually move from technical capability to embedded use.

This is not an argument for lowering standards or subsidising weak companies. It is an argument for recognising that AI often creates new costs before it creates new returns, and that capital structures may need to reflect that reality. During this integration phase, the most useful signals may not be headline growth metrics, but learning velocity, depth of engagement, quality of implementation and whether the company is building the conditions for lasting adoption. This is in line with the change in thinking between the lean startup thinking of the 2000s and the build well thinking we are now moving into, when trust, security and stability are seen as a differentiator in a landscape full of sloppy products.

Investors who understand that may have an edge. Supporting companies through the messy integration period rather than pulling back at the first sign of friction creates the possibility of participating in the compounding that follows. More importantly, it reduces the risk of writing off strong businesses simply because they are solving real problems on timelines the market has not yet adjusted to.

AI is not just another software cycle. It is a general-purpose technology that changes how work gets done. Treating it as though it will follow familiar adoption curves risks systematic mispricing and missing opportunities for massive value creation. The question is whether existing funding models are prepared to support the transition.

A few months ago I wrote a paper about the way in which AI fails the creative industries, as a lot of AI products still do not really consider how different people naturally communicate. Some of us think visually, some verbally, some through sound, movement, examples or comparison. Yet most AI tools still begin with the dreaded prompt box, asking everyone to translate what is in their head into written instructions before the machine can do anything useful. We have used prompt boxes in our product, of course, but they need to be balanced with other types of input and used at times as a last resort, especially when we are trying to bridge the gap between the human and creative and the mechanical and logical.

A designer may know what feels wrong before they can explain why. A musician may communicate through sound. A creative director might work through references, mood, colour, association and comparison rather than a precise written brief. Asking them to convert all of that into text is not necessarily making the technology easier to use. It may simply be forcing people to communicate in the way the machine prefers.

There is a quiet inversion at work here. Prompt-based systems end up rewarding the people who can describe creativity well over those who actually practise it, giving an advantage to the prompt-writer rather than the practitioner.

Generative AI is now very good at producing text, images, video, audio and code, but the way we give it information has not developed at the same pace. A richer interface might let someone combine references, sketches, examples, taxonomy, emotional language, images, previous work and simple choices rather than trying to describe an entire creative vision in a paragraph. The point is not to remove language, but to recognise that natural language is much broader than words.

There is a cultural bias built into this too. Prompt systems privilege certain norms of expression, making some forms of communication easier for the AI to recognise than others, which is its own quiet kind of exclusion.

This becomes even more important when AI sits inside real business workflows. Different stakeholders often hold different parts of the knowledge: a designer understands the visual intention, a technical team understands what can be built, a commercial team understands the customer and someone else may understand compliance or production. If AI is going to sit between those people, it needs to help capture and hand off that knowledge without flattening it, misinterpreting it or quietly throwing away the parts that cannot easily be put into words. Human-in-the-loop oversight has a real role to play, but it should be there for judgment and compliance, not as a fallback for an interface that is hard to use. If people keep stepping out of the system just to make themselves understood, the model has failed, not the user.

For product developers, this means thinking beyond the model itself. Domain knowledge still matters, but so does understanding how the people in that domain actually think, communicate and make decisions. The best AI products may be the ones that learn how to meet users in those existing behaviours rather than training everyone to become better prompt writers.

The next step in AI interaction may therefore be less about teaching humans how to communicate with machines, and more about designing machines that can understand the different ways humans already communicate with each other.