🪴 gillchristian

Search

SearchSearch

How will AI impact Software Engineering?

Aug 19, 2026 • 23 min read • 🌱

Notes

I was always a denialist of “No code” and AI tools meaning the end of software engineer as a career. I still believe it will not mean the end but it will have a huge impact in the way we write code and the way we do software engineering.

This is the tweet that changed my perspective:

https://twitter.com/finereli/status/1573547244611305472?s=20&t=4GWCL_4DO09yIUWuTyGtjQ

https://twitter.com/amasad/status/1573375453565681665?s=20&t=TMDq-xDdbWSPcpgYo65NJA

I think it has to do in a sense with something that happens very often. Humans tend to worry so much about a certain thing that they don’t realize when that thing they worry about already became a reality, just it did so in a way they didn’t realize it’s the same thing. Eg. people worry about some future Cyberpunk dystopia where the rich and powerful will be in control. Which is kinda the reality today, minus the cyberpunk aspect of it.

Notes

What came before

We haven’t had any AI revolution before, but we can still learn from history. The industrial revolution is a good example, tools and machinery were introduced that totally changed the way humans produce goods. From manually assembled to machine assembled. The role of the human went from being the tool to controlling a machine. Since the Industrial Revolution the trend of having machines do more of the heavy work continues and keeps being refined. Machines change the things we do not only how we do them

#question how much does a machine operator need to know about the process in order to operate the machine? If developer becomes the machine operators do they still need to understand all the code the machine spits out?

The Technological Revolution (ie. the introduction of computers) brought similar changes, the possibility for humans to achieve tasks that are not humanly possible. Computers enable micromanagement

One interesting thing that happened, specially with manufactured good, is the rise of demand for human and home made goods. For craftsman goods. Sites like Etsy all are about hand made goods. Specially when manufactured goods are of low quality, lack originality and creativity. Will this happen as well with AI generated content vs. 100% human produced content? Will we have “100% human produced” seals in our digital products? What does that even mean? For a chair or a belt it is easy to define, but what about a piece of code or an article?

Higher level code

Dijkstra states that natural language programming will never replace formal language programming because it natural language cannot be formalized. I agree with that.

However, what happens when the productivity of a developer aided by Copilot becomes impossible to process with our normal processes? Will we still have pull requests?

The way we write code today, is very imperative. Some languages like Haskell get closer to a more declarative style. In general, variables are defined and mutated, arrays are traversed.

#question how does a programming language looks like in the age of Copilot?

Something that is still formal enough to be checked for correctness but higher level than today that the inner workings of it can be left to the AI to generate? Maybe we’ll have some AI Script type of language that is the result of the prompts we give to the AI, which will also have a lower level representation in actual JavaScript/TypeScript/Go, also readable and editable by the developer to further improve the feedback cycle.

Now this takes us back to the previous question, how much of the inner workings does the machine operator need to know?

Or maybe coding will look more like an scene from Iron Man where Tony and Jarvis work together than what we do of today, where developers write and read most of the lines of codes involved in their application.

#question what if the process is different, what if we are stuck with our current languages but developers stop verifying the AI generated code and we are stuck in a very optimal local minimum?

#question how do we prevent dog fooding of the AI models that are our pair programmers partners? Is the code they generate and we (don’t) verify a good input to further improve and refine the models? When everybody is using Copilot, does it even make sense to only train the models with human written code?

NOTE: see HyperTalk and Arbor for an example of a higher-ish level languages

#question as the field of programming changes and we shift towards higher level languages and less code tools. Who can become a programmer? Should everybody become programmers? Hamming states that Not everybody can become a programmer, based on a forma definition of programming (Programming is about formal specification). If the definition is more lose, then most of the population has to become programmers (Society went from material goods based to information services based).

Resources:

Learning to code?

All of the before is based on the paradigm of a developer that learned to code before AI and now is adapting.

#question how does programming change when developers are learning to code aided by AI?

In the same fashion, as new developers learn to code they don’t tend to reach out for lower level languages but instead go for higher level languages that allow them to be productive without having to learn all the inner workings of the machine. From Assembly, to C, then C++, then Java and now JavaScript.

And so, with this new metaphorical AI Script, will new developers even learn to code understand the underlying TypeScript?

Programming vs. Software Engineering

Software engineering is programming over time, that’s the difference with programming.

Programming will definitely be impacted, probably for the better (Photoshop for text).

How does software engineering change with the introduction of AI? Will Copilot define the architecture of the application as well? Will it aid us in doing systems design?

