seamossfet

I don't know if I agree with the premise that having access to AI results in dulling human intellect.

I feel like to get to Terry's level you need a combination of passion and aptitude for the subject. People that don't want to learn about a topic will always look for shortcuts, which I think represents the vast majority of people. Terry Tao is quite exceptional, and I think exceptional people will still exist even when the "easy" button is bigger than it's ever been.

The big take away for is the fact that the ONLY reason why chatgpt was able to get to this counterexample was because of the knowledge of the person driving the conversation.

I don't think chatgpt could have come to this on its own without the amount of steering he did, which just validates the idea that AI is not a replacement for human expertise but an amplifier.

Nothing wrong with vibecoding a toy project.

We're building a CAD for drug design, we often have to handle large and highly varied file formats. Protein structures, compounds, python scripts, lab notebook entries, instrumentation data, etc.

From a data structure and file ergonomics perspective, think of it as similar to Unity or UE4 for drug design. We have a huge variety of assets to manage alongside their relationships to each other, and the project files are local on the user's machine (with a collaboration / sync over the network between scientists working on the same project, hence where something like this would come in for us).

Many of those files are fine with a winning side strategy, but some of them might not be that clean. Take a protein structure defined by an `mmcif` file for example, if we clean the file by removing hydrogen atoms and another scientist repairs a side chain on that same file then we'd need a way to reconcile those differences.

On the agent side, our agents will generate small python scripts that manipulate the proteins, then cache and re-use those scripts as tools when possible. So preserving those scripts alongside the mutated asset and conversation history is something we've been working on.

Does this provide gitflow to handle conflicts from multiple agents touching the same file system or is it purely for single-branch sequential iterations on the filesystem?

I have a use case that could use this if it supports handling branching and merging file systems.

People often use "non-deterministic" to imply "unreliable" when that's not always the case. You can have an LLM that's clearly non-deterministic but also reliable for tasks.

Great article, but your site background had me trying to clean my laptop screen thinking I splashed coffee on it.

The hardest part about using agents to code for me has always been working in teams. When you can cut through huge parts of the code with a chainsaw, how do you review multi-thousand line PRs?

It's really hard to do surgical changes with an AI agent, and it's even harder to review those changes. Even if I'm reviewing the specs and the code, the cognitive load on reviews feel like they've ballooned from what used to be a few hours to now taking me days to review these PRs.

This is why I built [AI slop tool]. [Self promotion link to my vibe coded startup with no users]

A false dichotomy that segments typical replies into one of two groups.

Group 1: A thinly veiled straw man that buckets everyone I disagree with, along with an attempt to appear as if I'm being unbiased

Group 2: The group I put myself in and provide better arguments for why this perspective is correct.

Vague motte and bailey statement that gives me plausible deniability when someone criticizes my analysis.

The problem with models like this is they're built on very little actual training data we can trace back to verifiable protein data. The protein data back, and other sources of training data for stuff like this, has a lot of broken structures in them and "creative liberties" taken to infer a structure from instrument data. It's a very complex process that leaves a lot for interpretation.

On top of that, we don't have a clear understanding on how certain positions (conformations) of a structure affect underlying biological mechanisms.

Yes, these models can predict surprisingly accurate structures and sequences. Do we know if these outputs are biologically useful? Not quite.

This technology is amazing, don't get me wrong, but to the average person they might see this and wonder why we can't go full futurism and solve every pathology with models like these.

We've come a long way, but there's still a very very long way to go.

This is awesome! The only limiter here is the resolution, I think this is fantastic for cellular level organelles but it doesn't quite get down to the same resolution something like x-ray diffraction does.

There's a huge trade off between resolution and scale that makes it hard to determine things like complex molecular dynamics and how those dynamics influence the broader functions of the cell.

That said, excited for more images like this! More data at that scale is always a good thing for researchers.

Honestly, this is a good thing. OpenClaw as a concept was rather silly to run such a heavy model for. If you want something like OpenClaw to work you really need to figure out how to do it with an economical model.

Honestly, it'd be really funny to try and make a CLAUDE.md file for slop maxxing.

I'm not convinced people who are doing real work on production applications with any sizable user base is writing code through only agents. There's no way to get acceptable code from these models without really knowing your code base well and basically doing all the systems thinking for the model.

Your workflow is probably closer to what most SWEs are actually doing.

Oh my god, this comment gave me flashbacks to when I was writing android apps in Eclipse + ADT

We very much still believe this

That's good to hear, I might have jumped a little too quickly in my opinion. It's a bit of a Pavlovian response at this point seeing a product I very much love embrace a giant chat window as a UX redesign haha.

I would love to see more features on the roadmap that are more aligned with users like us that really embrace the Cursor 2 style with the code itself being the focal point. I'm sure there's a lot you can do there to help preserve code mental models when working with agents that don't hide the code behind a chat interface.

Yeah that's the disconnect though right? Even with the best frontier models, you need to do a lot of system design work, planning, and reviewing before you can let these models run.

These models are infinitely more effective when piloted by a seasoned software engineer and that will always be the case so long as these models require some level of prompting to function.

Better prompts come from more knowledgeable users, and I don't think we can just make a better model to change that.

