You're not wrong but there's entire jams on YouTube from people with real gear and no DAW that produce uninteresting synth based music. Yet The Prodigy made good albums entirely with Reason.
I'm not sure what point you're making. I never claimed any set of tooling is necessary of sufficient to produce good music. I merely pointed out that, as it became more accessible to produce music, the overall quality of the output decreased.
I think the volume of good music has actually increased, but maybe less than the bad music.
You know, sometimes I feel that all this discourse about AI for coding reflects the difference between software engineers and data scientists / machine learning engineers. Both often work with unclear requirements, and sometimes may face floating bugs which are hard to fix, but in most cases, SWE create software that is expected to always behave in a certain way. It is reproducible, can pass tests, and the tooling is…
I’m currently getting my masters in AI (lots of ML) and as a SWE, it’s definitely a new muscle I’m growing. At the same time, I can think about MLE in isolation and how it fits within the larger discipline of SWE. How I can build robust pipelines, integrate models into applications, deploy models within larger clusters, etc. I think there are many individuals which are pure MLE and lack the SWE perspective. Most critically, lots of ML people in my program aren’t computer people. They are math people or scientists first. They can grok the ML but grokking SWE without computer affinity is difficult. I see true full-stack being an understanding of low-level systems, back-front architecture, deployment, and now MLE. Just need to find someone who will compensate me for bringing all that to the table. Most postings are still either for SWE or PhD in MLE. Give me money!! I know it all
You know, sometimes I feel that all this discourse about AI for coding reflects the difference between software engineers and data scientists / machine learning engineers. Both often work with unclear requirements, and sometimes may face floating bugs which are hard to fix, but in most cases, SWE create software that is expected to always behave in a certain way. It is reproducible, can pass tests, and the tooling is…
You're talking about deterministic behavior vs. probabilistic behavior and yes some discourse lines up with what you describe.
I don't think it's the case with this article. It focuses on the meta-concerns of people doing software engineering and how AI fits into that. I think he hits it on the head when he talks about Program Entropy.
A huge part of building a software product is managing entropy. Specifically, how you can add more code and more people while maintaining a reasonable forward velocity. More specifically, you have to maintain a system so you make it so all of those people understand how all the pieces fit together and how to add more of those pieces. Yes, I can see AI one day making this easier but right now, it oftentimes makes entropy worse.
Honestly there are good reasons to resist AI even as a senior. If prompting an LLM cannot be easily integrated into your existing workflow or demands a huge change in tooling, it's just distracting or crippling. I don't think we need to have a long discussion as to why distractions and context switches are counterproductive.
You can say that, but when the principle down the hall from you who's got a highly tuned agentic AI workflow is outproducing half your team by himself while leading engineering direction on multiple projects, it's hard to justify that to management.
Honestly there are good reasons to resist AI even as a senior. If prompting an LLM cannot be easily integrated into your existing workflow or demands a huge change in tooling, it's just distracting or crippling. I don't think we need to have a long discussion as to why distractions and context switches are counterproductive.
You can say that, but when the principle down the hall from you who's got a highly tuned agentic AI workflow is outproducing half your team by himself while leading engineering direction on multiple projects, it's hard to justify that to management.
I’m sure it will all come down to their risk appetite.
The author seems to have an inflated notion of what developing software is about. Most software doesn't require "perspicacity". Think about Civil Engineering. In a very few cases you are designing a Golden Gate Bridge. The vast majority of the time you are designing yet another rural bridge over a culvert. The first case requires deep investigation into all of the factors involving materials strength, soil dynamics, ... In the second case your role as an engineer is to run the standard calculations so that it meets legal standards and isn't going to fall apart in a couple of years.
We all like to think the we are grand architects finely honing software for the ages, when in reality we are really just specifying that the right grade of gravel is being used in the roadbed so that you don't get potholes.
> I don't think anyone believes that a computer program is literally their companion Quoth the makers of Claude: > AI systems are no longer just specialized research tools: they’re everyday academic companions. > https://www.anthropic.com/news/anthropic-education-report-ho... To call Anthropic's opener brazen, obnoxious, or euphemistic would be an understatement. I hope it ages like milk, as it deserves, and so embar…
I don’t think there’s a contradiction. Anthropic writes this because they want people to believe this, the author argues though that no one believes it.
I believe there’s a small minority of people that truly believes AI is a friend, but I would say it’s a psychological pathology.
I don’t bother trying to guess what large companies really think: a/ they’re made of so many different stakeholders I don’t think it’s possible. And b/ I know money is the most important thing if they are large enough and have lots of anonymous investors, I don’t need to know anything else.
Remember when 3d printing was going to replace all manufacturing? Anybody? AI is closer to this sentiment than it is to the singularity.
It might not lead to singularity but for people who work in academia, in terms of setting and marking assignments and lecture notes, for good or bad AI has had an enormous impact. You might argue that LLMs have simply exposed some systematic defects instead of improving anything, but the impact is there. Dozens of lecturing workflows that were pretty standard 2 years ago are no longer viable. This includes the entire…
I fully agree, in academia it truly is a revolution - for good and for bad.
There will be the before and after AI eras in academia.
I strongly agree with both the premise of the article, and most of the specific arguments brought forth. That said, I've also been noticing some positive aspects of using LLMs in my day-to-day. For context, I've been in the software trade for about three decades now. One thing working with AI-generated code forces you to do is to read code -- development becomes more a series of code reviews than a first-principles c…
I appreciate your nuanced position. I believe that any developer who isn't reading more code than they are writing is doing it wrong. Reading code is central to growth as a software engineer. You can argue that you'll be reading more bland code when reviewing code generated with the aid of an LLM. I still think you are learning. I've read lots of LLM generated code and I routinely learn new things. Idioms that I wasn't familiar with, or library calls I didn't know existed.
I also think that LLMs are an even more powerful accelerant for senior developers. We can prompt better because we know what exists and what to not bother trying.