Over the past year, I’ve received some version of the same question again and again. It arrives in emails, in DMs, and after talks, mostly from engineers early in their careers, or from people thinking about becoming one:

With AI doing so much of the heavy lifting, does it still make sense to learn how to code?

Whatever the wording, the worry behind it is the same. They have watched a model produce in seconds what took them a week to learn, and they’re wondering whether the years it takes to get good at this will still be worth it by the time they get there.

The most recent version came from a young engineer in Accra. He’d already shipped a few products with AI’s help, and building that fast had shown him where his understanding ran out: architecture, data modeling, debugging, and knowing when a system is reliable. He wanted to be able to define the domain rules, design the data and its boundaries, test the failure cases, and maintain the system on his own judgment. He didn’t want to spend months collecting tutorials and still be unable to explain what he’d built.

His version skips the panic and goes straight to the practical question underneath: how do you learn the part AI can’t do for you? It deserves a better answer than the quick replies I’ve been sending.

The short answer is yes. The longer answer is that the reason to learn has changed, and so has what you should be learning toward. The goal has moved from typing the code to owning the system the code runs in.

Twenty years. That’s how long I’ve been writing code professionally, and as I wrote last year, I’ve seen this episode before. This time, the clearest reruns aren’t in software at all.

Two industries already ran the experiment we’re living through, and both kept careful notes.

The car factory shows what happens to the people who make things when machines take over the making. The camera shows what happens when everyone gets the machine. AI is doing both to software at the same time, which is why the moment feels so disorienting.

Part one: the factory

The workshop

People built the first cars by hand.

Karl Benz finished his Patent-Motorwagen in 1885 and filed for a German patent on it in January 1886. Benz and a few workers built the three-wheeled carriage, with its single-cylinder engine, in a small Mannheim workshop. They understood every part of it: the engine, the chassis, the steering, the brakes.

The Benz Patent-Motorwagen, shown in an 1890s reconstruction of the 1885 original. In the craft era, a small crew built the entire car and understood all of it. From W. Worby Beaumont, Motor Vehicles and Motors (1900). Public domain.

Within a decade, carmaking became a business, and it still looked like a workshop. In The Machine That Changed the World, their study of the global auto industry, James Womack, Daniel Jones, and Daniel Roos use the Paris firm Panhard et Levassor as their example of craft production in the 1890s. Parts came from small shops across the city, and the shops didn’t share a standard system of measurement. Skilled fitters filed each part by hand until it fit, so two cars built to the same design came out different.

Building a car this way was slow and expensive, and early automobiles were toys for the rich. By the end of 1894, P&L, one of the leading carmakers in the world, had built ninety cars in total.

But the builders owned the machine. If something broke, the person who built it could diagnose it, because no gap separated the maker from the product. The knowledge lived in individuals.

Parts that fit

Ask people what Henry Ford invented and most will say the assembly line. The line was the visible part. The invisible precondition came first.

By the time Ford introduced the Model T in 1908, his factory had something P&L never had: parts that fit. Ford insisted on a single gauging system across the whole manufacturing process, and he took advantage of new machine tools that could cut hardened metal, so parts no longer warped after machining. Each part came out the same. Fitters, the skilled craftsmen who had made craft production work, became unnecessary.

Womack and his co-authors measured what that alone did. By August 1913, before the moving line existed, the average task cycle for a Ford assembler had already fallen from 514 minutes, assembling a large share of a car, to 2.3 minutes, performing a single step. The moving line then cut it to 1.19 minutes. Interchangeable parts made the narrow job possible. The line made it faster. Remember that; it comes back later.

The line

On October 7, 1913, Ford’s Highland Park plant in Michigan switched on its moving assembly line. Instead of workers walking to the car, the car came to the workers, pulled along by a rope and later a chain. Within about a year of experiments, the labor needed to assemble a chassis fell from about twelve and a half hours to ninety-three minutes.

The assembly line at Ford’s Highland Park plant, 1913. The knowledge moved out of individual workers and into the process. Library of Congress, public domain.

The price of a Model T fell from $850 in 1908 to about $260 by the mid-1920s. Ford built more than fifteen million of them before production ended in 1927. Ordinary families could afford a car.

