Why Do We Still Need Software Engineering in the AI Era? — Lecture 1 of Nanjing University's Generative Software Engineering

Course page: Lecture 1 of the 2026 Generative Software Engineering course at Nanjing University

1. Why this course is appearing now

This lecture starts from a practical problem: computers are going through a new round of capability democratization, while university education, the way people learn, and the way people work have not fully adapted to this change.

Many transformations in computing history can be understood as the same thing happening over and over: capabilities that were once expensive, scarce, and usable by only a few gradually become everyday commodities that ordinary people can use directly. Personal computers brought computing power into personal life, the internet connected people, and mobile internet brought payments, communication, and services to everyone's phones. Generative AI further compresses text generation, image generation, code writing, information processing, and software operation into natural-language interaction.

The class uses the evolution of ICQ, OICQ, and QQ to illustrate the early-internet sense of connection: a person could reach someone at the other end of the world at random, even if the two sides differed completely in language and experience. The spread of mobile payments shows another kind of change: QR codes entered everyday scenes such as vegetable markets in a very short time, changing how people complete transactions. Generative AI is spreading even faster, and has already begun redefining learning, work, and creation.

The dilemma of "letting AI do my degree for me"

When teachers use AI to write exam questions and students use AI to do homework, a course can still complete its assessment, but the students may not actually get trained. The whole teaching loop looks normal; what is truly missing is the process in which the students themselves gain ability from the problems.

This shift brings several specific anxieties:

• Grades can be very good, yet at graduation you find you never truly mastered the ability to solve problems;
• Many skills you worked hard to learn, AI can already do as well;
• Huge numbers of résumés stack up internships, awards, papers, and competitions, making people harder and harder to tell apart;
• If a résumé has no GitHub, personal homepage, preprints, runnable projects, or other verifiable work, the experiences on paper can hardly demonstrate real ability.

The class gave an example of a résumé that "looks perfect": it contains papers and experience, but lacks code repositories, a personal homepage, and materials that allow further verification. The problem is not whether the layout is beautiful, but that the résumé leaves behind too little evidence of real work. Generative AI makes textual packaging easier, and makes "looking excellent" less scarce.

Therefore, the goal of the course is not simply to teach everyone to write more code, but to let everyone regain two things in the AI era: first, the ability to use AI to produce real work; second, the ability to understand software engineering, judge the quality of results, and leave behind verifiable outcomes.

2. Course positioning: generative software engineering

The course is named "Generative Software Engineering". It is still a software engineering course; generative AI and agents have been added to the software production process.

Software engineering is not the same as writing the code out. The more fundamental questions are: how to keep software from failing, and how to turn a requirement into software that can be delivered, verified, and kept in maintenance.

The course is case-led, with loose discussion and practice first. Cases in class include configuring an operating system, handling email, reading papers, analyzing videos, operating a browser, building Excel tools, and designing maintainable software architecture. Traditional "old-school programming" is no longer the center of the course; the focus shifts to how to describe problems, direct agents, verify outputs, and settle one-off successes into long-term reusable systems.

The course also discussed several practical constraints:

• Token costs need to be brought into the workflow; demos can prefer models that are cheaper, faster, and sufficiently capable;
• Models should not be treated as absolutely reliable black boxes; important results still need checking;
• The course design leans toward evaluating projects on a "pass / fail" basis, but the specific judging criteria are still taking shape;
• One executable project direction is to implement a personal email management system that can send and receive mail, handle replies, and keep running long-term on a small computer;
• A project's value is shown not only in its grade, but in whether it ultimately forms a work that is accessible, explainable, and reproducible.

Content as code

The courseware shown in class is itself a case of generative software engineering. The Markdown lecture notes are treated as the source of truth; agents expand the notes into slides and image assets, which the browser then renders into the final courseware. Many images and page elements in the courseware are generated by AI, and the content is further adjusted through rounds of prompting, different agents, and blind review.

This approach splits one lecture into several objects that can be processed further:

1. The Markdown lecture notes written in advance;
2. The in-class explanation and spontaneous discussion;
3. The recorded complete course;
4. Knowledge clips produced by slicing, review, and recombination;
5. A digital course that can be maintained, customized, and shared afterward.

