Forem: Krisada Vivek

ทำไม Vibe Coding คือหายนะที่ Senior Dev เห็น แต่คุณไม่: เจาะลึก 7 ขั้นตอนใช้ AI เขียนโค้ดแบบมืออาชีพ (Senior Approved)

Krisada Vivek — Tue, 31 Mar 2026 07:28:10 +0000

ในยุคที่ Claude Code, Cursor, และเครื่องมือ AI เขียนโค้ดเบ่งบานราวดอกไม้ไฟ เรามักจะเห็น Hook ชวนฝันว่า:

"สร้างเว็บเสร็จใน 5 นาที เพียงแค่พิมพ์ Prompt เดียว!"

เทรนด์นี้ถูกเรียกว่า "Vibe Coding" ซึ่งทำให้การเขียนโปรแกรมดูเป็นเรื่องง่ายและสนุก

แต่ทำไม Software Engineer ประสบการณ์ 20 ปี และอดีต Director of Engineering อย่างคุณ Owain Lewis ถึงมองว่านี่คือ "หายนะ" ที่รอวันระเบิด?

วันนี้เราจะมาแกะรอยบทความของคุณ Owain และคุณเอฟ (เจ้าของโพสต์ต้นทาง) เพื่อทำความเข้าใจความแตกต่างระหว่าง "โค้ดที่รันได้ตอนทดสอบ" กับ "โค้ดที่มีคุณภาพสำหรับ Production"

และเปิดเผย 7 ขั้นตอนการทำงาน ที่บริษัทระดับโลกอย่าง Google หรือ Amazon ใช้ ซึ่งจะช่วยให้คุณใช้ AI ทำงานเสร็จไวขึ้น 300% โดยที่ระบบไม่พังเมื่อลูกค้าเริ่มใช้งาน

บทสรุปของ "Vibe Coding" คืออะไร?

Vibe Coding คือการที่เราใช้ความรู้สึก (Vibe) นำทางการโค้ดดิ่ง เรามีไอเดียคร่าวๆ พิมพ์ลงไปใน AI ให้มันเสกโค้ดออกมา แล้วเราก็ก๊อปปี้แปะ ถ้ามันรันผ่านบนหน้าจอเรา เราก็รู้สึกว่า "เสร็จแล้ว"

แต่ความจริงในโลก Engineering นั้นโหดร้ายกว่ามาก:

ทำเสร็จ ≠ ทำดี: โค้ดที่รันผ่านในเครื่องเรา (Local) อาจจะมีช่องโหว่ด้าน Security, ก่อให้เกิด Technical Debt (หนี้ทางเทคนิค) มหาศาล, หรือไม่ได้ออกแบบมาให้รองรับคนใช้งานจำนวนมาก (Scaling Issue)
เมื่อถึง Production: เมื่อลูกค้าเริ่มใช้จริง สิ่งที่ Vibe Coding ทิ้งไว้มักจะเป็น Error รัวๆ ที่แก้ได้ยากมาก เพราะคนสั่ง AI ไม่เคยอ่านโค้ด หรือไม่เข้าใจโครงสร้างที่ AI มั่วขึ้นมาให้

เครื่องมืออย่าง Claude หรือ Cursor ก็เป็นแค่เครื่องมือ พลังที่แท้จริงไม่ได้อยู่ที่ Prompt วิเศษ แต่อยู่ที่ Workflow การทำงานจริง ซึ่ง AI ควรทำหน้าที่ "เร่งความเร็ว" ไม่ใช่ "แทนที่กระบวนการคิด"

เจาะลึก Mental Model: 7 ขั้นตอนการทำงานร่วมกับ AI ระดับโปร

เพื่อให้คุณเป็น Dev ที่เก่งกว่าคน 99% นี่คือ 7 ขั้นตอนที่คุณควรนำ AI ไปแทรกซึมเพื่อเร่งสปีด:

1. Requirements (คิดก่อนทำ)

ก่อนจะตะโกนสั่ง AI ให้สร้าง "แอปส่งอาหารแบบ Lineman" อย่าพึ่งใจร้อนให้มันเขียนโค้ด ให้ AI ช่วยคิดและรีเสิร์ชข้อมูลก่อน โดยการให้ AI ช่วยเขียน Product Requirements Document (PRD) ที่ดี ซึ่งควรประกอบด้วย:

Goal: สิ่งที่จะสร้างคืออะไร
Why: ทำไมเราถึงสร้างมัน
Who: สร้างให้ใครใช้
Scope: อะไรอยู่ในขอบเขต / นอกขอบเขตของการทำงานรอบนี้

AI สามารถช่วยร่างต้นแบบ (Prototype) หรือ Mockup ได้ไวมาก เพื่อให้เราเห็นภาพตรงกันก่อนลงมือ

2. Design (วางโครงสร้าง)

Requirements บอกว่า "สร้างอะไร" แต่ Design จะบอกว่า "สร้างอย่างไร" ขั้นตอนนี้สำคัญที่สุดและแก้ยากที่สุด AI สามารถให้คำแนะนำได้ แต่ มนุษย์ต้องเป็นคนตัดสินใจ final:

Architecture: จะใช้ Microservices หรือ Monolith?
Database: SQL หรือ NoSQL?
Security: ระบบ Auth จะใช้เจ้าไหน (Firebase, Auth0)?

อย่าปล่อยให้ AI ตัดสินใจเรื่องเหล่านี้ให้ทั้งหมด เพราะมันอาจจะเลือกสิ่งที่ "เป็นที่นิยมในเน็ต" แต่ไม่ได้เหมาะกับ Business Context ของคุณจริงๆ

