wesionaryTEAM Co. Ltd. logo - We offer product co-creation, DX, system development, and app development

Services

Company

News

Case Studies

Blog

Estimate

Dev & DX ConsultationConsultation

Contact Us

Article Categories

All Articles

Soft Skills

Organizational Culture

Technology

BLOG

What a Software Development Company Should Stand for in the Age of AI: Building Fast Is Not, in Itself, the Value

With AI, a system takes shape almost immediately. It proposes screens, writes the code and runs the tests. In our own daily work, we delegate much of that to AI agents.

Even so, we do not sell "building fast". Speed is becoming a given that every company can have. What sets companies apart is on the judgment side: what not to build, whether the screens are usable, whether the system is safe, and who takes responsibility.

This article explains that view with research available as of November 2026 and with how we actually work. It also puts numbers on what happens when everything is left to AI.

Building fast is not, in itself, the value: the human steps of observing, cutting, designing screens and verifying make the difference, while the AI build step does not

About the author

wesionaryTEAM Editorial Team

The editorial team is made up of wesionaryTEAM's project managers and engineers. Drawing on what we learn every day on business system, AI adoption and digital transformation projects, we publish information people can use when making decisions, with cases and figures.

Speed does not carry straight through to the client's results

Writing code has certainly become faster. That does not always make the whole project faster.

Bain's 2025 report puts the productivity boost for teams using AI assistants at 10 to 15%. And writing and testing code accounts for only about 25 to 35% of the time from idea to launch. The rest goes into deciding what to build, verifying and fixing.

Perception is no guide either. In a 2025 randomized trial using 246 issues from 16 experienced developers (METR), AI made them 19% slower, while they believed it had made them 20% faster. That result reflects the tools of the time, and in a February 2026 update METR said developers are likely sped up more now. Even so, with a gap that wide between perception and measurement, speed figures cannot be taken at face value.

There is also the burden after the code is written. In Stack Overflow's 2025 survey, the top frustration with AI was "solutions that are almost right, but not quite" at 66%, followed by "debugging AI-generated code is more time-consuming" at 45%. DORA's 2025 report likewise finds that AI adoption increases throughput but continues to have a negative relationship with delivery stability, and concludes that AI does not fix a team but amplifies what is already there.

"It works" and "it is safe" are different things

Code written by AI usually works. The problem is that working and being safe are not the same.

In a continuing study (Veracode) that gives AI tasks prone to vulnerabilities and runs the output through static analysis, vulnerabilities appeared in 45% of cases across more than 100 models in July 2025, and in 38% across 18 models in October 2026. Even the best models passed only 73% of the time.

A 2026 paper on apps built by leaving the work to AI and then deployed audited 200 of them. It found at least one vulnerability in 91.0%, and 65.77% of the vulnerabilities found were rated Critical or High. They were concentrated in broken access control, injection and authentication failures.

The incidents happen in the same place. In May 2025, it was reported, based on a survey by an employee of another AI tool company, that 170 of 1,645 apps featured on a prompt-to-app service's site let anyone read their users' information. In July that year, an AI agent was reported to have deleted data from a production database during a code freeze. In both, what was missing was not code but the judgment of who may see what and what must never be done in production.

OWASP listed "Inappropriate Trust in AI Generated Code" among the risks just outside its 2025 Top 10. It says you should be able to read and fully understand all code you submit, and does not recommend having AI write code without human oversight (vibe coding) for business-critical programs or programs used for a long time.

The image at the top of this article puts that state into one fictional screen: open to everyone, authentication skipped, keys left on screen, debug mode on in production. Such flaws happen without AI too. But when everything is left to AI, nobody is left to doubt them.

In Japan, IPA's "10 Major Security Threats 2026" chose "cyber risks around the use of AI" as the third threat for organizations, for the first time. The Personal Information Protection Commission's October 2026 warning gave a case where rewriting a URL or member ID exposed other people's data, IDs were sequential, and access was not rate-limited. That is the same kind of access-control flaw the paper above found so often.

On the other hand, as far as we could find as of November 2026, no incident in Japan has been publicly attributed to code written by AI. The published cases are ones where people put personal information into an outside AI, including one covering about 334,000 people in October 2026.

Deciding what not to build

Every added feature makes a system harder to use, easier to break and heavier to maintain. Requests still pile up, and because AI will turn anything into a screen on request, the decision not to build gets left behind even more.

The numbers show how much that decision matters. Pendo's 2019 report, based on usage data from 615 subscriptions, found that 80% of features are rarely or never used and that 12% of features generate 80% of daily usage. At Microsoft, only about a third of the experiments designed to improve a key metric succeeded.

