kweingar

And yet the systems built at these places far exceed what an indie dev can do

I was wondering if there was something particular about AI, but that's just the standard reason people give to use JS for anything.

Why is JS particularly good for agents?

Many of the curious ones will be adversely affected.

When you're a college student, the stakes feel so high. You have to pass this class or else you'll have to delay graduation and spend thousands of dollars. You have to get this grade or else you lose your grant or scholarship. You want to absorb knowledge from this project (honestly! you really do) but you really need to spend that time studying for a different class's exam.

"I'm not lazy, I'm just overwhelmed!" says the student, and they're not wrong. But it's very easy for "I'm gonna slog through this project" to become "I'm gonna give it a try, then use AI to check my answer" and then "I'm gonna automate the tedious bits that aren't that valuable anyway" and then "Well I'll ask ChatGPT and then read its answer thoroughly and make sure I understand it" and then "I'll copy/paste the output but I get the general idea of what it's doing."

Is it natural, or have we just adapted to it? Maybe if we had always had 10-day weeks, we'd get sick if we switched to 7.

I was being sarcastic there, a bad habit of mine. There are some advantages to being an early adopter (you get to reap some of the benefits now), but it doesn't give you a permanent advantage, and the people who aren't closely following and adopting weeks-old tools aren't doomed to irrelevance.

The iPhone was an equalizer. Existing mobile devs did get a genuine head start on mobile app design, but their advantage was fleeting.

(I deleted a less productive comment.)

I do use these tools though! I spent some time with AI. I have coworkers who are more heads-down working on their projects and not tinkering with agents, and they're doing fine. I have coworkers who are on the absolute bleeding edge of AI tools, and they're doing fine. When the tooling matures and the churn lessens and the temperature of the discourse is lowered, I'm confident that we will all be doing great things. I just think that the "anybody not using and optimizing Codex or Claude Code today is not gonna make it" attitude is misguided. I could probably wring out some more utility from these tools if I spent more time with them, but I'd rather spend most of my professional development time working on subject matter expertise. I want to deeply understand my domain, and I trust that AI use will (mostly) become relatively easier to pick up and less of a differentiator as time goes on

This is why devs who started with J2ME are the holy grail of app developers, since they started making apps years before iPhone devs

If the "meta" changes so quickly, then that sets an upper bound as to how far behind you are, no? Unless you are doing low-autonomy, non-specialized work or are applying to fly-by-the-seat-of-your-pants startup jobs, no hiring manager is going to care if you have three months less experience with Codex than the other candidate.[1]

so much of using LLM right now is context management

That is because the tooling is incredibly immature. Even if raw LLM capabilities end up plateauing, new and more effective tools are going to proliferate. You won't have to obsess over managing context, just like we don't have to do 2023-level tricks like "you are an expert" or "please explain your thought process" anymore. All of the context management tricks will be obsolete very soon... because AI tooling companies are extremely incentivized to solve it.

I find it implausible that the tech is in a state where full-time prompters are gaining a durable advantage over everyone else. J2ME devs probably thought they were building a snowballing advantage over devs who dismissed mobile development. Then the iPhone came out and totally reset the playing field.

[1] Most employers don't distinguish between three months and nine months of experience with JS framework du jour, no matter what it says on the job listing

Edited to add: Claude Code brought the agentic coding trend to the mainstream. It came out three months ago. You talk about how much you're laughing at the naivete of people here, but are you telling me with a straight face that three months is enough to put a talented engineer "behind"? At risk of being unemployable? The engineers who spent the last three months ping-ponging between Claude Code, Cursor, Codex, etc. can have their experience distilled into like a week of explaining to a newcomer, and I predict that will be true six months from now, or a year from now.

You're making at least a year's worth of pre-LLM progress in 5 weeks?

You expect to achieve more than a decade of pre-LLM accomplishments between now and June 2026?

If progress continues at the rate that AI boosters expect, then soon you won't have to use them smartly to get value (all existing workflows will churn and be replaced by newer, smarter workflows within months), and everybody who is behind will immediately catch up the moment they start to use the tool.

I can't think of many engineering disciplines that do things this way. "This seems to work, I don't know how or why it works, I don't even know if it's possible to know how or why it works, but I will just apply this moving forward, crossing my fingers that in future situations it will work by analogy."

If the act of discovery and iterative refinement makes prompting an engineering discipline, then is raising a baby also an engineering discipline?

I think we agree. Interacting with employees is not an engineering discipline, and neither is prompting.

I'm not objecting to the incantations or the vibes per se. I'm happy to use AI and try different methods to get the results I want. I just don't understand the claims that prompting is a type of engineering. If it were, then you would need benchmarks.

This is an interview published in Common Dreams, rehosted at Chomsky's site. Those are the interviewer's words, not Chomsky's.

How do we benchmark these different methodologies?

It all seems like vibes-based incantations. "You are an expert at finding vulnerabilities." "Please report only real vulnerabilities, not any false positives." Organizing things with made-up HTML tags because the models seem to like that for some reason. Where does engineering come into it?

If you cannot afford the hundreds of dollars a month Claude costs

Employers will buy AI tools for their employees, this isn't a problem.

If you're saying that you need to buy and learn these tools yourself in order to get a job, I strongly disagree. Prompting is not exactly rocket science, and with every generation of models it gets easier. Soon you'll be able to pick it up in a few hours. It's not a differentiator.

Highly recommend this podcast by patio11 explaining that poor people are not funding credit card rewards programs.

https://www.complexsystemspodcast.com/episodes/credit-card-r...

