Sebastian Galonska

So here’s the long and short of it: Rabbit R1 is a $200 piece of hardware (which happens to look cool, because Teenage Engineering is a great design studio) that says “ET phone home” for every action you take. Under the hood, it appears to be a bunch of Playwright scripts. (With the exception of “Play a random song.” This is hard coded to be a Beatles song. Which I find hilarious.) Playwright is dope. You should learn how it works. I’m not throwing shade for using tools that are dope if you’re making a dope product. I just don’t understand how they got like $300M in venture funding to make… a voice-to-text NLP processor that runs a bunch of Playwright scripts and then calls them “apps” or whatever. (A relevant limitation here is going to be the web interface, because if even one button moves, your app breaks. Hence why all the Rabbit apps constantly break.) What did we learn here today? Playwright is useful. Skip the $200 hardware and latency. https://playwright.dev/

29

5 Comments

“Codegen tools are broken.” They churn out boilerplate, need endless fixes, and rarely feel… smart. So when I asked Codebuff to create a browser-based Minecraft game, I wasn’t sure what to expect as I just told it: 👉 “generate a basic minecraft clone that runs in my browser that lets me move around in the world, explore it, and mine blocks. keep going until it's very recognizable as a minecraft game.” And here’s what happened: ✅ Hover effects to show where blocks drop. ✅ Particle effects when blocks are destroyed. ✅ An instruction overlay showing block types. Codebuff uses two agents: 👨‍💻 A Developer agent to write features. 🕵️‍♂️ A Product Manager agent to critique and refine. The best part? The game actually works. We showed a basic version to a dozen people, and each added their own ideas and features to our project. Check out the demo video for the final version. Check out our Substack post for more information: https://lnkd.in/gVFp4H69

17

Yesterday we put out a blog post that I co-authored with Dan Goslen from Vouch Insurance (YC S19). Dan is a staff-level engineer with over a decade of experience, and quite literally wrote the book on code reviews. In this post we discussed what code reviews are, what they should be, and where AI fits in. While our full-codebase-context-aware code review bot is our most popular product, our stance at Greptile continues to emphasize the criticality of human code reviews, and this post goes into great detail on why that is. Tl;dr 👉 Code reviews aren't just QA, they are oppurtunities for mentorship 👉 It is one of the few truly collaborative parts of the software dev lifecycle and should be preserved 👉 Great engineers are "clairvoyant" and can place PRs in context of the teams roadmap quarters ahead, and have critical context of quarters past. Today, this is impossible to replicate. Link in comments for those interested to read more!

63

7 Comments

When there is great uncertainty, there can't be predictability to any useful level. We have to reduce uncertainty to where it can be managed effectively, and we do this by running experiments... trying things. Does the stakeholder like what we've done? Does the customer like what we've done? Are we solving the problem that customers have? This puts us in the 'complex' quadrant of the Cynefin Model, where we have to try and (perhaps) fail, perhaps repeatedly, until we know enough. Yet, we still have a goal in mind and we at least know the first few things that need to get done... or the first thing we need to test to determine feasibility. Apple knew that unless it could source a ruggedized hard drive that would withstand being carried and occasionally dropped, the iPod would not be successful... so getting a commitment from Western Digital (who had been working on such a drive and was almost ready to ship) was the key decision point. The Wright Brothers knew that unless they could figure out a way to turn their airplane without 'skidding' and stalling a wing (a problem that had killed many of their inventive contemporaries) they couldn't build a safe airplane... oh, and find a lightweight, powerful-enough motor while you're at it. It all comes down to reaching decision points: do we know enough to know whether to continue, or whether to cancel our effort? In the example below (waterproofing a below-ground basement), we are going to have to continue. Therefore, we want to continue only at the pace at which we are certain of the decisions we're making. Is what we're doing working? If so, do more! If not, do something else. That is exactly what the contractor did in the post below, making 'MVP' experiments until the path to success was clear, until they had the 'Aha!' moment. So, when do we get predictability with useful accuracy? At the 'Aha!' moment. Figure out what 'Aha!' moments are needed, devise experiments to reach those moments and drive enough uncertainty out (you'll never get to zero) to where the range of uncertainty is acceptable. #predictability #forecasting #estimation #commitment #agile #planning #riskmanagement #projectmanagement

