AI Coding vs. Programming: What AI Can't Replace

Every few weeks an executive asks me some version of the same question. They watched a demo where someone typed a sentence and a working app appeared. They want to know how soon they can stop paying programmers.

I understand the excitement. I use AI every day. In my own projects it writes most of the syntax now, and it writes it faster than I can read it.

The hard part of building software is deciding. A corporate website or an enterprise application is the sum of hundreds or thousands of decisions, and those decisions determine whether it works for the business. AI is good at the typing and weak at the deciding. Most people miss that gap, and companies pay for it later.

Coding and programming are two different jobs

The two words name two different kinds of work, and most people use them interchangeably.

Coding is writing syntax. It turns an instruction that someone has already decided on into text a computer can run, such as a loop, a database query, a CSS rule that sets the spacing on a card, or a function that formats a date for US readers.

Programming is deciding what the instructions should be. A programmer decides which pages exist, what happens when a form fails to send, who can edit the pipeline chart, and who has to approve the edit. A programmer also decides where the data lives, how long it stays there, and what breaks if the vendor shuts down next year.

Programming produces the product. Coding records it.

A programmer does both jobs, which is why the words blur together. On most projects the typing is the small part of the day. The rest is reading, asking questions, testing, finding out that an assumption was wrong, and changing the plan.

Why people think syntax is the hard part

There are good reasons for the confusion.

Syntax is the part you can see

Open a code file and it looks like a foreign language. So people assume the syntax is the barrier. The decisions behind the code are invisible. They live in meetings and in the head of the person who made them. Nobody looks at a finished website and sees the forty choices that made the contact form reliable.

The culture taught us to say “coder”

“Learn to code” campaigns, movies with hackers typing green text, and job titles built around languages all point at syntax. The word “coder” describes the most visible activity, so people assume it is the main one.

Bad decisions show up late

A wrong choice in month one surfaces in year two as a slow site or a rebuild. By then nobody traces the cost back to the decision. Typos show up right away, so they get the blame for difficulty they don’t deserve.

Demos show the first day

An AI demo builds a to-do app from a prompt in a minute. Nobody demos year four of that app, when the third content editor has quit, the legal team wants an audit log, and the hosting bill has tripled.

What AI does well

I want to be fair here, because AI has changed how I work.

It writes syntax in almost any language. It produces boilerplate, the repetitive setup code every project needs, in seconds. It translates code from one framework to another. It explains unfamiliar code. It writes tests when you tell it what to test. It catches many small bugs. It drafts a first version of a component that I can then correct.

Work that used to fill an afternoon can take minutes. A programmer who refuses to use these tools will be slower and more expensive than one who uses them well.

All that is coding. The instruction already exists, and AI turns it into syntax.

Where AI falls short

The trouble starts when the instruction does not exist yet, which is most of the time on a real project.

It answers the question you asked

Ask for a contact form and you get a contact form. AI rarely stops to ask whether the form should go to a shared inbox, whether submissions need to land in the CRM, whether the form should flag a lead from a competitor, or what the visitor sees if the email service is down. A senior programmer asks those questions because they have watched forms fail.

It has no context about your company

It does not know that the company abandoned the last website because editors found the CMS confusing. It does not know the CFO hates pop-ups, that the IR team has a review process for anything investors see, or that the person who will update the site is a part-time contractor who logs in twice a month. Those facts decide the right form, the right CMS, and the right permissions.

It goes along with you

AI companies train their models to be helpful, and in practice that often means going along with the framing of the request. A good senior programmer often says “We shouldn’t build that.” AI says it less often than it should.

Its output looks finished either way

A bad decision in messy code is easy to spot. A bad decision in clean, confident code is hard to spot, and AI produces clean, confident code whether the underlying decision was right or wrong. The demo works. The problem shows up months after launch.

It decides by default

When a prompt leaves something unstated, AI fills the gap with something common. When nobody makes a decision, the tool makes it, and nobody checks it.

Nobody is accountable

When the site goes down on the morning of an investor day, a person or a team has to fix it. They can only own decisions they understood when they made them.

Building a house

