Introduction

As AI drives development costs to unprecedented lows, the foundational logic of software engineering is being restructured. This article uses the example of a development scheduling tool to reveal how AI can complete traditional team processes worth tens of thousands of yuan with just 124.8 yuan in cash and 8 hours of labor. It also deeply analyzes the disintegration of the Taylorist management system and the reconstruction of the product manager’s role.

While coding and enjoying watermelon, I suddenly realized a key point: AI does have hallucinations and is not entirely controllable, but it has an unstoppable trend—cost reduction. Time costs, labor costs, opportunity costs, and sunk costs have all been minimized. The MVP strategy that product managers have been advocating for years has finally become feasible.

When coding is no longer a bottleneck, where should software engineering management theory head? It is clear that AI is dismantling a fundamental structure—the old division of labor system based on Taylor’s scientific management, which focuses on “task division and manual translation.”

In simple terms: what we once thought required collaborative division of labor can now be accomplished by one person and a computer in just two weekends.

What I Created

In two weekends, totaling 7-8 hours, I developed a development scheduling management tool. The core features include:

• Intelligent Scheduling Engine: Automatically matches personnel with positions, resolving resource conflicts and task dependencies that previously took hours of discussion.
• Visual Gantt Chart: Allows for drag-and-drop adjustments to the schedule, with real-time updates.
• Resource Calendar: Manages overtime and leave uniformly, with the system automatically assessing the impact of personnel changes on the schedule.
• Automatic Email Notifications: When the schedule changes, relevant personnel automatically receive notifications without needing to @ everyone in a group chat.

Additionally, it includes a dashboard, multi-user permissions, and a feedback system, effectively completing the entire process of development scheduling.

https://schedule-d9gwumlxp26e60447-1443061996.tcloudbaseapp.com/

Cost Breakdown

Here’s the accounting:

• Token cost: 24.9 yuan
• Cloudbase server: 59.9 yuan (for 3 months)
• Two watermelons: 30 yuan
• Electricity: 10 yuan
• My labor time: 8 hours, low intensity

Total: 124.8 yuan in cash + 8 hours (including time spent eating watermelon).

Traditional Development Costs

Let’s calculate the costs if we followed traditional development processes.

First, the reviews. At least two rounds of intensive reviews, each lasting a minimum of two hours, involving testing, development, UI, frontend, and operations. Two rounds would total 16 hours, equating to about 2 person-days, costing around 2000 yuan just for reviews.

Next is development. Given the complexity of this system, it would require at least: 5 person-days for backend, 3 for frontend, 2 for UI, and 2 for testing. This does not even account for the product manager’s time.

Speaking of product managers, there’s a very real issue: they face endless rounds of re-confirmation. No matter how clearly the PRD is written, there will always be misunderstandings due to context loss. Moreover, developers often miss places where the product manager hasn’t specified default logic—like if the product manager doesn’t explicitly state that passwords should be stored encrypted, most developers will store them in plain text. Discovering this requires another iteration and another round of reviews to resolve.

Going through this process, the time, labor, and communication costs are far beyond what two or three weekends can cover.

Real Challenges Encountered

It would be untrue to say there were no issues. Working with AI for development reveals the pitfalls only when you dive in. The tool I used was Trae, and I spent several days tweaking it, nearly crashing the project a few times.

Pitfall 1: A Huge HTML File from the Start

On the first day, I purely described my requirements: “I want a scheduling tool that can manage demands and personnel, and automatically generate a Gantt chart.” Trae generated an index.html file directly, containing the data model, UI, and Gantt chart all in one. It was ready to use, which felt great.

However, as more features were added, this file grew to nearly 4000 lines. Changing one part often affected another unrelated module because everything was in one file, with all variables global. It was hard to manage.

Later, I had Trae break the project into a React structure, organizing it into pages, components, utils, and store under the src/ directory. After this change, the scope of modifications became visibly smaller—changing the demand page wouldn’t affect the scheduling engine, and the type definition compiler would directly inform me where updates were needed.

Experience: Rapid iteration with a single file is fine for feature validation, but once the core logic stabilizes, it’s best to modularize the structure as soon as possible.

Pitfall 2: Login Button Unresponsive, Debugging for Half an Hour

After adding login and registration, I prepared for pre-deployment testing and found that clicking the login button did nothing, with no errors reported in the console.

I had Trae add logs in doLogin, and after rebuilding, found that the logs weren’t printing at all—indicating the function wasn’t registered globally. Tracing back, I discovered that while adding a legend to the dashboard, Trae’s SearchReplace matched a block of code containing both the Gantt chart and resource load chart, inadvertently duplicating a crucial } else { structure, which rendered a large segment of the script (including doLogin and all page logic) dead code.

After fixing this, I developed a habit: after any modification, I compile everything to ensure nothing is missed, even if it’s just a small CSS change.

Conclusion: Where Should Management Theory Go?

As AI brings the cost of “writing code” close to zero, the scarce resources in software engineering will no longer be “production capacity” but rather the abilities to define problems and assess value. Future management may shift from focusing on how to execute each step to addressing a few more fundamental issues:

1. Result Acceptance: Clearly defining acceptance criteria rather than fixating on the process.
2. Feedback Loops: How to quickly verify the correctness of generated code?
3. Constraint Management: Hard constraints like overtime, leave, and resource conflicts are more critical than scheduling itself.

Another direct conclusion is that the boundaries between product managers and developers are disappearing.

The future “developer” may be someone who understands the business, can write clear prompts, and can design acceptance scenarios. Code reviews may evolve into “logic reviews” or even “cost reviews”—because the tokens you spend are also money.

The old systems established to “reduce rework” through reviews, approvals, and documentation processes may become the largest costs in the AI era. The cost of trial and error has dropped so low that you can abandon “big planning and big design.”

The product I created in 8 hours can be discarded and redone without regret. The layered approval and repeated confirmation processes were fundamentally designed to prevent “humans” from being lazy or making mistakes—but AI does not have this laziness; if you tell it that passwords need to be encrypted, it will call the encryption library without negotiation.

So, Where to Go?

We are moving towards a direction where there are “no engineers, only problem solvers.”

We are truly entering a new era.