Computer are much better at remembering things, keeping tracking of multiple variables, and running simulations. Maybe they will become a good partner in the process of designing a system.

However I believe we are further from reaching that level with AI than we are of having AI do the coding for us.

ChatGPT “thoughts”

C: What is the best way as a software engineer to prepare for the age of AI?

G: As a software engineer, the best way to prepare for the age of AI is to become familiar with the basics of machine learning and artificial intelligence. This includes understanding key algorithms and techniques, such as supervised and unsupervised learning, and knowing how to implement these algorithms using popular libraries and frameworks. Additionally, it can be helpful to stay up-to-date with the latest developments in the field by reading relevant articles and attending conferences and workshops.

C: How will AI change the day to day of a software engineer’s work?

G: AI has the potential to change the way software engineers work in a number of ways. Some possible ways in which AI could impact the day-to-day work of a software engineer include:

  1. Automating routine tasks: AI algorithms can be trained to perform many routine tasks that are currently done by software engineers, such as debugging code or writing simple tests. This could free up software engineers to focus on more complex and interesting work.
  2. Augmenting human intelligence: AI algorithms can be used to help software engineers solve complex problems more quickly and accurately. For example, an AI system might be able to suggest solutions to a coding problem based on previous experience, or help identify patterns and trends in large datasets.
  3. Creating new tools and platforms: The development of AI algorithms and systems will likely lead to the creation of new tools and platforms for software engineers to use. These could include new programming languages, frameworks, and libraries specifically designed for building AI-powered applications.

Overall, the impact of AI on the day-to-day work of a software engineer is likely to be significant, and it will be important for software engineers to stay up-to-date with the latest developments in the field in order to remain competitive.

C: And what would be the impact on software engineering as a discipline? I believe it will change the field fundamental way, like programming languages would look different as well as design system patterns. What are your opinions?

G: It is likely that the rise of AI will have a significant impact on the field of software engineering as a discipline. Some possible ways in which AI could impact the discipline include:

  1. Changes to the way software is developed: As AI algorithms become more advanced and easier to use, software engineers may start to rely more heavily on AI to automate routine tasks and augment human intelligence. This could lead to changes in the way software is developed, including the use of new programming languages and design patterns.
  2. The emergence of new sub-disciplines: The development and application of AI algorithms is likely to give rise to new sub-disciplines within software engineering, such as AI engineering or machine learning engineering. These new sub-disciplines may require specialized knowledge and skills, and could lead to the creation of new job roles within the field.
  3. Greater collaboration with other fields: The development of AI systems often involves collaboration between software engineers and experts in other fields, such as data scientists, statisticians, and neuroscientists. As a result, software engineers may need to work more closely with these other fields in order to build effective AI systems.

Overall, it is clear that the rise of AI will have a significant impact on the field of software engineering. As AI continues to advance, software engineers will need to adapt and stay up-to-date with the latest developments in order to remain competitive.

Dangers of AI

  • Limited creativity and innovation: AI-generated code may lack the creativity and innovation that human developers bring to the table. Whilst AI can generate code based on existing patterns and examples it might not be able to come up with novel solutions by thinking outside the box like humans can.
  • Over reliance on AI: would lead to a decline in human programming skills.
  • Ethical concerns: biased algorithms and loss of jobs due to automation.
  • Security risk: AI generated code might introduce vulnerabilities which would go unnoticed given the sheer magnitude of productivity gained by using AI and the decrees in skills of the human developers.

Journal / Notes on …

2025-01-31 ~ Cursor

DeepSeek announcement made me wanna try Cursor. Enjoying the experience so far. Definitely way better than Copilot, which was only good to do less typing on the repetitive stuff. I do find myself reaching for its different editing features even for simple things that I used to be able to do very quickly and efficiently without putting any thought into them. And in some cases the result is slower than if I had done it myself.

I remember finding it odd that my dad lost the ability to drive around without a GPS when he started using Google Maps, even for directions to places he’s actually very familiar with and traveled his whole life to without even a map.

I’m three days into using Cursor and I’m already experiencing the same.

Also, embedded AI tools are way better than the general purpose chat bots. Until now I was reluctant to try other tools, I adopted ChatGPT Pro relatively early and stuck with that. But now I see how much powerful it is to bring the LLM over into the editing tool. I’m sure there’s much more potential and whole other paradigm shifts waiting to happen (Paradigm shifts in development) in the way we write code (and more generally write/create/think I guess), yet Cursor already feels very well accomplished and, I dare to say, novel or innovative.

