Becoming an AI-proof software engineer

A quick note before I begin: I've finally formalised my coaching offering and gotten some testimonials onto my landing page. If you've ever wondered about either of these things, that information's available now!

The tech industry is in an extremely weird place at the moment. Immense quantities of money are sloshing around looking for places to be invested. Tech leaders, in bed with outright fascists, are attempting to appropriate as much of that money as they can and to discipline the tech workforce by firing most of them at the same time. Like clockwork, the LLM craze filled the gap, meaning that we're now going through, in basically every sphere of society and especially in the tech industry, a wave of mass hysteria about machines taking away our jobs and who knows what else. The labour market, as a consequence, is largely irrational and people are doing all kinds of weird shit, much of it actively detrimental to sound engineering practice.

If you are, for one reason or another, thrown into an open job market in this situation, it's a pretty terrifying place to be. New graduates and junior engineers by-and-large fail to learn professional skills or engineering judgement at university, and with the LLM craze being what it is, there's basically no chance of learning it on the job at the moment. If you've been laid off and are looking for a new opportunity, you'll find that what employers are apparently looking for is somewhere between being incoherent and actively evil. Trying to defend yourself against the encroachment of LLMs and the madness that they bring with them, and eventually find work in a place that isn't completely mad, is thus of high importance in the current situation. How to do that, however, can often be quite unclear.

Here, then, are the things that I reckon a software professional in 2026 needs to learn or otherwise be good at if they want to protect their career, their skills and their sanity against the current industry-wide obsession with LLM tools.

Learn your tools exhaustively

It might surprise you to know that I don't actually value the raw skill of "being good at writing code" all that much in the context of engineering. Sure, not having to look up basic syntax is useful and you'll almost always be faster working in a language that you know well than one you don't know at all, but writing code is not, in most cases, what you spend most of your time on. What I do stress as being very important, though, is knowing the tools that you use to write and run software extremely well. Tooling, after all, is what you use to write your code, to test it, to deploy it and to make it available to other people, and software that other people don't have access to is worse than useless. If you don't know your tools, you'll struggle to share your code or actually do anything with it, no matter how good the code that you actually write is. By contrast, if you only have a mediocre grasp of the programming language you're working with but can build, test, version control and deploy your software effectively, you can have a real positive impact even with not-very-good code. Good tooling also constrains you in ways that make the code that you produce better: being able to roll back changes to your code and keep snapshots of it, being able to run and test your code more frequently than you might without good tooling and having access to linters and similar code quality tools all contribute to the production of high-quality code much more than you might get just from knowing the language, and the frequent feedback that they provide mean that you learn the details of a language much faster than you otherwise would.

The first and most important tool that you work with is your development computer: this is the tool through which you use all of the others, and it's impossible to do much that's useful without it. Given this, being deeply familiar with how a computer actually works is very important. This goes right down to hardware: you should know how to open up your machine's case and add RAM or an internal hard drive, switch out a GPU or refresh your CPU's thermal paste. You should also be comfortable with installing and running operating systems that are different from the default, as that's a pretty common task: even if you decide to do your work on Windows or whatever the latest Apple OS is, being able to dual boot Linux or one of the BSDs is an essentially skill (don't use Windows unless you can't possibly avoid it though: it's terrible, you're going to have to use WSL for anything important anyway and Windows 11 is a complete nightmare. While this has been going on, Linux has only gotten better, and you can even play most video games on it with very few issues). In general, you really need to be comfortable making your computer work for you, doing basic maintenance and being your own tech support 99.5% of the time: without this, it's very difficult to be at all effective as an engineering professional.

