A good part of my site was written by an AI. Today, it writes production code every day, right up to the companies that build it: this is no longer a hypothesis, it's already the reality. The question is no longer whether it can code, but how to adapt and stay at the controls.

My site answers that better than any speech. I started it knowing neither HTML nor CSS; it is far more polished today than at its beginnings, and it shows concretely how I work with AI.

Understand before delegating

I don't delegate what I've never understood, even a little. That's my first rule, and it's where the site began.

At first, I wanted to learn HTML and CSS. I designed a mockup in Figma, then built it by hand, almost without JavaScript. It was slow, sometimes clumsy, but every line showed me how a page holds together. Reproducing a mockup when you're discovering CSS is a good lesson in humility: you quickly realize that even centering an element properly means understanding what's happening underneath. I didn't come out of it an expert, only able to understand the basics and use them. That was the point.

Why bother, since the AI would have churned all that out in minutes? Because a tool you don't understand ends up owning you. The day it breaks, or the day you have to explain a choice, you're stuck. Understanding the foundations, even modestly, is what later lets you delegate without becoming a hostage to what you delegated.

Judgment first, code second

Once the basics are in place, the AI becomes a very fast executor. But an executor needs someone to decide, and that's where my work is: before and after the code, far more than during.

When I wanted to move the site from a student project to something more professional, I didn't settle for asking it to "make me a nice site". I set a clear idea of what I wanted. But an AI left to itself drifts everywhere; it needs a frame and a clear context. That's where my AI harness comes in, a topic that deserves its own article: the guidelines I feed it every time to keep it on my rails. No framework, reuse the components already there, keep the site fast and readable. I weighed the pros and cons of the options. The AI coded, I tested, I iterated, and I only published when the result matched what I wanted. On the other hand, the site's tech watch, that pipeline publishing an edition every week, I coded almost entirely myself: I only handed the AI the regeneration of the HTML pages, the repetitive part. Automation is my turf: it's where I want to keep exploring and learning.

This is maybe what AI changes most about the job. Making something is no longer necessarily writing it yourself: it's designing it, framing it, deciding it, and knowing how to recognize when it's good. Writing the code matters less, the architecture and the judgment more.

Control the result

I don't read every line of what the AI produces. My site's JavaScript, for instance, I haven't combed through. What I do know is what to test to check that a change works and hasn't broken anything else. My control is on the behavior, not on each instruction. Concretely, I don't start from what the diff contains but from what it can break. A CSS tweak is judged on screen, not only in the code. The real reflex is knowing what a change can affect elsewhere, including where you don't expect it, and going to check that rather than rereading everything.

That doesn't mean skimming everything. The level of understanding I demand of myself depends on the domain. On the front end, I accept delegating and not mastering everything; that's not where I focus my attention. On DevOps and cloud, it's different: there, even without knowing the code by heart, I want to understand what I'm doing and why, because it's my turf and I'll be judged on it. Knowing where to set the cursor of your understanding is already a decision.

Be honest

The last rule is the simplest and the most important: owning what comes from me and what comes from the AI.

It's not a matter of posture. You can only defend, explain, and evolve what you truly understand. Code you claim without having understood it isn't an asset, it's a debt: sooner or later, you have to know what it does and why.

This clarity is an asset, not a constraint: it tells me at every moment what I master, what I delegate, and what I need to dig into. It's the map I need to move in the right direction.

Where I make the difference

In a single year, the developer's job has changed faster than ever: AI now writes part of the code, and my value has shifted elsewhere. My expertise now concentrates on the engineering: understanding the problem, solving it, and staying able to explain and evolve what I ship. I lean on AI to speed up my learning and to hand off the repetitive or secondary tasks.

AI produces code better and better, and faster and faster. Putting my attention on how to write that code rather than on the problem to solve would mean losing my value. My difference is there: on the problem.

This site is the first place I practice it, and it's all visible. The code is public, if you want to see: github.com/TuroTheReal/Portfolio.