I keep hearing people express dismay that people are financing their lunch, sneakers, or concert tickets.

But this has been the norm for a while, no? I can't remember the last time I didn't utilize credit at a restaurant or retail store. If you use credit cards, it doesn't make sense to reflexively admonish people for using BNPL for everyday purchases.

To be sure, BNPL is in many ways a predatory innovation. But it isn't totally novel. It seems like a natural consequence of what came before.

I get paid to provide technical solutions to business problems.

That's true of all SWEs who write HTML and CSS, and it's the reason I don't think there's much downside for devs to not proactively start using these agentic tools.

If it truly turns weeks of work into hours as you say, then my managers will start asking me to use them, and I will use them. I won't be at a disadvantage compared to people who started using them a bit earlier than me.

If I am looking for a new job and find an employer that wants people to use agentic tools, then I will tell the hiring manager that I will use those tools. Again, no disadvantage.

Being outdated as a tech employee puts you at a disadvantage to the extent that there is a difficult-to-cross gap. If you are working in COBOL and the market demands Rust engineers, then you need a significant amount of learning/experience to catch up.

But a major pitch of AI tools is that it is not difficult to cross the gap. You draw on your domain experience to describe what you want, and it gives it to you. When it makes a mistake, you draw on your domain experience to tweak or fix things as needed.

Maybe someday there will be a gap. Maybe people will develop years of experience and intuition using particular AI tools that makes them much more attractive than somebody without this experience. But the tools are churning so quickly (Claude Code and Cursor are brand new, tools from 18 months ago are obsolete, newer and better tools are surely coming soon) that this seems far off.

I actually agree with this. I use LLMs often, and I don't compare them to a calculator.

Mainly I meant to push back against the reflexive comparison to a friend or family member or colleague. AI is a multi-purpose tool that is used for many different kinds of tasks. Some of these tasks are analogues to human tasks, where we should anticipate human error. Others are not, and yet we often ask an LLM to do them anyway.

Agreed. The nice thing is that I am told by HN and Twitter that agentic workflows makes code tasks very easy, so if it turns out that using these tools multiplies productivity, then I can just start using them and it will be easy. Then I am caught up with the early adopters and don't need to worry about being out-competed by them.

If it's zero effort, then why do devs need to adapt fast? And wouldn't adapting be incredibly easy?

The only disadvantage to not using these tools would be that your current output is slower. As soon as your employer asks for more or you're looking for a new job, you can just turn on AI and be as fast as everyone who already uses it.

I expect my calculator to be 100% accurate 100% of the time. I have slightly more tolerance for other software having defects, but not much more.

I don't think there was ever a sustainable route to a semantic web that would work for the masses.

People wanted to write and publish. Only a small portion of people/institutions would have had the resources or appetite to tag factual information on their pages. Most people would have ignored the semantic taxonomies (or just wouldn't have published at all). I guess a small and insular semantic web is better than no semantic web, but I doubt there was a scenario where the web would have been as rich as it actually became, but was also rigidly organized.

Exactly right. My books (and later, college courses) emphasized linked lists and inheritance as fundamental concepts of programming, but the reality as a working engineer is totally different.

When I first encountered Go, I was still a learner and the lack of these things in the language and standard libraries shocked me. But it turns out that they were writing a language more for practical software engineering than for outdated curricula. At the end of the day, structs, slices, and maps cover 99% of what you need!

I learned programming from a Java 7 book in high school. When I went through the Tour of Go, I found myself shocked that anybody would want to write software in a language like this. Where is inheritance? Where is the data structures package? I couldn't even find a standard linked list. What if I have a list where I need to make lots of insertions in the middle?

My 15-year-old self would be shocked at my day-to-day as an engineer now.

With GPL you don't have to actively work to upstream your patches, but in practice you can't withhold your patches from upstream. If you add a feature, they get to have it too.

Unlike permissively licensed software, where you can add proprietary features.

Since this has become a general thread about Epic, here are my comments:

I am amazed at some of the software Epic has built for itself over the years. Using its own database product (the backbone of the product they ship to customers), they built their own code review tools, design doc review tools, project management tools, time logging tools, etc. There is a unity and cohesion to the process of getting things done at Epic, better than my experiences at big tech.

It is very easy to answer questions like "how many dev-hours were spent fixing bugs caused by the code written to implement project X?" or "will there be any days next week where every dev who has contributed to codebase Y will be out of office?"

Imo they could really benefit from staffing infra/tooling teams better. Too many product devs, not enough devs tackling the low-hanging fruit that would make product devs way more productive.

This is an issue of tooling, not intelligence. Language models absolutely have the power to process email and send (push?) code, should you give them the tooling to do so (also true of human intelligence).

At a certain point, a tooling issue becomes an intelligence issue. AGI would be able to build the tools they need to succeed.

If we have millions of these things deployed, they can work 24/7, and they supposedly have human-level intelligence, then why haven't they been able to bootstrap their own tooling yet?

This is the reason why I am so confused by the strain of open source thought which says that large companies exploit OSS maintainers and ought to pay them.

Maintainers often pick permissive licenses specifically because they want companies to use the code. They want their project to grow and be adopted, and they reason that GPL would stifle adoption.

I don't really like the tactic of making your code as convenient as possible for anyone to grab off the shelf when they want to use it, and then later turning around and saying they should pay you. Why not do the payment part up front (by GPL-licensing the code and then selling dual licenses to interested companies)? Because then you wouldn't have any takers. Better to wait until people have integrated it into their systems before informing them that they ought to pay you.