Ashmaad
What It is Really Like to Use AI for Real Coding Work
I run a small tech site. I built the theme myself, and I write most of the content too. Over the past few months, I’ve built up real AI coding experience this way, not as a novelty, but as a daily working habit.
People talk about AI coding in two ways. Some say it lets anyone build an app in a weekend through what’s often called vibe coding. Others warn about AI writing broken or unsafe code. Both of these things can be true. But neither one tells you what a real AI coding experience looks like on a project you already have. A project with bugs, history, and real users.
So here are three real situations I ran into. Each one taught me something different about where AI actually helps, and where it doesn’t.
The Bug That Was Hiding Somewhere Else
My homepage broke one day. Nothing dramatic happened. One section just looked slightly off. The kind of thing that makes a site feel wrong, even if you can’t say why right away.
My first move was to check the CSS for that section. The code looked fine. I checked it again. Still fine. This is the moment where things often go wrong. You start changing code that was never the problem, simply because it’s the code in front of you.
What actually helped wasn’t a quick fix from AI. Instead, it helped me search in the right direction instead of guessing. The real cause was an old cached style file. A caching tool had saved an older version of the page and kept serving it, even after I updated the real styles. My CSS was correct all along. It just wasn’t being used.
Why Ruling Things Out Beats Guessing
This taught me something useful. Good AI assisted debugging isn’t about jumping straight to an answer. It’s about ruling things out, one layer at a time. Is the problem in the code itself? In the browser cache? In a plugin’s cache? Working through that list with a tool that doesn’t get stuck on its first guess saved me real time. The actual fix was simple. I just had to clear the cache. Finding the real cause was the hard part.
A few smaller bugs showed up during the same check. One was a mismatch in how a caching key was created versus how it was read, so the two sides were quietly missing each other. Another was a database query running too often instead of being limited or cached properly. None of these bugs were exotic. They were simply invisible by just reading the code, because the code looked fine on its own.
The lesson: AI is most useful as a way to organize your search for a bug, not as a machine that hands you the fix. If you skip the search step on anything beyond a tiny bug, you risk fixing the wrong thing while the real cause keeps causing problems somewhere else.
Building a Feature Where the Hard Part Wasn’t the Code
I wanted to build a small tool for my site editor. It would let me search for any of my own articles by title, then drop in a nice looking card that links to it. This way, I wouldn’t need to copy and paste raw links every time I wanted to connect two articles.
This sounds simple, and in a way, it is. But this part of my AI coding experience showed me something important about AI and coding. The hard part was never the code that runs on the public page.
The part that actually displays the card is easy to write. For example:
function render_link_card($attributes) {
$post_ref = isset($attributes['postRef']) ? $attributes['postRef'] : '';
$linked_post = resolve_post_ref($post_ref);
if (!$linked_post) {
return is_admin()
? '<div class="card-empty">Start typing a title above...</div>'
: ''; // show nothing on the live page if the link is invalid
}
$permalink = get_permalink($linked_post->ID);
// build and return the card's HTML here
}A search feature, plus a function that turns a post into a styled card. None of this is hard, and AI can write working versions of it fast.
The Part AI Couldn’t Decide For Me
The truly tricky part is the editor experience. For example, you need to slow down the search requests so you’re not sending one on every single keystroke. You also need a backup plan. What happens if someone searches for a title that doesn’t exist? Should they be able to paste a raw link or post ID instead? AI can write the slow-down logic easily. However, it can’t decide on its own that showing nothing on the live page, instead of a broken looking empty box, is the right choice when a link is invalid. That’s a judgment call about what should happen when things go wrong. It only gets made correctly if a real person thinks about it.
I also made one choice on purpose that’s easy to skip if you’re moving fast. The block doesn’t save any content into the post itself. Every time the page loads, the link is built fresh on the server. This means that when a search engine visits the page, it sees a real link in the raw page code right away. It doesn’t have to wait for anything to load through JavaScript first. That matters a lot if you care about your site being properly understood by search engines. AI will happily build a version of this same feature that works fine on screen, but saves the link in a way that depends on JavaScript loading correctly. You might never notice the difference unless you went looking for it.
The lesson: the code AI writes is rarely wrong on its own. But it’s often missing the harder questions. What happens with bad input? What happens if a linked post gets deleted later? Those questions are still your job to ask, not the AI’s.
The Code That Worked Perfectly and Was Still a Bit Wrong
The last example is small, but it’s the one where this AI coding experience got genuinely humbling.
I added a “you might also like” section at the bottom of every article. It pulls a few other posts from the same topic, so readers (and search engines) can move between related articles more easily.
$related = new WP_Query(array(
'posts_per_page' => 3,
'post__not_in' => array(get_the_ID()),
'category__in' => array($primary_cat_id),
'orderby' => 'date',
'order' => 'DESC',
));This code ran without any errors. It looked correct on every page I checked. The real problem only showed up once I looked at the whole site together, not just one page at a time. Because the code sorted by newest first, the same few recent posts kept showing up everywhere in that topic. Meanwhile, older posts in that same topic never got picked at all. So the newest content kept getting more attention, while the older content stayed buried. The feature was working exactly as written, but it still wasn’t doing what I actually needed.
The fix was small. I changed the sorting to pick posts randomly instead of by date. Now older articles get a fair turn too. But the real issue wasn’t really about that one line of code. My code did exactly what I asked for. So really, what I’d asked for wasn’t quite the right thing to ask for.
The lesson: working code and code that does what you actually need are two different things. That gap is easy to miss when you’re looking at just one file. It usually shows up later, once you look at the bigger picture, which is also the most annoying time to go back and fix it.
What This AI Coding Experience Taught Me
None of these three stories involve a disaster. No security hole, no major outage, nothing dramatic. That’s actually the point.
Using AI on a real, ongoing project usually isn’t about huge wins or huge failures. It’s a steady stream of code that looks correct, where you still need to ask, “Correct compared to what?” That question matters every time.
AI genuinely helped me move faster in all three of these stories. But that speed only worked because I was already asking the right questions. It wasn’t a replacement for asking them. If you’re keeping something running long term, and that probably includes whatever you’re building too, that difference is the whole game. If you want the bigger picture behind all this, I broke down the wider trend in a separate piece on what vibe coding actually means, which pairs well with this one.
