When Programming Became the Smaller Part

I used to copy entire files into a chatbot and ask it, vaguely, to optimize them or find issues. The request was rarely more specific than that. I would paste a module, wait, skim what came back, and decide whether any of it belonged in the project. If the assistant needed more context, I assembled it by hand: another file, a snippet of an error, a paragraph explaining what I thought the code was supposed to do.

That workflow felt strange in a way I could not name at the time. I graduated with a computer science degree in the spring of 2021. "Machine learning" was a much more natural phrase to me than "AI." My degree emphasized software engineering and cybersecurity. I had taken a Coursera machine-learning course in my free time, but even then the subject felt like a technical specialization: train a system to identify something, classify something, recognize a cat in an image. I learned the discipline immediately before that changed, then watched the change happen at the beginning of my career.

In that picture, a model was a trained system with a narrow job. You prepared data, chose a model, evaluated whether it had learned the intended distinction, and treated the result as a component inside a larger program. The interesting work was still around the model: the interfaces, the failure modes, the question of whether the component belonged there at all. Nothing in it suggested that the ordinary act of writing software would itself pass through a generative system.

The first practical form of that was the chat window. I brought it fragments. I asked it to review a function, rewrite a messy block, or tell me what I was missing. The collaboration was real, but the memory was mine. Every useful session depended on my ability to restate the project in language: what the code did yesterday, what I had already tried, which tests were failing, which constraints still mattered. When the restatement was incomplete, the advice was incomplete. I was not pairing with something that could see the work. I was briefing an advisor and hoping the briefing was current.

The next change arrived inside the editor. Instead of assembling context by hand, I could point a model at a file, then at a directory, then at enough of the repository that I no longer had to perform the assembly myself. That was a real improvement. It also revealed something I had not expected. The editor was becoming a convenient surface over a more general capability: inspect a body of software, propose a change, and produce the change in a form I could accept or reject. Once I noticed that, the particular window mattered less than whether the system in front of me could see the work.

The more important transition was not speed. One technically complex personal project made the limit of chat-based collaboration obvious. The assistant and I could design the system together and iterate in conversation. The work itself required constant testing and many small corrections. As the repository changed, it became harder to keep an external assistant synchronized with the actual state: what had changed, what remained broken, what had already been attempted, and what the correct next action was. Eventually the project went stagnant. Not because the idea had failed, but because the cost of continually re-explaining the present had overtaken the work.

When I began using repository-native command-line agents that could inspect the codebase, the tests, the diffs, the current failures, the documentation, and the project state themselves, the project started moving again. The system I was trusting to help determine the next action could see the current work instead of depending on my account of it. AI had moved from being a conversational advisor I had to brief into a collaborator embedded in the work itself.

That is the change I have been trying to understand since then. Programming is becoming a smaller part of software engineering.

I do not mean that the two are separating, or that writing code has become unimportant. Programming is the production of code. Software engineering is broader: understanding the problem, defining desired behavior, designing the system, establishing constraints, tracing interactions and failure modes, validating an implementation, deciding among tradeoffs, maintaining what already exists, and determining whether the result actually satisfies its purpose. Generative tools have made it easier for me to delegate more of the production. That does not make understanding less important. It makes understanding more important. The implementation barrier can fall without the standard for understanding the system falling with it.

The literacy this requires is easy to misstate. I do not think an engineer necessarily needs to inspect every line a model writes. Line-by-line familiarity is one kind of knowledge, and it remains useful. It is not the kind that is becoming more central. What I need is an accurate enough model of the system to know what it is supposed to do, how its major pieces interact, which constraints matter, which assumptions are in play, what could fail, whether an implementation actually represents the intended design, and whether the proposed next action makes sense. That is system-level technical literacy. Traditional coding knowledge still has value. The center of gravity is moving.

I can understand Arabic much better than I can speak it. Comprehension and production are related abilities, but they are not the same ability. Someone can increasingly understand a software system, reason about its behavior, direct changes, notice discrepancies, and evaluate an implementation without personally producing every line that constitutes it. The analogy only goes so far. Speech and code are not identical crafts, and I am not arguing that production skill should atrophy. I am arguing that comprehension can run ahead of production and still be real, as long as it holds up when I have to explain the system or catch it doing the wrong thing.

My working method now follows from that distinction. I begin with an idea. I discuss it until I am satisfied that the problem and the intended result are understood. That conversation may produce a plan or a specification. Another pass, this time inside the repository, may perform the implementation. The resulting work and the report that accompanies it can be reviewed again, sometimes with assistance, to see whether the result matches the original intent and to find the places where it does not. Then I decide what happens next.

This is not a story in which humans think and machines execute. I use these systems to think constantly. I bounce ideas off them, ask them to challenge an assumption, let them structure a concept I only half have, and let them propose solutions I would not have reached as quickly alone. Reasoning can be collaborative. Judgment remains my responsibility. The failure mode I care about is not that a model participates in the thinking. It is that I allow it to decide without my understanding and evaluating the decision.

That is also why I take prompting seriously, though I do not think of it as a bag of clever phrases. Good prompt engineering is specification engineering. A useful prompt contains the things a competent implementer would need: a coherent problem statement, the relevant context, the boundaries, the constraints, the intended behavior, the important edge cases when they matter, and the criteria by which the result should be accepted. A useful test follows from that. If a highly competent human programmer could not take the instructions and reliably run with them, there is no reason to expect a model to do so either.