Picture building a house.

Power tools changed construction. A framing crew with nail guns puts up walls faster than a crew with hammers. The architect’s job stayed the same.

The main challenge in building a house is architecture and structural engineering. It is knowing the building codes, knowing what materials and options exist, sequencing the work, staying inside the budget, and seeing the problems the owners can’t see. A crew with excellent tools and no plans builds something. Whether it is the house the family needed is a matter of luck.

AI is a power tool for software, and a strong one. It is a nail gun that can frame a wall from a description. Somebody still has to decide where the walls go.

The 100 decisions below make the point. Each one pairs a decision in building a house with the same kind of decision in building a corporate website or an enterprise application. Every one of them happens away from the nail gun.

Before the first shovel

Who lives there. A house for a couple in their seventies needs a bedroom without stairs. A house for five kids needs a mudroom. A website for investors needs the pipeline and the latest data within two clicks, and a website for job candidates needs the careers page and the culture. Building before you know who it is for is a mistake every later decision inherits.
What the house is for. A home office, a rental, and a place to retire are three different plans. A corporate website might exist to support a raise, recruit scientists, back a partnership, or prepare for an IPO, and each goal ranks the pages differently.
The real budget. An architect who knows the real budget designs a house that can be finished. A programmer who knows it chooses a platform the company can afford to run for five years after launch.
The lot. Slope, soil, sun, and the neighbor’s oak tree all shape the house. Software has to fit what is already there, such as the email platform marketing uses, the HR system that posts jobs, the investor relations feed from an outside vendor, and the single sign-on IT requires.
The survey. Before building, someone confirms where the property line is. Before a redesign, someone lists every URL the old site has, because each one carries search traffic and inbound links that vanish if nobody maps them.
Who decides. Couples who disagree about the kitchen stall a house for months. A website with five executives and no single owner stalls the same way. Someone settles who has final say before design starts.
What failed before. If the last house on the lot sank, you want to know why before you pour concrete. If the company abandoned the last website after a year, find out why. Maybe the editors found the CMS confusing, the person who championed the site left, or the vendor disappeared. Each of those reasons calls for a different fix.
How long they will stay. A starter home and a forever home need different builds. A site for a private company raising next spring and a site for a public company planning ten years ahead need different foundations.
What will change. A family expecting kids plans a room that can become a nursery. A biotech expecting new programs plans a pipeline that can grow from two rows to twelve without a redesign.
What not to build. A good architect talks clients out of the indoor pool. A good programmer talks clients out of the member portal nobody will log in to, the chatbot nobody asked for, and the custom feature that a standard tool already handles.

Foundation and framing

Slab, crawl space, or basement. The foundation is expensive to change later. Choosing between WordPress, a headless CMS, a static build, and a hosted site builder is the same kind of choice. Changing it later means a rebuild.
Load-bearing walls. Some walls hold the house up. In an application that job usually falls to the data model. If the data model says a drug program has one indication, adding a second one later touches every page that shows it.
Wood, steel, or concrete. Each material suits a different building. Each framework suits a different team. A choice that is right for a startup with three engineers can be wrong for a company whose IT department supports one language.
Span. How far a beam can reach without support decides how open the floor plan can be. How much traffic a system can handle without help decides whether the site stays up when a press release goes out on the morning of a data readout.
Room for a second story. Engineers size the foundation for floors that don’t exist yet when the owners say they might add them. Programmers design for features that don’t exist yet when the roadmap says they are coming.
Too much foundation. Over-building is a real cost. A garden shed does not need a basement. A ten-page company site does not need microservices, a container cluster, and a custom design system with 200 components.
Where the rooms connect. Hallways decide how people move through a house. APIs decide how systems talk to each other. A badly placed hallway makes every trip longer for the life of the house.
Standard sizes. Doors, windows, and lumber come in standard sizes so any carpenter can work with them. Common conventions and open formats keep software repairable by people who did not build it.
Settling. Every house settles. Every database grows. A search that is instant with 500 records can stall at five million if nobody planned for it.
Who can repair it. A house built from a rare imported material needs a rare contractor for every repair. Software built on an obscure framework needs a rare programmer. The next person to touch the code matters as much as the first.

