How software engineering is changing

October 21, 2026

This was written for the Pragmatic Engineer essay challenge.

I’m starting to write this as I just finished a /grill-me session with Claude Code Opus 5 running in a tmux session on my university’s cluster; once I approve the plan, it’ll get posted to the GitHub issue and I’ll wait for the draft pull request.

After surveying other PhD students in my university laboratory, I’ve determined that I use AI more than older students. They still manually accept edits, I do something more like spec-driven development with subagents. I often get this phantom feeling that one day the jig will be up, that my use of AI will result in a spectacular failure and I’ll have to reduce my level of automation or actually get more comfortable coding by hand. But it’s just… working out?

I have no context on the industry before AI. I had a budding interest in coding and was 10 days into a Python bootcamp in 2022 when ChatGPT came out. Everything since then, from becoming a software specialist at a marketing agency, to entering a CS transition degree, and now starting a PhD in machine learning, has been under the spectre of growing capabilities of agentic coding. When industry people express concern that juniors won’t actually know what their code does or simply will never learn the fundamentals necessary to code without AI, I am who they’re talking about. I’m part of the first cohort who does not remember a time before AI programming and could not reasonably work without it.

In this essay I’ll walk through how I got into software engineering from a previous career, and why I leaned into it as AI tools got better rather than thinking twice about the career switch. I haven’t experienced previous waves of innovation like more senior engineers, but hopefully I can answer the question of what software engineering should be without pinning it down to what it might have been before AI.

Early era, 2022-2023

I worked in marketing right after my bachelor’s degree in business at a mid-sized agency in Montreal. In those first few months, I had a decent amount of downtime, and I found myself gravitating toward coding. The vast majority of my job was copywriting for ads at that time, and I wanted to exercise my technical skills. I enrolled in the Udemy 100 Days of Code class. That was October 2022. ChatGPT released at the end of November.

The reaction to ChatGPT was pretty immediate at our advertising agency. Even though GPT 3.5 would be considered primitive today, it entered the workflow for a lot of basic copywriting, mostly because of how easy it was to use. This was the era when a few LinkedIn influencers pulled the stunt of, “ChatGPT wrote my last post, and nobody noticed”, which was more an omen rather than of actual economic value, because many VPs and C-suites on LinkedIn don’t manage their own LinkedIn; their PR agency does. Billable hours are how the business stays alive. The main argument against this business threat was that a competent professional needed to finish the work from an AI-written draft and deliver it to the client. How could skilled professionals prompt LLMs to get as close to the finished product as possible? Software engineers who noticed the early capability of ChatGPT to spit out code took a similar line of thinking and coined “prompt engineering”.

This led to an initiative in our agency which tried to craft the perfect prompts to turn ChatGPT into a press release drafting machine. The GPT 3.5 API had just come out, and these were the very early days of RAG, which mostly involved doing some sort of web or database search and appending the results into the prompt. We could build a bespoke prompt loop that would accelerate the process to a finished release to be sent off to journalists.

I volunteered for the initiative with my rudimentary Python skills. I knew two CS grads who had had their offers delayed at Amazon, hired them, and went to build what was basically a GPT wrapper with a search API. During this project, my workflow was mainly a ChatGPT Plus subscription and copious prompting into GPT-4. I would paste in a chunk of code and whatever error message I was getting from my terminal and receive a new chunk of code. Copy, paste, run. Copy, paste, run. I was an agent harness before it was cool!

At that time, Stack Overflow was still somewhat useful, as were the OpenAI developer forums, because GPT-4 frequently gave its best guess for the answer, but often got the diagnosis wrong. I frequently would start a new chat, tweak the available information (paste some Stack Overflow post), rule out causes we had investigated, etc. and hope that it would very confidently give me the right answer. I’m pretty sure other software engineers were getting stuck in this loop too, because the “prompt treadmill” was coined around this time. There were many days I found myself furiously trying to diagnose a crash in AWS or a fail screen in the application, sometimes for hours at a time. It was a pretty anxious way to work that was only mitigated by the fact that I was young and experiencing a builder’s high.

On the product side, it was painfully clear at the time that APIs serving LLMs were not production-ready. Their downtime was significant, and their token throughput was incredibly low. Despite explicit instructions to output valid JSON, GPT failed a good chunk of the time which caused our regex to fail to parse the response and return an error. Output speeds were extremely unreliable and so was the uptime. I remember one event in late 2023 or early 2024 when French accents on letters (é, à, ç, etc.) were replaced by an escape character, causing the output of models to truncate. It took OpenAI several days to identify the issue and simply told developers to pin an old snapshot of their models.