The meaning of "content as code", or "everything is code", is not to mechanically turn all content into programs, but to give content a clear origin, structure, generation process, and maintainable form. A course can then be revised, combined, and reused like software, and even maintained further by different people.

3. From large language models to agents

The class does not start from the engineering details of training models, but first builds an intuition that a user can grasp.

A large language model can be understood as a probability distribution learned from a large amount of data. Given a piece of context, it keeps predicting the tokens that follow; the output looks like a continuous article, code, or answer, but is essentially the composition of many predictions. A model can handle very long text, and can handle different forms of input such as images, but it is not by nature equal to a reliable software engineer.

Agents appear once the model has longer context, stronger reasoning, and the ability to call tools. An agent no longer just generates an answer; it can:

1. Read the task and the current environment;
2. Invoke tools such as bash, the browser, or computer control;
3. Observe the results the tools return;
4. Judge whether the current path is reasonable;
5. Modify the plan and keep executing;
6. End the task after verification passes.

This is the ReAct-style loop shown repeatedly in class. The model's output can trigger a program, the program's results are fed back into the model's context, and the model continues to act accordingly. A complex task is therefore no longer "one generation", but is composed of multiple observation, action, and correction steps.

The first step in using agents is not learning how to train a model, but giving it a clear task directly and letting it start working. Configuration files such as AGENTS.md in a project can provide standing background, roles, and constraints; a person can gradually learn the agent's capability boundaries through follow-up questions, inspection, and feedback. The judgment given in class: imagination, the ability to describe requirements, and the ability to verify, determine to what extent an agent can be used.

4. What agents can do: from personal environments to knowledge workflows

4.1 Configuring the local system in natural language

The class showed a local working environment completed with an agent's assistance. A bootable Linux system was placed on a USB device; the window manager, terminal, NeoVim, and command-line tools were customized, with the interface and way of operating optimized around the class demonstration.

In the past, configuring such an environment required consulting large amounts of documentation, understanding configuration files, repeated trial and error, and handling compatibility issues item by item. Now you can first describe the goal in natural language, and let the agent check the system state, install components, modify configuration, and verify the results. The agent can also replace ordinary commands with tools better suited to daily use, and make unified adjustments to terminal output, window layout, and keyboard shortcuts.

The change that is really happening here is not "humans no longer need any knowledge", but a change in how knowledge is used. A person needs to know what kind of system they want, know which results are worth accepting, and be able to spot errors and ask the agent to re-check; the specific configuration details can be handed to the agent.

4.2 Handing daily tasks to a personal agent

Another case is a personal email workflow. The system stores emails and replies processed in the past, so after a new email arrives, the agent can execute a chain of consecutive actions:

• Label the email's status automatically;
• Generate reply drafts according to the established tone;
• Recognize invoices and other materials in attachments;
• Save important attachments to the designated archive location;
• Receive tasks from Reminders;
• Call the printer to finish printing;
• Push a notification to the watch when done.

The key to this kind of flow is not how complex any single action is, but that multiple tools are combined into a continuously running workflow. Email, database, file archiving, Reminders, the printer, and notification devices form a personal automation system.

The class also emphasized the boundary: daily tasks can be handed to an agent, provided the task is trustworthy enough and the risk acceptable, and important results should still go through confirmation. An agent being able to operate the computer does not mean all operations should be unconditionally authorized.

4.3 Using multiple agents to speed up reading books, papers, and videos

Agents are not only for writing code; they can also change how knowledge is acquired.

When reading a paper, different agents can each take on different tasks: looking back at humanity's existing knowledge and historical cases, searching for related work, analyzing the problem with first principles, or raising challenges from different positions. After multiple agents form different views, they discuss; the lead agent hands the disagreements back to them for handling, until relatively stable conclusions are reached.

The core of this reading style is not letting AI replace the original text, but first stripping away the already-familiar parts and extracting the genuinely new content, then continuing the conversation with the original text, layered summaries, and questions. For a very long paper, once the known background and formalistic groundwork are compressed, the remaining key contributions, assumptions, and limitations become easier to locate.

Watching videos can adopt a similar process:

1. Capture the complete content and organize it into workable material;
2. Generate the transcript and the image-text timeline;
3. Keep screenshots at necessary points as ground truth;
4. Let the agent identify already-familiar content;
5. Keep only the new ideas, cases, and methods;
6. Return to the original video with the summary to verify.