The floor plan

The front door. Where the front door goes decides how guests first meet the house. The homepage decides what an investor sees in the first five seconds, and someone has to choose which single message leads.
The order of rooms. You walk through the living room before you reach the bedrooms. Navigation decides what a visitor finds first, what they find second, and what they never find.
How many rooms. Too many small rooms feel cramped. Too many thin pages feel the same way. Deciding which content gets its own page and which shares one affects how pages rank and how much there is to maintain.
The kitchen triangle. Kitchens keep the sink, stove, and fridge close together because the cook moves between them all through a meal. Good interfaces keep repeated actions close together. An admin screen that makes an editor scroll three times to publish a press release has a bad triangle.
Closets. Every house needs storage nobody sees. Every site needs a home for old press releases, past presentations, and retired programs, plus a rule for how long each one stays.
Doors that lock. Some rooms need privacy. Some pages need passwords, some need to stay out of search results, and some must stay hidden until a specific date and time.
Steps at the entrance. A house with steps at every entrance shuts out a wheelchair. A site with poor contrast, no keyboard support, and images without text descriptions shuts out real visitors and invites legal trouble.
Light. Architects place windows for the hours a room gets used. Designers place the most important content where the eye lands first on a phone, which differs from where it lands on a large monitor.
Noise. The bedroom goes on the side away from the street. Pop-ups, autoplay video, and oversized cookie banners are street noise, and someone decides how much of it a visitor has to put up with.
Guests and residents. A guest bath and a primary bath serve different people. A public site and a logged-in portal serve different people too, and blurring them causes confusion and security holes.

Plumbing, wiring, and mechanical

Where the pipes run. Plumbing goes into the walls before the drywall goes up. The team plans connections to the CRM, analytics, email, and HR systems before anyone builds pages. Otherwise someone bolts them on later through holes cut in finished walls.
Water pressure. A shower on the third floor needs enough pressure to reach it. A form that sends leads to a CRM has to handle the CRM being slow or down, or the leads disappear and nobody notices for weeks.
Shutoff valves. A good house lets you stop the water to one room without draining the whole house. A good system lets you switch off one feature without taking the site down.
The breaker panel. Electricians size circuits for the load they carry. Programmers size servers and databases for theirs, and somebody chooses what happens when the load goes past the limit.
Labeled circuits. An unlabeled panel turns a ten-minute fix into an afternoon of flipping breakers. Unlabeled settings, undocumented API keys, and mystery scheduled jobs do the same thing to software.
Ventilation. A bathroom without a fan grows mold. A system without logs grows problems nobody can see until something fails in public.
Gas lines. Some systems hurt people when someone builds them wrong. Payments, patient data, and anything that stores personal information belong in that group, and the people handling them need to know the rules.
The water heater. A small tank runs out halfway through the third shower. One investor conference can send more visitors to a site in an hour than it normally sees in a month. Someone decides the size of the tank.
Shared wells. A house on a shared well depends on its neighbors. A site that loads a third-party script, a font service, a chat widget, and a video host depends on four companies you don’t control.
Smart home overreach. A house whose lights need an app goes dark when the app company folds. A site that needs five paid subscriptions to load its homepage breaks when one of them changes its pricing or shuts down.

Codes, permits, and inspections

