Skip to content

Code Capsule Posts

Requirements-as-Code for AI-Augmented Software Engineers

Most content about AI model predictions is not going to age well given how quickly the frontier is moving on what is possible these days. Yet, I find it useful to write such articles as they form the basis of the ongoing conversations about how those models are going to impact all of us in the tech industry.

After my recent trials with vibe coding, I wanted to push the experiment further and apply second-order thinking to project what software engineering will look and feel like in a future in which every software engineer is “augmented” with LLMs.

When you think about it, asking LLMs to write code is not so far from the experience that product managers have today with human software engineers. Most product managers are not technical enough to verify that the products built by software engineers are accurate, correct, and secure. To them, the software is a black box, and they have to trust that the software engineers understood the user stories, and that the QA engineers wrote the right set of tests. This is pretty much what vibe coding is all about, except one asks an LLM to write code instead of a human.

And of course, a product manager might notice bugs or issues, which are logged as tickets for the team to look after. This is similar to the process one has with an LLM, by inputting error logs into the model or asking it to make changes, or even with agentic AI systems that detect error messages and automatically pipe them into additional LLM iterations until the code compiles and the requirements are met.

Software engineering will move away from writing code using programming languages to writing PRDs and acceptance tests, what I call “requirements-as-code.” This is because if you are able to describe your requirements with enough context and details, and if you can correctly describe the expected behaviors to test, then the AI models will be able to both build what you want, and deterministically test all assumptions to guarantee that the code is accurate and correct.

It does not matter what’s in the code as long as you can guarantee that its outputs are what you expect for a given set of inputs. And it might not be entirely correct all the time, just like software written by humans, but if the guarantees are met 99.99% of the time, then they are correct enough to meet commercial standards and be shipped to production.

Just like infrastructure-as-code became a thing over the past decade, we are going to see requirements-as-code becoming the new thing, with new industry standards being created to describe PRDs in a clean and maintainable way for LLM inputting, and those PRDs will be stored with version control repositories to track changes.

Now you might ask, why would we need requirements when we have the source code, can’t we just use the code as requirements? Yes and no.

Yes, ultimately the code can act as your requirements, but also no, because if you rely on the code, then you’re still thinking like a software engineer of the year 2025.

Remember, this is already the future, we’re in the year 2030, and most software is now a black box, just like assembly code is an alien language to most software engineers. Having the source code isn’t particularly useful if you can’t read code so well, what you want is a set of requirement in a natural language, so that as a human, you can understand what is present or missing in the expected behaviors, and so you can make adjustments easily if needed.

Those requirements will be separated into categories, like functional requirements, UX/UI design requirements, data model requirements, and security requirements.

Until now, vibe coding meant endless back‑and‑forth with an AI model. Agentic systems remove that friction: they iterate in a closed loop until the code meets every requirement and clears all acceptance tests, without the need for human intervention. You could even have multimodal AI models perform end-to-end testing from the final consumer’s perspective.

Traditional tooling like package managers and CI/CD pipelines will collapse into one “Regenerate and Validate” button that triggers everything, from architecture generation down to final QA testing.

Below is a simplified diagram that illustrates what the process of writing software will become in the near future. As a human operator, you will write requirements and tests, and then everything else will be a black box.

Human inputs requirements and tests, and the AI models handle everything in between.
Human inputs requirements and tests, and the AI models handle everything in between.

The Main Implications of LLMs for Software Engineering

Based on the above, it’s now only a matter of a few years until a high percentage of all human-driven programming goes away. I spent some time projecting into a second-order thinking what are the main implications I’m forecasting. I had a hard time organizing them holistically so instead I’m presenting them individually in the sections below.

Solving the Prompt Management Problem

As of April 2025, the frontier has moved to AI Agents and Agentic AI. And yet, the ChatGPT interface remains impractical to organize past conversations or make sense of one’s most used prompts.

I find myself storing my prompt templates in various text files, google docs, or copy-pasting from previous prompts. It’s all a big mess and a waste of time. So I needed a tool to management my prompts.

To solve this problem I’ve created Prompt Library, a web-based prompt library and composer. The tool lets you create, edit, search, and tag your prompts, insert variables and placeholders, etc. All data is stored locally for more privacy, and you can export your prompts as a JSON file. You can check out the full list of feature on the GitHub project page.

Future developments will include a way to store the history of changes made to a prompt, and compare different versions, and possibly to be able to store “prompt paths,” that is to say how to represent a graph of prompts used in sequence for more complex tasks.

You can check out the tool here: https://github.com/goossaert/prompt-library