The specification itself can be drafted by a model. Authorship of the first version is not the important part. What matters is whether the specification makes sense, reflects the system I actually want, and covers the required scope. I am responsible for that evaluation. Models can fail on work that was specified well, and they do. But poorly bounded work is an important and often overlooked source of failure in its own right: unclear goals, missing context, vague constraints, or acceptance criteria that would not have guided a person either. It is worth separating from the model's own mistakes, because it is the part I can fix before the work begins.

Two personal projects made different sides of this visible. Aether showed me something about energy. The work could be about aesthetics, and it became more enjoyable, when so much of my attention was no longer consumed by producing every implementation detail by hand. A project can die of implementation fatigue before the underlying idea has been fully explored. Reducing that burden did not merely make development faster. It preserved the capacity to care about the experience, to experiment, to refine the presentation, and to finish the thing I was building.

Erebus showed me the technical side. Software with that many interacting parts remained manageable when implementation was paired with context that persisted between sessions, iterative validation, and assistance that could see the repository. The work did not become instant or effortless. It stayed highly iterative and required extensive involvement and testing on my part. What changed was that complexity became something I could keep working through rather than something that closed over the project.

People sometimes ask a simpler question: if a model wrote the code, did I really build it? Typing each line captures only one part of building software. If I framed the problem, established or validated the architecture and constraints, evaluated the implementation, tested whether it behaved correctly, identified discrepancies, chose among tradeoffs, and remained responsible for the resulting system, then authorship cannot be reduced to keystrokes. The opposite case is just as important. If I cannot explain the system, cannot evaluate it in any serious way, and simply accept whatever arrives, the claim of ownership becomes much weaker. More of the implementation can be delegated. Responsibility cannot be sent along with it.

None of this is foreign to the profession. Senior engineers have long spent much of their time on framing, design, review, and judgment. What has changed is how much of my own practice that part now occupies, and how early in my career it arrived. The transition is still underway, and I do not think I am looking at a finished form of the job.

Programming can become a smaller part of my work without making software engineering smaller. Models now take part in nearly every stage of it, including the thinking. What has not become cheaper is knowing what I am building. Someone still has to decide what the system should do and whether the result is acceptable, and that decision stays with me.

Provenance

Abstract

The author graduated in spring 2021, just before generative AI began moving from a specialized technology into ordinary software-development workflows. This essay traces one practitioner's progression from manually pasting code into chatbots, to editor-level repository context, to agents that work directly inside a codebase. The result has not been the disappearance of software engineering but a change in how it is practiced: programming occupies less of the author's attention, while problem framing, system-level technical comprehension, specification, review, and judgment occupy more. The essay argues that AI can participate in reasoning as well as implementation, and that good prompt engineering increasingly resembles good specification engineering. Lowering the barrier to producing code does not lower the standard for understanding the system or for deciding whether what was built is acceptable.

Sources (10)

Inspection scope: presence here does not imply full-text access to every cited work. The external web sources were inspected on September 25, 2026, during the author's research for this essay, and the findings below are as recorded in that research. The timeline sources establish product dates, not adoption rates. First-person experience, including the Aether and Erebus examples, is not cited to any source and is labeled as author observation in the fact-check table.

Fact-check table (13)

VERIFIED means the specific claim is supported by the identified inspected material. QUALIFIED marks an interpretation or a result whose scope matters. ANALOGY marks a personal comparison used to draw a distinction, not a finding about software. AUTHOR OBSERVATION and ORIGINAL SYNTHESIS are labeled as such.

Editorial note: original synthesis

Inherited. The breadth of software engineering beyond construction (SWEBOK). Requirements engineering as its own discipline (ISO/IEC/IEEE 29148). The importance of explicit instructions, context, constraints, and verification when directing models, including Anthropic's rule of thumb about instructions that would confuse a colleague (OpenAI and Anthropic prompting guidance). The capabilities of repository-native coding agents (OpenAI on Codex; Anthropic on Claude Code). The existence of agent failure sources other than ambiguous input (OpenAI agent-safety guidance). Product dates for Copilot and ChatGPT.

Analogical only. The Arabic comprehension/production analogy, used to separate understanding a system from producing it. The body states where it stops holding.

This essay's contribution. The central synthesis that programming is becoming a smaller part of software engineering, which is not attributed to IEEE or to any AI vendor. The distinction between line-by-line code literacy and system-level technical literacy. "Good prompt engineering is specification engineering": requirements-engineering practice and provider prompting guidance support the importance of clear requirements, context, and constraints, but neither states the equivalence. The test that instructions a highly competent human programmer could not reliably run with should not be expected to work for a model, which is the author's formulation and is closely consistent with Anthropic's published guidance. The workflow model in which AI participates in framing, specification, implementation, and review while the author keeps final judgment. Aether and Erebus as first-person examples of creative sustainability and technical manageability respectively.

Normative position. The ownership and accountability discussion. The sources establish what agents can do and how they can fail, not what responsibility should remain human; that conclusion is the essay's.

Corrected after review. An earlier draft implied that poorly bounded work was the common explanation when implementations go badly. The published text states that models can fail on well-specified work, and treats poorly bounded work as an important and often overlooked additional source of failure.

Limits. One practitioner's account. No measurement of how much of the author's time implementation occupies now compared with before, and no controlled comparison of the chat-based and repository-native workflows. The Aether and Erebus observations are unmeasured. The timeline sources date product launches; they do not measure when generative tools became normal in professional practice.