“Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” — a quote attributed to Greek mathematician and physicist, Archimedes.

Archimedes' lever (image credit ¹)

I vividly recall my early days of programming: the dopamine hits after seeing my code successfully compile and my program run; the thing that I imagined suddenly coming to life on screen. Programming was difficult and knowledge hard-won, perhaps due to my skill level at the time and the fact that documentation and guidance were not so readily available.

These were the days of 56k dial-up, GeoCities and Quake III Arena. Websites were individually-crafted and online communities were mostly decentralised. Programming knowledge was dispersed across small and dedicated websites and communities. Then came the rapid proliferation of open-source software and Stack Overflow's arrival, which changed the scene again, centralising programming discussions, better disseminating knowledge and example code.

The world looks very different now and the landscape is shifting dramatically once more. A pivotal moment arrived in 2022 with the release of ChatGPT, the generative artificial intelligence (AI) chatbot from OpenAI, which is based on their Generative Pre-trained Transformer (GPT) Large Language Model (LLM).

While the initial implications might have been hazy, with each subsequent advancement, the power of LLMs and their place in our future is becoming clearer.

Cognitive bias and the creative identity crisis​

The "AI effect" describes how, once AI researchers accomplish a task previously considered indicative of true AI—such as defeating a human at chess—the definition of genuine AI shifts, often relegating the achievement to mere logic or "just maths".

I think part of this stems from a potential creative identity crisis and a tendency to want to hold onto skills that feel uniquely ours. Imagine you've spent your life mastering a craft or some creative art: a studio photographer, a professional song composer, a podcaster, or a writer. Generative AI can create incredible photos, incorporating subjects (products, people, etc.) and beautiful, lifelike videos, resulting in AI-generated adverts and fairly convincing movies (see Kitsune). It can create music of all different styles, write academic literature reviews, poetry and stories. It can create convincing podcasts with multiple hosts who sound real and discuss source materials of your choice (like for this article, courtesy of Google's NotebookLM).

“AI slop”, you say? Perhaps sometimes but the power and quality of generative AI is advancing quickly, to the point where it is a challenge to keep up, and we are still working out how to make best use of it. Progress is set to continue given the incredible competition between the key players, like OpenAI, Google, Meta AI and Anthropic. We're no longer rendering human hands that look like spaghetti and with too many fingers.