If you do try it and have feedback, leave a comment below

Screenshot

My Takeaways on Vibe Coding

I recently OpenAI’s o3-mini-high model to generate a small web application, which I have published on GitHub.

My use case was simple: I wanted a way to send ChatGPT conversations and research sessions to my e-reader so I could read them while avoiding the impact of blue light from screens. I use the application pocket to send web pages to my ereader, but OpenAI conversations are behind a login wall, and therefore cannot be saved via the usual Pocket web extension.

First, I asked the model for different approaches to solve this problem, and it gave me several options, including one in which as a user I would select text from a page, and click on a bookmarklet that would send the text to an API which would save that text in a database. This is the option that seemed the best so I stuck with it.

What Special Forces Can Teach Us About High-Impact Engineering Teams

There’s a reason Special Forces bypass traditional military hierarchy, and it’s the same reason high-performing tech teams should too. Being French and having an interest in organizational structures and cultures, it was logical that I ended up learning about how the French military is set up. I spent time learning…

How Many Reports For Engineering Managers & Other Bedtime Stories

The number of direct reports for an engineering manager is a recurring debate among tech managers. I’ve heard many different versions of it, and I’ve witnessed many implementations, which led me to have strong battle-tested opinions on the topic.

So, how many reports should an engineering manager have?

I’m a fervent fan of High Output Management by Andy Grove, and in that book, he shares that “A manager whose work is largely supervisory should have six to eight subordinates; three or four are too few and ten are too many […] this ensures half a day per week for each subordinate.”

And the keyword here is “supervisory” which means the manager has a medium amount of individual responsibility, however, that level of responsibility will depend on how your organization and yourself want to define the role of engineering manager.

A lot has also been written about managerial archetype, but it all feels either subjective or generic to me, and the rationale is often not clear. Things are actually more complex than just following a rule of thumb, and I hope to shed some light as to how I think of it with this article.

Performative Leadership: From Cargo Cults to OKRs

After working in leadership roles for a decade, I’m still baffled at how cultish large organizations can be.

No matter where I look and what former colleagues tell me of the places they now work at, I hear the same stories of tools and structures: dysfunctional performance appraisals, OKRs of dubious quality, broken managerial hierarchies, and always some flavor of agile methodologies when in fact nothing is agile.

Every single of those tools and practices can usually be tracked to a single company that developed it to solve a problem they had locally, and then some consulting firms heard of it and productized it into training material that they could charge money for.

And so we end up with processes, each from its own distinct cultural context in which it was working and effective, being passed to consultants who don’t fully understand that culture. And then those consultants go on to train employees at other companies who find themselves two degrees removed from the source, and who naturally are struggling to make sense of it. And I’m being generous here, because often you have a chain of consultants who have taught one another to the point that everything has been watered down to oblivion, and all that’s left is language.

Without going into too much detail, I will start by covering three examples of decontextualized practices and how they fail to fulfill their original purposes.

Solution-Oriented Coaching, or the Lost Art of Effective Conversations

After spending more than a decade in different managerial roles and learning various aspects of the job, I came to the conclusion that as a manager, conversations are the ultimate tools of the trade. They enable you to direct, motivate, and engage people, and to pull information from the environment.

I realized at some point that many managers, myself included, were too reliant on gut feelings during decision making, or were biased in searching for problems to solve in teams or in people—and therefore self-prophesying problems—which was not always constructive. I was able to track down this behavior to a simple lack of rigor and effectiveness when conducting conversations.

It’s amazing how many companies do not train their managers, or when they do, train them poorly on how to conduct a conversation effectively so that it will lead to results. So I started looking for better solutions to making my direct reports accountable for their work, giving direction and motivation, and supporting them along the way, specifically via conversations.

On that journey, I stumbled upon a therapy framework called Solution-Focused Brief Therapy, or SFBT for short, and it has changed the way I interact with people at work so much that I decided to write this article so I could share my experience.

This article is the culmination of my personal journey with SFBT over the past three years. It covers the basics of SFBT, how I’ve used it in the workplace, and the some limitations I’ve encountered. The article concludes with a long list of resources, many of which are free, to help you dive further into SFBT.

For the rest of this article, I will refer to SFBT applied to coaching and management as Solution-Focused Coaching, to make it clear that I do not want to go into the realm of therapy, given that I am neither trained or medically licensed for it, and that providing therapy is not my role as a peer or manager in a workplace environment.

