Anyone who has done work on their own house knows the rule without ever having read it: painting a wall is a weekend job; changing a socket, carefully, too; touching the fuse box or knocking down a wall is another matter — it needs someone who knows what they are doing, and sometimes a plan and a permit. The criterion is not the size of the house. It is what happens if it goes wrong, and how much it costs to learn to do it well.
The same applies to AI, and the difference in 2026 is that the "do it yourself" tools have become very good. A manager with no technical training can today, with Codex, Claude Code or Copilot, build an automation, a prototype or an analysis that two years ago required a team. That is true and it is good. It is also true that it has never been easier to build something that works in the demo and that nobody can maintain three months later.
This article is an honest attempt to answer the question we are asked every week — "do we do this ourselves or do we need help?" — including the cases where the right answer is "do it yourselves", and there are many.
What these tools changed
It is worth separating three things that usually come mixed together.
Assistants in the editor. GitHub Copilot started as code suggestions inside the IDE and today also answers questions about the code and carries out tasks — but its natural place is beside someone who programs, speeding up what that person already knows how to do. If nobody is programming, there is nobody to make suggestions to.
Coding agents. OpenAI's Codex and Anthropic's Claude Code are a different category: they receive a task ("connect this form to the database and send an email when a request arrives"), read the project, write the code across several files, run the tests and hand back the result. They work in the terminal, in the editor, in the cloud. This is what lets someone without a technical team build real things.
The models behind them. The same LLMs that power these tools are available via API to build products and automations. That is another level of work, and the only one where the "do it yourself" tools are not enough on their own.
What the three have in common: they have drastically lowered the cost of starting. They have not lowered the cost of maintaining, of integrating, or of answering when something fails with customer data inside it.
When doing it yourself is the right answer
There are more such cases than a consultancy would like to admit. These are the ones we see working well without outside help:
Personal and team use. Summarising meetings, drafting the first version of a document, analysing a spreadsheet, writing a difficult email. No integration, no third-party data leaving the company (as long as the tool is the right one — see below), and the only risk is losing an hour. Do it.
Prototypes to make a decision. "Would an assistant over our knowledge base be any use?" The best way to answer is to build one in two days with a coding agent and show it to three people. A prototype like that is worth more than a forty-page feasibility study — and if you later decide to go ahead properly, the prototype is the best briefing a consultancy could receive.
Low-risk internal processes. A script that renames files, an automation that compiles a weekly report from three sources, an internal form. If it fails, someone notices and does it by hand. Not worth involving anyone from outside.
Technical teams that just need to speed up. If there are already developers, Copilot or Claude Code are productivity tools, not a project. It is up to the team to adopt them — with a warning, further down, about what the studies say.
When the goal is to learn. Some companies want the team to understand what AI does and doesn't do before deciding where to invest. Building small things, hands-on, is the best training there is. No course replaces it.
What these cases have in common: the cost of error is low, the data is yours and nothing depends on it working tomorrow morning.
When doing it yourself gets expensive
The signs that the job is no longer a weekend one:
Customer data. The moment the solution touches names, emails, contracts, invoices or purchase history, there is GDPR, there are processors, there is the question "where is this going?" Most of the problems we see in home-made solutions are not the code — it is the model receiving data it shouldn't, without anyone having decided that.
Integration with critical systems. ERP, CRM, invoicing, bank. A coding agent writes the integration in half an hour; what it doesn't know is that the customer table has three legacy fields nobody documented, that the ERP rejects updates outside working hours and that the sync running twice duplicates invoices. Anyone who has broken an integration like that knows what it costs.
Processes that cross teams. If the solution changes the way sales, operations and finance work at the same time, the problem has stopped being technical. It is process design, it is change management, it is deciding who does what. No coding tool solves that.
"It works on my laptop." The solution lives on one person's machine, with a personal API key, without version control, without anyone who understands it if that person leaves. It is the equivalent of an improvised electrical installation: it works until the day it doesn't.
No outcome metric. It was built because it was possible. Nobody defined what should change — time, cost, errors, revenue — and nobody is measuring. After six months, nobody knows whether it was worth it.
Nobody to maintain it. Models change, APIs change, prices change. A solution with AI is not a spreadsheet: it needs someone to follow it. If that person doesn't exist, the solution has an expiry date.
And there is the warning we promised about technical teams. A 2025 study by METR, with experienced developers on real open-source projects, measured something nobody expected: with AI tools, they took 19% longer to close tasks — and remained convinced they had been 20% faster. The 2024 DORA report points the same way: AI increased individual productivity and satisfaction, but worsened the stability and throughput of deliveries. The lesson is not "don't use them"; it is that the feeling of speed is not speed, and that without a process around it the tool accelerates the person and slows the system.
The middle ground that works
In practice, the choice is rarely binary. The two hybrid models that work most often:
External diagnosis, internal execution. Someone from outside maps the process, identifies where AI is worth it and where it isn't, defines metrics and designs the solution — and the team builds with the agent tools. The company keeps the knowledge; the consultancy comes in where experience counts (knowing what usually goes wrong) and leaves before it becomes a dependency.
Internal pilot, scale with help. The team builds the prototype, proves there is value, and only then does someone come in to make it robust: integration, security, data, monitoring, training. It is the "I painted the room myself, I called the electrician for the fuse box" version.
In both, the question to ask the consultancy is the same: "when do you leave?" If the answer is vague, it is a sign that the business model is to stay.
The tools, without prices
Prices change from month to month and would be out of date before this article is read; to estimate usage costs, we keep an AI cost guide up to date. What doesn't change as fast is the positioning of each one:
- GitHub Copilot — the most integrated into the workflow of people who already program (editor, GitHub, code review). The natural choice for technical teams that want to speed up without changing tools.
- OpenAI Codex — a coding agent with a CLI, an editor extension and a cloud environment; it carries out whole tasks, including in parallel, and integrates with the OpenAI ecosystem.
- Claude Code — a coding agent that reads the whole project, edits files, runs commands and connects to external tools (documents, tickets, databases) via MCP; available in the terminal, the editor, a desktop app and the browser.
For someone who is not technical and wants to build prototypes or automations, the two agents (Codex and Claude Code) are the starting point; Copilot assumes a programmer in the chair. For those who already have a team, any of them will do — what decides is what the team already uses.
One note that applies to all three: read what each one does with the data it is given (the code, the documents, what is typed into prompts) and choose the business plans when customer data is involved. It is the difference between painting the wall and touching the fuse box.
Decision matrix
Three questions, and the answer almost falls out by itself.
| Low risk (internal data, reversible) | High risk (customer data, critical systems, money) | |
|---|---|---|
| Internal capability (someone to build and maintain) | Do it yourself. Agent tools, a defined metric, a review after a month. | External diagnosis, internal execution. Someone from outside designs and sets the limits; the team builds. |
| No internal capability | Do it yourself to learn, with a small scope. Prototypes, personal automations, no integration. | Consultancy with an exit date. Diagnosis, implementation until it works, training the team to maintain it. |
The third question is urgency: if the result is needed in weeks and there is no internal capability, the cost of learning along the way is higher than the cost of someone who has done it before.
What to ask a consultancy before signing
If the matrix pointed to outside help, these questions separate those who accelerate from those who sell hours:
- "What are you going to decide not to do?" A good consultancy takes things out of scope. A bad one accepts everything.
- "What is the metric, and when do we measure it?" If the answer is "productivity" without a number, there is no metric.
- "What stays with us at the end?" Code, documentation, access, and a team that knows how to maintain it. If dependencies stay, invoices stay.
- "When do you leave?" A date, or a criterion. "When it's working" is an acceptable answer if it comes with a definition of "working".
- "Show me a case where you told a client not to use AI." Anyone who never has either lacks experience or isn't being honest.
- "Who does the work?" Are the people presenting the proposal the ones who will execute it? If not, who, and with what experience in processes like ours?
- "What happens when the model changes?" Vendors retire models, change prices, change behaviours. Who follows that afterwards?
Our answer to these questions is in how we work: we decide what changes, we stay until it is working, with weekly deliveries and an exit date. If the right answer for your case is "do it yourselves", that is what we say — and the free assessment exists precisely to find that out before there is a contract.
Frequently asked questions
Can I build an AI automation without knowing how to program? With a coding agent like Codex or Claude Code, yes, for small-scope, low-risk cases: internal automations, prototypes, analyses. What you can't do without experience is integrate with critical systems, guarantee data protection and maintain the solution when the models change.
Copilot, Codex or Claude Code — which one? If there are developers, whatever the team already uses; Copilot is the most integrated into a programmer's workflow. If there aren't, the agents (Codex, Claude Code) are the starting point, because they carry out whole tasks from a description.
When is a consultancy justified? When the data belongs to customers, the solution touches critical systems, the process crosses teams, or the result is needed in weeks with no internal capability. And it should come in with an exit date.
Do the studies say AI makes developers slower? A controlled METR study (2025) measured experienced developers 19% slower with AI tools, even though they felt faster; DORA 2024 saw individual productivity rise and delivery stability fall. The conclusion is that a tool without a process accelerates the person and slows the system — not that it shouldn't be used.
Is the prototype we built internally any use if we then bring in help? Very much so: it proves there is value, shows the real process and is the best possible briefing. What usually isn't reusable is the prototype's code, which was built to demonstrate, not to last.
Sources
Writes about applied AI, operations, GEO/SEO and how to turn companies into machines that keep running even when no one is watching.