Application Development as a Software Company | Founder @ https://xitter.cf/t.co/ByOyJNYoii | Co-Founder @ Tokenome AI | Founder/CEO @ SWIRL
Boston, MA
Joined September 2008
- Tweets12.7K
- Following390
- Followers2K
- Likes7.2K
Pinned Tweet
In 1801 Eli Whitney assembled muskets from a pile of interchangeable parts in front of Congress, and became famous for it. The demonstration was staged; the parts were hand fitted and secretly marked...
Real interchangeability took another forty years.
Software factories are not a 2024 idea. People have been trying to build them since 1968, and why those attempts failed is more useful than why we think this one will work.
On Thursday, October 15 at 1 pm EST, I'll be giving a talk about Conjure.work: a software factory in production, powered by fleets of AI agents that design, build and test real software, directed by senior engineers, with a person accountable at three fixed points.
This is a working session on what actually holds it together, and it is not the agents.
The talk will cover:
* Why the old discipline still works and is harder to apply. Work breakdown structures, RACI, retrospectives: none of it stopped being useful because the workers became agents.
* Why narrowing what an agent is responsible for buys more reliability than making it smarter.
* Why speed without proof is not leverage, and what that demands of CI/CD.
* Where the human has to stand. Toyota gave every worker on the line a cord that stops it, and the line got faster. That remains the best answer anyone has found.
* What a feedback loop looks like when your users' own words decide what gets built next.
* Where this goes next, including the research question nobody has answered: how little human oversight is enough, and where in the pipeline it has to sit.
The talk will be 30 minutes with 15 for questions. Free + Virtual. Link to register in the comments. I hope you'll join us!
Starting in 30 minutes!! Register: luma.com/15qeiow8
Don't miss John O'Neil's demo/talk of Tokenome AI on Thursday as part of Boston AI Week !!
Register: luma.com/15qeiow8
Git blame tells you who changed a line. It cannot tell you why.
Tokenome indexes your AI conversations on your own machine and links every line of code to the conversation that produced it.
At this talk Tokenome’s creator + founder will install it live and use it on a real codebase showing line to conversation, the reason behind a reversal, the daily journal, and a coding agent that looks up its own history over MCP.
A rank 1 from one system and a 0.63 from another mean nothing to each other. A federated result list is six lists stapled together, unless something puts them on one scale.
SWIRL reads the query and every result together, scores them on one scale, re-scores the top results for confidence, groups duplicates and versions, and puts the approved version on top.
Then, and only then, does it generate the answer.
The whole journey, step by step: swirlaiconnect.com/ranking
Connector is a misnomer here.
According to my analysis, Claude Duet is live querying, not ingesting. It's using MCP.
Ingestion is not necessary to generate insight. Period. And here's the proof...
Claude Duet flips the default: the AI messages you first. Own cloud computer, finished work back, asks before it pays or sends anything. 6,000+ connectors. Assistants that start the conversation. claude.com/product/claude-du…
Sid Probstein retweeted
I highly recommend cloudflare's security audit skill: github.com/cloudflare/securi…
Run it on all your software. Run it with the free models. Use it even if you used a model to audit something - it will find much more things. Works in all agent harnesses and is model independent.
A transcript corpus is the most sensitive text a developer owns. Tokenome keeps it exactly where it already is.
It holds your architecture, your half-formed ideas and the odd pasted secret. So the first question is not what Tokenome does, it is where the text goes. The answer is what is inside the download:
* The index and the search engine, running against a directory in your home folder.
* The embedding model, which runs on your own hardware with no GPU, so no text is ever sent anywhere to be embedded.
* The journal, written locally. The default writer needs no model at all.
* No account, no sign-up, no licence check. The product does not know who you are.
The one connection the desktop app makes on its own is an update check against the public releases page, with no conversation data in it. Only if you switch them on: the Claude Desktop source, which fetches your own conversations from claude.ai with your own session key, and Team, which shares only projects you opt in.
The local service needs a token file only you can read, so another process on your machine cannot read your history over localhost. Tokenome adds no encryption beyond file permissions, so keep full-disk encryption on. To remove it all, delete the app and ~/.tokenome; your original transcripts are untouched.
Nothing leaves your machine. No account. No cloud embeddings. That is the architecture, not a policy we ask you to trust.
hashtag#LocalFirst hashtag#DeveloperTools hashtag#Privacy
Try it: tokenome.ai
* Install the signed macOS or Linux build, from the site
* CLI:
uv tool install tokenome-ai
* in Claude Code:
/plugin marketplace add tokenome/releases
Don't miss John O'Neil's demo/talk of Tokenome AI on Thursday as part of Boston AI Week !!
Register: luma.com/15qeiow8
Git blame tells you who changed a line. It cannot tell you why.
Tokenome indexes your AI conversations on your own machine and links every line of code to the conversation that produced it.
At this talk Tokenome’s creator + founder will install it live and use it on a real codebase showing line to conversation, the reason behind a reversal, the daily journal, and a coding agent that looks up its own history over MCP.
Don't miss John O'Neil's demo/talk of Tokenome AI on Thursday as part of Boston AI Week !!
Register: luma.com/15qeiow8
Git blame tells you who changed a line. It cannot tell you why. Tokenome indexes your AI conversations on your own machine and links every line of code to the conversation that produced it. At this talk Tokenome’s creator + founder will install it live and use it on a real codebase showing line to conversation, the reason behind a reversal, the daily journal, and a coding agent that looks up its own history over MCP.
Once a day, Tokenome writes down what you decided and why. Every reason quotes the sentence it came from.
You get a decision record that nobody has to maintain.
If a claim cannot be quoted, it is not written down. That one rule is what makes the record safe to lean on: every line can be checked against the words that produced it.
How it works:
1. Tokenome reads the day's conversations from Claude Code, Claude Desktop, ChatGPT and Gemini, on your machine.
2. It pulls out the decisions and the reason given for each.
3. Under each reason sits the sentence it came from and the turn it was said in. Open it and read the original.
4. A decision that was later undone is marked as a reversal.
5. Entries are plain markdown on disk, so you can read them, grep them and keep them.
Weeks later, "why did we do that?" has an answer with a receipt. Ask in the web UI, or let your agent pull the last few days over MCP instead of asking you to explain it again.
Here is the kind of sentence it keeps, from our sample project: "kept the ledger.post metric inside post_entry, so it fires once per posting instead of once per attempt." A vague summary cannot be quoted, so it does not make the record.
Already have months of conversations? tokenome journal --backfill writes the entries for days that have none yet.
The journal is in the free tier, on one machine. No account, nothing leaves your laptop. acme-payments is sample data made up for demos; the software is real.
Try it: tokenome.ai
* Install the signed macOS or Linux build, from the site
* CLI:
uv tool install tokenome-ai
* in Claude Code:
/plugin marketplace add tokenome/releases
Most AI search builds an index of your documents and a copy of your permissions, then tries to keep both in sync.
SWIRL does neither!!
Every search runs live, as the signed-in user, and the system that holds the document decides who sees it. Delete at the source and it is gone.
There is no second copy to secure, subpoena or purge!
The security and architecture page: swirlaiconnect.com/under-the…
Sid Probstein retweeted
The biggest misread of anyone predicting the end of software engineering was imagining that the world only needed a certain amount of software, and bringing automation to the field would reduce the need for labor.
Exactly the opposite is happening where essentially most things are actually turning into software. Because agents can use tools, work with computers, write software on the fly, and process data like humans (but far faster), we can now throw “software” at problems that never could reasonably be digitized before.
What that leads to is the role of engineering taking on greater importance in the economy, because we can now engineer far more systems and processes than were possible before.
If you’re a bank trying to do new forms of trading, engineers are often your first bet. If you are in life sciences, you expect more and more research and lab work to be engineering centric. If you’re in manufacturing, you’re trying to automate more of the supply chain, all that is engineering. More and more work is shaped like software problems.
Yes we’re not going to be coding manually in the future. But almost everything will be code, which means those that understand it are in a fantastic position.
Some observations about the "total" automation of software engineering:
1. There are more software engineers now than in 2025, and demand is growing.
2. Software engineers have never worked harder than they do now.
3. They largely don't write code anymore, agents write ~100% of the code.
4. The bottom line of the companies that employs these engineers and agents (i.e. the terminal purpose of all this code) is typically not budging as a result of AI adoption.
This is why you have to think in terms of systems. Automating one aspect of a system creates its own friction and moves the bottlenecks elsewhere.
Sid Probstein retweeted
Yes. Undo without the basis is just a mystery in the log. Keep the reason next to the change and an agent can learn from the reversal instead of guessing.
Git can tell you a change was undone. It cannot tell you why.
Tokenome shows the decision, the reversal that followed it, and the conversation each one came from.
An example from our sample project. A cache goes in; the conversation says lookups dominate p95 latency and accounts almost never change. Days later a tenant migration sends two postings to the old account, and the cache comes back out.
Git has two commits, "Cache tenant account lookups" and "Go back to direct account lookups". Neither says why.
Tokenome has the sentence that ended it: "Account lookups went back to direct reads, because a stale account misroutes money and the latency win is not worth that."
So the next person who sees slow lookups does not re-propose the cache and repeat the week. They see it was tried and why it came out.
How it works:
1. The daily journal writes down decisions, each reason quoted.
2. When a conversation states a reversal and gives the reason, that record is marked as reversed, and the earlier answer stays visible instead of being overwritten.
3. Ask in the journal, "why did we go back to direct account lookups", or let your coding agent call why_was over MCP. You get the decision and the reversal together, each linked to its conversation.
It only writes down what someone said. A revert nobody explained has nothing to quote, so it stays out of the record.
Local, no account, free on one machine. acme-payments is sample data made up for demos; the software is real.
Try it: tokenome.ai
* Install the signed macOS or Linux build, from the site
* CLI:
uv tool install tokenome-ai
* in Claude Code:
/plugin marketplace add tokenome/releases
Sid Probstein retweeted
Every week someone tells me they vibe-coded their app over the weekend and don't need developers anymore.
Before it touches a paying customer, make sure it includes:
> a schema someone designed, instead of one the AI improvised table by table
> login that still works when someone puts a plus sign in their email
> password reset links that expire and work once
> MFA, plus a recovery path for the user who lost their phone
> sessions that time out, and a way to kill every session for one user
> SSO for the enterprise customer who won't sign without it
> SAML, because that customer's IT team doesn't do magic links
> SCIM, so a fired employee loses access the moment IT offboards them
> roles and permissions deeper than "admin" and "everyone else"
> checks that stop user A from reading user B's data by changing one number in the URL
> tenant isolation, so one customer's bug never shows another customer's records
> an admin "log in as this user" button for support, with an audit trail on every use
> rate limits on login, so nobody can guess passwords at scale
> lockouts that stop attackers without locking out your CFO the night before the board meeting
> database migrations that run forward and roll back
> migrations that don't lock the main table at 2pm on a Tuesday
> indexes, because the query that was instant on 50 test rows times out on 5 million real ones
> connection pooling, so a traffic spike doesn't exhaust the database
> backups every night
> a restore from those backups, tested, because a backup you've never restored is a hope
> point-in-time recovery for the day someone runs a delete without a where clause
> soft deletes, so "I deleted it by accident" is a support ticket and not an incident
> validation on the server, not just in the form
> timezones stored right, so the 9am reminder doesn't fire at 4am
> the customer with an apostrophe in their last name
> emoji, accents and right-to-left text in every field
> money stored as integers, because 0.1 + 0.2 doesn't equal 0.3 in floating point
> currency, rounding and tax rules for every country you sell into
> a data model that survives your second customer asking for "one small change"
> idempotency keys, so a retried payment doesn't charge the card twice
> deduplication for the user who clicks submit four times
> pagination that still works on page 400
> exports, because sooner or later every customer wants their data in a spreadsheet
> imports that survive the CSV someone saved in 2009
> retention rules, and code that deletes what your contract says you'll delete
> secrets out of the code, out of the repo and out of the AI chat history
> rotating every key the AI pasted into a config file last month
> confirming every package the AI installed exists and is the one you meant
> dependency scanning, because the AI pulled in libraries nobody reviewed
> input sanitization everywhere a user can type
> protection against SQL injection, XSS, CSRF and the rest of the OWASP list
> file uploads that get scanned, size-limited and stored where they can't execute
> CORS rules that aren't "allow everything"
> security headers on every response
> encryption at rest and in transit
> least-privilege access for everyone, including the AI agent holding production credentials
> logs that record who did what, without recording passwords, tokens or card numbers
> a penetration test before your enterprise customer's security team runs their own
> answers to the security questionnaire every enterprise buyer sends, with evidence behind each one
> a disclosure process for the day a stranger emails you a vulnerability
> a plan for the day a laptop with production access gets stolen
> SOC 2, which means policies, evidence and an auditor, not a checkbox
> HIPAA, the moment a single patient record touches your system
> a BAA with every vendor that touches that data, including your AI model provider
> audit trails that show who viewed a record, not just who changed it
> PCI scope, and card numbers kept out of your database
> GDPR deletion requests that reach every table, backup and log
> data residency for the customer whose contract says EU only
> quarterly access reviews someone signs off on
> dev, staging and production environments that match each other
> infrastructure written as code, so the setup lives somewhere other than one person's memory
> a deploy pipeline that runs the tests before anything reaches customers
> one-click rollbacks, because Friday deploys happen
> zero-downtime deploys, because your customers don't have maintenance windows
> feature flags, so you can ship the code without shipping the feature
> autoscaling for the Monday morning spike
> a CDN, so the app loads fast in Singapore too
> DNS, SSL certificates, and renewals that don't expire on a Sunday
> background job queues, so slow work doesn't freeze the page
> retries with backoff, so one flaky API call doesn't become a lost order
> a dead-letter queue for the jobs that fail every retry
> cron jobs that don't run twice the day you add a second server
> caching, and clearing that cache when the data changes
> SPF, DKIM and DMARC, so your password resets don't land in spam
> bounce and complaint handling on every transactional email
> storage rules, so you stop paying to keep 2021's temp files
> cost alerts, so a runaway agent loop shows up the same day and not on the invoice (we learned this one for $1,382.59)
> a disaster recovery plan, written down and tested once a year
> a second region, if your contract promises uptime one region can't deliver
> structured logs you can search at 3am
> error tracking that groups the same bug instead of sending you 4,000 emails
> uptime checks from outside your own network
> alerts that page a human, tuned until they stop paging for nothing
> dashboards for latency, error rate and throughput
> tracing for one slow request across every service it touches
> an on-call rotation, and a person who picks up
> runbooks, so the engineer on call knows what "queue depth critical" means
> postmortems that change something
> a status page customers check before they email you
> unit tests written by someone who knows what the logic should do
> integration tests for every third-party API you depend on
> end-to-end tests for signup, checkout and the other flows that make you money
> load testing before the launch email goes out
> test data that looks like production without being production data
> regression tests, so fixing bug 41 doesn't bring back bug 12
> testing on the five-year-old laptop your biggest customer's ops team still uses
> accessibility compliance, because the enterprise contract requires it
> subscriptions, upgrades, downgrades and proration
> failed-payment retries and dunning emails
> invoices with the customer's PO number on them, because procurement won't pay without it
> sales tax and VAT
> refunds, credits and partial refunds
> usage metering that matches what you bill, to the cent
> annual contracts with custom terms your billing logic never planned for
> revenue reports your finance team can reconcile
> webhooks that verify signatures
> webhooks that retry, with a log of every failed delivery
> a versioned API, so you can change it without breaking your customers' integrations
> API keys customers can create and revoke
> API rate limits that protect you without blocking real integrations
> a plan for the day a third-party API changes its response format without telling you
> OAuth token refresh, because tokens expire at the worst possible moment
> a sandbox where customers can test their integration
> protection against prompt injection in every field that reaches the model
> customer and patient data kept out of prompts that leave your network
> a model spend cap per customer, so one heavy user can't run up your bill
> evals, so you find out when a model update makes your answers worse
> a fallback for the afternoon your model provider goes down
> a migration plan for the day your model gets deprecated
> prompt and output logs for debugging, minus whatever you're not allowed to keep
> a human approval step for anything the AI does that can't be undone
> pages that load on hotel wifi
> empty states, loading states and error states on every screen
> error messages a customer can act on, instead of "something went wrong"
> forms that keep what people typed when one field fails validation
> emails that render in every mail client your customers use
> notifications people can turn off
> undo
> keyboard navigation and screen reader support
> translations, with dates and numbers formatted for each locale
> a back button that does what people expect
> code a human can read
> code review on every change
> a branching strategy, so two people can work without overwriting each other
> monthly dependency upgrades, so you're never two major versions behind
> framework upgrades before the old version stops getting security patches
> deleting the dead code the AI left behind from its first three attempts
> splitting up the 2,000-line file the AI kept appending to
> architecture decisions written down, with the reasons
> a README that gets a new engineer running locally in under an hour
> documentation for whoever inherits this
> an admin panel for your ops team
> support tooling, so customer success can answer questions without pinging engineering
> a changelog customers can read
> terms and a privacy policy that match what the code does
> every account, domain and repo in the company's name, not the name of whoever built the prototype
> a bus factor higher than one
Oh, and besides keeping all of this working every day, forever… your vibe-coded app will still need people who know what they're doing:
> reading every line the AI wrote before it ships (a senior engineer)
> designing the data model before your second customer breaks it (a backend engineer)
> explaining why the AI's fix for one bug created two new ones (a senior engineer, again)
> deploys, rollbacks, servers and the cloud bill (a DevOps engineer)
> answering the page at 3am when payments stop (whoever's on call)
> patching the framework the week a vulnerability goes public (security)
> walking an auditor through how patient data moves (security and compliance)
> testing what the AI says it tested (QA)
> running a migration on a live database without losing a row (a backend engineer)
> saying no to the feature that breaks three others (a tech lead)
> turning "works on my laptop" into "works for every customer at once" (an architect)
> debugging the code when the AI that wrote it can't (a senior engineer)
> remembering why it's built this way, a year from now (someone who was there)
…wishing them the best 🫡
TODAY 10/15 @ 1 pm EST... register here: luma.com/5jkb17ry
