Anyway, I get deeper into this later, but that is a summary of the problem, and I do talk about solutions that remedy a lot of the risk.

2 of hearts today, if you know you know. Now, I’m wondering the best way to prove it is me rather than a random card each week. My bot has gotten so good at work people are wondering what slack messages are me. :) Now, that is real progress. Got Blanka up to Triple platinum (again). I still want Diamond, and then master. I’m grinding when I can, but not a top priority for me right now.

Ok, on to the newsletter…

Subscribe now

A few weeks ago I found myself staring at a log trail trying to answer a question that should have been simple: who did this?

Something had run. It had made a decision, taken an action, and moved on. The decision wasn’t catastrophic — it was just wrong in the quiet way that things are wrong before they become expensive. And when I traced it back, I didn’t find a person. I found an agent. And when I traced the agent back, I found... nothing. A config file. A prompt someone wrote in a hurry three months earlier. No owner. No on-call. No name.

I’ve been doing this for thirty years, and I’ve spent a lot of that time on the receiving end of incident reviews. The hardest part of an incident was never the technical fix. It was the honesty. Somebody had to sit in a room and say I made that call, here’s what I was thinking, here’s what I missed. That moment is uncomfortable, and it’s also the single most valuable thing that happens in the whole process. It’s where the learning lives.

I sat there realizing that moment had quietly gone missing. And nobody had noticed, because nothing had technically broken.

The number that should scare you isn’t the capability one

Gartner is projecting that 40% of enterprise applications will have embedded agents by the end of this year — up from under 5% in 2025. That’s not a gradual adoption curve. That’s a cliff we all cheerfully drove off together.

Meanwhile, the honest reporting out of the field says the constraint on agent adoption isn’t model capability at all. It’s organizational design, fragmented data, and a shortage of people who actually know how to implement this stuff. The models are fine. We’re the bottleneck. And the phrase I keep seeing — that agent governance is the new cybersecurity — sounds right to me, but I think it undersells the problem.

Because cybersecurity, for all its pain, has an owner. There’s a CISO. There’s a budget line. There’s a person whose job is on the line.

Agents have none of that. We deployed a workforce and skipped the org chart.

Here’s what I think actually happened, and I say this with no superiority because I did it too. Agents entered our systems through the side door. Not as a platform decision with a review board and a rollout plan — as a convenience. One engineer wires up an agent to triage tickets. Someone in ops automates a reconciliation step. A PM builds a workflow in an afternoon that would have been a quarter of work last year. Every one of those was a good decision in isolation. That’s the trap. Nothing arrived that was big enough to require a decision about it.

So we ended up with dozens of small, capable, unsupervised things making judgment calls inside our companies, and no answer to the only question that matters when one of them is wrong: whose is it?

What ownership actually looks like

I don’t think the answer is a governance committee. I’ve sat on those committees. They produce documents, and documents don’t get paged at 2am.

The answer is smaller and more boring than that, which is usually a sign it’s correct.

1. Every agent gets a human name attached to it. Not a team, not a Slack channel — a person. The same way a service has an owner. If you can’t name the owner, the agent doesn’t ship. This one change does more than the next four combined.

2. Every agent gets a written job description. What it’s allowed to decide, what it must escalate, and what it must never touch. If you can’t write that in five sentences, you don’t understand what you deployed. Write it before you build it, not after.

3. Agent actions go in the same incident review as human ones. No separate process, no “well, that was the AI.” When an agent makes a bad call, the owner sits in the room and explains what the agent was optimizing for and why that was wrong. Keep the honesty moment. It’s the whole point.

4. Inventory what you already have. Not what you approved — what’s actually running. I promise the list is longer than you think and at least one item on it will surprise you. Do this one this week. It takes an afternoon and it’s the only step that requires nothing but willingness.

5. Give every agent an off switch a non-engineer can find. If killing a misbehaving agent requires a deploy, you don’t have control. You have hope.

None of this is glamorous. Nobody’s writing a conference talk about naming conventions and kill switches. But this is what “responsible AI” actually means at the implementation layer — not a values statement on your website, just a person willing to put their name on a thing that acts on their behalf.

I keep coming back to something I’ve believed my whole career: the tools change constantly, and the accountability never should. We spent the last two years arguing about whether AI would replace engineers. It didn’t. What it quietly did was let us deploy decision-makers without deploying anyone to answer for them, and that’s a much stranger problem than the one we were all bracing for.

The good news is that this is a fixable problem, and it’s fixable by exactly the kind of unglamorous, execution-shaped work that most companies won’t bother to do. Which, as always, is the opportunity.

Go find out what’s running in your systems this week. Put your name on the ones that are yours.

Then go build something amazing.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Oh, 2 of Spades… if you know you know, got a new invisible palm technique that I’m working on that is pretty cool. Ok, back to the newsletter.

I want you to try something. Go find your engineering team’s velocity dashboard. Look at the line that says “time to write code.” Look at it go down. Look at everyone in the room nod like we just cured cancer.

Now ask a different question: how much time is your team spending reviewing what the AI wrote?

Nobody has that dashboard. That’s the whole problem.

A Harness survey just dropped and it says the quiet part out loud: 81% of engineering leaders admit the time they saved writing code with AI is being eaten alive by reviewing AI’s code. Not “some of it.” Not “a little.” Eaten. Nearly a third of a developer’s day now goes to this invisible work. It doesn’t show up in your sprint report. It doesn’t show up in your board deck. It shows up in your engineers being exhausted and nobody knowing why.

Subscribe now

We Measured the Wrong Thing On Purpose