The value of doing this is not just "watching faster", but turning video from a consume-once medium into knowledge material that can be searched, reviewed, and reorganized.

4.4 Browser and computer-use capabilities

The browser is an extremely complex software engineering product. Chrome DevTools provides development interfaces for page structure, network requests, script execution, and state observation. In the past, only developers used these capabilities systematically; agents can hand part of these capabilities to ordinary users.

Typical operations mentioned in class include opening developer tools, observing the page and network requests, reading request headers and cookies, copying browser requests into cURL commands, and continuing to process data while preserving the current state. The class also showed the idea of running an Android interface in the browser: after an app's interface elements, text, and coordinates are extracted, display and interaction can be completed through the browser.

When an agent operates a web page, it may first try one approach, find that directly injecting events does not work, then switch to real clicks or another viable path. Failure does not necessarily mean the task is over; the agent can observe the failure result, choose tools again, and keep trying.

More importantly, a successful operation path can be saved as a script or a memory. After the agent completes an exploratory operation once, subsequent repeated tasks can become deterministic automated flows. Browser operations, page state, scripts, and memories can therefore be combined into larger personal workflows.

4.5 The stronger the capability, the more the security boundary matters

The restricted-environment case in class illustrates the dual use of agent capability: a machine can allow files to enter while forbidding files from leaving directly; if legitimate input, display, and interaction channels are combined, a data exfiltration path may still form.

The point of the QR-code animation and Excel formula demos is not to provide an attack tutorial, but to show that a security boundary cannot rely only on "forbidding program installation" or "forbidding file copying". When an agent can operate the browser, desktop, spreadsheets, the printer, and other devices, previously separate channels may be recombined. Software engineering design must consider function, permission, observability, and misuse risk at the same time.

4.6 From bits to atoms

At the end, the class widened the view from on-screen digital content to the real world: natural language can drive a Python program, and the Python program can in turn generate 3D-printed objects. Videos, papers, slides, code, and physical objects can all be brought onto the same "content—code—execution" chain.

"From bits to atoms" is not a slogan about the future. As long as a digital object can be described by code, an agent can take part in the conversion from intent to physical entity.

5. What software engineering really needs to solve is the "gap"

AI can complete many local tasks, but a usable product is not the simple addition of local tasks.

For example, a food-delivery system contains frontend, backend, interaction, data, deployment, and operations at the same time. AI can separately help design pages, write interfaces, generate the database schema, or propose operations plans, but as long as any one piece does not match the other pieces, the whole product may be unusable. Product development is therefore systems engineering, and organizing these local capabilities matters more than generating a piece of code.

5.1 Three spaces

The class uses three spaces to describe the conversion process of software from idea to product:

One Intention can correspond to many Specifications; one Specification can also be realized by many Implementations. When the client, the product manager, the analyst, and the programmer form different understandings of the same requirement, the gap is amplified.

The core work of software engineering is continuously filling the gaps between Intention, Specification, and Implementation. Software usually fails not because the syntax of some line of code is wrong, but because what was finally implemented was not the wanted thing from the very beginning, or because although the goal was achieved, it did not satisfy the requirements for correctness, reliability, and maintainability in the specification.

5.2 The QR / Excel case: being able to finish is not the same as doing it right

The class used a QR / Excel tool to illustrate the agent's limits. The task looks clear: input an arbitrary string, encode it, generate a QR-code animation, and use formulas compatible with old versions of Excel.

Without an explicit architecture, the agent tends to inflate the requirement, trying to pursue a universal solution "that holds for all inputs". The results can include hard-coding Base64 content into formulas, generating unmaintainable code, or a bare completion only after a long time of repeated patching. Even if a runnable result is obtained in the end, it does not mean it satisfies the real Specification, still less that it is fit to keep evolving.

The more reliable method is to first limit the problem's scope, then split the system into layers that can be verified separately:

1. First define the minimal input and output that cannot fail;
2. Design an intermediate language or DSL;
3. Make the intermediate language both executable as Python and translatable into Excel formulas;
4. Verify separately whether the Base64 encoding is correct;
5. Verify separately whether the generation of every pixel of the QR code is correct;
6. Verify separately the translation from the intermediate language to Python and to Excel;
7. Form a closed loop with tests, run results, and human review.