3. Plan (หั่นงานเป็นชิ้นเล็ก)

กฎเหล็ก: 1 งาน ต่อ 1 Agent

อย่าสั่ง AI แบบเหมาเข่งว่า "สร้างระบบอีคอมเมิร์ซให้หน่อย" เพราะ context จะมั่วและ AI จะเดา (Hallucinate) ทันที ให้คุณซอยงานเป็นข้อเล็กๆ (Sub-tasks) เช่น:

ทำหน้า UI ลงทะเบียน
ทำ API สำหรับ Register
เขียนเทสต์เคสสำหรับหน้า Register

ถ้าคุณไม่รู้ว่าจะซอยงานยังไง ให้สั่ง AI ว่า: "ฉันมี requirements A และ Design B ช่วยซอยงานนี้เป็นข้อเล็กๆ ให้ฉันหน่อย"

4. Build (บรีฟให้ชัด ไม่ใช่แค่สั่ง)

AI ไม่ใช่ผู้วิเศษที่จะรู้ใจคุณ ถ้าคุณไม่มี Context ที่ชัดเจน มันก็จะเดาและทำพลาด การเขียนระบุบริบท (Provide Context) ให้ดีก่อนสั่งสร้าง จะช่วยให้คุณได้โค้ดที่ถูกต้องโดยไม่ต้องสั่งแก้ซ้ำซ้อน ซึ่งเปลือง Token และเสียเวลา

5. Review (อย่าไว้ใจทาง อย่าวางใจ AI)

นี่คือขั้นตอนที่ Vibe Coder ข้ามมากที่สุด การแค่กด "Accept" โค้ดที่ AI เขียนมาโดยไม่ดูด้วยตัวเอง คือการฝังระเบิดเวลาไว้ในโปรเจกต์

ความจริง: AI มักจะเขียนโค้ดที่ใช้งานได้ ในกรณีทั่วไป แต่ไม่ได้คำนึงถึง Edge Case หรือความปลอดภัย
วิธีที่โปร: สั่ง AI ตัวอื่นมา Review โค้ดนี้ หรืออย่างน้อยคุณต้องอ่านและทำความเข้าใจมันทุกบรรทัด

6. Deploy (ปล่อยของ)

การเอาเว็บขึ้นระบบจริงมักจะมีศัพท์เทคนิคอย่าง CI/CD, Pipeline, Containerization ที่น่าปวดหัว ถ้าคุณไม่ถนัด ให้สั่ง AI ช่วยอธิบายการตั้งค่า หรือสั่งให้มันนำทำทีละขั้น (Guided Steps) จนเอาระบบขึ้นให้คนอื่นใช้งานได้จริงได้สำเร็จ

7. Monitor (เฝ้าระวัง)

เมื่อระบบรันอยู่บน Production ของจริงมัน "พังได้เสมอ" เป็นเรื่องปกติ เราต้องตั้งระบบตรวจจับ Error และระบบแจ้งเตือน (Alerts) เอาไว้ เพื่อที่คุณจะได้รู้ตัวและแก้ไขได้ทัน ก่อนที่ผู้ใช้งานจะทักมาด่าในแชท

บทสรุป

ศัตรูที่แท้จริงของการพัฒนาซอฟต์แวร์ไม่ใช่ AI และไม่ใช่เทรนด์ใหม่ๆ แต่คือ "การไม่ยอมคิดเองตั้งแต่แรก"

การ Vibe Coding คือการละทิ้งกระบวนการคิดและวางแผนทั้งหมด ซึ่งเป็นหัวใจหลักของงาน Engineering การที่คุณจะสั่ง AI แค่ว่า "สร้างมาให้หน่อย" โดยไม่มีแผน ไม่มีโครงสร้าง สุดท้ายคุณจะได้แค่โค้ดที่ใช้งานได้ แต่รอวันพัง และเมื่อมันพัง คุณก็แก้ไม่ได้เพราะคุณไม่ได้เป็นคน "สร้าง" มันจริงๆ

แต่ถ้าคุณทำการบ้านมาดีและทำตาม 7 ขั้นตอนนี้ โดยให้ AI ช่วยเร่งความเร็วในแต่ละส่วน สุดท้ายคุณจะได้ซอฟต์แวร์ที่ทั้งมีคุณภาพ และที่สำคัญคือ คุณ "เข้าใจมันอย่างแท้จริง" ค้าบ

*ขอบคุณเนื้อหาต้นฉบับจาก Owain Lewis

Modern IoT Part 2: Setting Up the LINE Bot & Serverless Webhook (2026 Edition)

Krisada Vivek — Wed, 11 Feb 2026 04:00:00 +0000

Introduction

Welcome back to the IoT Weekend 2026 series!

In Part 1: The 2026 Architecture, we established our foundation by setting up a secure, serverless HiveMQ Cloud Broker for MQTT 5.0 communication. We decided to ditch the old, insecure ways of 2018 in favor of TLS encryption and scalable infrastructure.

Today, in Part 2, we are building the "brain" of our operation. We are moving away from long-running, expensive servers and deploying a high-performance TypeScript Webhook on Vercel to handle interactions from the LINE Messaging API.

The Goal for Part 2

By the end of this tutorial, you will have:

Created a LINE Messaging API Channel.
Designed a modern UI using LINE Rich Menus.
Coded and deployed a Serverless Webhook on Vercel.
Successfully published a secure MQTT message via a chat command.

Step 1: Create your LINE Messaging API Channel

