All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves, to a raciness in load_json where it's checked for file existence with an if and then carrying on as if the file is certainly there...
In a nutshell, if the rest of it is like this, it simply sucks.
Also…
def _save_current_date_time(current_date_time_file: str, current_date_time: str) -> None:
with Path(current_date_time_file).open("w") as f:
f.write(current_date_time)
The scary thing is: I have seen professional human developers write worse code.
I far from a heavy LLM coder but I’ve noticed a massive excess of unnecessary comments in most output. I’m always deleting the obvious ones.
But then I started noticing that the comments seem to help the LLM navigate additional code changes. It’s like a big trail of breadcrumbs for the LLM to parse.
I wouldn’t be surprised if vibe coders get trained to leave the excess comments in place.
Anyway, I don't think any of the current LLMs are really good for coding. What it's good at is copy-pasting (with some minor changes) from the massive code corpus it has been pre-trained. For example, give it some Zig code and it's straight unable to solve even basic tasks. Same if you give it really unique task, or if you simply ask for potential improvements of your existing code. Very, very bad results, no signs of out-of-box thinking whatsoever.
BTW: I think what people are missing is that LLMs are really great at language modeling. I had great results, and boosts in productivity, just by being able to prepare the task specification, and do quick changes in that really easily. Once I have a good understanding of the problem, I can usually implement everything quickly, and do it in much much better way than any LLM can currently do.
the dev is just lazy to not include them anymore, wheres the model doesn't really need to be lazy, as paid by the token
It’s trivial to ask Claude via Cursor to add comments to illustrate how some code works. I’ve found this helpful with uncommented code I’m trying to follow.
I haven’t seen it hallucinate an incorrect comment yet, but sometimes it will comment a TODO that a section should be made more more clear. (Rude… haha)
This is a human sentiment because we can fairly easily pick up abstractions during reading. AIs have a much harder time with this - they can do it, but it takes up very limited cognitive resources. In contrast, rewriting the entire software for a change is cheap and easy. So to a point, flat and redundant code is actually beneficial for a LLM.
Remember, the code is written primarily for AIs to read and only incidentally for humans to execute :)
This is kind of the rub of it all. If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter? I mean at that point its kind of like looking at the output of a bytecode compiler and being like "wow what a mess". And it's not like they can't write code up to your stylistic standards, it's just literally a matter of prompting for that.
You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.
We did this song and dance pretty recently with dynamic typing. Developers thought it was so much more productive to use dynamically typed languages, because it is in the initial phases. Then years went by, those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities, and those developers who hyped up dynamic typing invented Python/PHP type hinting and Flow for JavaScript, later moving to TypeScript entirely. Nowadays nobody seriously recommends building long-lived systems in untyped languages, but they are still very useful for one-off scripting and more interactive/exploratory work where correctness is less important, i.e. Jupyter notebooks.
I wouldn't be surprised to see the same pattern happen with low-supervision AI code; it's great for popping out the first MVP, but because it generates poor code, the gung-ho junior devs who think they're getting 10x productivity gains will wisen up and realize the value of spending an hour thinking about proper levels of abstraction instead of YOLO'ing the first thing the AI spits out when they want to build a system that's going to be worked on by multiple developers for multiple years.
You'll notice the type systems being bolted onto dynamic languages or found in serious attempts at new languages are radically different than the type systems being rejected by the likes of javascript, python, ruby and perl.
In my experience, type checking / type hinting already starts to pay off when more than one person is working on an even small-ish code base. Just because it helps you keep in mind what comes/goes to the other guy's code.
A fairly incompetent one, in my experience. And don't even get me started on "me 3 months ago", that guy's even worse.
I think this has a ton to do with the mixed results from "vibe coding" we've seen as the codebase grows in scope and complexity. Agents seem to break down without a good type system. Same goes for JS.
I've just recently started on an Objective-C project using Cline, and it's like nirvana. I can code out an entire interface and have it implemented for me as I'm going. I see no reason it couldn't scale infinitely to massive LOC with good coding practices. The real killer feature is header files. Being able to have your entire projects headers in context at all time, along with a proper compiler for debugging, changes the game for how agents can reason on the whole codebase.
Humans also worry about their jobs, especially in PIP-happy companies; they are very well known for writing intentionally over-complicated code that only they understand so that they are irreplaceable
For example, I've seen a C# application where every function takes in and outputs an array of objects, supposedly built that way so the internal code can be modified without ever having to worry about the contract breaking. It was just as bad as you are imagining, probably worse. Was that incompetence or building things to be so complicated that others would struggle to work on it?
Also I find "AI makes crap code so we should give it a bigger task" illogical.
This is my issue with all the AI naysayers at this point. It seems to all boil down to "haha, stupid noob can't code so he uses AI" in their minds. It's like they are incapable of understanding that there could simultaneously be a bunch of junior devs pushing greenfield YouTube demos of vibe coding, while at the same time expert software engineers are legitimately seeing their productivity increase 10x on serious codebases through judicious use.
Go ahead and keep swinging that hammer, John Henry.
It's funny you would say this, because we are really commenting on an article where a self-proclaimed "expert" has done that and the "10x" output is terrible.
I'm working in the field professionally since June 1998, and among other things, I was the tech lead on MyHammer.de, Germany's largest craftsman platform, and have built several other mid-scale online platforms over the decades.
How well I have done this, now that's for others to decide.
Quite objectively though, I do have some amount of experience — even a bad developer probably cannot help but pick up some learnings over so many years in relevant real-world projects.
However, and I think I stated this quite clearly, I am expressively not an expert in Python.
And yet, I could realize an actually working solution that solves an actual problem I had in a very real sense (and is nicely humming away for several weeks now).
And this is precisely where yes, I did experience a 10x productivity increase; it would have certainly taken me at least a week or two to realize the same solution myself.
I don't doubt this is doing something useful for you. It might even be mostly correct.
But it is not a positive advertisement for what AI can do: just like the code is objectively crap, you can't easily trust the output without a comprehensive review. And without doubting your expertise, I don't think you reviewed it, or you would have caught the same smells I did.
What this article tells me is that when the task is sufficiently non-critical that you can ignore being perfectly correct, you can steer AI coding assistants into producing some garbage code that very well might work or appear to work (when you are making stats, those are tricky even with utmost manual care).
Which is amazing, in my opinion!
But not what the premise seems to be (how a senior will make it do something very nice with decent quality code).
Out of curiosity why did you not build this tool in a language you generally use?
And if I cannot bring language-proficiency to the table — which of my capabilities as a seasoned software&systems guy can I put to use?
In the brown-field projects where my team and I have the AI implement whole features, the resulting code quality — under our sharp and experienced eyes — tends to end up just fine.
I think I need to make the differences between both examples more clear…
Btw, AI doesn't just code, there are AIs for debugging, monitoring etc too.
No, coding speed is really not the bottleneck to software engineer productivity.
No one said productivity is this one thing and not that one thing, only you say that because it's convenient for your argument. Productivity is a combination of many things, and again it's not just typing out code that's the only area AI can help.
Again, the context here was that somebody discussed speed of coding and you raised the point of not using any tooling with Notepad.
But that's not what we get in this early stage of grifting. We get 10% marketing buzz on how cool this is with stuff that cannot be recreated in the tool alone, and 89% of lazy or inexperienced developers who just turn in slop with little or no iteration. The latter don't even understand the code they generated.
That 1% will be amazing, it's too bad the barrel is full of rotten apples hiding that potential. The experts also tend to keep to themselves, in my experience. the 89% includes a lot of dunning-kruger as well which makes those outspoken experts questionable (maybe a part of why real experts aren't commenting on their experience).
Iin this case, I did put in the guard rails to ensure that I reach my goal in hopefully a straight line and a quickly as possible, but to be honest, I did not give much thought to long-term maintainability or ease of extending it with more and more features, because I needed a very specific solution for a use case that doesn't change much.
I'm definitely working differently in my brown-field projects where I'm intimately familiar with the tech stack and architecture — I do very thorough code reviews afterwards.
People have different definitions of "reasonably maintainable", but if code has extra stuff that provides no value, it always perplexes the reader (what is the point of this? what am I missing?), and increases cognitive load significantly.
But if AI coding tools were advertised as "get 10x the output of your least capable teammate", would they really go anywhere?
I love doing code reviews as an opportunity to teach people. Doing this one would suck.
That's not the scary part. It's the honest part. Yes, we all have (vague) ideas of what good code looks like, and we might know it when we see it but we know what reality looks like.
I find the standard to which we hold AI in that regard slightly puzzling. If I can get the same meh-ish code for way less money and way less time, that's a stark improvement. If the premise is now "no, it also has to be something that I recognize as really good / excellent" then at least let us recognize that we have past the question if it can produce useful code.
But whenever someone advertises how an expert will benefit from it yet they end up with crap, it's a different discussion.
As an expert, I want AI to help me produce code of similar quality faster. Anyone can find a cheaper engineer (maybe five of them?) that can produce 5-10x the code I need at much worse quality.
I will sometimes produce crappy code when I lack the time to produce higher quality code: can AI step in and make me always produce high quality code?
That's a marked improvement I would sign up for, and some seem to tout, yet I have never seen it play out.
In a sense, the world is already full of crappy code used to build crappy products: I never felt we were lacking in that department.
And I can't really rejoice if we end up with even more of it :)
With AI they can simply blame whatever model they used and continually shovel trash out there instantly.
If you're in a team where somebody can continuously commit trash without any repercussions, this isn't a problem caused by AI.
They’re very good at honing bad code into good code with good feedback. And when you can describe good code faster than you can write it - for instance it uses a library you’re not intimately familiar with - this kind of coding can be enormously productive.
And they're very bad at keeping other code good across iterations. So you might find that while they might've fixed the specific thing you asked for—in the best case scenario, assuming no hallucinations and such—they inadvertently broke something else. So this quickly becomes a game of whack-a-mole, at which point it's safer, quicker, and easier to fix it yourself. IME the chance of this happening is directly proportional to the length of the context.
So, how did I end up with a logging.py, config.py, config in __init__.py and main.py? Well I prompted for it to fix the logging setup to use a specific format.
I use cursor, it can spit out code at an amazing rate and reduced the amount of docs I need to read to get something done. But after its second attempt at something you need to jump in and do it yourself and most likely debug what was written.
In some ways this is even more impressive -- every prompt you make, your LLM is in effect re-reading (and re-comprehending) your whole codebase, from scratch!
Perhaps there is simply too much crappy Python code around that they were trained on as Python is frequently used for "scripting".
Perhaps the field has moved on and I need to try again.
But looking at this, it would still be faster for me to type this out myself than go through multiple rounds of reviews and prompts.
Really, a senior has not reviewed this, no matter their language (raciness throughout, not just this file).
Every since ~4o models, there seems to be a pretty decent chance that you ask it to change something specific and it says it will and it spits out line for line identical code to what you just asked it to change.
I have had some really cool success with AI finding optimizations in my code, but only when specifically asked, and even then I just read the response as theory and go write it myself, often in 1-15% the LoC as the LLM
Worse by far is still the ability of AI to really integrate different problems and combine them into a solution. And it also seems to depend on the language. In my opinion especially Python and JS results are often very mixxed while other languages with presumably a smaller training set might even fare better. JS seems often fine with asynchronous operation like that file check however.
Perhaps really vetting a training set would improve AIs, but it would be quite work intensive to build something like that. That would require a lot of senior devs, which is hard to come by. And then they need to agree on code quality, which might be impossible.
But the alternative would be the tool doesn't get built because the author doesn't know enough Python to even produce crappy code, or doesn't have the money to hire an awesome Python coder to do that for them.
Note how it has invented the faster parameter for the zpool command. It is possible that the blog writer hallucinated a faster parameter themselves without needing a LLM - who knows.
I think all developers should add a faster parameter to all commands to make them run faster. Perhaps a LLM could create the faster code.
I predict an increase of man page reading, and better quality documentation at authoritative sources. We will also improve our skills at finding auth sources of docs. My uBlacklist is getting quite long.
The date can be spoofed. It first showed up on archive.org in December 2022, and there's no captures for the site before then, so I'm liable to believe the dates are spoofed.
I suspect they might actually have a pool named faster -- I know I've named pools similarly in the past. This is why I now name my pools after characters from the Matrix, as is tradition.
How useful is a library of knowledge when n% of the information is suspect? We're all about to find out.
But then again the old id doesn't match between the two commands.
def ensure_dir_exists(path: str) -> None:
"""
Ensure a directory exists.
Args:
path: Directory path
"""
# Ensure the directory exists and is writable
ensure_dir_exists(work_dir)
work_path = Path(work_dir)
if not work_path.exists() or not os.access(work_dir, os.W_OK):
This might not matter here because it's a small, trivial example, but if you have 10, 50, 100, 500 developers working on a codebase, and they're all thoughtlessly slinging code like this in, you're going to have a dumpster fire soon enough.
I honestly think "vibe coding" is the best use case for AI coding, because at least then you're fully aware the code is throwaway shit and don't pretend otherwise.
edit: and actually looking deeper, `ensure_dir_exists` actually makes the directory, except it's already been made before the function is called so... sigh. Code reviews are going to be pretty tedious in the coming years, aren't they?
It will take some time tho, as decision makers will struggle to make up reasons why why noone on the payroll is able to fix production.
Software that’s well designed and architected is a pleasure to read and write, even if a lower quality version would get the job done. I’m watching one of the things I love most in the world become more automated and having the craftsmanship stripped out of it. That’s a bit over dramatic from me, but it’s been sad to watch.
I agree with you that it is sad. And what is especially sad is that the result will probably be lower quality overall, but much cheaper. It’s the inevitable result of automation.
Saying that, for typed languages like TypeScript and C#, they have gotten very good. I suspect this might be related to the semantic information can be found in typed languages, and hard to follow unstructured blobs like dataframes, and there for, not well repeated by LLMs.
It's probably because spark is so backwards compatible with pandas, but not fully.
> However, my broad understanding of software architecture, engineering best practices, system operations, and what makes for excellent software projects made this development process remarkably smooth.
If the seniors are going to write this sort of Python code and then talk about how knowledge and experience made it smooth or whatever, might as well hire a junior and let them learn through trials and tribulations.
The Python standard library has a configparser module, which should be used instead of custom code. It's safer and easier than manual parsing. The standard library also has a tomllib module, which would be an even better option IMO.
While I would have hoped for a better result, I'm not surprised. In this particular case, I really didn't care about the code at all; I cared about the end result at runtime, that is, can I create a working, stable solution that solves my problem, in a tech stack I'm not familiar with?
(While still taking care of well-structured requirements and guard rails — not to guarantee a specific level of code quality per se, but to ensure that the AI works towards my goals without the need to intervene as much as possible).
I will spin up another session where I ask it to improve the implementation, and report back.
I asked $random_llm to give me code to recursively scan a directory and give me a list of file names relative to the top directory scanned and their sizes.
It gave me working code. On my test data directory it needed ... 6.8 seconds.
After 5 min of eliminating obvious inefficiencies the new code needed ... 1.4 seconds. And i didn't even read the docs for the used functions yet, just changed what seemed to generate too many filesystem calls for each file.
What if I had trusted the code? It was working after all.
I'm guessing that if i asked for string manipulation code it would have done something worth posting on accidentally quadratic.
600% improvement is worth what, 3 days of billable work if it lasts 5 minutes?
In such a place I should be a very loud advocate of LLMs, use them to generate 100% of my output for new tasks...
... and then "improve performance" by simply fixing all the obvious inefficiencies and brag about the 400% speedups.
Hmm. Next step: instruct the "AI" to use bubblesort.
Then you would have been done five minutes earlier? I mean, this sort of reads like a parody of microoptimization.
If you hadn't told me that I would also not have bothered optimizing syscalls.
Did you tell the AI the profiler results and ask for ways to make it faster?
Acting like a LLM now :P
> Did you tell the AI the profiler results and ask for ways to make it faster?
Looking for ways to turn a 10 minute job into a couple days?
> Acting like a LLM now :P
Hey, if we're going to be like that, it sure sounds like you gave the employee an incomplete spec so you could then blame it for failing. So... at least I'm not acting like a PM :P
Your brilliant AI calls another low level function to get the file size on the file name. (also did worse stuff but let's not go into details).
Do you call reading the file size from the in memory structure that you already have a speed optimization? I call it common sense.
It's so funny how these AI bros make excuse after excuse for glaring issues rather than just accept AI doesn't actually understand what it's doing (not even considering it's faster to just write good quality code on the first try).
Stuff that google search from 10 years ago would have done without pretending it's "AI". But not google search from this year.
* it wasn't able to simply list the fields of the returned structure that contained a directory entry. But since it gave me the name, i was able to look it up via plain search.
Its less funny when you realize how few of these people even have experience reading and writing code.
They just see code on screen, trust the machine and proclaim victory.
because that is what the market is trying to sell?
Explain the issue with load_json to me more. From my reading it checks if the file exists, then raises an error if it does not. How is that carrying on as if the file is certainly there?
It's not a race. It's just redundant. If the file does not exist at the time you actually try to access it you get the same error with slightly better error message.
There are plenty of ways to structure code so this does not happen, but simply "do not do anything at the top module level" will ensure you don't hit these issues.
By the way, prompting models properly helps a lot for generating good code. They get lazy if you don't explicitly ask for well-written code (or put that in the system prompt).
It also helps immensely to have two contexts, one that generates the code and one that reviews it (and has a different system prompt).
This is insane on so many levels.
https://github.com/dx-tooling/platform-problem-monitoring-co...
Where things are placed in the project seems rather ad hoc too. Put everything in the same place kind of architecture. A better strategy might be to separate out the I and the O of IO. Maybe someone wants SMS or group chat notifications later on, instead of shifting the numbers in filenames step11_ onwards one could then add a directory in the O part and hook it into an actual application core.
As far as knowledge/experience, I worry about a day where "vibe coding" takes over the world and it's only the greybeards that have any clue WTF is going on. Probably profitable, but also sounds like a hellscape to me.
I would hate to be a junior right now.
All said, it’s hard on me knowing it’s possible to use llm to spit out a crappy but functional version of whatever I’ve dreamt up with out satisfaction of building it. Yet, it also seems to now be demotivating to spend the time crafting it when I know I could use llm to do a majority of it. So, I’m in a mental quagmire, this past year has been the first year since at least 2000 that I haven’t built anything significant in scale. It’s indirectly ruining the fun for me for some reason. Kind of just venting but curious if anyone else feels this way too?
But I've been using Claude to help with all kinds of side projects. One recently was to help create and refine some python code to take the latest Wikipedia zipped XML file and transform/load it locally into a PostgreSQL DB. The initial iteration of the code took ~16 hours to unzip, process, and load into the database. I wanted it to be faster.
I don't know how to use multiple processes/multi-threading, but after some prompting, iterating, and persistent negotiations with Claude to refine the code (and an SSD upgrade) I can go from the 24gb zip file to all cleaned/transformed data in the DB in about 2.5 hours. Feels good man.
Do I need to know exactly what's happening in the code (or at lowers levels, abstracted from me) to make it faster? not really. Could someone who was more skilled, that knew more about multi-threading, or other faster programming languages, etc..., make it even faster? probably. Is the code dog shit? it may not be production ready, but it works for me, and is clean enough. Someone who better knew what they were doing could work with it to make it even better.
I feel like LLMs are great for brainstorming, idea generation, initial iterations. And in general can get you 80%+ the way to your goal, almost no matter what it is, much faster than any other method.
I take it as an opportunity to learn too. I'm working on a video library app that runs locally and wanted to extract images when the scene changed enough. I had no idea how to do this, and previously would have searched StackOverflow to find a way and then struggled for hours or days to implement it. This time I just asked Aider right in the IDE terminal what options I had, and it came back with 7 different methods. I researched those a little and then asked it to implement 3 of them. It created an interface, 3 implementations and a factory to easily get the different analyzers. I could then play around with each one and see what worked the best. It took like an hour. I wrote a test script to loop over multiple videos and run each analyzer on them. I then visually checked the results to see which worked the best. I ended up jumping into the code it had written to understand what was going on, and after a few tweaks the results are pretty good. This was all done in one afternoon - and a good chunk of that time was just me comparing images visually to see what worked best and tweaking thresholds and re-running to get it just right.
Example:
I'm building a tool to grab my data from different sites like Steam, Imdb, Letterboxd and Goodreads.
I know perfectly well how to write a parser for the Goodreads CSV output, but it doesn't exactly tickle my brain. Cursor or Cline will do it in minutes.
Now I've got some data to work with, which is the fun bit.
Again if I want to format the output to markdown for Obsidian, the LLM can do it in a few minutes and maybe even add stuff I didn't think about at first.
It's been depressing to listen to people pretend that LLM generated code is "the same thing". To trivialize the thoughtful lessons one has learned honing their craft. It's the same reason the Studio Ghilbi AI image trend gives me the ick.
I agree though that the Studio Ghibli trend feels off. To me, art like this feels different to code. I know that's probably heresy around these parts of the internet, and I probably would have said something different 15-20 years ago. I know that coding is creative and fulfilling. I think I've just had the fun of coding beat out of me over 25 years :) AI seems to be helping bring the fun back.
It also lets me explore other libraries and languages without having to invest too much time and effort before knowing if it's right for what I want to do. I know that if I want to continue in a different direction, I haven't wasted tons of time/effort and getting started in the new direction will be much less effortful and time consuming.
On the other hand, most tasks aren't fun nor satisfying and frankly they are a waste of time, like realizing you're about to spend the afternoon recredentializing in some aspect of Webpack/Gradle/BouncyCastle/Next.js/Combine/x/y/z just to solve one minor issue. And it's pure bliss when the LLM knows the solution.
I think the best antidote to the upset in your comment is to build bigger and more difficult things. Save your expertise for the stuff that could actually use your expertise rather than getting stuck wasting it on pure time burn like we had to in the past.
LLMs can one-shot pretty good server-authority + client-prediction + rollback netcode, something I've probably spent weeks of my life trying to build and mostly failing. And they can get a basic frontend 'proof' working. And once you verify that the networked MVP works, you can focus on the game.
But the cool thing about multiplayer games is that they can be really small in scope because all of the fun comes from mechanics + playing with other people. They can be spaceships shooting at each other in a single room or some multiplayer twist on a dumbed down classic game. And that's just so much more feasible than building a whole game that's expected to entertain you as a single player.
I'm pragmatic and simply don't trust current LLM's to do much in my domain. All that tribal knowledge is kept under lock and key at studios, so good luck scraping the net to find more than the very basic samples of how to do something. I've spent well over a decade doing that myself; the advanced (and even a lot of intermediate) information is slim and mostly behind paywalls or books.
So far none of them are having a great time after their initial enthusiasm. A lot of it is people discovering that there’s far more to a business than whipping up a SaaS app that does something. I’m also seeing a big increase in venting about how their progress is slowing to a crawl as the codebase gets larger. It’s interesting to see the complaints about losing days or weeks to bugs that the LLM introduced that they didn’t understand.
I still follow because it’s interesting, but I’m starting to think 90% of the benefit is convincing people that it’s going to be easy and therefore luring them into working on ideas they’d normally not want to start.
This reminds me of the famous HN comment when Drew Houston first announced Dropbox here in 2007: https://news.ycombinator.com/item?id=9224
thankfully, I'm not important enough for my comment to amount to the same thing.
I had long ago culled many of those ideas based on my ability to execute the marketing plan or the “do I really even want to run that kind of business?” test. I already knew I could build whatever I wanted to exist so My days of pumping out side projects ended long ago and I became more selective with my time.
a project in a niche where I live and breath the fumes off the work and I can help the whole ecosystem with their workflow? sign me up!
Any SaaS business. In a week. And to be a "serious contender", you have to have feature parity. Yet now you're shifting the goalposts.
What's stopping you? There are 38 weeks left in 2025. Please build "serious contenders" for each of the top 38 most popular SaaS products before the end of the year. Surely you will be the most successful programmer to have ever lived.
My claim is that in a week you could build a thing that people want to use, as long as you can sell it, that's competitive with existing options for a given client. Salesforce is a CRM with walled gardens after walled garden. access to each of which costs extra, of course. they happened to be in the right place at the right time, with the right bunch of assholes.
A serious contender doesn’t have to start with everything. It starts by doing the core thing better—cleaner UX, clearer value, easier to extend. That’s enough to matter. That’s enough to grow.
I’m not claiming to replace decades overnight. But momentum, clarity, and intent go a long way. Especially when you’re not trying to be everything to everyone—just the right thing for the right people.
as for Spotify: https://bit.ly/samson_music
I'm not sure what you are trying to say here - that this website is comparable to Spotify? Even if you are talking about just the "core experience", this example supports the opposite argument that you are trying to make.
Spotify has the licensing rights to songs and I don't have the business acumen to go about getting those rights, so I guess I could make Pirate Spotify and get sued by the labels for copyright infringement, but that would just be a bunch of grief for me which would be not very fun and why would I want to screw artists out of getting paid to begin with?
i think ive detected the root cause of your problem.
and, funnily enough, it goes a long way to explaining the experiences of some other commentators in this thread on “vibe coding competitive SaaS products”.
Spotify is not the audio player widget in some user interface. It started off as a Torrent-like P2P system for file distribution on top of a very large search index and file storage. That's the minimum you'd build for a "whitelabel [...] Spotify clone". Since then they've added massive, sophisticated systems for user monitoring and prediction, ad distribution, abuse and fraud detection, and so on.
Use that code generation platform to build a product off any combination of two of the larger subsystems at Spotify and you're set for retirement if you only grab a reasonable salesperson and an accountant off the street. Robust file distribution with robust abuse detection or robust ad distribution or robust user prediction would be that valuable in many business sectors.
If building and maintaining actually is that effortless for you, show some evidence.
I'm listening. I fully admit that I was looking at Spotify as a user and thus only as a music playing widget so I'd love to hear more about this side of things. What is user prediction?
You can find out quite a lot in their blogs and publications:
https://research.atspotify.com/2022/02/modeling-users-accord...
I skimmed the vibecoding subreddits for a while. It was common to see frustrations about how coding tools (Cursor, Copilot, etc) were great last month but terrible now. The pattern repeats every month, though. When you look closer it’s usually people who were thrilled when their projects were small but are now frustrated when they’re bigger.
On Greenfield projects there's simply too many options for it to pursue. It will take one approach in one place then switch to another.
On a brownfield project, you can give it some reference code and tell it about places to look for patterns and it will understand them.
Bolting AI onto existing products probably doesn't make sense. AI is going to produce an entirely new set of products with AI-first creation modalities.
You don't need AI in Photoshop / Gimp / Krita to manipulate images. You need a brand new AI-first creation tool that uses your mouse inputs like magic to create images. Image creation looks nothing like it did in the past.
You don't need Figma to design a webpage. You need an AI-first tool that creates the output - Lovable, V0, etc. are becoming that.
You don't need AI in your IDE. Your IDE needs to be built around AI. And perhaps eventually even programming languages and libraries themselves need AI annotations or ASTs.
You don't need AI in Docs / Gmail / Sheets. You're going to be creating documents from scratch (maybe pasting things in). "My presentation has these ideas, figures, and facts" is much different than creating and editing the structure from scratch.
There is so much new stuff to build, and the old tools are all going to die.
I'd be shocked if anyone is using Gimp, Blender, Photoshop, Premiere, PowerPoint, etc. in ten years. These are all going to be reinvented. The only way these products themselves survive is if they undergo tectonic shifts in development and an eventual complete rewrite.
That's a long time for Adobe not to have figured out what your are saying.
A faster GPT 4o will kill Photoshop for good.
Even the latest model from this week, which is undeniably impressive, can’t get close to the level of control that photoshop gives me. It often edits parts of the image I haven’t asked it to touch among other issues. I use photoshop as a former photojournalist, and AI manipulated images are of no use to me. My photos are documentary. They represent a slice of reality. I know that AI can create a realistic simulacrum of that, but I’m not interested.
This is like saying we won’t need text editors in the future. That’s silly, there are some things that we won’t need text editors for, but the ability of ai to generate and edit text files doesn’t mean that we won’t ever need to edit them manually.
I'm really eager to see how this pans out in a decade.
I am not going to spend half an hour coming up with that prompt, tweaking it, and then spend many hours (on the optimistic side) to track down all the hallucinated code and hidden bugs. Have been there once, never going to do that again.
I'd rather do it myself to have a piece of mind.
I start every piece of work, green or brown, with a markdown file that often contains my plan, task breakdown, data models (including key fields), API / function details, and sample responses.
For the tool part, though, I took a slightly different approach. I decided to use Rust primarily for all my projects, as the compile-time checks are a great way to ensure the correctness of the generated code. I have noticed many more errors are detected in AI-generated Rust code than in any other language. I am happy about it because these are errors that I would have missed in other languages.
Is that because the Rust compiler is just a very strong guardrail? Sounds like it could work well for Swift too. If only xcodebuild were less of a pain for big projects.
Regarding swift, totally hear you :) Also I haven’t tried generating swift code - wondering how well that would be trained as there are fewer open source codebases for that.
Basically the state of the art right now can turn me into an an architect/CTO that spends a lot of time complaining about poor architectural choices. Crucially Claude does not quite understand how to greenfield implement good architectures. 3.7 is also JUST . SO. CHATTY. It’s better than 3.5, but more annoying.
Gemini 2.5 needs one more round of coding tuning; it’s excellent, has longer context and is much better at arch, but still occasionally misformats or forgets things.
Upshot — my hobby coding can now be ‘hobby startup making’ if I’m willing to complain a lot, or write out the scaffolding and requirements docs. It provides nearly no serotonin boost from getting into flow and delivering something awesome, but it does let me watch YouTube on the side while it codes.
Decisions..
If it’s high surprise then there’s a greater chance that you can’t tell right code from wrong code. I try to reframe this in a more positive light by calling it “exploration”, where you can ask follow up questions and hopefully learn about a subject you started knowing little about. But it’s important for you to realize which mode you are in, whether you are in familiar or unfamiliar waters.
https://royalicing.com/2025/infinite-bicycles-for-the-mind
The other benefit an experienced developer can bring is using test-driven development to guide and constrain the generated code. It’s like a contract that must be fulfilled, and TDD lets you switch between using an LLM or hand crafting code depending on how you feel or the AI’s competency at the task. If you have a workflow of writing a test beforehand it helps with either path.
1. Is the company providing the model willing to indemnify _your_ company when using code generation? I know GitHub Copilot will do this with the models they provide on their hardware, but if you’re using Claude Code or Cursor with random models do they provide equal guarantees? If not I wonder if it’s only a matter of time before that landmine explodes.
2. In the US, AFAICT, software that is mostly generated by non-humans is not copyrightable. This is not an issue if you’re creating code snippets from an LLM, but if you’re generating an entire project this way then none or only small parts of the code base you generate would then be copyrightable. Do you still own the IP if it’s not copyrightable? What if someone exfiltrates your software? Do you have no or little remedy?
Senior developers have the experience to think through and plan out a new application for an AI to write. Unfortunately a lot of us are bogged down by working our day jobs, but we need to dedicate time to create our own apps with AI.
Building a personal brand is never more important, so I envision a future where dev's have a personal website with thumbnail links (like a fancy youtube thumbnail) to all the small apps they have built. Dozens of them, maybe hundreds, all with beautiful or modern UIs. The prompt they used can be the new form of blog articles. At least that's what I plan to do.
the low-hanging fruit is to create content/apps to help developers create their personal brands through content/apps.
First, I can still use neovim which is a massive plus for me. Second it’s been pretty awesome to offload tasks. I can say something like “write some unit tests for this file, here are some edge cases I’m particularly concerned about” then I just let it run and continue with something else. Come back a few mins later to see what it came up with. It’s a fun way to work.
I find it quite interesting how we can do a very large chunk of the work up front in design, in order to automate the rest of the work. Its almost as if waterfall was the better pattern all along, but we just lacked the tools at that time to make it work out.
Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed.
Specs were never frozen with waterfall.
That's what waterfall always wanted to be and it failed because writing the code usually took a lot longer than writing the specs, but now perhaps, that is no longer the case.
As a frontend designer, not a developer, I'm intrigued by the techniques presented by the author, though most devs commenting here seem to be objecting to the code quality. (Way above my pay grade, but hopefully a solvable problem.)
As someone who loves to nerd out on creative processes, it's interesting indeed to contemplate whether AI assisted dev would favor waterfall vs incremental project structure.
If indeed what works is waterfall dev similar to the method described in TFA, we'll want to figure out how to use iterative process elsewhere, for the sake of the many benefits when it comes to usability and utility.
To me that suggests the main area of iteration would be A) on the human factors side: UX and UI design, and B) in the initial phases of the project.
If we're using an AI-assisted "neo waterfall" approach to implementation, we'll want to be highly confident in the specifications we're basing it all on. On regular waterfall projects it's critical to reduce the need for post-launch changes due to their impact on project cost and timeline.[1] So for now it's best to assume we need to do the same for an AI-assisted implementation.
To have confidence in our specs document we'll need a fully fledged design. A "fully humane", user approved, feature complete UX and UI. It will need to be aligned with users' mental models, goals, and preferences as much as possible. It will need to work within whatever the technical constraints are and meet the business goals of the project.
Now all that is what designers should be doing anyway, but to me the stakes seem higher on a waterfall style build, even if it's AI-assisted.
So to shoulder that greater responsibility, I think design teams are going to need a slightly different playbook and a more rigorous process than what's typical nowadays. The makeup of the design team may need to change as well.
Just thinking about it now, here's a first take on what that process might be. It's an adaptation of the design tecniques I currently use on non-waterfall projects.
----------
::Hypothesis for a UX and UI Design Method for AI-assisted, "Neo-Waterfall" Projects::
Main premise: Designers will need to lead a structured, iterative, comprehensive rapid prototyping phase at the beginning of a project.
| Overview: |
• In my experience, the DESIGN->BUILD->USE/LEARN model is an excellent guide for wrangling the iterative cycles of a rapid prototyping phase. With each "DBU/L" cycle we define problems to be solved, create solutions, then test them with users, etc.
• We document every segment of the DBU/L cycle, including inputs and outputs, for future reference.
• The USE/LEARN phase of the DBU/L cycle gives us feedback and insight that informs what we explore in the next iteration.
• Through multiple such iterations we gain confidence in the tradeoffs and assumptions baked into our prototypes.
• We incrementally evolve the scope of the prototypes and further organize the UX object model with every iteration. (Object Oriented UX, aka OOUX, is the key to finding our way to both beautiful data models and user experiences).
• Eventually our prototyping yields an iteration that fulfills user needs, business goals, and heeds technical constraints. That's when we can "freeze" the UX and UI models, firm up the data model and start writing the specifications for the neo-waterfall implementation.
• An additional point of technique: Extrapolating from the techniques described in TFA, it seems designers will need to do their prototyping in a medium that can later function as a keyframe constraint for the AI. (We don't want our AI agent changing the UI in the implementation phase of the waterfall project, so UI files are a necessary reference to bound its actions.)
• Therefore, we'll need to determine which mediums of UI design the AI agents can perceive and work with. Will we need a full frontend design structured in directories containing shippable markup and CSS? Or can the AI agent work with Figma files? Or is the solution somewhere in between, say with a combination of drawings, design tokens, and a generic component library?
• Finally, we'll need a method for testing the implemented UX and UI against the USE criteria we arrived at during prototyping. We should be able to synthesize these criteria from the prototyping documentation, data modeling and specification documents. We need a reasonable set of tests for both human and technical factors.
• Post launch, we should continue gathering feedback. No matter how good our original 1.0 is, software learns, wants to evolve. (Metaphorically, that is. But maybe some day soon--actually?) Designing and making changes to brownfield software originally built with AI-assistance might be a topic worthy of consideration on its own.
----------
So as a designer, that's how I would approach the general problem. Preliminary thoughts anyway. These techniques aren't novel; I use variations of them in my consulting work. But so far I've only built alongside devs made from meat :-)
I'll probably expand/refine this topic in a blog post. If anyone is interested in reading and discussing more, I can send you the link.
Email me at: scott [AT] designerwho [DOT] codes
----------
[1] For those who are new to waterfall project structure, know that unmaking and remaking the "final sausage" can be extremely complex and costly. It's easy to find huge projects that have failed completely due to the insurmountable complexity. One question for the future will be whether AI agents can be useful in such cases (no sausage pun intended).
So you’d set things like code standards (and hopefully enforce them via feedback tools), guides for writing certain architectures, etc. Then when you have the LLM start working it will first read that readme to “learn” how you want it to generally behave.
I’ve found that I typically edit this file as time goes on as a way to add semi-permanent feedback into the system. Even if your context window gets too large when you restart the LLM will start at that readme to prime itself.
That’s the closest analogy I can think of.
“This is especially noteworthy because I don’t actually know Python. Yes, with 25+ years of software development experience, I could probably write a few lines of working Python code if pressed — but I don’t truly know the language. I lack the muscle memory and intimate knowledge of its conventions and best practices.”
You should not use AI to just “do” the hard job, since as many have mentioned, it does it poorly and sloppy. Use AI to quickly learn the advantages and disadvantages of the language, then you do not have to navigate through documentation to learn everything, just validate what the AI outputs. All is contextual, and since you know what you want in high level, use AI to help you understand the language.
This costs speed yes, but I have more control and gain knowledge about the language I chose.
That being said, using AI as a teacher can be a wonderful experience. For us seniors, but also and probably more importantly, for eager and non-lazy juniors.
I have one such junior on my team who currently speed-runs through the craft because he uses AI to explain EVERYTHING to him: What is this pattern? Why should I use it? What are the downsides? And so on.
Of course I also still tutor him, as this is a main part of my job, but the availability of an AI that knows so much and always has time for him and never gets tired etc is just fantastic.
I'm blasting through tickets, leaving more time to tutor and help junior colleagues and do refactoring. Guiding them has then been a multiplier, and also a bit of an eye opener about how little real guidance they've been getting up until now. I didn't realise how resource constrained we'd been as a team leading to not enough time guiding and helping them.
I don't trust the tools with writing code very often but they are very good at architecture questions, outputting sample code etc. Supercharged google
As a generalist, I feel less overwhelmed
It's probably been the most enjoyable month at this job.
I know Python, but have been coding in Go for the last few years. So I'm thinking how I'd implement this in Go.
There's a lot of code there. Do you think it's a lot, or it doesn't matter? It seems reasonably clear though, easy to understand.
I'd have expected better documentation/in-line comments. Is that something that you did/didn't specify?
I really wanted to see how far I can get with that approach.
I will ask it to clean up the code and its comments and report back.
Actually coding is a relatively small part of my job. I could use an LLM for the others parts but my employer does not appreciate being given word salad.
The main message I want to bring across is two-fold:
1. Senior developers are in a great position to make productive use of AI coding tools
2. I have (so far) identified three measures that make AI coding sessions much more successful
I hope the reworked version makes these more central and clear. I'm not a native English speaker, thus it's probably not possible for me to end up with an optimal version.
Still, I hope the new approach works a bit better for you — would love to receive another round of feedback.
> For controllers, I might include a small amount of essential details like the route name: [code]
Commit history: https://github.com/dx-tooling/platform-problem-monitoring-co...
Look, I honestly think this is a fair article and some good examples, but what is with this inane “I didn’t write any of it myself” claim that is clearly false that every one of these articles keeps bringing up?
What’s wrong with the fact you did write some code as part of it? You clearly did.
So weird.
What I wanted to express was that I didn’t do any of the implementation, that is, any logic.
I need to phrase this better.
Coding by prompt is the next lowering of the bar and vibe coding even more so. Totally great in some scenarios and adds noise in others.
No, the article was just something about enjoying AI. This is hardly anything related to senior software developer skills.
1. Clearly define requirements
2. Clearly sketch architecture
3. Setup code tool suite
4. Let AI agent write the remaining code
Is better price-performance than going lighter on 1-3 and instead of 4, spending that time writing the code yourself with heavy input from LLM autocomplete, which is what LLMs are elite at.
The agent will definitely(?) write the code faster, but quality and understanding (tech debt) can suffer.
IOW the real takeaway is that knowing the requirements, architecture, and tooling is where the value is. LLM Agent value is dubious.
It also makes coding a lot less painful because I'm not making typos or weird errors (since so much code autocompletes) that I spend less time debugging too.
Those lamenting the loss of manual programming: we are free to hone our skills on personal projects, but for corporate/consulting work, you cannot ignore 5x speed advantage. It's over. AI-assisted coding won.
Otherwise, it can be 0.2x in some cases. And you should not use LLMs for anything security-related unless you are a security expert, otherwise you are screwed.
(this is SOTA as of April 2025, I expect things to become better in the near future)
If you know the programming language really well, that usually means you know what libraries are useful, memorized common patterns, and have some project samples laying out. The actual speed improvement would be on typing the code, but it's usually the activity that requires the least time on any successful project. And unless you're a slow typist, I can't see 5x there.
If you're lacking in fundamental, then it's just a skill issue, and I'd be suspicious of the result.
I just hope that most hiring managers now realize this. With AI the productivity of younger developers has gone up by a factor of 10x, but the productivity of us "Seasoned" developers has gone up 100x. This now evens the playing field, I hope, where us experienced guys will be given a fair shake in the hiring process rather than what's been happening for decades where the 20-somethings pretend to be interviewing the older guys, because some boss told them to, but they never had any actual intentions of hiring anyone over 40, just on the bases of age alone, even if some older guy aces the interview.
Would it be okay for you if I quote this on a revised version of the article (with proper attribution, of course)?
...however I'm absolutely certain there are many interviews I've aced and not gotten the job, primarily for being in an several undesirable categories that Silicon Valley progressive wokesters despise with a passion: 1) Over 40. 2) White 3) Male 4) Straight 5) Handsome 6) Rich 7) American, speaking perfect English.
All 7 of those demographic stats about me are absolutely despicable to Silicon Valley hiring managers, and any one alone is enough for them to pass by a candidate over a different one lacking the trait.
You can also quote, this post about Silicon Valley too, and there was even a time when such rants like this would've been CENSORED immediately by HackerNews. Thankfully they've lightened up a bit.
1. Do piddly algorithm type stuff that I've done 1000x times and isn't complicated. (Could take or leave this, often more work than just doing it from scratch)
2. Pasting in gigantic error messages or log files to help diagnose what's going wrong. (HIGHLY recommend.)
3. Give it high level general requirements for a problem, and discuss POTENTIAL strategies instead of actually asking it to solve the problem. This usually allows me to dig down and come up with a good plan for whatever I'm doing quickly. (This is where real value is for me, personally.)
This allows me to quickly zero in on a solution, but more importantly, it helps me zero in strategically too with less trial and error. It let's me have an in-person whiteboard meeting (as I can paste images/text to discuss too) where I've got someone else to bounce ideas off of.
I love it.
But it's usually an iterative process, I find pattern A and B on google, I'll ask the LLM and it gives A, B and C. I'll google a bit more about C. Find out C isn't real. Go back and try other people commenting on it on reddit, go back to the LLM to sniff out BS, so on and so on.
We all know how big companies handle software, if it works ship it. Basically once this shit starts becoming very mainstream companies will want to shift into their 5x modes (for their oh so holy investors that need to see stock go up, obviously.)
So once this sloppy prototype is seen as working they will just ship the shit sandwhich prototype. And the developers won’t know what the hell it means so when something breaks in the future, and that is when not if. They will need AI to fix it for them, cause once again they do not understand what is going on.
What I’m seeing here is you proposing replacing one of your legs with AI and letting it do all the heavy lifting, just so you can lift heavier things for the moment.
Once this bubble crumbles the technical debt will be big enough to sink companies, I won’t feel sorry for any of the AI boosties but do for their families that will go into poverty
I have a business which is turning in millions in ARR at the moment (made in the pandemic) it's a pest control business and we have got a small team with only 1 experienced senior engineer, we used to have 5 but with AI we reduced it to one which we are still paying well.
Even with maintenance, we plan ahead for this with an LLM and make changes accordingly.
I think we will see more organizations opting for smaller teams and reducing engineer count since now the code generated is to the point that it works, it speeds up development and that it is "good enough".
Other devs will say things like "AI is just a stupid glorified autocomplete, it will never be able to handle my Very Special Unique Codebase. I even spent 20 minutes one time trying out Cursor, and it just failed"
Nope, you're just not that good obviously. I am literally 10x more productive at this point. Sprint goals have become single afternoons. If you are not tuned in to what's going on here and embracing it, you are going to be completely obsolete in the next 6 months unless you are some extremely niche high level expert. It wont be a dramatic moment where anyone gets "fired for AI". Orgs will just simply not replace people through attrition when they see productivity staying the same (or even increasing) as headcount goes down.
It could be that other developers are not benefitting from AI as much as you because they don't understand it.
It could also be that you are benefitting more than them because you're less skilled than them, and AI can fill in your gaps but not theirs.
I don't really need AI to write code for me, because that's the easy part. The aspect that it needs to be good at is helping me ship features that works. And to this date, there's never been a compelling showcase for that one.
My projects are much more complex than standard CRUD applications. If you're building simple back-office CRUD apps, you might see a 10x productivity improvement with AI, but that hasn't been my experience with more complex work.
Grounding these conversations in an actual reality affords more context for people to evaluate your claims. Otherwise it’s just “trust me bro”.
And I say this as a Senior SWE who’s successfully worked with ChatGPT to code up some prototype stuff, but haven’t been able to dedicate 100+ hours to work through all the minutia of learning how to drive daily with it.
I'm not the OP, but on your other point about completing sprint goals fast - I'm building a video library app for myself, and wanted to add tagging of videos. I was out dropping the kids at classes and waiting for them. Had 20 minutes and said to Aider/Claude - "Give me an implementation for tagging videos." It came back with the changes it would make across multiple files: Creating a new model, a service, configuring the DI container, updating the DB context, updating the UI to add tags to videos and created a basic search form to click on tags and filter the videos. I hit build before the kids had finished and it all worked. Later, I found a small bug - but it saved me a fair bit of time. I've never been a fast coder - I stare at the screen and think way too much (function and variable names are my doom ... and the hardest problem in programming, and AI fixes this for me).
Some developers may be able to do all this in 20 minutes, but I know that I never could have. I've programmed for 25 years across many languages and frameworks, and know my limitations. A terrible memory is one of them. I would normally spend a good chunk of time on StackOverflow and the documentation sites for whatever frameworks/libraries I'm using. The AI has reduced that reliance and keeps me in the zone for longer.
But I have also spent hours asking Claude and ChatGPT with help trying to solve several annoying Django problems and I have reached the point multiple times where they circle back and give me answers that did not previously work in the same context window. Eventually when I figure out the issue, I have fun and ask it "well does it not work as expected because the existing code chained multiple filter calls in django?" and all of a sudden the AI knows what is wrong! To be fair, there was only one sentence in the django documentation that mentions not chaining filter calls on many to many relationships.
Also, Keyframing can be done in a more autonomous fashion. Sr Engineers can truly vibe code if they setup a proper framework for themselves. Key framing as described in the article is too manual.
Sorry, but as the wind blows, we only have indications of the opposite so far and it's wildly reported as a generating losing their ability for deep thought, relying too much on automated code generation. This is especially damaging for juniors, who never get the chance to learn the tricks of the trade in the first place, and they're the ones having a hard time explaining what the code the LLM generated even does.
Seniors will be few and far between, and we will charge premium for fixing up the crap LLM created, which will fit us great before retirement.
Good luck when we are retired.