A useful system can be hard to define when its hardware is visible.

A phone has glass, metal, chips, and a battery. A server has memory, storage, and cooling fans. An AI device may have a camera, a speaker, and a small computer inside. These things are easy to point at.

Software is different. It is defined by code, not hardware.

Code is a set of instructions. It tells a computer what to do. Software includes the programs, rules, data, and related files that make those instructions work. The device runs the code, but the device is not the software.

This sounds simple. In delivery work, it matters a great deal.

A laptop can run a text editor, a web browser, or a local AI model. The hardware stays the same. The software changes what the machine does. The same service can also run on a cloud server, a phone, or a small computer at the edge of a network.

That is the first fact worth keeping. Hardware provides the physical means to run software. Code provides the behavior.

The device is part of the system

The line is clear in theory. In practice, people often talk about a whole product as if it were one thing.

A smart speaker is a product. Its software includes the code that hears commands, sends data, chooses a response, and plays sound. Its hardware includes the microphone, processor, speaker, casing, and network parts.

The product needs both. The definition of its software still comes from its code.

This also explains why software can move. A program may run on one type of processor today and another tomorrow. It may move from a company server to a cloud service. It may run as a browser application instead of a desktop application.

The code may need changes. The user interface may change. The system may need a new driver or library. Yet the physical machine does not define the software. It only sets limits on what the software can do.

Those limits are real. A slow processor may make an application feel poor. A small memory limit may prevent a model from running. A camera can shape what a vision system can see. Hardware affects speed, input, storage, and cost.

It does not change the basic definition.

Where the line gets less tidy

Firmware makes the boundary harder to see.

Firmware is code stored in a device to control its basic functions. It may start a machine, control a sensor, or manage a network chip. It often stays in the device for a long time. Some firmware is stored in memory that does not change during normal use. Some can be updated.

People sometimes call firmware “hard software.” That phrase shows the problem. Firmware lives close to hardware, but it is still software because it consists of instructions and related data.

The label matters less than the design decision. A team needs to know which part can change, who owns it, how it is tested, and how it is updated.

A device may also include configuration. Configuration says how the software should behave in a given setting. It might name a server, set a timeout, choose a language, or define access rules.

Configuration is not always code. Still, it can change system behavior. That makes it part of the delivery picture, even when it does not fit a simple software label.

This is where tidy definitions meet real systems. The code defines the software, but the full behavior may depend on code, configuration, data, hardware, and the people operating them.

That does not weaken the main point. It gives the point a useful limit.

Why this matters for AI delivery

AI systems make the confusion worse.

A model may be stored as files. It may run on a graphics processor. It may use a search index, a database, a prompt, and an application around it. A retrieval-augmented generation system, often called RAG, finds information from a known source before an AI model writes an answer.

The model is software. The search code is software. The index is data. The server is hardware. The answer depends on all of them.

If the source documents change, the answer may change. If the prompt changes, the answer may change. If the model changes, the answer may change. If the hardware is too slow, the system may become hard to use.

A delivery team cannot fix this by pointing at the machine and calling it the product.

The useful unit is the running system. That includes the code and the conditions around it. It also includes tests, logs, access rules, update steps, and a clear owner.

This is why a demo can look complete while the software is not ready. The code may produce an answer. But a real service also needs a way to check that answer, handle failure, protect data, and pass work to another team.

AI does not remove this work. It adds more places where behavior can change.

Code is the part that can be examined

Code gives a team something concrete to review.

Human-readable source code can show how a system makes decisions. Tests can check whether it behaves as expected. Version control can show what changed. Build files can show how the program becomes something a machine can run.

The final running program may not look like the original source. It may be compiled into another form. It may include libraries and packages. The important point stays the same: software is the set of instructions and related parts that direct computer behavior.

This also creates a useful delivery question. Can another team understand, test, run, and change the software?

If the answer is no, the system may still work. It is simply hard to own. That is a delivery risk, not a hardware problem.

I care about this distinction because ownership lasts longer than a launch. The original people may move on. A vendor may change its service. A model may be replaced. Hardware may be refreshed.

The code, tests, settings, and operating notes need to make sense after that change.

There is one honest limit. Software behavior is never defined by code alone once the system is running. Inputs, data, hardware, networks, external services, and human choices all affect the result.

Still, the software itself is identified by its code and related instructions. Hardware runs it. Hardware can constrain it. Hardware does not define it.

That small distinction helps teams speak clearly. A broken sensor is a hardware issue. A wrong rule in a program is a software issue. A bad answer caused by stale source data may belong to the system as a whole.

Clear words lead to clearer ownership. Clear ownership makes useful technology easier to test, operate, and hand over.

That is the grounded observation behind The Practical Signal: AI becomes useful when the code is treated as part of a system that people can understand and continue to run.