3

3 Comments

AI code tools currently have a middle market problem. If they can solve that I think they'll see another inflection point of uptake. What's the middle market? Currently these tools really deliver the wow factor for either: 👶 Junior or non technical folks who can now build things they previously couldn't. They don't have an alternative to using the tools, and they're not discerning about code quality. They're also OK with building relatively simple apps / products that solve a single problem. 👴 Senior staff engineer / manager level folks. These people bounce around between codebases. Are the ultimate generalists. And are pretty good at understanding and verifying the output of LLMs. They find these tools a useful way to dive into new codebases or languages and remove some of the grunt work. Then there's the folks in the middle. They range from mid to senior, but they generally focus on one or two languages / technologies. They know the language features and APIs off by heart, and when they don't they have their IDE dialled in and configured just right for their stack to fill in the gaps. These folks can find LLMs get in the way a little bit. The code can be verbose and generic. And worst of all hallucinations introduce silly bugs that slow them down. So what do these AI coding tools have to do to take this middle market? - Deeper language integration. I don't know if any are doing it already, but something like RAG to LSP integration. I've had LLMs invent methods on libraries to fix bugs. Rookie stuff. - Better UX. They need to let experienced folks drive most of the time and only help when useful. - Better code quality. This might be helped by chain of thought models like o1. But the cleaner and better quality the code is, the more easily an engineer can understand it, mentally verify it works, and accept it. I think these tools will get there, but I guess one counter is... do they need to? Maybe with non technical folks able to code, and senior generalists able to deliver more: the middle market of specialists will shrink?

22

1 Comment

Agentic Design for LLM pipeline orchestration is changing the way we think about software applications. Leaving LLMs with the agency to make decisions is a real challenge to build robust applications, but we start to understand better what works well and what doesn't! The idea of building planning agents is possibly as old as the idea of AI, and a few basic patterns have emerged in the world of LLM pipelines for agentic planning.    The plan-and-execute paradigm involves a planner and executors and is well adapted to successive tool calls. The idea is that the planner establishes a series of the necessary steps to reach a solution, and the executors execute those steps in sequence. As the executors aggregate the tool observations, the following ones will be able to adjust the specific execution strategy of their respective steps. This process might be a bit blindsided, and we are not allowing for potential adjustments to the plan as we accumulate feedback while solving the problem. We can have a replanner agent specializing in assessing the plan and updating it if necessary. The Plan and Execution pattern often involves using a ReAct agent. This process is sequential, therefore slow, and requires injecting the same data over and over within the different prompts during the iterative process of the ReAct agent. This leads to high latency and high costs due to prompt redundancy. The Plan-Work-Solve pattern consists of establishing the tool calls as part of the plan. The full plan is listed in the initial step, then the tool calls are processed in the following step, without reassessment of the plan, and in the final step, the results from the tool calls are aggregated to provide a final solution to the problem. The tall calls can be made concurrently since they are not dependent on each other. In this paradigm, we need a solver agent that can process the aggregated set of information coming from the tool calls. The plan and Execution paradigm assumes that all the different steps are to be executed sequentially, whereas the Plan-Work-Solve paradigm makes the drastic assumption that all the calls be executed in parallel. With the LLMCompiler paradigm, the planner constructs a graph of the steps by establishing the dependencies for each of the steps. This way, we can plan for the steps that can be processed concurrently, and we can save on latency while keeping accuracy high. Because the execution remains somewhat sequential due to the graphical nature of the nature, it provides more opportunities, as in the Plan and Execute paradigm, for replanning after each tool execution and their feedback. -- 👉 Don't forget to subscribe to my ML newsletter https://lnkd.in/g4iKyRmS --

230

48 Comments

"In solving the specific problem of their function, they had lost sight of the holistic forest through the trees. I've observed companies where the product or design org and the engineering org have their own core model. The models use completely different languages; they don't interact with each other, and no one speaks the same language. They do this because there's a lot of pressure on each org to produce something, and collaborating cross-functionally is difficult. Meanwhile, the business is searching for one simple model to rule them all, which doesn't really exist. As a result, without a viable alternative, the company uses metrics like revenue and NPS (a travesty of statistics and research)." https://lnkd.in/gbk48eS7

35

3 Comments

