gombosg

Haha, nice website, with the greyed-out comments on HN featured among the offending examples. :)

I think this is where the circle closes with the "dead internet theory"... you go to Reddit, and see bots commenting on posts created by bots.

Then you go on to search for something, and find only results that are clearly AI generated pages and come to the conclusion that directly prompting some LLM is better than reading an AI slop page that's output by the same AI for slightly less specific prompt.

My concern is that this will only get worse over time - which is great for companies selling AI tokens and bad for society and whoever wants to interact with other humans over the internet.

I started my career as a machine designer (mechanical engineering), designing some machines for FMCG factories.

It wasn't that much different from SWE - mostly looking up catalogs, connecting certain pre-made pieces together with custom parts and lots of testing of the final plan to make sure there are no collisions and every movement is constrained properly.

95% of the time no load or sizing calculations were necessary - we just oversized everything based on tacit knowledge (the greybeards reviewing the plans) since these machines were not mass produced and choosing somewhat bigger parts was not expensive given that these machines would operate and produce value 24/7 for years.

(I hope the analogy to software engineering is visible!)

What I'm saying is that the level of "engineering rigor" heavily depends on the field where engineers are operating within. Even certain SWE fields (healthcare, finance, aviation etc.) have more regulation and require more rigor than others.

Right at the top: "That distinction matters more than people think." That's basically telltale AI :)

Also the entire framing around "judgment" and "taste" is what LLMs love to parrot about the topic.

There are fair arguments in the post but I totally agree that "writing is thinking" and also holding myself to "if you didn't bother to write it, why would I bother to read it"?

I'm sorry for your experience, but loved the painting at the end... :)

I think you're right, ephemeral code would be the concept that you have (I'm hand-waving) "the spec", that specifies what the code should be doing and the AI could regenerate the code any time based on it.

I'm also baffled by this concept and fundamentally believe that code _should be_ the ground truth (the spec), hence it should be human readable. That's what "clean code" would be about, choosing tools and abstractions so that code is consumable for humans and easy to reason about, debug and extend.

If we let go of that and rely on LLMs entirely... not sure where that would land, since computers ultimately execute the code - and the company is liable for the results of that code being executed -, not the plain language "specs".

Exactly, basically then every desk or office job means sitting next to a box?

I still don't get it.

If AI really improves efficiency and allows the company's employees to produce more, better products faster and thus increase the competitiveness of a company... then why does said company fire (half of!) its staff instead of, well, producing more, better products faster, thus increasing its competitiveness?

Am I naive or is AI a lie when marked as a cause?

Why is it that us employees are gaslighted with the FOMO of "if you don't adopt AI to produce more, then you'll be replaced by employees who do", and why do these executives don't feel "if you fire half of your employees for whatever reason, you'll be outcompeted by companies who... simply didn't?"

Love your approach and that you actually have "before vs. after" numbers to back it up!

I personally also use AI in a similar way, strongly guiding it instead of vibe-coding. It reduces frustration because it surely "types" faster and better than me, including figuring out some syntax nuances.

But often I jump in and do some parts by myself. Either "starting" something (creating a directory, file, method etc.) to let the LLM fill in the "boring" parts, or "finishing" something by me filling in the "important" parts (like business logic etc.).

I think it's way easier to retain authorship and codebase understanding this way, and it's more fun as well (for me).

But in the industry right now there is a heavy push for "vibe coding".

I think there are four fundamental issues here for us...

1. There are actually less software jobs out there, with huge layoffs still going on, so software engineering as a profession doesn't seem to profit from AI.

2. The remaining engineers are expected by their employers to ship more. Even if they can manage that using AI, there will be higher pressure and higher stress on them, which makes their work less fulfilling, more prone to burnout etc.

3. Tied to the previous - this increases workism, measuring people, engineers by some output benchmark alone, treating them more like factory workers instead of expert, free-thinking individuals (often with higher education degrees). Which again degrades this profession as a whole.

3. Measuring developer productivity hasn't really been cracked before either, and still after AI, there is not a lot of real data proving that these tools actually make us more productive, whatever that may be. There is only anecdotal evidence: I did this in X time, when it would have taken me otherwise Y time - but at the same time it's well known that estimating software delivery timelines is next to impossible, meaning, the estimation of "Y" is probably flawed.

So a lot of things going on apart from "the world will surely need more software".

I love using LLMs as well as rubber ducks - what does this piece of code do? How would you do X with Y? etc.

