From one line of Python to an AI SDLC

I remember early 2023, when ChatGPT came into my hands. It was capable of writing, like, one line of Python correctly, after I copy-pasted the whole documentation into it. And it already clicked in my mind that it was the tool of the future, and that it would change the world, how we think and how we work. Ever since, I’ve been using LLMs for everyday work. At that exact moment I knew that AI was going to help me a lot with the part I didn’t like the most: manual work. As one of my professors at university said, a student must be lazy but nimble.

By early 2024 I was using GPT-4, which was so good. It was able to write some functions, and quite good ones! I was building different weather-related projects with it, and instead of polishing plots for like an hour, I was able to just say what I wanted and get the code for the plot right! That felt like things were already better! Like I could build things, and I didn’t have to spend days learning a new framework or programming language.

Later that year I was building my first real analytics project, with a database, ETL, Docker and a BI system, running on a cloud machine. All I knew before that was just math, advanced data analytics and classic machine learning for research purposes in weather science. And now I was building software that brought those analytical skills to the whole company, to make data-driven decisions. GPT-4o was the one that powered it, together with my feeling that things should be automated and that I was the one who could make this work. And I actually made it and learned a lot along the way.

All it was at that moment was just a bunch of chats, or, most of the time, one chat from planning to building to debugging. And I was able to build systems without deep knowledge: I just made things work, and LLMs were the powerhouse behind that.

Then fast-forward to early 2025, and I got a position where I’m building analytics systems: many people use them in their everyday work and rely on their robustness, while for data analysts I focus on improving their development experience. Here I started to get deeper into planning and guiding LLMs to write correct code that I verified, and I was able to achieve a lot with Sonnet 3.7, the frontier model at the time. I was able to build robust systems alongside doing a lot of research in weather science, where I tried to stop building block by block and instead tried the /goal idea: just write the intent and see what the model can do. And it just did the little project flawlessly. All I needed to do was give the right intent.

And 2025 was the year when more and more people got into using LLMs to code, and it was amazing to see that everyone now understood what I had been doing for years: that this is the future. And the term “vibe coding” felt so good at that moment. Finally, I got a name for my way of working.

During that time I started developing a system with an LLM under the hood, and other data-related projects, and the main question was verification: how can we make sure that the AI is working in the correct way and writing correct code? I tried TDD and was quite happy with it for a while, but at some point I understood that tests are restrictions on code, and some of the time the AI just overfits these tests. We need to find a way to give more freedom to LLMs while maintaining quality. That was the question that bothered me for a year.

In summer 2025 I got into my first complex project that I wrote completely with AI. There I understood that deep planning is the way to make things work. You need to define most of the code in text: what tools to use, the data contract, the Pydantic models. I defined and verified them row by row, and it worked! Just lots of manual verification and checking cases, but it worked. Zero hand-written code, just plain English.

From late 2025 to early 2026, everyone understood that Claude Code can be used by non-technical people to just build things with natural language and no knowledge behind it. Yeah, these are kinda simple things, not a widely used, distributed data analysis platform with multiple microservices, but small things inside it are easily managed by agents. “Agents” is the word of 2026.

Then, in spring 2026, OpenClaw and Hermes came into play. And now agents are in your daily life. Something is wrong with your laptop: tell the agent, “Please solve X, I want it to be fixed.” Or “Here is a PDF, I want to read it on my e-reader.” Or “Add a notification on my iPhone.” And all of that gets done from one chat. And here you know that you can tell agents to go wherever they need: just give them a goal, suggest a path if you know it, and that’s it. The path is really optional. Agents probably know better than you.

Summer 2026 was all about how to write tests. I came to understand that plain tests are not good enough, plus we are definitely shifting towards the idea that you are not going to need engineers to build and improve data products. And here again we got the idea of intent elevated. The core idea is that business people write what they want to get, and then an analyst translates this into requirements, or, in our case of BDD, into scenarios. In this paradigm we describe the logic in scenarios, in structured English that describes the behavior of the system. Using these scenarios, we build sophisticated test cases that will be relevant at any stage of the product life cycle. Once they are defined, we can change the code however we like. The goal is to make these scenarios pass.

And here we get to the current moment: BDD AI SDLC.

• Intent is the part we know from the last few years: we need to describe what we want to the agent in detail, and that is the core of getting things done.
• Spec as scenarios in BDD allows us to have a single source of truth for the logic that should be supported in the data product.
• Planning is key to building a robust system, and here the developer is still the one who can steer the technical parts in the right direction and actually help the agent make the architecture decisions.
• Build just became something we do not manage at all: the LLM is going to build better than you ever thought possible and save you so much time.
• Review is to run the scenarios and check that they pass.
• Watch is the way to integrate an LLM into monitoring and actually make the LLM maintain the project.

And I think that last step is what I’m going to get into. That step will close the loop, make it active all the time and, on its own, ask me as the engineer to check what’s going on.