AI Library
The Age of Autonomous Scientific Discovery
Kim Kyung-jin, Attorney at Law
AI Scientists and Self-Driving Labs
This book follows how AI scientists and self-driving labs are changing the way science generates and verifies claims. It covers literature-based discovery, natural-language protocols translated into robot commands, multi-agent research systems, closed-loop laboratories, materials search, the verification gap, chains of evidence, research harnesses, journal ethics, and legal responsibility.
AI Library
A New Era of Life Sciences Opened by Artificial Intelligence
Structural Proteomics, Genomic Foundation Models, Autonomous Laboratories, and Global Governance
Kim Kyung-jin, Attorney at Law
This book is a research volume compiled with artificial intelligence. A human selected the materials and structured the work, while AI models drafted the sentences and cross-checked the facts.
AI Library
The Double Structure of Digital Sovereignty
Europe’s Departure from Palantir and the Chains of American Big Tech
Kim Kyung-jin, Attorney at Law
This is a record of 2026, when European intelligence agencies and defense ministries began removing analytics tools from America’s Palantir. It covers the replacement decisions made by France’s General Directorate for Internal Security (DGSI), Germany’s Federal Office for the Protection of the Constitution (BfV), and the Netherlands Ministry of Defense; the incident in which US export controls severed an ally’s ac…
New English Edition
Artificial Intelligence in Horticulture
Kim Kyung-jin, Attorney at Law
Across five chapters and ten sections, this book examines computer vision for crop diagnosis, harvesting robots and autonomous field systems, smart greenhouses and digital twins, precision irrigation and supply-chain quality control, high-throughput phenotyping, and predictive breeding.
New English Edition
Artificial Intelligence in Food Crop Agriculture
Kim Kyung-jin, Attorney at Law
Across six chapters and eighteen sections, the book examines digital agricultural infrastructure, remote sensing, crop diagnosis, yield forecasting, precision irrigation, genomics, molecular breeding, agricultural robotics, climate-smart agriculture, and global food security.
New English Edition
The Future of Forestry and Agroforestry
Kim Kyung-jin, Attorney at Law
Driven by Artificial Intelligence and Digital Innovation
Across five chapters and fifteen sections, the book follows satellites, drones, LiDAR, digital twins, forest-specific language models, wildfire and pest forecasting, forestry robotics, agroforestry, timber traceability, and forest carbon markets.
New English Edition
Smart Livestock Farming: AI Enters the Barn
Kim Kyung-jin, Attorney at Law
Sensors listen, cameras watch, and artificial intelligence helps farmers decide.
Across five chapters and fifteen sections, the book follows precision livestock farming from animal health and reproduction to robotic milking, virtual fencing, digital twins, methane reduction, welfare, and data ownership.
Table of Contents
Han Dong-hoon, Busan Buk-gu Gap: A Record of the 100 Days Before and After the Election (Mar. 26-Jul. 3, 2026)
Kim Kyung-jin
Table of Contents and 13 sections
From March 26 to July 3, 2026, this record follows the spring after expulsion, the Busan Buk-gu Gap by-election, victory as an independent, and the first bill submitted in the National Assembly.
Table of Contents
Artificial Intelligence and Medicine
Kim Kyung-jin, Attorney at Law
AI in clinical care, hospitals, education, and research
AI in medical imaging, risk prediction, treatment planning, hospital operations, education, and research, with patient safety, privacy, and accountability.
[AI Library] Chapter 16: Beyond Deployment: Maintenance and Updates
Mastering Claude Code
Chapter 16: Beyond Deployment: Maintenance and Updates
Kim Kyung-jin
Mastering Claude Code
The Limits of Deployed Automation: Where Self-Healing Disappears
Two days after the Blender landing page goes live, I open the site. It works fine. A week later, still no problems. But a month later, scroll animations begin to freeze on certain mobile browsers. The question becomes where to start fixing it. Can I just tell Claude Code to fix it?
During development, Claude Code demonstrates strong self-checking abilities. It takes screenshots to compare, reads error logs, fixes code, and validates again. Because this cycle happens in real time, problems are caught and fixed immediately.
But on a deployed site, this self-healing loop stops working. Claude Code is a tool that runs in my computer's development environment, not a tool that monitors a deployed server continuously. After the site goes up on Vercel, Claude Code's session likely ended. When problems occur, no entity exists to detect or fix them automatically.
This difference must be clearly recognized. During development, AI acts as an "active guardian." After deployment, AI becomes an "on-call repair person."
The types of problems that can occur after deployment differ in nature from development bugs.
External dependency changes: The response format of an external API the site uses may change, or the URL of a font file hosted on a CDN (Content Delivery Network) may be modified.
Browser updates: When Chrome or Safari updates, the behavior of certain CSS properties or JavaScript APIs may change. Animations that worked perfectly during development actually break on new browser versions.
Traffic changes: If visitors suddenly surge, image loading may slow down or animation frames may drop. On my computer, I alone access it, so I cannot experience such problems.
Certificates and domains: Infrastructure-level problems like SSL certificate expiration or missed domain renewal can occur. Vercel handles much of this automatically, but for custom domains, renewal is the user's responsibility.
The basic principle for handling these problems is to visit and check the site regularly in person. When no automation tool is available, human eyes are the best monitoring available.
The Difference Between Scheduled Execution and Webhook Triggers
Cannot the task of checking the site regularly be automated itself? Two approaches exist.
Scheduled execution repeats specific tasks at fixed time intervals. It is the kind of task where you "access the site's main pages every morning at 9 AM and measure response time." This method, also called a cron job, is time-based. Because a time gap exists between when a problem occurs and the next check, problems may not be discovered immediately.
In Claude Code, you can set up simple scheduled execution with the /loop command. When you request "check deployment status every 5 minutes," it checks repeatedly within the same session. However, this loop runs only while the session remains active, and lasts at most 3 days. If long-term monitoring is needed, you must build a separate monitoring service.
A webhook trigger works differently. It is a structure that sends alerts or executes tasks immediately when a specific event occurs. "When a new commit is pushed to GitHub, Vercel automatically redeployment" is a typical example of a webhook. It reacts to events, not to time.
The difference between the two approaches can be summarized as follows.
In practice, both approaches are combined. Webhooks handle deployment automation and immediate alerts, while scheduled execution performs regular health checks.
Vercel itself is a prime example of GitHub webhook use. When Vercel registers a webhook with a GitHub repository, GitHub notifies Vercel of "new changes" each time a commit is pushed. Vercel pulls the code, builds it, and deploys it the moment it receives that signal. This process is connected automatically without the user needing any separate setup.
Battle Testing Before Deployment: Validation with Diverse Inputs
If you go through one more procedure before pressing the deploy button, you can prevent a considerable portion of problems after deployment. It is battle testing.
A developer built a payment form. On my computer, I enter a name, email, and card number, then click submit. It works. Deploy. But then a real user enters a Korean name in the email field. Another user puts a space in the card number field. Yet another user clicks the back button and submits again. One of these causes an error, and the site freezes.
Battle testing is not using the site "normally," but trying to use it "abnormally." It intentionally tests unexpected inputs, illogical click sequences, extreme screen sizes, slow network conditions, and so on.
Methods for battle testing using Claude Code exist.
Include validation steps in the to-do list. As covered in the previous chapter, we could add items like "build the website, take a screenshot, and verify it" to Claude Code's self-generated to-do list. By the same logic, we can add items like "check rendering at various browser sizes," "try submitting a form with empty values," and "simulate an image-loading failure."
There is also a method using Chrome DevTools. Claude Code can open a browser and interact directly. It clicks buttons, fills forms, and reads console errors. Using this capability, you can request "open the site, try clicking every button, and check if there are errors in the console."
Mobile responsiveness must not be overlooked. You will remember that when opening the Blender site on a phone earlier, the layout looked odd because mobile optimization was missing. Including the instruction "check whether the layout displays correctly at mobile viewport size" in pre-deployment checks lets you catch such problems early.
Battle testing has one principle: doubt the assumption "it works fine when I use it, so it should be okay." Verify in advance what happens when someone else, using the site in ways you did not anticipate.
The Principle of Deploying Workflows and Tools, But Not Agents
Once you understand the pipeline of website deployment, a natural thought arises: "Cannot I deploy the AI agent itself and run it 24 hours?"
Suppose you create a workflow with Claude Code that automates the process of collecting data, analyzing it, and making a report. Could you not upload it to a server and have it run continuously without people?
The answer is "it is possible, but in most cases it is better not to."
A fundamental difference exists between workflows and agents. A workflow executes fixed steps in order. Input comes in, it performs the set processing, and produces output. The path is predictable. Agents are different. They assess the situation and decide their next action independently. Even with the same input, they can act differently depending on context.
Deploying a workflow is safe. "Each morning, retrieve data from this API, convert it to this format, and store it in this database." Such workflows have clear steps, are easy to diagnose when they fail, and behave predictably.
Deploying an agent, by contrast, creates unpredictable situations. When an agent sends a request to an external API and the response differs from expectations, you cannot know in advance what judgment the agent will make. When a person is present, you can review and correct the agent's decisions, but in an unattended environment, bad judgments can cascade.
Practical guidance is as follows.
What you should deploy are tools and workflows. Website code, scheduled data collection scripts, API endpoints, and automated build pipelines fall into this category.
Better left undeployed are agents that require judgment. Agents that analyze code and refactor, agents that interpret user feedback and decide on design changes, and agents that combine multiple APIs to perform complex tasks are safer to run in human-supervised environments.
You can also install Claude Code on a remote server like a VPS (Virtual Private Server) and keep it running always. Because sessions persist even if you close the laptop, this favors long-running work. You can access it via SSH (Secure Shell) or even control it remotely from a phone. But even in this case, the assumption that "a person checks it regularly" is necessary.
There is a crucial difference between an agent deciding and acting alone and an agent working while a person reviews.
This boundary can shift depending on the project's nature. Low-risk, easily reversible work (such as drafting blog posts) can give agents more autonomy. High-risk, hard-to-undo work (like database schema changes or payment system modifications) must pass through human review.
Your website is live. Your deployment pipeline is in place. Your maintenance principles are established. Tools have given you the technical skill to write and deploy code, yet what you build, whom you build for, and what quality you maintain remain human judgments. The more capable you grow with tools, the more urgent becomes a different question: What will you do with them?
Kim Kyung-jin, AI Policy Expert and Lawyer
Specialist in AI law and policy · Former Member of the National Assembly · Author of multiple works
If this book has stayed at your side even for a moment, please support the next story reaching the world.
(Voluntary support welcome. Bank: Nonghyup, Account: 302-1096-0948-81, Account holder: Kim Kyung-jin)
Kim Kyung-jin
Attorney · Former Member of the National Assembly · AI Policy Researcher
© 2026 Kim Kyung-jin. All rights reserved.