Figma's 2026 report puts the situation in one line: "AI can build almost anything. What it can't do is determine what's worth building." The decision to cut has to stay with people.

Usable screens are decided by people

Ask AI for a screen and a tidy proposal appears at once. We use AI for proposals too. We never use them as they are.

A 2025 study had AI generate the home screen of a banking app. When two experts assessed accessibility against ten criteria, an average of 58% of the screens had a violation. Writing the conditions into the prompt brought the average down to 19%, but not to zero. Writing the prompt, and fixing what remains, is human work.

What AI produces is a generic screen for a generic task. The order in which people look at things, and where they get lost, can only be learned on site. Only after sitting with the users, reordering and removing what they do not need does a screen become usable.

Responsibility does not move with the method

AI having written the code does not remove the development company's responsibility. Under a contract for work, the company is liable for non-conformity if the deliverable does not match the contract. Under a quasi-mandate, if payment is for the work, there is in principle no such liability, only a duty of care, but many such contracts promise a finished deliverable. That is why the contract type and the acceptance criteria should be settled before building starts.

Copyright needs care. The Council for Cultural Affairs' "Approach to AI and Copyright" holds that if the instructions to AI stop at the level of an idea, the output is not recognized as a copyrighted work. There may be no copyright to assign, so beyond a clause saying copyright belongs to the client, it is safer to write a licence to use and modify, and the handover of source code, into the contract.

National guidelines also place the judgment with people. Version 1.2 of the "AI Guidelines for Business" from the Ministry of Internal Affairs and Communications and the Ministry of Economy, Trade and Industry (March 2026) asks for measures against the risk of over-reliance on AI, such as automation bias, and a note introduces the proposal that a person approving an AI's judgment should first work out their own reasons.

What the freed-up time goes into

Where the time goes: before and now

Development used to spend most of its time on implementation and testing. We put the time AI frees up not into shorter schedules, but into thinking about screens first, fixing them hands-on with the people who use them, and deciding what not to build.

How we actually work

Principles alone are just talk. In practice, this is how we move every week.

How we actually work: watch, cut, design screens, build, fix

First we watch the users' workflow on site. Next we remove the features nobody would miss from the request list before building. For screens we make several proposals and choose together with the users, hands on. Up to here is human work.

AI agents carry out implementation and testing, but our developers review every change before it goes in. Checks for leaked secrets and audits of library vulnerabilities are mandatory, and deleting production data or changing permissions happens only after a person has confirmed it (our rules).

Requests, specifications, progress, reviews and approvals are kept in our management tool, and clients can check them any time on their own screen. Every week we show working software to the client, have them use it, and fix it.

What to check with a development company

Japan's Kanto Regional Development Bureau publishes a checklist for reviewing how contractors use generative AI. Adding what we care about to its items gives these seven points.

  • Do they propose what not to build? Building everything tends to produce something hard to use.
  • Do they check the screens with the people who will actually use them?
  • Is the review of AI-written code a working practice rather than a formality?
  • Can they say which AI services they use and show the basis for input not being used for training?
  • Can they explain how they verify who may see what (authorization) and how keys are handled?
  • Do they settle the acceptance criteria and contract type in writing before building starts?
  • Can they write the handover of source code and a licence to use and modify into the contract?

FAQ

If you use AI, should cost and schedule not come down?

Writing time comes down. But writing and testing code is only about 25 to 35% of the whole, and the time for judgment and verification remains. We put that time into deciding, screens and safety.

Will you take a project where speed is the priority?

Yes. Even then, we start by deciding together what not to build. In the end, that is the fastest way.

Can we use a screen built entirely by AI as it is?

For a throwaway internal tool, yes. For anything that holds customer data or will be used for a long time, have a person check permissions and keys first.

Summary

Thanks to AI, building something that works fast has become a given. The value has moved to working out which features are truly needed, thinking usable screens through with the people who use them, confirming safety, and taking responsibility for it. We want to be the development company that puts the time AI frees up into exactly that.

If you would like to decide together what to cut and how far to leave to AI, contact us through the free estimate consultation.

Related articles and pages

Sources

Reviewed by

Ichiro NagataCEO and Representative Director

A former engineer at Yahoo! JAPAN. For more than 18 years at startups and large companies, he has worked on a wide range of projects, from new consumer and business ventures to the digital transformation of operations. Alongside hands-on development as an engineer, he has built and managed teams, designed businesses and tested hypotheses, gaining broad experience in launching and growing businesses. He has been through three business sales. Convinced that co-creation makes products better and lets ideas be tested in the market, he founded wesionaryTEAM to offer a co-creation platform.

Development Consultations and Estimates

As your co-creation partner, we drive business development and DX.

We start with a call with your project manager to confirm what to build and the expected cost range.