Six months in, more uncertainty than before

Where I am

I graduated in December and started working in March. I assumed that by now I’d have a rough idea of where I’m going. I have less of one than the day I got my degree.

This isn’t a complaint. I’m loving my job and I’m learning faster than I ever did at university, but every few weeks I try to picture myself in five years, and I can’t see any traditional path that will hold up over the years. These are my notes on why, and on the options I keep turning over. They’re personal, and I’m writing them down mostly to think.

The map I was given

After university, there was a “simple” map to follow. Pick a lane, frontend, backend, infrastructure or data, go deep, and the depth is what you sell. Ten years later you are the person who knows that thing.

Every lane on that map assumed that writing the software was the hard part. For most of what I do day to day, it isn’t anymore. At work we run pipelines where agents write and review code overnight. I ship features end to end, from the design to the backend. A few years ago that kind of work took a whole team months. I do it in a week, and I’m supposed to be a junior. So if juniors are doing the work a team of seniors used to do, what is the senior of the future going to be like?

That question is what unsettles me. If I can do this six months in, how do you grow professionally, or gain seniority over the years? What I’m good at today is not scarce.

So I keep asking where the scarce thing went.

Option one: go toward the models

The first answer is to go where the change is coming from. If models are doing the work, then work on the models: research, training, evaluation, the systems underneath them. That knowledge is hard to get and few people have it.

Part of me wants this. The problems I’ve enjoyed most are the ones where I had to understand a system all the way down. When spending a few months in a research lab in Lyon, I liked being allowed to stay on one question for weeks.

But I can’t tell if it’s a path or a lottery. The people who really move models forward are few, most of them have a PhD and years of head start, and the field moves fast enough that what you learn can be old before you’re good at it. I also don’t know whether I’d like the work or whether I like how it sounds.

Option two: know all four lanes

The second answer is to stop choosing a lane. The old map made you pick one of four. Agents make it possible, and necessary, to know all of them: enough frontend, backend, infrastructure and data to take a spec and ship the whole thing. It’s the normal software engineer job, just wider. You don’t write most of the code, but you have to understand all of it. It’s close to what I already do.

In this version, seniority is how wide you can go and still answer for the result.

My concern is where that goes. The effort it takes from me keeps shrinking over time. I can see it becoming 20% engineer and 80% agents doing the rest without supervision, and I don’t know what that 20% is worth, or how many people it takes to do it. There’s also no room in it to stand out as an individual: if everyone covers everything with the same agents, the work looks the same whoever did it.

Option three: stay close to the people

The third answer is the one I keep coming back to. If anything can be built by anyone, fast, then your side project can be cloned in a weekend and so can the startup you work at. What I ask now is why someone would keep paying for this one.

My bet is the experience. By that I mean how well a product understands the person using it: what they were trying to do, in what order, and how much patience they had left. Two products with the same features are different products if one makes you think and the other doesn’t. When features cost almost nothing, that difference is most of what’s left to sell.

I see it at work. People talk to our product over WhatsApp. None of them care which model answers. They care whether it understood what they meant.

The obvious objection is that agents will design the experience too. Maybe. I think understanding people is slower to copy than code, because someone has to watch real users struggle with the thing, and no tool gives that time back. I’m not sure it holds for ten years.

What I think still holds

None of this means years of experience stopped mattering. I do believe they’re still necessary. There is technical knowledge you simply have to have, and it shows up in two places: in how precise your prompts are, and in the criteria you use to review the code that comes back. An agent will write something either way. The person who knows what a good version looks like asks for it better, and catches more when it’s wrong.

What I notice about myself

When I line the three up, I notice I’m ranking them by fear more than by what I want. Research scares me because the odds are long. Knowing all four lanes scares me because my share of the work keeps shrinking. The third option is the one I think is slowest to copy, which is either a good reason to pick it or a convenient one.

I also notice that every answer I come up with is something a new graduate can actually do. Distribution, data and trust might matter more than any of this, and I have none of them yet. It’s possible I’m choosing my conclusion to fit my position.

For now

I can’t plan a path, so I picked a direction, and I’m holding it loosely. I take features where I own the whole thing, from what the user sees down to the database. I try to watch how people use what I shipped before deciding what comes next. I stopped treating design as someone else’s job. The second option I’m already doing at work, so I’ll find out about it either way. And I keep reading about the first, because I haven’t ruled it out.

I’ll write this again in a year and see which paragraphs I’d take back.

If you see another option that I’m missing, write to me. I’d like to hear it.