[thallavajhula]

I’m loving today. HN’s front page is filled with some good sources today. No nonsense sensationalism or preaching AI doom, but more realistic experiences.

I’ve completely turned off AI assist on my personal computer and only use AI assist sparingly on my work computer. It is so bad at compound work. AI assist is great at atomic work. The rest should be handled by humans and use AI wisely. It all boils down back to human intelligence. AI is only as smart as the human handling it. That’s the bottom line.

[tick_tock_tick]

> AI is only as smart as the human handling it.

I think I'm slowly coming around to this viewpoint too. I really just couldn't understand how so many people were having widely different experiences. AI isn't magic; how could I have expected all the people I've worked with who struggle to explain stuff to team members, who have near perfect context, to manage to get anything valuable across to an AI?

I was original pretty optimistic that AI would allow most engineers to operate at a higher level but it really seems like instead it's going to massively exacerbate the difference between an ok engineer and a great engineer. Not really sure how I feel about that yet but at-least I understand now why some people think the stuff is useless.

[btown]

One of my mental models is that the notion of "effective engineer" used to mean "effective software developer" whether or not they were good at system design.

Now, an "effective engineer" can be a less battle-tested software developer, but they must be good at system design.

(And by system design, I don't just mean architecture diagrams: it's a personal culture of constantly questioning and innovating around "let's think critically to see what might go wrong when all these assumptions collide, and if one of them ends up being incorrect." Because AI will only suggest those things for cut-and-dry situations where a bug is apparent from a few files' context, and no ambitious idea is fully that cut-and-dry.)

The set of effective engineers is thus shifting - and it's not at all a valid assumption that every formerly good developer will see their productivity skyrocket.

[btucker]

I've been starting to think of it like this:

Great Engineer + AI = Great Engineer++ (Where a great engineer isn't just someone who is a great coder, they also are a great communicator & collaborator, and love to learn)

Good Engineer + AI = Good Engineer

OK Engineer + AI = Mediocre Engineer

[jgilias]

This fits my observations as well. With the exception that it’s sometimes the really sharp engineers who can do wonders themselves who aren’t really great at communication. AI really needs you to be verbose, and a lot of people just can’t.

[felipeerias]

At the moment, AI tools are particularly useful for people who feel comfortable browsing through large amounts of text, intuitively nudging the machine this way and that until arriving at a valuable outcome.

However, that way of working can be exasperating for those who prefer a more deterministic approach, and who may feel frustrated by the sheer amount of slightly incorrect stuff being generated by the machine.

[oblio]

As a summary, any scaling tech greatly exacerbates differences.

Nassim Taleb is the prophet of our times and he doesn't get enough credit.

[jerf]

I've been struggling to apply AI on any large scale at work. I was beginning to wonder if it was me.

But then my wife sort of handed me a project that previously I would have just said no to, a particular Android app for the family. I have instances of all the various Android technologies under my belt, that is, I've used GUI toolkits, I've used general purpose programming languages, I've used databases, etc, but with the possible exception of SQLite (which even that is accessed through an ORM), I don't know any of the specific technologies involved with Android now. I have never used Kotlin; I've got enough experience that I can pretty much piece it together when I'm reading it but I can't write it. Never used the Android UI toolkit, services, permissions, media APIs, ORMs, build system, etc.

I know from many previous experiences that A: I could definitely learn how to do this but B: it would be a many-week project and in the end I wouldn't really be able to leverage any of the Android knowledge I would get for much else.

So I figured this was a good chance to take this stuff for a spin in a really hard way.

I'm about eight hours in and nearly done enough for the family; I need about another 2 hours to hit that mark, maybe 4 to really polish it. Probably another 8-12 hours and I'd have it brushed up to a rough commercial product level for a simple, single-purpose app. It's really impressive.

And I'm now convinced it's not just that I'm too old a fogey to pick it up, which is, you know, a bit of a relief.

It's just that it works really well in some domains, and not so much in others. My current work project is working through decades of organically-grown cruft owned by 5 different teams, most of which don't even have a person on them that understands the cruft in question, and trying to pull it all together into one system where it belongs. I've been able to use AI here and there for some stuff that is still pretty impressive, like translating some stuff into psuedocode for my reference, and AI-powered autocomplete is definitely impressive when it correctly guesses the next 10 lines I was going to type effectively letter-for-letter. But I haven't gotten that large-scale win where I just type a tiny prompt in and see the outsized results from it.

I think that's because I'm working in a domain where the code I'm writing is already roughly the size of the prompt I'd have to give, at least in terms of the "payload" of the work I'm trying to do, because of the level of detail and maturity of the code base. There's no single sentence I can type that an AI can essentially decompress into 250 lines of code, pulling in the correct 4 new libraries, and adding it all to the build system the way that Gemini in Android Studio could decompress "I would like to store user settings with a UI to set the user's name, and then display it on the home page".

I think I recommend this approach to anyone who wants to give this approach a fair shake - try it in a language and environment you know nothing about and so aren't tempted to keep taking the wheel. The AI is almost the only tool I have in that environment, certainly the only one for writing code, so I'm forced to really exercise the AI.

[katbyte]

It’s like the difference between someone who can search the internet or codebase well bs someone who can’t

Using search engines is a skill

[smartmic]

Today, I read the following in the concluding sentence of Frederik P. Brooks' essay “No Silver Bullets, Refired"[0]. I am quoting the entire chapter in full because it is so apt and ends with a truly positive message.

> Net on Bullets - Position Unchanged

> So we come back to fundamentals. Complexity is the business we are in, and complexity is what limits us. R. L. Glass, writing in 1988, accurately summarizes my 1995 views:

>> So what, in retrospect, have Parnas and Brooks said to us? That software development is a conceptually tough business. That magic solutions are not just around the corner. That it is time for the practitioner to examine evolutionary improvements rather than to wait—or hope—for revolutionary ones.

>> Some in the software field find this to be a discouraging picture. They are the ones who still thought breakthroughs were near at hand.

>> But some of us—those of us crusty enough to think that we are realists—see this as a breath of fresh air. At last, we can focus on something a little more viable than pie in the sky. Now, perhaps, we can get on with the incremental improvements to software productivity that are possible, rather than waiting for the breakthroughs that are not likely to ever come.[1]

[0]: Brooks, Frederick P.,Jr, The mythical man-month: essays on software engineering (1995), p. 226

[1]: Glass, R. L., "Glass"(column), System Development, (January 1988), pp. 4-5.

[WhyNotHugo]

> AI is only as smart as the human handling it.

An interesting stance.

Plenty of posts in the style of "I wrote this cool library with AI in a day" were written by really smart devs who are known for shipping good quality library very quickly.

[devmor]

I'm right there with you, and having a similar experience at my day job. We are doing a bit of a "hack week" right now where we allow everyone in the org to experiment in groups with AI tools, especially those that don't regularly use them as part of their work - and we've seen mostly great applications of analytical approaches, guardrails and grounded generation.

It might just be my point of view, but I feel like there's been a sudden paradigm shift back to solid ML from the deluge of chatbot hype nonsense.

[rerdavies]

Sure. But a smart person using an AI is way smarter than a smart person not using an AI. Also keep in mind that the IQ of various AIs varies dramatically. The Google Search AI, for example, has an IQ in the 80s (and it shows); whereas capable paid AIs consistently score in the 120 IQ range. Not as smart as me, but close enough. And entirely capable of doing in seconds what would take me hours to accomplish, while applying every single one of my 120+ IQ points to the problem at hand. Im my opinion, really smart people delegate.

[danenania]

The way I've been thinking about it is that the human makes the key decisions and then the AI connects the dots.

What's a key decision and what's a dot to connect varies by app and by domain, but the upside is that generally most code by volume is dot connecting (and in some cases it's like 80-90% of the code), so if you draw the lines correctly, huge productivity boosts can be found with little downside.

But if you draw the lines wrong, such that AI is making key decisions, you will have a bad time. In that case, you are usually better off deleting everything it produced and starting again rather than spending time to understand and fix its mistakes.

Things that are typically key decisions:

- database table layout and indexes

- core types

- important dependencies (don't let the AI choose dependencies unless it's low consequence)

- system design—caches, queues, etc.

- infrastructure design—VPC layout, networking permissions, secrets management

- what all the UI screens are and what they contain, user flows, etc.

- color scheme, typography, visual hierarchy

- what to test and not to test (AI will overdo it with unnecessary tests and test complexity if you let it)

- code organization: directory layout, component boundaries, when to DRY

Things that are typically dot connecting:

- database access methods for crud

- API handlers

- client-side code to make API requests

- helpers that restructure data, translate between types, etc.

- deploy scripts/CI and CD

- dev environment setup

- test harness

- test implementation (vs. deciding what to test)

- UI component implementation (once client-side types and data model are in place)

- styling code

- one-off scripts for data cleanup, analytics, etc.

That's not exhaustive on either side, but you get the idea.

AI can be helpful for making the key decisions too, in terms of research, ideation, exploring alternatives, poking holes, etc., but imo the human needs to make the final choices and write the code that corresponds to these decisions either manually or with very close supervision.