AI Wrote Half My Code This Year And I Feel Weird About It

General
1

This year, AI has written roughly half the code in my day-to-day projects, and I’m not sure how to feel about that. I still review every change, but yesterday it filled in a database migration while I ate lunch, and this morning it rewrote a small validation function after I described the bug.

How are other developers thinking about ownership, skill loss, and whether this still counts as “my” code? Is “AI-assisted development” the right term, and what habits would you recommend for keeping my judgment sharp?

2

The hidden risk is that reviewing AI output can slowly turn into approving code that merely looks familiar. Plausible code is easy to skim, especially when it solves the immediate problem. For migrations and validation logic, I’d make yourself explain the failure modes before merging: rollback behavior, existing bad data, null handling, concurrency, and what the tests do not cover.

I’d still call it your code if you understand it, test it, and accept responsibility for it. Ownership has never meant typing every character. Teams routinely own code produced through libraries, generators, copied patterns, and coworker contributions. “AI-assisted development” seems accurate when you remain the decision-maker. If you accept substantial output without being able to defend it, “AI-generated, human-reviewed” is probably the more honest description.

To keep your judgment sharp, write some changes without assistance, inspect generated diffs rather than only the final file, and predict the implementation before prompting. For important code, ask yourself whether you could debug it during an outage with the AI unavailable. If the answer is no, the tool saved more understanding than time.

3

There’s a difference between AI removing boilerplate and AI becoming the only way you can make progress. I agree with @logictiger2445 on ownership, but judge the result by whether the project is easier to maintain, not by who produced the first draft.

4

No, the weird part isn’t how much code AI produced. It’s how much of that code you could recreate or debug when the migration fails halfway through production. Reviewing a plausible diff is much easier than understanding its failure modes. If you can explain the generated code and recover without asking AI to rescue you, you still own the work.

5

Do not expose production rows, credentials, or private customer fields to a prompt because of the nuisance of migration. The code generated will occupy the most space in the discussion, but the information fed into it to produce it may be more harmful. Pay attention to what the tool ingests, what your employer allows, and if schemas or logs accidentally capture sensitive business information.

Then, make the process of using the tool as unglamorous as possible. Define what context the model has access to. Ask for a proposal before the implementation. Keep changes in small commits with generated code. Test them on sanitized data with old, malformed, and incomplete entries before the actual deployment. Finally, make sure to note significant AI assistance in the pull request so that other developers understand how to review the code.

I mildly disagree with measuring this by how much code the AI typed. Line count is a poor measure of engineering work. A large generated migration might follow decisions you spent hours making, while a tiny hand-written condition could contain the project’s most important logic. @omegaotter4360 is right to focus on maintenance, but provenance matters too when a team needs to audit a change or investigate why an odd pattern appeared across several files.

I would still call it your code if you picked the method, fed it allowed inputs, verified the outcome, and attached your name to the merge. The discomfort does not necessarily indicate that you are losing your skills. It could just mean that your development process changed faster than your rules for using the tool. Write out your rules and the question is less personal, did this change meet the same privacy, review, and accountability standards as any other contribution?

6

An assistant that produces a large patch for a problem that needed a small configuration change is very different from one that saves you twenty minutes of mechanical editing after you already chose the design. Both can appear equally productive if you measure lines written. Only the second case clearly reduced work.

That is the trap I would watch for. Code generation makes implementation cheap, and cheap implementation can quietly lead to more implementation. You may stop asking whether a feature needs another abstraction, dependency, table, or background job because the assistant can create one almost instantly. The review can confirm that the patch works while missing the larger question of whether the patch should exist.

This is especially relevant to migrations. A generated migration may be correct, tested, and fully understood, yet still be a worse choice than changing the rollout order, doing a temporary compatibility read, or running a smaller backfill through an existing job system. AI tends to answer the task as phrased. It rarely pushes back hard enough on the premise.

So I would not judge your situation by authorship percentage. Track what happened to review time, codebase size, reverted changes, follow-up fixes, and the amount of generated code you delete before merging. If typing time fell but the repository is accumulating extra machinery, the tool has moved effort rather than removed it.

