What Does It Really Mean to Program With AI? Inside the Shift Reshaping Software Development

Ask ten developers what it means to "program with AI" and you will get ten different answers. For some, it is a smarter autocomplete that finishes a line of code. For others, it is a full teammate that reads a ticket, plans a change, writes the tests, and opens a pull request. That gap in understanding is not a small semantic quibble. It shapes how teams hire, how they review work, how they measure productivity, and ultimately how reliable the software running our world becomes.

That is the tension at the heart of a recent and genuinely useful conversation with Joy Ebertz, whose discussion digs into what is actually happening when humans and AI write software together. The conversation avoids the usual hype and doom, and instead asks the harder, more practical question: when the machine can produce code, what is the human still for?

The Question Behind the Question

On the surface, "what does it mean to program with AI" sounds like a question about tools. It is really a question about identity. For decades, a software engineer's value was closely tied to the ability to translate an idea into working code. Typing, structuring, debugging, and remembering syntax were core skills. If a model can do much of that translation, the job does not disappear, but its center of gravity moves.

This is the shift that separates genuine adoption from performative adoption. Teams that treat AI as a faster keyboard get faster typing and roughly the same outcomes. Teams that treat it as a junior collaborator with unlimited stamina but questionable judgment get something structurally different: a change in where human attention is spent, and therefore a change in what the organization needs to be good at.

The conversation makes a persuasive case that the real skill being tested is not prompt writing. It is evaluation, the ability to look at generated code and know, quickly and confidently, whether it is correct, safe, maintainable, and appropriate for this particular codebase.

From Autocomplete to Agentic Teammate

It helps to think of AI in software development as a spectrum rather than a single thing. At one end sits inline suggestion: the model predicts what you were about to type, and you accept or reject it. At the other end sit agentic systems that take a described goal, explore a repository, propose a plan, make edits across multiple files, run tests, and report back.

Each step along that spectrum changes the nature of the human's job:

• Inline suggestions keep the human firmly in the driver's seat. The risk is low, and so is the upside, mostly speed.
• Conversational assistance shifts work toward explanation and design discussion. The developer asks why, and the model answers. Value comes from learning and unblocking.
• Task-level delegation hands over a whole chunk of work. Now the human is a reviewer and a spec-writer, and quality depends heavily on how well the goal was described.
• Agentic autonomy distributes work across many steps the human never directly observed. This is where review discipline, testing infrastructure, and trust boundaries become the entire game.

The further along that spectrum a team travels, the more the bottleneck moves away from writing and toward verifying. That is a profound change, because most engineering organizations have spent decades optimizing for the opposite.

The New Bottleneck Is Judgment, Not Typing

When code generation becomes cheap, code review becomes the scarce resource. This is the single most important practical insight in the discussion, and it deserves to be said plainly: producing more code is not the same as producing more value. A codebase that grows faster than the team's ability to understand it is a liability, not an asset.

Consider what happens when a developer can generate two hundred lines in seconds. Someone still has to answer uncomfortable questions. Does this handle the edge case where the input is empty? Does it leak a database connection under load? Does it duplicate logic that already exists three directories away? Does it quietly broaden a permission that should have stayed narrow? Does it pass the tests because the tests were also written by the same system, sharing the same blind spot?

That last point is the subtle one. AI tools are excellent at making tests pass. They are not automatically good at making tests meaningful. If the generator writes both the implementation and the checks, a green test suite can become a comfortable illusion rather than a safety net. Mature teams are responding by insisting that human-written tests, or at least human-defined acceptance criteria, sit upstream of generated code.

What Happens to Skill Development?

There is a real and unresolved concern about the apprenticeship pipeline. Junior engineers have historically learned by struggling: by writing something broken, debugging it for four hours, and emerging with intuition they could not have been told. If that struggle is removed from the early years, where does the intuition come from?