Here’s what actually happened. Every AI coding vendor needed a number to sell you, so they picked “lines of code generated per hour” or “PRs opened per week” because those numbers go up fast and look great in a sales deck. They did not pick “hours spent verifying that the AI didn’t import a library that doesn’t exist” because that number is annoying and doesn’t sell licenses.

I’ve built two products with these tools — Cash Critters and StatusSage — for about $50 a month combined in tooling. I’m not anti-AI. I’m anti-lying-to-yourself-with-a-dashboard. The AI genuinely writes code faster than a human. Nobody’s arguing that. But “faster to generate” and “faster to ship” are two completely different claims, and right now companies are reporting the first one and pretending it’s the second.

This is the same trick the industry always pulls. Remember when “lines of code” was the metric? Then everyone realized more lines of code usually meant a worse solution, not a better one. We’re doing that again, just with an AI logo slapped on the dashboard.

Where the Tax Actually Gets Paid

The overhead isn’t imaginary, and it isn’t going away. It’s the hallucinated import that looks legitimate until your build breaks in staging. It’s the business logic that runs perfectly and does the wrong thing. It’s the “silent failure” that passes every unit test the AI also wrote, because of course it grades its own homework consistently.

That’s not a productivity story. That’s a trust story. And trust doesn’t show up on a burndown chart, it shows up three weeks later when a customer finds the bug your team never saw because everyone was too busy admiring how fast the PR got opened.

What I’d Actually Do About It

1. Track review time as its own metric, starting this week. Not “cycle time.” Review time specifically. If you can’t see the cost, you can’t manage the cost.

2. Stop rewarding PR volume. If your team’s incentive is “ship more PRs,” you’ve just told everyone to generate more stuff for someone else to verify. Reward verified, shipped, working software instead.

3. Give your best people the hallucination check, not the boilerplate. The most experienced engineer on your team should be doing the highest-leverage verification, not writing CRUD endpoints an agent can already handle.

4. Ask your team the honest question in your next 1:1. Not “is AI helping you?” Ask “where did AI cost you time this week that nobody’s tracking?” You will get an earful, and it will be useful.

The tools aren’t the lie. The dashboard is the lie. AI is a legitimate amplifier of what your team can do, but only if you’re honest about where the hours actually go. Measure the real thing or don’t bother measuring at all.

Go build something amazing. Just make sure someone’s actually checking it before it ships.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Real John here. Ok, as I mentioned previously, I’m going to write a little more this weekend, and sent out a survey yesterday, and today is a little advice that I took from myself. I’ve been helping everyone build things, improve their business, get more clients, and redo their website to be aligned with their actual business, not what they think their business is. This week I took my own advice and executed. Eight of clubs, if you know you know. (new deck by the way from The Art of Play in Brooklyn)

This week is a little different. No headlines, no acquisition breakdowns, no model comparisons. This week, I’m talking about something I built for myself.

I rebuilt startupsandcode.com.

Here’s the confession part. For someone who has spent 30+ years telling people to ship, I let my own site sit in “good enough” mode for way too long. The cobbler’s kids have no shoes, and apparently the engineering advisor has a website that undersold everything he actually does. I’d tell a client to fix that in the first fifteen minutes of a call. It took me considerably longer to take my own advice.

So I did what I always tell you to do. I sat down, defined the actual problem, broke it into small pieces, and executed.

What Startups and Code Actually Is

Let me be direct, because that’s the whole point of the rebuild.

Startups and Code is an engineering advisory practice. I help founders, CTOs, and engineering leaders make better technical decisions, build engineering organizations that consistently deliver, and apply AI where it creates real leverage instead of real chaos.

Notice what I didn’t say. I didn’t say AI consulting. I didn’t say digital transformation. I didn’t say tailored end-to-end solutions, because I’d rather delete my newsletter completely than write that sentence, no really.

Here’s the point of view the entire site is built on:

Most companies don’t have an AI problem. They have an execution problem. AI simply exposes it.

I’ve watched this play out over and over. A team adopts the latest tools, the demos look incredible, and six months later delivery is somehow slower. The tools were never the issue. The decision-making, the architecture, the team structure, the delivery habits, that’s where the leverage lives. AI just turns the volume up on whatever you already are. If your organization executes well, AI makes you faster. If it doesn’t, AI helps you ship bad decisions at unprecedented speed.

You don’t need another AI tool. You need a better engineering organization.

How I Work With Teams

I kept it simple. Three ways to engage:

Executive Engineering Review (starting at $5,000). For leaders facing a consequential decision: architecture, roadmap, hiring, team structure, AI adoption. You get a written assessment, clear priorities, risks, recommendations, and a 90-day action plan. Judgment on paper, not a workshop with sticky notes.

AI Engineering Sprint (starting at $15,000). Two to four weeks improving how a real team actually works. AI-assisted development, Claude Code rollout, agentic workflows, delivery friction. Measured by delivery improvement, not by how many tools got installed.

Fractional Engineering Advisor (starting at $7,500/month). Ongoing senior judgment without adding a full-time executive. Architecture review, roadmap input, hiring calls, team coaching, practical AI decisions.

The thing underneath all three is the same operating loop I’ve used for two decades of leading engineering teams. I call it the Engineering Flywheel: Clarify the right decisions, Strengthen the team and systems, Accelerate delivery without sacrificing quality, Compound that into a lasting advantage.

This isn’t theory I read in a book. It’s what I’ve done at Microsoft, at startups, as a CTO, and on my own products. When I tell you constraints breed better work, it’s because I built Cash Critters on a $50/month budget. When I tell you AI tools need engineering judgment wrapped around them, it’s because I use them every single day.