Ford’s line workers became interchangeable, like the parts. A worker on the line might tighten the same few bolts all day, and could learn the job in minutes. The work was so monotonous that Ford’s labor turnover reached about 370 percent in 1913: the company had to hire more than three people a year to keep each position filled. Part of the fix was the five-dollar day in 1914, a profit-sharing scheme that more than doubled pay for workers who met the company’s conditions.

The skill went two places. Some of it went into the process itself: the sequence of stations, the timing, the jigs and fixtures that held each part in the right place. The rest went to a new class of people who stood beside the line rather than on it. Industrial engineers designed the work. Toolmakers built and maintained the machines. Inspectors checked the output. Supervisors kept the flow moving.

No single worker understood the whole car anymore, but a new set of people understood the whole system. Once machines take over production, ownership moves to whoever understands the system that does the producing.

Toyota puts judgment back on the line

After the Second World War, Toyota couldn’t copy Detroit. It had little capital and a small domestic market that wanted many kinds of vehicles in small numbers. It also couldn’t treat its workers as disposable. Toyota settled a bitter 1950 strike, which cost founder Kiichiro Toyoda his job, by guaranteeing long-term employment to the workers who stayed. If the people on the line were going to be there for decades, it made sense to use their heads as well as their hands. Taiichi Ohno, a Toyota engineer, spent the following decades building what became the Toyota Production System.

The core idea came from a loom. Sakichi Toyoda, the company founder’s father, built automatic looms, and his Type G of 1924 stopped itself when a thread broke instead of weaving defective cloth until someone noticed. Toyota calls the principle jidoka, automation with a human touch. Ohno carried it onto the assembly line: any worker could pull a cord to halt the line at a defect, and the team fixed the process so the defect wouldn’t recur.

Ford had moved knowledge off the line. Toyota moved some of it back, and expected the people on the line to spot defects and stop the line for them.

The robots

The first industrial robot, the Unimate, started unloading hot die-cast parts at a GM plant in New Jersey in 1961. Over the next two decades, robots took over welding and painting, the hot, toxic work people were glad to give up.

In the 1980s, GM tried to skip ahead. Under chairman Roger Smith, the company spent about $45 billion during the first half of the decade, much of it on automation and new technology, chasing a “factory of the future” that would beat Japanese competitors with machines. Its showcase Detroit-Hamtramck plant opened in 1985 with around 260 robots and ran far below its target rate for years. The stories that came out of GM’s automated plants became industry folklore: robots reportedly painting each other instead of the cars, and lines stopping for hours while technicians debugged the machines.

The robots struggled with variation, the thousand small differences and edge cases that human workers absorbed without thinking. GM had automated a process it didn’t understand well enough to automate.

The strongest evidence came from a factory GM ran at the same time. In 1984, GM and Toyota reopened GM’s shuttered Fremont, California plant, once one of GM’s worst, as a joint venture called NUMMI. More than 85 percent of the workforce came from the old plant. Toyota ran it under the Toyota Production System, with less automation. Within months, its defect rates matched those of Corollas built in Japan and beat GM’s own high-tech factories. (The plant closed in 2010. Tesla builds cars there now.)

The plant had the same workers and fewer robots, and it built better cars. The system and the judgment inside it made the difference.

Carmakers keep relearning the lesson. In 2018, stuck in Model 3 production trouble in the same Fremont plant where NUMMI had proved the point more than thirty years earlier, Elon Musk admitted that “excessive automation at Tesla was a mistake.” His next line: “Humans are underrated.” Sakichi Toyoda’s loom could have told him that in 1924.

Where the humans went

A new division of labor emerged. Robots took the repetitive work they were good at: welding, painting, lifting, placing. Humans moved up the stack into the roles the robots couldn’t fill.

KUKA robots from the 1980s at work on a body shop line. Robots do the repetitive work. Humans verify, diagnose, and improve the system. Photo by Mixabest, CC BY-SA 3.0.

Today, many of the skilled people in a car plant run quality assurance, build diagnostic systems, maintain the machines, and redesign the line itself. The valuable skill now is checking the machine’s work, and understanding the system well enough to improve it. (The craft survives as a niche: at Goodwood, a single Rolls-Royce craftsman still paints the coachline on each car by hand.)

