How can a traditional software team get started with AI quickly and effectively? https://x.com/i/article/2118988492659380224
How to Build an AI R&D Team Quickly and Efficiently
AI coding tools have become part of everyday work for many developers. In the 2026 Stack Overflow Developer Survey, 65.9% of the 17,464 people who answered this question said they used AI coding assistants or coding agents at work. That is a survey of respondents, not a measure of how many purchased licenses are being used.
The organizational question remains: how do you turn individual use into a way of working that the whole team can actually benefit from?
1. A Number Worth Thinking About
In March 2026, Cursor published a case study about the Japanese fintech company Money Forward. Staff Engineer Aaron Li described an engineering all-hands where the team showed coding agents handling software tasks from beginning to end.
The report said that, within a week of introducing Cursor, the number of engineers using coding agents increased by 30%. At the time of the report, Cursor said more than 1,000 Money Forward employees used it daily, including people in engineering, product, design, and QA.
The report does not date the all-hands or say that the demonstration caused the increase. But it gives us something worth thinking about: what happens between introducing a tool and making it part of a team's work?
Building an AI R&D team is not about buying tools, setting targets, or running training courses. It requires an entirely different methodology.
I have summed it up in four pillars.
2. Pillar One: You Need an Evangelist
An evangelist is not a manager.
This distinction is crucial, but almost everyone gets it wrong.
Most companies' first reaction is: “We need to set up a dedicated AI task force and have the technology director lead it.” Or: “Let's have the CTO put together a plan and train the team.”
That's the wrong approach. Evangelists and managers are two different species.
Managers care about processes, metrics, and allocating resources. Evangelists care about questions like these:
Does this thing actually work? How do you use it? Where are the pitfalls, and how do you get around them?
What does a typical evangelist look like?
They are the person who starts using it themselves. They do more than watch other people or read the documentation. They put AI tools into real business workflows with their own hands. They have run into every pitfall you can think of: model hallucinations, lost context, garbled output formats, and incompatible toolchains.
Then they do one more thing:
They turn what they learned from those pitfalls into a process the team can repeat.
Money Forward's all-hands example shows the value of making the work visible. Rather than asking people to take a claim about AI on faith, the team showed what coding agents could do with an engineering task.
An evangelist isn't someone who just makes slides. An evangelist gets their hands dirty.
Their value lies not in how much they know, but in how many people they can get to actually use the tools. The first problem they need to solve is trust. Not getting the team to believe that AI is powerful, but getting people to believe: “I can use it to build something too.”
I've seen too many companies hand AI adoption over to an “innovation department” or a “digital transformation office.” A year later, apart from a few reports and pilot projects, nothing has changed.
Why? Because the people in those departments don't use AI themselves to write code, create designs, or draft documents. How can they persuade anyone else to use it?
An evangelist must come from the front line.
They could be a senior engineer, a product manager, a designer, or even someone in QA. The only requirement is that they use AI every day to solve real problems and are willing to share what they learn.
3. Pillar Two: Treat AI as Your Digital Twin, and Trust It
This is the hardest step.
I've seen too many teams buy all the tools and set up all the accounts, only to get stuck at a strange point:
People are afraid to use them.
An engineer looks at AI-generated code and thinks, “Will this run? Will it have bugs?”
A product manager looks at an AI-written requirements document and wonders, “Are the developers going to tear this apart?”
A designer looks at an AI-generated image and hesitates: “Is the style right? Will the client accept it?”
One of the biggest obstacles is psychological, alongside practical concerns about quality, security, and access.
People have an instinctive distrust of things they didn't create with their own hands. They feel less assured about them. That feeling is amplified in the AI era because AI output looks so much like something a person made that we forget it is still, fundamentally, a tool.
What is the right way to think about it?
Treat AI as your digital twin, not your replacement.
Imagine you are mentoring an intern. They won't be able to complete a task independently on day one. You give them background information, explain the standards, and provide feedback. Gradually, they learn your style and understand your preferences. Eventually, they can independently complete the tasks you give them.
Working with AI also takes context and feedback. The analogy has limits: an agent does not automatically remember every correction or learn your preferences across tasks. What it can do independently depends on the tool, the task, and the safeguards you give it.
The key shift is from “I write it” to “I define the intent, and AI carries it out.”
A GitHub blog post by Gwen Davis, published in March 2026, put it in its headline: “The era of ‘AI as text’ is over. Execution is the new interface.”
AI is moving from a conversational model, where you say something and it answers, toward one where you give an instruction and it carries it out.
You are doing more than chatting with AI. You are directing an assistant that can also take action.
How important is this change in thinking? Let me give you an example.
In the traditional model, a programmer's process is: understand the requirements → design the architecture → write the code → debug → refactor. In an AI-assisted model, the process becomes: describe the requirements in natural language → AI produces the first version of the code → a person reviews and adjusts it → AI improves it → a person gives final confirmation.
Does that look like just a change in order? No. The nature of the work has changed.
In the first, you are creating. In the second, you are orchestrating.
The shift puts more emphasis on defining the intent and guiding the work. AI can make a first pass at the details, while you keep control of the direction and work through the details that still need human judgment.
Of course, trust is not blind.
It is built into the process: code review is still there, tests are still there, and CI/CD is still there. AI-generated code goes through the same quality gates, not because it can't be trusted, but because that is engineering discipline.
The important thing is not to avoid using it because you are afraid of mistakes.
I saw a team that had paid for Copilot for a year, yet its usage rate was below 20%. When asked why, the engineers said, “The generated code always needs changing. I might as well write it myself.”
That is a classic trap in thinking. You don't use AI to get perfect code in a single attempt. You use it to quickly get a starting point that you can iterate on.
Speed itself is a form of quality.
4. Pillar Three: Document-Driven Development
This may be the most underestimated of the four pillars.
Many people think: AI is so smart. Can't I just say a few things to it? Why do I need to write documents?
Because AI is best at working with existing context. What it handles least well is vague requirements communicated verbally.
The “documents” I mean here are more than a formal specification written once and put away.
They give both people and AI the context needed to do the work. They can also become part of the instructions an AI uses to execute a task.
Money Forward's approach is instructive. The company reported that its product managers use Cursor to understand existing code, generate architecture diagrams, and draft PRDs. Documentation is no longer just a ritual before development. It is also fuel for AI execution.
What does that look like in practice?
An effective workflow I've seen looks like this:
PRD (Product Requirements Document) → Architecture Doc → Task Breakdown → AI Execution
Each step provides context for AI.
The PRD tells AI what problem needs to be solved, who the target users are, and what success looks like. The Architecture Doc tells it where the system boundaries are, how the modules interact, and what technical constraints apply. The Task Breakdown divides a large task into pieces small enough for AI to handle.
With these in place, AI can really do its best work.
Without them, you may find that the same prompt produces code worth 80 points for one person and only 40 for another. Where does the difference come from?
Context.
Relevant, accurate context can make the output more useful. More material is not automatically better, especially if it is outdated or unrelated.
Another benefit of document-driven development is that it preserves knowledge.
Traditionally, once a project is finished, knowledge is scattered across chat logs, emails, and spoken conversations. When someone new takes over, the first thing they do is “ask Wang.” Wang may have left, may have forgotten, or may describe something differently from how it was actually done.
When the context for AI execution lives in documents, a newcomer can see the full chain of decisions. Why was it designed this way? What constraints were considered at the time? The answers can be traced.
Documentation becomes the team's shared memory.
Of course, that requires the documents themselves to be good. Longer does not necessarily mean better. They need to be structured, precise, and actionable.
A good PRD should include user stories, acceptance criteria, dependencies, and risks. A good architecture document should include system boundaries, data flows, interface contracts, and performance constraints.
This is not mere formality. It is what helps AI “understand” your intent.
5. Pillar Four: Choose an Approachable Tool. Cursor Is a Good Starting Point for Evangelism
The choice of tool directly determines the success of evangelism.
There are many AI coding tools on the market: Claude Code, GitHub Copilot CLI, OpenClaw, Cursor, and others. Each has its strengths and weaknesses, but there is one key difference:
The barrier to getting started.
CLI tools are powerful, but starting in a terminal, learning commands, and configuring an environment can be an invisible wall for people who are not used to them. Some CLI tools can also connect to browsers or other visual interfaces; the distinction is not that one can see and the other cannot.
Cursor's core advantage is that it is a tool that is easy to introduce to others.
Its visual interface resembles VS Code, which can make it easier for people to get started without beginning in a terminal. Its built-in browser can show and help test changes, so designers and QA can inspect a result visually. Setup still depends on the team's environment and policies, but the interface can lower the first barrier to trying.
Money Forward's case is interesting here: the report says design, product, and QA teams adopted Cursor, and describes lower acceptance of other tools without a similarly strong user interface among those groups. That is the company's experience, not a universal ranking of CLI and visual tools.
Why?
Because Cursor reduces the effort required to try.
You don't have to begin by convincing a designer to learn the command line. You can start with a familiar-looking editor and show them: “Tell the AI what you want, and let's look at the change together.”
At its heart, evangelism is about reducing friction.
But there is an advanced path to keep in mind:
Cursor can be a starting point. A CLI workflow can be a useful next step when a team wants deeper integration or automation.
Once you and your team are familiar with the basics of AI-assisted development, you may want more flexible customization, scripting, and integration. That is a good time to consider a CLI workflow.
Claude Code and GitHub Copilot CLI can be used in terminal workflows and scripts. You can integrate tools like these into your own workflows and automate repetitive tasks. OpenClaw is a different kind of tool: a self-hosted agent platform with several interfaces, including a CLI. It can be part of a more customized agent setup.
One possible path is: start with an approachable visual tool such as Cursor → explore Claude Code or Copilot CLI → build or customize an Agent system when your work calls for it.
Each step has its value. A visual tool can help people build confidence. A CLI can make certain workflows easier to automate. A customized Agent system can give you more control over how a workflow is put together. This is a possible progression, not a requirement that every person or team use the same tools in the same order.
A recent discussion brings out another part of getting started. A developer said their new employer provided a basic AI chatbot but expected engineers to pay for their own coding subscriptions, while allowing third-party tools. It is one person's account, and we do not know the company's full policy. Still, a new teammate should know which tools and accounts are supported, who pays, what information may be shared, and who can access the work later.
6. Closing Thoughts
Building an AI R&D team is, at its heart, about building a new way of working.
What it needs isn't a bigger budget, a larger team, or a more complicated process. It needs:
An evangelist who believes in it, the habit of treating AI as a digital twin, a system of documents written for AI, and a tool that helps the team get started quickly.
These four pillars support one another. None can be left out.
Without an evangelist, even the best tools can struggle to spread. Without a change in thinking, the tools may just sit there. Without useful documentation and context, teams make AI's work harder to guide and review. Without an approachable tool, the cost of getting people on board rises.
Over the past year, I've seen too many companies burn money, wear out their people, and waste time on AI transformation, only to achieve very little. The reason is often that they focus on only one or two of these elements instead of bringing them together in a complete cycle.
Money Forward's story is worth learning from for more than its choice of Cursor. Its reported experience shows why practical demonstrations, a tool people can approach, and work across engineering, product, design, and QA all matter.
The four pillars are my way of bringing those lessons together. They are a framework for a team to try, not a claim that the case study proves every team followed the same process.
That is what “quickly and efficiently” really means.
7. A Question I Keep Thinking About
While writing this article, I kept thinking about a question: What exactly is AI?
It can write code, draw, compose music, and hold a conversation. It seems capable of everything. But does it really understand what it is doing?
Wittgenstein wrote:
“A person can see what they have, but not what they are.”
The same is true of AI, as I see it.
It can see the data it processes, the code it generates, and the content it produces. It can see what it “has.” But I do not think it can see what it is. It does not understand its own boundaries or blind spots, or why it is sometimes right and sometimes wrong.
And I am observing this.
Here, I want to keep sharing more than technical tools. I also want to explore the limits of AI's capabilities, the relationship between people and AI, and the philosophical questions behind the technology.
The focus will shift from “how to use it” to “what it is” and “why.”
If you are thinking about these questions too, I hope you'll continue on this journey with me.
Wittgenstein said, “A person can see what they have, but not what they are.” The same is true of AI. I am observing this.