The Ask

I almost never do this, so when I do, it matters.

If you’re a founder or engineering leader at a startup with roughly 10 to 150 engineers, and you’re staring down a decision that actually matters, I want to talk to you. If you know someone in that seat, forward them this email. That’s genuinely the most valuable thing you can do for me this week.

Share

The first step is a strategy call. No pitch deck, no discovery theater. You bring the problem, I bring 30 years of pattern matching, and we figure out if I can help. If I can’t, I’ll tell you that too, and probably point you somewhere useful anyway.

Book a Strategy Call

The site is live. It says exactly what I do and who I do it for, in plain language, with real prices. That alone puts it ahead of half the consulting sites on the internet.

I practiced what I preach. Defined the problem, shipped the solution, and now I’m telling you about it. That’s the whole playbook.

Now go build something amazing. And if you’re stuck on what to build next, you know where to find me.

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Subscribe now

Let’s get into the newsletter…

I caught myself doing something strange last week. I was three hours into a session with Claude Code, and I switched voices without even noticing. One minute I was setting boundaries, telling it exactly what NOT to touch, the way you’d tell a toddler not to run into the street. Ten minutes later I was reviewing its output like a manager grading an intern’s first pull request, generous but specific. Then it explained a pattern back to me that I hadn’t considered, and I was the student, taking notes from a professor who happened to be running on my laptop.

Three roles, one session, no script for any of it.

That’s the part nobody prepared me for. Everyone talks about AI coding tools like they’re a single relationship. Prompt in, code out. But if you’ve actually built something real with these tools, you know it’s not one relationship. It’s three, shifting under you depending on the moment, and the builders who get the most out of AI are the ones who know which role they’re playing at any given second.

The Parent Moment

Early in a project, you’re the parent. You set the rules before the kid can break anything expensive. This is your CLAUDE.md file, your project conventions, your “don’t touch the payment logic without asking.” Skip this step and you’ll spend your evening cleaning up a mess a two-year-old made with a permanent marker on your architecture.

I learned this the expensive way building Cash Critters. Early sessions without clear boundaries meant I’d come back to files touched that had nothing to do with what I asked for. Once I started treating context the way you’d childproof a house, before letting the kid loose, not after, the chaos dropped fast.

The Manager Moment

Once the guardrails exist, you shift into managing an intern. A sharp one. Fast, tireless, occasionally overconfident. You review the output. You ask clarifying questions. You don’t just accept the first draft because it compiled. Managing an intern well isn’t about micromanaging every keystroke, it’s about knowing when to trust the output and when to say “walk me through your reasoning here.”

This is where model selection actually matters, and it’s not a minor detail, it’s the whole management decision. Handing your intern the wrong tool for the job is on you, not them. There’s real research right now on context engineering, the discipline of curating exactly what an agent sees instead of dumping your whole codebase at it and hoping for the best. The teams treating this seriously are seeing real gains. The ones skipping it are getting confident, wrong answers delivered with a straight face, which is worse than an intern who says “I don’t know.”

The Student Moment

Then, without warning, the roles flip. The tool explains something I didn’t fully understand, a pattern, a tradeoff, an edge case I hadn’t thought through. Suddenly I’m not managing anything. I’m learning. That’s the moment most builders miss because they walked in expecting a vending machine, not a professor. If you never let yourself be the student in this relationship, you’re leaving half the value on the table.

What Actually Works

Here’s the practical version, because I promised you something you can use, not just a metaphor to nod along with:

1. Set the boundaries before you need them. Write your context files, your conventions, your “don’t touch this” list, before the session starts, not after the damage is done.

2. Match the tool to the task, deliberately. A UI generator is not a debugging specialist. Know which model or tool you’re reaching for and why, the same way a good manager doesn’t hand every task to the same person regardless of their strengths.

3. Review the output like you’d review a junior dev’s PR. Ask why, not just what. Confidence from an AI is not the same as correctness.

4. Let yourself learn. When the tool surfaces something you didn’t know, sit with it. That’s not the tool showing off, that’s the actual upside of working this way.

The builders who are winning right now aren’t the ones with the fanciest prompt. They’re the ones who know which relationship they’re in at any given moment, parent, manager, or student, and who switch between them without ego getting in the way.

That’s the whole game. Set the boundaries, manage the output, stay humble enough to learn something.

Go build something amazing.

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Subscribe now

I applied to over 300 jobs after leaving my last role.

Three hundred. I have 30+ years of experience. I’ve been a CTO, a VP of Engineering, I’ve built teams from zero, shipped products that actually worked, reduced cloud spend by 40%, and maintained 90%+ team retention for over two years straight. I have a patent. I’ve taught at universities.

Didn’t matter. Most rejections came back within the hour. Sometimes minutes.

At first I thought the market was broken. Then I realized something worse: I was playing by the old rules in a game that had completely changed the board.

The Numbers Tell a Brutal Story

Over 127,000 US tech workers were laid off in 2025. That number isn’t slowing down in 2026. Every week there’s a new headline. Another round, another “restructuring,” another LinkedIn post with the blue banner.

Meanwhile, AI-adjacent roles are on fire. AI engineers, ML ops, prompt engineers, agent developers, AI product managers. Companies cannot hire fast enough. Patronus AI just raised $50 million specifically to help enterprises test AI agents before deploying them. That is an entire company, funded at $50M, that exists because the demand for AI implementation outpaced the supply of people who actually know how to do it safely.

There are two job markets right now. One is collapsing. One is exploding. And most laid-off developers are standing in the wrong line.

This Is Not a Job Market Problem