For anyone deciding whether to learn to code, the factory offers a plain lesson. The workers whose jobs disappeared were the ones whose only skill was a motion the machine could repeat. The people who kept their value understood the machine: how it worked, how it failed, and how to tell the difference. Most of them learned it by doing the work first.

Part two: the camera

The factory tells a story about producers. It doesn’t say much about what happens when the means of production ends up in everyone’s pocket. For that, we need a second story.

Before the button

Louis Daguerre made photography practical enough to announce his daguerreotype process to the public in 1839. “Practical” still demanded a lot. The photographer polished a silver-plated copper sheet to a mirror finish, sensitized it over iodine, exposed it for several minutes, and developed it over hot mercury (health and safety would like a word). Each plate produced one image, with no negative for copies. Owning a camera covered one part of the job. The rest was chemistry, optics, and a subject willing to hold still.

A Susse Frères daguerreotype camera from 1839, at the WestLicht Museum in Vienna. The camera was the easy part. Public domain.

This was photography’s workshop era. The photographer, like the fitter at Panhard et Levassor, owned the whole process and sold access to something few people could do.

“You press the button, we do the rest”

Over the next half-century, dry plates, faster emulsions, and roll film moved work out of the photographer’s hands. George Eastman turned that into a business. The Kodak camera arrived in 1888 loaded with enough film for 100 exposures. Customers took their pictures, mailed the whole camera to Kodak, and received prints, negatives, and a reloaded camera in return. Eastman described the arrangement with one of the best product slogans ever written: “You press the button, we do the rest.”

Kodak hid the complicated part behind a service. The customer expressed intent through the shutter; the company ran the backend.

The Brownie followed in 1900. It sold for one dollar, and by the end of 1905 Kodak had sold more than 1.2 million of them, according to the Smithsonian. Families could record birthdays and holidays without hiring a portrait studio. The number of people taking photographs exploded because Kodak removed the requirement that they become chemists first.

The original Kodak Brownie of 1900. It sold for one dollar. Photo by Deveycx, CC BY-SA 3.0.

Kodak anticipated Ford by a quarter of a century. Eastman’s factory processed film the way Highland Park would later assemble chassis: standardized, centralized, at scale. The customer saw a button. Behind it sat a system that few customers understood and none needed to.

Professional photographers kept working. Their customers still needed someone who could compose a portrait, control light, direct a subject, and deliver a result on demand. The Brownie reduced the value of operating the process. It increased the value of the choices made around it.

The camera learned the settings

Manufacturers kept encoding technique into the product: built-in light meters, automatic flash, and by 1977 autofocus on a mass-produced compact. You no longer needed to understand aperture or shutter speed to bring home a decent snapshot. Professionals used the same features and earned their fees by knowing when the automatic choice would work, when to override it, where to stand, and when to press the shutter.

A camera could focus on a face. It couldn’t decide which face carried the story.

The darkroom moved onto the desktop, then into the phone

A Kodak engineer, Steve Sasson, built the first self-contained digital camera in 1975. Over the next three decades, digital cameras made an extra attempt nearly free, Photoshop moved the darkroom onto the desktop, and the iPhone put a camera, an editor, and a publishing platform in one pocket.

Modern phones go further. Google’s Night Sight captures a burst of frames, aligns them, and merges them with machine-learning models before you see a single photograph. The device chooses the lens, reads the scene, and does the post-processing. You still decide where to point it.

Abundance had a cost

Fotomat once operated more than 4,000 drive-up kiosks where customers dropped off film for development. Digital photography removed the film roll, and Fotomat had closed by 2009. Members of the Camera & Imaging Products Association shipped 121.5 million digital cameras in 2010. In 2023 they shipped 7.7 million. Buyers moved the part of the market closest to “good enough” into the phone.

Photographers felt it too. A restaurant could shoot its daily special on a phone, so some paid work vanished and the rest lost pricing power.

The profession remains. The U.S. Bureau of Labor Statistics counted 151,200 photographer jobs in 2024, two-thirds of them self-employed. The assignments that survived make the distinction clear. A wedding photographer has one chance to capture a first kiss. A commercial photographer has to reproduce a client’s visual language across a campaign. A photojournalist needs access, timing, context, and an ethical relationship with what happened.

Everyone gained the ability to make a photograph. The market kept paying people who could solve a photographic problem for someone else when it mattered.