Having secured this, the next step is to make sure that you have a comfortable grasp of the Unix command line. While I'm not the kind of engineer who thinks that you should do everything via the command line, and learning vi is extremely optional, many basic administration and software tasks are done much more easily from the command line than through a GUI. While you can do some very powerful things with shell scripts, you probably just need the basics to start with: you should have at your fingertips the commands to navigate through your filesystem, open, create, edit and delete files and directories, install packages and apps through a package manager and check system behaviour. You should also develop an understanding of pipes and file redirects as soon as possible. Having the skills to do this committed to muscle memory will make working with your computer and writing software both much easier.

While the exact tooling you'll need for your work will depend on what language you're working in and a bundle of other factors, git for version control is something of a universal. Being able to use the basics of git without having to look anything up, then, is really important. You should be able to initialise a repository, add files, make commits, reset to a previous commit, work with branches and work with remote repositories from memory. Being an effective user of git makes software development much less painful and importantly allows you to collaborate with other developers: something which is very important but also seldom taught in university programs or boot camps.

Finally in the list of tools that you need to have a deep grasp of is the particular tooling required for the language you're working in. If you're working with anything in the web ecosystem these days, for example, you probably want to understand Node, npm and all of the attendant quirks. If you're working with Rust, you need to know Cargo back-to-front: Python these days basically requires uv(seriously: if you use Python and haven't tried it, do it. It'll change your life.). Knowing how dependencies work and how to resolve them in your languages of choice winds up saving you an awful lot of grief.

There are a few ways to build that level of almost instinctive facility with your tools. Spaced repetition to remember commands works well if you're aiming for deliberate practice, for example. By far the best way to build fluidity with tools, though, is to use them in your day-to-day work. If you're a student or you're working at a not-so-good company, for example, using git from the command line even when it isn't required will quickly get you to be properly good at using the damned thing. Similarly, scaffolding projects and working with files using the command line, while hard at first, will teach you how to use the command line quite efficiently: you might even choose to write code using a terminal text editor such as micro instead of using a GUI (though I'd not suggest this for larger projects). Using the tools regularly is the single best thing you can do to gain confidence with them.

Of course, doing this on your own using only the resources available to you on the internet can be a struggle and lead to you developing bad habits. It can thus be helpful to work on this with more experienced people: this can look like formal mentoring or coaching, or it can simply be hanging out in a discord server with a bunch of good engineers. Either way, having someone whom you can ask questions to and whom you can run what you're doing by is extremely helpful, both when you've made a mistake and, even more importantly, to build confidence in your work when you're using the tools correctly. The other thing that can help a lot with the proper use of tools is reading books on the subject: they're usually much more rigorous than your average internet resource is. A decent university library will usually have a good selection of books on any subject you care to mention or you can buy the text: no matter how tempting it might be, you should never go to Anna's Archive and search for texts you might find interesting, because that is piracy and piracy is morally wrong. So be sure not to do that.

Deploy something as soon as you possibly can

The main failing of almost all software education programs and most workplaces is that almost none of them require you to personally deploy something to real-world users and then be responsible for maintaining and building on it over a decently long period of time. The fact is, you write code once over a period of days to months, but you maintain it and build on it for years, or in many cases, decades. The vast majority of work you'll do as a software engineer is thus maintaining or extending code rather than building new things, and to be a truly good engineer, you have to make your peace with that (it's even better if you can find ways to enjoy it). The best way to learn how to do that is to build something for yourself or that you want to share with other people and actively make it available as soon as you possibly can. Ideally you should have something useful deployed within six weeks of deciding to take engineering seriously: obviously if you've been in the field for a while this isn't an option, but the second-best time to start is, as always, today.

If you already know a language well, working in that is the obvious choice for this kind of project. If you're just starting out and don't have real confidence and deep knowledge in any language, though, thinking of a project that you can deploy immediately can be a real challenge. If you're in such a situation (and honestly even if you aren't), a good starting project is a basic personal website. HTML is a) very quick and easy to learn and b) almost everywhere these days, so knowing it is extremely useful in whatever space you're working in. A personal website or blog is something that's important both to you and to the people that land on it and that you'll want to expand on and update as time passes. This means that, even if you don't know all the details of programming as such, you still get to experience the entire software life cycle, from planning, to building, to deploying the damned thing, making choices about hosting and then maintaining and updating the website. In building and updating it you get a crash course in why version control is important, learn how to work effectively with a remote repository, get lots of practice with the command line and generally pick up the tools and mindset that you need to be good at delivering software.

