Rebuilding Professional Identity Through AI

For most of my career, I believed my professional value came from thinking carefully and solving hard problems. Early on, that meant persisting until an unclear problem became well posed and could be solved. Consulting refined that instinct: I needed to solve problems efficiently, recognize stalled progress, seek expertise early, and make uncertainty visible when success was not assured.

AI did not make that work suddenly easy. Learning to use it has meant continually adapting to technology that changes almost as quickly as I can form a reliable mental model of it. That frustration is familiar to software engineers, whose tools and abstractions have always changed beneath them.

Over time, however, a quantitative change became qualitative. The effort required to produce something acceptable declined, while the quality of the result began to exceed what I would previously have targeted. I crossed technical boundaries that had constrained me for years: infrastructure, front-end development, browser testing, deployment, presentations, and complete applications. I moved from solving within my specialty toward taking an idea much further toward a product.

That expansion came at a cost.

From Comprehension to Selective Ownership

My old way of working depended on fitting the relevant parts of a problem into my head. Over a day or two, I would understand the affected system, construct a solution, and retain enough of the reasoning to explain and defend it.

With AI, much more can change in the same period. More code is written, more documents appear, more concepts are introduced, and more parallel paths become possible. The half-life of working knowledge becomes shorter.

I can arrive at a meeting with a functioning result and discover that I cannot answer basic questions about it without walking through the code in the same way as the person asking me. I may have delivered the artifact, but I cannot stand over it as its expert.

This does not necessarily make the work illegitimate. Transparency matters: both practitioners and organizations are learning what it means to build systems this way. But professional responsibility must be redefined. I may not need to understand every generated function or every document written by AI for another AI. I do need to know what matters, how completion was assessed, where the risks are, and which questions must be answered before a meeting rather than during it.

At AI speed, total comprehension may be neither achievable nor valuable. The objective becomes selective ownership.

Milestones as a Unit of Control

The most useful working pattern I have found is to organize development into milestones. A milestone is large enough to produce meaningful progress but bounded enough to force a moment of synthesis:

• What changed?
• What objective was actually achieved?
• What evidence supports that conclusion?
• What remains uncertain?
• What must I understand personally before continuing?
• How should this feedback shape the next objective?

Git diffs, pull requests, tests, previews, and deployment artifacts make change inspectable without requiring every detail to remain in human memory. The milestone review does not require reading every line or correcting every transient document. Its purpose is to recover enough understanding and feedback to define the next coherent step.

AI can also produce implementation documentation for its own future use. If the objectives, constraints, and motivations are clearly stated, attempting to internalize and perfect every derived document may consume attention without improving the result. The human interface moves upward: from managing every detail to defining intent, constraints, evidence, and decision points. This is not abdication, but a narrower and more deliberate form of ownership.

Cognitive Saturation

The exhaustion of AI-assisted development feels different from the exhaustion of programming. Programming could be tiring, but the effort often produced comprehension, mastery, and satisfaction. AI-assisted work can instead saturate attention with conversations, specifications, reviews, unfamiliar concepts, generated documents, and a continuous stream of decisions.

More parallel work intensifies this effect, but it is not the fundamental cause. The rate at which details are created can exceed the rate at which human intuition incorporates them. Explicit memory, emotional orientation, and the intuitive sense of the project all begin to saturate. The collaborator is tireless, so there is no natural stopping point.

The limiting resource in AI-assisted work may not be tokens, compute, or generated output. It may be the human capacity to preserve judgment and direction under a continuously expanding stream of possibilities.

When Activity Is Not Progress

An early infrastructure task made this risk concrete. I was using Terraform/OpenTofu to pursue an outcome I understood in a domain where I could produce more readily than I could assess. The model continually generated activity that appeared to approach the objective. After days of work, I realized that the objective was not achievable with the technology as it existed at the time.

The model did not establish that boundary, and I lacked enough expertise to recognize it quickly. This produced a useful warning signal: AI-assisted work generally moves quickly. When it repeatedly fails to converge, continuing the same conversation with greater determination is unlikely to help. The task may be too broad, a hidden constraint may make it impossible, or I may lack the expertise needed to recognize its real complexity.

This reverses one of my oldest professional instincts. Persistence once meant staying with a problem until it yielded. With AI, persistence sometimes means stopping the production of more activity and reformulating the problem.

Expanded Capability and Lost Mastery

The gains remain substantial. AI has given me a form of full-stack fluency that was previously inaccessible. I can specify infrastructure, construct front ends, deploy applications, establish browser tests and continuous delivery, and turn small ideas into usable products without first spending months becoming fluent in a new technology stack.

Examples include a cervical-screening application using a JavaScript neural network in the browser, a dashboard for exploring which car to buy, and a tracker for a constipated toddler. AI also made programmatic, versioned presentations and front-end testing approachable after years in which their tooling felt prohibitively finicky.

But some satisfaction has simply been lost. Almost two decades of accumulated mastery no longer feel scarce in the same way. The pleasure of holding a difficult problem in my head and personally constructing its solution is harder to find. I am trying to cultivate mastery of this new mode of work and to derive satisfaction from the scale and meaning of what can now be achieved. That is not yet a complete substitute.

The word reborn should therefore not imply an effortless or purely positive transformation. Rebirth includes a loss of identity.

Where Professional Value May Move

Looking back, my greatest value may never have come entirely from personally solving every hard problem. I was often most useful when coordinating expertise: recognizing what I did not know, finding people who knew it, combining their perspectives, and directing that knowledge toward an organizational goal.

Coordinating AI may continue that skill at a different scale. As solving well-scoped problems becomes cheaper, value moves toward deciding:

• Which problem deserves attention?
• What outcome would matter?
• What constraints cannot be violated?
• What evidence would demonstrate success?
• Who is accountable for the consequences?
• When is apparent progress actually misdirection?

This may flatten parts of the traditional hierarchy. Passing poorly communicated intent through several organizational layers becomes more costly when AI can act immediately and at great scale. The people directing it need proximity both to organizational purpose and to the realities of implementation.

The reborn software engineer may be less defined by producing code and more by serving as an effective interface between human intention and machine capability. That role requires greater autonomy, a clearer understanding of what the organization needs, and the judgment to establish direction rather than merely implement instructions.

The Unresolved Question of Depth

Donald Knuth distinguished getting to the bottom of things from staying on top of things. AI appears particularly well suited to absorbing well-scoped, effortful problems: the very work in which deep thinkers once found mastery. New domains of depth may continue to emerge, but it is also possible that humans will increasingly remain on top of systems whose details are explored more effectively by machines.

It is therefore difficult to defend the comforting claim that deep human thought will always remain economically protected. A more credible claim is:

We still need depth to recognize when fluent output is wrong, when a task is impossible, when the objective is poorly chosen, and when the result does not deserve our confidence. But we may need to practice that depth selectively, where it governs direction and consequence, rather than throughout every implementation detail.

This personal encounter contains the larger argument of the talk: expanded capability, disrupted mastery, cognitive saturation, the loss and reconstruction of ownership, and movement from solving assigned problems toward choosing and directing consequential work.