The word photographer ended up with two meanings. I’m a photographer when I take a picture with my phone. I hire a photographer when I need someone to deliver a body of work under constraints. The activity became universal, while the profession narrowed to the people who understood it.

An exchange I came across on X captured the difference. Saanvi Dhillon wrote that “AI makes everyone a developer” is true in the same way cameras made everyone a photographer. Brandon Galang, who used to do paid shoots, responded that if you put a $5,000 camera in an amateur’s hands, his photographer friend could still outshoot them with an iPhone. He would also trust an experienced engineer using a weaker AI model over a novice using the strongest one.

The photographer with the iPhone wins because they learned light, composition, and timing the hard way, and the tool can’t supply what they learned.

Part three: software walked the same road

Put the two stories side by side and they move through the same eras. Software has already lived through most of them.

This isn’t the first time someone has predicted the end of programming. In “AI and Software Engineering: This time it’s different (it never is)”, I traced seventy years of those predictions, from compilers to low-code. Each wave moved us further from the machine, and each one created more software work, not less. The factory and the camera add a harder lesson to that history: a profession can survive while whole categories of paid work inside it disappear.

The workshop and the line

Software’s first era was the generalist age. One engineer held the whole system in their head: the HTML, the server code, the database, the deployment. Those of us who built LAMP-stack applications in the 2000s remember it. Slow by today’s standards, but the builder owned the machine, like the fitters at Panhard et Levassor.

Then came interchangeable parts. Open-source libraries, package managers, standard protocols, and public APIs did for software what Ford’s single gauging system did for cars. A component built by a stranger on the other side of the world would fit, because everyone agreed on the interface. You no longer file parts by hand. You run npm install, and occasionally discover that half the internet depends on eleven lines called left-pad.

Specialization followed: frontend, backend, database administrator, systems administrator, then DevOps, SRE, platform, mobile, data, and machine learning. Here the analogy needs care. Software specialists resemble Toyota’s teams more than Ford’s line workers. A good database engineer has deep knowledge of their station and stops the line when they see a problem.

And we built our own assembly line: the CI/CD pipeline. Code moves down a line of stations. Lint. Unit tests. Integration tests. Security scan. Staging deploy. Production. Automated quality gates sit at every step, like inspection stations on a factory floor. A failing build is an andon cord. It stops the line so the defect gets fixed where it happened rather than discovered by a customer.

No single engineer understands the entire pipeline anymore, and that’s fine. The people who own software today are the people who understand that system.

The robot and the Brownie, at the same time

Now the third era is arriving, and AI plays both roles from our two stories.

AI is the factory robot. Copilot, Claude, and coding agents do the repetitive production work: the boilerplate, the first draft, and more often now the whole feature. That’s already how many teams work.

AI is also the Kodak Brownie. It hides a specialized process behind a simple interface, the way Kodak hid film chemistry behind a button. A product manager, a designer, or a small-business owner can describe an application, inspect the result, request changes, and publish something useful without learning the language that implements it. Software production no longer belongs only to people who can write syntax from memory.

Developer is acquiring the same two meanings as photographer. Millions more people will make scripts, internal tools, and small applications, and most of them will never call themselves engineers. Arguing over whether they count as “real developers” misses what happened. Software exists that did not exist before, because a new tool let someone express an idea at a higher level.

Both things are happening to software engineers at once. Machines are taking over our production work, as they did the line workers’. And everyone is getting our tools, as the studio photographers’ customers did. Either change alone would reshape the profession. Together, they make it hard to see what the job is.

I won’t pretend this is painless, least of all for the people asking me the question. Both histories are honest about the cost. Fotomat’s kiosks closed. Ford’s fitters lost their trade. Some routine implementation work will lose its price, and teams will expect smaller groups of engineers to attempt more. Some of the entry-level tasks that used to train junior engineers will disappear before companies figure out what replaces them. The transition will be uneven.

But the two histories also agree on who comes out the other side. In the factory, the people who kept their value moved to verification, diagnosis, and design of the system. In photography, the professionals who survived sold judgment and reliability when the result mattered. Both groups won on judgment, and neither tried to outproduce the machine.

Where the analogy breaks

The comparison has limits, and they cut in the engineer’s favor.