Stop blaming the economy. Stop blaming AI for “taking jobs.” Stop blaming the ATS systems that ghosted you.

This is a skills translation problem. Full stop.

Here’s what I mean. You have 8 years of backend Java experience. You’ve built APIs, handled scale, debugged production fires. That experience is genuinely valuable. But your resume says “Senior Software Engineer, Java, Spring Boot, Microservices.” It does not say what you can do with AI tooling. It does not say you’ve shipped anything using Claude Code or Cursor. It does not mention that you understand how to wire an LLM into a real workflow and keep it from hallucinating on your users.

The hiring manager, who is now also probably using AI to screen you, doesn’t see the connection. So neither does the system. So you get a rejection in 47 minutes.

You didn’t fail. You failed to translate.

The Skills You Have Already Qualify You

Here’s the part nobody is saying loud enough: most of what AI needs, experienced developers already have.

Understanding data flows? You have that. Debugging unpredictable systems? You’ve done that for years. Knowing when a tool is wrong for the job? That’s senior engineering judgment. Something a junior AI hype-chaser absolutely does not have.

The gap isn’t your experience. The gap is vocabulary and proof.

Vocabulary: can you speak about AI integration, agent design, retrieval-augmented generation, MCP tools, and evaluation pipelines in a job interview without faking it?

Proof: have you shipped anything, anything at all, that uses AI as a functional layer? Even a side project. Even something small.

I built Cash Critters (cashcritters.com) for $50/month using Lovable, Vercel, and Claude Code. It’s a real product. It has real users. It teaches kids about money. It also serves as proof that I know how to build with AI tools end to end. That one project changed how I talk about my work in every conversation.

What You Should Actually Do

Stop submitting 300 applications with the same resume. Start here instead:

1. Pick one AI tool and build something real with it. Cursor, Claude Code, Lovable, Replit. Pick one. Build a tool that solves a problem you actually have. Deploy it. Put it on GitHub. Put it on your resume.

2. Retranslate your existing experience. Go through your last three roles. For every project, ask: where would AI have fit? Where does it fit now? Rewrite your bullets around that lens.

3. Learn the vocabulary of the new stack. Agents. MCP. RAG. Evals. You don’t need to be an ML researcher. You need to know what these are and when to use them. One weekend of reading will do it.

4. Ship publicly and talk about it. Write one LinkedIn post about something you built. One newsletter. One GitHub repo with a README that actually explains what the thing does. Distribution is the new credential.

The market isn’t broken. The translation layer is. Fix that, and the market opens back up.

The developers who figure this out are going to have the best careers of their lives. AI doesn’t replace engineers who understand systems, judgment, and scale. It multiplies them. The ones sitting on the sidelines waiting for the market to “return to normal” are going to be waiting a long time.

Normal isn’t coming back. The new normal is better. Go learn the language and go build something amazing.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive with 30+ years in the industry, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

I talk about agent stuff today, but there is one thing that I want to also talk about… Fable being pulled. Why? Because they refused to remove the jailbreak bug. But the real reason is probably because they don’t know how to stop it. A quick intro before I get into this week’s newsletter. AI LLMs cannot be blocked by guard rails in a markdown file. AI is just as susceptible to social engineering as much as we are. Remember it was all trained on human data, so human flaws exist in its OWN system. If you are worried about privacy, security, or blah, blah, blah. Stop using the internet, wifi especially, and never touch AI. You carry a digital tracking device with you 24 hours a day, you login to multiple systems a day using the same account, you tell a chat company secrets and it promises it is being private. If an AI said it would sell you swamp land or a bridge, you probably would buy it. Be human, trust but verify. Don’t think your data is not being used.

Ok, that part of the rant is over… Let’s get into the latest buzzword Agentic AI and how people are claiming they are AI forward and don’t even know what that means (probably because they didn’t write the script, the AI did it for them, c’mon people, be better). Ok, let’s get into it.

I’ve been in software for 30+ years. I’ve survived the Java EE era. I sat through Agile transformations that were just scrum ceremonies with a new logo. I watched companies “go cloud” by lifting and shifting their on-prem disasters into AWS and calling it digital transformation.

And now I’m watching it happen again. Same movie. Different buzzword.

Agentic AI.

Every conference talk, every LinkedIn post, every VC pitch deck in June 2026 has the word “agentic” in it. AI that doesn’t just answer questions — it does things. It browses, clicks, writes code, sends emails, manages tasks end to end. Autonomous. Proactive. A whole new paradigm.

Cool. So why does every team I talk to still have a human copying the AI’s output into a spreadsheet?

The Gap Nobody Wants to Admit

Here’s what actually happened over the last year: companies went from using AI as a chatbot to buying AI agent tooling. They subscribed to the platforms, they wrote the system prompts, they plugged in the APIs.

And then they dropped the agent into the exact same workflow they had before.

Same approval chains. Same ticket system. Same standup where someone reports what the AI said. Same manager who “reviews the AI output” for three hours a day and wonders why productivity didn’t go up.

You didn’t adopt agentic AI. You gave your old process a robot assistant and called it transformation.

That’s not a technology problem. That’s a thinking problem.

The bottleneck was never the model. It’s that nobody has sat down and asked: “If this agent can actually do the work, what does my job look like now?”

That question is terrifying. So instead, everyone just adds AI to the existing job and wonders why they’re more exhausted than before.

What Deploying Agents Actually Requires

Let me be specific, because vague inspiration isn’t useful.

