I used to write words one letter at a time. Now I can talk to my computer like something out of Star Trek.

Somewhere between autocomplete and LLMs, I stopped being someone who writes software and became someone who orchestrates it. This did not happen overnight. It has been a steady shift, one tool at a time, gradually changing not just how I build, but how I think about building.

Early on, everything was friction. Working in a Unix terminal, editing files in vi, even moving between files was a chore. You did not just click around. You closed one file, typed the path to another, and hoped you did not make a mistake. Writing even a simple function could take hours.

That kind of slowness forces discipline. You think before you type. You plan more. You value every line. But it also sets a high bar for entry. You had to really want it.

Then came drag and drop builders. Visual Basic. Template editors. Suddenly things were faster and more approachable. You did not need to know everything. You could see it, move it, wire it together.

Autocomplete pushed that even further. Editors like VS Code and SQL Server tools started predicting what you meant before you finished typing. Each step made development more accessible. There is always a tradeoff though. The easier it becomes to build, the easier it is to build something you do not fully understand.

Stack Overflow changed the game. You were no longer solving every problem from scratch. You were standing on the shoulders of thousands of people who had already tried things before you. It accelerated everything.

It also came with a catch. You still had to understand why something worked. Copying code got you moving, but understanding it required digging, reading, and context switching. You got the fix, but the learning was still on you.

Tools like Copilot felt like the next leap. You could generate entire functions in seconds. Boilerplate disappeared and patterns showed up instantly. But it was not quite there.

It did not really understand your system. It did not know that you already had a helper function that formatted a string a certain way, or that your data model had nuance. It would duplicate logic you had spent years telling junior developers to avoid. It was fast, but not aware. It felt more like enhanced autocomplete than a true collaborator.

The real shift came with LLMs. For me, it happened during an authentication refactor when we were moving from an on-prem user structure to an Entra tenant. This was not a small change and not something you want to get wrong.

I gave it our existing authentication configuration and asked for two things: help me plan the migration and minimize the impact. Within minutes, I had a clear path forward. Not just code, but reasoning, tradeoffs, and a plan.

That was the moment it clicked. This was not just generating snippets. It was helping think through the problem. Stack Overflow gave you answers. This gave you answers and understanding at the same time.

At first I used LLMs in the browser, but that did not last long. By mid 2025, I was using the Codex extension inside VS Code. That became my normal for a while. I was still working in code and reviewing diffs, but now with an assistant embedded directly in the workflow.

Then something shifted again. I got access to the Codex app and quickly it became my primary interface. The change shows up clearly in how I use the tools.

Earlier, most of my usage was inside the editor through extensions.

Now, most of it happens in the Codex app, with GitHub alongside it.

VS Code did not go away, but it stopped being where most of the work happens.

These days, I do not start in a code editor. I start in a conversation. I am not typing out git commands anymore and I am not manually resolving merge conflicts line by line. Codex handles that faster and often cleaner than I would.

VS Code still has a role. I use it for testing changes and making precise, one-off tweaks that would take too many back-and-forth prompts, like adjusting layout details. But the bulk of the work happens outside of it.

The question has changed. It is no longer about whether I can fix something faster myself. It is about whether I should fix it manually or keep the system in context so it can continue helping. That is a different way of thinking.

This shift is not just about convenience. It has changed how I work. I am finishing sprints days ahead of schedule. I am shipping more proof of concepts and exploring more ideas. My sprint velocity is up by about fifty percent.

Some things have not caught up. Estimates are still human and AI still has a tendency to misjudge effort. But the overall shift is real. When the cost of trying something drops, you try more things.

A few things feel increasingly clear to me. Developers who cling to code-first workflows are going to fall behind. Prompting and problem description are becoming core engineering skills. We need to actively teach junior developers how to work with these tools instead of around them. This is not going to stop at software either. It is going to reshape every job that relies on a computer.

The most important skill now is not typing faster or memorizing syntax. It is solving the right problem, describing it clearly, and keeping the solution from drifting off course.

The tools have changed. The interface has changed. The responsibility has not.

I still build software. I just do not build it the same way anymore.