Junior: "Look at this clever one-liner I wrote!" Mid-level: "I should probably add some comments here." Senior: "Let's refactor this for clarity." Lead: "How can we design this to prevent errors in the first place?" If we write code as cleverly as possible, we're setting ourselves up for debugging nightmares. It's not about writing less code, but about writing code that tells a clear story. Key principles I've learned: 1. Write for humans first, computers second 2. Optimize for readability, then performance 3. Treat comments as an essential feature, not an afterthought 4. Design systems that are hard to use incorrectly Today's clever hack is tomorrow's technical debt. Our job isn't just to solve problems, but to create solutions that stand the test of time and teamwork! #developer #simplicity #coding

204

62 Comments

LLMs can generate endless pages of Product Requirement Documents drivel. They can hallucinate acceptance criteria and write a bazillion Jira tickets. Yet social media isn't full of "OpenAI will come for PO jobs" articles. Why is that?

6

11 Comments

When you quantize down an LLM model, can you maintain its accuracy? I used to think no, but the data says otherwise. For example, Llama 3.1 405B FP16 has an average Accuracy score of 86.63. If you quantize down this model from FP16 to INT4, its Accuracy score falls to 86.47. That’s a recovery ratio of 99.81%. 🔥 🔥 In return, you get 4x more VRAM and higher performance. As people struggle to fit their models onto 8x H100s, a tiny loss in accuracy for 4x more VRAM sounds like a great bargain. Secret sauce seems to be the GPTQ algorithm, combined with neural networks being robust to quantization. Source: Neural Magic's Llama-3.1 70B and 405B INT4 models on Hugging Face. The link's in the comments. #opensource #llama3

35

5 Comments

UCL - Ubiquitous Common Language. I first hear of this term reading Eric Evans's Domain Driven Design... and I fell in love with it. Why, you might ask? Well: I am an advocate of clear and open communication with clients. All the time. Every time. Even if there are problems, the sooner they are addressed, the sooner they can be dealt with and the easier it will be to get the project back on path. But I am a software developer, working in a highly technical industry. How can someone who is in e.g. construction understand the nuances I am talking about? This is where Ubiquitous Common Language comes in: a set of terminology which both client (domain owner) and developer (technology owner) come to agreement about. And then use when designing systems, talking about systems, issues, problems, ideas etc. It is important that, if the developer is modeling a process of e.g. a customer coming to make a payment at the cash register, that both sides are 100% on the same page about what do the words Customer, Payment, Cash Register mean! As precisely as possible. Making this clear upfront, and making an effort to make both sides use these precise terms in discussions on a daily basis will definitely help your project move forward much faster. And will definitely help avoid the "But that is not what I meant" meetings. 😀 #softwaredevelopment

9

4 Comments

Dev agencies, if you don’t want to be treated as a commodity, stop acting like one. - Learn the business context for engineering needs - Stop squeezing your clients every opportunity you get - Prioritize transparency, communication, and accountability In short, position yourself as a partner that uses tech to solve business problems. You really can’t complain about being seen as a commodity if you treat everything as a transaction.

1

1 Comment

