Completely disagree that "software development, as it has been done for decades, is over". AI is a useful tool, agreed - but it will always be reliant upon humans writing code. Let's take a very simple example to prove my point. Let's say that everybody is now using AI to write code, and someone develops a new programming language with it. Cool! We have a new language now. What we don't have, however, are any example…
Code is cheap. Show me the talk
211–220 of 237 posts
Re: Code is cheap. Show me the talk
#212Earlier quoted context omitted.
I genuinely appreciate your response, because there's a good chance it'll result in me changing my perspective, and I'm asking these questions with that intent! > You are thinking of assembly language which is a different thing. Initially there was no assembler, someone had to write one. This is why I specifically mention opcodes. I've actually written assemblers! And...there's not much to them. It's mostly just repl…
Computer Science stole the term abstraction from the field of Mathematics. I think mathematics can be really helpful in clearing things up here. A really simple abstraction in mathematics is that of numeric basis (e.g. base 10) for representing numbers. Being able to use the symbol 3 is much more useful than needing to write III. Of course, numbers themselves are an abstraction- perhaps you and I can reason about 3 a…
To continue with the idea of numbers, let’s say you asked someone to add 3 and 5. Is that encapsulation? What information are you hiding? You are not asking them to add coins or meters or reindeer. 3 and 5 are values independent of any underlying information. The numbers aren’t encapsulating anything.
Encapsulation is different. When you operate a motor vehicle, you concern yourself with the controls presented. This allows you, as the operator, to only need a tiny amount of knowledge to interact with an incredibly complex machine. This details have been encapsulated. There may be particular abstraction present, such as the notion of steering, acceleration, and breaking, but the way you interact with these will differ from vehicle to vehicle. Additionally, encapsulation is not concerned with the idea of steering, it is concerned with how to present steering in this specific case.
The two ideas are connected because using an abstraction in software often involves encapsulation. But they should not be conflated, out the likely result is bad abstractions and unwieldy encapsulation.
Re: Code is cheap. Show me the talk
#213> Thus, the extreme proponents of manic “agentic” vibe coding,[19] and the outright denouncers of LLMs, are both missing the forest for the trees. That there is a pragmatic middle path, where people who have the experience, expertise, competence, and the ability to articulate can use these tools to get the outcomes they desire with the right sets of trade-offs.
LLMs are tools. They are not gods to replace man, nor are they exclusively means of harm. It is entirely possible to denounce the blatant attempt of rent extraction in the form of OpenAI, Google Gemini, Microsoft CoPilot, Anthropic, and others, while still running Qwen and Ministral and their like on local hardware. You can, in fact, have it “both ways”.
As fun as it is to poke at cloud services to see their new features and advancements, I (in IT terms) personally could never recommend them in any serious enterprise context for the very reason that they’re fundamentally insecure; you will never, ever have full E2EE with these services because it would nullify their ability to evolve, improve, monetize, and exploit.
That said? I can truly be a one dinosaur army in an enterprise now, as a generalist with a modest Mac Mini (or Studio) and a local LLM to fill in edge cases as needed. I can query these local tools for questions on database schemas or build a one-off API integration for me, so I can focus on the substance of work in safeguarding and accelerating the enterprise. I don’t need fleets of specialists unless I’m running a huge conglomerate or have specific needs - and even then, it’s going to be cheaper to retain one or two seniors to direct the larger army of generalists when needed. The landscape has changed, and it’s why I target leadership and management roles accordingly with my sales pitch (“One senior generalist can do the work of three mid-level specialists”).
Don’t get me wrong, I still have immense grievances regarding theft of work, reductions in force, rent extraction, and the seeming attempt at destroying local general compute, but local LLMs as a tool have been in my kit for years, and that’s not going away.
Re: Code is cheap. Show me the talk
#214Earlier quoted context omitted.
No this is not the way we want learning to be - just like how students are banned from using calculators until they have mastered the foundational thinking.
There is research that shows that banning calculators impedes the learning of maths. It is certainly not obvious to me that calculators will have a negative effect - I certainly always allowed my kids to use them. LLMs are trickier and use needs to be restricted to stop cheating, just as my kids had restrictions on what calculators they could use in some exams. That does not mean they are all bad or even net bad if u…
I've seen oodles of research concluding the opposite at the primary level (grades 1- 5, say). If your mentioned research exists, it must be very well hidden :-/
Re: Code is cheap. Show me the talk
#215Re: Code is cheap. Show me the talk
#216Re: Code is cheap. Show me the talk
#217Earlier quoted context omitted.
One issue is that tooling and internals have been optimized for individual people's tastes currently. Heterogeneous environments make the models spikier. As we shift to building more homogenized systems optimized around agent accessibility, I think we'll see significant improvements Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agent…
> Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agents will be able to successfully solve problems in this codebase. If code is "bad" it makes future problems harder. An analogous argument was made in the 90's to advocate for the rising desire for IDEs and OOP languages. "Bad" code came to be seen as 1000+ lines in one file because y…
Ultimately I think we need to move away from the concept of codebases as they currently exist, towards "databases" of functionality that get composed as needed. Agents are going to make mixing and matching for bespoke purposes such a central paradigm that large monolithic packages don't make as much sense as they used to, just like monolithic apps make less sense in a world where agents programmatically call tools to do most work on computers.
Re: Code is cheap. Show me the talk
#218I asked Codex to write some unit tests for Redux today. At first glance it looked fine, and I continued on. I then went back to add a test by hand, and after looking more closely at the output there were like 50 wtf worthy things scattered in there. Sure they ran, but it was bad in all sorts of ways. And this was just writing something very basic. This has been my experience almost every time I use AI: superficially…
ATM I feel like LLM writing tests can be a bit dangerous at times, there are cases where it's fine there are cases where it's not. I don't really think I could articulate a systemised basis for identifying either case, but I know it when I see it I guess. Like the the other day, I gave it a bunch of use cases to write tests for, the use cases were correct the code was not, it saw one of the tests broken so it sought…
Additionally, if their code has broken existing tests, it "fixes" them by not fixing the code under test, but changing the tests... (assert status == 200 becomes 500 and deleting code.)
Tests "pass." PR is opened. Reviewers wade through slop...
Re: Code is cheap. Show me the talk
#219Earlier quoted context omitted.
This is how you do things if you are new to this game. Get two other, different, LLMs to thoroughly review the code. If you don’t have an automated way to do all of this, you will struggle and eventually put yourself out of a job. If you do use this approach, you will get code that is better than what most software devs put out. And that gives you a good base to work with if you need to add polish to it.
The quality of generated code does not matter. The problem is when it breaks 2 AM and you're burning thousands of dollars every minutes. You don't own the code that you don't understand, but unfortunately that does not mean you don't own the responsibility as well. Good luck on writing the postmortem, your boss will have lots of question for you.
And we'll just have the AI write the postmortem, so no big deal there. ;)