This author is transitioning from PHP full-stack to Go, using AI as a companion throughout. The task in part 59 is mundane: change the admin entry point from /admin to a custom path (for security reasons). The tech is simple, but the interesting part is the gap between "what AI wrote first" and "what it produced after review."

What This Is

Background: the author is building an open-source admin framework called ai-go-admin, where all backend routes are mounted under /admin by default. He wants to support customization—for example, changing it to /dfwef1dki—so the admin entry isn't so conspicuous.

He first asked AI for several implementation approaches (file config vs. constant), and AI's suggestion was to add an app.admin_path config item. He glanced at it and decided that path-related config belongs under the server namespace, not app, and told AI to redo it.

After AI redid it, the author noticed it had made another small architectural mistake: in a function called BuildCheckPath, AI had the function receive adminPath as a parameter from outside, instead of reading the config itself. The author judged that since this function lives in the infra folder (internal code, not a public package), it could read the config directly and shouldn't be passed from upstream.

This is a classic case of "AI can write code, but needs to be taught how to write it properly."

Industry View

Many engineers support this workflow. Frontline developers repeatedly note on Twitter/X and V2EX that AI coding tools' biggest value isn't replacing coding, but translating "what I want to do" into "code that runs"; real design judgment still requires a human.

But there's dissent. A former Alibaba P8 wrote a similar concern in a Zhihu comment: over-reliance on AI coding will cause junior programmers to skip the training of "why this way"—and when they later need to review AI output and judge the merits of approaches, they won't be able to handle it. This author's ability to spot the app vs. server namespace issue, and to judge whether BuildCheckPath should read the config itself, comes precisely from traditional software engineering training.

There's another overlooked risk: AI-generated code looks like it runs, but the engineering details (namespace ownership, parameter passing reasonableness, middleware mounting position) only surface during review. This author reviews every installment—that's a critical habit.

Impact on Regular People

For enterprise IT: This kind of "AI-assisted development" workflow is maturing fast, but if companies adopt AI coding tools, they still need to keep a human review step in place—otherwise the code may ship, but so will the architecture debt.

For individual careers: A programmer's core competitiveness is shifting from "writing" to "judging." Those who can accurately tell AI "what's wrong and why" will be worth more than those who just write code.

For consumer markets: No direct impact visible yet. But one observation: the open-source community is producing more and more real-world records of "human + AI collaboration," which reflect the true capability boundaries of AI coding tools better than vendor launch events.