Back to the point above. I believe the net result is more productivity. Specially on the type of coding I’m doing these days that requires a lot of back and forth and exploration. But there are many a moment when I end up being less productive just because I’m using the tool. For things that’d take me less time to edit/write them myself I end up still writing a prompt and have the AI do it. Is it maybe because the editor is not completely the one I’m used to?

#question Is it a paradigm shift or not? Paradigm shifts in development …

2026-02-12 ~ Claude Code

My usage of Cursor evolved quite a lot during the past year. From editor heavy, relying mostly on the tab feature: an autocomplete on steroids greatly reducing typing, specially of repetitive stuff that is mostly similar but not quite. To chat heavy: using it for code exploration, writing tests, and implementing larger features across several files.

One thing remained, Cursor is a text editor. The lens to the code I’m writing—am I writing the code or is the LLM— was still the text editor.

For the past three weeks I’ve been using Claude Code. In terms of capabilities, it is basically the same thing but scaled horizontally. Specially because Cursor already supports Opus 4.5 (and 4.6), which was my model of choice for the last couple of months. I did try something new, writing small applications from scratch.

  • Cadence
  • ScriptureStudy ~ re-write of the frontend
  • A tool to clean up dev envs by checking whether the deployed branch and/or ticket has already been closed.

However—this might be the actual paradigm shift—one key piece has changed considerably. The window to the code I’m writing is not the editor anymore. Claude Code is solely a chat tool. It does have some extra features on top, like showing diffs and what not, but the “thing” I look at first now is natural language. I still fire up my editor, sometimes it’s still Cursor (gotta have that tab completion) sometimes is my beloved nvim, but that is mostly for small-ish fixes and navigating the code I’m about to ask Claude to edit. Even when it comes to looking at the output of Claude’s work I use git diff (CLI and GitHub’s).

2026-07-22 ~ revu

Let’s brainstorm on how the steps are constructed. I think we need to fine tune the prompt to get better results. But before we make changes to the prompt, let’s think a bit about what the goal and philosophy of the project are.

Software engineering is defined as programming over time. A programmer writes code. When the time variable is introduced, we are now having to maintain it. That means it’s not only about the fresh new lines of code but rather how the code evolves. This implies architecture of the code. One cannot just change it without any sort of plan. It also implies, though not necessarily, more than one person working on the codebase/systems. It implies some sort of infrastructure where those systems live. It implies interactions with the drivers of the product, that is those who decide what is being built to serve the interests of the clients, whether those clients are paying customers or just free users has some impact but not as much.

Code review served as one of the points in time when the team came together to make sure we weren’t just merely writing code but rather practicing software engineering.

The cadence of code writing and code reading was more or less one to one. Members of the team wrote and read code at the same speed, so the could all progress together. You’d write some code, read it, get your colleagues to read it, make some changes, and ship it.

In practice reading was even faster than writing. But I’d say it was around a very similar order of magnitude.

That whole process had a quite unexpected side effect, understanding of how the codebase evolved, which is probably the slowest of the pieces, progressed alongside the code just fine.

Enter LLMs. In the last couple of years, the process of code writing has been sped up by LLMs entering the scene. And we are now at the point where the code writing is largely done by LLMs. This has a lot of, let’s say unexpected, side effects.

But I would argue that maybe the main one is the balance between new code being written and the understanding how that code evolves has been broken. Code is now written orders of magnitude faster that it can be read, let alone understand.

The 17k lines PR I keep referencing is equivalente to 350 to 400 pages of a book. I know code doesn’t read in the same way as a book, but still it’d take quite a while to go through the whole thing.

I’ll give you that this particular PR is an outlier, we are still trying to keep PRs small, however that doesn’t change the fact that LLMs can write 10-20k lines of code a day and someone has to review them, even if they are split in PRs of 1-2k lines.

Not all teams rely heavily on code reviews, some don’t do code reviews at all. But even then, at least one person wrote the code and could be said to have the understanding of it. Now that human are not the ones writing the code there’s no single person with an understanding of this new code in the team.

I’m tempted to keep rambling about the problem. There’s a big difference between the understanding one develops through reading and writing. And that is even more so in code. There are plenty of decisions that one takes when writing code, it’s the whole process of solving a problem, making the choices that would be correct, the necessary trade-offs, and so on. All of those are much more, if not only, internalized when the code is written by the person doing the writing.