1. Kill the handoff. If your agent produces output that a human then manually moves somewhere else, you haven’t deployed an agent. You’ve deployed a fancier copy-paste machine. The agent needs to finish the job — (for those wondering, I edit it so it adds those emdashes for formatting, I don’t use emdashes) write to the database, send the message, update the record. If you can’t trust it to do that, figure out why and fix that problem first.

2. Rewrite the job description around the agent, not alongside it. The agent is not a tool you use. It’s a team member with a role. Define its scope. Define what it owns. Define what escalates to a human and why. I did this with Cash Critters — specific AI tasks have specific lanes. When something falls outside that lane, it surfaces to me. Everything inside the lane? It runs.

3. Your review process is now exception handling, not proofreading. If you’re reading every output your agent produces, you haven’t changed anything. You’ve just added a step. Exception-based review means: the agent ships, you see anomalies, you investigate anomalies. Not “let me check everything it did.” That’s not delegation. That’s micromanagement with extra steps.

4. Measure the right thing. Nobody is tracking “hours of work the agent completed autonomously.” They’re tracking the same KPIs they had before, wondering why the numbers look the same. Define what the agent is supposed to own, and measure whether it owns it. Not whether humans are happy with the output. Whether humans aren’t involved in producing it.

5. Ship it broken and fix it. This one stings for people who want a perfect rollout. There is no perfect rollout. I’ve been coding since I was 9 years old on a Commodore 64. You know how I learned what worked? I deleted something, watched it break, and fixed it. Agents are no different. Deploy them into real workflows with real stakes, watch where they fall over, and tighten it up. Waiting for perfect is how you get to 2027 still talking about the potential of agentic AI.

The Hard Truth

The companies winning right now aren’t the ones with the most sophisticated agents. They’re the ones who were willing to blow up their old process to make room for a new one.

That takes courage. It takes a leader willing to say “we don’t need that meeting anymore” and actually cancel it. It takes an engineer willing to let the agent own a thing they used to own. It takes a founder willing to trust the system they built.

Most people aren’t there yet. They want the productivity gains without the organizational change. You can’t have both.

Agentic AI isn’t a tool upgrade. It’s a workflow redesign that happens to involve a very capable tool. Skip the redesign, and you’ve paid for a gym membership you’re not using.

So yes — everybody’s talking about agents. Almost nobody has actually deployed one properly. The gap between those two groups is where the next competitive advantage lives.

Go build the thing. Then get out of its way.

Share

My new favorite quote - “The magic is in the work” - Jalen Brunson (Congrats Captain!)

John Mann is the founder of Startups and Code LLC, a software engineering executive with 30+ years in the industry, and the person who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that actually ship.

The one-shot BS is annoying and watching silly youtube demos of the marketing crap from Anthropic or OpenAI is generally a lie of some sort. But the interactions and more is real. It is so real that it can help you build custom solutions for your use case today. Ok, let’s get into this week. I did the card thing earlier, so I’m just going to get into it. Shout out this week to the WAV Pod for the kindness they showed for the passing my dog recently. Thank you all, it really meant a lot.

A few months ago, I caught myself doing something embarrassing.

I had Claude open in one tab, my code editor in another, and I was doing this little dance: ask a question, read the answer, copy the code, paste it, test it, go back, ask another question. Over and over. For hours.

I’m a guy who’s been writing software since I was 9 years old on a Commodore 64. I’ve shipped Cash Critters and statussage almost entirely with AI tools. And I was still using AI like it was 2023 — like a really smart search engine that happens to write code.

Subscribe now

Here’s the thing nobody wants to say out loud: most of you are still doing this too. You ask, you read, you copy, you paste. That’s not wrong, exactly. It’s just... small. It’s using a power drill to turn one screw and then setting it down.

The shift happening in AI right now isn’t about smarter chatbots. It’s about AI moving from answering to doing. From conversation to action. And if you’re still in question-and-answer mode, you’re leaving most of the value on the table.

So let’s fix that. Here’s how I actually use AI agents now — not in theory, but in the actual workflows I run for Cash Critters, statussage, and my day job.

Step 1: Stop asking “how do I” — start asking “do this”

The biggest mental shift is moving from questions to instructions with a defined outcome.

“How do I add authentication to my app?” is a chatbot question. You’ll get a tutorial. You still have to do the work.

“Add email/password auth to this app using Supabase, update the login page, and write a test that confirms a bad password gets rejected” is an agent instruction. The agent goes and does it — reads your code, makes the changes, runs the tests, and tells you what happened.

The difference is ownership of the outcome, not just the information. You’re not asking for help anymore. You’re delegating a task.

Step 2: Give the agent a way to check its own work

This is the part most people skip, and it’s the part that actually makes agentic workflows trustworthy.

When I’m working on statussage with Claude Code, I don’t just say “build this feature.” I make sure there’s something the agent can run to verify it worked — a test, a build command, a linter, a script that hits an endpoint and checks the response.

Why does this matter? Because an agent that can run code, see the error, and fix it is fundamentally different from one that just hands you code and hopes. The first one is doing real work. The second one is still a chatbot wearing a trench coat.

Practical tip: before you ask an agent to build something, ask yourself “how would I know if this worked?” If you can answer that in one sentence, you can probably hand that verification to the agent too.

Step 3: Let it run in the background while you do something else

This is the one that changes everything, and it’s the one almost nobody does.

I’ll kick off a task in Claude Code — “refactor this module to use the new API client, update all the call sites, and make sure the existing tests pass” — and then I go do something else. Answer emails. Walk Ella and Lego. Grab coffee with Susie.

Twenty minutes later I come back and either it’s done, or it hit a wall and explained why. Either way, I didn’t sit there babysitting a chat window.

