11,395 karma · joined March 8, 2014
My career has mostly been at the intersection of hardware and software (including a couple of years designing FPGA gateware) and focused on designing and developing correct, performant systems, but I've been paid to do everything from PCB design to React frontends.
I also have an interest in improving clinical trials for novel therapeutics.
email: jeffreyrogers27@gmail.com
Both books are largely about how the psychological defense mechanisms a person uses play a large role in determining how successfully they adapt to and navigate life.
So are humans. Every codebase I've worked on has duplicated code that has been written in slightly different (but hopefully equivalent) ways, often by the same person.
We're in the very early stages of LLM driven programming, so it's hard to say how it will all shake out, but my anecdotal experience is that LLM written software is very reliable and easy to extend and develop. I have a side project that is about 90% LLM generated code (about 25k lines of production code and a similar amount of test code). This is a revenue generating product and I've had no issues with reliability, security, or performance.
For what it's worth this app is a rails app and I have no plans to switch to anything else. Rails works nicely, the LLMs extend it easily, and almost everything is I/O bound so I don't need C++/Rust level performance.
I run a small business on the side, and although I did a ton of preparatory reading and learning not much of it was useful in retrospect. Most of it you learn by doing and it's not that hard to learn. The top three things that were useful to me to learn were sales, basic accounting and how to read financial statements, and what metrics to track/manage with. You can learn the basics for all of those in less than a month.
My advice is just start. You are probably wrong about what the market wants unless you are selling a product or service that you know there is already demand for. Figure out what it is you're offering and try selling it to people. If they want it you figure out how to make it better, if they don't you try something else.
Edit: I had wanted to start a business for a long time. I thought I needed some tricky new idea to be successful. That's really hard to come up with since most new ideas are bad or are too hard to sell/explain to people. In my case it was also a form of procrastination since I had to wait for the right idea. Things got easier when I just picked an existing problem/industry and decided to do that with my own proprietary software to make it easier for me. I know a guy making a couple million a year from owning multiple tanning salons. There's a lot of opportunity out there that doesn't require any special insight.
YC's founders also skew heavily towards a certain type of person and business. The returns of VC in biotech for example are much lower than the returns in B2C and B2B software. It's just a harder, more capital intensive, and more uncertain industry. Over optimizing for the YC archetype means you get less of the people who succeed in other areas.
Also, although PG disdains finance and management, many large problems are better addressed through people with skills in these areas IMO, since often the returns are not sufficient to attract VC interest but the financial and human resources that need to be coordinated to address them are substantially beyond the ability of a small, undercapitalized group.
I think companies will get better at measuring the impact of AI and attributing it to increasing profit or decreasing costs, and that the companies that are better at this will have an advantage over those that are worse, so eventually overall efficiency will improve.
I have worked on other projects where flaky tests are a problem (and generally cause developers to ignore and submit anyways), but so far I've avoided that. My experience with flaky tests is that they're typically due to poor modularity or to subsystems that other teams can modify. This project exists in a monorepo and I'm the sole developer so that's not a problem here.
I still think of what I'm doing as software engineering, and I'm glad that I had many years of professional and hobby development before using agents since I think that's given me the ability to make good architectural decisions (and helps me resteer the LLMs when they want to do something suboptimal), but my involvement in actually writing code is quickly going to zero. That said, they aren't perfect and they still introduce bugs, but I believe the quality of my current product is higher than what I would have created pre-agentic coding.
Things I've found helpful in keeping quality high:
- Visual regression tests (detect UI bugs before you commit them)
- Fuzz testing of interfaces and app behavior
- Automatically add regression tests for any bug that I/the LLM fixes
- Logging/alerting that tracks an errors/invariant violations triggered in the app
- Performance metrics that are surfaced in a dashboard.
All of these are very easy to add since the LLM can create this infrastructure for you. The fuzz testing in particular is something very few products I've previously worked on have since most people don't know how to implement it. I ran the fuzzers for a few minutes and they quickly caught multiple subtle bugs that I was not aware of.
This is a real product that helps a real, non-VC funded service business, and although I could have made something similar myself it would have taken me a lot longer, be harder to use, and probably be less reliable.
Edit: while it's true that you can quickly blow through the $20/month plan, the $200/month plan allows you to get a lot done and is basically sufficient for my needs. It's also very cheap when you consider what it would cost to pay someone to do similar work.
He has dozens of high signal claims in his prediction blog posts. Picking out one of the ones he got wrong doesn't tell you much. Overall his track record is pretty good. Definitely better calibrated than most people, especially the very anti and very pro LLM people.