To let users talk to our system, we need a LINE Official Account.

Log in to the LINE Developers Console with your LINE account.
Create a new Provider: If you don't have one, create one. Name it something like "My Smart Home".
Create a Messaging API Channel:
- Select your provider and create a new channel of type "Messaging API".
- Give your Bot a name (e.g., "HomeController-26") and upload a nice profile picture.
Get your Credentials: Once created, navigate to the Messaging API tab. Scroll down and issue a Channel access token (long-lived). Copy this token and your Channel secret (found on the Basic settings tab) to a safe place. We need them for Step 4.

Step 2: Designing the 2026 UI (Rich Menu)

In the old days, we asked users to type "ON" or "OFF". That's bad UX. In 2026, we use Rich Menus—a persistent menu bar at the bottom of the chat screen.

Go to the LINE Official Account Manager.
Select your account from the list.
Navigate to Home > Rich menus > Create new.
Design a simple menu with two large buttons.
Set the Action type for both buttons to Text.
- Button 1 Text: ON
- Button 2 Text: OFF
Save and activate the menu as the default for all users.

Now, when you tap a button, it sends the text command automatically!

Step 3: Coding the Serverless Webhook

We will use Next.js API Routes hosted on Vercel. This function will wake up only when LINE sends an event, process it, and go back to sleep—saving immense costs compared to a 24/7 server.

1. Initialize the project

Open your terminal and create a new Next.js project with TypeScript:

npx create-next-app@latest iot-webhook --ts
cd iot-webhook
npm install mqtt @line/bot-sdk

2. Create the Webhook Logic

In a modern serverless environment, we want our function to be stateless and fast. Create a new file at src/pages/api/webhook.ts.

This script performs three critical tasks:

Verifies the incoming request from LINE.
Connects to HiveMQ using TLS (Port 8883).
Publishes the command and Replies to the user.

// src/pages/api/webhook.ts
import type { NextApiRequest, NextApiResponse } from 'next';
import { Client, WebhookEvent, TextMessage } from '@line/bot-sdk';
import mqtt from 'mqtt';

// 1. Initialize LINE SDK with environment variables
const lineConfig = {
  channelAccessToken: process.env.LINE_ACCESS_TOKEN || '',
  channelSecret: process.env.LINE_CHANNEL_SECRET || '',
};
const lineClient = new Client(lineConfig);

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  // Only allow POST requests from LINE
  if (req.method !== 'POST') {
    return res.status(405).end();
  }

  const events: WebhookEvent[] = req.body.events;

  // Process events in parallel
  await Promise.all(events.map(async (event) => {
    if (event.type !== 'message' || event.message.type !== 'text') return null;

    const userMessage = event.message.text.toUpperCase();
    const replyToken = event.replyToken;

    // 2. Secure MQTT Connection (TLS 1.3)
    // We connect within the handler to ensure a fresh session for the serverless hit
    const mqttClient = await mqtt.connectAsync(`mqtts://${process.env.MQTT_BROKER}`, {
      username: process.env.MQTT_USER,
      password: process.env.MQTT_PASSWORD,
      port: 8883,
    });

    try {
      if (userMessage === 'ON') {
        await mqttClient.publishAsync('home/living-room/light', '1', { qos: 1 });
        await lineClient.replyMessage(replyToken, { type: 'text', text: '💡 Light turned ON' });
      } else if (userMessage === 'OFF') {
        await mqttClient.publishAsync('home/living-room/light', '0', { qos: 1 });
        await lineClient.replyMessage(replyToken, { type: 'text', text: '🌑 Light turned OFF' });
      }
    } catch (err) {
      console.error('MQTT/LINE Error:', err);
    } finally {
      // 3. Gracefully close MQTT connection to allow the Lambda to freeze
      await mqttClient.end();
    }
  }));

  res.status(200).send('OK');
}

Step 4: Deployment & Security

In 2026, we never hardcode credentials. We use environment variables to keep our secrets safe and our code clean.

