Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes.

With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax. Apparently the Rust compiler isn't a speed daemon either. But tests are something that's under your control. Unit tests should be done in seconds/milliseconds. Integration tests are where you can make huge gains if you are a bit smart.

Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system.

The fix for this is 1) allow no cleanup between tests 2) randomize data so there are no test collisions between tests and 3) use multiple threads/processes to run your tests to 1 database that is provisioned before the tests and deleted after all tests.

I have a fast mac book pro that runs our hundreds of spring integration tests (proper end to end API tests with redis, db, elasticsearch and no fakes/stubs) in under 40 seconds. It kind of doubles as a robustness and performance test. It's fast enough that I have codex just trigger that on principle after every change it makes.

There's a bit more to it of course (e.g. polling rather than sleeping for assertions, using timeouts on things that are eventually happening, etc.). But once you have set this up once, you'll never want to deal with sequentially running integration tests again. Having to run those over and over again just sucks the joy out of life.

And with agentic coding tools having fast feedback loops is more critical than ever.

Mostly works for me. Most of my projects I have some guardrails for what to do around testing, deploying, etc. Seems to work. You are right that LLMs are good at avoiding work and finding loopholes to do so. But generally if you ask codex to "hey look at my gh prs and label the ones that don't meet the contributor guidelines with 'slop'" it might do a decent enough job. Maybe add a skill that spells out criteria. Maybe set up openclaw or similar to do this every morning and then give you the list of prs it will auto close after you say the word.

You can do a lot of work with agents to remove a lot of manual work around the sales process. Sales is a lot of grinding on leads, contacts, follow ups, etc. And a lot of that is preparation work (background research, figuring out who to talk to, who the customer is, etc.), making sure follow ups are scheduled appropriately, etc.

You still should talk to people yourself and be very careful with communicating AI slop, cold outreach and other things that piss off more people than they get into your funnel. But a lot of stuff around this can be automated or at least supported by LLMs.

Most of the success with sales is actually having something that people want to buy. That sounds easy. But it's actually the hardest part of selling software. Getting there is a bit of a journey.

I've built a lot of stuff that did not sell well. These are hard earned lessons. I see a lot of startups fall into this trap. You can waste years on product development and many people do. Until it starts selling, it won't matter. Sales is not a person you hire to do it for you: you have to be able to sell it yourself. If you can't, nobody else will be able to either. Founder sales is crucial. Step back from that once it runs smoothly, not before.

Use AI to your advantage here. We use it for almost everything. SEO, wording stuff on our website, competitor analysis, staying on top of our funnel, analyzing and sharpening our pitches, preparing responses to customer questions and demands, criticizing and roasting our own pitches and ideas, etc. Confirmation bias is going to your biggest blindspot. And we also use LLMs to work on the actual product. This stuff is a lot of work. If you can afford a ten person team to work on this, great. But many startups have to prove themselves before the funding for that happens. And when it does, hiring lots of people isn't necessarily a good allocation of resources given you can automate a lot of it now. I'd recommend to hire fewer but better people.

Good decision. The two extremes of this decision are both bad. On one hand the status quo of a lot of slop demanding attention from busy people is just not sustainable and something has to change. But throwing out the baby with the bath water by just blanket banning all forms of AI contributions is not a long term sustainable solution. It's a stop gap solution at best. And one that would be challenged more and more as inevitably tools keep on getting better and more widely used. It's not going to take years even. Deciding to not decide right now gives people some time to think and reflect.

The right way might be to fight AI slop with AI enforced guard rails. It's not actually that hard to implement technically. You can literally just put some markdown skills in your repository and periodically have an AI bot apply the review PR skill to incoming PRs to pre-screen them and automatically close PRs that obviously fall short of well documented criteria, and label & prioritize remaining ones.

Open claw might be a bridge too far for some at this point but it's maybe a glimpse of a future where we have AI bots filtering, screening and funneling inbound information. If you are a bit handy, you can just unleash codex or code claude on your issue tracker and pull requests right now. Worth experimenting with at a small scale.

Criteria could include doing a quick code review. Is the code appropriate and minimal? Does it meet all the documented criteria? Does it fix something that is worth fixing? Does it need further review? AIs can do all sorts of things with PRs ranging from commenting to closing the PR, prioritizing it, commenting on them, or flagging it for escalation to the right person in the team. By the time a real person chooses to spend time on a PR it should have already passed a lot of quality gates and be in a decent enough shape.

A second innovation here could be doing more with reputation. Github users build up reputation by virtue of all the contributions they make over time to all sorts of projects. Also, git allows people to sign their commits. That allows AI gate keepers to sort incoming contributions by reputation. Maybe be lenient towards known repeat contributors. Give the benefit of the doubt to new contributors but scrutinize them more and be very strict on everybody else by default. In a meritocracy, you build reputation by consistently doing good work. Dumping a lot of AI slop on somebody's desk would be the opposite.

Just some thoughts. I have a few smaller github projects but I'm so far not burdened by a lot of low quality PRs.