@ Fabio Manganiello

If you work a software developer in a corporate environment, how do you approach the use of #AI tools in your day-to-day job? For a while I have tried to struck a pragmatic balance and use it in moderation. If I have an enum with 10 values and I have to fill up a switch-case boilerplate scaffolding for each of them, I'm happy to let Copilot do it for me. Same if I have a class with a bunch of attributes and I have to set up getters and setters for them. I mean, performing these tasks fast doesn't add a lot of value, just like performing quick multiplications of numbers with 5 digits may be a nice party trick but not exactly the kind of thing that you'd put on your CV. I'm trying not to get AI to erode my problem solving skills, but writing boilerplate code isn't something that contributes to those skills. Let machines do what they're best at (repetitive tasks) and let me do what I'm best at (solving problems) - that's been my guiding principle for a long time. I'm slightly amused when I see people react in shock to companies that announce that ~25-30% of their code is AI-generated. In my experience a way higher share of code in corporate codebases consists of boilerplate. Managing it by hand is often time consuming and error prone (you're always one copy-paste away from breaking production, and such errors often elude even the most eagle-eyed human reviewer). If that share of code is mostly filled up by AI (which is usually good at spotting repetitive patterns, and boilerplate interface definitions, YAML configurations or mappers/adapters usually have a lot of them) then I'm more than happy to offload those tasks, so I can spend more time thinking of how to fix that nasty memory leak or how to handle 10x traffic on my Kafka consumer. However, I feel like I'm increasingly finding myself in a position where my own career may be affected if I don't make a more aggressive use of AI tools - and I don't think I'm the only one here. When I started writing code for a living in the early 2000s, I had a good knowledge of C, C++ and Java, with a sprinkle of PHP and jQuery. That's literally all I needed to land any jobs I wanted in software development. And, in those times, I already had the chance to meet older developers who were grumpy about having to learn so many technologies, as they could get away for all of their professional lives by knowing only C, using only Makefiles to build their projects and using at most SVN to handle versioning. Those folks were skeptical even of object-oriented programming and git. Nowadays mastering even 4-5 programming languages and a couple of build tools is no longer sufficient to work in an efficient way in a corporate environment. The proliferation of programming languages and build/deployment tools in the past decade has been an interesting phenomenon. I feel like there have been more programming languages, paradigms and abstractions created in the past 10 years than in the 25 years that preceded them. Sure containerization and public clouds have played a big role in this, as well as the push towards turning all software developers into their own SREs and sysadmins. Earlier, when you wanted to add a new tool to your monolithic codebase deployed on prem, you had to go through the gates of hell to ensure that all the pieces of your infrastructure had the right dependencies with the right configuration to handle your new thing. Nowadays, you just throw a new container in your compose file or Helm chart, deploy it to your cloud through Terraform, and you're done. This has in turn encouraged much more experimentation, but it has also left our industry very fragmented and hyperactive. It's not uncommon in a job like mine nowadays to work on a Kotlin service today, a Java library tomorrow, a Python script the day after, and then a Groovy or Lua script used by one of your integrations, then some little Go program that somebody made because they just needed a small exe to launch in their CI/CD, then fix some issues in some Rust code that someone has decided to write to replace some legacy C++ service, then on a little TypeScript+Express web service that your former full stack guy made as a proxy for the API calls, then modify some nginx configurations, then work on Gradle build files the week after, then on a Bazel build the next day, and then put together a new Makefile that needs to be run in your Dockerfile that needs to be started by your compose file which needs to be run both in your Gitlab CI/CD and in your cloud, provisioned through Terraform and configured through an Ansible playbook - but hey you also need to deploy some of the changes to a legacy on prem system managed with Puppet and Jenkins. Oh, and then you need to provision that new Kafka topic - did you hear about those API changes and deprecations in Confluent btw? Oh, and then you also need to plug those new metrics that pull from ElasticSearch, Postgres, Loki, Prometheus and CloudWatch and use both Grafana and Bosun to handle alerts - did you take a look into that new OpenTelemetry integration btw? Oh, and then you also need to work on pipelines that replicate your data from Postgres to Snowflake for your data scientists, to Tableau for your business analysts, to Hadoop for long-running queries, to an S3 bucket for cold audits, to ElasticSearch to power your UI, to Redis for API caches (did you hear about those changes in the Valkey fork btw? and how about our PM who wants to switch to that new cloud product, have you looked into it?), to Neptune or Tinkerpop for that knowledge graph project (btw have you chosen between Gremlin and SparQL? How about RDF with Jena?), to Pinecone for your ML team (btw did you check out Chroma and Weaviate and that other couple of new vector databases that the PM talked about yesterday?) Oh, and you need to pack all those data pipelines into an Airflow workflow that runs both DBT queries (btw did you manage to adapt those SQL queries into both SparQL and Snowflake SQL?) and Spark jobs (btw did you manage to look into that Sagemaker integration for the ML folks?), which needs to be deployed through a Harness, Drone or Gitlab pipeline, as well as some Flink pipelines to do runtime aggregation of raw events. Oh, btw did you decide between Erlang, Elixir and Haskell as a functional language to write that small service that needs to process a lot of high-volume stuff? And so far I've only scratched the surface for backend developers. Let's not even get started with the frameworks madness of the frontend world - and the races between competing frameworks in today's languages in general. It's not uncommon nowadays to hear a colleague say "hey, did you hear about this framework / data storage / transmission / transformation technology?" at the coffee break, and being tasked with deploying a solution to production with that tool the next day. And programming languages themselves are now also in a position where it's objectively much harder to master them compared to 1-2 decades ago. C had about 40 keywords and a relatively small standard library. Java had a bit more expressive power and came with hundreds of possible frameworks to augment it. Kotlin has probably hundreds of keywords and countless ways of achieving the same results. And let's not even get started with modern C++ - a language that has become so complex and with so many caveats to be basically human unintelligible. Don't get me wrong, I love the expressive power of languages like Rust, Kotlin and modern Python over the rigidity of C, Tcl or early Java. But I'd argue that the learning curve of most of those modern programming languages is now smoother for beginners but steeper for those who need to master them - and if you need to write scalable production-ready software with the least amount of bugs you usually need some level of mastery that goes beyond reading a Medium/HackerNews article. So not only you're supposed to master more technologies, and master them faster than you were expected before (in the early 2000s it wasn't uncommon to give a new hire, even a senior, a quarter or two just to get familiarized with a new language or tech stack), but those languages themselves have become more complex and harder to master. This is no longer frameworks fatigue, this is pure technological madness. And I don't think that I'm speaking only of FAANG-level companies here - I've seen similar patterns also in smaller businesses. No human being in this world can master so many tools and be even remotely competent in 10% of them. But what happens when you tell your boss that yes, you can look into that new technology or integration, but it will take you 1-2 weeks just to understand how it works, how you're supposed to use it, and then another 1-2 weeks to reliably deploy it to production and fix anything that goes wrong? Well, that your colleague asks ChatGPT or Claude and comes up within minutes with a solution that may require only a couple of iterations and manual tweaks before being deployed in production. Sure, it may not be perfect and in most of the cases it still requires human scrutiny, but it's definitely more efficient than you trying to figure out the same things through Github pages, Medium articles, StackOverflow questions and trial-and-error. Then guess who gets a promotion. I've also noticed that in a quite short time many companies have gone from "please don't use AI tools - you may leak sensitive intellectual property to unauthorized parties or even to competitors" to "please use all AI tools you need if it means that fixing bugs and building stuff in today's hyperactive industry can take minutes/hours instead weeks/months". Just like you have that moment in school when you realize that there's no point of doing multiplications of long numbers by hand (you can delegate it to your pocket calculator so you can use your brain power to actually solve that differential equation before the exam is over), I feel like we've reached a level of complexity in our industry when there's literally no added value in being able to bootstrap a React project from scratch, knowing the functions of the standard library of your favourite programming language by heart, writing an ElasticSearch query by hand or deploying a cloud resource through Terraform without asking an AI assistant to create a template for you. All those tools and technologies are subject to constant change anyway, and tomorrow you may even be tasked to work on a different one - or everything they do suddenly becomes deprecated and you have to learn a new way of doing what you do now. Sure, AI may at some point make our jobs irrelevant. But I feel like, if we engineers don't learn fast how to master it to make ourselves more productive in today's hectic industry, we may become irrelevant sooner anyway. nostr:nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqq8m9f0f3mcmnu3x6a45y90hctvylk9g5uh4f7z9lsm6l7ny0sr3qfaym7f