Skip to content
Muhammet Şafak
tr
Journal 9 min read

The first question at the meetup: has AI ended software development?

AI ended writing code by hand at the keyboard, not the developer. What's over, what remains, and how a new graduate gets through a narrowing door.

TL;DR

AI ended writing code by hand at the keyboard, not the developer; the value now lies in describing the right system, in domain knowledge, and in taking responsibility. For a new graduate the door is narrow, but the person who gets in is valued highly.

Cover — on a dark background, Tan the beaver sits between a violet neural-network brain and a glowing keyboard, writing in a small notebook with a pen

At a small developer meetup, the first question was the one on everyone’s mind in the room. My answer was neither yes nor no: AI ended writing code by hand at the keyboard, not the developer. The difference is best shown by a payment system built in half an hour.

All the questions that evening revolved around the same worry: will what we’ve been learning for years still be worth anything? I gave short answers in the room. In this post I’m gathering those answers, along with examples I didn’t have time to go through there.

In short: what AI has taken over is the keyboard. What remains is describing the right system, knowing the domain, and taking responsibility for the outcome. The industry has shrunk, and I won’t hide that. The door is narrow, but the person who gets in is valued more. If you graduated this year, there’s a concrete list at the end of the post on where you can get in.

Has AI ended software development?

Last year I said “it hasn’t”; let me be more precise: what it ended is the keyboard.

The answer depends on how you define a developer. If the word brings to mind someone who writes code line by line, by hand, at the keyboard, my answer is yes. In my observation, that break happened about 9-10 months ago. Today I don’t write most of the code in my own work by hand; I describe it, read it, fix it. My hours at the keyboard moved to pinning down what I want and reading what comes out.

If the word brings to mind the person who works out the requirements and the roadmap for solving a problem, my answer is no. AI isn’t at that level yet. Its role in this work is to be a tool that speeds things up enormously: the moment you decide what to do, it cuts the doing from hours to minutes. Deciding what to do is still on you.

I also have to say this honestly: over the past year I’ve seen the industry shrink. The teams around me are getting smaller, when someone leaves they often aren’t replaced, and junior postings have dwindled. I’m not basing this on statistics but on what I see in my own circle; still, the picture is consistent.

So what has ended isn’t the profession, it’s the profession’s most visible manual skill.

Why do companies still employ developers?

The payment system built in half an hour shows where the work that left the keyboard went.

Getting AI to build a payment system for your site takes 1-2 prompts and half an hour of work. The payment provider’s SDK gets wired in, the payment form appears, the first payment with a test card comes back successful. The demo works. Can what comes out be called a payment system?

My answer: not yet. A payment system isn’t one where the happy path works, it’s one where the unhappy paths are anticipated too. In the half-hour version, these are usually what’s missing:

  • Idempotency. The user presses the button twice or the network request is repeated; the same payment is charged twice.
  • Webhook ordering and repetition. The provider can send notifications out of order and more than once. If the refund notification arrives before the confirmation, or the confirmation is processed twice, the order status breaks.
  • 3DS timeout. The user waits on the bank verification screen and the session times out. Whether the order was paid or not, nobody knows; the order is left hanging.
  • Declined cards. A declined card, insufficient funds, suspected fraud. Each requires a different message to the user and a different behavior from the system.
  • Partial refund. One item from a three-item order is refunded. If the amount, tax, and shipping share aren’t calculated correctly, the accounting records won’t match.
  • Reconciliation. At the end of the day, your records are compared against the provider’s report. Even if the difference is a few cents, someone has to explain it.

None of these is something AI can’t write. If you ask, it writes them, and often writes them well. The point is knowing which question to ask. There are two sources for knowing those questions: experience and domain knowledge. If you haven’t lived through a night when a webhook arrived twice, it may not occur to you to add it to the prompt. If you don’t know how accounting closes the day, you never ask about reconciliation.

What I’m criticizing here isn’t a person or a level, it’s a behavior: merging the output without reading it. Being a junior is not a flaw; everyone starts somewhere. The flaw is shipping generated code to production without understanding it and mistaking that for speed.

The third reason, and I think the heaviest, is responsibility. When the double-charge alarm goes off at 3 a.m., someone has to wake up and look. For a refund sent to the wrong account to be reversed, someone has to talk to the bank. When the auditor asks “why did this money go to this account?”, someone has to answer. “The AI wrote it that way” is not the answer to any of these questions.

