Pierre-Yves Gillier

For a few weeks, I participated in an internal hackathon where the main guideline was to exclusively use our own coding agent in its CLI¹ flavor.

As I had a project idea, among many in my backlog, I happily spent too much time building and, let be honest, talking to the agent. The first days were rough as I needed to understand how to communicate with the agent, had a lot of back-and-forth on details and, eventually, asked it to destroy project to restart from scratch…

Like many, I read the articles over the internet about the rise of coding agents and how it will reshape the development ecosystem, especially for junior developers. While I agree with the general opinion, I'm not convinced it will mark the end of developement as we know it, with it peculiar population.

For my hackathon, I asked the agent to build a Next.js stack with the Mantine framework. The agent wrote fully functional code in less time it would have taken me to simply display the default page of a Next.js project. That's great for hackathons, that's great for side-projects and small reach ones. But it's not for production targets. It's not intelligent for me to manage a project where I don't have enough experience and knowledge to maintain at least half of the code².

There are stories about "projects" written in a weekend using coding agents and being a total shitshow when deployed to production because:

1. Agents are here to write code, not optimize or secure it. So, imho, deploying projects as-is is a kind of russian roulette.
2. The humans behind the projects were not savvy enough to understand the inner mechanics.

All these signals make me think junior developars will still be needed, even in the Generative AI age. They will have to specialize far sooner than ever, be it in a technical field like mastering a specific framework or business one such as legal or finance. Why ? Because agents, utlimately, are statistical models and are not as efficient as human beings when having to deal with future problems suc as production deployments and relating technical problems with functional ones.

This transition won't be easy, unfortunately. Consulting companies will need to shift their learning and staffing process to hire and train more specialized people: leading to layoffs for those unable to step into this new paradigm. But no, coding agents won't replace humans in all tech domains. They will accelerate the delivery of projects by taking care of the structural work, the boilerplate. But humans will still be in the loop to put the cherry on the top.

When you're a technical guy at AWS, you need to be part of a TFC where you specialize in a domain. For me, it was the cybersecurity vertical which had my attention so I joined the community.

And, in 2023, I had the opportunity to work with several startups building LLMs, almost the prehistory there, and help them use our resources; SageMaker was quite low of features and Bedrock only a dream. Then, I grew a reputation of an "expert" in this field, while not knowing the difference between supervised learning and unsupervised one.

Despite working for the vast majority of last year on another vertical, I was often part of discussions on Generative AI and, due to my TFC, asked on related security topics. I began to dig on topics like "Responsible AI" and model ethics.

Coincidently, I spent time to certify myself both on AWS solutions and AIML fundamentals. These new knowledges were pivotal to my decision to explore further the intersection of both domains. "GenAI applied to Cybersecurity" and "Security of GenAI" are areas still vastly unexplored and a terra incognita I want to explore.

I do have several assets under review/building and hope I'll publish them before holidays.

When I started this iteration of my blog, more than a decade ago, my idea was to improve my writing by setting up a publishing cadence, starting at two posts per week, with both technical and non-technical content. It would have also helped me build a legitimacy in my fieldn which is never a bad thing.

I failed.

I failed because I was too obsessed with the quality, writing style and overall too perfectionist. It led to a lot more posts in draft status than published¹.

From a technical point of view, this blog is almost up-to-date on all dependencies and libraries. Why ? I took, and still do, each opportunity to dive deep in technical stuff instead of writing. I've event gone lengths to try a fully new distro…

I am not writing for a living, luckily, but this is a skill I need to improve. My company praises writing above everything else² and it is becoming mandatory for me to become a good writer as I'm looking to advance in my career here.

As writing is a skill, I need to train. This blog will, once again and for good hopefully, become a playground. Code, half-baked content, rants & so on. "Release early, release often" is a motto I gave to all my mentees; it's time to apply it to myself.

Edit: During the writing of this article, I had three times where I was digressing. It took a conscious decision to go back to writing.

Derrière ce titre un peu provocateur, je vous parle ce jour d'un nouvel outil découvert lors d'une review Guardian¹ et qui m'a conquis tout de suite: Taskfile.dev.

Ce petit binaire en go a pour ambition de remplacer les vénérables Makefile. Simplement le fait que les commandes soient décrites en yaml, que cela utilise le templating Go sont autant de raisons qui m'ont fait basculer mes principaux repositories sur cette solution.

L'essayer sera certainement l'adopter.

Dans les principes de leadership qui gouvernent toutes nos actions et que je tente encore et toujours de m'approprier, il y en a un que, tel monsieur Jourdain, je cultivais avant sans le savoir et que je sais avoir perdu de vue depuis un certain temps : "Learn and be curious"

Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

Je peux facilement dater le début de cet abandon. Le contexte de l'époque¹ et la pression politique associée m'ont obligé à délaisser ma passion pour la technique pour des considérations plus prosaïques, la réunionnite, et plus en rapport avec mes besoins à court terme.

Arriver chez AWS m'a redonné de la bande et du temps. Et, grâce à cela, j'ai pu mesurer l'étendue de mon retard...

Il est donc nécessaire de repartir sur de bonnes bases mais je dois rester concentré sur quelques sujets et ne pas me disperser. Vous n'imaginez pas la quantité de sujets shiny qui attendent d'être traités...

Voici donc une liste, non exhaustive, de sujets que je veux creuser :

• La sécurité informatique, avec un focus sur la sécurité des infrastructures.
• L'observabilité, en particulier les métriques DORA.
• Le self-hosting.
• Developer eXperience, le cloud est encore difficile d'accès quand il n'y pas de devops dans le coin
• Le MLOps en général
• en rapport avec l'item précédent, les containers et leur usage (j'ai récemment découvert les devcontainers par exemple)
• Python
• Rust
• ...

Et avec ces contraintes pour ne pas me disperser :

1. Deux sujets au maximum en parallèle
2. Un projet POC quand c'est possible (je ne me vois pas entraîner un LLM pour le moment...)
3. Documenter via un article sur ce blog. Cela sera certainement de la redite de ressources existantes mais j'aurai la satisfaction d'avoir fixé des infos au moins dans ma tête
4. Rester cohérent avec la fameuse work-life balance.

Je ne me mets pas de timeline à dessein. La machine est rouillée et je dois la relancer.

As a good pythonista, I'm fond of Flask framework for small/medium projects along Django for bigger ones. And, as a security-traumatized guy, I'm also using tools to manage my applications secrets outside of apps themselves. These times, I'm using Doppler which does the job for small projects and offer several useful integrations out-of-box.

For a long time, there was no related python library and, despite having a clear API documentation, I did not took time to build a small wrapper and use it im my projects. Luckily, an official SDK is available and can be consumed in python projects.

As I'm on a small Flask project¹, I quickly wrote an extension which injects secrets into my Flask project configuration. Here it is, as-is, caveat emptor. Feel free to amend / bugfix the gist, I may consider publishing a real library in the future.