Why is this important? We've already touched on a whole bunch of reasons, but the really important one, and it's one that we've not yet discussed, is that it's the only way to develop an engineering mindset that I've found thus far. You can learn how to code at a university, and you can even learn some basic engineering principles from case studies and such, but you really can't learn how to effectively deliver and maintain software products unless you've done the reps consistently over a long enough period. People who've not had to do this, or who haven't been personally responsible for delivering something directly to users tend not to develop this mindset, which means that they don't tend to produce very good software products: they're brittle, difficult to maintain and often just don't work. If your only goal in being an engineer is to earn a paycheck, that might be fine, but if you actually want to do good and robust work that helps people rather than making their lives a living hell, you need this experience.

Do the unfashionable work

For all that software engineering is supposedly a hard, rigorous field, it runs almost entirely on vibes. If you've been embedded in the tech world for any length of time at all, you'll be very familiar with the way that the industry runs on fads: in the last decade ago we went from NoSQL, to microservice architectures, to data science, to crypotcurrency and NFTs and now we're dealing with a massive LLM craze, which, whatever the uses of the technology, is massively overinflated. Backing all of the fads, though, is a massive infrastructure layer of boring and unsexy technologies that nonetheless make everything built on top of it work at all. From the sysadmin tools and shell scripts that we use to maintain the servers that run our code, to the databases backing them and the testing infrastructure and CI/CD that keeps our code reliable, there's a lot of work that isn't glamorous at all and is often held to be lesser or unimportant by the cool kids, but that keeps the entire industry afloat. One of the most important practices that you can develop as a junior engineer or a student of software in general, then, is to take every opportunity to do this unfashionable work and to learn from it.

Testing, in both the manual and the automated varieties, is one place where a lot of learning can happen. Manual testing certainly isn't fashionable at all, and outside of places like the late Pivotal Labs, automated testing is considered, on the whole, boring and unrewarding even when it's accepted as being necessary. Status comes from shipping features, not writing tests, and as of 2026 a lot of people are recommending that you just farm out unit tests to an LLM of some kind. This is a mistake.

Learning how to write good tests and do good manual testing teaches you a lot about how code breaks and how bugs form. The end result is that when writing new code, what you write is much tighter and less likely to break than it would otherwise, and that maintaining existing code becomes a lot easier because you're familiar with common bugs and know how to resolve them. This lets you move faster and write more robust, more efficient code, which is both inherently good and helps you out-compete other software professionals. It also pushes you to write testable code: code that has isolated internals, clear interfaces and that breaks down the program into manageable chunks. Of course, this is good practice in general, but as we all know, if we want to do the right thing consistently, we need to have structures in place to make sure we do the thing even when it's hard.

Having a strong understanding of SQL and database internals is another deeply unfashionable bit of knowledge that will nonetheless make you a much better engineer. Databases are overwhelmingly the main way in which software stores persistent data these days, but for some unaccountable reason much of the fashionable set in the software world think that the details of how the things work and are queried are beneath them, to be farmed out to an underclass of data engineers and analysts. When they're forced to interact with these things, they tend to lean heavily on ORM libraries, abstracting away all of the messy difficulties of actually writing SQL.

The consequences of this, however, are that database code is often slow, buggy and generally unfit for purpose. This can easily be avoided by learning a dialect of SQL and understanding how something like PostgreSQL works under the hood. Between indexing, stored procedures and a whole bunch of other such tools, you can make database operations that much faster and more robust, which consistently leads to better software. Stepping back a little further, the Linus Torvalds quote about good programmers worrying about data structures and their relationships rather than code is extremely true. At base, all programming is about the manipulation and communication of data: it's about the only thing these machines actually can do, when all's said and done. To that end, it's very much worth getting into the habit of thinking about data and how it's organised early, and learning about databases is an excellent way of doing that.

