← back to blog

thoughts on ai-coding (for lack of better words)

2025-12-27

Recursive function

disclaimer

I'm not an "expert", I'm not saying that my view is the right one, so take this with a grain of salt (same as any other thing you see on the internet) this is just my view on the matter that will be discussed below

intro

So now with that disclaimer out of the way, we can get into it.

First we have to distinguish between the different ways people "use AI for programming", there are different ways of using AI to either help you, or even do things in your place in this space. we have a few ways of doing this:

- using one of the platforms that let you build a full project using AI which have existed for quite some time now

- There's also editors that let you use AI directly inside them, so you're viewing the codebase & ask it for some changes

- there's also CLI coding agents, which you can directly talk to inside your terminal & ask it to do stuff

There's more ways to use AI to help you program, or "do the programming for you", and even within the listed ways, there's different ways of using it.

Why do we want to use AI as programmers?

Maybe that is a stupid question for some people, still I believe it's worth thinking about, what exactly does AI help you with?

Does it increase the productivity? I can see this case being true for some things of course, a lot of these "fast-moving teams", frame it this way. And it can be true, after all, with a coding agent, you can submit a huge amount of PRs, even fix some bugs that might be affecting production, you can even push new features.

From the customer's POV, this is a very good thing. Since it means responding to tickets/feature requests faster, and from the customer's perspective this is amazing again.

From an economic perspective & especially for people who aren't programmers (which is the case most of the time), this is a no-brainer & should be done (from their POV).

What can we deduce from this? That the advantage of using AI is speed, or more accurately, lines of code produced. That is true and no one can argue against it actually. But the question is, is the bottleneck for programming: lines of code produced? Has that ever been the case?

Programming is actually a very delicate art, everything (should) matter in a codebase, especially for an important project, this of course goes very deep, the mental models, the approaches you choose to use, the tools you choose to introduce, etc...

Context

I have actually used tools like Claude Code, Cursor, Antigravity, Codex, etc... So I'm not some dinosaur who has never heard of these tools (I'm only 24, that might be too old for some, some friends call me an unc lmao)

The problem(s)

There are multiple problems in this space, I already hinted at one of the most important ones. Which is that software is not the same as generating a 10,000 word essay for your assignment. It is not enough for it to just run & do X.

There are multiple layers to it, latency, speed, how much memory it consumes, the UX/DX, security, fault-tolerance, etc... All of these are user-facing problems, meaning they are problems that will impact the experience your user has when using/interacting with your software, to different degrees of course.

Then there's the other side, which is the issues that are not user-facing, on the top of the list for that are things like code-hygiene, maintainability, ease to understand, patterns, etc... In a way these can also be user-facing since it makes it impossible to work on, which makes it impossible to maintain & add new features/fix issues for the users

I'm sure you have heard about all of these things, but we can talk more about why it happens, I won't be talking about non-programmers using tools to generate entire projects for them, since we already know how it goes.

The fundamental problem is the blackbox effect these tools create. This of course depends on how exactly you use it, but the way most people use it, always ends up creating a blackbox

suppose you ask the llm in whichever tool you're using to implement x. It does it, and then asks you review the changes, or not (depending on your settings), then your job as the engineer is to review this code.

The issue is that it generates so much code, so fast, and it is quite tedious to keep on reviewing garbage full-time.

Like I said, I don't think that the bottleneck in programming is the LoC, that is an idiotic thing to say.

This brings us back to the first question on this post, which is why use AI as a programmer?

If the way to make it productive is, by moving slow enough (defeats the whole "move-fast" argument), and reviewing everything the llm outputs yourself (at which point, might as well just write it yourself)

FOMO

fomo is a real thing for this subject, after all you might see a lot of people saying that if you use X (different tools that make it better, or even different models) on top of the other things that you're already using, then it makes the outputs much better

let me save you the trouble, it might actually make the outputs better, but what has been said so far still applies, it is purely hype.

Not all software is equal

This is pretty obvious, but i felt like I should include it nonetheless, because it is true. so the stakes are different, and so that would explain why certain companies push the narrative (alongside other things, the simplest of which is just the decision-maker(s) being clueless)

You are the project

this post so far has been mostly about the software and the impact this has on it, but there's also an impact on the person relying on this

There are different degrees of relying on AI of course, but overall, and this applies to any skill, when you're not engaging it, you start to get rusty.

You're not going to forget everything and suddenly be completely ignorant of how software works, but there are a lot of things that you can only know when you're deep in the trenches. Some things that you will never actually learn (if you just got into programming) if all you're doing is relying on AI

This is in some way another abstraction inside of software, as you know software is built on top of abstractions, and we even define our own abstractions all the time as programmers, they're useful a lot of times, however in this case, this abstraction is actually harmful for you

In a way, it reminds me of the language learning (languages, not programming languages) platforms that use that kind of gamified style, where the user doesn't actually learn Spanish, they just think they did. Same can be said about vibe coded projects lmao

Addressing the FOMO

Software has actually been getting worse, it is not advancing, and no, this is not just because of AI, in fact this has been the case even before llms.

There are multiple reasons for this, one of them is the infinite bloat in software, an electron client for some service you use using 12gb of ram is absolutely criminal

but like I said, this has been the case even before llms, so how does this even relate to our subject

My point is this, some of the greatest & most influential software that has ever been built in the past was built by people who didn't use llms (duh).

So if you think that you're missing out on shipping a b2b saas (lmao ikr) because you're not using the #292829 new trendy things that makes model go ultra saiyan and one shot your code

just remember that the Mars Rover software was written by people who wrote it themselves

Closing notes

I'm not an "AI-doomer" (at least i don't think I'm), I also think that AI can be very useful for programming. I just don't think that the way it is being used (for programming) is the best way to use it. you might also be forced to use coding agents for your work, and that's okay too, i would do the same thing as a matter of fact (yes, i'm not getting fired over this, god knows the unemployment is hard lmao)

There are even more issues on the subject that i either didn't mention, or just didn't dive deeper into. This is by design, to force you to think deeper ~just kidding, i'm tired of writing and already behind schedule for today's tasks

and once again, this is just my personal opinion if anyone cares, this should go without saying, but do whatever you think is best

footnotes

just to be clear, i'm not against using coding agents, i think they can be useful tools in certain contexts. my issue is with relying on them, which has a few problems:

- the blackbox effect, where you don't fully understand what's happening in your own codebase

- code quality degradation over time, since reviewing everything is tedious and things slip through

- skill atrophy, you stop engaging with the craft and get rusty

- false sense of productivity, where lines of code produced doesn't equal actual progress

- technical debt accumulation, because the agent doesn't care about maintainability the way you would

if i was forced to use them (by work or whatever else), i would do it without hesitation, that's just how it is. i just wish the whole thing worked differently, where the focus was on augmenting understanding rather than replacing it