Engineering Ethics in the Age of AI
1. The Problem
Rapid improvements in AI productivity bring more than faster execution. They reorganize skills, redistribute learning costs, unsettle a sense of career security, and change how people define their contribution. Such disruption is a natural part of a generational technology shift. For an engineer, the practical question is how to build dependable ways of working amid that change.
2. A Shift in What Matters
Capability Has Not Disappeared; Its Structure Has Changed
People in different eras are not separated by a large difference in intelligence. What changes is the abstraction level of tools, the complexity of production systems, and the cost of obtaining information. AI changes the shape of the entry barrier.
| Earlier emphasis | Growing emphasis |
|---|---|
| Memorization | Understanding systems |
| Manual implementation | Architectural judgment |
| Fluency in code syntax | Organizing abstractions |
| Human-agent collaboration |
Anxiety About Control
When some execution moves from people to systems, discomfort is understandable. Giving up low-level execution does not necessarily mean giving up the right to set goals. Valuable engineering work moves toward goal setting, defining constraints, structural design, and evaluation.
3. The Cognitive Cost of Higher-Level Control
More Layers to Hold in Mind
The progression from LLM-assisted coding to agent-led task execution and then to delegating more decisions increases the abstraction level of the object an engineer manipulates.
| Stage | Primary object | C analogy |
|---|---|---|
| LLM-assisted coding | Concrete code | int x |
| Agent coding | Tasks and steps | int *p |
| Higher-level control | Rules and constraints | int **pp |
| Full feedback loop | Rules about rules | int ***ppp |
At every level, working memory must hold that level's meaning, its mapping to the next level, and how lower levels produce actual behavior. That is real cognitive load.
Why Generalization Is Difficult
A step-by-step document for one feature is concrete. Generalizing it to a class of features, and then to a meta-document for many business domains, requires enough specific examples to identify a stable pattern. More examples also fill working memory. The difficulty can be a capacity limit at a high abstraction level rather than a lack of ability.
Feeling Carried Along by an Agent
An agent can produce and expand work faster than a person can integrate, name, and stabilize the concepts behind it. It may instantiate a layer that has not yet been defined. The person sees an output without having gone through the definition process, so the layer is hard to recognize or retain.
An Engineering Response
C code with several pointer levels becomes easier to reason about when each level has a stable name:
typedef int* IntPtr;
typedef IntPtr* IntPtrPtr;
Agent work can follow the same idea. Name an abstraction and fix its boundary before using it as the foundation for a higher layer. Yet defining every layer before seeing examples can become circular: without examples there is nothing to generalize, and without a generalization the layer cannot be defined. A practical approach is to run a few concrete cases, find their common structure, and then name it. Agent output becomes material for learning rather than a stream to chase.
4. Stable Ethical Responsibilities in Production
Use AI to Amplify Work
Humans define the problem, AI explores possible solutions, and humans judge the quality of the result. This describes a division of responsibility rather than a claim that the system can own the outcome.
Treat Learning as Structural Investment
Industrial, computing, and AI transitions all devalue some skills and reward investment in others. The decision is where in the new abstraction stack to invest, not how to avoid every learning cost.
Turn Anxiety into a Design Question
Useful questions include: Which technical stage am I working at? Can I handle the new abstraction level? Do I know how to design an agent workflow? Can I judge the system as a whole? Giving these concerns a structure makes them more tractable.
5. Principles for Future Work
Keep Ownership of Goals
People must define goals, take responsibility for value judgments, and choose direction. Tools extend capability; they do not supply meaning.
Make the Production Chain Explainable
Keep process logs and decision trails, and establish evaluation criteria for agent or automated work. Visibility into how an outcome was produced can reduce uncertainty.
Raise the Level of Abstraction
The work can move from writing code to designing systems, from executing tasks to structuring tasks, from solving a given problem to defining the right problem, and from following rules to designing the rules themselves.
6. Conclusion
Technical progress does not automatically improve well-being. It can expand what people can build, open higher-level creative work, and change human-system collaboration. In a production setting, the ethical responsibility is to retain ownership of goals, develop the ability to reason at the relevant level, and build a stable collaborative structure. Anxiety can indicate that the structure of work needs to change; making that change explicit turns it into an engineering problem.
Appendix: A Hypothetical Cost of a Full AI Engineering Loop
Historical scenario, not a current price quote or measured deployment cost. The source imagined an engineer with five years of backend experience leading work on a million-line business system, collaborating daily with 10–15 developers and five business or product colleagues, and drawing on roughly one million Chinese characters of system documentation. AI-assisted development was assumed to be routine, with agents involved in coding, review, and design discussion. The question was what a complete AI loop aligned to that engineer's work rhythm might cost if all stages existed.
Model and Price Assumptions
| Work | Example model | Assumed input/output price per million tokens |
|---|---|---|
| Intent classification and routine Q&A | Claude Haiku | $1 / $5 |
| Technical plans and architecture | Claude Sonnet | $3 / $15 |
| Coding, generation, and review | Claude Opus | $15 / $75 |
| RAG embeddings | Local or low-cost Qwen3-8B route | About $0.05 |
These prices were assumptions in the original calculation. Actual provider prices, model names, and usage patterns can change.
Assumed Data Volume
Two hours of meeting recordings per workday over 250 days and five years would total 2,500 hours. At roughly 150 Chinese characters per minute, the source estimated around 22.5 million characters, or 30 million tokens. It estimated another 40 million tokens of work conversations over five years. For one million code lines at about ten tokens per line, a 30% core selection would be around 30 million tokens. A million-character documentation set was estimated at 1.3 million tokens. Together the embedding corpus was rounded to about 100 million tokens.
| Source | Estimated size |
|---|---|
| Five years of work conversations | ~40 million tokens |
| Five years of transcribed meetings | ~30 million tokens |
| System documents | ~1.3 million tokens |
| Core 30% of the codebase | ~30 million tokens |
| Rounded embedding corpus | ~100 million tokens |
At the assumed embedding price, a full one-time pass would be 100 million / 1 million × $0.05 = $5, roughly CNY 36 in the source's exchange-rate assumption. This excludes data preparation, storage, re-embedding, and operational work.
Assumed Daily Calls
Intent classification: 150 calls at about 320 input tokens each and $1 per million input tokens gave $0.048.
Routine Q&A: 60 calls at 2,500 input and 600 output tokens, using the assumed Haiku prices, gave $0.33.
Technical design: 15 calls at 5,000 input and 1,500 output tokens, using the assumed Sonnet prices, gave about $0.56.
Coding and review: The source used a personal-project anchor of roughly $30/day for intensive Sonnet-based agent work. It assumed a million-line system would require changes across 10–30 files and 200,000–400,000 input tokens per action, then used a fourfold complexity factor: $30 × 4 = $120/day for Sonnet. It estimated Opus at five times that cost, or $600/day. These are scenario multipliers, not measured enterprise usage.
Knowledge ingestion: For 50 captures a day, the source calculated about $0.35 of Haiku work and $0.525 of Sonnet work, totaling about $0.875.
| Work | Sonnet coding scenario | Opus coding scenario |
|---|---|---|
| Intent classification | ~$0.048 | ~$0.048 |
| Routine Q&A | ~$0.33 | ~$0.33 |
| Technical design | ~$0.56 | ~$0.56 |
| Coding and review | ~$120 | ~$600 |
| Knowledge ingestion | ~$0.875 | ~$0.875 |
| Total per workday | ~$122 | ~$602 |
At 22 workdays a month, the source estimated about $2,684/month and $32,208/year for Sonnet coding, or $13,244/month and $158,928/year for Opus coding. Using its CNY conversion, those were roughly CNY 19,500 and CNY 96,000 per month respectively. Coding and review dominated the modeled costs, at approximately 98% or more.
The source also contrasted usage depths: about $10/month for light Haiku-based Q&A, $20/month for deeper Sonnet planning without coding, $2,700/month for extensive Sonnet agent coding, and $13,000/month for the Opus scenario. These numbers illustrate sensitivity to context size, call frequency, and model price; they should not be treated as a forecast.
What the Scenario Was Meant to Show
Even if a model call becomes inexpensive, a person must still define what makes an answer good, verify knowledge retained by the system, and accept responsibility for a wrong decision. The calculation was intended to underline the value of human ownership of goals and evaluation, not to establish a current economic break-even point for replacing an engineer.