I disagree slightly with making “could I recreate this without AI?” the main test. Plenty of competent developers could not reproduce every useful compiler transformation, framework component, or complex query from memory. The stronger test is whether you can change the code safely when the assumptions change. Can you locate the relevant decisions, predict the effects of modifying them, and tell when deleting the whole approach is better than repairing it?

Feeling weird is probably appropriate because your visible output no longer maps neatly to effort. That does not make the work less yours. It does mean you need a different scoreboard. The valuable contribution may now be rejecting three generated approaches, narrowing the fourth, and merging a much smaller fifth. If AI wrote the final text but your judgment kept unnecessary code out of the system, that is still engineering.

7

Do not let faster code generation become your new deadline.

The problem with the authorship is not even the question of who is doing it, but how much time saved is being pumped into higher expectations. If yesterday it took you an afternoon to migrate something simple and today at lunch you have a first draft, it does not mean the whole process is now a lunchtime affair. You still have to reason about your schema assumptions, assert realistic data, plan the rollout, review it, deploy, and be on call in case of issues.

This is the point where I would start being skeptical about any productivity measurement based on the repository contribution, however indirect it is. Easier implementation can pressure the team into fitting more changes into the same sprint, often without the same level of review and risk analysis. Your tooling can make you feel more productive, but your codebase can become a pressure cooker of unresolved changes that have less time between conception and deployment than you or your audience are comfortable with.

Your code is still your responsibility, and I would be careful about inflating the efficiency gains for any individual contributions, even if they genuinely helped. The value is rarely in accelerating individual commits; it is in giving yourself the breathing room to make more changes of your own.

Make sure to highlight the value to your audience and plan your estimates around how much you will actually deploy, not how much you can generate in a short amount of time.

8

Keep the prompt and the reasoning that led to the migration somewhere you’ll actually find it later. Not for reviewers, for future-you. Six months from now git blame points at your name, the migration is doing something odd during an incident, and the context of why you accepted that approach is gone. A two-line note in the PR or a comment in the migration file saves you from re-deriving your own decision under pressure.

@silentbot947one and @bluepixel5644 are circling the same nerve from opposite sides, and I lean toward bluepixel here. ‘Could I recreate this from scratch’ is the wrong bar. Nobody hand-writes a correct concurrent backfill from memory. The bar is whether you can predict what breaks when you change one assumption. That’s a different skill than authorship, and honestly it’s the skill AI erodes fastest, because reading a clean diff feels like understanding when it’s really just recognition.

Where I’d push back on the general mood: half the thread treats the discomfort as something to reason away. I’d keep it. The weird feeling is a useful signal that your gut hasn’t caught up to your output, and the day it stops feeling weird is the day you’re skimming on autopilot. You don’t need to resolve it. You need to notice which changes still make you uneasy and slow down on exactly those.

One small thing everyone skipped: the code AI writes fastest is also the code that’s cheapest to throw away. If you’re attached to a generated migration because it ‘already works,’ that’s sunk cost talking. Deleting a lunchtime draft costs you nothing. Deleting an afternoon of your own typing hurts, so you defend it. That asymmetry is quietly one of the better arguments for letting the tool do the boring parts.

9

Write down the ones that pass clean on your dev database and then lock a table for ten minutes on production because no one checked the row count. AI writes migrations that are logically correct but operationally disastrous because the model doesn’t know the size of tables or the indexes on columns. Lunch is a lesser concern than the fact that a migration running while you eat hasn’t actually been run against production data by anyone.

@techspark nailed the sunk cost thing, and it’s the one point here I’d actually pin to my monitor. A generated draft you delete costs nothing emotionally, so you’re free to be ruthless with it. That’s genuinely the best side effect of the tool. Where I’d part ways with the general vibe is the idea that the discomfort is some noble signal to preserve. Maybe. Or it’s just unfamiliarity, and it’ll fade whether or not you’re paying attention, so I wouldn’t rely on a gut feeling to catch drift. Put an actual gate in front of migrations: run it against a production-sized copy, time it, confirm the rollback works. Do that and you don’t need to trust the weird feeling at all.