Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI has a multiplying effect on existing technical skills

joshwcomeau.com

Post reply on HN
Print view View original

81–90 of 344 posts

Re: AI has a multiplying effect on existing technical skills

#81

Post by enraged_camel »

giancarlostoro wrote: post #53
akersten wrote: post #23

Earlier quoted context omitted.

> The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end. In the Tailwind thread the other day I was explicitly told that the intended experience of many frameworks is "write-only code" so maybe this is just the way of the future that we have to learn to embrace. Don't worry how it's all hooked u…

Easy, have Claude review the code, tell it to be critical and that it needs to be easier to understand, follow Clean Code, SOLID principles and best practices. Lie to it, say you got this from a Junior developer, or "review it as if you were a Staff Level Engineer reviewing Junior code" the models can write better code, just nobody tells them to.

Even better, if you have access to multiple models, tell it you got the code from another AI agent.

I did an experiment on this a few weekends ago and Codex for example was a lot more adversarial and thorough in its review when given Claude-authored code compared to when given the same code with "I wrote this, can you review it?"

Re: AI has a multiplying effect on existing technical skills

#82

Post by tambourine_man »

reconnecting wrote: post #4

> I think AI tools are more like Iron Man's suit. There's an interesting repository with 63600 stars on GitHub (1). The developer of the repository is No 1 at the GitHub's trending contributors list (2). However, it seems like the application isn't what it's described to be (3), and the developers, on their end, are unable to clearly answer whether this is real or not, as it's just messy LLM output. Proof that the su…

> After a thorough independent code audit with cross-verification from three AI systems (Claude, Codex/GPT-5.2, Gemini), we confirm that this project is a non-functional facade.

So, a nonfunctional project is created by AI and AI is used to attests its nonfunctionality.

What a brave new world.

Re: AI has a multiplying effect on existing technical skills

#83

Post by giancarlostoro »

enraged_camel wrote: post #81
giancarlostoro wrote: post #53

Earlier quoted context omitted.

Easy, have Claude review the code, tell it to be critical and that it needs to be easier to understand, follow Clean Code, SOLID principles and best practices. Lie to it, say you got this from a Junior developer, or "review it as if you were a Staff Level Engineer reviewing Junior code" the models can write better code, just nobody tells them to.

Even better, if you have access to multiple models, tell it you got the code from another AI agent. I did an experiment on this a few weekends ago and Codex for example was a lot more adversarial and thorough in its review when given Claude-authored code compared to when given the same code with "I wrote this, can you review it?"

If it's within its context window, it will know you're lying, so either compact or start a new chat (don't do this on Claude, it dings your usage, always has).

Re: AI has a multiplying effect on existing technical skills

#85

Post by wiseowise »

Waterluvian wrote: post #6

I had an Iron Man moment last week where I was “vibe coding” a UI design with component tests live on the other screen. Iterating by asking it to move things, reduce emphasis of an element, exploring layout options, etc. The loop was near realtime and felt amazing. The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly…

> I had an Iron Man moment

Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment.

Re: AI has a multiplying effect on existing technical skills

#87

Post by gbear0 »

Waterluvian wrote: post #6

I had an Iron Man moment last week where I was “vibe coding” a UI design with component tests live on the other screen. Iterating by asking it to move things, reduce emphasis of an element, exploring layout options, etc. The loop was near realtime and felt amazing. The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly…

Why was it a maintenance dead end? It sounds like you were able to iteratively work on it in its current state, but are you going to be the one maintaining the code?

I keep asking myself the same questions, and the conclusion I keep coming to is the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.

There's definitely an efficiency angle here where it's faster for AI to go from a clean modeled solution to the desired solution because it's likely been trained on cleaner code. Is this really going to matter though?

The best argument I can come up with is the clean modeled solution is better for existing development tools because it's less likely to get confused by the patch work of vibes throughout the code; but this feels like it ultimately becomes an efficiency concern as well.

This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.

Re: AI has a multiplying effect on existing technical skills

#88

Post by marcosdumay »

giancarlostoro wrote: post #53
akersten wrote: post #23

Earlier quoted context omitted.

> The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end. In the Tailwind thread the other day I was explicitly told that the intended experience of many frameworks is "write-only code" so maybe this is just the way of the future that we have to learn to embrace. Don't worry how it's all hooked u…

Easy, have Claude review the code, tell it to be critical and that it needs to be easier to understand, follow Clean Code, SOLID principles and best practices. Lie to it, say you got this from a Junior developer, or "review it as if you were a Staff Level Engineer reviewing Junior code" the models can write better code, just nobody tells them to.

Lol, the only thing worse than a junior developer following Clean Code and SOLID has to be an LLM messing with code so it looks like it follows.

Re: AI has a multiplying effect on existing technical skills

#89

Post by renticulous »

snide wrote: post #7

I mostly share Josh's opinion, but I think a lot of these posts that talk about Senior vs. Junior experience when working with AIs is kind of rubbish. Sure, you get better results as a Senior working with AI tooling and struggle more as a Junior. Nothing has changed in that equation except the amplification. What folks seem to avoid is that a Junior (in ANY subject) has the ability to LEARN so much faster with an AI…

There are other axes as well.

Companies with AI will move faster than those without.

AI itself could subsume what we collectively consider as Engineering Taste.

AI is faster at what it does. So even if a junior costs less on his own than AI. Paying extra for AI means gaining first mover advantage.

Re: AI has a multiplying effect on existing technical skills

#90

Post by ff317 »

Waterluvian wrote: post #25
snarf21 wrote: post #16

Earlier quoted context omitted.

I feel the same but the question I struggle most with is this: "Does it matter when the people who are going to come along and maintain this are just going to use AI to fix or adjust this maintenance nightmare?"

At that point the code becomes a compile target, and then you need a new source of truth. Which I think is perfectly worthy of exploration. Some people want to check in the prompts. Or even better, check in a plan.md or evenest betterest: some set of very well-defined specifications. I'm not sure what the answer will be. Probably some mix of things. But today it is absolutely imperative that the code I write for the…

When we want to maintain a reliable, stable "product" in traditional software development (a binary executable artifact that ships out to users, or the binary engine of some SaaS the company sells to users), we don't just check in (to the source of truth repo) the actual application-layer source code. We also check in build instructions (think autoconf/cmake/etc) and have some concept of compiler compatibilities / versions, build environments, and papering over their runtime differences. And then our official executable output is not just defined by "Tag v1.23.45 of the application source code repo" - it's additionally defined by the build environment (including, critically, the compiler version, among many others).

It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output?

Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown.

If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos.

And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).

Post reply on HN