If you’re tethered to your screen watching an AI “think,” you’re not using an agent. You’re using a very expensive loading spinner.

Step 4: Build a pipeline, not a one-off

Once you’ve got a task that an agent can do well — write tests, generate documentation, review a pull request, draft a status update — don’t just do it once. Make it repeatable.

For Cash Critters, I have a setup where new feature branches automatically get a basic test pass and a summary of what changed, generated by AI, before I even look at it. That’s not magic. It’s just: take the thing you did manually with an agent once, and wire it so it happens every time without you asking.

This is the “Series A average is $51.9 million” world we’re living in — most of you don’t have that money, and you don’t need it. A solo builder with two or three of these pipelines running is doing the work of a small team. That’s not hype. That’s just math.

Step 5: Keep a human checkpoint where it actually matters

I’m not telling you to YOLO everything to an agent and walk away forever. Production deploys, anything customer-facing, anything involving money or data — you review that. Always.

But the line between “needs a human” and “doesn’t” is way further out than most people think. Internal tooling, test writing, refactors, documentation, first-draft anything — let the agent run. Save your attention for the decisions that actually need a human brain behind them.

This Week’s Action Items

1. Pick one recurring task you currently do by asking AI a question and copy-pasting the result. Rewrite it as an instruction with a clear, checkable outcome.

2. Give it a way to verify itself — a test, a script, a build step. If it can’t check its own work, it’s still a chatbot.

3. Walk away while it runs. Set a timer for 15 minutes and do literally anything else. Resist the urge to babysit.

4. Turn it into a pipeline. If it worked once, automate it so it happens every time without you asking.

That’s it. Four steps. None of them require a $59 billion funding round or a quantum computer. They require you to stop treating AI like a search box and start treating it like what it actually is now: a teammate that can do the work, not just describe it.

Go build something amazing.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

I was on the subway the other day — 1 train, naturally packed — and I thought about a bug I needed to fix in a running Codex session. Couldn’t do anything about it. Had to wait until I got home, sat down, opened the laptop. Classic developer problem. You are never more productive than when you’re away from your desk.

Subscribe now

OpenAI heard that complaint. On May 14th, they officially rolled Codex into the ChatGPT mobile app on iOS and Android, available in preview across all plans — including free. And the developer world immediately lost its mind about it.

I’m excited too. But let’s pump the brakes for exactly one minute before we declare the death of the desktop.

What Codex Mobile Actually Is

Here’s what OpenAI shipped: remote control for your desktop Codex session.

That’s it. Your phone is not running the code. Your phone is not spinning up environments. Your Mac — note the word Mac, Windows is “on the roadmap” — is doing all the heavy lifting. The mobile app is the control surface. You can review diffs, approve commands, switch models, kick off new tasks, and monitor what your agent is doing in real time.

It’s basically a dashboard with approval buttons. A very smart, very useful dashboard with approval buttons.

The workflow OpenAI pitched is exactly right: “Start something from a computer at home and then go out to the coffee shop and approve the final output over your matcha.” That’s the use case. You fire off a refactor, walk the dogs, and your phone buzzes when Codex needs a decision. You say yes or no. The agent keeps going.

That’s genuinely useful. I’m not being sarcastic. As someone who builds things in the margins of a full-time engineering executive role, asynchronous agent control changes the math on what I can ship in a week.

But — and this is important — this is management, not development.

The Shift Nobody Is Naming

Here’s what’s actually happening here, and nobody in the press release is saying it directly.

We are entering the era of async development. The mental model we’ve had for 30 years — sit down, type code, see result, iterate — is being replaced by something that looks a lot more like being a project manager for an AI team.

You write the prompt. You set the direction. You review the output. You approve or redirect. The execution is happening in the background, while you’re on the subway, walking the dog, sitting in yet another meeting that could have been an email.

I’ve been building on Codex. I’ve also been deep in Claude Code, which, for the record, Anthropic shipped remote control for back in February — three months before OpenAI caught up. Both tools are converging on the same pattern: the agent works, you supervise.

The practical question is no longer “can I code on my phone?” The answer to that has always been “technically yes, but it’s miserable.” The real question is now: how much do you trust your agent?

Because approving a diff on a 4-inch screen without reading every line means you are trusting the agent made the right call. Sometimes it will. Sometimes it will confidently remove something important. And you approved it on a phone, between stops on the 1 train.

How to Actually Use This Well

Here’s my honest take on when mobile Codex is a superpower and when it’s a trap:

Use mobile for:

• Monitoring long-running tasks you already kicked off and understood

• Quick approvals on small, isolated changes (a single function, a config update)

• Starting new tasks you’ve pre-thought through and can describe precisely in a voice note or quick prompt

• Staying unblocked while you’re away from the desk — the friction of “I’ll do it when I get back” kills momentum

Don’t use mobile for:

• Approving large refactors you haven’t reviewed carefully

• Debugging anything where you need context across multiple files

• Making architectural decisions in a Slack message format while distracted

The pattern that works: think at the desk, supervise from the phone. Your laptop is where you set up the task clearly and give the agent enough context to run. Your phone is where you keep the task alive when life happens.

The Part That Still Matters

I’ll say this plainly: the most important skill in 2026 is not knowing how to code. It’s knowing how to direct code. Knowing what you’re asking for. Knowing when the output is wrong even if it looks right. Knowing the difference between “the agent finished” and “the agent finished correctly.”

The mobile release doesn’t change that. If anything, it amplifies it. You’re now approving work at 30 second intervals between meetings. Your judgment — built from actually understanding what your code does — is the last line of defense.

