bGl2YW5j

This is really good perspective and an interesting story, thanks for sharing.

What do you reckon would work well for Aus?

I'm Australian and am increasingly ok with this approach. I'm growing slowly out of a protectionist mindset, toward one of cautious, and considered collaboration. Singapore follows this approach and it has worked well for them so far.

This is awesome. It's sad that examples like this are few and far between.

I reckon there's a limit to how long this abstraction can go on before not understanding underlying mechanisms will seriously hamstring you.

I very much agree! It feels like it's going to be exceptionally challenging in the coming years to convince non-technical people of the value of true SWE; by that I mean, SWE is not just coding, it's everything around that too.

I've also been loving the speed Claude has enabled me to move at, and now agree that the coding part of SWE has become LLM-wrangling instead. I now see interacting with an LLM, to build all parts of software, as the new "frontend".

Following this idea, what do people think "backend" work will involve? Building and tweaking models, and the infra around them? Obviously everyone will shift more into architecture and strategy, but in terms of hands-on technical work I'm interested in where people see this going.

I like the analogy and will ponder it more. But it didn't take long before the article started spruiking Kasava's amazing solution to the problem they just presented.

Yes, but whether they admit it or not, as humans subjectivity, whether informed by culture, opinion, experience, etc, creeps in. There's also variation in how a judge applies objective assessment to law; my interpretation of law may be different to someone else's.

"Outperforms" ... how can performance be judged when it doesn't make sense to reduce the underlying "reasoning" to a well-known system? The law isn't black and white and is informed by so many things, one of which is the subjectivity of the judge.

I reckon this opinion is more prevalent than the hyped blog posts and news stories suggest; I've been asking this exact question of colleagues and most share the sentiment, myself included, albeit not as pessimistic.

Most people I've seen espousing LLMs and agentic workflows as a silver bullet have limited experience with the frameworks and languages they use with these workflows.

My view currently is one of cautious optimism; that LLM workflows will get to a more stable point whereby they ARE close to what the hype suggests. For now, that quote that "LLMs raise the floor, not the ceiling" I think is very apt.

LinkedIn is full of BS posturing, ignore it.

This is a really cynical take. People work differently and get value from different things. It’s probably safe to assume most aren’t virtue signalling about writing.

Great point about the conflation. This makes me realise: for me, writing code is often a big part of thinking through the problem. So it’s no wonder that I’ve found LLMs to be least effective when I cede control before having written a little code myself, ie having worked through the problem a bit.

I like Nord Dark because it uses only 3 colours. It’s available as an extension.

I’m working with doctors at the moment in a similar area. eGFR is well-known to decline at approx 1 point per year after age 30. You’re fine.

Here’s just one source: “After the age of 30 years, glomerular filtration rate (GFR) progressively declines at an average rate of 8 mL/min/1.73 m² per decade.4”

https://www.racgp.org.au/afp/2012/december/ckd-in-the-elderl...

If the model was able to generalise, you’d expect it to output something like “[silence]” or “…”, in response to silence.

Instead, it reverted to what it has seen before (in the training data), hence the overfit.

I use Jetbrains AI assistant for its great integration with the editor and the codebase, and have been experimenting with Claude Code too. Jetbrains Assistant still has better editor integration for things like reviewing generated diffs and generating code based on currently selected code.

My augmented workflow is to “chat” with GPT because it’s free and powerful, to refine my ideas and surface things I hadn’t thought about. Then I start writing code to get in to the flow of things. I’ve found if I use the LLM straight away, I disengage, become lazy and lose context and understanding over the code. In these situations, I’ve had to redo the code more often than not. Lack of understanding is one part of why, but more importantly, disengaged prompting leads to vague and incorrect outcomes.

When I’m very clear in my head about my goal, I create a prompt either directly from my cursor, or if the changes are larger, I ask the LLM to not apply the changes but instead show them to me. I do both these things within the IDE in the chat window. I review the code and sometimes I’m happy applying it as is, other times I copy and paste it and tweak it manually.

I’ve got barebones rules set up; I haven’t felt the need to go overboard. Jetbrains Assistant does a good job of passing relevant context to the model.