I can sum up my own stance in one sentence: I have AI write the code, but I’m the one responsible for it, and I’ll keep being that person. Companies buy the model; they hire the person who will answer for it.

Can an unskilled person do the same job with AI?

How much you need someone to answer for it depends on the risk of the job. That’s why the answer to this question isn’t singular either.

For some jobs, yes. Someone with no software background can today use AI to produce a personal site, a small tool for their team, or a prototype that tests an idea. I don’t belittle that; it’s exactly one of the best things about these tools. What draws the line is what happens when the work breaks:

RiskExampleIf it breaks
LowPersonal site, internal team tool, prototypeIt’s reversible; the loss is a few hours of time
HighMoney movement, health or personal data, the infrastructure of a 100-million-dollar data centerMoney, data, or trust is lost; someone answers for it

On the low-risk side, an unskilled person really can do the same job. On the high-risk side, the real job isn’t producing code, it’s knowing what the produced code could break. I can’t imagine a company handing the infrastructure of a 100-million-dollar data center to someone who can’t explain what they’re doing, no matter how fast the code was written. I covered this distinction in more detail in the post where I explained the difference between vibe coding and AI-assisted development.

As the risk grows, so does the need for someone who understands the output and owns its consequences.

Is AI dangerous for this industry?

The need for someone to carry the responsibility continues; the real problem is the narrowing of the door that trains that person.

My answer to this question at the meetup was: we may be the last foot soldiers of the developers who learned by writing code by hand. The last generation that learned by writing code line by line, debugging, making the same mistake three times. What’s scarce becomes more valuable; seen from that angle, it’s not bad news for us.

But this is exactly where the danger for the industry begins. The real danger isn’t AI writing code, it’s developers who know what they’re doing not being trained. When teams don’t hire juniors, the places to learn the craft shrink too. Today’s seniors grew up in teams where, years ago, someone gave them room to make mistakes. If that room closes, where will the person to look at that 3 a.m. alarm come from ten years from now?

Telling new graduates “get in” after this thesis may look contradictory. I don’t think it is. The door has narrowed; but the value of the person who gets in rises for exactly that reason.

If you graduated this year, where should you get in?

The door has narrowed but not closed; the person who gets in is now valued more. The question is where you’ll get in.

The tractor didn’t end farming, it changed the farmer. The number of people working in the field fell, the work of those who remained changed; new professions were born to build, repair, and run the machines. AI is doing something similar to software. But I won’t hide this: the transition isn’t free. When the tractor arrived, the ones who paid the most for that transition were those trying to start work in exactly those years. You’re in that generation. Moving with that knowledge is better than waiting without it.

My suggestion is that you look in these directions:

  1. Learn the craft without having AI do it. Use AI, but deliberately do part of the work by hand: a data structure, a debugging session, a query plan. You can’t review code you can’t read.
  2. Infrastructure, GPU, and systems. Models run somewhere; setting up, scaling, and managing the cost of that place is a growing job. That’s why Linux, networking, container, and hardware knowledge are gaining value.
  3. MLOps, eval, and reliability. Measuring a model’s output, catching regressions, monitoring in production. Every company using AI needs an answer to this, and few people can give it.
  4. Domain knowledge + software. Payments, healthcare, logistics, energy; a developer who knows any field from the inside can ask that field’s right questions. The payment list above is an example.
  5. Network. In a period when postings are shrinking, doors are often opened through people. Go to meetups, contribute to open source, write about what you learn. A recommendation from someone who knows you can open the door that postings don’t show.

New jobs are also emerging on the data center and energy side; but I see that as a side path, not as the main door that will replace software development. I’ll write separately about the difference between running a local model and using an API, and its cost.

Can you explain the code AI wrote for you?

All the questions that evening arrive at the same place through different doors. AI writes the code; describing the right system, knowing the domain, and owning the outcome are still a human’s job. Without these three, code you had AI write becomes someone else’s 3 a.m. alarm one day.

Open the last piece of work you had AI do and ask yourself: if this code breaks in production, can I explain why? If the answer is no, that’s exactly where you need to learn.

If you have a question that wasn’t asked at the meetup, you can send it to me through the Just Ask page.

Comments

Sign in with your GitHub account to join the discussion. Comments are stored in GitHub Discussions.

Related Posts

Search the site

Start typing to search posts, projects and pages.

Esc to close Powered by Pagefind