The idea we're going to completely replace software engineers with agents has always been delusional, so anchoring their roadmap to that future just seems silly from a product design perspective.

It's just frustrating Cursor had a good attitude towards AI coding agents then is seemingly abandoning that for what's likely a play to appease investors who are drunk on AI psychosis.

Edit: This comment might have come off more callous than I intended. I just really love Cursor as a product and don't want to see it get eaten by the "AI is going to replace everything!" crowd.

Man, I wish they'd keep the old philosophy of letting the developer drive and the agent assist.

I feel like this design direction is leaning more towards a chat interface as a first class citizen and the code itself as a secondary concern.

I really don't like that.

Even when I'm using AI agents to write code, I still find myself spending most of my time reading and reasoning about code. Showing me little snippets of my repo in a chat window and changes made by the agent in a PR type visual does not help with this. If anything, it makes it more confusing to keep the context of the code in my head.

It's why I use Cursor over Claude Code, I still want to _code_ not just vibe my way through tickets.

I wonder how much of this is also used for audience segmentation for their advertisements? Linkedin ads are some of the most expensive out of any social media platform, but they also tend to have the highest conversion since you can get pretty niche with your targeting.

But if your workload is not shifting from write-heavy to read-heavy, you inevitably will be responsible for a major outage or quality issue.

I think that's actually a good way to look at it. I use AI to help produce code in my day to day, but I'm still taking quite a while to produce features and a lot of it is because of that. I'm spending most of my time reading code, adjusting specs, and general design work even if I'm not writing code myself.

There's no free lunch here, the workflow is just different.

slop cannons

I am stealing that phrase haha

Yeah, I'm not trying to defend slop.

I don't think all means-to-end people are just in it for money, I'll use the anecdote of myself. My team is working on a CAD for drug discovery and the goal isn't to just siphon money from people, the goal is legitimately to improve computational modeling of drug interactions with targets.

With that in mind, I care about the quality of the code insofar as it lets me achieve that goal. If I vibe coded a bunch of incoherent garbage into the platform, it would help me ship faster but it would undermine my goal of building this tool since it wouldn't produce reliable or useful models.

I do think there's a huge problem with a subset of means-to-end people just cranking out slop, but it's not fair to categorize everyone in that camp this way ya'know?

The public doesn't care about the code itself, they absolutely care about the quality and experience of using the software.

But you can have an extremely well designed product that functions flawlessly from the perspective of the user, but under the hood it's all spaghetti code.

My point was that consuming software as a user of the product can be quite different from the experience of writing that software.

Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product.

I'd just be careful to separate code elegance from product experience, since they are different. Related? Yeah, sure. But they're not the same thing.

I find most developers fall into one of two camps:

1. You treat your code as a means to an end to make a product for a user.

2. You treat the code itself as your craft, with the product being a vector for your craft.

The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster.

Personally, I fall into the first camp.

No one has ever made a purchasing decision based on how good your code is.

The general public does not care about anything other than the capabilities and limitations of your product. Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively.

With that said, I do have respect for people in the latter camp. But they're generally best fit for projects where that level of craftsmanship is actually useful (think: mission critical software, libraries us other devs depend on, etc).

I just feel like it's hard to talk about this stuff if we're not clear on which types of projects we're talking about.

Some of these really don't make sense. The implication that Cursor is a fraudulent company is a little weird considering they actually have real users.

Like sure, is it a VS code fork with agents stapled to it? Yes. But are they on the same scale as most of the people mentioned? Ehh probably not.

It reads more like a hit piece from someone with a grudge against random SF companies than anything else.

Oh my god, the rust developers are writing tests with Hegelian dialects.

They should consider rebranding to GOATSea

The Drug App - a CAD for drug design.

It's focused on structural analysis right now, but the goal is to allow for biologists, crystallographers, chemists, etc to quickly analyze large samples of structural data for patterns and find where those patterns break down.

Our goal is to make it a platform to analyze the output of various papers, tools, and structures to build a single unified biological model of your druggable target. For example, what if your alphafold output disagrees with pre-existing literature? If Diffdock says your candidate can bind to a pocket on a protein that hasn't been validated yet, what's the implications of that on the underlying biological mechanism?

Biology is extremely complicated, so scientists create simplified lenses of the world to make sense of things. Biologists are looking at different things than crystallographers, crystallographers are looking at different things than computational chemists, etc, etc.

Finding disagreements in these simplified lenses early can save a lot of money before things move to lab experiments.

I really don't think the analysis here is that credible. People aren't leaving existing SaaS for AI agentic platforms like this article implies. Switching costs are too high even outside of tech, the problem runs deeper than that.

Most of these organizations are looking for customizations that B2B SaaS struggles to provide since they have to walk a line of catering to a market segment broadly then building customization for specific clients.

I've seen a huge surge in organizations investing in small software development teams to do internal builds for things that they just aren't getting from these tools. Technology is not the value center for these companies.

I work in healthcare, so my perspective is heavily contextualized by that, but I'm seeing providers (especially specialty providers) build internal engineering teams to create ancillary systems that sit on top of their EHR. They are doing this instead of buying similar modules that might be up sold by the EHR.

Anyway, I just feel like these market trends are deeper than what this article implies.