vipshek

I also agree that qualitatively, this technology seems different than the others. However, I feel that people tend to overly fixate on their internal stochasticity. Even if LLMs' internal mechanism is nondeterministic, shouldn't we be able to verify their "side effects" aren't harmful? Of course, "harm" is subjective and at this scale, the most effective way to verify behavior is probably some kind of LLM-as-judge...

Anyway, in this case the problems have occurred while actually running the evals themselves, so again, we're in a situation where we can't even confidently test these things and know that they won't cause harm in the outside world.

When do we blame the user? When the tool is operating as intended by its creator, and we agree the tool meets certain quality standards and isn't defective.

When do we blame the creator? When the device doesn't meet those quality standards and reasonable use caused harm inadvertently. For example, for consumer devices, certifications like UL/CE are used to define acceptable performance levels and safety standards.

Maybe we need "quality certifications" for AI agents - essentially eval suites that demonstrate those agents won't cause harm under reasonable patterns of usage. Right now, these eval suites are run best-effort by the labs themselves.

The tricky thing is, a lot (all?) of these recent safety incidents have occurred while evaluating these models! This suggests we need much more rigorous standards for how exactly an eval can be run. Perhaps all of them should occur in truly air-gapped environments... though that may run counter to evaluating agents in a realistic way.

Regardless, it feels like the "industry standards" common in, say, electrical engineering and other disciplines are sorely lacking here. Unsurprising given how new these technologies are, but concerning since the blast radius for this technology is likely much larger than other technologies we've encountered in the past, except maybe nuclear technology.

This reminds me of the pedagogical philosophy of Seymour Papert, who was heavily influenced by the ideas of Jean Piaget. Piaget's "genetic epistemology" argues that knowledge and understanding is created by interacting with environments, which traditional educational approaches fail to provide.

Papert combined Piaget's ideas with the emergence of computing to argue that children should be taught subjects in a hands-on, exploratory way - and not just for teaching computing! The idea is that by programming in simplified languages, children can discover ideas in subjects like mathematics and grammar - deriving them as they try to solve problems instead of having them dictated to them.

Suppose that biology was taught in a game-like environment where students were designing cells or organisms in some way. Maybe the game could be structured so that each organelle could be "discovered" by the student as they designed the cell to survive in some environment. Perhaps that'd make the purpose of each cell component more grounded and memorable.

Papert's book Mindstorms covers all this in detail, and I highly recommend reading it. I feel like it's especially important today given fears of how AI will affect childhood education. At best, I hope that computing can be a boon to education instead of a detriment if it's woven into pedagogy thoughtfully.

For (1), the main value I'd see is in mentoring junior engineers or less technical contributors on a team. If someone puts up a PR with sloppy results, you could actually jump into the thread that produced that PR and see how the results came about, or even coach that contributor on how to do better next time. Also might make it easier to hand off work from one person to another - right now most coding agent sessions are user-local.

On (2), I frequently find myself consuming agents' gigantic text responses and tediously writing 8-bullet-point responses to guide them. It's pretty exhausting. I could see inline comments providing much better ergonomics.

All that being said, Zed has largely fallen out of the conversation for "agentic coding tools", and so this feels like their attempt at creating something like the Cursor Agents Window, Codex, or Claude Code. These two features seem compelling, and I understand they're even compatible with other coding harnesses. But I don't know if there's enough there to have a defensible product; if these features are excellent, others will clone them eventually.

Regardless, would love to give this a shot!

Feels a bit ironic... though this website is hosted on Cloudflare Workers so using an American company anyway?

Seems like your approach is a bit more "batteries-included" but I'd curious for your thoughts on the differences.

Been tinkering on this Olmsted-inspired map of all the trees in NYC for a long time - just added some more features (seasonal colors and better search/filtering) recently.

If you're in NYC, try finding some cherry blossoms near you: https://exploretrees.nyc/?species=cherry

As an engineer who's full-stack and has frequently ended up doing product management, I think the main value I provide organizations is the ability to think holistically, from a product's core abstractions (the literal database schema), to how those are surfaced and interacted with by users, to how those are talked about by sales or marketing.

Clear and consistent thinking across these dimensions is what makes some products "mysteriously" outperform others in the long run.

Not sure if you’re being figurative, but if what you wrote in your first comment is indicative of the tone with which you prompt the LLM, then I’m not surprised you get terrible results. Swearing at the model doesn’t help it produce better code. The model isn’t going to be intimidated by you or worried about losing their job—which I bet your junior engineers are.

Ultimately, prompting LLMs is simply a matter of writing well. Some people seem to write prompts like flippant Slack messages, expecting the LLM to somehow have a dialogue with you to clarify your poorly-framed, half-assed requirement statements. That’s just not how they work. Specify what you actually want and they can execute on that. Why do you expect the LLM to read your mind and know the shape of nginx logs vs nginx-ingress logs? Why not provide an example in the prompt?

