What got harder. What got easier. What disappeared.

1. Three lists

The cleanest way to see the shift is three lists. Things that got easier. Things that got harder. Things that disappeared.

Read them slowly. If you've been hearing that the field is harder now, or easier now, or unchanged, none of those summaries is right. It's all three at once, in different places.

2. What got easier

These used to take hours. Now they take minutes.

• Boilerplate. Setting up a project, wiring up routes, generating CRUD endpoints. The model produces all of it from a one-sentence description.
• Syntax lookup. Looking up how to format a date in your language, how to read a file, how a library's method is called. The model knows it.
• Drafting tests. Writing the obvious unit tests for a function. The model can produce a first pass in seconds. You still review and add the cases it misses.
• Scaffolding apps. Spinning up a new web app or service from a description. What used to be a half-day of yak-shaving is now an afternoon, including reading the output.
• Writing common patterns. Retry loops, debouncing, pagination, request validation. You describe what you need and read what comes back.
• Translating between languages. Porting a function from one language to another. Reading code in a language you don't write daily.
• Drafting documentation. A first pass of README content, API docs, or a code comment block.
• Explaining unfamiliar code. Pasting a function you don't recognize and asking what it does. It's not always right, but it's a starting point you used to not have.

If you're new to the field, this list is the part that looks like a gift. It is. Just don't confuse "the model wrote it" with "you understood it."

3. What got harder

These got harder because the volume of code per engineer went up, and the source of bugs shifted.

• Knowing when the model is wrong. The output looks confident even when it's nonsense. Catching the wrong line in the middle of correct-looking code is a skill that takes time to build.
• Debugging model-generated code. When you wrote it yourself, you knew the intent behind every line. When the model wrote it, you have to reconstruct the intent before you can fix the bug.
• Maintaining unfamiliar code. More code ships per engineer. Six months later, you're reading code nobody wrote by hand and nobody fully remembers.
• Building taste. Taste used to come from writing a lot of code, getting it wrong, and seeing the consequences. When the model writes most of the code, the feedback loop that built taste is weaker. You have to build taste deliberately.
• Not over-shipping. The model makes it cheap to add a feature. It's now harder to say no, because the cost looks small. It isn't always small; it's just hidden.
• Avoiding subtle wrong-direction problems. It's easy to be a week into a design that the model has been confidently agreeing with, only to find the design is wrong. The model rarely tells you to stop.
• Reviewing code carefully. More code, often less context per line, and a tendency to skim because it looks polished. Careful review is harder and matters more.

If you've been writing code for a decade, this list is the part that surprises you. The hard parts haven't gone away. They moved.

4. What disappeared

Some things really did vanish from the day-to-day. Not "got easier" — gone.

• Memorizing language syntax. Nobody under thirty in this field will ever sit down and memorize how a regex works. They'll look it up, every time, in seconds.
• The Stack Overflow copy-paste loop. The pattern of search, scroll, copy a snippet, modify it, paste it in, see if it works. Replaced.
• Reading bad API docs cover to cover. You used to have to read the whole doc to find the one paragraph you needed. Now you ask, and the answer comes back with a pointer to the right page.
• Simple competitive coding patterns as a daily skill. Two-pointer, sliding window, classic DP. Still useful to know they exist. Not a daily-driver skill anymore.
• Writing the obvious unit test by hand. The first pass is free. Your time goes to the non-obvious cases.
• Manually formatting code. Auto-formatters won that one earlier. The model finished it.
• Asking a colleague how to do a basic thing. You don't interrupt anyone to ask how a date library works. You ask the model. Colleagues are for the things the model can't help with.

5. The honest summary

The field is not easier. It is not harder. It is different.

Some hours of your day are gone, freed up, and you can do more in less time. Some hours of your day are heavier, because the judgment they require has gone up. And a few specific habits from the old way of working are done. Don't carry them with you.

The next unit clears up the myths that confuse this picture.