Why codes exist. Building codes record lessons learned from fires and collapses. Web standards record lessons learned from breaches and lawsuits. A programmer who knows them builds them in from the start. AI follows them when someone asks, and only as well as that person can check the result.
Permits. A house needs approval before construction starts. A page on a corporate site often needs approval from legal, compliance, investor relations, and communications before it goes live, and the system has to support that review.
Fire exits. Codes require a way out. Software needs a way to roll back a bad release in minutes.
The electrical inspection. An inspector checks the wiring before the drywall hides it. Code review checks the logic before six months of new features bury it.
Accessibility rules. The ADA shapes doorways and ramps. On the web, accessibility requirements apply to many organizations, and federal agencies must meet Section 508. A team has to know which rules apply to them.
Privacy rules. A homeowner can’t point a camera into the neighbor’s window. A site has rules about what it tracks, what consent it asks for, and how it treats visitors from Europe or California.
Disclosure rules. Selling a house can require disclosing radon or lead paint. Public companies have rules about when and how material news becomes public, and a website that posts a press release ten minutes early can break the company’s disclosure process. The legal team owns those rules. The system has to make them easy to follow.
Smoke detectors. They are cheap and required, and people ignore them until there is a fire. Uptime monitoring and error alerts work the same way.
The front door lock. Security is a hundred small choices about who can log in, how the system stores passwords, whether someone removes accounts when people leave, and whether someone updates the plugins. AI writes a login form in seconds. Somebody has to decide the policy behind it.
The final inspection. A certificate of occupancy says a house is safe to live in. Before launch, someone tests every form, every redirect, and every screen size, then signs off.

Materials and finishes

Brick or siding. Neighbors judge a house by its facade. Investors judge a company by its visual design, and the design has to fit the company’s brand and its stage.
Finishes that only look expensive. Some finishes look great at the open house and peel within a year. Some code looks great in a demo and falls apart the first time an editor pastes text from Word.
Paint in the real room. A paint chip looks different once it is on the wall. A design looks different on an older Android phone in direct sunlight.
Countertops that hold up. Marble stains. Some CMS setups let an editor break a page layout with one bad paste. Someone decides how much freedom editors get and where the guardrails go.
Flooring for the traffic. Hallways need tougher floors than guest rooms. The pages people visit most need the most testing and the fastest load times.
Windows that open. A pretty window that doesn’t open is a fire hazard. A pretty animation that blocks the content is a usability hazard. Motion on a science site should help someone understand the mechanism, the platform, or the data.
The weight of materials. A slate roof needs a stronger frame. Large images, background video, and heavy scripts need a site built to carry them, or every page gets slow.
Fitting the neighborhood. A glass cube on a street of colonials draws complaints. A playful consumer-app look on a clinical-stage biotech site can cost credibility with the audience the site exists for.
Finishes that age well. Trendy tile dates a kitchen within a few years. Trendy design dates a site the same way, and a programmer has to weigh current against durable.
Fixtures you can swap. A standard faucet comes out in an hour. A component built on standard patterns can be replaced without touching the rest of the site.

Weather and disaster

Hurricane straps. On the North Carolina coast, where I live, builders tie roofs to the walls with metal straps so a storm can’t lift them. A site that may see a traffic spike on a data readout day gets caching and a content delivery network set up ahead of time.
Flood insurance. You hope you never use it. Backups are the same, and the question that matters is whether anyone has ever tested restoring one.
The sump pump. Water gets into a basement eventually. Bad data gets into a system eventually too, and the system needs a way to catch it before it spreads.
The generator. When the power fails, something has to keep running. When a vendor fails, someone has already chosen which features must survive the outage.
Termite inspections. Termite damage happens slowly and out of sight. Outdated dependencies and unpatched plugins rot a site the same way.
The roof’s lifespan. An asphalt roof lasts a couple of decades. Frameworks and platforms have lifespans too, and their makers publish the dates when support ends. Someone has to track those dates.
Freeze protection. Pipes in an outside wall burst in the first hard freeze. Code that assumes an outside service will always answer breaks the first time it doesn’t.
Storm shutters. When a storm turns, you need the shutters closed in an hour. When a crisis hits, a company may need a statement on its site within the hour, and the right person has to be able to post it without waiting on a programmer.
Snow load. Roofs in Vermont carry a weight that roofs in Florida never see. A site for a company about to announce major clinical results needs capacity that a quiet site never needs.
The evacuation plan. The family knows where to meet. The team knows who to call, where the passwords live, and how to restore the site when it goes down at 2:00 AM.

Crew, schedule, and change orders

