I've been a software dev for 25 years. In the past year I've hand written maybe 10 lines of code. For the first 2-3 months i would read it, then I figured out how to really use AI/code gen and the amount created was more than I could read. I can work on 2-3 projects at once, or 2-3 parts of a larger project at once. More than that I can't keep task switching. The speed and complexity of what I'm able to create is 10x doing it by hand. In the hands of someone that understands system design it's a great tool, but still need fundamentals. I've seen junior's build stuff that would never deploy and would crash with a handful of users.
> The bigger cost was the typing. Every time I wanted to build something, I could see the code in my head. I just couldn’t type it out fast enough.
Facts. For me the bigger the gap between what i saw in my head and the speed with which my fingers could physically make it a reality the more stress i would feel and some marathon coding sessions would end w my back all messed up just from the tension
Nice to hear others are feeling this too. I started using typing websites to improve my speed a few months ago. More recently I've noticed that I'm starting to make lots of typos and use sloppy language in general because AI still understands me. That can't be healthy in the long term.
Unfortunate to see an otherwise-good article padded by AI-isms ("But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.", amongst other examples).
Maisem Ali writes about how they have not stopped engineering despite handing production of code over to AI. I think that's an interesting perspective for a few reasons, but most of all, I'm not sure I agree.
First, we see a prime example of how that can blow up. "botd died this month. It crumbled under its own weight." It's hard to imagine how an agent harness (or is it an overlay on top of other harnesses?) could crumble under its own weight from sheer technical complexity. What makes a tool like this "crumble"? If properly architected, it seems that any outside change could be adaptable. Failing tests could be fixed.
This AI coding evolution has given us the ability to spin up prototypes we don't understand the inner workings of, but I believe for anything of value (and, I would argue, botd appeared to have value to Maisem) we should at the very least understand and influence the architecture and engineering of what we're building. If Maisem had done that for botd, it would not and _could not_ have "crumbled under its own weight". Whatever outside influence required change within botd would have been manageable.
Second, the off-loading of the production of this article indicates to me a lack of respect (with no offence to Maisem, because this is what much of the industry is doing today) for the value in thinking through the writing process. There's a lot that I've learned personally about software I worked on that only came to me through trying to write explainers. Taking a step back from the software we build and looking at it from a birds-eye view, to share how it is constructed or how to use it, helps develop our understanding.
Maisem's article is already very good, and I hope that is demonstrative of their own writing! I would read more! But I want to read words written by a person for other people. AI can help edit, it can help us build ideas, but in code and in our written word, AI should not be _the author_.
I don't understand people that say "I no longer code" as a good thing. I think it's safe to assume that if you studied computer science or similar you like to code. If not, why did you even study that?
To me it just feels like you want to be a manager not an engineer
This is like if a plumber said. I no longer do any construction, I just tell people what to do. Then you probably aren't a builder anymore, you are a foreman or a project manager.
I think your job as an engineer is to know the codebase and how it was engineered
Some of us like the details. Bricklayers are not subhuman! You architect if you want, or manage which is what agentic seems like to me, I'm sticking to coding until I can't any more (or get properly sick of it all, which is likely to come first given everything is getting more and more remote and drowned in AI) then I'm doing something completely different because I don't want to manage (people or agents).
I like to make computers do the things I want. Since I was a kid, the satisfaction from programming or any sort of "computer engineering" (using the word engineering VERY loosely here) is in making something specific happen.
Sometimes, that means understanding the correct data structure to use, picking the right algorithm, and other computer science-y things.
Other times, and more often (for me), it means death by a thousand papercuts in managing third party dependencies, boilerplate, and other tedium and minutia.
I'm not someone who is "proud" of barely coding anymore, and I'm not entirely sure how I feel about the "structural soundness" of using LLMs this way (most of my coding is personal/hobbyist work), but I can confidently say that I don't really code just because I love coding, at least necessarily. I like making stuff.
>"This is like if a plumber said. I no longer do any construction, I just tell people what to do."
I'm pretty sure that's the dream goal of any plumber. No one "plumbs for fun". No one wants to truly do the actual thing, they want the money that allows them to do whatever they want. It's just that doing the actual thing is the only way you can get the money at first. And being good at doing the actual thing and enjoying doing the actual thing makes doing the actual thing bareable or even fun while reaching your actual goal (the money). As soon as you can free yourself from that you will.
It’s more AI copypasta as it goes further along where it gets really into the how and not the why.
“But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.”
If I had more time, I would have written a shorter letter…
I also haven't written more than a couple lines of code in months, but I definitely do read the code. You have to, or at least provide lots of Claude Rules to help steer it. AI has too many bad coding practices by default. But you don't need to modify lines of code by hand, you can just tell it what to fix.
I'm predicting a Docker for AI Coding. There really is a ton of stuff you need to set up to do AI coding/vibe coding in a way that's safe, has good results, and is fast. You don't just need a dev environment, you need a whole SDLC; codified good engineering decisions, test framework, credential management, an interactive UI and notifications, guardrails, a "waterfall" of progressive design/build/test, context management, and much more. It's too much for people to put together themselves without tons of time and experimentation. Same as containers, which is why Docker came about: to let an end user do complex things in an easy way.
AI coding is like a self-driving car. Making the car move is easy; making it get you to the destination you want safely is very hard.
Facts. For me the bigger the gap between what i saw in my head and the speed with which my fingers could physically make it a reality the more stress i would feel and some marathon coding sessions would end w my back all messed up just from the tension
1. https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
Software engineering is dead, long live software engineering!
Maisem Ali writes about how they have not stopped engineering despite handing production of code over to AI. I think that's an interesting perspective for a few reasons, but most of all, I'm not sure I agree.
First, we see a prime example of how that can blow up. "botd died this month. It crumbled under its own weight." It's hard to imagine how an agent harness (or is it an overlay on top of other harnesses?) could crumble under its own weight from sheer technical complexity. What makes a tool like this "crumble"? If properly architected, it seems that any outside change could be adaptable. Failing tests could be fixed.
This AI coding evolution has given us the ability to spin up prototypes we don't understand the inner workings of, but I believe for anything of value (and, I would argue, botd appeared to have value to Maisem) we should at the very least understand and influence the architecture and engineering of what we're building. If Maisem had done that for botd, it would not and _could not_ have "crumbled under its own weight". Whatever outside influence required change within botd would have been manageable.
Second, the off-loading of the production of this article indicates to me a lack of respect (with no offence to Maisem, because this is what much of the industry is doing today) for the value in thinking through the writing process. There's a lot that I've learned personally about software I worked on that only came to me through trying to write explainers. Taking a step back from the software we build and looking at it from a birds-eye view, to share how it is constructed or how to use it, helps develop our understanding.
Maisem's article is already very good, and I hope that is demonstrative of their own writing! I would read more! But I want to read words written by a person for other people. AI can help edit, it can help us build ideas, but in code and in our written word, AI should not be _the author_.
To me it just feels like you want to be a manager not an engineer
This is like if a plumber said. I no longer do any construction, I just tell people what to do. Then you probably aren't a builder anymore, you are a foreman or a project manager.
I think your job as an engineer is to know the codebase and how it was engineered
I like to make computers do the things I want. Since I was a kid, the satisfaction from programming or any sort of "computer engineering" (using the word engineering VERY loosely here) is in making something specific happen.
Sometimes, that means understanding the correct data structure to use, picking the right algorithm, and other computer science-y things.
Other times, and more often (for me), it means death by a thousand papercuts in managing third party dependencies, boilerplate, and other tedium and minutia.
I'm not someone who is "proud" of barely coding anymore, and I'm not entirely sure how I feel about the "structural soundness" of using LLMs this way (most of my coding is personal/hobbyist work), but I can confidently say that I don't really code just because I love coding, at least necessarily. I like making stuff.
I'm pretty sure that's the dream goal of any plumber. No one "plumbs for fun". No one wants to truly do the actual thing, they want the money that allows them to do whatever they want. It's just that doing the actual thing is the only way you can get the money at first. And being good at doing the actual thing and enjoying doing the actual thing makes doing the actual thing bareable or even fun while reaching your actual goal (the money). As soon as you can free yourself from that you will.
Can we stop posting obviously slop articles? If you can't make the effort to write the article, I'm not going to make the effort to read it.
“But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.”
If I had more time, I would have written a shorter letter…
I'm predicting a Docker for AI Coding. There really is a ton of stuff you need to set up to do AI coding/vibe coding in a way that's safe, has good results, and is fast. You don't just need a dev environment, you need a whole SDLC; codified good engineering decisions, test framework, credential management, an interactive UI and notifications, guardrails, a "waterfall" of progressive design/build/test, context management, and much more. It's too much for people to put together themselves without tons of time and experimentation. Same as containers, which is why Docker came about: to let an end user do complex things in an easy way.
AI coding is like a self-driving car. Making the car move is easy; making it get you to the destination you want safely is very hard.