I built Cash Critters using these async patterns. I’m not chained to a keyboard for hours anymore. But I know the codebase. I know what a bad diff looks like. That knowledge is what makes the workflow actually work.

The phone is just the remote. You still have to know what you’re controlling.

Go build something amazing.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

I can have a 10 year old write better code from scratch than some AI. But that doesn’t mean AI is trash, it means it needs training, education. Engineers are the teachers/orchestrators/conductors now. We can do marketing, product management, financial analysis, and business gtm strategies. Oh, did that hit a nerve to you non-engineers? Why? Because you have spent your career learning the nuances of how to do your job that AI can’t possibly understand. Yeah, exactly. AI can augment you and automate the silly stuff, but you need to teach it how to be better. So engineers who are afraid of AI or worse, think it is AI slop, it is because you expect a 5 year old to be able to operate at a PhD level with no education. Give it the education, take the time to work with it, and it WILL be better than you shortly, and it will help you be better too! So we are not experts in an area anymore, we are empowered to teach it something that we imagine by having conversations, not by single-prompting and then expecting the first result be perfect. Ok, rant over for now… let’s get into this week’s newsletter. King of Spades this week, if you know you know. (Side note: I’m working on my Elmsley count and having a lot of fun with that)

When I was nine, I wrote BASIC on a Commodore 64. By the time I’d worked my way through a few jobs, I’d written ABAP, Pascal, C#, Python, JavaScript, Kotlin, SQL, and a pile of languages I’ve mercifully forgotten. I never set out to be a “polyglot.” I just kept needing to solve a different problem than the one in front of me yesterday.

For most of my career, that made me weird. The industry wanted specialists. “What’s your stack?” Pick a lane. Be the React guy. Be the Kubernetes guy. Be the one who only does machine learning pipelines and gets a little twitchy when you ask him to write a CSS file.

Well. Funny how that turned out.

Subscribe now

The Org Chart Is Eating Itself

This isn’t me ranting into the void anymore. McKinsey just told a room full of engineering leaders the same thing: the high-performing teams are collapsing from the classic eight-to-ten-person “two-pizza” squad down to three-to-five people. Fewer specialists. More full-stack builders who can orchestrate AI agents across the entire stack — exploration, implementation, review — and own the whole outcome.

Read that again. The teams that are winning aren’t the ones with a specialist for every box on the org chart. They’re the ones with a handful of people who can do the whole job and point a few agents at the boring parts.

I have been screaming this for THIRTY YEARS. Great people beat big headcount. I wrote it when it cost me clients who wanted me to staff up. I said “I’d rather have $2 million for ten years than $5 million for one.” And now there’s a McKinsey slide that agrees with me. I’m not sure whether to feel vindicated or insulted.

Here’s the part nobody wants to say out loud: AI didn’t kill the specialist. AI just exposed that a lot of “specialist” roles were process overhead pretending to be expertise. When one person with Cursor and Claude Code can scaffold the backend, wire the frontend, write the tests, and ship to Vercel before lunch, the question “who owns the API layer” stops being a job title and starts being a Tuesday.

“But My Deep Expertise—”

Yeah, yeah. Calm down. I’m not saying expertise is worthless. I’m saying narrow expertise with nothing around it is now a liability.

The agent can write the SQL. The agent can refactor the component. What the agent CAN’T do is decide what’s worth building, catch the edge case that breaks production, own correctness end-to-end, or talk to a customer and figure out what they actually meant instead of what they said. That’s the human job now. That’s the WHOLE human job now.

If your entire professional identity is “I’m the person who writes the queries,” I have bad news and it’s already arrived. If your identity is “I’m the person who ships the thing that solves the problem,” congratulations, you just got a raise nobody told you about.

I built Cash Critters for fifty bucks a month. One person. The whole thing — finance app for kids, real users, real product. I am not a designer. I am not a DevOps “guru.” I’m a builder who refuses to be precious about which part of the stack he’s allowed to touch. That’s the entire move.

What To Actually Do About It

Enough theory. You came here for something you can do, so here it is:

1. Pick the part of the stack you avoid — and go build something in it this week. Backend person scared of CSS? Build a UI. Frontend person who fears the database? Stand up a schema. The fear is the map.

2. Stop collecting tutorials. Start orchestrating agents. Open Cursor or Claude Code, give it a real task, and learn to review its diffs like a hawk. Your job is judgment, not typing.

3. Ship one end-to-end thing with your name on the whole thing. Idea to deployed. No handoffs. No “that’s not my area.” Own all of it once and you’ll never go back.

4. Delete “I only do X” from how you describe yourself. You’re a problem solver who happens to use code. Say that instead.

The specialist waited for the perfectly-scoped ticket. The product builder just asks “what’s the problem?” and goes.

The thing is, I never had a choice. I learned to do all of it because I was usually the only one in the room, or because nobody else would, or because the Commodore didn’t come with a team. Turns out the constraint was the gift. It always is.

The whole industry is finally being forced into the corner I’ve lived in my entire life: be a generalist who ships, or be a line item that gets optimized away. I know which one I’d pick. You already know too.

So stop guarding your little patch of the stack like it’s a kingdom. It’s not. The kingdom is the thing you ship.

Now go build something amazing — all of it, this time.

Share

Final note: (still real John)… Most people don’t need another podcast, book, or AI tool.

They need a room full of people who are actually building.

My next Barn Session is happening in July. Six to eight people. One weekend. Real conversations. Real accountability. Real progress.

If you’ve got an idea that’s been living in your head for too long, let’s talk.

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

If you can't successfully reply to the email for Barn Sessions feel free to write a comment on the post.

Talk soon,

John