You can look at a photograph and decide whether you like it. Software can look convincing in a demo while hiding data loss, race conditions, security flaws, and a maintenance burden that arrives months later. A photograph sits still. Software runs, handles money and personal information, and keeps changing after it ships, as if someone kept rebuilding the car while you drove it.

That difference raises the value of engineering judgment. A model can generate an authentication flow. Someone has to decide which threats matter, how sessions expire, where secrets live, how a user recovers an account, and what the team will do after a breach. A model can write a database migration. Someone has to plan the rollback and protect years of customer data.

AI can help with each of those tasks. Its help doesn’t transfer responsibility to the model.

Part four: what the human job becomes

Underneath “should I still learn to code?” sits a deeper question: when the robots write the code, what is the human job? The factory and the camera both answered. The human job is verification, diagnosis, and systems thinking.

Verification is the job now

Verification comes down to a handful of skills you can build.

Read generated code like a reviewer, not an author. You trust code you wrote because you remember writing it. You don’t get that with generated code, so read it the way an attacker would. Trace the data flow and check every boundary: empty input, malicious input, ten thousand concurrent requests. The AI won’t volunteer its weak spots.

Learn the failure modes. Systems break in predictable places, and generated code is no exception: authentication and authorization logic, concurrency and race conditions, error handling paths, N+1 queries, retry storms, misconfigured timeouts. A verifier who knows where defects cluster is worth ten who read every line with equal attention.

Treat tests as specification. Tests are how you tell the machine what correct means. Property-based tests, load tests, and contract tests are your inspection stations. If you can’t write a test that would catch the bug, you don’t understand the system well enough to ship it.

Instrument everything. You can’t verify what you can’t see. Logs, metrics, and traces are your diagnostic systems, and the engineer who can read a system’s behavior under load is the one who can own it.

Review for security by default. Generated code optimizes for working code. Safety is your job. Injection flaws, exposed secrets, too-broad permissions, missing rate limits: assume they’re present until you’ve checked.

Pull the cord. Toyota’s line worked because anyone could stop it. Your pipeline, your code review, and your own judgment are only useful if you’re willing to stop the line when something looks wrong, even when the generated code is plausible, the deadline is close, and everyone else approved it.

All of this depends on one thing: you can only verify what you understand. Verification without first principles is rubber-stamping. GM in the 1980s had plenty of machines and too little understanding of its own process.

If you don’t know how a load balancer distributes traffic, you can’t evaluate whether the AI’s scaling strategy will survive a traffic spike. If you don’t understand consistency models, you can’t judge whether the generated caching layer will serve stale data at the worst possible moment.

Learn to code, then, by hand, even though a machine will write most of your code. Writing code is how you build the mental model that verification depends on. You learn what a race condition is by causing one and spending an afternoon finding it. You learn why a query is slow by writing the slow version first.

Both of our histories say the same thing. The photographers who could tell when the automatic exposure was wrong were the ones who had learned to set it themselves. Toyota’s line workers could pull the andon cord because they knew their station well enough to recognize a defect. And you can’t stop a line you don’t understand.

The purpose changes. You learn to code so you can read the machine’s work and catch its mistakes.

Systems thinking in practice

“Think in systems” is good advice that arrives without instructions. A systems thinker looking at any piece of software sees four things.

• State. Where does data live, who can change it, and what happens when two writers disagree?
• Feedback loops. What happens when this component gets slow? Does pressure propagate upstream, or does something absorb it?
• Failure domains. When this part breaks, what else breaks with it? What is the blast radius?
• Trade-offs. Every design decision buys something and sells something else. Speed for consistency. Simplicity for control. What did this design buy, and was the price worth it?

Suppose you need a notification service. The naive design: your API receives a request, writes to the database, calls the email provider and waits for it, and returns. It works. Ship it.

The naive design. The user waits while the API talks to the email provider, so the provider’s problems become the user’s problems.

Now learn one concept in depth: queues. Revisit the design. The API writes the notification to a queue and returns right away. Workers pull from the queue and call the provider, with retries.

The same service with a queue. The API’s job ends at the queue. Workers deal with the provider, retry failures, and set aside jobs that never succeed.

Now do the systems thinking. What did the queue buy? Resilience: if the provider is down, requests still succeed and notifications go out later. Backpressure: traffic spikes queue up instead of crashing the API. Independent scaling: you can add workers without touching the API.