Finally before jumping into the topic, I want to clarify that almost the entirety of the ideas presented in this article are not mine. They come from various therapists and clinicians who practiced and honed those techniques and shared about their findings in books and articles. I do not claim to take credit for any of those ideas, my main contribution here is that I am trying to bridge the usage of those techniques from a therapeutic setup into a workplace setup, and I am also sharing my personal experiences and findings in doing so.

The field of SFBT is gigantic, and in this article I will only be able to cover the surface. My goal is not that by the end you would be fully trained, but rather, that you would see the benefits for yourself to use those techniques, and that it would motivate you to spend more time on learning SFBT. So in short, this article is my attempt at selling you to the benefits of SFBT.

Part 4: Beyond The Code and What I’ve Learned – Ethereum Payment

In this series of articles, I’m doing a walkthrough of a hobby project I’ve worked on, a payment system for the Ethereum blockchain. You can read the intro article for more context about the project.

I have covered the majority of the technical details in parts one through three. In this fourth and final part, I will to cover the following:

  • How to extend the code to support more features or data providers
  • Important things to consider when dealing with blockchain data
  • Insights on what blockchain and web3 can enable in terms of product experience design

The content of this article will feel like a collection of somewhat disconnected ideas, and the goal is to do a brain dump of the biggest takeaways and learnings I had while I was developing a system for the Ethereum blockchain.

Part 3: Processing Payments – Ethereum Payment

In this series of articles, I’m doing a walkthrough of a hobby project I’ve worked on, a payment system for the Ethereum blockchain. You can read the intro article for more context about the project.

For this article, I will assume that you have read part 1 about authentication and wallet management, and part 2 about the data models used in the system. Therefore, I will start from the assumption that you’re aware of the basic foundation on how to let users connect their crypto wallets to as website, how to display a list of available digital products that they can buy from, and that you are also somewhat familiar with the data models presented in part 2.

In this part, I will cover how payments are processed and validated. This includes the following steps, in order:

  • Server-side prevalidation: validating, before even processing anything, that the wallet is authorized to buy a particular digital product, and that this product is available.
  • Purchase: sending a payment transaction to the Ethereum blockchain for the required price, and getting a transaction identifier in return (also called a “transaction hash”)
  • Polling the blockchain: using the transaction hash to check if the transaction has succeeded or failed.
  • Triggering post-payments actions: dealing with the aftermath of the transaction status, which means showing an error message in case the transaction failed, or starting further steps by allowing access to resources in case the transaction succeeded.

The Ethereum blockchain makes it very easy to process payments, because every transaction is given a unique transaction hash, which means that once you have submitted a transaction to the Ethereum network for validation, all you need is this transaction hash, and you’ll be able to track the status of the transaction by polling the Ethereum blockchain.

In reality, for a small application such as the hobby project I’m presenting here, there is no need to poll the Ethereum blockchain directly. Instead, my program uses a third-party provider that makes polling the blockchain easier via an API. Many medium to large applications nowadays are running their own Ethereum nodes so that they can poll the blockchain directly. It costs them extra teams and complexity to maintain that infrastructure, but it comes with the benefits of higher trust and control of their data, and also processing speed. For them, the tradeoff is worth it.

Processing Payments

Below is a systems diagram showing how I have implemented the payment processing part. It assumes that the user has connected his wallet and already obtained a JWT that identifies him uniquely.

The diagram contains a description of each step, and the rest of this section gives further details as to what happens in each step.

Systems diagram showing how a purchase gets processed, from the user clicking the payment button and the transaction that it triggers on the user’s wallet, to validating that transaction and creating a new JWT to give the user access. (click on the image to enlarge)

Part 2: Product Data Models – Ethereum Payment

In this series of articles, I’m doing a walkthrough of a hobby project I’ve worked on, a payment system for the Ethereum blockchain. Go read the intro article for more context about this project.

In this part, I will cover the following topics:

  • Product details, whitelistings, coupon codes
  • Displaying purchases and subscriptions, products available, and past purchases
  • Data models for products and whitelistings

None of what is described in this article is about web3, it’s all really web2 development. However, I do have to describe it to lay the foundation for parts 3 and 4 that will be focused on interacting with the blockchain, and with a recap of what I’ve learned about what crypto wallets and blockchain for developing mass-consumer product experiences.

Below are the data models used for products, purchases, and whitelistings and coupons (click to enlarge).

The data schemas used to represent products, purchases, and whitelists/coupons (click to zoom)

The follow diagram shows three user flows: the first flow shows products for non-signed in users, the second flow for signed in users, and a third flow just to display the current status of the access rights.

System diagram showing three user flows to display available products, past purchases, and current access rights.