Sequence. Drywall goes up after the wiring. Write the content before you lock the design, because real content breaks layouts designed around placeholder text.
The critical path. Custom cabinets take twelve weeks to arrive, so they get ordered first. Domain transfers, single sign-on approvals, and security reviews can take weeks too, so they start on day one.
Change orders. Moving a wall after framing costs many times what moving it on paper costs. Changing the data model after launch works the same way. A programmer knows which changes are cheap now and expensive later, and says so before it is too late.
The general contractor. Someone coordinates the plumber, the electrician, and the drywall crew. On a software project someone coordinates design, development, content, IT, legal, and outside vendors, and that person has to understand enough of each to spot conflicts.
Subcontractors. A careless sub can ruin good plans. A plugin from an unknown author can ruin a good site. Someone decides who gets to put code into the building.
Walking the site every day. Good builders check the work daily. Good programmers read the code that went in today, including the code AI wrote.
The punch list. At the end, someone walks the house with blue tape and marks every flaw. Before launch, someone does the same with the site and decides which flaws block launch and which can wait.
Dates tied to events. A family moving before the school year starts has a hard date. A company launching a site before an investor day or a major conference has one too, and the plan has to fit it.
Scope creep. “While you’re at it” adds cost to every construction job. It adds cost to every software project too.
Saying no. A builder who agrees to every request builds a house that fails inspection. A programmer who agrees to every request builds a site nobody can maintain. AI agrees to almost everything.

Moving in

Keys. Someone decides who gets a key and who collects keys when people leave. Someone decides who gets admin access and removes it when they leave.
The owner’s manual. Every appliance comes with one. Every site needs documentation for the people who will run it, written in their language.
The walkthrough. A builder shows the owners how the thermostat works. A programmer trains editors to publish, and watches where they get stuck.
Moving the furniture in. A sofa that won’t fit through the door is a planning failure. Content that won’t fit the new templates is the same failure, and moving content is often the longest part of a redesign.
Forwarding the mail. You tell the post office you moved. You redirect every old URL to its new home, or search engines and partners lose track of you.
Turning on the utilities. Analytics, search console access, uptime alerts, and email routing all need to work on day one. Each one is a decision about what to measure and who sees it.
The first night. Something always goes wrong the first night in a new house. Launch day needs someone on call who has access to everything and knows how the pieces fit.
A number on the mailbox. A new house needs its address where people can see it. A new site needs good page titles, descriptions, a sitemap, and structured data so search engines and AI tools describe the company correctly.
The housewarming. Someone plans the launch announcement with the communications team, so the site is ready when the press release links to it.
Whose name is on the deed. Owners keep the deed somewhere safe. Companies need to know whose account holds the domain, the hosting, and the analytics. A domain registered to a former employee’s personal email is a common and painful discovery.

Living there for years

The maintenance schedule. A house needs clean gutters, fresh filters, and new caulk. A site needs updates, backups, security patches, and broken-link checks. Neglect is cheap for a while and then expensive all at once.
Renovations. A kitchen remodel goes well when the original builder left room for it. A redesign goes well when the original programmer kept content separate from presentation.
Additions. A new wing has to tie into the old structure. A new product line, a new language, or an acquired company’s brand has to tie into the existing site.
Resale value. Buyers pay more for a house with clean inspections and good records. Acquirers and incoming teams look for clean code, documentation, and clear ownership of every account.
One contractor who understands it. If only one contractor in the state understands the house, that contractor sets the price. If only one programmer understands the site, that programmer does. A programmer who cares about the client avoids creating that dependency.
Proprietary fixtures. A house full of one brand’s proprietary parts needs that brand forever. A site built on a closed builder can’t move when the company outgrows it.
Rising costs. Property taxes go up. Software subscriptions go up too, and the cost of a platform over five years matters more than the cost to launch it.
A changing family. Kids grow up and the house has to change with them. Companies grow from preclinical to clinical to commercial, and the site’s audience shifts from investors toward physicians and patients.
Renovate or tear down. Some houses are worth fixing and some are teardowns. Deciding whether to repair an old site or start over depends on everything above this line.
Knowing what you don’t know. A good architect calls a structural engineer for the cantilever and a soils engineer for the hillside. A good programmer knows when a problem needs a security specialist, an accessibility auditor, or a database expert. AI rarely stops to say it doesn’t know enough to answer.