The conversation surfaces this honestly rather than dismissing it. There is no clean answer, but there are sensible postures. One is that reading and reviewing large volumes of AI-generated code, critically, with an experienced mentor explaining what is wrong, may become a legitimate substitute for some of that struggle. Another is that teams should deliberately preserve hard problems for junior engineers, even when a model could solve them in seconds, because the point of the exercise is the human's growth, not the artifact.

What clearly does not work is pretending the concern is overblown. A generation of engineers who can prompt fluently but cannot reason about a stack trace is a systemic risk to the entire industry. The organizations that take this seriously will treat skill formation as a first-class engineering concern, not an HR afterthought.

What This Means for Teams and Codebases

Zoom out, and the implications for how software organizations operate start to stack up.

Codebases become a shared human-AI artifact

When a meaningful share of code is machine-generated, the repository stops being a pure record of human intent. It becomes a blend of human design and machine output, and that changes what documentation and naming are for. Clear structure matters more, not less, because it is the context that future AI assistance will reason over. A messy codebase makes both humans and models worse.

Context is the real constraint

The quality of AI assistance rises and falls with the quality of the context it is given. Architecture notes, conventions, and well-named modules are no longer just good hygiene, they are inputs that directly determine output quality. Teams that invest in clarity get better results from every tool they adopt.

Review capacity becomes a planning metric

If one engineer can generate work faster than three engineers can review it, the constraint has moved. Smart teams will start tracking review latency and review depth the way they once tracked deployment frequency. Throwing more generation at a review bottleneck just creates a backlog of unverified changes.

Business Implications Beyond the Engineering Department

These dynamics do not stay inside the tech org. They ripple outward in ways business leaders should be planning for.

• Speed expectations reset. When features can be prototyped in hours, customers and executives start expecting that pace everywhere, including in the parts of the business that cannot move that fast. Managing that mismatch becomes a leadership skill.
• Cost models shift. Budget moves from headcount toward tooling, inference, and, crucially, quality assurance. A cheap prototype that needs expensive hardening is not actually cheap.
• Risk migrates. Generated code can carry subtle security and compliance problems at a volume human review was never designed to handle. Regulated industries will need new controls, not just new tools.
• Differentiation moves upstream. If everyone can generate similar code, advantage comes from knowing what to build, how to integrate it, and how to operate it reliably.
• Trust becomes a product feature. Companies that can demonstrate their AI-assisted development is verifiable and well-governed will win deals their competitors cannot.

Actionable Insights for Engineering Leaders

If the conversation has one practical takeaway, it is that adoption is a process design problem, not a tooling purchase. Here is what that looks like in practice:

• Define trust boundaries per task type. Not all code is equal. A test helper and an authentication routine should not travel along the same path. Decide explicitly what can be delegated and what must be human-authored.
• Put humans upstream of the tests. Write or approve acceptance criteria before generation begins, so the checks measure intent rather than echoing whatever the model decided to build.
• Measure what actually matters. Track rework rates, review depth, defect escape rates, and time-to-understand, not just lines produced or suggestions accepted.
• Protect learning time. Deliberately reserve certain problems for humans to solve unaided, especially for early-career engineers.
• Invest in context. Better architecture docs, cleaner module boundaries, and consistent conventions pay off twice, once for people, once for the models that read them.
• Normalize saying "I don't trust this yet." A culture where rejecting generated output is safe and expected will outperform one that treats acceptance as the metric.

The Road Ahead

The most valuable thing about this conversation is its refusal to pick a side. It does not claim AI will replace engineers, and it does not pretend nothing has changed. Instead it points at the messy, interesting middle where most real work happens: a person with judgment, working alongside a system with speed, producing something neither could produce alone.

What "programming with AI" really means, then, is a redefinition. It means the engineer's core competency is shifting from producing code to directing, evaluating, and taking responsibility for code, whether a machine or a human wrote the first draft. That is a harder job in some ways and a more leveraged one in others. It demands sharper thinking, better communication, and stronger judgment than writing the code yourself ever did.

The teams that thrive will not be the ones with the most impressive models. They will be the ones that figured out where to draw the line between machine speed and human accountability, and then had the discipline to hold it.