You don't need to be an engineer to be a super effective in product management. Many (of the best founder) excel without super deep technical expertise, despite common misconceptions that suggest otherwise The biggest mistake non technical people "assume" is you hand a developer an idea and they magically create the next Facebook. These are the same people who have no idea what a requirement is or who your customers are. what 90% of engineers do is over-engineer. (for engineer purposes like performance, scalability of platform, optimisations and 100's of other things and lastly about customer outcomes) In startups, you have to flip this script and focus 90% of customer outcomes. ^ This is why Startups really need a "senior, amazing" engineering person. (so you don't go down 1000 engineering rabbit holes) The hardest challenge here and Jason Lemkin agree on is finding that super technical, super customer and team focused startup VP of engineering / CTO / Principal level Dev. NO matter the cost ^

2

The best use case for overseas development I've heard: We have customers in the eastern hemisphere. To support those customers better, we're standing up product, dev, and support teams to help serve those customers needs. Two key ingredients in making that successful: commensurate pay and the same level of performance and accountability as US peers. #software #international #teammanagement #overseasdevelopment #startup #leadership #coaching

6

Airtable is great for small teams, but... I love Airtable. I think the price is reasonable for solo users or small teams. It’s also incredibly developer-friendly, making it easy to integrate into custom workflows. (Definitely a step up from Google Sheets.) But here’s the catch: Their pricing model for teams is steep, especially when hundreds (or thousands) of users need access to tables. I haven’t tried it yet, but I came across Undb.io as an open-source alternative. It seems to offer affordable enterprise pricing and is designed to be API-first. Has anyone else had similar thoughts about Airtable’s team pricing? Or maybe you've found other cost-effective solutions?

12

1 Comment

The best LLM so far. I've just tested the new open-source model from Meta Llama 3.1 and here is my review. 1. This model is the smartest available on the market (405b). It answers more high-quality outputs rather than other top competitors. 2. It's really good at coding. It resolved my usual live-codding assignment much better than Claude 3.5 (better, but meh) or Chat GPT 4 (bad enough). I will use Llama for coding and endorse you to try that out. 3. Llama is slower. Slower, but at the same time answers much better. Chat GPT and Claude are hosted on company servers, which is why in their interest to answer quicker even if responses are worth saving the computational resources. Llama is open-source and self-hosted, that's why it can afford to spend more time to think. And I like it more, but the result Llama has a higher price of usage. 4. Llama is open-source. Therefore, you can customize it in whatever you want, and be sure your data is safe, and the code is open. This model reminds me of Linux, and I believe this model is a top contender, and arguably even the best as of 25.07.2024. In the further posts, I will make more deep-dive reviews about this model.

10

6 Comments

This is a really good post. I've often thought that async/await is a truly horrible paradigm to program in. Its hard to reason about the computation model, its hard to debug, its hard to trace, apparently they're all implemented differently and have differing lineages (TIL from this article), and it infects a codebase almost in toto. I also have a sneaking suspicion (although I've never been able to prove it) that programming this way doesn't lead to a speed up over doing more naive concurrency or parallelization techniques. Hopefully in the future this pattern will go away toward concurrency models that are much easier to reason about (like Channels in Go or Actors in Elixir). Even threads might be reasonable as the author suggests, but async/await is bad imo and I'm with him. https://lnkd.in/eu9PPFBV

7

2 Comments

This doesn’t mean coding is dead (sorry, Jensen Huang). Instead, what we are seeing is how deeply polarized the tech market has become in 2024 and how wide the gap is growing. Fewer tech jobs = fewer tech companies hiring. And traditional SaaS companies are at the center of this shift. Because: 1) VC money isn’t flowing like it used to. Historically, most of the VC capital raised by tech startups went to hiring and customer acquisition. Now, with funding rounds slowing, there’s less cash to fuel headcount growth. 2) Growth has stalled. Many SaaS companies are paying the price for their “growth at all costs” phase, especially now that the ZIRP era is over. There's a ton of zombie companies out there—still walking, but essentially dead. Some are going for “life raft” options: selling at lower multiples, turning to private equity, acqui-hires, or raising funds at steeply diluted valuations. And of course, this means no expansion, hiring freezes, or worse—mass layoffs after the 2022 bubble burst. Now, on the other side of the gap is AI, grabbing all the money, headlines, and triple-digit growth. But even within AI, there are two distinct markets. 1) Core AI infrastructure – AI-focused hardware, software, and services. 2) AI-embedded companies – Businesses that natively integrate AI (like LLMs) into their applications. In 2024, every company is calling itself an “AI company,” slapping AI into their apps or pitch decks to ride the hype wave. This approach works for now—they’re raising capital, iterating, and searching for product-market fit. But in 5–10 years? Many of these companies might not be sustainable. Their AI offerings are often easy to replicate, and their competitive edge fades quickly. Moat-less. The good news is, we are starting to see more enterprise spending in the application layer and I think more value is being created. Agentic applications are really moving the needle now. Which is critical - the entire AI movement rests on the future of application builders. AI infrastructure, on the other hand, has more staying power IMO. These companies—especially those working on hardware—are playing the long game. Yes, they’re capital-intensive, but the opportunity is massive. The proverbial diamond mine of AI is far from fully explored. And as history shows, the ones selling the tools to dig the mine will often be the biggest winners. What do you think? Let me know your thoughts. P.S. Great data from Bigdata.com and Linas Beliūnas

7