Blog
AI changed my job twice
I have already seen AI make part of my job obsolete once. It happened again.
In 2012, Alex Krizhevsky, Ilya Sutskever, and Geoffrey Hinton, who would later receive the 2024 Nobel Prize in Physics for foundational contributions to machine learning with artificial neural networks, published a paper introducing AlexNet. It became one of the most influential papers in modern AI and helped open a new era for the field. The result was striking. In the ImageNet Large Scale Visual Recognition Challenge, AlexNet achieved a top-5 error rate of 15.3%, compared with 26.2% for the second-best entry. It was a huge leap. The impact, however, was not immediate. It took time for the community to join the party. The field had to mature, research exploded around deep learning, new architectures were developed, and the supporting software and hardware ecosystem had to catch up.
Industry adoption came later. By around 2017, it was becoming pretty clear that deep learning was outperforming traditional approaches in many computer vision tasks, and companies had to start adopting it if they wanted to remain competitive. Even then, I continued to see companies and colleagues dismissing it for quite some time.
Deep learning effectively killed an entire generation of algorithms based on carefully designed mathematical assumptions, heuristics, and hand-crafted rules. Some of those algorithms were extremely powerful for specific tasks, but they were often surprisingly easy to break when the input changed slightly. I remember hand-crafting sets of features to detect cells that were elongated, not too large, within a particular intensity range, and so on. It was actually fun to write those algorithms. But then a new sample would arrive with slightly different intensity values, or the cells would be slightly larger, and suddenly the rules no longer worked.
Machine learning changed the nature of the problem. That data-first shift still shapes how I approach computer vision consulting, from model design through production deployment.
Instead of continuously thinking about which new feature or rule we should introduce, we could collect more representative data and train the model on it. We effectively handed over the task of discovering useful combinations of features to the neural network. Our main concern shifted from feature engineering to data: finding representative examples, annotating them properly, designing the right training strategy, and evaluating whether the model generalized. That transition created a lot of discomfort in the field. I remember talking to colleagues who felt that years of research had suddenly become obsolete. And, to some extent, they were right. But eventually almost everyone adapted. Computer vision made an enormous jump in quality, and deep learning reached or surpassed human-level performance in a number of narrowly defined tasks.
What is happening now?
Fast-forward to November 2022. ChatGPT was launched and rapidly reached massive adoption around the world. We quickly realized that the tool was not just fun to use but also useful, it could write the recipe of a brownie in no time, but it could even write code. I started asking ChatGPT questions instead of searching Stack Overflow. It was faster, often more effective, and could give me answers tailored to the exact problem I was working on. Then LLMs moved into the IDE. I went from asking ChatGPT questions and copying code into my editor, to having an LLM autocomplete the lines I was writing. Then entire functions, then complete classes. Models became good enough to solve bugs, review code, refactor existing implementations, navigate large repositories, and eventually write substantial parts of complete applications. Then “vibe coding” became a thing: building applications largely through natural-language instructions, sometimes without manually writing much code at all.
In software engineering today, I often see two very different reactions. One group argues that LLM-generated code is unreliable and that serious engineers should not trust it. The other sees something very different: AI-generated software that is already useful enough, and sometimes better than software written manually by professionals. A few months ago, I still had concerns about LLM-generated code, particularly in large codebases. Today, my perception is different. I consider myself a good programmer, but if a tool can write many parts of the code faster than I can, and just as well or better, why should I insist on writing every line myself? I still want to believe that code generated by an LLM under the direction of an experienced software engineer will be better than code generated by someone without programming expertise. But I am no longer sure how long that advantage will last. Frontier models are improving extraordinarily quickly. Dario Amodei famously predicted in 2025 that AI would soon write the vast majority of code, although his timeline turned out to be too aggressive.
Deep learning automated feature engineering. LLMs are now automating implementation. In both cases, engineers move to a higher level of abstraction. No one knows where this stops, since LLMs are becoming increasingly powerful, but one thing is clear: software engineering has changed dramatically. Many people in the field, myself included, feel kind of sad about missing the coding part. But, just like what happened in computer vision, there is a shift in tasks. Computer vision engineers did not disappear after AlexNet. We stopped designing features manually and focused more on data, architectures, evaluation, deployment and system design. Now, software engineers are stopping writing lines of code and focus more on designing and framing the problem, iterating on the codebase, directing how software is built, trying new approaches, optimizing solutions, improving safety and increasing robustness. This is also the engineering focus behind my work on reliable agentic AI systems and workflow automation. The interesting question is no longer: “How good are you at writing code?” It is increasingly becoming: “What can you build when writing the code is no longer the bottleneck?”