121–130 of 206 posts
"Computer" use to be a job title. So no, I am not optimistic about the future of most programmers, maybe even all programmers. One possibility is that software starts to look more like traditional manufacturing. The machine is the company’s core asset. The engineer only needs to know how to operate the machine well. Once that happens, the barrier gets much lower, need much less people, and the job naturally become mu…
My personal experience: writing code has always been the easy part. AI does most of that now. Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately. I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-swi…
> My personal experience: writing code has always been the easy part. AI does most of that now. The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part. If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved fro…
to further that example, many people with the help of AI are ostensibly copy pasting trig problems from the book without understanding the mechanics running through them and labouring under the impressions they’ve become closer to skilled mathematicians
I'm a Senior Freelance Programmer, I can see many of my past and present clients moving towards the exact path you described. I keep warning them during meetings that Claude model isn't sustainable for long, eventually the VCs will come for their revenues and Claude will be forced to close their access to all but the most enterprisey ones with deep pockets. The mere electricity cost for that kind of high level reason…
My personal experience: writing code has always been the easy part. AI does most of that now. Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately. I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-swi…
> My personal experience: writing code has always been the easy part. AI does most of that now. The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part. If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved fro…
In my view, "programmer" merged with "analyst" to become "software engineer".
Earlier quoted context omitted.
> Knowing how to implement Djikstra or a linked list by heart is no longer important. This was never important. The important part was always knowing when to use them.
>The important part was always knowing when to use them. Two things can be true simultaneously. I think there was a time when deep familiarity with implementing algorithms was important.
code is like assembly now. in the olden days (pre-LLMs) we would write high-level code. the entire layer was high-level code and rarely would we ever need to peak into the assembly: writing, debugging, architecting, reviewing, testing - all were done in the high-level language layer. --- welcome to present day: since we don't write code - we write intents, we also shouldn't review code either - we should review inten…
> I ask the agent to generate markdown docs, graphviz diagrams, changelogs, audit reports, etc. I only review that. From an alternative perspective, that is the code.
Consider some software that was written by AI purely using markdown files. The spec was sufficient enough to classify all of the business logic, conditionals, etc... You might even end up creating "loops" that tell AI to do something over and over again. Some markdown files become standard, repeatable "functions" that are to be followed EXACTLY (determinism). Some markdown files become assertion tests. Heck, the markdown file might eventually invent some kind of "typing system" so that you know when you're working with the person "class", it's always going to have the same facets.
I love the concept of it going in this direction - we already had plenty of languages to tell a computer what to do, we've just generated MORE text at a higher level and made it less deterministic.
Just to clarify, I don't think it's likely that this is the end result, but it sure is funny to think about.
Earlier quoted context omitted.
I suppose our opinions stem from different experiences. I don't expect AI to do all the work with just a paragraph of instructions. Some people do, and they get very poor results. I design large, complex systems based on microservices, and so far I haven't encountered any of the obvious and glaring errors that other users report. For each project, I've spent two or three weeks working on thousands of lines of specifi…
Yeah, your experience is definitely different than mine. When I’m working with human teams, I don’t spend weeks giving them thousands of lines of precise instructions. We work incrementally, having fairly brief conversations to make sure we’re on the same page about the tasks we’re tackling, and then letting individual pairs work out the details of each task… which they do, because they’re experienced professionals.…
The interesting thing is what you mentioned, that "no further documentation is needed." In the industries I work in, it's mandatory (with or without AI, and it's been that way for many years) to have everything fully documented from the design process onward. For me, it hasn't been difficult to work this way with AI because I know and have practiced the discipline of documenting decisions for a long time. For my clients, it's an essential accountability requirement.
These documents now have a dual purpose because they now serve to manage cognitive discipline too, so that agents do a better job than they would with vibe coding. Because without that discipline, what you say is absolutely true: AI agents do a terrible job and only hinder the good workflows already adopted by professional teams.
Earlier quoted context omitted.
> hobby projects Unfortunately despite being impressive for solo stuff, such results don’t scale to software you’d give to others.
Claude writes probably 95% of our code now, fintech, amongst top 5 in the world in what we do. I am 100% certain we're not even at the forefront of using agents for coding compared to some others. It definitely can scale.
Maybe I'm wrong. Maybe AI Natives will be faster in the end and can build / do more, or building software really is a dead field - but I noticed that I was losing my brain and had to get back into the seat.
There are definitely great use cases for agents - but I think a lot of us aren't flexing our brains anymore and, even worse, some devs believe they are. I urge every developer to put Claude down for a day/week... see how well you can do in the "old" ways. It'll still be here when you get back, but my guess is it'll be a rude awakening.
For whatever it's worth -- I run my own product/company (software). I do all code by hand and don't use any AI.