A common argument is that LLMs are just statistical models, predicting the token that is most likely to follow the previous tokens, over and over. Behind the glossy chat interface, the main ChatGPT API method is called Chat Completions (e.g. POST https://api.openai.com/v1/chat/completions), which has connotations of predictive text completion more than real intelligence. This is true but misses the point and does not diminish the utility of LLMs.

In fact, the brain and LLMs work in somewhat similar ways, both by forming connections. In our brains, it is neurons communicating and adapting based on learning and experience. In LLMs, it is a vast number of parameters that are adjusted during training, based on huge amounts of data. When we prompt an LLM, we traverse these connections, like the sparks of electrical activity that dance across our brain's neurons.

As humans, we can dream up amazing innovations and novel ideas with true soul, but how much of what we produce is truly original or innovative? Many songs are composed of the same key chord progressions and only occasionally do we hear a song that truly stands out. Film scripts often repeat the same tried and tested storylines. Taking these "building blocks", whether these are notes or audio frequencies that form melodies, pixels that form images, words and characters that form source code or a natural language, and knowing how to arrange them to achieve a particular goal or effect is often what matters. And that is what generative AI seeks to do.

We need to remain mindful of these cognitive biases and emotional responses when approaching new developments in the field of AI, otherwise we risk overlooking or misunderstanding an incredibly useful technology.

LLMs and software engineers​

It turns out LLMs can write code and they are reasonably good at it, when provided the right prompt and context. If your role is to take on small and very well defined tickets and simply translate these into small code changes, then your job is ripe for disruption.

If we feed an LLM a prompt with the relevant context—parts of or all of the codebase—and clear instructions like: “Add a new ‘birth_date’ database column to the ‘users’ table of the Date type, which is nullable and has no index”, then our LLM-driven agent will probably produce the correct result and will even raise a pull request.

I notice a general trend of pessimism in online communities, particularly LinkedIn and X (Twitter), where we are told by influencers, not engineers, that this is the end of programming and software engineering. These comments tend to attract a lot of attention and clicks, devolve into arguments and generate a lot of circular discussion and noise, which is probably their intended purpose. I have a different and more optimistic take.

Much like the cranking of Archimedes' imaginary lever, LLMs let us amplify human effort to produce superhuman results and for everyone, and especially software engineers, this is an incredible time to be alive.

As software engineers, we already had great leverage. We can create and deploy an application or service and affect millions or billions of users, creating huge value for businesses and individuals and potentially changing the world. Armed with an LLM, individual software engineers and teams can now move even faster. Even better, and much as I enjoy software development, we can offload some of the drudgery and tedious work that we battle and that takes our focus away from what really matters. Maintenance work like fixing breaking API changes after a package upgrade might fall entirely to an LLM-based agent, and we can focus on the more exciting, novel and meaningful work.

There has also never been a better time to start a side hustle. The LLM will empower software engineers to start one-person companies and exceptional engineers will now produce even more exceptional results. Some of these companies will disrupt the slow-moving incumbent companies, operating with leaner teams and tighter margins, increasing competition all around.

Renewing our focus​

With one bottleneck reduced—the gap between the concepts and design in our minds and the resulting source code on our screens—we must shift our focus to hone our other skills and to tackle the remaining bottlenecks, which include:

• collaboration, communication, leadership and other soft skills
• business and domain knowledge
• product and systems thinking
• critical thinking and problem solving
• problem decomposition
• deep technical understanding across the stack
• prototyping, creativity and innovation
• testing and test automation
• debugging
• optimisation
• data management and analysis

And we are fortunate that LLMs can support us with these areas too.

For engineers, LLMs are an amplifier and multiplier. They are a "sharp knife", perhaps the sharpest of all, and we can achieve so much with them, but we must be careful not to cut our fingers. Engineering fundamentals matter now more than ever.

Systems design and software architecture mattered before but it now matters more because poor architecture will now sooner lead to bloat, duplication, complexity and poor performance. Thorough and constructive peer reviews mattered before but now matter more, especially if we are moving at a faster pace and changing or adding more lines of code. An awareness of security vulnerabilities always mattered but now matters more as we move to more rapidly ship new features, relying on code that might not have been written entirely by humans. If we forget the fundamentals, we risk vibe coding ourselves into a corner where things start to fall apart.

LLMs replacing software engineers​

In an interview with Joe Rogan, Mark Zuckerberg of Meta recently stated:

“Probably in 2025, we at Meta […] are going to have an AI that can effectively be a sort of mid-level engineer that you have at your company, that can write code.”

Although apparently controversial, Zuckerberg's comment is similar to my point above regarding the translation of a small and well defined Jira task into code changes. He does not actually state that engineers will be replaced with agents, even if some find that idea attractive. LLM-based agents lack autonomy and agency and require direction and supervision. Let us not forget that writing a detailed prompt to produce source code is still programming of a sort, albeit at a higher level of abstraction. Churning out code isn't enough - we still need the right code and it is up to us to decide what right is. Zuckerberg added, "I think [it] will augment the people working on it".

In my opinion, LLMs will not replace software engineers on the whole, but will give existing software engineers far greater leverage. A much longer lever to produce greater torque at the fulcrum, if you like, greatly amplifying the initial inputs.

There is a caveat though. I suspect that LLMs will form a component of Artificial General Intelligence (AGI), or will at least act as a stepping stone towards it, assuming AGI can indeed be created. If AGI arrives, then all bets are off and we enter an entirely new paradigm. In this future, no job is safe from disruption. With robotics, even physical, hands-on jobs will eventually be able to be automated. There is a possible future where a robot lays bricks, rewires your home and carries in your groceries. I digress.

Two types of companies​

Amongst others, there will be two key types of companies. The first type will be those that see software development simply as an overhead. They are not seeking meaningful growth or to push the boundaries, and are therefore able to now achieve the same output with fewer engineers. If profit is equal to total revenue minus total expenses, then reducing engineering headcount expenses will in turn increase profit, satisfying the short-term mindset.

On the other hand, the second type of company will leverage LLMs to significantly multiply their engineers' output, using the productivity boost to outmanoeuvre the competition, building better products and features, and many more of them. Combining human ingenuity at scale with LLMs, these companies will run rings around the first type of company.

For software engineers, some turbulence lies ahead as companies begin to experiment with and adapt to LLMs, and we see the tension between the two types of companies that I described above play out. Jobs will be lost, others will change and new jobs will be created. With the help of LLMs, some displaced engineers who would never have considered starting their own businesses will leave established companies to do just that.

Wrapping up​

Overall, I remain extremely optimistic about software engineering. Software is continuing to "eat the world" and there is no sign of this stopping. Software will one day be everywhere and in every thing and will be more critical to our lives, and we will need people who can build, understand, debug and maintain software. This is Jevons paradox in action. As software becomes easier to build, we will probably want more of it and more people to develop and manage it.

In fact, there is already plenty of work ahead - almost all of our existing software and its interfaces are built on the fundamental assumption that computers require imperative instructions, but that is no longer the case. We can talk to computers and they can talk back. We have the huge opportunity to build new systems, experiences and products using AI as a foundation. Similar opportunities appeared during the smartphone revolution, which literally put powerful computers in people's pockets - we had to rethink the assumption that computers stayed at home and rebuild accordingly. Those that adapted and took advantage of these opportunities were ultimately the winners. Let's get to work.

$ chruby
chruby: command not found

What happened?​

Let's take a closer look at what happened. The installation script automatically adds a /etc/profile.d script at /etc/profile.d/chruby.sh. The /etc/profile.d scripts are themselves auto-discovered and then executed by the /etc/profile script, which one might expect to happen upon logging in:

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

However, /etc/profile is invoked only for login shells. A login shell is what we use when logging in via SSH or via a TTY. Our terminal instance is an interactive non-login shell and so /etc/profile is not executed, including our new chruby.sh script that would have made the chruby command available to our session.

To make the chruby command available to an interactive shell, we must configure our shell accordingly. For Bash this involves editing the ~/.bashrc or /etc/bash.bashrc files, which are the current user and global configuration scripts for Bash respectively:

source /usr/local/share/chruby/chruby.sh

For ZSH on MacOS, the equivalent files would be ~/.zshrc and /etc/zshrc. If using a shell other than Bash or ZSH, consult the documentation to ensure the correct configuration script is updated.

Correctly configured, we now see the following when running chruby:

$ chruby
   ruby-3.3.0

What next?​

Although the convention for Unix-like application installers is not to touch the user's data, the Google Cloud SDK installer asks users whether it should update their ~/.bashrc file as part of the installation process:

Modify profile to update your $PATH and enable bash completion? (Y/n)?

The chruby installer could help users by offering to do the same, even if only handling the most popular shells like Bash or ZSH.

Some photographers enjoy the unobtrusive, film-like character that subtle image noise can add to an image, particularly for black-and-white photography. In my experience, however, many of us prefer clean and noise-free images for the same reason that we prefer clean and noise-free audio — noise distracts our senses and clouds the signal.

For images, noise can lead to the loss of detail and colour information. Luminance noise, which presents as random variations in pixel illumination, is easier to forgive, whereas chroma noise, which presents as random variations in pixel colour, is an unsightly distraction.

Recent advancements in image sensor technology mean that noise is less of an issue than it was say a decade ago, but image noise will still be noticeable when shooting at higher ISO values and can be particularly problematic for smaller image sensors that gather smaller quantities of light such as 1-inch, Micro Four Thirds and APS-C sensors.

Until recently, noise reduction algorithms have been fairly rudimentary, often resulting in a noticeable loss of detail as the image details are 'smoothed out' to hide the noise. This changed with the release of DxO PhotoLab's DeepPRIME noise reduction algorithm. The exact inner workings of DxO's proprietary algorithm have not been disclosed by the company, however we know that PhotoLab employs Artificial Intelligence in the form of a neural network that has been trained to perform the demosaicing and denoising processes.

In any case, the results speak for themselves. Below is a 100% crop of a raw image taken of a Christmas elf figure in low-light conditions at ISO 1250 using my Olympus OM-D E-M1 Mark II, paired with the Olympus 25mm f1.2 PRO lens. If it is not already clear, the left side is the image processed without noise reduction and the right side is the image processed with PhotoLab's DeepPRIME noise reduction (v5.5).

A further enlargement of the same crop follows:

The reduction in noise is significant, all without any obvious loss of image detail. DeepPRIME noise reduction has been a game-changer for my Micro Four Thirds photography and I look forward to seeing what further enhancements the team at DxO Labs can make.

Fortunately git bisect provides a helpful tool for doing precisely this. Rather than performing a linear search of the commits, git bisect uses a clever binary search algorithm to locate the offending commit far more efficiently.

Having identified a commit from the past where the regression did not exist (e.g. git checkout a commit from say a month ago), my typical usage of git bisect is along the lines of:

1. Check out the branch containing the regression and run git bisect start.
2. Label the good and bad commits: git bisect good <commit hash> and git bisect bad <commit hash>. The current commit is taken if the commit hash argument is omitted.
3. Bisecting commences — a candidate commit is automatically checked out and the number of revisions left to test and number of remaining steps are printed. You can run git bisect reset to abort at any stage.
4. Check whether the regression still exists, whether this involves running an automated test or taking manual replication steps. If the candidate commit contains the regression, run git bisect bad, otherwise run git bisect good. If any search area remains, another candidate commit is automatically checked out.
5. Repeat #4 until the bisecting process concludes and the bad commit's hash is listed.

Given git bisect's binary search technique, the number of steps required will only increase logarithmically as the number of commits increases — this is a time-saving tool that I turn to again and again.