This design turns "have the AI directly write the complete program" into "have the AI take part in building the infrastructure, then verify each transformation separately". The code may not be shorter, but the boundaries are clear, errors are easy to localize, and it is easier to maintain.

5.3 A failing project cannot rely on continuing to pile on resources

The classic judgment in The Mythical Man-Month: for a project already mired in failure, adding more people may only make the project fail more. The class extended this judgment to agents: when generated output has already produced slop, continuing to invest more tokens does not necessarily change direction, and may even let the wrong structure become further solidified.

Therefore, when encountering failure, the first thing is to judge which layer the problem belongs to:

• Whether the requirement was understood correctly;
• Whether the Specification is explicit enough;
• Whether the architecture allows later change;
• Whether the implementation satisfies the specification;
• Whether the tests can discover the errors;
• Whether the current patching is solving the problem, or masking a structural problem.

The goal of software engineering is not to make one demonstration look successful, but to let the system keep working through changing requirements, changing people, changing models, and changing environments. Reliability, the ability to evolve, maintainability, and long-term cost all belong to "whether the software is done right".

6. Human capabilities are still needed in the AI era

Traditional computer education usually starts from the C language, data structures, and concrete implementation, then gradually learns software engineering. Students first get familiar with the tools in the implementation space, then learn how to land requirements as programs. Exam questions, meanwhile, often require getting a definite answer within a very short time.

This training style still has value for foundational learning, but on short-range tasks AI already has more data, stronger memory, and clearer feedback signals. As long as a problem can be defined quickly, tested quickly, and scored quickly, the agent often finishes faster than a person.

The way of learning therefore needs to change: you can first let the agent build something, then go back and review why it works, where it is unreliable, and where the boundaries are. Doing this can be more efficient than hand-writing every detail from scratch, but it has an obvious risk: the understanding you get may only be "it runs" understanding, which is not equal to correct, complete, and transferable understanding.

The scarce value of humans

In the framework given in class, human value is no longer mainly about completing a local implementation faster than AI, but about taking on the following work:

• Discovering problems worth solving, instead of only waiting for a clearly defined task;
• Organizing vague intent into a Specification that can be discussed and verified;
• Choosing suitable architectures and intermediate representations to reduce the error between different spaces;
• Judging what results count as success, and what results only pass temporarily;
• Testing, reviewing, and fact-checking the model's output;
• Settling a one-off successful exploration into scripts, Skills, documents, or reusable systems;
• Using cheap experiments to validate direction, and stopping bad directions in time with evidence;
• Taking responsibility for the system's long-term results, risks, and responsibilities.

Curiosity, self-drive, engineering taste, and an understanding of the real world determine whether a person can bring AI to bigger problems. Knowing how to use an agent is only the starting point; knowing what it can do, what it cannot do, and how to organize it into reliable processes is the core capability of generative software engineering.

7. The conclusions left by the first lecture

This lecture does not portray AI as a finished, ultimate tool. Agents are getting stronger and stronger at single tasks, local code, and browser operations, but they still misunderstand requirements, rush to start, chase the short-term reward of "passing the tests", and generate implementations that are hard to maintain. Models may soon further learn engineering design and taste, and the methods in the course may also quickly become outdated as model capabilities change.

But this does not mean software engineering loses its meaning. Quite the opposite: as local execution becomes cheaper and cheaper, direction, structure, verification, and long-term results matter more.

"Old-school programming" is losing its dominant position, but software engineering has not disappeared. Whether a person can be recruited and trusted can no longer be judged only by whether they can write a piece of code that an AI could also write, but by whether they can answer a more difficult question:

Why hire a person, instead of buying a $200 Claude Max?

The answer given in class can be summed up as four things:

1. Find problems that are genuinely worth solving;
2. Break the problem into experiments with controllable cost;
3. Use evidence to stop wrong directions in time;
4. Take responsibility for the system's long-term results.

What agents amplify is execution. What generative software engineering needs to solve is how to set direction, fill the gaps between intent and implementation, build verification loops, and turn one-off generated results into systems that can keep evolving.