The unfashionable bits of tech are, in a very real sense, the things that hold the whole enterprise together. They're what takes lines of code from "pretty demo that works on my machine" to a tool that's actually usable by people in the real world and that doesn't fall over the moment you look at it. If you just want to be a programmer, that may well be OK, but if you aspire to be an engineer, spending a considerable amount of time learning the boring, low-status parts of your job really is necessary.

Learn something that isn't code

In and of itself and divorced from any other context, code is entirely useless: it's a way of relating a string of symbols to each other according to certain rules, which, while it might be very elegant, does nothing useful without being mapped to a context in the real, material world. Becoming an effective software engineer, then, requires you, in addition to being able to write code, to be able to effectively grasp the domain that you're working in, and in my experience doing this effectively means that you have to have learned, in depth, something that isn't simply writing-code type software engineering.

Knowing how to write software, in our current environment and without having made a serious attempt at doing anything else, will quickly make you lose your head. As software tools are very powerful and can do things very fast, writing software can make you think that you can do anything. Furthermore, in the usual model where software developers are insulated from the people using their thing by layers of product people (whom your average dev tends to look down on a bit for being non-technical), it is far easier to lose any connection with the people using what you build than in any other field. And then you end up with people like Elon Musk and the broader silicon valley culture, where you have a lot of very smart people who can code very well believing in things like eugenics and phrenology and trying to "disrupt" the dumbest things because (in addition to being extremely racist and sexist) they simply don't grasp much of what goes into any field other than software and thus convince themselves that only people who write code good know anything worth knowing. Consequently, they get massive amounts of VC money to produce things that largely fuck everything up for the rest of us and consider our unhappiness to be proof of our stupidity.

I didn't come into this field planning to write software: I started out, in fact, studying engineering physics and have had more training in things like fracture mechanics, industrial design and the modelling of fluid flows than I have in writing software as such. When you do this, you quite quickly learn that literally every field is difficult and far more complex than it looks from the outside. I know people who are experts in the specific paints used to paint pipelines in chemical manufacturing plants, people who have a deep and intuitive knowledge of the networks behind the electric signage you see on roadways, people who've dedicated their lives to understanding the acoustic behaviour of reinforced concrete and hundreds of other micro-specialities of this kind. Knowing how to write Rust or halfway decent JavaScript does not give you any special power when it comes to understanding these things, and you are not better than the experts at this shit just because you know how to produce syntax at a decent clip.

Engineering is an easy example to go for because software engineers still tend to respect it to an extent (though the Atlas Submersible collapsing while visiting the wreck of the Titanic demonstrates just how much damage misapplying the software mindset can do). I have to stress, though, that every field has this much depth and is this difficult to master: whether it be biology, baking (you would be amazed at how much effort goes into producing high-quality bread in a consistent way), makeup (the manufacture of lipstick base alone is something that you could reasonably be an expert in) or the fine arts, there is almost always way more complexity and depth to a field than you'd expect.

