I'm doing a similar thing (not could security though), similar thoughts try to surface.
If you're trying to build a business, only a small part of it is about generating code. Sticking with it and developing a good product is where you make the difference. I've built many things in a couple of weeks of coding, but then given up when faced with the hard work of making it a solid business.
My other thought is.. There are always others coding faster than me, writing better web copy, doing sales more successfully, etc. You/we pick AI as a threat because we understand it, but a good sales person is just as much of a threat to your idea.
We all have technical/skills advantages and disadvantages. In the successful startups I worked in these were not that important in the end. It was just about keeping going, every day. Relentless optimisim that you're right.
When I first started in dev, on a Unix OS, we did 'waterfall' (though we just called it releasing software, thirty years ago). We did a a major release every year, minor releases every three months, and patches as and when. All this software was sent to customers on mag tapes, by courier. Minor releases were generally new features.
Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed.
The difference between agile and waterfall only really matters at the start of a project. Once it is deployed/released/in-use, the two approaches converge, more or less.
This is interesting, thanks for posting. I've been searching for some sort of 'real' usage of AI-coding. I'm a skeptic of the current state of things, so it's useful to see real code.
I know Python, but have been coding in Go for the last few years. So I'm thinking how I'd implement this in Go.
There's a lot of code there. Do you think it's a lot, or it doesn't matter? It seems reasonably clear though, easy to understand.
I'd have expected better documentation/in-line comments. Is that something that you did/didn't specify?
"and your mental effort can shift from managing low-level details to clearly expressing your intent."
I really struggle to understand what people are doing that makes these two things mutually exclusive. Unless the catchment group is people who can't code or understand software engineering. Which is fine. It reminds me a lot of the no-code hype.
I wonder if ai-coding will turn out a bit like ultra processed food. Cheap to produce something that looks like it does the job, but actually is quite bad for consumers.
I don't see anyone producing objective measures on the improved apps. Like bugs per lines if code, feature development time, etc.
I did look at modifying the merge commit message, but I couldn't figure out how to accurately detect a merge commit.
Having re-looked, I just found 'git rev-parse --verify MERGE_HEAD' which may help here. Time to do some testing. It would be good to clean up and standardise the commit msg itself too. Thanks.
The prepare-commit-msg hook is the one. One of the hook args is the type of commit (merge, squash, etc). And the merge commit msg files exist (SQUASH_MSG, MERGE_MSG) so my original logic all works.
$ git log -1
commit 735ce5f9998736c4066d63ab851df2023640dad5 (HEAD -> master)
Author: Doug Bridgens <thisdougb@users.noreply.github.com>
Date: Tue Apr 1 22:31:22 2025 +0100
test4 does some stuff
Time spent on feat_test4: 0d:0h:7m secs=426
I'm trying to workout how it (the idea) can be ported to work with GitHub pull requests. But I don't know enough about what's happening under the hood with GitHub during the PR process.
I moved from GitHub to self-hosted gitolite. I use a (standard) Makefile in each repo, which my deploy job runs (make test, make build, etc). I use githooks to do various automation.
It's really not that much different to GH Actions, and not more work. But it's much faster, and easier to work with.
If you're working in a team, then PRs are hard to replace.
My company is looking into a move from GitLab to https://forgejo.org (Codeberg, essentially). Seems way easier to self host. Seems fine so much for all my team's needs.
Yeah, we've been using gitea for five years, and from administrator's point of view it's one of the easiest things to self host. Updates can happen automatically and require very little downtime, and it's light on server resources.
In comparison, Gitlab was a massive pain and became close to unusable on that same server before we migrated to gitea, even though Gitlab was used just for code hosting, and gitea is used for everything it supports (container image and package repositories, issues, etc).
On my first team in 2011 we used Phabricator before the company sprung for github enterprise. Phabricator was fine; you could even just copy/paste the output of `git diff` into a form on the UI as an alternative to pushing to a monitored branch.
For code review and merge workflow gerrit used to be good a decade ago, it's probably good today, too. Github PRs are strictly worse today than what I remember from gerrit back then.
Gerrit is great if your team is willing to work in a rebase based workflow!
We handled huge repos on Gerrit (and a huge number of them) at my previous employer with very few problems. It does take a certain effort to self-host it, but then what doesn't.
what advantage does gitlolite over gitea? If i wanted to replace GitHub my intuition would be to replace it with gitea. It seems to have similar interface, pull requests, workers etc to gh.
Gitolite is a bare bones git server. Gitea is a forge. They’re not remotely in the same class of software. Gitolite doesn’t even have a web view for the repos, you need a separate package like cgit for that; never mind project management features.
I've been trying for a few years to get a SaaS type thing launched.
The first few attempts were with other people, because that's what all the advice tells you. These all petered out because my driving purpose didn't match the other person, which only came to light when things got serious. Nothing acrimonious, just a total loss of motivation on both sides as we implicitly pulled in different directions.
Now I've been trying solo. It's hard, doing everything. But also easier. For me the motivation to keep going is the hard part. I did an iOS app which got lost in the sea of apps, then a more SaaS-like app inside Strava which ended when Strava changed their terms. In both cases I could/should have continued, but motivation was gone.
In the last few weeks I've built and released a free-tier dev tool. Now building the paid-for versions while also trying to build awareness and get people using it. I've really shrunk down the product scope, which has helped stay motivated/focused. I've built something with a target audience of my own industry. Most importantly (for me) is that I've become more aware of motivation drains (individuals, websites, doom-scrolling, the news, lack of exercise, etc), and more pro-active at avoiding them. It's going better this time around.
What I've learned so far:
- look outside tech for inspiring people who've built products (every independent hair salon, baker, accountant, etc already did it). Tech is not special, in many ways it's risk-free. I found the How I Built This and CoRecursive podcasts useful to maintain perspective, and have some down time with my inspiration.
- just start. Don't treat the first thing as 'the one' (I sort of do every time, and it's a mistake I'm trying to correct), because it's too much pressure. I'm still discovering things about my approach to this that I will fix in the next attempt.
- I tried the side-hustle thing. But I like to do a good job, so I was using my energy for the people paying me. I couldn't, in good conscience, work on my thing on someone else's dime. That's just me, but it meant I never had the energy to work on my stuff at night. Now I've blocked out the next six months for the SaaS product I'm doing (I’m a freelance/contractor).
- coding is the easy part. Sticking to your vision/purpose/core-product is harder, because everyone else seems to be faster/smarter/pivoter/experter. Mostly I found the cliches don’t work until you learn them by experience (so just start).
- managing time/work. Much of the time I need to spend is thinking, simplifying, or reading/writing, with coding being about 10%. I queue up non-coding tasks to be done ‘anywhere’, so train journeys, cafes, lunch, your notice period. Maintaining momentum is easier if you’ve a lightweight management tool. I use Things3, because its iOS home-screen widget shows my current checklist and I can see progress.
- motivation has been my achilles heel every time, particularly as a solo. There is some cliche or other about this, which of course I’ve known and understood forever. But the previous experiences have been like practical training, making my motivation more robust. Each time I’ve found extra places to patch up my soul to prevent motivation leaks and recognise gumption traps.
If you want inspiration from someone who did something without an expert coding career, lookup the podcasts/interviews with the StoryGraph founder (Nadia Odunayo). There are countless other examples of paths to building a SaaS product, if you have a look.
If you're trying to build a business, only a small part of it is about generating code. Sticking with it and developing a good product is where you make the difference. I've built many things in a couple of weeks of coding, but then given up when faced with the hard work of making it a solid business.
My other thought is.. There are always others coding faster than me, writing better web copy, doing sales more successfully, etc. You/we pick AI as a threat because we understand it, but a good sales person is just as much of a threat to your idea.
We all have technical/skills advantages and disadvantages. In the successful startups I worked in these were not that important in the end. It was just about keeping going, every day. Relentless optimisim that you're right.
reply