It’s odd—I go out of my way to “treat” the LLMs with respect, and find myself feeling an emotional reaction when others write to them with lots of negativity. Not sure what to make of that.

This comment is like saying, “This diet didn’t work for me” without providing any details about your health circumstances. What’s your weight? Age? Level of activity?

In this context: What language are you working in? What frameworks are you using? What’s the nature of your project? How legacy is your codebase? How big is the codebase?

If we all outline these factors plus our experiences with these tools, then perhaps we can collectively learn about the circumstances when they work or don’t work. And then maybe we can make them better for the circumstances where they’re currently weak.

Meridian develops software to accelerate the next generation of companies building in the physical world across aerospace, defense, automotive, robotics, and more. We automate the administrative work of quality and compliance to help our customers go to market faster, scale their production, and increase their pace of innovation.

Meridian is 3 months old. We’ve already signed paying customers, built and launched our product, and raised an oversubscribed pre-seed round.

For our three first hires, we’re looking for world-class generalist engineers who can ship great product experiences fast while laying the foundations for a platform that will scale to large and complex enterprises in the future. We're offering competitive salaries and above-market equity.

We're building an in-person engineering team that prides itself on shipping excellent products for a user segment (quality engineers in manufacturing) that's been sorely neglected in the past. We ship with speed and quality, own a large product surface area, and are relentlessly customer-focused.

To apply, send us your resume and anything else you’d like to [email protected].

I think the utility of generating vectors is far, far greater than all the raster generation that's been a big focus thus far (DALL-E, Midjourney, etc). Those efforts have been incredibly impressive, of course, but raster outputs are so much more difficult to work with. You're forced to "upscale" or "inpaint" the rasters using subsequent generative AI calls to actually iterate towards something useful.

By contrast, generated vectors are inherently scalable and easy to edit. These outputs in particular seem to be low-complexity, with each shape composed of as few points as possible. This is a boon for "human-in-the-loop" editing experiences.

When it comes to generative visuals, creating simplified representations is much harder (and, IMO, more valuable) than creating highly intricate, messy representations.

1. You can configure which LLMs you want to use, whereas Copilot just supports OpenAI models. I just use Claude 3.5 for everything.

2. Chatting with the LLM can produce file edits that you can directly apply to your files. Cursor's experimental "Composer" UI lets you prompt to make changes to multiple files, and then you can apply all the changes with one click. This is way more powerful than just tab-complete or a chat interface. For example, I can prompt something like "Factor out the selected code into a new file" and it does everything properly.

3. Cursor lets you tune what's in LLM context much more precisely. You can @-mention specific files or folders, attach images, etc.

Note I have no affiliation whatsoever with Cursor, I've just really enjoyed using it. If you're interested, I wrote a blog post about my switch to Cursor here: https://www.vipshek.com/blog/cursor. My specific setup tips are at the bottom of that post.

All that being said, it's very possible to prompt these generators to create images in a particular style. I usually include "flat vector art" in image generation prompts to get something less photorealistic that I've found is closer to the style I want when generating images.

If you really want to go down the rabbit hole, click through the styles on this Stable Diffusion model to see the range that's possible with finetuning (the tags like "Watercolor Anime" above the images): https://civitai.com/models/264290/styles-for-pony-diffusion-...

The core cultural values seemed reasonable to me, but the efforts to scale the culture felt heavyhanded and seemed like they sometimes backfired. Attempting to quantify someone's "believability" based on subjective data collected on an iPad app was a bit silly and easily gameable. The fact that Dalio and other executives scored highest on basically every facet was an obvious sign that the system was a bit farcical.

Maybe the company managed to solve some of those cultural scaling challenges after 2013? I wasn't around to see what happened after.

I think all the other comments saying "read a lot" and "talk to everyone" are correct first steps, but for me, consuming information has diminishing returns after a short while. After you've reached a point where your brain feels like it's exploding, you should switch your focus to outputting information.

If you're a "write things down" person, then write a synthesized document explaining everything you've learned, and then ask a few trusted coworkers to tear it apart.

If you're a "talk out loud" person, schedule time with coworkers to have a "teachback session" where you give a presentation about everything you've learned. Again, ask them to tear it apart.

It's crucial to build trust with a few coworkers who are willing to critique your output. Get them to rip everything you've created to shreds. Whenever you write or say something that's even slightly off compared to how someone in the industry would say it, make sure you learn about that, and learn how someone in the industry would say it.

This focus on getting the language right - especially the colloquial language of how people actually describe things day-to-day - is important for every role, but I assume it's especially important in marketing, where you need to be able to use the precise language that your customers use.

tl;dr: Read/talk to people at first, but switch to writing/presenting ASAP. Solicit and internalize as much critical feedback as you possibly can.