glimshe
3 days ago
We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
I love being able to quickly bring out the program that is already running in my head without having to worry about the grind of typing it into a format that the compiler understands. Dealing with API names. Syntax. Language quirks. Library gotchas. A sizeable portion of my successful career as a software engineer was spent on the tiresome process of interacting with a text editor/IDE to get a program to do what I wanted.
I was there when people were still coding assembly. A slow torture where the simplest things took forever to get right.
Once I've mentally solved the problem, the fun is mostly over for me. Pure vibe coding is dull and unsustainable with current technology for all but the simplest systems; AI-assisted coding, on the other hand, rekindled my passion for computers.
corv
3 days ago
I like your constructive outlook and I want to believe that we can now focus on the bigger picture, but I'm not really seeing it around me. Most everyone I know that's "AI-pilled" has spent the newfound capacity on throughput instead of altitude.
Is anyone actually seeing a shift towards improved structure rather than more code, faster? We seem to be living in the Gatling-gun version of the picture John Carmack drew when modernity also ushered into precision marksmanship...
Razengan
3 days ago
The people who are using AI to improve what they were already doing anyway, aren't going around expounding "I made this with AI!"
Like one of my personal projects is a sort of "middleware" for Godot, and it needs to be lean, precise and match certain rules, because it's meant to be used by many games, so I can't blindly trust AI to generate code for it, it'd be too sloppy,
BUT Codex reviews have been a great help in finding bugs that would have taken me ages to even notice on my own. Some of those AI findings helped me overhaul entire subsystems, still manually coded.
archagon
2 days ago
I feel like using LLMs as a sort of deep search to find bugs and security issues is going to end up relatively uncontroversial all around, if the externalities of LLM use are ever taken care of.
mettamage
2 days ago
I use vibecoding to capture UX. It's the best way of capturing requirements I've seen so far. Then once it's all captured and dies down towards requirements that are all in the "could have" category of MoSCoW, then I use AI-assisted coding (and the fun task of reading tens of thousands of source code lines) to refactor or create an entirely new application that is more technically sound.
I'm making full-stack applications at the moment.
lowbloodsugar
2 days ago
Miyamoto having an assault rifle doesn’t exclude 19 year old cannon fodder also having assault rifles and spraying them liberally to little effect.
charcircuit
3 days ago
Are those people working on products or platforms? Platforms still have to be rock solid and deliver performance guarantees to the products built on top of them.
enraged_camel
3 days ago
>> Is anyone actually seeing a shift towards improved structure rather than more code, faster?
Yes. At work we recently finished a complete rewrite of the platform. The old codebase got abandoned and two new codebases got stood up. Previous stack was Phoenix LiveView and the new one is Phoenix API + Vue /w TypeScript. Zero code shared between the two. We took the opportunity to re-architect a lot of the core functionality and get rid of the tech debt that had been hounding us and killing our velocity for the past six years.
We finished the rewrite in two months. A little over 700k LoC total. 95% of it was planned, orchestrated and written by AI. We could have gotten it done faster, but we were well aware of the potential for slop and thus paid an absurd amount of attention to (and tokens for) code quality. For example, there is a 100% test coverage requirement in both server and client, combined with AI-driven review rules that say all tests must be non-vacuous, plus a ton of invariants enforced via deterministic checks. Everything from standard linting and formatting rules to AI-necessitated stuff like "comments cannot be more than five lines each" is in there. At the end of each week, we get together for ~30 minutes to review each bug that was fixed that week (there haven't been that many) and try to figure out if more deterministic checks can be added (or new ones extended) to prevent that class of bug from re-appearing. We actually have an Architecture epic with a dedicated Fable agent orchestrating all the initiatives and tickets in it and keeping track of improvements (and the occasional regression). So things like accessibility, usage of shared helpers, enforcement of common patterns, etc. are all kept track of.
The difference between the old codebase and the two new ones has been night and day. The new codebases, combined, are ~35% larger than what we had before, and yet there are way fewer bugs (we actually got suspicious at first and had to check to make sure our logging instrumentation was configured correctly). Performance is also stellar, features have been a lot easier to add and extend, and everything is a lot easier to find. When someone asks a question or has an issue we have a pretty good idea of what part of the codebase to look in and we're usually right.
It wasn't all unicorns and rainbows. Not everyone on the team was proficient with AI-driven development, so they had to be brought up to speed quickly and taught the tools and also what works and doesn't. Code reviews were also difficult and time-consuming. We had to deal with our anxieties about working in two new codebases none of us had authored much code in ourselves. What made all of it worse was that we were racing towards a deadline imposed by external factors so we all ended up working a lot of hours. It was essentially between getting it done this summer or waiting until next summer and we bit the bullet and did it. It absolutely would not have been possible without AI.
Yoric
2 days ago
That is interesting, but... is it actually improving structure?
We're mid-way through a similar process at work. Rewriting a legacy app in a new language, with new architecture and new features.
And it's a mess.
We're at 10x loc (admittedly, the new programming language is more verbose than the old one), comments make no sense. Yes, we have ~100% coverage, but most of the tests are meaningless. The agent keeps removing our tests to replace them with tests that are easier to pass, breaking code invariants, removing all the engineered data structures and replacing them with stringly-typed code, etc.
And of course, given the number of LoC (and the fact that the agent rewrites so much code all the time), it's physically impossible that all of them were reviewed by a human being.
AI made it possible, insofar as upper management would never have greenlit the project without AI, but I can't escape the feeling that we're building on quicksands.
lowbloodsugar
2 days ago
In my experience, when you attempt something like this it grows like a crystal. If you start badly, with poor tests and poor architecture, that is the code that has the attention of the model going forward. More than any rules you give it, what matters to the model is all the code that’s already there. I’ve found myself in such a situation from going to fast and expecting new hyped models to “just take care of it”. The solution was to stop and take stock. I ended up deleting most of the dead-end and using the models to refactor the rest. From that point on, new code from the models was at the standard I needed, following rules already expressed in the code base.
If your code base is script-kiddy garbage, your models are only going to keep writing more garbage. You should throw it all away. I expect that isn’t an option. Try instead instructing the model that the code you have is legacy garbage written in a hurry that needs siginificant refactoring, but that right now I need one new feature written to these new standards instead. Take it one small piece at a time. Don’t let context go beyond 100k. Good luck!
hermitcrab
2 days ago
I thought stringly-typed was a typo. Apparently not.
https://www.hanselman.com/blog/stringly-typed-vs-strongly-ty...
jacquesm
2 days ago
10x loc? wow. That makes me wonder how it will perform. And how you will review that, since if it is physically impossible for a human then who will take responsibility for what you release?
Yoric
a day ago
Benchmarks look good.
Reviews? They were the first casualty.
enraged_camel
2 days ago
>> That is interesting, but... is it actually improving structure?
Can you be more specific? "Improve structure" can mean different things to different people.
We've ensured that agents strictly adhere to code architecture rules, using both agentic review rules and deterministic CI gates. Everything from file naming, location and namespacing to the "shape" of each file that shares the same role are consistent. We can trace functions of the same role across the same set of modules, with abstractions and code reuse where they make sense. Once someone learns the code in one part of the codebase, their understanding of that "spine" translates to other areas - the only differences relate to the specific business rules governing those areas.
>> And of course, given the number of LoC (and the fact that the agent rewrites so much code all the time), it's physically impossible that all of them were reviewed by a human being.
Code review was difficult at the start due to the volume of code. One insight we gained midway through though is that the value humans bring to code review is judgment and business context. So we created a code-atlas skill that creates an artifact for PR reviewers. That artifact highlights the most important parts of the code. For example, if a PR author has made the choice to use soft-deletes when the product uses hard-deletes for everything else, that is flagged by the code atlas, and a human reviewer can use that to ask questions about it. Meanwhile, things like boilerplate are de-emphasized; any problems associated with them are reliably found and flagged by AI reviewers anyway. The refreshing part about this is that this has almost completely eliminated bike-shedding: people no longer argue about module naming or whether a comment is worded properly.
Yoric
a day ago
> Code review was difficult at the start due to the volume of code. One insight we gained midway through though is that the value humans bring to code review is judgment and business context. So we created a code-atlas skill that creates an artifact for PR reviewers. That artifact highlights the most important parts of the code.
Yeah, we did that, too.
But every time I end up, for some reason, digging up deep in the code, I realize that it's not nearly sufficient in our case.
oleggromov
3 days ago
LLMs are a game-changer. You work more for less money.
luipugs
2 days ago
Need to get the budget for those tokens somewhere.
pdimitar
11 hours ago
Awesome. Any further writeups? Would love to read.
Also what kind of problems did you have with LiveView?
HWR_14
3 days ago
> We finished the rewrite in two months. > racing towards a deadline imposed by external factors so we all ended up working a lot of hours.
2 months of 80 hour weeks is 4 months of regular weeks. Can you clarify how many hours your team was putting in? And how large was your team?
enraged_camel
3 days ago
Probably averaging 70. 9 devs and 1 QA engineer.
hansvm
3 days ago
Assuming the LLM never got anything wrong or otherwise had to be re-prompted, that means your devs were reviewing 130 SLOC per hour, on what was described as moderately greenfield (examining new implementations rather than comparing to old historical accidents).
How?
I don't want to sound flippant, but if the point is to add human thought to the mix, that's a high review rate even when examining small tweaks to an existing, working product, even with substantial AI help to pre-filter major gotchas before you bother spending a lot of human effort on the review. That's only 20-30wpm, but a review isn't just scanning or reading code, especially if you're trying to figure out how a new system which doesn't run yet will fit together.
lelanthran
2 days ago
> Assuming the LLM never got anything wrong or otherwise had to be re-prompted, that means your devs were reviewing 130 SLOC per hour,
It's possible, I think, but humans cannot do repetitive mental work (like reviewing code) constantly without atrophy.
Can I review 130 SLoC/hour? Sure. Can I do it 80 hours a week? No. Not even a single 8-hour workday.
hansvm
2 days ago
The fatigue aspect matters too, but another important point I was trying to get across is that not all reviews are created equally. In a working, well tested, properly factored system, with a high quality PR, I can do a cursory, local analysis of the new code and be very confident that it works. AI code I've seen is ... not that. I wouldn't be comfortable in that review without manually checking preconditions and postconditions, defining invariants, examining lifetimes, and a host of other activities. Moreover, for a greenfield replacement of lots of SLOC, I'd expect that most of the code for the early PRs can't even meaningfully run or do anything important, making any sort of broader architectural analysis impossible.
I could see a world potentially where they came up with a magic prompt allowing each proposed PR to be cohesive, shippable, well factored, and everything else you need to be able to actually review it at a higher level and be comfortable with the results, but I'm skeptical. That's a major innovation if they managed to do so even as a one-off, and that wasn't the thing they highlighted when talking about the project.
kalaksi
3 days ago
Is that actually a high review rate? Especially if you know the language and domain. Sure, initially there's a learning curve for a new codebase structure, but lots of lines will also be trivial and many changes might also be similar to each other.
IsTom
3 days ago
For small separate changes in isolation then maybe it's ok? But not for whole days 8 hours each.
But then you need to watch for bugs coming from interaction with previous changes and in 700k loc that might be nontrivial. How do you know which states are reachable and which are not? That takes time.
It only takes a botched condition here (forgot a "not"? swapped "and"/"or"?), a swapped variable name there, code that looks ok, but isn't.
skrtskrt
3 days ago
No don’t worry they said it’s not slop because there’s tests lol
nazgul17
3 days ago
Could you share more about how you guys set up the rewrite? I am interested in the shape of the software as well as how you achieved (or aimed to achieve) high quality.
alexpotato
3 days ago
> We could have gotten it done faster, but we were well aware of the potential for slop and thus paid an absurd amount of attention to (and tokens for) code quality. For example, there is a 100% test coverage requirement in both server and client, combined with AI-driven review rules that say all tests must be non-vacuous, plus a ton of invariants enforced via deterministic checks.
This is why my current view in terms of LLM productivity gains are:
- debugging and triaging 5x
- refactoring when you have tests in place 3x
- greenfield where you have zero tests is about 1.5x
doctorpangloss
3 days ago
> For example, there is a 100% test coverage requirement in both server and client, combined with AI-driven review rules that say all tests must be non-vacuous,
look, your application works, right? so it doesn't really matter what you or i think, and this is why AI matters. but this, your "100% test coverage" - that is pure slop. just 20 years ago, all the most popular software shipped with NO tests. are you getting it?
socalgal2
3 days ago
> just 20 years ago, all the most popular software shipped with NO tests
not sure what you're point is here. It sounds similar to "we use to use blood letting and leeches and doctors didn't clean their hands and everything was fine so what are you getting at?"
Good tests have real benefits. The fact that people shipped without them in the past in no way suggests they aren't needed or have no point.
feffe
3 days ago
Also, 20 years ago SW was tested by QA department and approved before shipping. Don't want to go back to that, but there were testing, just differently.
flohofwoe
2 days ago
IMHO getting rid of proper QA done by teams of QA specialists is the main reason for the current software quality crisis (and that already started 15 years ago or so). We should go back to QA teams and proper QA procedures! Automated tests are no replacement, especially when they are set up by the same people designing and building the product.
YeGoblynQueenne
2 days ago
Well. First they came for the testers. Then they came for the developers.
user
3 days ago
telotortium
2 days ago
> just 20 years ago, all the most popular software shipped with NO tests
Are you getting older? A lot of people anchor their intuition of time and history to a certain year. There are probably still lots of people who think the 1990s is not that long ago even though it’s now over a quarter century since it ended. Maybe you mentally default to 2012 or so, when it might be true that most popular software shipped without automated tests (although manual QA was a lot more extensive in 1992).
But 20 years ago is now 2006, and unit tests were well established as a best practice. Perl had extensive automated tests in the late 1990s that everyone who ever compiled Perl would have noticed, since they were run by default and produced obvious output. Kent Beck’s “Test Driven Development: By Example” was released in 2002, and popularized both the name and practice.
Chris_Newton
2 days ago
But 20 years ago is now 2006, and unit tests were well established as a best practice.
I agree with the spirit of what you wrote, but my recollection of the timeline is different. The first decade of the 2000s was peak Crazy Agile Advocacy, but IIRC it wasn’t until the 2010s that unit testing really became almost universal practice. Much before that and it was still tangled up with XP, TDD and lots of other things that certainly weren’t universally accepted as good practices (notwithstanding the strident advocacy of a certain group of consultants/authors/speakers/bloggers and their fans).
I remember, back in the mid-2000s, when we had some consultants brought in to talk about different aspects of quality and testing. There were several working groups, each led by one of those external consultants, and one of them was about unit testing. This was in a relatively large software development organisation for the time, a few thousand people, and while some parts of the organisation had some form of automated testing operating by then, it definitely was not the case that the well-known products produced by the organisation all had a unit test suite. Other practices we’d consider routine today, such as peer code reviews, were also in their infancy during that period: some were doing them, many were not, and generally we had much less experience of how to do them effectively than we have today.
As an industry, I don’t think we really matured in how even the most ardent fans of unit testing were writing test suites until the 2010s either. In the 2000s, we still had lots of people mocking the entire universe and then writing unit tests that were 99% testing those mocks because of 100% test coverage requirements, and similar dogmatic nonsense.
By the 2020s, I think there was much more awareness of that automated testing is generally a good idea, but there are different kinds/levels of automated testing and finding a mix that suits each project’s specific needs is important. One of the great benefits from the more recent AI tools, particularly the agentic ones over the past year or so, has been that it has clearly demonstrated both the value of a good automated test strategy and how much of a waste of time vacuous tests are.
questionableans
3 days ago
What kind of software are you talking about? Test harnesses were commonly used in 2006. JUnit was created in 1997.
enraged_camel
3 days ago
>> but this, your "100% test coverage" - that is pure slop.
Not really, but I can see why some people think that.
We treat 100% test coverage as "required, but by itself not sufficient". It doesn't give us false confidence that everything will be perfect or anything like that. But it provides us with the discipline to make sure no corners are cut, and the bugs that are fixed don't come back.
One refreshing aspect was that during PR reviews we stopped debating whether something needed test coverage. Instead we focused on what was being tested and how.
taneq
3 days ago
> One refreshing aspect was that during PR reviews we stopped debating whether something needed test coverage.
I’d be curious to know what percentage of the time spent implementing tests would have otherwise gone to discussions about whether to implement them or not. ;)
Yoric
2 days ago
> just 20 years ago, all the most popular software shipped with NO tests. are you getting it?
Not really?
About 20 years ago, I was working on Firefox and we had millions of tests on CI. I was working on a host of other open source apps and they all had tests (most of them had no CI, of course).
fc417fc802
3 days ago
And 80 years ago cars didn't have seatbelts. Your point?
SoftTalker
2 days ago
Careless drivers got weeded out.
Cars today are safer than ever. Drivers (in my memory anyway) have never been worse.
user17847392650
2 days ago
If only the careless drivers were those crippled or killed by their poor driving, it'd be a self-resolving issue as you imply, and nobody should care.
However, what actually happens is that careless drivers often cripple or kill innocent bystanders in other vehicles as a result of their poor driving. That's why seatbelt laws and improved vehicle safety features are a good thing.
fc417fc802
2 days ago
But surely then you agree they are having an effect. Thus my analogy serves its point - test coverage isn't to be dismissed out of hand.
SoftTalker
2 days ago
I'm exactly the opposite. I like knowing how the code works, what the data structures are, what APIs are being used, and yes even typing the code into the editor. When I'm working with LLMs there's less thinking. I'm bored. My brain is not fully engaged in the task. There's less sense of accomplishment in the finished product.
I also prefer to drive cars with manual transmissions.
KronisLV
2 days ago
> I like knowing how the code works, what the data structures are, what APIs are being used, and yes even typing the code into the editor.
I'd say it probably depends on the kind of work you do - if the low level details are exciting then that's totally understandable. But if you're dealing with more rote CRUD work or soul sucking enterprise bullshit, then probably less so and the low level details are obstacles to getting things done, alongside sometimes unreasonable workloads.
I'm reminded of: https://www.stilldrinking.org/programming-sucks
> Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.
That said, AI will probably saturate most CRUD work first, which doesn't make for great job prospects.
locknitpicker
2 days ago
> I'd say it probably depends on the kind of work you do - if the low level details are exciting then that's totally understandable.
Even those who work with CRUD apps need to know things like computational complexity of standard container types, and how to pick basic data structures or choose which basic algorithms to use. Otherwise you'll end up implementing things that have an unreasonably high computational cost that will rear its head at the wrong time.
> That said, AI will probably saturate most CRUD work first, which doesn't make for great job prospects.
I think so too. Today's AI models excel at makeshift plumbing. The boring CRUD jobs are the first ones to go with a prompt.
skinfaxi
2 days ago
What's stopping you from slowing down and doing those things even with AI?
criddell
2 days ago
Do you consider yourself to be part of the retro computer scene?
> That’s ok! The retro computing scene is delightful, full of people building and exercising old skills for the love of it.
lowbloodsugar
2 days ago
Yes. You are the Kung Fu master in Carmack’s analogy.
vouaobrasil
2 days ago
Not necessarily a bad thing. Just because Carmack has an optimistic view and has some catchet in the programming world doesn't mean he's any more correct than a raving lunatic. Frankly, he said relatively little of substance and it's only made more irrelevant because he's said it from a priveleged position.
lowbloodsugar
2 hours ago
>Not necessarily a bad thing.
Agree. I made no judgement call.
>Just because Carmack
"Just because a man, who has some cachet with mountain climbers for being the first to climb mount everest doesn't mean he's any more correct about how to climb mount everest than a raving lunatic". That's your pitch?
Carmac has shipped massive selling, fun games, using low-level, innovative techniques, back when such crazy shit was necessary. The issue is the difference between what is necessary ("Miyamoto") and what is prescriptive ("Kung Fu").
turpentine
3 days ago
> We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
Focusing on data structures, architecture and algorithms is what competency in programming has looked like since forever. Building systems out of smaller pieces gets you there.
If your complaint above is that you were struggling with syntax and reading documentation, one might ask if you failed to progress past beginner levels, and now AI is just your cheat-code?
staticautomatic
3 days ago
Do you remember how bad documentation was? I still have nightmares about Twisted.
eloisius
2 days ago
Some projects have fantastic documentation. Qt comes to mind. The experience of writing Qt is a pleasure because I can always jump to the doc for whatever class I'm dealing with and find what I'm looking for immediately. Also every argument type is well-linked in every signature so it's easy to follow and understand everything you're dealing with.
wartywhoa23
2 days ago
And I have wonderful lucid dreams about MSDN.
Also, are you implying that docs became better in the AI era?
_zoltan_
3 days ago
> Focusing on data structures, architecture and algorithms is what competency in programming has looked like since forever
yes, being able to bang out leetcode hard from head on an interview on paper matters so much... oh wait. it does not.
in the real world, outside of interview questions, it hardly matters. when it comes there, I'll optimizite it, but getting the first system up and running in a way I want is way more fun & challenging. need a lock free ringbuffer? I'll look up what's the latest way to build it. or just ask my AI.
Herbstluft
2 days ago
So which is it now? Do you hate thinking about algorithms and data structures or do you hate writing code? Or both?
skydhash
2 days ago
> yes, being able to bang out leetcode hard from head on an interview on paper matters so much... oh wait. it does not.
That's about reciting standard data structures like stack and queues. I think parent is talking more about the design of primitives for the domain of the software. That requires creativity and insight.
kaffekaka
3 days ago
I think you are not interpreting GP in the most charitable way. He simply said that not having to manually write all the code lets him spend his energy on bigger things. That is different from "struggling with syntax".
turpentine
2 days ago
Syntax is listed right there in the GP comment. They've given plenty of rope to hang themselves by.
Someone who says that programming is not about working at the level of about data structures and algorithms without LLMs raises red flags.
fodkodrasz
3 days ago
It is the same. I mean many mainstream languages made thinking in datastructures hard. Not a coincidence why functional languages, Haskell, F#, OCAML, Scala, Clojure, LISP, etc. had their enthusiast, as they felt just like what you claim.
The datastructures already did the heavy lifting. The syntax was not something to struggle with, but it was the natural way to stick the bits together.
JavaScript for one never gave me this feeling, and I always felt that either the language, or the libraries, but something was always a struggle to overcome. (Python too... seriously, working with collections is a pain in the "pythonic" way for someone who has experienced LINQ... and for most line of business apps it is all about working with collections.)
lelanthran
2 days ago
> We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
Why? What makes you think your data structure design, architecture and algorithms are ever going to surpass AI in the near future?
You honestly can't see a (near) future where those 3 elements are done by AI, not by you?
glimshe
2 days ago
I can and I'd be okay with that too. The world doesn't have carriage makers anymore. Nobody is entitled to doing what they love or what they are good at. I certainly didn't as my job as a software engineer, despite being profitable, was far from what I like in the discipline.
That said, I think AI is still many years or decades away from completely replacing the Software Engineering profession. My kids are entering college right for a CS degree and that's what I tell them. I have skin in the game as I'm ultimately responsible for them.
I could be wrong, but anyone's opinion is at most an educated guess at this point.
user
2 days ago
agentultra
3 days ago
I’m the opposite. I don’t believe there is a royal road to understanding anything. For me, the process of programming involves frustration. That is usually when I find my greatest insights.
Syntax isn’t a big deal. Names either. You can look them up. Remember them. Language gotchas are annoying and sometimes problematic.
To me, our job is understanding problems. And for me, understanding the problem involves wrestling with the code. I learn much from modelling problems in code, building theories, testing them.
Once an LLM system has generated some code I haven’t learned anything. Even when I read through the solution. It doesn't require the same activation of my brain. There’s nothing quite like working through the problem yourself.
LLMs definitely feel like they are draining my passion for computers. There were plenty of folks who checked out or were never truly passionate about programming. Now they’re louder than ever. “Nobody cares about code,” and, “optimizing is a waste of time.” Now we don’t even want to understand how it works, or whether it works at all. They repeat the lines their master have told them: get on board or get left behind.
I’m pretty sure I am risking getting, “left behind.” But I’m okay with that. The tech is truly the least interesting thing to me. If I don’t have a career in 10 years… oh well. I’ll still be programming.
acedTrex
3 days ago
ya i find all LLM output to be incredibly boring and unskillful, I can ship vibe bugs fast with the best of them but it brings me no joy.
I'll never let myself be left behind but the joy professionally of writing quality software is 100% gone.
fragmede
3 days ago
The possibility to have an agent implement every little thing that comes up in your mind as you're building doesn't spark the tiniest bit of joy? Previously, "ooh it would be cool if" had to answer to "yeah but it'll take too long". Now, it's more like, "how important is that really?" to stupid ideas that never would have seen the light of day before.
skydhash
2 days ago
> "ooh it would be cool if" had to answer to "yeah but it'll take too long". Now, it's more like, "how important is that really?" to stupid ideas that never would have seen the light of day before.
My answer was it to "ooh it would be cool if" has always to build a PoC of the thing or a MVP, then I can flesh it out when I need more features. Sometimes a web app can be a single PHP script, and a cli command can be as simple as a single file C program. Or using tkinter with python for GUI.
The answer to "ooh it would be cool if I can travel fast" is not "yeah but it'll take too long to build a car". It's "let's build a kick scooter first".
acedTrex
2 days ago
Not even a little bit to be frank. The joy of things came from their implementation to me. I will write something and then peruse its code on github for hours afterwards just looking, like one would at an art gallery.
If I did not toil on it I wont use it most likely. There's a very very small amount of software I ACTUALLY desperately need in a way that I would not care how it came to exist.
Do not get me wrong, those things exist, i have a plethora of dog shit vibe code websites, clis and tuis and other random stuff on a self hosted forgejo. They did their job now they die. But it brought me no joy, in fact it was rather unpleasant the entire time doing it.
fragmede
2 days ago
That's really sad! I'm sorry for you. If you try reframing it, maybe you can find joy again.
skydhash
3 days ago
Have you tried live programming (smalltalk, LISP)? Or a proper Edit-Compile-Run cycle with a good editor?
A lot of people are bashing old practices, but from y standpoint, it always seems like a lack of proper (usage of) tooling to streamline the coding phase of building software.
glimshe
3 days ago
Dear sir, I appreciate the help but, as I mentioned, I've been around since the Assembly days... Been there, done that. I currently have a crazy efficient Edit-Compile-Run setup and a great VSCode personal config, all of which were made a lot more crazy efficient with Codex.
huurtehoog
2 days ago
LISP has been around since 1959. To the point: the proclaimed advantage of operating at new levels of "abstraction" is not a novel contribution of LLMs to coding.
Put another way: live coding, meta programming, high level abstraction, all have been possible for some 60 years now. Two generations! We don't need the monstrous amounts of accidental complexity involved in running dozens of GB in RAM for LLMs and all the "harness" apparatus, we have had from the right tooling for almost a century (!) now.
Yoric
2 days ago
> We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
That would be lovely.
It's sad that we're being forced to vibe code, though, because my day-to-day experience of that is that the agent does not respect the data structures I feed it, nor the architecture, nor the algorithms.
> Pure vibe coding is dull and unsustainable with current technology for all but the simplest systems; AI-assisted coding, on the other hand, rekindled my passion for computers.
Agreed.
teiferer
3 days ago
> We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
That exact sentence could have been said 20 years as well as 40 years ago. I don't know how you programmed pre-LLM, but line-by-line has long been a thing of the past, if it ever existed. I'm sure the folks creating the Apollo software were thinking a lot about data structures, software architecture and algorithms.
yvdriess
2 days ago
They weren't. A lot of abstraction concepts like ADT, modularization, structured programming had to be developed over the following decades.
penguin_booze
2 days ago
> AI-assisted coding, on the other hand, rekindled my passion for computers.
"Walking on stilts made me taller"?
Daishiman
2 days ago
More like, not having to read the docs of a library or a domain with a million gotchas is a bummer and best avoided if possible.
josebmneto
a day ago
Kinda agree with this. And your point is valid for most of the problems that we solve today as software engineers.
However, you cannot forget that there are problems where - all the knowledge of - AI don't help. Problems where letting AI do the work for you means putting more time and effort than doing yourself.
Problems where you need to be so precise in your prompt/spec that at that point you're coding in English. But English don't compile.
I like the idea of power tools vs hand tools. AI is a power tool, but that are times that the most pragmatic approach is using a hand tool.
hermitcrab
2 days ago
>AI-assisted coding, on the other hand, rekindled my passion for computers.
I would be interested to know what you mean by AI-assisted coding.
I've been coding for 50 years (40 professionally) and maintain several largish C++ code bases for commercial apps. There is no way that I am going to let an AI scan (train on), let alone edit, my code. But I do ask MSCoPilot questions, basically using it like turbo-charged StackOverflow. And I do get some value from that, even if it is often wrong. Is that what you mean?
Chris_Newton
2 days ago
We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
Hadn’t good developers been focussing on those things, and other high-level modelling that relates the software system back to the underlying real world domain, for many years before the LLMs were in the picture?
I’d even say that it’s one of the most reliable markers of a more senior/experienced developer that their code reads like a clear and logical explanation of what the system does and why, with concerns well separated and minor details and technicalities abstracted away so they don’t clutter the rest of the code.
flohofwoe
2 days ago
I kinda of agree, but still believe that writing most of the critical(!) code yourself has long term benefits. IME the initial mental model hardly survives contact with reality and all those little micro decisions that come up during implementation are good to do on your own and have in your own head instead of being buried in an LLM managed decision record where no human ever ventures.
It all depends of course where the code sits between "low level mission critical code" and "high level throw-away code". every non-trivial project has code across that entire range.
E.g. the lower level the code, the more I want to get directly involved, and that may mean typing each line manually to get that code directly into my head (IME for that purpose, writing is better than reading - have that manually written code reviewed by LLM instead).
Of course that only works if you don't have a manager breathing down your neck who insists on prioritising implementation speed over quality ;)
Also you should try assembly coding with modern (non-LLM) tooling, it feels incredibly more productive than with the primitive tools on slow machines of the past.
Also:
> software engineers can focus on data structures, software architecture and algorithms.
Come on, this is was already "normal" decades before LLMs, that's why an entire zoo of high level languages was created which allow to describe a solution in a highly abstract (yet still precise) way. Replacing this high level problem specification in a programming language with a "sloppy" human language specification is arguably even a step back.
(also tbf, I'm writing this comment while sitting in a cafe while the LLM at home is busy coding a GL mocking library ;) (which is exactly the boring type of throwaway code which should be automated)
duxup
2 days ago
I think I feel similarly to you.
M currently re-writing an app that I wrote years ago. All the issues came from data structures, queries, architecture that didn’t fit what emerged as the use case.
Now I can focus on those things and work far faster, and even ADJUST architecture, theorize about pros and cons of changes as I work … sometimes I find that some adjustments are easier than I thought.
The result is far faster development, and a more optimal result where I can stay focused on improvements / efficiency rather than random minutia.
_zoltan_
3 days ago
a lot of people don't understand that the joy of making something is not coding but actually being able to build anything I want. AI just made it 50x better, as exactly as you said, we don't need to deal with the useless junk (what's the API syntax? what's the library syntax? oh it changed in the last 3 versions, let me look up the new API, this and that...).
it's great.
omnicognate
3 days ago
> a lot of people don't understand that the joy of making something is not coding but actually being able to build anything I want
I expect "a lot of people" understand perfectly well that that's where the joy comes from for you. Do you not understand that other people have different motivations?
ozim
2 days ago
Crafting code in your preferred language in a way that it is easily understood by others or fulfills some other constraints while doing whatever algorithm requires can be as fulfilling as writing poetry.
I can write „you live, you die, get over with it, life is hard, love hurts” - it basically encodes all wisdom of countless poems, books. Yet I have seen many people getting that idea better when the knowledge of this simple truth is in a form of a story.
Conversely, if you write an algorithm using better structure, better data structures it makes a lot of difference.
_zoltan_
3 days ago
coding for the sake of coding is, well, dumb.
2muchcoffeeman
2 days ago
The number of down votes the parent comment has seems to me like a litmus test of people who will use AI and those that are just critical of it.
I have my reservations about AI but so far I’ve found ways to make me faster. So I’ll continue to use it but make sure to review my usage regularly.
omnicognate
2 days ago
The number of downvotes reflects the fact that people don't consider just calling something "dumb" a worthwhile contribution to the discussion.
user
2 days ago
stavros
3 days ago
Is painting for the sake of painting dumb too?
_zoltan_
2 days ago
that's a dumb comparison. are you equating writing code to painting like Michaelangelo?
SoftTalker
2 days ago
Did Michaelangelo paint his works himself, or did he buy a bunch of slaves and give them some prompting?
_zoltan_
2 days ago
Eh, take your fav painter then.
Ekaros
2 days ago
How can you have proper real understanding of data structures and algorithms without at same time having line-by-line mental model?
Or do you blindly trust what machine tells you at whatever time you are communicating with it?
Architecture I might give not needing line-by-line model. But I really doubt the same with data structures and algorithms. Those are in the end build from lines.
jampekka
2 days ago
Djikstra seemed to manage?
https://en.wikipedia.org/wiki/Edsger_W._Dijkstra#Use_of_tech...
Ekaros
2 days ago
Seems to indicate to me that he had full mental model of everything. Whole thing in his head at once. Clearly having it in mental model sentence by sentence.
AI would here be the word processor.
layer8
2 days ago
He still thought in terms of what the actual code would need to be, at that level of precision, and also wrote pseudo-code.
Seattle3503
2 days ago
> one where software engineers can focus on data structures, software architecture and algorithms.
I see this a lot and I'm not sure why people don't think AI will be able to do this too. The self-play training that got them writing code can be used for this too.
Daishiman
2 days ago
Given enough context for a business problem, sure. But LLMs are not in a condition to judge how you should pick the technical solution to a business problem with several stakeholders, risks, and so on.
Seattle3503
2 days ago
With the speed AI moves, a lot of technical decisions become reversible. And while engineering often makes decisions that could lie elsewhere in the business, outside of engineering, I could imagine those decisions moving elsewhere in a fully AI world.
Do you have examples of things that would be hard to train for? One that could be compensated for with changes elsewhere in the business process?
Daishiman
2 days ago
Yes, if Alex from BizDev is a scheming moron who consistently lies about the priority of features, it’s hard to keep an LLM on the loop about it when transcribing meetings and feature requests. If your boss is gonna be unavailable for a month and that means that a junior devs garbage PRs will be getting merged because the second in command is much laxer then you need to be aware for that and so on.
What I mean is that these things decant into technical decisions and even with all the AI in the world running a DB schema migration does not become any more trivial.
unethical_ban
2 days ago
In the long term, I think you're correct. In the medium term, AI still won't know your business-specific workflows and data relationships, and humans are needed to define those things and let the AI build the scaffolding around it.
throwaway893257
3 days ago
> We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
I prefer an AI that is good at data structures, architecture and algorithms. Then, finally, no more leetcode.
0trip
2 days ago
leetcode and data structures are 2 different things. Just like a marathon and jogging in the park
archagon
2 days ago
AI is not an abstraction and is not like moving up from assembly at all.
andrekandre
4 hours ago
not that i disagree, but its funny because i just came back from a presentation from a "chief ai officer" where he boldly stated that ai is the next big abstraction for programmers (even had fancy charts and tables to boot)
archagon
4 hours ago
I find it disturbing how often supposed professionals make this claim.
abathologist
2 days ago
> We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
This is what declarative programming gives us, not what LLM-based generation offers.
> I love being able to quickly bring out the program that is already running in my head without having to worry about the grind of typing it into a format that the compiler understands.
Using natural instead of a formal language to get probabilistic results based on token fields is not bypassing arbitrary constraints of the compiler, it is dereliction of the responsibility to know and articulate precisely what you are specifying.
dtj1123
2 days ago
Would you mind elaborating on where exactly the boundary between vibe coding and AI assisted coding lies?
GoblinSlayer
2 days ago
Architecture is the first to be outsourced to AI, because AI shepherds have no idea how to do it.
epolanski
3 days ago
You're describing software developers, even better, coders, not really engineers.
flyingshelf
3 days ago
> AI-assisted coding, on the other hand, rekindled my passion for computers.
AI-assisted coding isn't a thing. Why would anyone pay you to code when your competitor spends 1 minute spelling out a problem and doing the same thing for 59 more problems?
As far as I'm concerned coding is dead as a profession, now we are Harness Managers.
flyingshelf
3 days ago
You guys can downvote all you want. If you don't already realize this you'll realize soon enough.
ghthor
3 days ago
This is where I’m at as well. It is incredibly liberating I feel very empowered
bitwize
2 days ago
> We are going from the era of manual, line-by-line mental model transcription to one where software engineers can focus on data structures, software architecture and algorithms.
AI is getting good at picking those as well. Frontier models can be fed a vague problem, analyze the code base, and pick out an architectural solution that makes sense.
We're going from a world that needs specialized "software engineers" to speak the language of the machine into one where ordinary people need only sit down and think, "what exactly would solve my problem here?", spell it out in ordinary procedural language, and get a software solution that employs best practices without the intervention of professional computer-touchers.
Tim Bryce was right 20 years ago. Abolish programmers, bring back systems analysts!
vouaobrasil
2 days ago
There will always be people who will like it because they are the ones getting ahead and get some reward. If a person is rewarded for something, it's unlikely that they'll care how the reward comes or be critical of the mechanism. It's just human nature; AI has incredible downsides but those who get ahead won't mind, as long as they get ahead.
I bet thieves feel a rush when they rob a store. Does that also make it right?