AI Vibe Coding in Practice, Part 2: Product Decisions and a Revised SMS Suite Plan

In the previous article, I shared my prompt and Claude Code's development plan for an SMS suite—shared infrastructure, verification codes, and authentication—for the CabloyJS fullstack framework. At the end of that plan, Claude Code asked me to confirm three groups of product decisions: registration behavior, phone-number scope, and rollout scope.

I had a question about “automatically register on SMS login”: if users do not enter a username, how should userName be determined? I sent that question back to Claude Code along with the other two decisions so it could refine the plan. Here is the next part of the conversation for reference.

Here is the prompt:

1. Registration: should SMS login automatically register a new user? I am unsure. If registration is automatic, how is userName determined?
2. Phone-number scope: mainland China only initially, or international numbers too? Support international numbers.
3. Rollout:
   • Enable SMS login on both Web/Admin.
   • Deliver the complete Mock flow in the initial release and integrate real vendors as well:
     • Mainland China: Alibaba Cloud / Tencent Cloud.
     • International numbers: please recommend one or two of the most popular services.

Here is the development plan returned by Claude Code:

These clarifications let us narrow the plan further. First, the username question: automatic registration is possible, but explicit registration fits the current account model more naturally. I recommend separating SMS registration from SMS login for the initial release, without automatic registration by default.

For international SMS, I recommend Twilio and Vonage. Integrate Twilio initially and keep Vonage as the second choice, rather than requiring both in the first release.

1. Registration: prefer explicit registration with a user-chosen userName

1. Why not generate a username automatically?

After checking the source further, the current user.name is more than an internal technical identifier:

• Registration writes it from profile.username.
• It is used for user display.
• Existing password login looks up users by this field.
• Profile editing currently allows users to change it.

It cannot simply be treated as an automatically generated, immutable internal ID. There is also no separate persisted nickname field for display names.

Source references:

• User profile mapping: vona/src/suite/a-home/modules/home-user/src/service/userAdapter.ts:13.
• User registration: vona/src/suite-vendor/a-vona/modules/a-user/src/bean/bean.user.ts:27.
• Password login lookup: vona/src/suite-vendor/a-auth/modules/auth-simple/src/bean/authProvider.simple.ts:58.

Automatic registration could generate a username such as sms_<random identifier>, but that raises further product questions: can it be changed, what gets displayed, and which name is used if the user later sets a password? Implementing SMS login does not require redesigning the account naming model in the initial release.

2. Recommended registration and login contracts

Operation	Input	Behavior
SMS registration	International phone number, username, SMS code	Verify the number, create the user and SMS identity mapping, then sign in
SMS login	International phone number, SMS code	Sign in only through an existing SMS identity; never create a new user

The initial registration flow does not require a password or email, and must not create fake password credentials.

Recommended username rules:

• Reuse and complete the existing username validation.
• Trim surrounding whitespace and apply consistent case-equivalence rules when checking names.
• Require uniqueness within the current instance.
• Reject reserved system names such as admin.
• Return a field error when a name is taken, rather than silently appending a random suffix.
• Preserve uniqueness when the same phone number or username is registered concurrently.

One more detail matters: the current profile editor's “Display name” changes the same user.name, without the duplicate-name checks used for registration. Registration and renaming should share the necessary username constraints. Otherwise, renaming can introduce conflicts after registration has enforced uniqueness.

3. Separate phone identity from username

Keep three concepts distinct:

Field/concept	Purpose
user.id	Internal user identifier
user.name	Account name chosen by the user
SMS identity mapping	Association between a verified, normalized phone number and userId

Consequently:

• Renaming a user does not affect phone login.
• A phone number must not become the default username, which could expose the full number wherever the user is displayed.
• A username matching an old account does not trigger automatic association.
• A phone number matching an old account's mobile field does not claim that account either.

The existing authentication chain's automatic registration behavior also needs to be explicitly disabled. The framework can currently create users for both login and register, so passing intention: 'login' alone does not make an operation login-only.

For a missing SMS identity, prompt the user to register after verifying ownership of the phone number. The send-code endpoint itself must not disclose whether an account exists.

---

2. Phone-number scope: support international numbers and normalize to E.164

Use an explicit international-number contract on both frontend and backend:

• Provide a country/region selector on the frontend.
• Use a mature server-side number parser, such as a libphonenumber-based implementation.
• Normalize numbers to E.164 for storage, comparison, and sending, for example +86138… or +447….
• Use the same normalization logic for sending and verification.
• Do not use a simple regular expression to validate numbers from every country.
• Do not infer the recipient's country from the UI language, browser locale, or IP address.

Routing rules

Destination	Default sending channel
Mainland China	Alibaba Cloud or Tencent Cloud
Hong Kong, Macao, Taiwan, and other international destinations	Twilio, or Vonage if configured
Explicit development/test configuration	sms-mock

Do not route Hong Kong, Macao, or Taiwan through the mainland China SMS channel, or choose a vendor based on page language.

Supporting international numbers does not mean enabling worldwide sending by default. Configure allowed countries/regions, quotas, and spending limits. Destinations may have different Sender ID, number registration, template, or use-case requirements, so enable and verify them individually.

---

3. International vendors: Twilio and Vonage

Both are mature, widely used international communications API vendors. This is an engineering recommendation, not a claim that they rank first and second in verifiable global market share.

Vendor	Recommended role	Integration
Twilio	First choice for international SMS in the initial release	Programmable Messaging
Vonage, formerly Nexmo	Second choice or a later alternative channel	SMS API