What did it cost? Complexity: queue infrastructure, workers, and dead-letter handling for messages that never deliver. Eventual consistency: you told the user “sent” before the email went out. Ordering questions: does notification B depend on notification A going first?

Neither design is “correct.” The systems thinker is the person who can name what each design buys and what it costs, and pick based on what the product needs. That’s the whole skill. Everything else is vocabulary.

Ohno did this on Toyota’s shop floor for years. He watched the line, named what each practice was buying and what it was costing, and changed it.

Part five: how to learn now

Theory alone won’t build any of this. You need practice that forces understanding. I recommend the same practice to everyone who asks.

Learn to code like the machine isn’t there

Start with the code itself, because everything else builds on it.

Write without the assistant for a while. Pick a language and build small, complete programs with AI completion switched off. A command-line tool. A tiny web server. A parser. It will feel slow and a little absurd. That slowness is where the mental model gets built.

Debug your own bugs before you ask. When something breaks, spend real time with the error message, the debugger, and the logs before you paste anything into a model. Debugging is where you learn how programs behave, as opposed to how you assumed they would. It’s the closest thing software has to learning exposure on a manual camera.

Then use AI as a tutor. Once you’ve written something yourself, ask a model to critique it, or to solve the same problem another way, and study the gap. Don’t accept a generated line you can’t explain back in your own words.

Read more code than you write. Open-source projects, your team’s codebase, and the model’s output are all reading material. Reading code with suspicion is the skill you’ll use most for the rest of your career.

Then learn the systems

Once you can write and read code with confidence, move up a level. Start with first principles. Read Backend from First Principles end to end. Use AI to explain concepts until they click, but don’t skip the hard parts; the hard parts are the skill. Keep System Design 101 nearby as a reference for specific concepts, and work through the exercises in the System Design Primer.

Then run the loop:

1. Pick three to five systems and design the simplest version of each, from scratch, with what you know right now. A URL shortener. A notification service. A rate limiter. Keep the designs small enough to finish.
2. Learn one new concept in depth. Caching. Load balancing. Consensus. Message queues.
3. Go back to your naive designs. Apply the concept the way I did above with the queue. Write down what improved, what got worse, and what trade-offs you introduced.
4. Document your progress, then repeat with the next concept.

Two more things.

First, don’t leave the designs on paper. Build them. Write the first version of each one yourself, by hand, because that’s where the understanding comes from. After that, use AI to build the variations faster, and read every line it gives you. Then simulate load and watch where they break. Tools like breakscale.tech can help. A design you’ve watched fail under load teaches ten times more than one you’ve only read about, and like the photographer’s digital camera, an extra attempt now costs almost nothing.

Second, write down what you learn as you go. The writing is part of the learning. If you can’t explain the trade-off in plain language, you don’t understand it yet.

The honest timeline

Do this every week for a year and you’ll understand systems well enough to look at an AI-generated architecture and know where it will fail under load, where the security boundary is thin, and what to verify first. Familiarity with frameworks and a collection of prompt recipes won’t get you there.

It won’t feel fast. The fitters at Panhard et Levassor spent years learning their craft, and Ohno spent decades refining his system. You’re trying to build the judgment that both of them had, in a fraction of the time, with tools they couldn’t have imagined, so a year is a bargain. The engineer in Accra had already worked that out. He’s set himself a year of deliberate practice and is building a tool to hold himself to it.

Read the line

The factory workers who kept their value weren’t the ones who tightened bolts fastest. The robots took that job, and no amount of practicing for speed would have saved it. The ones who lasted learned to read the whole line, to spot defects and improve the system, and they learned it by working the line first. They practiced to understand, not to compete with the machine.

Once everyone had a camera, owning an expensive one stopped setting anyone apart. The photographers who survived were the ones who could be trusted with a moment that wouldn’t happen twice.

AI is our assembly line and our Brownie at the same time. More people than ever will make software, and machines will make most of it. The engineers who thrive won’t be the ones who generate code fastest. They will be the ones who understand the system well enough to know whether the code deserves to run, and who are willing to stop the line when it does not.

So, should you still learn to code? Yes. Learn it the way the best factory workers learned their station and the best photographers learned exposure: well enough that you can tell when the machine gets it wrong.

Own the system, not the code. Learn to read the line.