Stop generating, start thinking
localghost.dev
localghost.dev
Once you understand the sole winner in this hype is the one who'll be brutally scraping every bit of data, whether it's real-time or static and then refining it to give it back to you without your involvement in the process (a.k.a, learning) you'll come to understand that the current AI by nature is hugely unfavorable to mental progression...
Shouldn't we blame copyright laws for that?
In some places there's an exception to copyright law for format shifting if you destroy the original. If you don't destroy the original, then you made a copy and that's not allowed.
I don't agree at all. The "commodity" argument is actually a discussion on economic viability. This is the central discussion, and what will determine if tomorrow we will still have higher-quality and up-to-date LLMs available to us.
You need to understand that nowadays there is a clear race to the bottom in LLM-related services, at a time when the vast majority is not economically viable. The whole AI industry is unsustainable at this point. Thus it's rather obvious that making a business case and generating revenue is a central point of discussion.
1. Microsoft's announcement of cutting their copilot products sales targets[0]
2. Moltbook's security issues[1] after being "vibe coded" into life
Leaving the undeniable conclusion to be - the vast majority (seriously) distrusts AI much more than we're led to believe, and with good reason.
Thinking (as a SWE) is still very much the most important skill in SWE, and relying on AI has limitations.
For me, AI is a great tool for helping me to discover ideas I had not previously thought of, and it's helpful for boilerplate, but it still requires me to understand what's being suggested, and, even, push back with my ideas.
[0] https://arstechnica.com/ai/2025/12/microsoft-slashes-ai-sale...
[1] https://www.reuters.com/legal/litigation/moltbook-social-med...
I'd go further and say the thinking is humanity's fur and claws and teeth. It's our strong muscles. It's the only thing that has kept us alive in a natural world that would have us extinct long, long ago.
But now we're building machine with the very purpose of thinking, or at least of producing the results of thinking. And we use it. Boy, do we use it. We use it to think of birthday presents (it's the thought that counts) and greeting card messages. We use it for education coursework (against the rules, but still). We use it, as programmers, to come up with solutions and to find bugs.
If AI (of any stripe, LLM or some later invention) represents an existential threat, it is not because it will rise up and destroy us. Its threat lies solely in the fact that it is in our nature to take the path of least resistance. AI is the ultimate such path, and it does weaken our minds.
My challenge to anyone who thinks it's harmless: use it for a while. Figure out what it's good at and lean on it. Then, after some months, or years, drop it and try working on your own like in the before times. I would bet that one will discover that significant amounts of fluency will be lost.
Microsoft might just be having trouble selling copilot because Claude or whatever is better, right?
Moltbook is insecure, but the first couple iterations of any non-trivial web service ends up having some crazy security hole. Also Moltbook seems to be some sort of… intentional statement of recklessness.
I think we’ll only know in retrospect, if there’s a great die-off of the companies that don’t adopt these tools.
I'm not saying this is perfect or unproblematic. Far from it. But I do think that shops that invest in this way of working are going to vastly outproduce ones that don't.
LLMs are the first technology where everyone literally has a different experience. There are so many degrees of freedom in how you prompt. I actually believe that people's expectations and biases tend to correlate with the outcomes they experience. People who approach it with optimism will be more likely to problem-solve the speed bumps that pop up. And the speed bumps are often things that can mostly be addressed systemically, with tooling and configuration.
I say this as someone who does use the tools, they're fine. I have yet to ever have an "it's perfect, no notes" result. If the bar is code that technically works along the happy path then fine, but that's the floor of what I'm willing to put forth or accept in a PR.
There is absolutely reason for concern, but it's not inevitable.
For the foreseeable future, I don't think we can simply Ralph Wiggum-loop real business problems. A lot of human oversight and tuning is required.
Also, I haven't seen anything to suggest that AI is good at strategic business decisionmaking.
I do think it dramatically changes the job of a software developer, though. We will be more like developers of software assembly lines and strategists.
Every company I have ever worked for has had a deep backlog of tasks and ideas we realistically were never going to get to. These tools put a lot of those tasks in play.
> I have yet to ever have an "it's perfect, no notes" result.
It frequently gets close for me, but usually some follow-up is needed. The ones that are closest to pure one-shot are bug fixes where replication can be captured in a regression test.
Some of that backlog was never meant to be implemented. “Put it in the backlog” is a common way to deflect conflict over technical design and the backlog often becomes a graveyard of ideas. If I unleashed a brainless agent on our backlog the system would become a Frankenstein of incompatible design choices.
An important part of management is to figure out what actually brings value instead of just letting teams build whatever they want.
I'm experiencing the early stages of a reality where much more of this stuff is possible to build. I say early stages, because there's still plenty of friction between what we have now and a true productivity multiplier. But most of that friction is solvable without speculative improvements, like the models themselves getting better.
If I worked someplace where there was nothing of value on the backlog, then I would be worried about my job.
I don't know about that. This PR stunt is a greenfield project that no one really knows what volume of work went behind it, and targeted a problem (bootstrapping a C compiler) that is actually quite small and relatively trivial to accomplish.
Go ahead and google for small C compilers. They are a dime a dozen, and some don't venture beyond a couple thousand lines of code.
Check out this past discussion.
I do agree that some folks are in for rude awakening, because markets (labor and otherwise) will reveal winning strategies. I'm far from a free market ideologist, but this is a place where the logic seems to apply.
But it's also true that it simply is better than the OP is giving it credit for.
Depressingly. Because I like writing code.
You never see job adverts requiring VIM or IntelliJ experience, I expect it will be the same for Claude Code or Cursor.
> We are AI-native and expect you to use tools like Cursor and Claude to ship significantly faster.
> Stack: Python 3.12 (Typed), FastAPI, MongoDB/Beanie, React/TS, Gemini/Claude, Claude Code,
> Who you are: Strong software engineering background with TypeScript in production. Hands-on with AI coding tools (Cursor, Claude Code, Aider, Copilot)
You can't simply throw the generated code over the wall to the reviewer. You have to put in the work to understand what's being proposed and why.
Lastly, an extremely important part of this is the improvement cycle. The tools will absolutely do suboptimal things sometimes, usually pretty similar to a human who isn't an expert in the codebase. Many people just accept what comes out. It's very important to identify the gaps between the first draft, what was submitted for code review, and the mergeable final product and use that information to improve the prompt architecture and automation.
What I see is a tool that takes a lot of investment to pay off, but where the problems for operationalizing it are very tractable, and the opportunity is immense.
I'm worried about many other aspects, but not the basic utility.
If you are really truly reviewing every single line in a way that it is the same as if you hand wrote it… just hand write it. There’s no way you’re actually saving time if this is the case. I don’t buy that people are looking at it as deeply as they claim to be.
I think this is only true for people who are already experts in the codebase. If you know it inside-out, sure, you can simply handwrite it. But if not, the code writing is a small portion of the work.
I used to describe it as this task will take 2 days of code archaeology, but result in a +20/-20 change. Or much longer, if you are brand new to the codebase. This is where the AI systems excel, in my experience.
If the output is +20/-20, then there's a pretty good chance it nailed the existing patterns. If it wrote a bunch more code, then it probably deserves deeper scrutiny.
In my experience, the models are getting better and better at doing the right thing. But maybe this is also because I'm working in a codebase where there are many example patterns in the codebase to slot into and the entire team is investing heavily in the agent instructions and skills, and the tooling.
Yes, the code archaeology is the time consuming part. I could use an LLM to do that for me in my co-workers generated code, but I don’t want to because when I have worked with AI I have found it to typically create overly-complex and uncreative solutions. I think there may be some confirmation bias with LLM coders where they look at the code and think it’s pretty good, so they think it’s basically the same way they would have written it themselves. But you miss a lot of experiences compared to when you’re actually in the code trenches reading, designing, and tinkering with code on your own. Like moving around functions to different modules and it suddenly hits you that there’s actually a conceptual shift you can make that allows you to code it all much simpler, or recalling that shareholder feedback from last week that — if worked with —could allow you a solution pathway that wasn’t viable with the current API design. I have also found that LLMs make assumptions about what parts of the code base can and can’t be changed, and they’re often inaccurate.
Completely agree. Working with this tooling is a fundamentally different practice.
I'm not trying to suggest that agentic coding is superior in every way. I simply believe that in my own experience, the current gains exceed the drawbacks by a large margin for many applications, and that significantly higher gains are within close reach (e.g. weeks).
I spent years in management, and it's not dissimilar to that transition. In my first role as a manager, I found it very difficult to divest myself of the need to have fine-grained knowledge of and control over the team's code. That doesn't scale. I had to learn to set people up for success and manage from a place of uncertainty. I had to learn to think like a risk manager instead of an artisan.
I'll also say that when it comes to solution design, I have found it very helpful to ask the agent to give me options when it comes to solutions that look suboptimal. Often times, I can still find great refactor opportunities, and I can have agent draw up plans for those improvements and delegate them to parallel sessions, where the focus can be safely executing a feature-neutral refactor.
Separately from that, I would note that the business doesn't always need us to be making conceptual shifts. Great business value can be delivered with suboptimal architecture.
It is difficult to swallow, but I think that those of us whose market value is based on our ability to develop systems by manipulating code and getting feedback from the running product will find that businesses believe that machines can do this work more than good enough and at vastly higher scale.
For the foreseeable future, there will be places where hands-on coding is superior, but I see that becoming more the exception than the norm, especially in product engineering.
I am going to have to agree to disagree overall though, because the second there is something the AI can’t do the maintenance time for a human to learn the context and solve the problem skyrockets (in practice, for me) in a way I find unacceptable. And I may be wrong, but I don’t see LLMs being able to improve to close that gap soon because that would require a fundamental shift away from what the LLMs are under the hood.
As I said up top:
> LLMs are the first technology where everyone literally has a different experience.
I totally believe you when you say that you have not found these tools to be net useful. I suspect our different perceptions probably come from a whole bunch of things that are hard to transmit over a discussion like this. And maybe factors we're not even aware of -- I am benefiting from a lot of investment my company has made into all of the harness around this.
But I do pretty strongly believe that I'm not hallucinating how well it's all working in my specific context.
Can't relate to GP's experience of one-shotting. I need to try a couple of times and really hone in on the right plan and constraints.
But I am getting so much done. My todo list used to grow every year. Now it shrinks every month.
And this is not mindless "vibe coding". I insist on what I deploy being quality, and I use every tool I can that can help me achieve that (languages with strong types, TDD with tests that specify system behaviour, E2E tests where possible).
IMO it’s probably that. The difference between where this was a a year ago and now is night and day, and not using frontier models is roughly like stepping back in time 6-12 months.
- like the sister comment says, use the best model available. For me that has been opus but YMMV. Some of my colleagues prefer the OAI models.
- iterate on the plan until it looks solid. This is where you should invest your time.
- Watch the model closely and make sure it writes tests first, checks that they fail, and only then proceeds to implementation
- the model should add pieces one by one, ensuring each step works before proceeding. Commit each step so you can easily retry if you need to. Each addition will involve a new plan that you go back and forth on until you're happy with it. The planning usually gets easier as the project moves along.
- this is sometimes controversial, but use the best language you can target. That can be Rust, Haskell, Erlang depending on the context. Strong types will make a big difference. They catch silly mistakes models are liable to make.
Cursor is great for trying out the different models. If opus is what you like, I have found Claude code to be better value, and personally I prefer the CLI to the vscode UI cursor builds on. It's not a panacea though. The CLI has its own issues like occasionally slowing to a crawl. It still gets the work done.
So do I, but I also quite like Cursor's harness/approach to things.
Which is why their `agent` CLI is so handy! You can use cursor in any IDE/system now, exactly like claude code/codex cli
Thank you for sharing that!
I also always check that it explicitly states my rules (some from the global rules, some from the session up until that moment) so they're followed at implementation time.
In my experience opus is great at understanding what you want and putting it in a plan, and it's also great at sticking to the plan. So just read through the entire thing and make sure it's a plan that you feel confident about.
There will be some trial and error before you notice the kind of things the model gets wrong, and that will guide what you look for in the plan that it spits out.
I spend a lot of time on plans, but unfortunately the gotchas are in the weeds, especially when it comes to complex systems. I don't trust these models with even marginally complex, non-standard architectures (my projects center around statecharts right now, and the semantics around those can get hairy).
I git commit after each feature/bugfix, so we're on the same page here. If a feature is too big, or is made up of more than one "big" change, I chunk up the work and commit in small batches until the feature is complete.
I'm running golang for my projects right now. I can try a more strongly typed language, but that means learning a whole new language and its gotchas and architectural constraints.
Right now I use claude-code-router and Claude Code on top of openrouter, so swapping models is trivial. I use mostly Grok-4.1 Fast or Kimi 2.5. Both of these choke less than Anthropic's own Sonnet (which is still more expensive than the two alternatives).
Some bugs really can be one-shotted, but that's with the benefit of a lot of scaffolding our company has built and the prompting process. It's not as simple as Claude Code being able to do this out of the box.
If all you're doing is reviewing behaviour and tests then yes almost 100% of the time if you're able to document the problem exact enough codex 5.3 will get it right.
I had codex 5.3 write flawless svelte 5 code only because I had already written valid svelte 5 code around my code.
The minute I started a new project and asked it to use svelte 5 and let it loose it not only started writing a weird mixture of svelte 3/4 + svelte 5 code but also straight up ignored tailwind and started writing it's own CSS.
I asked it multiple times to update the syntax to svelte 5 but it couldn't figure it out. So I gave up and just accepted it, that's what I think is going to happen more frequently. If the code doesn't matter anymore and it's just the process of evaluating inputs and outputs then whatever.
However if I need to implement a specific design I will 100% end up spending more time generating than writing it myself.
I can totally imagine that in greenfield, the LLM is going to explore huge search spaces. I can see that when observing the reasoning of these same models in non-coding contexts.
Which is still okay, only until I have access to good and cheap LLMs.
Then it will have the signal that is in your head, and you’ll never again need to tell it to use Svelte 5.
As you see more “wrong” usage, have it add those to the checker, and the checker will keep getting better over time.
> Code you did not write is code you do not understand > You cannot maintain code you do not understand
We need no AI for this one: If I could only maintain code I wrote, I'd have to work alone. Whether I am reviewing code written by AI or by a human is irrelevant here. The rest of the comments on the human we know having more trust is in itself a smell on your development process: This is how we get cliques, and people considering repos hostile, because there's clear differences in behavior for well known contributors, who are just as capable of writing something bad as anyone else. If there's anything I have seen in code review processes, regardless of where I've worked for the last couple of decades, is that visual inspections rarely get us anywhere, and no organization is willing to dedicate the time to double check anything. Bugs that happily go through inspection come in too even when the organization commits to extreme programming: Full time TDD and full pairing.
There is a question on how fast we can merge code in a project safely, regardless of the identity of the author of the PRs. A systematic approach to credible, reliable development. But the answer here has very little to do with what the article's author is saying, and has nothing to do with whether a contribution was made by an AI, a human, or a golden retriever with access to a keyboard and a lot of hope.
I don't think that "Code you did not write is code you do not understand" implies that the only way to understand code is to write it. I can read code, run it, debug it and figure out how it works.
It's true that all of that is possible with AI generated code. But the thing is, is it worth for me spending time understanding that PR, when I can make the change or launch my own agent to prompt it myself? At least with my own prompt I know exactly what I want it to be.
The real effort of coding is understanding it, reviewing it, improving it, making it work, and work well and durably. All of this requires thinking.
It says if you didn't write the code and you read it then you don't understand it.
It says if you didn't write the code and you debugged it then you don't understand it.
It's wrong, obviously.
I think you missed the whole point. This is not about you understanding a particular change. This is about the person behind the code change not understanding the software they are tasked to maintain. It's a kin to the discussion about the fundamental differences between script kiddies vs hackers.
With LLMs and coding agents, there is a clear pressure to turn developers into prompt kiddies: someone who is able to deliver results when the problem is bounded, but is fundamentally unable to understand what he did or the whole system being used.
This is not about sudden onsets of incompetence. This is about a radical change in workflows that no longer favor or allow research to familiarize with projects. You no longer need to pick through a directory tree to know where things are, or nagivate through code to check where a function is called or what component is related to which component. Having to manually open a file to read or write to it represents a learning moment that allows you to recall and understand how and why things are done. With LLMs you don't even understand what is there.
Thus developers who lean heavily on LLMs don't get to learn what's happening. Everyone can treat the project as a black box, and focus on observable changes to the project's behavior.
This is a good thing. I don’t need to focus on oil refineries when I fill my car with gas. I don’t know how to run a refinery, and don’t need to know.
No, it isn't. If you do not know what the project does, you are unable to even review the changes proposed by a coding agent.
Consequently, we already have a long track record of LLMs introducing vulnerabilities.
LLMs are great at speeding up small tasks but the trade-off is that developers become progressively clueless.
This sums up my interactions with LLMs
This isn't GPT-3 anymore. We have added fine tuning and other post training techniques to make this unnecessary.
...
’ve been using Copilot - and more recently Claude - as a sort of “spicy autocomplete” and occasional debugging assistant for some time, but any time I try to get it to do anything remotely clever, it completely shits the bed. Don’t get me wrong, I know that a large part of this is me holding it wrong, but I find it hard to justify the value of investing so much of my time perfecting the art of asking a machine to write what I could do perfectly well in less time than it takes to hone the prompt.
You’ve got to give it enough context - but not too much or it gets overloaded. You’re supposed to craft lengthy prompts that massage the AI assistant’s apparently fragile ego by telling it “you are an expert in distributed systems” as if it were an insecure, mediocre software developer.
Or I could just write the damn code in less time than all of this takes to get working."
Well there's your problem. Nobody does roll-based prompts anymore, and the entire point of coding agents is that they search your code base, do internet searches, and do web fetches, as well as launch sub agents and use todo lists, to fill and adjust their context exactly as needed themselves, without you having to do it manually.
It's funny reading people planatively saying, "I just don't get how people could possibly be getting used out of these things. I don't understand it." And then they immediately reveal that it's not the baffling mystery or existential question there pretending it is for the purpose of this essay — the reason they don't understand it is that they literally don't understand the tech itself lol
Just last week, I prompted (not asked, it is not sentient) Claude to generate (not tell me or find out or any other anthropomorphization) whether I need to call Dispose on objects passed to me from 2 different libraries for industrial cameras. Being industrial, most people using them typically don't post their code publicly, which means the models have poor statistical coverage around these topics.
The LLM generated a response which triggered the tooling around it to perform dozens of internet searches and based on my initial prompt, the search results and lots of intermediate tokens ("thinking"), generated a reply which said that yes, I need to call Dispose in both cases.
It was phrased authoritatively and confidently.
So I tried it, one library segfaulted, the other returned an exception on a later call. I performed my own internet search (a single one) and immediately found documentation from one of the libraries clearly stating I don't need to call Dispose. The other library being much more poorly documented didn't mention this explicitly but had examples which didn't call Dispose.
I am sure if I used LLMs "properly" "agentically", then they would have triggered the tooling around them to build and execute the code, gotten the same results as me much faster, then equally authoritatively and confidently stated that I don't need to call Dispose.
This is not thinking. It's a form of automation but not thinking and not intelligence.
“Brute force” is mostly what makes it all work, and what is most disappointing to me currently. Including the brute force necessary to train an LLM, the vast quantity of text necessary to approach almost human quality, the massive scale of data centers necessary to deploy these models, etc.
I am hoping this is a transitional period, where LLMs could be used to create better models that are more finesse and less brute force.
Because right now everything in the west is structured around rich people owning things they have not built while people who did the actual work with their hands and their minds are left in the dust.
For a brief period of time (a couple decades), tech was a path for anyone from any background to get at least enough to not struggle. Not become truly rich as for that you need to own real estate or companies but having all your reasonable material needs taken care of and being able to save up for retirement (or in countries without free education, to pay for kids' college).
And that might be coming to an end, with people who benefited from this opportunity cheering it on.
I don't think it's really fair to talk about "people who benefited from this opportunity cheering it on" in the comments on one of my posts. I'm an agentic AI coding enthusiast because I find it fascinating, it allows me to focus more on what I like most about programming (software architecture, systems thinking, etc), and the decreased cognitive load and increased productivity allows me to continue to do interesting projects in the time and energy I have left after my jobs and disability take.
People either focus on the models not meeting their standards (which is very subject matter dependent) or being exploitative. The thing is, both can be true at the same time and the models can in theory get good enough. Just like the water usage argument - I am not saying it's right or wrong, I am saying it can change if somebody comes up with more energy efficient models. We should focus on the fundamentals.
And those are that LLMs are build on the work of millions (hundreds of millions?) of people without their consent and that their goal is to reduce or completely eliminate the economic (and therefore political) power of those people.
I understand why you do it, I use stolen code too because ultimately nobody is likely to be punished and I'd just be disadvantaging myself for no reason. But we need to think about the endgame - not ours - theirs - because theirs dictates ours.
And it’s nothing to sneeze at because it allows me to stay in the terminal rather than go back and forth between the terminal and Google.
I have each program i use regularly bound to a keyboard shortcut and the search bar is ctrl+k in most browsers. If we're talking purely about the time saving of not having to open/focus another program and its search bar, than those costs can be negligible.
AI "reasoning" in it's current state is a hack meant to overcome the problem of contextual learning[0]. It somewhat works given enough time and good automatic tooling. When this problem is solved, I think we will see a significant boost in productivity from these tools. In it's current state, I'm not convinced that they are worth my time (and money).
Yes, usually my agents directly read the source code of libraries that don't have lots of good documentation or information in their training data, and/or create test programs as minimal viable examples and compile and run them themselves to see what happens, it's quite useful.
But you're right overall; LLMs placed inside agents are essentially providing a sort of highly steerable plausible prior for a genetic algorithm to automatically solve problems and do automation tasks. It's not as brute force as a classic genetic algorithm, but it can't always one-shot things, there is sometimes an element of guess-and-check. But IME at least that element is usually not more iterations than it takes me to figure something out (2-3), on average, although sometimes it needs more iterations than I would've on simple problems, and other times much less on harder ones, or vice versa.
That only works if the source is available.
And since software licenses are meaningless now, we might see more and more closed source software.
> I have a source file of a few hundred lines implementing an algorithm that no LLM I've tried (and I've tried them all) is able to replicate, or even suggest, when prompted with the problem. Even with many follow up prompts and hints.
People making this kind of claim will never post the question and prompts they tried. Because if they did, everyone will know it's just they don't know how to prompt.
In fact, most LLMs would do a better job than most commenters on HN.
The POV of the author I understand quite well because it was mine. Its really only in the last 6 months or so that my perspective has changed. The author still sounds like they are in the "black box that I toss wishes into and is dumb as fuck" phase. It also sounds like they are resistant to learning how to make the most of it which is a shame. If you take the time to learn the techniques that make this stuff tick you'll be amazed at what it can do. I mean maybe I am a total idiot and this stuff will get good enough that I am no longer necessary. Right now though? I see it as an augmentation. An amplification of me and what I am capable of.
One of the things I’m struggling to come to terms with is the “don’t commit code that you don’t understand” thing.
This makes sense, however it’s a thorn in my side that if I’m honest I’ve not been able to come up with a compelling answer to yet.
I agree with the sentiment. But in practice it only works for folks who have become domain experts.
My pain point is this - it’s fine to only review if you have put in the work by writing lots of code over their careers.
But, what’s the game plan in 10 years if we’re all reviewing code?
I know you learn from reviewing, but there’s no doubt that humans learn from writing code, failing, and rewriting.
So…this leaves me in a weird place. Do we move passively into a future where we don’t truely deeply understand the code anymore because we don’t write it? Where we leave it up to the AI to handle the lower level details and we implicitly trust it so we can focus on delivering value further up the chain? What happens to developers in 10-20 years?
I don’t know but I’m not so convinced that we’re going to be able to review AI code so well when we’ve lost the skill to write it ourselves.
What is representative democracy if not that?
One reason - the main reason? - we live in groups with different roles and skills is to rely on others to think for us.
An overwhelmingly large number of people keep saying that socialism is bad, individualism is where it's at. I trust they're right.
ChatGPT has been out for 3 years (Nov 2022)
Claude almost 3 years (March 2023)
Gemini 1 and a bit years (2024)
There hasn't been an avalanche of new software online - if anything things have slowed
1: Garbage filling a place.
Number of commits don’t tell anything about the value and quality of those commits. Please don’t measure yourself with this poor metric.
— Jaana Dogan ヤナ ドガン (@rakyll) February 26, 2019
Number of IOS apps isn't much of a metric either to be honest, but sure we can pretend that that's a result of the AI revolution...
This seems like a really disingenuous statement. If claude can write an entire C compiler that is able to compile the linux kernel, I think it has already surpassed an unimaginable threshold for "cleverness"
Turns out the dark mode in Brave (mobile) makes the garden theme font almost the same color as the background. I tried it on default Chrome and it looked better.
The 2nd, 3rd, and 4th themes are easy to read with Brave but the others are not.
I like to say that you don't need computer science to write software, until you do. The thing is that a lot of software in the organisations I've worked in, doesn't actually need computer science. I've seen horrible javascript code on the back-end live a full lifecycle of 5+ years without needing much maintainence, if any, and be fine. It could've probably have been more efficient, but compute is so cheap that it never really mattered. Of course I've also seen inefficient software or errors cost us a lot of money when our solar plants didn't output what they were supposed to. I'd let AI's write one of those things any day.
Hell I did recently. We had an old javascript service which was doing something with the hubspot API. I say something because I didn't ever really find out what it was. Basically hubspot sunset the v1 of their API, and before the issue arrived at my table my colleagues had figured out that was the issue. I didn't really have the time to fix this, so when I saw how much of a mess the javascript code was and realized it would take me a few hours to figure out what it even did... well... I told my AI agent running on our company framework to fix it. It did so in 5-10 minutes with a single correction needed. It improved the javascript quite a bit while doing it, typing everything. I barely even got out of my flow to make it happen. So far it's run without any issues for a month. I was frankly completely unnecessary in this process. The only reason it was me who fired up the AI is because the people who sent me the task haven't yet adopted AI agents.
That being said... AI's are a major security risk that needs to be handled accordingly.
The point of programming is to automate reasoning. Don't become a reactionary just cause your skills got got. The market is never wrong, even if there is a correction in 20 years we'll see nvidia with 10T market cap. Like every other correction (at&t, NTT)
Why don't do it yourself, like you want to do it, when you could just fallback to mediocrity and instead do like everybody else does?
Why think when you can be told what to do?
Why have intercourse with your wife when instead you can let someone else do? This is the typical llm user mentality
It's a bit weird to be against the use of the phrase "artificial intelligence" and not "machine learning". Is it possible to learn without intelligence? Methinks the author is a bit triggered by the term "intelligence" at a base primal level ("machines can't think!").
> “Generative AI” is just a very good Markov chain that people expect far too much from.
The author of this post doesn't know the basics of how LLMs work. The whole reason LLMs work so well is that they are extremely stateful and not memoryless, the key property of Markov processes.