I keep my prompts top-down (https://en.wikipedia.org/wiki/BLUF_(communication)) and explicit. Sometimes I’m much more detailed than others, and I’ve found that extra detail isn’t always necessary for a good result.

Until an LLM or some new form of AI can manage an entire architecture itself, I say we need a middle ground. Something will always go wrong, and understanding of the system is necessary to troubleshoot.

I think the feeling to keep up is simply fear of being left behind. Fear is the same thing driving people to become defensive when others dismiss the idea of needing to keep up, because that undermines their core belief that the new “AI skills” they’ve acquired will keep them safe from job disruption.

It’s also interesting that at the heart of the skill set evolving around efficient LLM use, is communication. Engineers and technical people have been the first to admit for decades that they struggle with effective communication. Now everyone’s an expert orator, capable of describing in phenomenal detail to the LLM what they need from it?

Not worrying about all this feels so much better!

This week I saw a video of a robot assembling PCBs at lightning speed. This reminded me a lot of an LLM coding for us, but there are still numerous people in the production line to design, oversee and manage this kind of production. Software engineering is changing but not going.

Came to comment on the same quote.

I'm surprised, but know I shouldn't be, that we're at this point already.

These concepts have been copied directly from Notion.

I’ve found Anytype to be more streamlined. I’m highly familiar with Notion though, so adapted easily.

Yes! I’ve been thinking along similar lines: agents and LLMs are exposing the worst parts of the ergonomics of our current interfaces and tools (eg programming languages, frameworks).

I reckon there’s a lot to be said for fixing or tweaking the underlying UX of things, as opposed to brute forcing things with an expensive LLM.

Also feeling let down by it.

Have been using it to build a DSL in JS. Greenfield. I’ve followed the commonly touted “plan, act, evaluate” approach; I’ve got it to generate a clear project vision, scope, and feature checklist. Then told it to refer to that for context. I’ve been descriptive and explicit in my prompting, way more so than previously.

It has gotten the broad strokes right, I’ve got an exceptionally barebones DSL, made up of 5 entities, working…just.

It has now started to spin its wheels on small issues and can’t fix them without breaking something else. The codebase isn’t even big (~8 main functions across a few files). Troubleshooting the code is difficult because it’s convoluted and I lack the same intuition for it I would have had I written it myself. I’ve decided to rewrite everything with less control ceded to the LLM.

When it works, it feels great. When it doesn’t, which is often, the spell is broken and I feel I’ve wasted a bunch of time and have not much to show for it.

You should challenge this idea in your internal monologue. Learn a bit more about technology and how it's made. "Fast" in most cases most definitely does not equal cheap, especially over the long term.

"Shrink-and-grow technique for efficiently packing n-dimensional spheres" isn't obtuse enough.

I think something like "Hypertopological Constriction-Expansion Dynamics in Quasistatic R^n-Ball Conglomeration" would be even more apt.

I hated maths as a kid, now I love this stuff; pure maths for its own sake. Super impressive! It's a dream of mine to discover anything useful in the field.

I don’t think the problem is “how to optimise tool selection for the LLM”. I think the real problem is using an LLM to do tool selection at all. This is control flow and I believe should be handled with hardcoded rules and/separation of concerns.

If LLMs could handle determinism better, I’d say having a single chat-based entrypoint into a plethora of services makes sense. But as they stand, it doesn’t make sense. Simpler control flow and constraining the number and type of downstream services that sit behind a single interface I think is the way to go.

That said, I agree we should keep the ambition to move to the one size fits all approach.

Creative. You’ve given me some ideas. Thanks!

I’m interested if anyone here knows what exactly Cursor has built? My limited understanding is that they’ve done nothing but fork VS code and add a chat window and AI-integrated editing tools.

What a coincidence! I’m also in Australia and have just finished a self-imposed 8 month holiday from the tech world BS you describe.

I started the holiday super jaded with the idea of working in tech forever. I spent my time on everything but tech. Recently my passion has been reignited and I’ve got more clarity around what it is about tech and my career I enjoy, and what I want from my future.

Now, I’m working on a healthcare service for chronic disease.