Posted by poisonfountain 10 hours ago
It’s really unfortunate that AI hasn’t raised the ceiling on the space of possibilities as much as it’s raised the floor on how much can be automated, we’re all getting squeezed in the space between.
- More localism. Are you afraid of being cut off from tech by some future US government? Now it's feasible for your local culture to grow its own office suite, operating systems, Active Directory competitor etc. A less interdependent world with more competition does have its advantages.
- The building management company for my apartment sucks. Basic problems go unfixed because they appear to suffer extreme labour shortages and serious problems with flaky labour e.g. employees that just randomly go AWOL in the middle of conversations without bothering to tell anyone. A lot of the work of these employees is actually just coordinating and paying contractors in response to problem reports, something that can now be automated by AI ... but they haven't done it yet.
- I just finished assembling some flatpack furniture. Every time I do this it reminds me why IKEA dominates the market. Other furniture companies give the strong impression they don't usability test their instruction leaflets. This should and could be massively better: AR assistance during the build would be great, AI stress-testing instructions to verify they make sense would be great, AI checking every packet has the right number of components in it would be great. And there are lots of furniture companies out there. They don't all need to use a single SaaS to do this.
+ in general robots will require tons of software/models to make them do tasks usefully, especially as they lack training data.
That's just a few examples of places software could have made my life easier in just the last few weeks.
That is allready solved by FOSS.
Yup. Most everything we need was already built in the 1970s. Programmers have been kept busy because we've kept introducing incompatibilities into the mix, like DOS programs needing to be rewritten for Windows, and then the web, and then mobile.
And now they're being rewritten for AI platforms. It may be giving the squeeze due to being the first platform that will also help with the rewrite effort, but it is also the thing that kept the industry going. As you point out, there wasn't any work left to do until AI showed up.
I recently had Cursor evaluate a huge code base that we took over. All public stuff, nothing scary security wise, but it was so convoluted that it was taking me forever to find the bugs. It was written by a person, I should add.
I did this in cursor and after one prompt using Plan, it found all the bugs, created a plan to fix them, it looked good, and I had the agent create the fix.
It took 30 minutes.
The client had this project in the hands of another company without ai tools and they couldn’t fix the bugs she told them about.
So my point is, if we are holding on to our jobs for dear life on the basis that “code quality” matters, you might as well kick down the 4th pillar. Like I said, the LLM does not care.
Why aren't the designers and PMs shipping things if these tools are so good?
In every case when I've shifted domains, the skills that have got me the job were demonstrable solid programming experience on a wide variety of systems, with only a tangential link to the new company's business. In each case, I've gone in knowing almost none of the domain knowledge, but it's never been a problem because the business analysts know that stuff and tell me what they want me to do, or it's been stuff I've been able to pick up in the first few months.
For example, when I switched to games development it was the combo of systems admin and web backend development that the company wanted, I actually used none of those skills in the first year doing what they hired me for, and pretty quickly I'd transitioned from that to become a rendering engineer, and I've now spent the majority of my career optimising shaders and game engines.
So for me, it's certainly the case that I value my adaptability across domains, and I'm not worried about having to shift to another business domain because I know I'll be able to produce whatever it is they want if there's a reasonable spec in place.
Sure, when hiring if you have 2 candidates - 1 with the exact domain knowledge you want, and 1 without, the one with domain knowledge has a head start, but in the case where nobody has that domain knowledge (or in the case of the article, it doesn't matter because AI levels the field), then I don't think it matters much. Personally, I'd rather be the person with the broadest skills and able to pick up what I need than to have been stuck doing the same thing my entire career.
Don't get me wrong, I am sure we will get to all three of these pillars, probably by next year. I am not naive.
Genuine question: what exactly is "quality"?
It's something I've been trying to understand for a very long time. It seems like it's entirely contextual, and it has both subjective and objective facets (the latter only for quantifiable things, and still entirely contextual).
If you're using the product, and you want to question or debug what's going on, you can:
* Jump directly to the single relevant part of the frontend responsible
* Likewise with the backend. The layout and naming of the code should scream its purpose.
* Once you're looking at the code, it should be trivial to run it, right now, instantly, in unit test, or cli. You shouldn't need to stand up a database to see whether your code rounds taxes the expected way.
The system contains its own checkability. You can, for instance, just sum up all the incoming money and outgoing money and see if your balance is correct. (It's not enough to have good tests today, if you're working on data that was incorrectly calculated and stored yesterday)
Maybe ask the same question about other things. What makes a good guitar? What makes a good chair? What makes a good airplane? What makes a good book? What makes a good song? What makes good art? Each of these has a long list of very specific goals and concerns. And to help define the boundaries, also ask what makes something bad, and what makes something mediocre.
Code quality starts with functionality. Does it perform the stated requirements? Does it have testing in place to catch breaking changes in functional requirements? That’s the basic stuff that probably isn’t part of “taste”. A lot of code quality goals center around how code changes over time, and beliefs about designing to avoid functional breakage.
For example you can ask things like does the code use minimal dependencies? Is the code organized into clean classes/modules/functions that each have a single clear role? Is the API easy to read, understand, and use? Is the API hard to misuse accidentally? Is all the code easy to read? Is there documentation, and is the documentation useful, and more than a list of contents? Is the code self-documenting? Is the code efficient, both in how it executes, and in its use of code itself? Is the code designed so that it won’t fail when someone runs it with different sized types, or a different compiler or execution environment, or on a different architecture? Is the code surprisingly elegant and fun to use?
Those are just the beginning. There are of course more layers of application-specific and environment-specific and audience-specific qualities. The good news is that quality depends on your own goals, you can decide which aspects of taste matter to you, and ignore the ones that don’t. It’s fine if your taste & goals change over time.
Quality is usually observed from a human perspective. But in my experience, codebases that humans would judge as "low quality" are actually fine for LLMs. They don't have as much trouble as we do with spaghetti code. They don't have problems with readability or obscure syntax, it's all perfectly fine for them. They don't care about indentation either.
Also it's really easy to increase the quality of the code base. You can just prompt to add unit test coverage and it will. You can prompt the LLM to handle edge cases better and it will (you don't even have to specify which, it helps, but it's optional). If you want to have better separation of concerns, just ask the LLM to have more separation of concerns and you'll have it. Documentation lacking? Just one prompt away. More robust build pipeline? You get the idea.
one of myriad ways to define "quality" I use often is 'as the intersection of art and science'
I’m not planning on firing people, but I am planning on building more, using more tokens, and less app subscriptions.
One aspect of building that doesn’t erode is human values.
LLMs don’t create software with zero direction and although I do have 12 agents building constantly, I run out of attention to increase that to 100.
Is it really though? Access to information is quicker, but you still need to know what ‘good’ looks like to leverage it effectively. I can prompt my way to a medical diagnosis, but I’d still want to run it by a doctor.
If the LLM is wrong and gives you a wrong medical diagnosis you end up hurting your health. If an LLM gives you a wrong debugging answer you've just lost 5 minutes.
Software engineering is the only knowledge work where mistakes are usually inexpensive except for data breaches. Outside for that nobody cares for bugs.
That's not true in most other knowledge jobs. If a lawyer uses AI and hallucinates something there is a legal problem. If someone vibecodes an app and crashes, it can be fixed with more AI and try again
One of my tests for new models is to ask about a concept I already know the mathematical model for, but as if I don’t. So far, they all answer the same way:
1. Convoluted explanations about how it kinda-sorta is common terms.
2. If you follow up with the correct mathematical term, it immediately claims that’s correct and the right way to model it.
3. If you ask it why it didn’t use that term for your question, the LLM gives some version of explaining that it tried to match your language.
I have no choice but to assume the model behaves similarly other times — and that I am largely trapped in a basin of my own ignorance, when using LLMs.