Until recently, software development followed a relatively stable and well-established process:
- Write functional and technical specifications
- Design the architecture and software components
- Implement backend and frontend code following best practices (unit tests, functional tests, integration tests, naming conventions, etc.)
- Iterate in an agile way
With the rise of AI, what has actually changed?
AI itself is not new. What has changed fundamentally is the emergence of large language models (LLMs) and, more broadly, the LLM ecosystem. We now consider LLMs capable of understanding complex contexts with a surprising level of accuracy. Given a structured prompt and sufficiently detailed context, we can realistically rely on them to produce working code.
This article is a reflection on my own experience and mistakes while developing a personal project using LLMs.
1. AI Is Fast. So We Code Fast (Too Fast)
I decided to restart a personal project in financial accounting. On paper, this is an ideal use case for AI: CRUD logic, data processing, reports, and a clean UI that can be generated almost “for free”.
I did write specifications, one, two, maybe three pages. In hindsight, this was far too short. Even with brainstorming sessions with an LLM, I never produced real specifications. That was my first mistake.
My goal was speed: get results quickly. That mindset is fine for a proof of concept, but not for a personal application meant to evolve step by step over time. I obtained quick results, but I failed to define clear coding guidelines: short and testable functions, modular design, explicit boundaries.
Speed hid structural debt.
2. First Attempt: Antigravity
My first experiment was with Antigravity, using the free subscription. Each session allowed roughly one hour of interaction, and I ran several sessions over time. Antigravity also explicitly asked for feedback, which I provided.
I let the tool handle everything: brainstorming, design, and implementation. It proposed a Python backend and a React frontend. In my specifications, I asked for CSV deduplication based on either a key or a hash defining uniqueness.
Initially, it handled deduplication per CSV file. Managing deduplication across multiple CSV files required several iterations, and even then, I was not fully convinced by the solution.
In retrospect, this requirement should have been stated clearly from the very beginning. The technical stack was also not really my choice. While Python has evolved significantly (typing, generics), I still consider it better suited for scripts, data analysis, or SQL tooling than for large, long-lived, reliability-oriented systems. React was also clearly overkill for my UI needs.
In the end, I lost time trying to correct early design decisions. I eventually gave up on this attempt.
First conclusion:
Before writing any code, explicitly ask the LLM to:
- Brainstorm the technical stack
- Challenge your specifications
- Challenge your screen design and architecture
3. I Almost Stopped Reading the Generated Code
I then switched to ChatGPT.
I used a small script to linearize the entire codebase into a single file, then provided:
- The prompt
- The specifications
- The full codebase
This time, I explicitly chose the stack: Rust and HTMX.
I asked the model to generate code and moved forward milestone by milestone until I reached an MVP. This entire phase did not take weeks, but less than a single day. During that time, I barely looked at the code itself and focused almost exclusively on delivered features.
That was another mistake.
Files and functions were too large, poorly structured, and completely untested. The first refactoring phase was unavoidable and took time. I performed it manually through copy-paste, which inevitably introduced friction and small errors.
Second conclusion:
You must give explicit coding guidelines to the LLM. Refactoring with a human in the loop is error-prone. As context grows, LLM accuracy degrades. At some point, I had to ask ChatGPT to rewrite the specifications, the prompt, and the context, and then restart with a fresh session.
4. The Code Can Be Surprisingly Reliable
Despite these issues, some results were genuinely impressive.
For example, I needed recursive SQL queries to manage hierarchical categories for analytic accounting. These categories feed charts at different aggregation levels, rolling income and expenses up through multiple layers of subcategories.
The LLM generated correct recursive SQL queries on the first attempt.
That was a strong signal.
Third conclusion:
The future of programming is already here. The key skills are no longer syntax mastery, but:
- Software design principles
- Writing high-quality specifications and prompts
- Defining clear context
- Knowing what good code looks like
At some point, we may stop reading most of the code altogether. Code quality could be enforced automatically through metrics, static analysis, and validation pipelines.
5. Speeding Up with AI Agents
For now, I continue developing through direct interaction with ChatGPT. This phase is crucial: it helps understand how to work with AI effectively.
The next step is AI agents. Tools like LangGraph already exist. But humans must remain in the loop.
Driving a car is not the same as driving a Formula 1 car. A small mistake at high speed leads to massive refactoring. Rollback strategies become essential.
One promising idea is to have an agent managing Git commits automatically, committing not only code, but also context, prompts, and specifications at each step.
That will be my next experiment.
6. Skills in the Age of AI
AI may be naive, but it is extremely fast. Software development will change deeply.
Tomorrow, code itself may no longer be the primary artifact.
This raises a philosophical question: if nobody learns to code anymore, a claim sometimes heard online, are we really ready to board the rocket?
I do not think this is the real issue. Testing itself can be automated independently of implementation details, through acceptance tests and specification-driven validation.
The core skills to master in the age of AI are:
- Writing precise specifications and instructing AI to implement them
- Writing validation and acceptance test scenarios
- Writing code specifically designed for AI agents to extend
- Communication, because coding is, at its core, a communication problem
7. An Impressive Tool, and a Philosophical Trap
My reflections end on what may sound like a paradox.
LLMs are astonishing tools. They force us to rethink what intelligence actually is. Perhaps our own brains are not so different from LLMs: trained on massive datasets, shaped by reinforcement, sometimes brilliant, sometimes deeply flawed. Even the emotional dimension can be trained or simulated, as recent experiments suggest.
This does not make LLMs human, but it does blur boundaries we once considered obvious.
The real risk is not that machines become too intelligent, but that humans stop exercising judgment. When answers are always one prompt away, learning itself can become optional; and that is the real trap.
At the same time, I am convinced that companies which fail to understand the importance of human relationships; trust, empathy, collaboration, responsibility may disappear. Technology can accelerate execution, but it cannot replace meaning, intention, or social cohesion.
AI raises profound philosophical questions, not because it replaces us, but because it reflects us. Understanding that reflection may be one of the most important challenges of the coming years.
Comments