What those 100 decisions have in common

Each one needs knowledge of this company, these users, these rules, this budget, and this timeline. Each one needs someone who has seen the options and watched the wrong choice fail.

AI can help with many of them. It can list options, explain tradeoffs, summarize the rules, and draft a plan. That help is real and I use it. The decision still belongs to someone who understands the situation and will answer for the result.

Look at the list again and notice how few of the wrong answers would show up on launch day. A missing redirect plan, an editor-hostile CMS, a domain registered to the wrong person, and an untested backup all look fine at launch. They surface months or years later, when fixing them costs the most.

Every decision gets made, even when nobody makes it

When you prompt an AI tool to “build a biotech website,” you leave hundreds of decisions unstated. The tool still has to pick a framework, a host, a content system or none at all, a navigation structure, a color palette, a way to store form submissions, and a place to keep the keys. It fills each gap with a common answer.

Some of those defaults will suit your company. Some won’t. You won’t know which until much later, and you can’t find them because nobody wrote them down.

Andrej Karpathy coined the term “vibe coding” in early 2025. He described it as accepting whatever the AI produces without reading it closely, and said it was fine for throwaway weekend projects. That framing is right. A weekend project can survive a hundred unexamined defaults. A website that investors, partners, and regulators read cannot.

Business-critical software is a different job

A prototype has to work once, for the person who built it. A business-critical site has to keep working for years, for many people, under rules, while the business changes around it.

I spend part of my week as a senior developer on an enterprise WordPress platform that is moving more than 400 federal websites onto one system. I built most of its theme, including about 25 custom content blocks. Writing the code for any one block is the easy part, and AI makes it easier. The hard part is deciding how that block behaves across hundreds of sites run by editors I will never meet. Every page has to pass accessibility rules, and a core team and a working group of more than 20 people weigh in. Those decisions take most of the time, and they decide whether the platform works.

Corporate websites for public companies, investor-facing sites for companies preparing a raise, and enterprise applications all sit in this category. They have many stakeholders, legal review, real security risks, accessibility obligations, traffic spikes tied to news, and connections to other systems. They live for years. On this kind of software, AI is nowhere near ready to replace the people who program it.

AI will take over syntax. That has happened before.

The history of programming is a history of removing syntax.

The first programmers wrote machine code, the raw numbers a processor reads. Assembly language replaced the numbers with short words. Then high-level languages replaced assembly for most work. In 1954, the IBM team building FORTRAN predicted in an early report that it would all but eliminate coding and debugging. COBOL followed, designed to read like English so that business people could write programs themselves.

Neither prediction came true the way its backers imagined. FORTRAN removed most of the tedious syntax, and the number of programmers grew. Professional programmers ended up writing most COBOL. Each new layer made the old syntax unnecessary, and each one left the decisions standing. Programmers spent less time telling the machine how and more time deciding what.

AI is the next layer. I think we are heading toward a point where most programmers rarely write syntax by hand, the way most programmers today never write assembly. Programmers will spend their hours reviewing and deciding.

A person or a team still has to understand the business and the technology well enough to make the thousands of choices that determine whether the product succeeds. The job title may change. Someone will still hold the role.

What this means if you run a company

If you are about to hire someone for a site that matters, How to Avoid a $100K Mistake When Hiring a Web Agency covers how to tell a vendor who makes decisions from one who builds whatever you ask for.

Expect AI to make good programmers faster. Syntax should get cheaper and quicker. A team that refuses to use AI will cost more than it should.
Keep the people who make the decisions. If you cut the programmers and keep the tools, you have nail guns and no plans.
Judge programmers by their questions. A good programmer asks about your audience, your approval process, your editors, and your next two years before quoting a price. A vendor who starts building before asking is letting defaults decide.
Be wary of anyone promising that AI replaces the whole team, especially on the site your investors read. Ask them who makes the 100 decisions above.
Use AI to prototype. A quick AI-built prototype is a cheap way to test an idea. Treat it like a model home, and don’t move the family into it.
Ask who answers when it breaks. Get a person’s name.

AI Writes Code. Someone Still Has to Program.