The problem is that this spec-driven philosophy (or hype, or mirage...) would lead to code being entirely deprecated, at least according to its proponents. They say that using LLMs as advisors is already outdated, we should be doing fully agentic coding and just nudge the LLM etc. since we're losing out on 'productivity'.

I can totally relate to your experience.

I started this career because I liked writing code. I no longer write a lot of code as a lead, but I use writing code to learn, to gain a deeper understanding of the problem domain etc. I'm not the type who wants to write specs for every method and service but rather explore and discover and draft and refactor by... well, coding. I'm amazed at creating and reading beautiful, stylish, working code that tells a story.

If that's taken away, I'm not sure how I could retain my interest in this profession. Maybe I'll need to find something else, but after almost a decade this will be a hard shift.

I think this analogy to assembly is flawed.

Compilers predictably transform one kind of programming language code to CPU (or VM) instructions. Transpilers predictably transform one kind of programming language to another.

We introduced various instruction architectures, compiler flags, reproducible builds, checksums exactly to make sure that whatever build artifact that's produced is super predictable and dependable.

That reproducibility is how we can trust our software and that's why we don't need to care about assembly (or JVM etc.) specifics 99% of the time. (Heck, I'm not familiar with most of it.)

Same goes for libraries and frameworks. We can trust their abstractions because someone put years or decades into developing, testing and maintaining them and the community has audited them if they are open-source.

It takes a whole lot of hand-waving to traverse from this point to LLMs - which are stochastic by nature - transforming natural language instructions (even if you call it "specs", it's fundamentally still a text prompt!) to dependable code "that you don't need to read" i.e. a black box.

I think that just because AI won't be as good for tech as initially promised, it still has penetration potential in the wider economy.

OK I don't have numbers to back it up but I wouldn't be surprised if most of the investment and actual AI use was not tech (software engineering), but other use cases.

I also backed out from using Zed a couple months ago, but since last week, Linux font rendering looks good to me both on full HD and HiDPI displays.

I kind of miss the RSS days when you just had your own news/blog aggregator without the annoyance of Substack, Medium or anything else.

Agreed - computer music compared to live music is what, say, Adobe Illustrator is to drawing. Or a Wacom drawing table, but definitely not prompting AI to draw for you.

Whether drawing (writing etc.) through AI counts as drawing (as making art) is a debate we have to resolve in the upcoming future.

Who am I to debate with Tim O'Reilly?

But this made my mind explode:

So yes, let’s be bold and assume that AI codevelopers make programmers ten times as productive. (Your mileage may vary, depending on how eager your developers are to learn new skills.)

Has anyone ever seen this hypothetical 10x AI developer? Why do we always back into such hand-wavy arguments when talking about the efficiency of AI-supported software engineering?

Here's what I think the flaw is in all the AI hype's arguments, including the one in this article (I hope Tim O'Reilly can withstand this small amount of debate).

Currently, LLM AIs are stochastic parrots and they don't offer creating levels of abstractions, i.e. creatively and responsively packaging ideas into some higher level form that can be reused.

All the examples in the article did offer a higher level of abstraction: assembly, high-level programming languages, libraries & frameworks like React, database systems etc.

AIs don't offer abstractions. They are not creative, they don't have "better ideas" than what their training data contains. They don't take responsibility for their work.

Us engineers at our company have all tried and are using some AI tools but they don't nearly work as well as management would think so. They make us 10%, maybe in the best case 20% more efficient, but not 10x efficient or anything.

Let's just call mutators as 'mixins' :)

So many good memories from high school! Gaming in the computer lab was banned in theory and the teacher always tried to delete any games found on these machines. So we always kept about a dozen 'hidden' copies on each machine.

I think that unit tests are super valuable because when used properly, they serve as micro-specifications for each component involved.

These would be super hard to backfill later, because usually only the developer who implements them knows everything about the units (services, methods, classes etc.) in question.

With a strongly typed language, a suite of fast unit tests can already be in feature parity with a much slower integration test, because even if mocked out, they essentially test the whole call chain.

They can offer even more, because unit tests are supposed to test edge cases, all error cases, wrong/malformed/null inputs etc. By using integration tests only, as the call chain increases on the inside, it would take an exponentially higher amount of integration tests to cover all cases. (E.g. if a call chain contains 3 services, with 3 outcomes each, theoretically it could take up to 27 integration test cases to cover them all.)

Also, ballooning unit test sizes or resorting to unit testing private methods give the developer feedback that the service is probably not "single responsibility" enough, providing incentive to split and refactor it. This leads to a more maintainable service architecture, that integration tests don't help with.

(Of course, let's not forget that this kind of unit testing is probably only reasonable on the backend. On the frontend, component tests from a functional/user perspective probably bring better results - hence the popularity of frameworks like Storybook and Testing Library. I consider these as integration rather than unit tests.)

Yes, this is why we love functional programming! "What happened along the way" equals to the call stack, as long as there is no field mutation involved.

And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.

Yes: "IBM to pause hiring in plan to replace 7,800 jobs with AI, Bloomberg reports"

https://www.reuters.com/technology/ibm-pause-hiring-plans-re...

"Obviously" hilarious! :)

Anyone also using Timewarrior? It's FOSS, command-line and also dead simple.

I agree. Usually you're already working within some framework or DSL where you can describe what you want to do. Ideally, you already have an idiomatic codebase enabling you to succinctly transform specifications into code.

Let's take parent poster's issues:

Writing HTTP endpoints, parsing json. Mapping data types.

The generative model (for now) won't figure out for you: authentication, authorization, input form schema, JSON schema, required & optional fields, field constraints, entity modeling, indexing, query optimization, just to name a few basic issues we are looking at when "just developing CRUD apps".

If any of those go bad, it would result in 400s, 500s, performance or security issues.

I think the ultimate question is how much more productive a software engineer would get compared to baseline. I.e. using GPT for assistive programming instead of using Google, Stackoverflow and some good ol' thinking about problems.

Productivity means not just coding, but the ability and rate to successfully complete software projects and maintain software.

Factor in that soon, most search engines will also use GPT as a backend (as Bing already does) in some form, to get an explicit answer or better rank search results. Thus, search engines will also improve and lead to more productivity.

We might not need less software engineers at all due to the Jevons paradox. [1]

Basically, demand for software engineers is constantly increasing currently, in a roughly linear fashion, despite automation being at levels never seen before. Think low-code/no-code API integration platforms, simple to use, high-level and mature programming languages, frameworks & libraries, cloud technology etc.

We never measured how many developers these technologies have replaced, because the increase in application possibilities and technology accessibility have only created jobs.

Assistive programming with GPT (if/when possible in a professional way, like Copilot is) could only disrupt this if the average productivity increase for every developer in the world over-weighs the average increase of jobs.

So, if ceteris paribus there would be 3-4% more developer jobs each year [2], then, if 10% of developers globally started using GPT assistive programming, they would need a 30-40% overall productivity increase in order to thwart that trend.

That's a lot, because it's not just being able to create some "x code snippet 20% faster", but generally being able to complete entire software projects 30-40% faster (and maintain them 30-40% more efficiently!) than their non-GPT-user counterparts.

If the productivity increase is more like in the 10% range, then on the individual level, time might be better spent leveling up and learning technology instead of learning how to tweak prompts and find bugs in GPT-generated code - as learning any technology as a developer yields to way more than a mere 10% of increase in productivity.

[1] https://en.wikipedia.org/wiki/Jevons_paradox [2] https://www.statista.com/statistics/627312/worldwide-develop...

Haha, same here, whenever I see some random meeting called "[whatever] chat" being scheduled, like "Engineering chat" or "Quick eng all-hands", you know it's

1. Someone's leaving or is getting fired from the department 2. More people are getting fired

The point is that this, along with "*changes" is always bad news. :D

I saw your same - not really valuable - comment above. If you're using Windows for games only, then having or not having an Edge icon on the desktop is not an issue.

If you're using it professionally, then it's annoying, along with all the ads, tracking, dark patterns and other bullshit you receive in Windows - especially that you already pay for a license.

Compare that with Linux, which mostly gets out of your way, doesn't track you and is free.

I've been using (Fedora) Linux for professional work for more than 5 years now and still very happy with it. I'm also gaming occasionally on a dual-booted Windows (browsing HN while Death Stranding is installing :)) and get annoyed every time when booting into it.

It always feels good to go back to Linux, where you can play most non-AAA game titles anyway.

Maybe this is a good time to ask. Have you found Pomodoro to be good for coding?

When I get into the flow I completely lose track of time, and find the 5 minutes interruption every 25 minutes annoying. And then, during the break, I either can't get my thoughts off the problem at hand, or I do and then it's more effort to get back to the task.

I'm curious about your experience.