Push to GitHub: Create a private repository and push your Next.js project.
Connect to Vercel: Import your repository into Vercel.
Configure Environment Variables: In the Vercel Dashboard, navigate to Settings > Environment Variables and add the following keys:
- LINE_ACCESS_TOKEN (Your Long-lived Channel Access Token)
- LINE_CHANNEL_SECRET (Found in Basic Settings)
- MQTT_BROKER (Your HiveMQ Cluster URL, e.g., xxx.s1.eu.hivemq.cloud)
- MQTT_USER (The MQTT credentials created in Part 1)
- MQTT_PASSWORD
Configure Webhook: * Once deployed, copy your Vercel deployment URL (e.g., https://iot-webhook.vercel.app/api/webhook).
- Go to the LINE Developers Console > Messaging API tab.
- Paste the URL into the Webhook URL field.
- Toggle "Use Webhook" to Enabled.

Step 5: Testing the Logic

Now it’s time to see the cloud-to-cloud communication in action.

Open the LINE Bot on your smartphone.
Tap the "ON" button on your Rich Menu (which we designed in Step 2).
Check HiveMQ: Open your HiveMQ Cloud Web Console. Under the "Web Client" tab, you should see a message 1 published to the topic home/living-room/light.
Check LINE: Your Bot should reply instantly: "💡 Light turned ON".

Summary

By leveraging Serverless functions, our bot only "lives" for the few milliseconds it takes to process a command. We’ve eliminated the need for a 24/7 running server, making this architecture highly cost-efficient, low-maintenance, and ready for the 2026 standard.

Coming Up Next

In Part 3, we finally bridge the gap between bits and atoms! We will flash our ESP32-S3 with C++ code to listen to these secure MQTT messages and finally toggle a physical LED in your room.

Happy Coding! 🚀

IoT #LINEAPI #Vercel #TypeScript #MQTT #SmartHome #DeveloperExperience

Modern IoT: Controlling Devices via LINE Bot, MQTT, and Serverless (2026 Edition)

Krisada Vivek — Fri, 06 Feb 2026 06:55:40 +0000

Introduction

Back in 2018, I started an "IoT Weekend" project using Heroku and CloudMQTT. Fast forward to 2026, the landscape has changed significantly. We have moved away from permanent virtual servers toward more robust serverless options, better security standards, and more efficient hardware.

In this updated guide, I’ll show you how to build a smart-home controller using the LINE Messaging API and MQTT, modernized for today’s developer workflow.

The 2026 Architecture

The flow remains elegant but is now more scalable and secure:

User triggers a command via a LINE Rich Menu.
LINE Platform hits a Serverless Webhook (Vercel/Next.js).
Webhook publishes a secure message to a Cloud MQTT Broker (HiveMQ/EMQX).
IoT Device (ESP32-S3) receives the command via a TLS-secured connection and toggles the hardware.

Key Tech Stack

Hardware: ESP32-S3 (with built-in hardware security)
Protocol: MQTT 5.0 (The modern standard for low-latency IoT)
Backend: Next.js / TypeScript (deployed on Vercel)
Broker: HiveMQ Cloud (Serverless MQTT)
API: LINE Messaging API v2

Why MQTT 5.0 in 2026?

While REST APIs are great, MQTT 5.0 is the backbone of the "Matter" era. It offers:

Binary Data handling: Highly efficient for tiny sensors.
Shared Subscriptions: Better load balancing for multiple devices.
Enhanced Auth: We now use TLS/SSL by default to ensure no one "sniffs" your home commands.

Preparation

LINE Developers Account: To create your provider and channel.
HiveMQ Cloud (Free Tier): Our modern MQTT broker.
Vercel Account: For hosting our webhook without managing servers.
Hardware: ESP32-S3, an LED, and a 220-ohm resistor.

Step 1: Setting up the Modern MQTT Broker

We’re skipping the old Heroku add-ons for a dedicated IoT SaaS.

Go to HiveMQ Cloud.
Create a Serverless Cluster (Free).
Security First: Create a "Database User" in the HiveMQ console. This credential will be used by your ESP32 and Webhook.
Note your Cluster URL (e.g., xxxxxx.s1.eu.hivemq.cloud).

Step 2: Deploying the Webhook (Serverless)

Instead of a long-running server, we use a TypeScript function. It wakes up, sends the MQTT command, and goes back to sleep—saving costs and resources.

// api/webhook.ts (Next.js / Vercel)
import mqtt from 'mqtt';

export default async function handler(req, res) {
  const client = await mqtt.connectAsync('mqtts://YOUR_CLUSTER_URL', {
    username: 'YOUR_USER',
    password: 'YOUR_PASSWORD',
    port: 8883 // Secure port
  });

  if (req.body.events[0].message.text === 'ON') {
    await client.publishAsync('home/living-room/light', '1');
  }

  res.status(200).send('OK');
}

Step 3: Hardware Evolution (ESP32-S3)

In 2026, we no longer use unencrypted connections (Port 1883). Modern IoT hardware like the ESP32-S3 features hardware acceleration for encryption, allowing us to use TLS/SSL (Port 8883) with minimal impact on performance.

Secure Connection Code (Arduino IDE Compatible)

To run this in the Arduino IDE, make sure you have installed the ArduinoMqttClient library via the Library Manager. This code uses WiFiClientSecure to handle the modern MQTT 5.0 encrypted handshake.

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <ArduinoMqttClient.h>

// WiFi & HiveMQ Credentials
const char* ssid     = "YOUR_WIFI_SSID";
const char* password = "YOUR_WIFI_PASSWORD";
const char* broker   = "YOUR_CLUSTER_URL.s1.eu.hivemq.cloud";
const char* mqttUser = "YOUR_DEVICE_USER";
const char* mqttPass = "YOUR_DEVICE_PASS";

WiFiClientSecure wifiClient;
MqttClient mqttClient(wifiClient);

// The LED pin - Pin 2 is common for built-in LEDs, adjust if using ESP32-S3 DevKit
const int ledPin = 2; 

void setup() {
  Serial.begin(115200);
  pinMode(ledPin, OUTPUT);

  // Connect to WiFi
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  // In 2026, we prioritize TLS 1.3
  // For development, we can skip cert validation, but production should use setCACert()
  wifiClient.setInsecure(); 

  mqttClient.setId("ESP32_Line_Controller");
  mqttClient.setUsernamePassword(mqttUser, mqttPass);

  Serial.print("Attempting to connect to MQTT broker: ");
  Serial.println(broker);

  if (!mqttClient.connect(broker, 8883)) {
    Serial.print("MQTT connection failed! Error code = ");
    Serial.println(mqttClient.connectError());
    while (1);
  }

  Serial.println("Connected to HiveMQ!");
  mqttClient.subscribe("home/living-room/light");
}

void loop() {
  // Keep the connection alive and check for messages
  mqttClient.poll();

  // Listen for the '1' or '0' payload sent from your LINE Bot via Vercel
  while (mqttClient.available()) {
    char c = (char)mqttClient.read();
    Serial.print("Message received: ");
    Serial.println(c);

    if (c == '1') {
      digitalWrite(ledPin, HIGH);
    } else if (c == '0') {
      digitalWrite(ledPin, LOW);
    }
  }
}

Summary: 2018 vs. 2026 Standards

The transition from 2018 to 2026 represents a shift from "making it work" to "making it secure and scalable." Below is a comparison of how the tech stack has evolved over the years.

Feature	2018 Approach	2026 Modern Standard
Hosting	Heroku (Monolithic)	Vercel / Cloudflare (Serverless)
MQTT Protocol	MQTT 3.1.1 (Insecure)	MQTT 5.0 (TLS/SSL Secured)
Language	Ruby / Sinatra	TypeScript / Node.js
Cloud Broker	CloudMQTT	HiveMQ / EMQX Cloud
Security	Basic Auth (Plaintext)	Token-based / TLS 1.3 Encryption

Conclusion

The shift from 2018 to 2026 isn't just about different tools; it's about adopting a Security-First and Scalable mindset. By leveraging Serverless functions and TLS-secured MQTT, your IoT projects are now more responsive, cheaper to maintain, and significantly more secure against modern threats.

What's Next?

In Part 2, we will configure the LINE Rich Menu. This will allow you to control your home with a polished UI—tapping physical icons on your phone screen instead of typing commands—and we'll set up Vercel environment variables to keep your credentials safe.

Happy Coding! 🚀

IoT #MQTT5 #ESP32 #Serverless #LineAPI #Arduino #WebDev #SmartHome

Beyond Autocomplete: The 2026 AI Toolset Every Software Engineer Must Master

Krisada Vivek — Sat, 03 Jan 2026 10:34:15 +0000

By Krisada Vivek
Date: 3rd January 2026

The New Reality of Engineering

It’s 2026. If you are still treating AI as just a slightly better version of IntelliSense, you aren’t just falling behind; you are actively increasing your own technical debt.

The "hype cycle" has settled. We are no longer impressed that an LLM can write a Fibonacci sequence. Today, AI has moved from being an assistant that sits beside us to becoming the infrastructure through which we work. Our value as engineers has shifted from writing syntax to system architecture, AI orchestration, and rigorous validation.

To thrive today, there is a core competency you must master: AI Fluency. ---

1. The Agentic IDE: Repository-Wide Context

We’ve moved past simple plugins. The IDE itself is now an agentic system. Tools like Cursor, GitHub Copilot Workspace, and the matured JetBrains AI are no longer passive.

The Shift: In 2026, you don't just highlight a function to explain it. You use agents for multi-file refactoring.
The Workflow: You prompt: "Update the auth flow to use biometric data, adjust the DB schema via a migration, and update the UI components." The tool generates a diff spanning ten files, runs existing tests, and proposes the migration script.
The Human Skill: You must become a master of diff review. The AI writes faster than you can read; your job is to spot logical flaws that emerge when AI touches complex business logic.

2. Autonomous QA and Test Agents

If you are still manually writing assertEqual for basic CRUD operations, you are wasting company time. Specialized testing agents integrated into GitLab/GitHub CI have matured into fully autonomous units.

The Shift: These agents analyze your codebase and generate complete, meaningful test suites (unit, integration, and regression) without human intervention.
The Capability: They don't just check for code coverage; they use AI to deduce the semantic intent of your code and test for edge cases you likely forgot.
The Human Skill: Defining semantic boundaries. AI is great at testing how the code works, but you must define what the code is supposed to achieve for the business.

3. AI-Powered Architectural Prototyping

The gap between a whiteboard sketch and a running frontend prototype has shrunk to almost zero. Tools evolved from Vercel v0 allow for instantaneous foundational builds.

The Shift: You can take a screenshot of a Figma design or a system diagram showing microservices connected by Kafka, and the AI generates the foundational, deployable code (Next.js/React, Docker Compose, or Kubernetes manifests).
The Benefit: It saves days of initial setup, allowing you to focus immediately on unique, high-difficulty business logic.
The Human Skill: Prompting as System Design. You must describe architectural patterns—like event sourcing or clean architecture—precisely so the AI generates a scalable foundation rather than a "monolithic mess."

4. Infrastructure-as-Code (IaC) Generators

Managing Cloud infrastructure manually (ClickOps) is extinct. Even writing raw Terraform is becoming rare for application engineers.

The Shift: Tools like Pulumi Insights generate IaC based on application requirements.
The Workflow: You state your needs: "I need a fault-tolerant REST API, PostgreSQL backend, AWS deployment, and a CDN." The AI agent generates the Pulumi or Terraform code, optimized for cost and security.
The Human Skill: Security and Cost Audit. The AI builds the infrastructure, but you own the bill and the data breaches. You must validate that the generated network configurations (VPCs, Security Groups) are truly secure.

Conclusion: The Synthesis Mindset

In 2026, AI didn't take the job of the software engineer; it took the job of the coder.

Our job today is *Synthesis. * We take the business requirement, use architectural agents to scaffold the solution, agentic IDEs to implement logic, and QA agents to validate it. If you aren't comfortable directing agents and questioning their output, you aren't ready for the "Production Era" of AI.

*The best time to start building these skills was two years ago. The second-best time is today. *

🚀 Flutter Mobile Testing Methodologies Recap 2025

Krisada Vivek — Sat, 26 Jul 2025 07:28:35 +0000

Flutter's momentum in 2025 has brought powerful upgrades to its testing ecosystem. Whether you're shipping production apps or contributing to side projects, structured testing is key to delivering reliable mobile experiences.

Here's a quick, practical recap of modern Flutter testing practices for this year.

✅ Unit Testing: Logic First

Unit tests are still the fastest and most isolated way to validate business logic. Dart’s built-in test package and mocking libraries like mocktail remain the go-to tools.

Best practices in 2025 emphasize:

Clear separation of business logic from UI
Value-based assertions over excessive mocking
Testing edge cases, not just the happy path

🧪 Widget Testing + Golden Testing (with Alchemist)

Widget testing is essential for verifying UI behavior and interactions. In 2025, alchemist has become the standard tool for golden testing—replacing the now-discontinued golden_toolkit.

Golden tests help detect visual regressions by comparing rendered UI to baseline images.

Why Alchemist?

Clean syntax for building UI snapshots
Built-in theme/layout variations
CI-friendly performance

Perfect for testing UI components in different device sizes and themes.

📱 Integration Testing with Patrol

For full end-to-end testing, patrol is leading the charge in 2025.

What makes Patrol stand out:

Interaction with both Flutter and native platform UI (e.g., permissions, alerts)
Cross-platform support (Android + iOS)
Smoother syntax and improved stability compared to integration_test

Patrol allows you to test the complete user journey—including system dialogs and background events.

🔁 CI/CD: Automate Everything

Testing is only as good as its automation. Most Flutter teams now integrate testing into their CI/CD workflows via platforms like GitHub Actions, Codemagic, or GitLab CI.

Recommended strategy:

Run unit and widget tests on every pull request
Schedule golden tests or run them on key merges
Execute Patrol tests on emulators or real devices post-merge
Send test failure alerts via Slack, Discord, or email

🔍 Summary Table

Testing Type	Tooling	Purpose
Unit Test	`test`, `mocktail`	Business logic validation
Widget Test	`flutter_test`	UI interaction in isolation
Golden Test	`alchemist`	Visual regression detection
E2E Test	`patrol`	Real-device, real-flow interaction
CI/CD Integration	GitHub Actions, Codemagic	Automation and team visibility

✅ Final Thought

Flutter testing in 2025 isn’t just faster—it’s smarter.

With tools like Alchemist and Patrol, developers can confidently ship clean, scalable code across devices and platforms.

Start small. Automate early. Your users will thank you.

✍️ Written by Krisada Vivek
🔗 Follow me on GitHub • Portfolio

flutter #mobiledev #testing #alchemist #patrol #devtools2025

🚀 Automation in 2025: n8n vs The Alternatives (What Devs Should Know)

Krisada Vivek — Tue, 15 Jul 2025 12:00:00 +0000

Tired of repeating tasks or manually syncing tools? You’re not alone.

In 2025, workflow automation is no longer just for ops teams — it’s becoming a core developer skill.

In this post, I’ll break down n8n, the go-to open-source automation tool, and compare it to key alternatives.

Let’s find the right fit for your next automation project.

🔧 What Is n8n?

n8n is a low-code, open-source automation platform built for developers. It lets you visually build workflows to integrate APIs, services, and custom logic.

✅ 350+ built-in integrations (REST, Webhooks, Databases, etc.)

✅ JavaScript anywhere (custom functions, expressions)

✅ Self-host or use n8n Cloud

✅ Advanced logic (if/else, wait, loops, error handling)

Ideal for: Developers who want flexibility, transparency, and control.

⚔️ n8n vs. The Competition

1. Zapier (Cloud, No-code)

Best for: Non-tech users automating SaaS
Pros: Easy UI, huge library
Cons: Expensive at scale, limited logic, no self-hosting 🔗 zapier.com

2. Make (Integromat) (Cloud, Visual-first)

Best for: Users needing advanced branching, data handling
Pros: Flexible scenarios, robust filters
Cons: UI can get complex, pricing tiers grow fast 🔗 make.com

3. Pipedream (Cloud, Code-first)

Best for: Developers writing quick API glue code
Pros: Fast setup, serverless execution
Cons: No visual flow, cloud-only 🔗 pipedream.com

4. Node-RED (Open-source, IoT-friendly)

Best for: Hardware & IoT automations
Pros: Low-resource, great for edge computing
Cons: Lacks modern SaaS integrations 🔗 nodered.org

5. Activepieces (Open-source, Zapier-style)

Best for: Teams needing self-hosted no-code flows
Pros: Clean UI, growing ecosystem
Cons: Still maturing vs. n8n’s depth 🔗 activepieces.com

👨‍💻 Why Developers Prefer n8n (Still) in 2025

Feature	n8n	Others
Self-hostable	✅ Yes	Mostly ❌
Custom logic	✅ JS-native	Limited (Zapier)
Visual editor	✅ Yes	Varies
Cost control	✅ Free/Self	Pay-per-run (cloud)
Community	🔥 Growing	Mixed

🧠 TL;DR: Choose Based on Your Stack

🧑‍💻 n8n – Best for devs who want control, custom logic, and open-source.

🧰 Make / Zapier – Best for fast SaaS integrations with no code.

⚙️ Pipedream – Best for quick backend automation with minimal setup.

🔌 Node-RED – Best for IoT/edge workflows.

🌱 Activepieces – Best for self-hosted Zapier-style automation.

✅ Final Thoughts

Automation in 2025 is more developer-centric than ever.

Whether you’re scaling internal tools, building no-code platforms, or streamlining your own ops — the right tool saves hours every week.

My go-to for dev-first workflow building? Still n8n — flexible, powerful, and made for coders.

💬 Have you used n8n or any of the alternatives? Drop your experiences in the comments 👇

📌 Follow me for more dev automation insights in 2025. Let’s build smarter, not harder.

Flutter vs React Native vs Kotlin Multiplatform (and More) in 2025 – What Should You Choose?

Krisada Vivek — Sat, 12 Jul 2025 04:09:04 +0000

Choosing the right mobile development framework in 2025 isn’t just about speed or performance — it’s about ecosystem, team skills, and future scalability. Here’s a concise breakdown of the top cross-platform players in today’s dev world.

⚡ TL;DR

Framework	Language	Best For	Drawbacks
Flutter	Dart	Fast UI, pixel-perfect apps	Larger app size, Dart learning curve
React Native	JavaScript/TypeScript	Web-to-mobile teams, rapid dev	UI inconsistency, performance bottlenecks
Kotlin Multiplatform	Kotlin	Shared business logic, native UI	Not full UI sharing, still maturing
SwiftUI + Jetpack Compose	Swift/Kotlin	Platform-first UX	No code reuse, platform-specific
MAUI (.NET MAUI)	C#	Enterprise, .NET ecosystem	Slow tooling, large footprint

🔹 Flutter (Google)

Why Use It? Full UI control with a single codebase for iOS, Android, web, and desktop. Backed by Google and improving rapidly with Impeller and Dart 3.
Use Case: Startups, design-heavy apps, multi-platform launches.
2025 Update: Flutter 4 brings better compilation, new dev tools, and improved native interop.

✅ Best choice for polished UIs and startups aiming to scale across platforms fast.

🔸 React Native (Meta)

Why Use It? Easy for JS/TS devs, wide community support, reusability with React ecosystem.
Use Case: Teams already using React or building MVPs quickly.
2025 Update: Fabric and TurboModules are mature, improving perf & native bridges.

🔁 Best for hybrid teams with strong web backgrounds.

🔹 Kotlin Multiplatform (JetBrains)

Why Use It? Share business logic across iOS, Android, desktop, backend.
Use Case: Teams that want to keep native UIs but avoid duplicating logic.
2025 Update: Stable KMP 1.1 and Kotlin 2.0 make it production-ready.

💡 Great for native-first apps with shared logic, especially in fintech, health, and enterprise.

🔸 .NET MAUI (Microsoft)

Why Use It? Unified .NET framework for mobile and desktop.
Use Case: Enterprise apps, existing C# teams.
2025 Update: Better tooling and community, but still less traction outside enterprise.

🏢 For .NET shops looking to reduce code duplication.

🔹 Native (SwiftUI & Jetpack Compose)

Why Use It? Best platform integration, smoothest UX.
Use Case: When perfect native experience is required.
2025 Update: Declarative UI now stable and dev-friendly on both iOS and Android.

🔥 Ideal for apps where UX trumps development speed.

🔍 Final Thoughts

You Are...	Consider
A startup or indie dev	Flutter or React Native
An enterprise team	Kotlin Multiplatform or MAUI
A native-focused product team	SwiftUI + Jetpack Compose
A web-first dev team	React Native

No one-size-fits-all. Choose what matches your team’s skill, product needs, and long-term roadmap.

👨‍💻 Follow me for more updates on mobile dev, architecture, and real-world implementation tips!

flutter #reactnative #kotlinmultiplatform #mobiledevelopment #2025

📱Is Flutter Dying in 2025? A Deep Dive

Krisada Vivek — Tue, 15 Apr 2025 10:23:37 +0000

Flutter has been a powerful cross-platform framework since 2017, but there’s been a lot of buzz in 2025. Let’s explore the facts, myths, and future of Flutter in depth.

🚀 What is Flutter?

Flutter is an open-source UI framework by Google that allows you to build apps for:

iOS
Android
Web
Desktop

All from a single Dart codebase.

⚠️ Why Do Some People Think Flutter Is Dying?

1. Google’s Mixed Signals

Flutter’s promotion by Google has slowed.
Some deprecated features have caused confusion.
Focus seems to be shifting toward Flutter Web and embedded systems.

2. Rise of Other Frameworks

React Native, Kotlin Multiplatform, and Jetpack Compose are getting better.
Developers are exploring native-first approaches.

3. The Flock Fork

A group of developers created Flock, a community-led fork of Flutter.
Aimed at addressing long-standing issues and improving Flutter’s build system.
Some viewed this as a sign of Flutter weakening—but it actually shows growth and community resilience.

✅ What’s Actually Happening in 2025?

🔄 Flutter Is Evolving, Not Dying

1. Flutter 4.0 + Impeller Engine

New rendering engine: Impeller
Better performance: smoother animations, faster startup.

2. Stable Web & Desktop Support

Flutter Web and Desktop are now production-ready.
Widely used for:
- Admin panels
- Enterprise tools
- Internal business apps

3. Ecosystem Growth

Mature packages:
- riverpod, flutter_bloc (state management)
- go_router (navigation)
- flutter_hooks, animations, etc.

4. Google is Still Supporting Flutter

Regular updates.
Ongoing investment in:
- Web performance
- Material 3
- Dart improvements
- DevTools and Hot Reload

🌐 What is Flock and Should You Care?

Flock is a community-led fork of Flutter focused on:

Smaller SDK
Faster build times
Removing Google-specific code

Flock is not a threat—it's a complement. Think of it like Ubuntu vs. Debian in the Linux world.

💼 Flutter in the Job Market (2025)

📊 Still in Demand For:

Fintech
E-commerce
Government & enterprise apps
Startup MVPs

🧪 Notable Flutter Apps in 2025:

eBay Motors
Google Classroom (portions)
BMW in-car UIs
Various internal corporate tools

🧠 Should You Learn Flutter in 2025?

Yes, if:

You want to build multi-platform UIs quickly.
You work on apps that need high customizability or animation.
Your team/company already uses Flutter.

Maybe not, if:

You’re focused only on backend development.
You prefer native APIs like SwiftUI or Jetpack Compose.
You’re building hardware-heavy apps (AR, Bluetooth, etc.).

🔚 TL;DR

Is Flutter Dying in 2025?

No. It’s evolving.

Still supported by Google.
Actively used in the industry.
Community is engaged and innovating (e.g., Flock).
Remains a top choice for cross-platform UI.

Want a breakdown between Flutter vs React Native vs Kotlin Multiplatform in 2025? Or details on how Flock technically differs from Flutter? Just let me know!

Summarized Flutter in 2024 and what's new for 2025.

Krisada Vivek — Wed, 25 Dec 2024 11:39:11 +0000

Flutter in 2024:
As of 2024, Flutter remains one of the leading frameworks for building cross-platform applications, enabling developers to create mobile, web, and desktop apps with a single codebase. Key features include:

Unified Codebase: Write once and deploy to iOS, Android, web, and desktop, reducing time and resources needed for development.
Improved Performance: Continued optimization of the framework and engine for faster, native-like experiences, especially on mobile devices.
Mature Web & Desktop Support: While Flutter was initially focused on mobile, its support for web and desktop has become more robust, providing stable cross-platform experiences.
Rich Widgets & Customization: A wide variety of highly customizable UI widgets, enabling developers to create beautiful, responsive apps.
Strong Ecosystem: A large and growing collection of community-driven packages and plugins, as well as deep integration with services like Firebase.
Active Development: Continuous updates and improvements, including Dart enhancements, tooling improvements, and expanded native integration.

What's New for Flutter in 2025:

Looking ahead to 2025, several trends and updates are expected:

Flutter next (4.0) and Beyond: The upcoming major release, Flutter 4.0, will likely continue refining cross-platform performance, with even better native integrations and optimizations for mobile, web, and desktop.
Enhanced Desktop Support: Expect even more advanced desktop capabilities with Flutter, possibly including better support for macOS, Linux, and Windows-specific features, as well as more desktop-native UI components.
Improved Web Performance: Ongoing improvements in Flutter’s web capabilities, especially in rendering and responsiveness, to bring it closer to native web app performance.
Tooling Enhancements: Flutter's developer tools, such as Flutter DevTools, will continue to evolve, making debugging, profiling, and testing even more powerful and user-friendly.
Integration with AI and ML: As AI/ML capabilities become more pervasive, Flutter may see deeper integration with Google’s machine learning tools (like TensorFlow Lite), enabling app developers to easily implement AI-driven features.
Better State Management: There will likely be further advancements in state management techniques and tools, improving performance and scalability in large apps.
Increased Adoption of Flutter on Embedded Devices: We could see Flutter making inroads into embedded system development, where lightweight UIs for IoT devices and hardware interfaces are needed.

In summary, Flutter in 2024 is a mature, cross-platform solution with broad support across mobile, web, and desktop. The future of Flutter in 2025 will likely include enhanced performance, better tooling, deeper AI integration, and expanded desktop and embedded capabilities.

Testing on Flutter: generate unit test badge using LCOV to your repository

Krisada Vivek — Thu, 03 Sep 2020 10:48:00 +0000

TLDR; in this publication, I assumed that you all know how to write test and testing terminology and methods, no mentions here.

What is LCOV

LCOV is a graphical front-end for GCC’s coverage testing tool gcov. It collects gcov data for multiple source files and creates HTML pages containing the source code annotated with coverage information. It also adds overview pages for easy navigation within the file structure. LCOV supports statement, function, and branch coverage measurement.

Installing LCOV

brew install lcov

Generating an example app — flutter counter app
example test scripts ./test/widget_test.dart

Objective of lcov

To see the coverage of the code.
To deliver the code with quality.

To perform the test with coverage

install test_coverage library in pubspec.yml under dev_dependencies

dev_dependencies:
    flutter_test:
       sdk: flutter
    test_coverage: ^0.4.2

then run test command with flags

flutter test --coverage

when test complete it will generate folder ‘coverage” in the project directory, to see the result in visualized, run this commands

genhtml -o coverage coverage/lcov.info
# Open in the default browser (mac):
open coverage/index.html
this is the html report, that generated out looks like.

now you will get the coverage result, but I want to present in the GitHub repo how do I do that? you should get a badge!!!

To generate badge image

assume that you are at the root of the project

$ yarn init
$ yarn add lcov2badge — more detail here

then create a javascript script to generate a badge form the coverage file.

what you get is the ./coverage_badge.svg that you can use inside the README.md file, like this.

![Coverage](./coverage_badge.svg?sanitize=true)

the example Github code can be found here!

3lVv0w / test_lcov_bedge

this repo demonstrate how to generate coverage badge form lcov.info for unit testing

test_lcov_bedge

A new Flutter project.

Getting Started

This project is a starting point for a Flutter application.

A few resources to get you started if this is your first Flutter project:

For help getting started with Flutter, view our online documentation, which offers tutorials, samples, guidance on mobile development, and a full API reference.

View on GitHub

If you have any question/discussion with me, you can contact/ follow me
FB: Krisada Vivek
DEV.to: @3lvv0w

Follow me Krisada Vivek for a more upcoming tech publication