Coding with AI eventually comes down to two paths, I've realized. One is using AI exclusively for everything. The other is not using it at all. There is almost no middle ground. The reason is that as the complexity and depth of the problem increase, the code AI generates increasingly follows enterprise level patterns. The deeper the meaning of what I input, the more AI tends to produce code that goes beyond my own area of expertise. For example, a human expert's code is very powerful and deep within their own domain, but when you look at the entire codebase, it's often shallow and uneven outside that domain. But the moment you write code with AI, once you go deep in one part, AI tries to standardize the rest accordingly. This means the entire codebase converges toward enterprise level standard code, which essentially reflects the average patterns of senior programmers who built large scale systems.
The problem is this. Human cognitive resources are finite, so we inevitably become shallow outside our own expertise. There is no programmer who can do everything well. And as systems grow in scale, they become more modularized and fragmented, making it impossible to understand the whole system. So what should we do about this? That's always the question.
In the end, do I choose not to use AI, finish the project with uneven code outside my domain, and deliver it? Or do I use AI and deliver a program that is uniform and consistent, but not in my own style? I still don't know. I haven't found the answer yet.
The middle ground is to use it as a power tool: give me an example of this, fix my types, do this fussy bit, find this in the docs, without ever letting go of control.
When using power tools you make all the measurements and decisions, you just hammer screw drill and cut faster. You cannot power tool your way to building a things that you don’t know how to build.
The other interesting thing about this is it works with smaller models and uses a fraction of the compute.
You can also just use AI and keep the scale of your changes small rather than refactoring the whole app with a change? This isn't super-weird.
"In the discrete world of computing, there is no meaningful metric in which "small" changes and "small" effects go hand in hand, and there never will be." - E.W.Dijkstra (EWD1036)
I believe grandparent meant "small enough changes that you can understand what the effects are likely to be"
Then it's probably small enough - where you don't need a help of AI, and should do it yourself.
My position is that AI could be useful to find the potential places for these changes, but it should be someone who's capable of thinking to implement them.
That might be true for you. For me, I can stay in flow state so long as I'm progressing, even if progressing doesn't involve writing every line by hand. Whereas I easily fall out of flow state as soon as I am frustrated by an inability to remember some particular bit of syntax, or a particular bit of architecture, or a particular code pattern.
For me, AI has been a godsend for productivity because it's great at what I'm bad at. I'm not spending 99% of my day grinding away at C++ code; I'm never writing enough for it to become a world class language expert. I'm jumping between SQL queries, CSS, Java, bezier curves, Python, and shell. If I need to write something in a language I touch infrequently (e.g. Go or Ruby) it's nice to have individual blocks of code generated for me, so that I'm not slowed down by my ignorance on a language's iterator syntax, or whatever.
As you know, the boundary ultimately depends on code quality. The problem is that AI generates code that looks high quality even outside my area of expertise, at least from my perspective. So now the boundary has to be redrawn. Refactoring usually ends up redefining those boundaries. At that point, the question becomes: do I rewrite my own code, or do I reject the AI code? Those are the two choices left.
In the end, an exceptionally skilled programmer might be able to keep their core domain intact, but I think the vast majority would find that very difficult. So it might be possible once you cross a certain threshold, but considering the sheer amount of code required to deliver a single modern program, it's hard to know which parts to focus on. However, my perspective might be different because I'm coming from the point of view of delivering a working program, not from the perspective of open source development
I'm part of the middle ground. Not able to do full agent code, but I'm fine using it to generate snippets that i fully read. I find it great to use apis with little documentation. For me AI is similar to a google search when im not able to find meaningful doc or i want the code snipped and refine over it
I feel like my current approach is a decent middle ground.
In the past, I wrote code by first writing English pseudo-code as a series of self-documenting comments. These would be declarative assertions of what the code will do. (For example, "Method returns true if array values are within 0.5% of spherical.") I then wrote the real code next to each comment.
My current workflow is mostly the same as before, but as soon as I think there's nothing creative left to do, I allow AI to take a pass at it, insisting it include verbose comments. Next I read everything; its comments are often redundant but allow me to internalise the logic/intent more quickly. I make any corrections myself. And I strip any pointless AI comments.
In short, I stay in full control of the architecture while tasking AI with the grunt work, the implementation details, and the superficial correctness.
> There is almost no middle ground.
I use it rarely. I did have it rewrite some code, mainly from one language to another. That works really well. I also had it rewrite a database interface, which also seems to work (no time to test it thoroughly, yet, so it's not in production). But I'll be damned if I let it write new features. I've debugged other people's code, and it ain't fun. Debugging 10kLOC AI code sounds like hell to me.
Own the design and let AI write the code. Spend the extra free time on becoming a better/broader architect.
How can you own the design if you don't know what your design actually does?
You can't, so you do read the code.
This idea is being pushed to increase sunk costs IMO. We are told to spend huge amount of time writing specs, behaviour tests, AGENTS.md and prompts.
Pinky promise that's enough to get good output.
Pinky promise we won't invent yet another body of work the whole industry must adopt to get good output.
Pinky promise the AI tool will properly read all your work
And then of course we are told you must never trust its output !? You must review all code it produces line by line and grok it fully !
And now we have: keep challenging it, keep rejecting it, keep interrogating it... That's just fancy words for spend more money (tokens)
Wow hang on, I'm suggesting to use AI as a code writing aid, not to increase scope until owning the design becomes unreasonable.
It's been years at this point though; everyone knows where "use AI as a code writing aid" ends up.
I think the differentiator is whether someone cares about what they build or not. Someone who doesn't care wouldn't produce masterpieces without AI, and using AI isn't going to prevent someone who does care from building something nice.
But everyone claims they care; everyone using AI is telling you that they're not like the slop merchants, that they're really building masterpieces/the next unicorn. Just like everyone using AI to write says they're just using it as a fancier spellcheck.
It doesn't seem like AI users are very good at telling how much or how well they're using it.
I'd rather blowtorch my nipples off than yell at a computer all day