In my own side projects I haven’t been doing code reviews at all, that has worked out quite well. The LLM agent is fully autonomous in writing the code, testing it, deciding it fits the criteria and shipping. However, these are all small side projects, one could argue they are just programming, since the (over) time variable hasn’t been introduced just yet, thus they aren’t software engineering.

The flip side of all of this is there are great performance benefits to be unlocked by writing code orders of magnitude faster. I see it at work everyday, the stuff I’m able to achieve by working with LLM coding agents is way more ambitious than it was before. But the potential for introducing bugs and for taking the wrong architectural direction grow at least linearly with the amount of code introduced, maybe even exponentially.

And this newfound speed in code writing is also challenging some of the principles that governed programming until now. The agents that write code can also read and process tremendous amounts of code easily. However, their memories doesn’t work in the same way human memory works. Either something is in their context window or it isn’t. All of this favors much more verbose and explicit code, rather than code that is lean and abstracted for reuse.

All code, regardless whether it is human or LLM authored, has some ratio of signal and noise. But LLM written code is even more noisy. There’s nothing inherently wrong with that, it’s just different. It’s optimized for how LLMs operate. Before we were optimizing for how human brains work.

Reading through the whole list of changes by alphabetical order of files, the good old code review way, doesn’t work anymore. Something has to be done so that we can leverage the boost in delivery speed while remaining confident that codebase growth stays within the realm of comprehension of the members of the team.

Revu is an attempt to deal with that problem.

I used Revu in a few PRs already. The UI we’ve built is perfect for the phase of the project we are at. We’ll evolve it later, to get an even better UX. However I don’t believe the problem we are dealing with is an UX problem per se, so let’s get to back later.

But the way the prompt is working, which I’ve turned into a skill for Claude Code, is not producing the results I want.

One insight I draw is that maybe I’m working around or making up for not structuring my changes in a way that would make up for small commits that would tell the story of the changes. I need to get back to that idea. Maybe Revu should be commit aware. Still that’s not the direction I want to take just yet.

I should point out that I use the latest Opus model and Max thinking mode for my code writing and also the produce the review manifests.

What I noticed is that Claude Code tries to cover all the changes in the list of steps it generates. This is exactly what I don’t want the review manifest to be. There are plenty of changes that can be ignored, or at least given way less weight.

Let me give you a few examples.

  • If the code introduced a new endpoint, I know that Claude Code will wire it correctly, and if it didn’t I already noticed by executing the code. So what I want to see for the new endpoint is the body of the handler function.
  • If I extract a big component out from a page into a standalone, reusable component, I might want to only see only the new file, and maybe the lines where it used in the old place. I can skip all the removed lines, for example. I might want to even skip most of the new lines, aside from maybe the signature and types that are new defined (which weren’t needed before when the code was inline somewhere else).
  • At work we use a tool to validate SQL queries against the DB, those produce cache files in JSON. If an SQL file is added or changed, there will be an accompanying JSON file which is never read by us when doing code reviews.
  • Similarly, lock files (Cargo.toml.lock, package.lock.json, etc) are never read in a code review.
  • Generated files, such as API clients, are skipped most of the time, same as formatting-only changes.

These are all examples of noise on a code review. There are other tools and processes dealing with that, directly or indirectly.

There are two things I want to do to start addressing this:

  1. Update the spec of the review manifest to support including files in a step that are related to what the step is trying to highlight but of a lower weight. And I think those should be collapsed by Revu. This implies support for collapsing files (toggleable so I can still expand a file, and also collapse the expanded ones). There are some files that it’s only important to know they were changed, not what. Eg. the JSON cache file for an SQL file in the example above.
  2. Instruct, through the code review manifest prompt, coding agents to prioritize only code changes that are relevant to the full picture of what is being changed. They should also fully skip stuff that is purely noice. Eg. a file that was just formatted, a lock file, etc.

2026-08-17

More and more I’m just having Claude Code do the code writing, reviewing, etc.

By introducing automation/robots into the process changes what we do, not only how we do it. Screws and bolts became rivets and welding see the notes connected to this.

The idea of a Knowledge Base as the driver is fully settled as the way I write my code. I need a name for this pattern.

Also I need to explore the idea of more autonomous coding agents in the Dark Factory style. One thing that worked form me this past week, which was a very little step in this direction, was creating an .agent-lock file and telling the agent to delete it with done and the other agent to only start when the lockfile was deleted.

Graph View

Backlinks