So for me being able to have AI wrote certain things extremely fast with me just doing voice to text with my specific approach, is amazing.
I am all in on everything AI and have a discord server just for openclaw and specialized per repo assistants. It really feels like when I'm busy I can throw it an issue tracker number for things.
Then I will ssh via vs code or regular ssh which forwards my ssh key from 1password. My agents have read only repo access and I can push only when I ssh in. Super secure. Sorry for the tangent to the article but I have always loved coding now I love it even more.
No jobs get easier with automation - they always move a step up in abstraction level.
An accountant who was super proficient in adding numbers no longer can rely on those skills once calculator was invented.
This is the key. I haven't found that things have become harder. The hard parts are still hard, and those have been the most important and prominent parts of my job once I reached a certain level.
In any case, I think we should start treating the majority of code as a commodity that will be thrown away sooner or later.
I wrote something about this here: https://chatbotkit.com/reflections/most-code-deserves-to-die - it was inspired by another conversation on HN.
It never was
Why? Because the bottleneck was never typing code. It was always understanding the problem, making architectural decisions, debugging edge cases, and most importantly - knowing what NOT to build.
AI made me faster at producing code, but it also made me produce MORE code, which means more surface area for bugs, more maintenance burden, more complexity to reason about. The discipline of "write less code" is harder now because writing code costs almost nothing.
The engineers who thrive will be the ones who can resist the temptation to over-engineer when the marginal cost of adding complexity drops to near zero.
Why will the 8th project still have those things as the bottleneck given your experience?
Also if you're not seeing any real gains in productivity, why are you using AI for your side projects and wasting tokens/money?
At work, I was told to use AI but it doesn't actually work for anything that I couldn't have handed off to a brand new undergraduate intern. So I use it for things that I don't care about then go spend twice as long rewriting what it output because it made the task longer by being wrong.
Why do you look at it that way? Why does anyone beside you have to care about what you do?
Just build something for yourself. You will always have things you'd like to build for yourself. You will be in competition with yourself only and your target audience will be yourself.
Market forces do not apply to side-projects, because that's what people do for fun.
Just because there are chess computers, doesn't mean that no one plays chess anymore at home.
If you have no reaction at all, you probably weren't paying attention.
Eventually though, people _should_ recover and return after having processed the changes. So maybe the professor was still recovering at the time?
This is just a correction of something that managed to remain in an invalid state for an impressively long time.
In software it's the same thing. People don't really want software they want data and data transformation. But traditionally the proxy for that has been selling the software (either as a desktop app or then later as sole kind of service).
You could argue that in either case the proxy is not what people want but yet because of the difficulty of selling the "actual" thing the proxy market has flourished.
We're now inventing a new tool that will completely disrupt that market and any software business that is predicated on the complexity required to create the software to transform the data is going to get severely disrupted. Software itself will be worthless.
The value of computers since its inception was that it's capable of transforming data very, very fast and autonomously. But someone has to input that data from the real world or capture it using some device, and someone has to write the rules.
What happened is that we created a whole world of information and the rules has become very complex. Now we have multiple layers stacked vertically and multiple domains spread horizontally. At one time, ASCII was enough, now we have to deal with Unicode.
Software becoming worthless will mean that everyone has learned the rules of the systems we created and capable of creating systems with good enough quality. I'm not seeing that happens anytime soon.
The whole side project or even private project thing doesn't just hinge on being able to produce software. There's a lot more.
A lot of the moats are gone, but quality (and security) is in a nose dive. AI built project might be the Ikea furniture. Good for the masses, but there's still a market (much smaller) for well crafted applications and services. It's hard to say what it'll look like in a couples years though. Maybe even the crafting is eventually gone. /shrug
Even if they were I disagree that 10x more ideas being produced means 10x more products in competition. You could leverage AI to execute but still have terrible ideas, leadership, product stewardship etc.
I think some clever people with a real and valuable insight will finally be able to turn that insight into a product. I also think the other 9 products will be get rich quick attempts by people with nothing to offer.
I think there's more opportunity to do something novel.
AI can't do it, and the humans with the skills to do it are rapidly disappearing.
Were you able to fairly split test?
You can use it to discuss about what you should build, identify edge cases, ask you questions to force you to take decisions, etc.
I'm not afraid of breaking stuff because it is only a small set of users. However for my own code for my professional job no way I would go that fast because I would impact millions of users.
It is insane that companies think they can replace teams wholesale while maintaining quality.
I find it… Amusing? That’s not quite the word. That programmers—a group notoriously for making wrong estimates of how long something will take to build—continuously and confidently spew a version of this.
And it’s not even estimating how long we ourselves would take to build something, now we’re onto estimating what an undetermined team of completely made up strangers could do. It’s bonkers. It has no basis in reality.
It’s amazing for him and it works on his iPad.
However when I tried it on my iPhone it was a broken mess. Completely unusable (not because of screen size differences).
I tried getting Claude to fix it but it couldn’t do it without changing too much of the look and feel, so I dug into the code and it was thousands of lines of absolute madness. I know from using this at work that there are things I could have done. Write tests to lock in things I like etc…
But so much of the speed up was about not caring about the specifics that once I started caring about making an actual product, I was not much faster maybe not any faster at all. The bottleneck in writing a game was never in banging out code.
Tech-savvy people might understand this feeling, but those who are responsible for hiring will easily proceed with another candidate that goes fast.
When push comes to shove, then, programmers will opt to have food to eat over handling technical debt generation.
This would augment actual engineer code reviews and help deal with volume.
I think from time to time, it's better to ask the AI whether the codebase could be cleaned and simplified. Much better if you use different AI than what you use to make the project.
For me, this is a bit different. Writing code has always been the bottleneck. I get most of my joy out of solving edge cases and finding optimizations. My favorite projects are when I’m given an existing codebase with the task, “When mars and venus are opposite eachother, the code gets this weird bug that we can’t reproduce.”
When a project requires me to start from scratch, it takes me a lot longer than most other people. Once I’ve thought of the architecture, I get bored with writing the implementation.
AI has made this _a lot_ easier for me.
I think the engineers who thrive wi be the ones know when to use what tool. This has been the case before AI, AI is just another tool allowing more people to thrive.
Well if you're ever in need for a complementary mind in side projects- huh, how does one connect over HackerNews?
One area --and many may not like that fact-- where it can help greatly is that the cost of adding tests also drops to near zero and that doesn't work against us (because tests are typically way more localized and aren't the maintenance burden production code is). And a some us were lazy and didn't like to write too many tests. Or take generative testing / fuzzy testing: writing the proper generators or fuzzers wasn't always that trivial. Now it could become much easier.
So we may be able to use the AI slop to help us have more correct code. Same for debugging edge cases: models can totally help (I've had case as simple as a cryptic error message which I didn't recognize: passed it + the code to a LLM and it could tell me what the error was).
But yup it's a given that, as you put it, when the marginal cost of adding complexity drops to near zero, we're opening a whole new can of worms.
TFA is AI slop but fundamentally it may not be incorrect: the gigantic amount of generated sloppy code needs to be kept in check and that's where engineering is going to kick in.
Anything else? I'll struggle and grow as a developer, thanks. And before anyone says "but there are architecture decisions etc. so you still grow"... those existed anyways. If I have to practice, I'll practice micro AND macro skills.
I can guarantee you this... the story is not absolute. Depending on who you are and what you need to work on dev time could be slower, same or faster for you. BUT what we don't know is the proportion. Is it faster for 60% of people? 70%, 80%?
This is something we don't know for sure yet. But i suspect your instinct is completely wrong and that 90% of people are overall faster... much faster. I do agree that it produces more bugs and more maintenance hurdles but it is that much faster.
The thing is LLMs can bug squash too. AND they are often much faster at it then humans. My agentic set up just reads the incoming slack messages on the issue, makes a ticket, fixes the code and creates a PR in one shot.
I'm sure it also helps translate an app written for iOS into an app written for Android.
So it definitely improves performance.
As you mentioned, scope definition and constraints play a major role but ensuring that you don't just go for the first slop result but refine it pays off. It helps to have a very clear mental model of feature constraints that doesn't fall prey to scope creep.
Since managing dependencies is one of the major maintenance burdens in some of my projects (updating them, keeping their APIs in mind, complexity due to overgeneralization), this can help quite a lot.
See also https://www.karl.berlin/simplicity-by-llm.html for some of my thoughts regarding this.
Interestingly, most jobs don't incentivize working harder or smarter, because it just leads to more work, and then burn-out.
[1] https://en.wikipedia.org/wiki/Automation#Paradox_of_automati...
That this kind of writing puts a great number of us off is not important to many who seek their fortune in this industry.
I hear the cry: "it's my own words the LLM just assisted me". Yes we have to write prompts.
I'm not shy to admit that LLMs even from 2 years ago could communicate ideas much better than me, especially for a general audience.
It’s like everything else that AI can do - looks fine at a glance, or to the inexperienced, but collapses under scrutiny. (By your own admission you’re not a great communicator… how can you tell then?)
A lot of the time, the inability to express an idea clearly hints at some problem with the underlying idea, or in one's conceptualisation of that idea. Writing is a fantastic way to grapple with those issues, and iron out better and clearer iterations of ideas (or one's understanding thereof).
An LLM, on the other hand, will happily spit out a coherent piece of writing defending any nonsense idea you throw at it.
I'll let an LLM update code documentation or even write a README for my project but I'll edit that to ensure it doesn't express opinions or say things like "This is designed to help make code easier to maintain" - because that's an expression of a rationale that the LLM just made up.
I use LLMs to proofread text I publish on my blog. I just shared my current prompt for that here: https://simonwillison.net/guides/agentic-engineering-pattern...
Like look at this paragraph:
> Junior engineers have traditionally learned by doing the simpler, more task-oriented work. Fixing small bugs. Writing straightforward features. Implementing well-defined tickets. This hands-on work built the foundational understanding that eventually allowed them to take on more complex challenges.
The first sentence was enough to convey everything you needed to know, but it kept on adding words in that AI cadence. The entire post is filled with this style of writing, which, even if it is not AI, is extremely annoying to read.
Here's another example from the blog:
> Here is something that gets lost in all the excitement about AI productivity: most software engineers became engineers because they love writing code.
> Not managing code. Not reviewing code. Not supervising systems that produce code. Writing it. The act of thinking through a problem, designing a solution, and expressing it precisely in a language that makes a machine do exactly what you intended. That is what drew most of us to this profession. It is a creative act, a form of craftsmanship, and for many engineers, the most satisfying part of their day.
can just be:
> Most software engineers became engineers because they love writing code. It is a creative act, a form of craftsmanship, and for many engineers, the most satisfying part of their day.
Clarity is something that is taught in every writing class but AI generated text always seems to have this weird cadance as follows: The sound is loud. Not a whimper, not a roar, a simple sound that is very loud. And that's why... blah blah blah.
You have to care about your readers if you're writing something seriously. Throwing just a bunch of text that all mean the same thing in your writing is one of the bigger sins you can do, and that's why most people hate reading AI writing.
I would read the hell out of Joyce’s Perl 5 documentation, but only after six or seven beers.
The part you'd like to remove ("Not managing code...") may be not required to convey the objective meaning of the sentence, but humans have emotions, too. I could have written stuff like that. To build up a bigger emotional picture.
> The act of thinking through a problem, designing a solution, and expressing it precisely in a language that makes a machine do exactly what you intended.
This sentence may not be relevant for whatever you experience to be the relevant message of the text. But it still says something the remaining paragraph does not. And also something I can relate to.
Also, as LLMs are statistical models, one has to assume that they write like this because their training data tells them to. Because humans write like this. Not when they do professional writing maybe, but when they just ramble. Not all blogs are written by professionals. I'd say most aren't. LLM training data consists mostly of humans rambling.
I also sometimes write long comments on the internet. And while I have no example to check, I feel like I do write such sentences, expanding on details to express more emotional context. Because I'm not a robot and I like writing a lot. I think it's a perfectly human thing to do. I find it sad that "writing more than absolutely needed" is now regarded as a sign of AI writing.
Reading AI code is very pleasant. It's well annotated and consistent - how I like to read code (although not how I write code LOL). Reading language/opinions is not meant to be this way. It becomes repetitive, boring, and feels super derivative. Why would you turn the main way we communicate with each other into a soulless, tedious, chore?
I think with coding it's because I care* about what the robot is doing. But, with communication, I care about what the person is thinking in their mind, not through the interpretation of the robot. Even if the person's mind isn't as strong. At least then I can size the person up - which is the other reason understanding each other is important and ruined when you put a robot in between.
We should probably normalize publishing things in our native languages, and expecting the audience to run it through a translator. (I have been toying with the idea of writing everything in Esperanto (not my native language, but a favorite) and just posting links to auto-translated English versions where the translation is good enough).
EDIT: as someone with friends and family from Eastern Europe, I can tell you that the prevailing attitude is: "everything is bullshit anyway" (which, to be fair, has a lot of truth to it), and so it is no surprise that people would enthusiastically embrace a pocket-sized bullshit factory, hook it up to a fire-hose, and start spraying. We saw it with spam, and we see it now with slop. It won't stop unless the system stops rewarding it.
I don’t think there will be a point in coming to this site if it’s just going to be slop on the front page all the time.
Maybe mods should consider a tag or flag for AI generated content submissions?
I hate it. I couldn't read much more after that.
Looks like something AI would say. Regardless of how it really was written
Admittedly it was so long and basic, I stopped halfway.
> That is not an upgrade. That is a career identity crisis.
This is not X. It is Y.
> The trap is ...
> This gap matters ...
> This is not empowerment ...
> This is not a minor adjustment...
Your typical AI slop rhetorical phrasing.
Phrases like: "identity crisis", "burnout machine", "supervision paradox", "acceleration trap", "workload creep"
These sound analytical but are lightly defined. They function as named concepts without rigorous definition or empirical grounding.
There might be some good arguments in the article, but AI slop remains AI slop.
> AI is an in-context learner, not a standards enforcer.
> The AI is not judging your code. It is learning from it.
> Speed without structure is not speed. It is borrowed time.
> This is not about premature optimization or over-engineering. It is about giving the AI the patterns it needs to work effectively on your behalf.
> This is not a theoretical distinction. It is the single most important practical reality of working with AI coding tools in 2026.
Its not this, its that.
> But here is the part nobody wants to hear: the reverse is equally true.
> The result was transformative.
> Here is why.
If you want I can provide N=3 with the same AI pattern and phrases again.
But I have no issue with your argumentation whatsoever, it is just that I think there is more than sufficient evidence, and you think there is not.
What I never enjoyed was looking up the cumbersome details of a framework, a programming language or an API. It's really BORING to figure out that tool X calls paging params page and pageSize while Y offset and limit. Many other examples can be added. For me, I feel at home in so many new programming languages and frameworks that I can really ship ideas. AI really helps with all the boring stuff.
AI makes using them a breeze.
I can actually build nice UIs as a traditional ML engineer (no more streamlit crap). People are using them and genuinely impressed by them
I can fly through Rust and C++ code, which used to take ages of debugging.
The main thing that is clear to me is that most of the ecosystem will likely converge toward Rust or C++ soon. Languages like Python or Ruby or even Go are just too slow and messy, why would you use them at all if you can write in Rust just as fast? I expect those languages to die off in the next several years
The scenario I'm somewhat worried about is that instead of 1 PM, 1 designer and 5 developers, there will be 1 PM, 1 designer and 1 developer. Even if tech employment stays stable or even slightly increases due to Jevons paradox, the share of software developers in tech employment will shrink.
Maybe this is not entirely true yet, but it most likely will be in the near future.
Can they really? Engineering is about keeping the whole picture in mind so that you know which lever to push and which to not push for a certain goal. Trying until you're lucky can get you to that goal, but it's costly and not sustainable. So you need someone that can work out a model for experimentation in a less costly manner.
Judgment in this case is about deciding which path to direct the project, tradeoffs is being aware that there are other paths that are better in some aspects. And responsibility is acknowledging that a bad decision will bear a personal cost.
Everyone does the above in their own domain. But I don't think I've ever see a manager wanting to do it in the engineering domain. It's more about pushing the engineer to accept the responsibility, but denying them the power of judgment.
Also, check out the dude's linkedin: https://www.linkedin.com/in/ivanturkovic/
... most software engineers became engineers because they love writing code. Not managing code. Not reviewing code. Not supervising systems that produce code. Writing it. The act of thinking through a problem, designing a solution, and expressing it precisely in a language that makes a machine do exactly what you intended. That is what drew most of us to this profession. It is a creative act, a form of craftsmanship, and for many engineers, the most satisfying part of their day.
Actually surprised none of the other comments have picked up on this, as I don't think it's especially about AI. But the periods of my career when I've been actually writing code and solving complicated technical problems have been the most rewarding times in my life, and I'd frequently work on stuff outside work time just because I enjoyed it so much. But the other times when I was just maintaining other people's code, or working on really simple problems with cookie-cutter solutions, I get so demotivated that it's hard to even get started each day. 100%, I do this job for the challenges, not to just spend my days babysitting a fancy code generation tool.
Another little thing that resonated was a tweet that said "some will use it to learn everything and some so that they don't have to learn anything ". Of course it's not really a hard truth. It's questionable how much you can learn without really getting your hands dirty. But I do think people looking at it as a tool that helps then and/or makes them better will profit more than people looking to cut corners.
THE MARKET WILL FILL THAT VOID
IT DOES NOT MAKE IT TRUE
it's all so fucking tiresome
A surgeon (no coding experience) used Claude to write a web app to track certain things about procedures he had done. He deployed the app on a web hosting provided (PHP LAMP stack). He wanted to share it with other doctors, but wasn't sure if it was 'secure' or not. He asked me to read the code and visit the site and provide my opinion.
The code was pretty reasonable. The DB schema was good. And it worked as expected. However, he routinely zipped up the entire project and placed the zip files in the web root and he had no index file. So anyone who navigated to the website saw the backups named Jan-2026.backup, etc. and could download them.
The backups contained the entire DB, all the project secrets, DB connection strings, API credentials, AWS keys, etc.
He had no idea what an 'index' file was and why that was important. Last I heard he was going to ask Claude how to secure it.
An SWE who bases their entire identity and career around only writing code is not an engineer - they are a code monkey.
The entire point of hiring a Software ENGINEER is to help translate business requirements into technical requirements, and then implement the technical requirements into a tangible feature or product.
The only reason companies buy software is because the alternative means building in-house, and for most industries software is a cost-center not a revenue generator.
I don't pay (US specific) 200K-400K TCs for code monkeys, I pay that TC for Engineers.
And this does a disservice to the large portion of SWEs and former SWEs (like me) who have been in the industry because we are customer-outcome driven (how do we use code to solve a tangible customer need), not write pretty code.
Look, AI/ML and especially LLMs are powerful, but there does remain a degree of instability and non-determinism which will require human intervention to remediate.
That said, there is a lot of dev work in companies that is a cost-center, and those are the portions that will start getting vibe coded and deployed in product with little-to-no oversight (eg. a support portal for SMBs at an enterprise), but the equivalent feature would have already been an afterthought even without LLMs and probably given to a couple SWEs we'd be fine re-orging in a quarter anyhow.
> but there does remain a degree of instability and non-determinism which will require human intervention to remediate.
I agree.
I mean, it depends on the feature/product and how critical it is to the health of the business.
Like I mentioned in my edited comment, there is a lot of dev work in companies that is a cost-center, and those are the portions that will start getting vibe coded and deployed in product with little-to-no oversight (eg. a support portal for SMBs at an enterprise), but the equivalent feature would have already been an afterthought even without LLMs and probably given to a couple SWEs we'd be fine re-orging in a quarter anyhow because we cannot justify spending $500K-750K a year (the backend cost of 3 FT SWEs or Contractors for a company) on a customer form which nets $0 in revenue and is not directly tied with pipeline generation.
Leaders thinking they will basically prompt out new revenue generating features with no human engineers to "figure it out". Not cost centers, low hanging fruit, etc. No these are not giant corps like Google or whatever and likely run by morons, but it was easier when they did not think they were "empowered". There is no opportunity for engineers to "think in higher abstractions" or whatever in these cases.
These, surely, are the skills they always needed? Anyone who didn't have these skills was little more than a human chatgpt already, receiving prompts and simply presenting the results to someone for evaluation.
In the past, I would give them an assignment and they would take a few days to return with the implementation. I was able to see them struggling, they would learn, they would communicate and get frustrated by their own solution, then iterate.
Today, there are two kinds: 1) the ones who take a marginally smaller amount of time because they’re busy learning, testing and self reviewing, and 2) the ones who watch Twitch or Youtube videos while Claude does the job and come to me after two hours with “done, what’s next” while someone has to comb through the mess.
Leadership might see #2 and think they’re better, faster. But they are just a fucking boat anchor that drags down the whole team while providing nothing more than a shitty interface to an LLM in return.
xyzsparetimexyz•1h ago