I knew that we had made some terrible, GPT-flavoured design decisions during development: the total size of our application was several gigabytes due to a bunch of NLP dependencies we barely used, we launched on AWS Elastic Beanstalk and paid for 24/7 runtime despite having almost no traffic, we used Flask despite wanting to dynamically load elements more like React. The app was shipped as a monorepo where the login page was part of the same runtime as all the vector database stuff, so if anything broke, the entire application including the landing page went down. I still get stressed when I see “502 Bad Gateway” in my day-to-day life. The project was badly designed as a consequence of both the models being bad, but also because I had no taste for how to steer them. “Prompt engineering” made me feel like a hotshot coder, but then the “prompt treadmill” would crush my dreams. I knew that there were systems and fundamentals at play that were still important in spite of AI. I left the marketing agency for a CS degree.

2024: Entering a CS program

By the time I got into a CS program, although this Pandora’s box was opened, AI was still not good enough for entry level courses. My first classes were in Racket, a spinoff of LISP, logic gates, time complexity, and C. AI did more harm than good in these classes, maybe due to their obscurity relative to javascript and python, and even if it was good enough, I probably would not have used it extensively. Take-home assignment grades for CS courses are pretty much near 100% now, but midterms and finals crush those who took a shortcut. I hear many stories of companies today where engineers are forced to ship as fast as possible with AI and in contrast, I felt like my learning was safeguarded and rewarded in university.

AI did completely change hackathons. I did one in my first year and we spent the 24 hours all furiously copy-pasting into ChatGPT. We used a javascript framework for 2D games called Phaser.js that none of us had used before. There were no harnesses at this point, but given the deadline, there was no chance we were going to read docs and work by hand. We ended up winning (the game is still up). It was honestly nauseating and not very fun. This was before agentic tools took off and maybe the experience is better, but I did not do any more hackathons. They’re all vibe-code-a-thons now.

2025-2026: First internship

I landed a SWE job for Fall 2024 through co-op at my university. Funny enough, I got placed on their agentic workflow team because they had seen my AI project from my marketing agency job.

For this company, their agentic workflow, which predated Model Context Protocol, was having a Claude model output tool calls that could fetch information or even modify elements inside a dashboard, thanks to some Java Spring magic. The company was betting big on this “AI agent” that would eventually adopt personas and job roles across their SaaS products. It was my first exposure to how engineering was changing at a respectably mid-tier software company with pro-AI leadership.

When I joined, the default enterprise solution was GitHub copilot. It had an Agent setting, but I found it often got caught in search loops, and so I used it the same way I had in school and at my prior job. Dump a bunch of context, inspect the outputted code, paste it in manually, wait for results, repeat. It was definitely helpful, but it was often wrong and couldn’t handle long horizon tasks with much success. Our team was also testing out amazon Q developer, which was the first CLI-based agentic coding platform I tried. I had heard some developers using Claude Code for their side projects.

What happened next is well-known in the industry. Somehow, during the end of December 2025, everyone had decided to move to Claude Code. My company moved really fast; our Github copilot was cut off by mid-January 2026. Claude Code was just significantly better, and faster. Although I had begun to ramp up and my ticket completion pace was improving, I definitely felt Claude Code improved my workflow, and compared to other models, it was more right and lied less. At the time, I had the Gemini CLI (rip) for free as a student, and I was using it in a course solely to prepare the LateX for assignment submissions. This thing ignored instructions, changed my answers to questions and in one case actually erased my entire assignment. Cursor was like commanding a hyperactive child; blindingly fast but reckless. It was amazing in Winter 2026 just how far ahead Claude Code seemed.

Very useful was JIRA’s MCP at the time which could pull all our ticket details directly into context. No more copy pasting! Claude Code became the main driver of my productivity from triage of a ticket to implementation. But I still felt like I was in the loop. One of the key quality control mechanisms at our company was the standup meeting. I learned that no matter how much of my code was being Claude generated, I needed to be able to explain and defend my solution to senior engineers who had often designed and built the codebases I was now Clauding around in. I felt like respect was due to the architect sitting around the table at standup. I’m not sure what the rules are when codebases are no longer hand-written by fellow engineers. How much will seniors know their authored code? I’m guessing that hand-written code will still be the majority in some products in 5 years, but it’s just a matter of time.

In the case of my final intern project, I actually felt like I couldn’t use Claude Code alone. I had to do the technical analysis for the project and scope out all the work. Writing the tickets was probably the hardest part as they had to contain all the architectural and design choices and they had to be good enough such that any one on the team could pick them up in a sprint. UML-style diagrams I had learned from CS courses actually ended up being the best way for me to internalize and present my design, which is a manual task I still do today. I think that having AI tools for whiteboarding that automate diagramming new features or mapping out a codebase will be its own killer niche (there seems to be a Y Combinator startup for this).

I read a few articles about some tech leaders who worried about junior engineers stunting their development with AI. When I asked Claude about this, it told me to “not use AI when I’m trying to learn”. But I found that to be a terrible answer. I liked AI for its search capabilities and if anything, helping with syntax. How much was too much? Our company used React/Typescript for their frontend and with only a month left, I realized I basically did not know the language. Part of this was that I didn’t like frontend. What helped me was a mid-level engineer who pair programmed with me sometimes. She’d ask me great teaching questions like how I would pass in parameters through the header of an HTTP request, just to make sure I could do it by hand. So I managed to make some progress in that last month by modelling her style and being EXTREMELY explicit about Claude not giving me answers, being my tutor, and asking me leading questions about the code. The “learning” mode of most of these harnesses I found to be awful, and I don’t even know if they’re shipped anymore.

