I'd estimate that using AI to implement a well-defined feature typically takes about 1.5x the time for me - and yet I still use AI extensively.
The key difference is that I can context switch. Once the AI has context and is doing its thing, I can move on to another task that's not working in the same area or project. I can post on HN. I can catch up on my Slack inbounds, or my email.
Having two tasks running at once nets a small but nice improvement in velocity. Having any tasks running while I'm doing other things effectively doubles my output.
Look, there's a rich spectrum of abstraction that we are lucky enough to choose from as developers. Obviously you can write a byte stream onto the disk using assembly if you want, or you can have a high-level API store data for you without knowing how or where it's going. You can call any combination of technology a "stack."
Since you asked, the level I've chosen for this project is Go and PostgreSQL via pq. There's a single level of indirection to wrap the database access in case we need to switch from Postgres for any reason, but otherwise the app interfaces directly with the database. Migrations are simple SQL files that are run as necessary as the server starts up.
This will all run on a dedicated server that is already doing other stuff. That's the full "stack" as it were.
Someone needs to know what a "database migration" is in order to ask Claude to build one.
I think a lot of people are massively underestimating how much knowledge and skill is needed in software engineering beyond typing code into a text editor.
You know that Linus was at one point "typing code into an editor" to review other people's patches because he found it easier to catch mistakes that way.
If your field of software engineering is so simple that you can survive on code snippets stolen from other people, great. Please do not generalize that.