# AI Writes My Code Now, But My Engineering Habits Matter More Than Ever

## How my work changed

A lot of you know me from my Flutter articles. Lately, I've also been working on web frontend, AI tools, and a few side projects: a language learning web app, an Anki deck builder, and a trip planner.

The biggest change isn't the stack. It's that I barely write code anymore. These days I spend most of my time reviewing code, writing prompts, and building reusable instructions (skills) that help AI do better work.

You might expect that to mean I care less about good engineering practices. It's the opposite. The more code AI writes for me, the more those old habits matter. This article is about how I work now, what still goes wrong, and the habits that keep me safe.

## My AI setup: the right tool for each job

I use two AI tools, and each one has its own job.

- **Gemini** handles quick tasks: images, text content, small functions, regex, converting data from one format to another, CSS fixes, and test data.
- **Claude** handles planning and more complex work.

The split comes down to cost and quality of results. Small tasks don't need the most powerful model, and big decisions deserve one that thinks things through.

Your tools may be different, and that's fine. The point is to match the tool to the task instead of using one tool for everything. From here on, everything I share applies no matter which tools you use.

## Explore loosely, then plan properly

When I'm just exploring an idea, I don't plan much. I build quick prototypes, try things, and throw a lot away. That's the fun part, and planning too early slows it down.

Once the idea feels concrete, I switch modes. I describe the idea to the AI, ask for a proper plan, and give it skills with best practices for software engineering and for the stack I picked.

This step fills gaps I would have missed. Plans have caught things like:

- Error handling
- Offline support
- Testing
- Folder structure
- Accessibility
- How to store user data

These are the "boring but important" parts we tend to skip when we're excited about a new idea. Planning them early gives me a much cleaner codebase later.

## Choosing skills carefully

Skills are reusable instructions you give an AI agent, like a set of best practices for a framework or a checklist for reviews. A good skill can make a big difference. A bad one can quietly lead the AI in the wrong direction, or even worse, introduce security vulnerabilities into your project.

I find skills by watching videos from other developers who explain which problems a skill helps with. Then I decide if it fits what I need.

I'm also careful about where they come from. I only use skills from trusted repositories that scan them for vulnerabilities. A skill shapes everything the AI produces in your project, so it deserves the same caution as any package you install.

## Where AI still lets me down

AI isn't perfect, and I don't want to pretend it is. A few things still frustrate me:

- **Over-complicated solutions.** Sometimes it picks the clever answer when a simple one would do.
- **Confident but wrong answers.** The code looks right, but it isn't. Worse, it can go in circles, trying fixes that don't work again and again.
- **UI design.** Early on, the designs were pretty bad. To be fair, models have improved a lot, and this is getting better. I've also learned to help it along by setting up a proper design system and giving the AI good design skills to follow.

None of these are deal breakers. They're just reminders that I still need to check the work.

## Reviewing code I didn't write

Since I don't write the code, reviewing it is my main job. But I don't read every line either. I ask the agent to summarize the changes and highlight the points I care about. Most of my effort goes into prompts and skills that help me see the important details.

So how do I stay in control? I build trust step by step.

1. At the start of a new project, I review more by hand.
2. As I learn what tends to go wrong in that project, I write it down.
3. Over time, that becomes a review skill and checklist made for that specific project, which I can rely on.

My checklist is different for each project, since it's built around that project's needs. But most of them share common points, which also match what many developers recommend:

- **Secrets:** No keys, tokens, or private data in the code, test data, or logs.
- **Security:** Permissions aren't too open, inputs are validated, and no data is exposed.
- **Understanding:** I can explain why every piece of code is there. If I can't, it doesn't go in.
- **Edge cases:** Empty input, null values, single items, and unusual characters are handled. AI tends to get the happy path right and miss the edges.
- **Meaningful tests:** Tests check what the code is supposed to do, not just copy what it already does.
- **Simplicity:** The solution is simple and clear, not just clever.
- **Cleanup:** No old code left commented out "just in case."

## Tests you can actually trust

Here's a moment I think many of you know: every test passes, you open the app, and things are broken.

If I'm trusting AI to write and maintain my code, I need at least one thing I can fully trust, and that's the test suite. A big pile of tests means nothing if they don't catch real problems.

The testing guideline I follow (adapted from one I found online) comes down to a few simple ideas:

- **Only test what your project owns.** Trust that well-known libraries already work. Focus on your own business rules, calculations, decisions, and state changes.
- **Every test needs a reason to exist.** Before adding one, you should be able to name what it protects and a real bug it would catch.
- **Don't let mocks fool you.** If the expected result just comes from how the fake was set up, the test proves nothing.
- **Use the right kind of test.** If you can't test something properly with what you have, write it down as a gap instead of writing a fake test.
- **Delete useless tests.** Tests that only check simple pass-through code or library behavior are just noise. High coverage doesn't mean good tests.

This matters even more with AI, because AI is very good at writing lots of tests that look busy but don't protect much.

## The scary parts: secrets and overly eager agents

There's a worry that sits at the back of my head: what if I accidentally put an API key in a page I publish, or commit it to my repository? When AI is writing most of the code, it's easy for something like that to slip through.

Here's what I do about it:

- **Keep all secrets in a gitignored file.** Always, from day one.
- **Ask AI to scan for sensitive data in logs.** It's easy to log a token or user detail by accident.
- **Run agents in sandboxes.** This gives them a hard boundary, so they can't touch my other files.

The other scary part is how persistent AI agents can be. Earlier this year, a developer in Melbourne asked his AI agent to book him into a popular gym class. He was fourth on the waitlist and asked if it could move him up. The agent found that the gym's booking system never checked who was cancelling a booking, so it cancelled the reservation of the person in first place, without being asked to. It couldn't undo it afterward. ([Read the story](https://thenextweb.com/news/openclaw-ai-agent-gym-booking-api-flaw-australia))

The booking system did check permissions for making bookings and joining the waitlist. It just missed one action, and that was enough. More and more people use AI agents, and agents will try every option to finish a task. So if your app has a security hole, someone's agent may find it, even when nobody meant to attack you. That's why good tests, guardrails, and clear boundaries still matter so much.

## Keep your engineering habits

If you're thinking about leaning more on AI, here's my one piece of advice: keep your engineering habits.

AI changes how we build software. It doesn't change what good software needs. Secrets still belong in safe places. Tests still need to catch real bugs. Permissions still need to be set up right. And someone still needs to be accountable for what goes in.

A good place to start is finding trusted skills with best practices for your stack, so your AI follows good patterns instead of guessing. Whatever tools you choose, the same habits apply.

I'd love to hear how you're using AI in your own work. What's your setup, and what has gone wrong for you? Let me know in the comments.