Other things I noticed firsthand at this company:

Present and Thoughts on Software Engineering

Now I’m a PhD student in machine learning. Alongside my SWE internship, I had been slowly building up fundamentals for deep learning, and that’s what I’m doing now. I’m taking grad courses while working on diffusion world-action models and browser-use agents.

In my internship, I worked on the full-stack implementation of AI infrastructure, and now I build the models. Through this world I’ve noticed that AI startups raising money in Silicon Valley use their raises mainly for GPUs. On a $50M seed round, they might hire a team of 7 or 8 PhDs and save the rest for the training and inference costs of their models. Why do I bring this up? The CS job market has been rough for juniors since 2023, and as new companies are concentrated in AI, it’s worrisome that headcount is so low. Other companies seem to be embracing the AI engineer or the forward deployed engineer, which could be considered the natural successors to SWE. My read is that traditional software engineering will continue to be unstable, and many good and talented people will feel the crunch as their skills get re-valued. It’s not their fault, it’s not what they signed up for, and it’s not what they deserve. But when I made the career switch into tech, I basically decided that I’d do what it takes to make it, hence the PhD. It turned out along the way that I love machine learning and I’m very excited for the future of the field, even if software engineering roles are succeeded by new ones.

How is software engineering changing because of AI? Personally, I think the biggest shifts have already happened, at least for a while. Most engineering teams are saturated at near 100% adoption of harnesses, and while some companies, especially startups and frontier labs are trying to stretch just how many subagents, loops and tokens they can use, I don’t see that as feasible for the vast majority of companies today. During my internship, scoping out work from our backlog and product roadmap required a ton of hands at the table, often being as much about human relationships and pressures within the organization than about an optimal programming implementation.

Maybe Agile will become less popular. Maybe on-call will be rethought. Maybe programming languages will consolidate around the ones AI is good at (it probably already has). Not to sound hand-wavy about the human experience, but the organizations I’ve worked in have centered around human interpretability, and that characteristic may not be alleviated by firing a lot of people and spreading the remaining ones thin. The desire for control might lie too deep in human psychology. A senior engineer I chatted with recently told me that a good junior leaving school now can expect to have the skills of a staff engineer thanks to AI. Not everyone wants to be a staff engineer, and that’s fine. But I won’t mourn the industry or profession that is now gone. I’m pretty confident that I’ve found a balance between designing an implementation and letting AI do the work. Crucially, I can explain what my commits to, and I can discuss at length with a senior engineer or fellow PhD student the problem in front of me and think really hard about tradeoffs. That is what I think software engineering should be. We should be building systems that are still interpretable, explainable and shareable between humans. If AI makes everyone a manager, then that’s the new skill that will unlock value in this field. I feel myself thinking more like an engineering manager and I definitely still feel like it’s a long, difficult growth with a ton of focus and persistence required. And it’s still incredibly fun.

Epilogue 1: My Workflow

I don’t want to be more out-of-the-loop than a legitimate pre-AI software engineer. Right now, Matt Pocock is my baseline. I use a variety of his skills and my current workflow is inspired by a workshop he gave at AI Engineer Europe. I don’t want to be a vibe coder. I will have returned to school for four years to become technical and I believed going in that there was enough technical foundation in the education to make me categorically more valuable in software engineering than someone non-technical. Though acknowledging my confirmation bias in justifying the sunk cost, I still believe that to be the case.

I use Claude Pro and though I’m throttled by usage limits, I believe that this is for the best because having more usage available would probably lead to more code volume that I can’t review.

I don’t want to get grilled by my academic supervisor. If I present an experiment with novel results and I can’t withstand a lengthy technical grilling session on the implementation, then I’ll embarrass myself. Therefore, I usually spend a few hours backfilling my understanding of changes AI made on the work I plan on discussing with my supervisor during our meeting. I wrote a commit-review skill that loads each commit into a local diff in VSCode, then I can make changes and fold them into that commit on the pull-request.

Sometimes I will kick off a plan or give Claude instructions before leaving work at the end of the day and wait for the runs to land in wandb as indication that it was completed.

Epilogue 2: Am I sad that real programming has gone away?

Not really, I can’t miss pre-AI programming because I never lived it. I did quite like my CS courses and found programming using just my brain to be very satisfying. The difference is that my hand-typed assignments at school have artificial value created by the environment. In the real world, I just don’t see my hand-typed code as valued enough to be worth the time investment, unless it’s strictly for learning. Some might argue that the point of internships is not to be valuable, but to learn. But interns want to be valuable to get return offers, and contributing as much as you can feels good. In my experience, even when I have no performance metrics such as in research, I still choose AI. Therefore, I can’t say that someone is forcing me to use these tools. I choose to use them and try to strike a balance.