I’m putting together a small founder’s cohort weekend called Barn Sessions.

It’s for people who have had an idea sitting in the back of their mind for months, maybe years, and are ready to stop thinking about it and start building.

This isn’t a conference, networking event, or pitch competition.

It’s a small group of 6-8 people spending a weekend together focused on turning ideas into action.

The next Barn Session will be in July.

If you’re interested, reply to this email and tell me what you’ve been wanting to build. I’ll follow up with details.

-John- (aka real john, 10 of clubs, if you know you know)

Subscribe now

Everyone in the AI dev space is throwing around “MCP” like it’s been part of their vocabulary forever. Model Context Protocol this, MCP server that. I watched a demo last week where someone connected Claude to their database, their GitHub, and their Slack — all from the terminal — and it felt like magic.

It’s not magic. It’s plumbing. And once you build one yourself, the mystery evaporates completely.

I’m going to walk you through shipping your first MCP tool in about 30 minutes. Real code. No hand-waving. By the end, Claude will be able to call your custom function like it was born knowing about it.

What Even Is MCP?

Quick, no-fluff explanation: MCP (Model Context Protocol) is an open standard Anthropic shipped in late 2024. It lets AI tools like Claude Code connect to external systems — your database, your APIs, your custom logic — through a single standardized interface.

Before MCP, connecting Claude to GitHub required one custom integration. Connecting it to Slack required a different one. Every tool meant new glue code. MCP solves that with a universal connector layer. There are over 2,300 public MCP servers available as of right now, and every major AI coding tool — Claude Code, Cursor, Windsurf, VS Code — supports it.

But here’s the thing: most developers have only ever used MCP servers. They’ve never built one. And building one is how you actually understand what’s happening under the hood.

What We’re Building

A simple MCP tool that takes a URL and returns a summary of the page’s metadata (title, description, status code). Boring? Yes. Perfect for learning? Also yes. The pattern transfers to anything — querying your DB, hitting an internal API, reading a log file, whatever.

Prerequisites: Node.js 18+, Claude Code installed, 30 minutes.

Step 1: Scaffold the Project

mkdir my-first-mcp && cd my-first-mcp
npm init -y
npm install @modelcontextprotocol/sdk

The MCP SDK handles all the protocol boilerplate. You just define your tools.

Step 2: Write the Server

Create index.js:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "url-inspector",
  version: "1.0.0",
});

server.tool(
  "inspect_url",
  "Fetches metadata from a URL: title, description, and HTTP status",
  { url: z.string().url() },
  async ({ url }) => {
    try {
      const res = await fetch(url);
      const html = await res.text();

      const title = html.match(/<title>(.*?)<\/title>/i)?.[1] ?? "No title";
      const desc = html.match(/<meta[^>]+name="description"[^>]+content="([^"]+)"/i)?.[1] ?? "No description";

      return {
        content: [
          {
            type: "text",
            text: `Status: ${res.status}\nTitle: ${title}\nDescription: ${desc}`,
          },
        ],
      };
    } catch (err) {
      return {
        content: [{ type: "text", text: `Error: ${err.message}` }],
        isError: true,
      };
    }
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

That’s it. That’s a real MCP server. The server.tool() call registers your function, the Zod schema validates inputs, and the stdio transport is how Claude Code will talk to it.

Add "type": "module" to your package.json so ES imports work.

Step 3: Register It With Claude Code

claude mcp add --transport stdio url-inspector -- node /absolute/path/to/my-first-mcp/index.js

Verify it registered:

claude mcp list

You should see url-inspector in the list.

Step 4: Use It

Open a Claude Code session:

claude

Then just ask it:

“Use inspect_url to check what’s on https://cashcritters.com”

Claude will call your tool, get the response, and use it in its answer. Your code. Your tool. Running live inside an AI session.

What Just Happened

A few things worth internalizing:

You defined the interface, not the implementation. Claude doesn’t know how your tool works — it just knows the name, description, and input schema. You control what runs underneath.

The description is the most important line you wrote. Claude decides when to call your tool based on that string. Write it like you’re explaining to a smart junior dev what this function does and when to reach for it.

Stdio transport means local only. For a production MCP server that multiple people or agents can hit, you’d switch to SSE (Server-Sent Events) transport and host it somewhere. Vercel works fine for this. But for personal tooling or team-local tools, stdio is perfect.

Where To Go From Here

Once you have the pattern down, the interesting tools are obvious:

• Query your own database — give Claude direct read access to your schema so it stops hallucinating column names

• Internal API wrapper — expose your company’s internal APIs as MCP tools so Claude can pull real data in context

• Log parser — tail your Vercel function logs and surface errors on demand

• StatusSage integration — I’ve been wiring up my own projects to MCP so Claude can check status and incidents without me copy-pasting anything

The pattern is always the same: define the tool, write the logic, register it. Everything else is just what you point it at.

The best way to understand any abstraction is to build one layer below it. MCP seemed like magic until I wrote my first server. Now it’s just a function with a description attached. That’s the whole thing.

Go build something amazing.

Share

John Mann is the founder of Startups and Code LLC, former CTO, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Read more

Read more

Read more

This is a conversation space exclusively for subscribers—kind of like a group chat or live hangout. I’ll post questions and updates that come my way, and you can jump into the discussion.

Join chat

Read more

Read more

Hey all, it’s me Real John. So today I have to talk about SpaceX trying to buy cursor… but I’m going to do another one this week, mainly because there is so much going on in my head I really want to share. AI is getting so good right now, and its getting more fun everytime I start playing with it. The next article is about using…

Read more

Subscribe now

Read more

Read more