1. Twilio: recommended for the initial release

It fits the proposed architecture because it provides:

• A general-purpose SMS sending API.
• E.164 recipient numbers.
• A sending number or Messaging Service for sender configuration.
• Extensive documentation on destination permissions and country requirements.

2. Vonage: a second choice

Vonage SMS API provides general-purpose recipient, sender, and message-body parameters. It can support another SMS Provider following the same contract.

For specific target countries, the final choice should still consider:

• Sending identities that can actually be provisioned.
• Delivery rate and latency tests.
• Unit prices and message-segment billing.
• Account entity and local compliance requirements.

3. Do not default to managed Verify products for this plan

Both Twilio and Vonage offer managed verification products. For this suite, use:

• Twilio Programmable Messaging.
• Vonage SMS API.

The plan does not default to their Verify products because sms-captcha is already intended to manage:

• Code generation.
• Expiry.
• Phone-number and purpose binding.
• Attempt limits.
• Single consumption.

Keeping vendors responsible for transport lets Mock, Alibaba Cloud, Tencent Cloud, and international Providers share the same verification semantics.

---

4. The infrastructure must support two vendor sending models

With international vendors included, the unified SMS interface cannot require a vendor template ID for every request. Their APIs differ:

Provider	Typical sending model
Alibaba Cloud	Signature + template ID + named parameters as JSON
Tencent Cloud	Signature + template ID + ordered parameter array
Twilio	Sender/Messaging Service + message body
Vonage	Sender + message body

Keep the business call consistent:

// Proposed interface
await this.bean.sms.send({
  scene: 'sms-auth:signup',
  recipient: normalizedPhone,
  params: {
    code,
    minutes: 5,
  },
});

Server-side Scene configuration and Provider adapters handle the differences:

• Alibaba Cloud: convert { code, minutes } to template parameter JSON.
• Tencent Cloud: convert parameters to an array in an explicitly configured order.
• Twilio/Vonage: render the body from localized text templates maintained on the server.

Parameter order must not depend on object enumeration. Public requests must not freely supply message bodies, vendor templates, or senders.

Also distinguish:

• Recipient region: determines requirements and available channels.
• Message language: determined by the business language policy.
• Vendor account region: determined by Client configuration.

Do not combine all three into one region field.

---

5. Module structure: retain four core modules and extend real Providers independently

Since the initial scope explicitly includes multiple real vendors, retain the four core modules and create separate vendor modules:

Module	Initial recommendation
cabloy-sms	Required: transport infrastructure
sms-captcha	Required: verification codes
sms-auth	Required: registration and login
sms-mock	Required: development and testing
sms-aliyun	Required: mainland China Provider
sms-tencent	Required: mainland China Provider
sms-twilio	Recommended for the initial release: international Provider
sms-vonage	Alternative; include when two international channels are needed

All belong to the cabloy-sms suite. Separate modules isolate SDKs, credential types, and vendor changes, so consumers do not have to load every SDK.

If retaining exactly four modules is essential, real Providers could live in cabloy-sms. With multiple real vendor consumers now confirmed, separate Provider modules are a better fit.

Default routing selects one vendor for each send. For example:

• Mainland China defaults to Alibaba Cloud, with Tencent Cloud selectable through configuration.
• International destinations default to Twilio.
• Never send through multiple Providers simultaneously.
• Do not automatically resend through another vendor when a timeout leaves the result uncertain.

---

6. What enabling both Web/Admin means

Both can offer SMS registration and login while sharing:

• Users.
• SMS identity mappings.
• The Provider configuration mechanism.
• Passport and session handling.

Registering through Web or Admin must not create separate users for the same phone number.

Opening a login entry point and granting business permissions are separate decisions:

• SMS registration grants only ordinary registered-user permissions.
• Registering from an Admin page does not grant administrative permissions.

---

7. Updated initial delivery recommendation

Set the initial scope to:

1. Infrastructure + Mock: establish a working unified sending contract.
2. Alibaba Cloud, Tencent Cloud, and Twilio Providers: integrate with that contract.
3. SMS verification: international numbers, purpose binding, rate limits and cooldowns, single consumption, and Mock autofill.
4. Explicit SMS registration and login restricted to existing SMS identities.
5. Web/Admin entry points and permission regression checks.

For real Providers, distinguish:

• Code integration complete: request mapping, response parsing, and error handling have been verified.
• Real SMS acceptance complete: accounts, signatures/templates/sending identities have been approved, and authorized test numbers have actually received messages.

The former cannot replace the latter, and a complete Mock flow cannot replace real vendor acceptance.

My final recommendation is explicit registration to establish userName, E.164 normalization for international numbers, and initial integration with Alibaba Cloud, Tencent Cloud, and Twilio, with Vonage as the second international option. This covers the requested initial business scope without also taking on account-name redesign, worldwide channel activation, and automatic failover.

Sources

• Twilio Messages API: recipient numbers, message body, and sender parameters
• Twilio international SMS destination permissions and restrictions
• Vonage SMS API
• Alibaba Cloud SendSms API
• Tencent Cloud SendSms API

No code was changed in this round. Vendor information was checked against search results from official documentation; full-page retrieval was restricted by network access. No commitments were made about availability in specific countries, pricing, or actual delivery rates.

---

After this exchange, Claude Code had more concrete recommendations for registration, international numbers, and real vendor integration, along with clearer boundaries for shared Web/Admin identities and permissions. I will leave it here for now to keep the article manageable. If you would like to see the implementation that follows, leave a comment and I will continue putting the material together.