If you want to be a truly good engineer, then, you really need to learn and get good at something that isn't software. Engineering in the regular sense is a good choice (I would say that, of course), but so are a lot of other things. Above all, it should be something that you enjoy and that you're genuinely interested in, as well as being challenging and rigorous enough to push your understanding and let you get some measure of the extent of your ignorance (because it's possible to build an entire software career without getting that). If you're at university or planning to go to university, doing as many papers as you can in the humanities or natural sciences is an excellent plan (a decently rigorous economics program can also do a lot of good: I've not seen much good come from other commerce programs). If you're working, becoming active in your local community is an excellent way of learning things that aren't just writing code too (your mileage may vary if your community happens to be in Silicon Valley).

Write

Finally, if you want to be seriously good at engineering, it's very much well worth your time to learn how to write. The most obvious reason is that, as with everything, engineering is mostly about communication. If you can't communicate your ideas clearly and persuasively, you will consistently struggle to do well. In a decade in which LLMs are doing their level best to consume increasing amounts of human brain matter, being able to write clearly and with a distinct voice is one of the very few ways you can identify yourself as a sensible human who can think and write clearly and who is a good engineer. Almost anything can be faked, but opinions and a point of view absolutely can't be.

In a more quotidian sense, writing about technology is an excellent way to learn about it: for my part I've learned an awful lot about R by writing a book about it, and it really forces you to explicitly state your ideas and knowledge in a way that other people can understand. That means that once you've written about something, you understand that thing much better than you otherwise would have. Writing also exercises a lot of the same skills that a good engineer uses when writing code: breaking larger ideas down into smaller chunks, expressing them idiomatically and then putting them back together into a coherent whole. While that's obviously something that you can learn by writing code itself, it can be difficult to generalise the skill if you only use it in one domain. If you use the same analytical skill in two separate fields, by contrast, the skill generalises much better and you can apply it to things beyond just coding and writing.

Writing about your work and publishing it, furthermore, lets you meet people and develop a reputation for capability in the field. Simply by virtue of writing and putting stuff out there, I've had conversations with at least one Leverhulme Prize winner, a creator of Nuxt, a startling number of truly amazing engineers and more writers than I can list. I've learned a lot from a bunch of former Pivots that I made friends with, and while the job market right now is still hell, the interviews that I do get at the moment are for much better jobs than I could possibly have hoped to get without writing. If you've taken my advice and built and hosted a personal website for yourself, then, writing a blog and posting it there is an excellent way to both write regularly and get the reps in for deploying and maintaining a project.

Conclusion

All of the things that I've discussed here will help you develop skills that are not easily replicable (if they're replicable at all) by an LLM. More importantly, they'll help you develop an engineering mindset and transferable skills which will allow you to be effective in almost any field you turn your mind to. Being able to break down ideas, state them clearly and synthesise them is, after all, an extremely useful skill almost wherever you are. So is being able to communicate clearly in writing, deliver and maintain a complex project, learn from work that other people might consider boring or beneath them and developing mastery of the tools you use day to day. Whatever the role of LLMs proves to be in future, these are always going to be useful skills to have.

Right now, everything solid is largely melting into the air. Whatever one might say about LLM tooling at the moment, it's clear that the technology is massively overhyped (this applies, for the record, even if you aren't an LLM critic and believe that the tools are good for some things) and is, quite frankly, cooking the brains of the people who currently hold the purse strings. We're in the middle of an economic crisis, and the most powerful military in the world is in the hands of a decaying cadaver who also happens to be a pedophilic Nazi. The tech industry in particular is currently dealing with massive, unsustainable layoffs and public spending on tech is likewise in the hole, all while essential infrastructure falls apart. I don't know what the industry is going to look like in ten years' time and I don't think anyone really does, to be honest.

In such a situation, the best thing we can do is cultivate a mindset and skills that will be useful no matter what happens. I think the ones that I've written about here fit the bill admirably: whatever tech looks like in the future, you'll need to know these things, and in the meantime they'll help you survive however you can, even if it's not in the industry you'd want to be in. I'll not guarantee that being good at all these things will give you a good job right here and now (hell, it hasn't given me a good job, and a significant number of serious engineers consider me highly capable), but they will certainly give you much more of a fighting chance than you might otherwise have had.

---

Developing the skills and engineering mindset that I've described here is much easier to do with a coach or mentor, and this is very much a service that I provide. If you feel that you could benefit from developing a more resilient set of engineering skills and mindsets, or if you know someone in your life who's about to be thrown into what's a very tough engineering market, get in touch!