I love vibe coding. I really do. I built Cash Critters with AI tools, I’m building StatusSage with them, and I preach the gospel of shipping fast with a $50/month stack every single week in this newsletter.

So when I tell you vibe coding has a serious problem right now, I need you to hear it — not as a critic, but as someone who’s all in on these tools and doesn’t want to watch them get buried by a wave of self-inflicted disasters.

Because that wave? It’s already here.

The Party Was Great. Someone Left the Door Open.

Moltbook launched January 28th, 2026. Big hype. AI social network. The founder proudly announced he “didn’t write a single line of code.” Within three days, 1.5 million API keys were exposed. Thirty-five thousand emails. Gone. The entire database was publicly accessible because the AI never enabled Row Level Security — and no human ever checked.

Three. Days.

That’s not a one-off. Researchers at Escape.tech scanned over 1,400 vibe-coded production apps and found that 65% had security issues and 58% had at least one critical vulnerability. Georgia Tech’s Vibe Security Radar tracked 6 CVEs attributable to AI-generated code in January 2026. By March? Thirty-five. In a single month. And researchers estimate the real number is 5 to 10 times higher because most AI tools don’t leave identifiable commit metadata.

Meanwhile, Veracode tested over 100 AI models on security-sensitive coding tasks. Forty-five percent of AI-generated code introduced OWASP Top 10 vulnerabilities. Not obscure edge cases. The classics. XSS. SQL injection. Hardcoded secrets. The stuff every developer learns to avoid in year one.

The AI doesn’t know what it doesn’t know. And if you don’t know either, you just shipped a vulnerability to production with confidence.

Why This Is Happening (And It’s Not the Tools’ Fault)

Here’s the uncomfortable truth: the tools are working exactly as designed.

AI coding tools optimize for making the error message go away. They generate code that satisfies the stated requirement. The problem is “make a login form” and “make a secure login form” are two completely different prompts — and most people only type the first one.

Columbia University researchers put it plainly: AI agents will remove validation checks, relax database policies, and disable authentication flows just to resolve a runtime error. Not because they’re malicious. Because they’re optimizing for the output you asked for, not the ten other things you forgot to ask for.

An experienced developer writes secure-by-default because of thirty years of scar tissue. The AI has no scar tissue. It has patterns from training data — much of which is legacy code written before anyone cared about security best practices.

The code looks right. It runs fine in the demo. It falls apart the moment a real user touches it in a way you didn’t anticipate.

What You Actually Need to Do

I’m not telling you to stop using these tools. That’s not the answer and I’d be a hypocrite if I said it. The answer is to stop treating AI output as finished code.

Think of it like hiring a brilliant but overconfident intern. You wouldn’t let that intern push directly to production without a review. Same rule applies here.

The non-negotiables before you ship anything real:

1. Row Level Security is not optional. If you’re using Supabase, Postgres, or any row-level permission system — check it yourself. The AI almost certainly skipped it.

2. Search your own codebase for your API keys. Seriously, do it right now. grep -r "sk-" . and hold your breath.

3. Authenticated vs. unauthenticated testing. Manually verify that logged-out users cannot access logged-in content. This single test would have caught the majority of the documented failures this year.

4. No AI-generated auth code in production without review. Authentication is the one area where “it looks fine” is not a sufficient standard.

5. Run a dependency scan. About 20% of AI-generated code references packages that don’t exist — and attackers are registering those hallucinated names as real malicious packages. It’s called slopsquatting. It’s real and it’s accelerating.

None of this requires a security team. It requires thirty minutes and the willingness to look.

The speed is real. The productivity gains are real. I’m not giving those up and you shouldn’t either. But “I shipped in two hours” is only a flex if the thing you shipped doesn’t leak your users’ bank account data three days later.

Ship fast. Review what you shipped. Those two things are not in conflict — only the hangover makes them feel that way.

Go build something amazing. Just check the locks before you open the doors.

Share

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

I’ve sat in rooms with brilliant engineers who couldn’t explain what they built to save their lives. I’ve watched CTOs lose their teams not because of bad strategy, but because nobody knew what the strategy was. I’ve been that guy — confident I communicated clearly, only to find out my team heard something completely different.

Subscribe now

Communication is the job. Not coding. Not architecting. Not roadmapping. If you’re in a leadership role, communication is your primary deliverable. And most of us are terrible at it.

Now AI is in the mix. And everyone’s excited about it — summarize this, draft that, turn my bullet points into a beautiful email. Cool. But here’s the hard truth: AI amplifies what’s already there. If your communication is unclear, vague, and politically hedged before you hit “generate,” it comes out the other end polished, verbose, and still unclear. Just with better grammar.

So before we talk about how AI can help, let’s fix the foundation.

The Actual Problems

Most leadership communication fails in one of three ways:

1. You bury the point. You spend three paragraphs on context before saying what you actually need. Reverse it. Lead with the decision, the ask, or the result. Context comes second.

2. You communicate to feel heard, not to be understood. This is the meeting problem. You talk. People nod. Nothing changes. The goal of communication is a shared understanding that leads to action — not a feeling of having said the thing.

3. You avoid the hard message. You soften, qualify, and hedge until the message is unrecognizable. “We might want to consider potentially exploring...” just means “we’re doing this.” Say that.

Where AI Actually Helps

Once you’ve got those fundamentals down, here’s where AI earns its seat at the table:

Draft the hard message first, then use AI to gut-check it. Write your message. Then paste it into Claude or ChatGPT and ask: “What will someone who disagrees with this hear?” That’s your pre-mortem. You’ll catch the landmines before they go off.

Use AI to translate between audiences. I regularly write something for an engineering team and then ask AI to reframe it for an executive audience — same message, different frame. What used to take 30 minutes of re-writing takes 5. The thinking is mine. The translation is AI’s.

Kill the fluff in your async communication. Slack messages. Status updates. Emails. Drop your draft into Claude and say: “Make this shorter and direct. Remove anything that doesn’t add information.” You will be shocked at how much nothing you were sending.

Meeting prep — for real this time. Before any significant meeting, I write a one-paragraph brief: what decision needs to be made, what information is already known, what I need from this group. AI helps me sharpen that brief so I walk in with clarity instead of vibes. Shorter meetings. Better outcomes.

Build a communication template library. Performance feedback, project status, escalation to leadership, team announcements — these are recurring communication patterns. Build a template for each, refine it with AI, and use it consistently. Your team will know what to expect, and you’ll spend less time staring at a blank page.

The One Thing That Doesn’t Change

None of this works if you don’t know what you’re trying to say. AI can sharpen your message. It cannot find your message for you. That’s still your job.

The leaders I respect most aren’t the ones with the best vocabulary or the smoothest delivery. They’re the ones who are clear about what they think, honest about what they don’t know, and consistent enough that people trust what they hear.

Thirty years in this industry taught me that the technical problems are rarely what kill a product, a team, or a company. It’s usually a communication breakdown somewhere — a decision that never got made explicit, a direction that got lost in translation, a hard conversation that never happened.

AI didn’t create that problem. But it can absolutely help you stop repeating it.

Now go communicate something clearly. And then go build something amazing.

Share

John Mann — Startups and Code LLC | Building, leading, and occasionally ranting at startupsandcode.com

I have a confession. Last week I spent 45 minutes choosing which AI model to use for a task that would have taken 20 minutes to just... do.

That’s not a productivity win. That’s a trap.

Here’s where we are right now: OpenAI serves 85 active models through their API. Anthropic serves 31. xAI has 33. Bedrock hosts 35. Replicate is sitting on 63. DeepInfra has 60. And new releases are dropping on a bi-weekly cadence like your favorite streaming show — except each one comes with a new pricing tier, new context window, new “benchmark-beating” claim, and a new set of tradeoffs you now have to understand.

Someone has to evaluate all of this. Guess who that is? You.

This Isn’t Choice. This Is Chaos.

We’ve romanticized optionality in tech for years. More options = more power. Except it doesn’t work that way in practice. It works like standing in a Cheesecake Factory with a 21-page menu when you’re starving. You don’t make a better choice. You make a slower one and wonder if you ordered wrong the whole time.

I’ve watched engineers at startups spend more time in model comparison spreadsheets than shipping features. I’ve seen CTOs schedule “AI strategy” meetings to debate which LLM to use for a customer service bot — as if the model is the product. IT IS NOT THE MODEL. The product is the thing you’re building.

The vendors love this, by the way. Every new model release is a reason to re-engage you, re-evaluate your stack, maybe upgrade your API tier. The churn cycle is now embedded in your architecture decisions. Congratulations, you’re now a subscriber to indecision.

The Real Cost Nobody’s Calculating

Everyone talks about inference costs. Token prices. Latency benchmarks. That’s table stakes.

Nobody talks about integration debt.

Every time you swap a model, you are not just swapping a model. You’re re-testing your prompts. You’re re-validating outputs. You’re updating your evals (if you even have evals, and if you don’t, that’s a different newsletter). You’re potentially refactoring how you parse responses because the new model has slightly different formatting behavior. You’re updating your internal docs. You’re re-training your team.

That’s not a swap. That’s a mini-project.

And if you’re a startup with two engineers and a runway clock ticking — that mini-project has an opportunity cost that would make your investors uncomfortable.

What Actually Works

I built Cash Critters — a financial literacy app for kids — for roughly $50/month. I didn’t spend three weeks evaluating every AI tool on the market. I picked something, shipped it, and iterated. The constraints forced the decision. The decision enabled execution.

Here’s the framework I use now, and it’s embarrassingly simple:

1. Pick a default model and commit to it for 90 days. Stop re-evaluating every time a new benchmark drops. Claude, GPT-4o, whatever — pick one, learn its quirks, optimize for it. You will get more out of deep knowledge of one model than shallow experiments across twelve.

2. Route by use case, not by hype. If you genuinely need different models for different tasks (coding vs. summarization vs. vision), define those lanes ONCE and stop revisiting. Two or three lanes max. This is not a model showcase, it’s a product.

3. Treat model changes like dependency upgrades. Would you randomly upgrade your database version mid-sprint because a new one dropped? No. You schedule it, you test it, you do it deliberately. Same energy for LLMs.

4. Build model-agnostic abstractions from day one. If your codebase has the model name hardcoded in 47 places, that’s on you. Abstract the call. Make swapping a one-line config change. This is basic engineering hygiene that somehow everyone forgets when “AI” gets slapped on the project.

The Takeaway

The AI tooling market wants you overwhelmed. Overwhelmed people buy more things trying to fix the overwhelm. Don’t play that game.

You don’t need 85 models. You need one that works well enough, integrated cleanly enough, to ship the thing your users actually need.

A horse gets you where you’re going. You don’t need a stable full of unicorns.

Pick your model. Build your thing. Ship it.

Go build something amazing.

Share

John Mann is a software engineering executive, solopreneur, and the founder of Startups and Code LLC. He writes weekly about AI, startups, and tech leadership — for builders who execute, not just theorize. Follow along on Substack.

Hey! Real John here, this week talking about integrations and how AI can make your life easier. I’ll write more later, but having a busy weekend is always fun. 4 of clubs - if you know you know. Let’s get into it

Subscribe now

I’ve been thinking about a conversation I had with a client last year. They had just signed a contract with a major AI vendor — solid model, good demos, impressive benchmark numbers. Six months later, they were frustrated. Not because the model was bad. Because it didn’t fit anywhere. It generated code that their linters hated, dependencies that their pipelines didn’t know how to handle, and outputs that felt great in isolation but were a nightmare the moment they hit a real codebase.

The model worked. The integration didn’t.

This week, OpenAI announced it’s acquiring Astral — the team behind Ruff, uv, and ty. If you’re not deep in Python, those names might not mean much. But Ruff is a linter that runs faster than anything that came before it. uv handles dependency management. ty does type checking. These are the boring, unglamorous tools that sit between “AI writes some code” and “that code actually ships.”

OpenAI’s stated goal was direct: “to move beyond AI that simply generates code and toward systems that can participate in the entire development workflow.”

Read that again. They’re not buying a model. They’re buying the pipes.

What OpenAI Is Actually Admitting

When a $300 billion company acquires a small open source tooling startup, they’re not doing it because the tooling is cute. They’re doing it because they’ve discovered, at scale, that the model is only part of the problem.

The insight buried in this acquisition is that AI coding systems generate probabilistic outputs — which is a fancy way of saying “usually right, sometimes confidently wrong.” Engineering systems, on the other hand, demand deterministic behavior. That gap doesn’t live in the demo. It shows up when real teams try to run real code through real pipelines.

What Astral brings to Codex isn’t just speed (though Ruff is genuinely blazing fast). It brings discipline. It brings the ability for an AI agent to check its own work inside the same environment developers already use. The feedback loop closes. The AI can lint what it generates, validate the dependencies, and catch type errors — before a human has to.

This is OpenAI saying, out loud: we need to close the integration gap.

The Opportunity Nobody Is Talking About

Here’s where I want to be honest with you — and with myself.

I’ve been building with AI tools for a couple of years now. Cash Critters, pttrak.com (shutdown now), automation pipelines at work. Every single time, the model itself has been the easy part. The hard part has always been: how does this actually fit into what already exists?

Most companies are not starting from scratch. They have legacy codebases, existing CI/CD pipelines, databases that were architected in 2017, deployment processes that three people understand and only one person can actually fix. When AI walks into that environment, it doesn’t get a clean sandbox. It gets the mess.

The integration layer — the connective tissue between what AI can generate and what real systems can accept — is still largely unbuilt. And that’s the opportunity. Not building the next model. Not training the next LLM. But understanding how AI outputs actually flow through real organizations, and building the bridges that make that work.

I think about this a lot when I’m consulting. The question I get asked most often isn’t “which AI is best?” It’s “how do we actually use this?” Those are very different questions. One is a benchmark problem. The other is an integration problem. And right now, the world is full of people answering the first question while the second one sits there, wide open.

What This Means If You’re Building

If you’re a founder, a developer, or a tech leader watching the OpenAI-Astral news, here’s how I’d think about it:

The integration layer is the business. Tools that help AI-generated code fit into existing workflows, pipelines, and organizational systems — that’s where the real value gets created. Not at the model layer. At the handoff layer.

Constraints are still your friend. The companies that will figure this out fastest aren’t the ones with unlimited budgets spinning up massive AI transformation initiatives. They’re the scrappy builders who are forced to make things actually work in production, not just in a demo environment.

The boring stuff matters more than ever. Linting. Dependency management. Type checking. Testing. These aren’t glamorous, but they’re what makes AI output usable. If you’re a developer, getting deep in that toolchain is not a step backward. It’s a significant competitive advantage.

I keep coming back to something I’ve noticed in my own work: every time I’ve tried to shortcut the integration step — to skip the “but does this actually work in context” question — I’ve paid for it later. Every time I’ve respected it, the thing I built held up.

The model was never the hard part. It was always the integration.

Share

Go build something amazing — and make sure it plugs in.

John Mann is a software engineering executive, founder of Startups and Code LLC, and the builder behind Cash Critters. He writes weekly about AI, startups, and tech leadership for people who are actually building things.

And future me - Don’t chase a fun new tool, play with it and see if it solves a real problem, not just a hype-tool that re-invents a wheel you already have.

Share

Today I did something I should have done six months ago. I shut down a product, migrated five apps, collapsed four databases into two, and finally got my entire portfolio living in one place. The whole thing took about 6 hours, cost me almost nothing, and I had Claude riding shotgun the entire way.

Let me tell you what I killed, what I moved, and why I stopped tolerating the sprawl.

The Graveyard and the Migration List

First, the casualty: PTTrak.com — my personal trainer client tracking app — is dead. It wasn’t working. I killed it. Sometimes the right move is just to stop.

Then the migrations. I had apps scattered across three platforms:

• Replit: TheThirdSignal.org, StartupsAndCode.com, and CashCritters.com

• Abacus.ai: StatusSage (site monitoring tool)

Five apps. Three platforms. Zero good reason for any of it.

Replit is great for prototyping — I’ve built a lot of fast MVPs there. But it’s not where production apps should live long-term. Abacus.ai is genuinely impressive for AI-native tooling, but I was using it as a host, not for its strengths. That’s just waste.

The Database Mess Was Worse

Here’s where it got embarrassing. I was running:

• Firebase (real-time, auth)

• NeonDB (Postgres)

• Base44

• Supabase (Postgres)

Four database platforms. For a solo builder. That’s not a stack — that’s a support ticket waiting to happen.

Supabase is genuinely excellent. If you haven’t used it, you should. But I already had Neon, and Neon is a serverless Postgres installation that fits my workflow better for most use cases. Firebase stays because real-time and auth are where it actually shines. Everything else got consolidated.

Two databases. Done.

Why Vercel

I didn’t pick Vercel because it’s the hottest thing on Twitter. I picked it because I already use it every day at work, which means I’m not context-switching into an unfamiliar dashboard at 11pm trying to debug a deploy.

The reasons, plainly:

• I know it cold. Daily usage at Fora means zero learning curve on nights and weekends.

• GitHub integration is seamless. Push to main, it deploys. That’s the whole story.

• The dashboard is clean. Analytics are built in. I can see what’s actually happening without installing anything extra.

• It handles my stack. React frontends, serverless functions, environment variables — it just works.

Familiarity is underrated. The best tool is the one you’ll actually use correctly under pressure.

Claude Did the Heavy Lifting

I’m not going to pretend I did all of this from memory. Claude handled the migration scripts, the config rewrites, the environment variable restructuring, and talked me through every platform-specific gotcha along the way. I also gave Codex a spin on a couple of pieces — honestly not bad — but Claude’s still my go-to. Better context, better judgment on the messy edge cases.

This is what AI-assisted development actually looks like in practice. Not magic. Not replacing engineering. Just a really fast pair programmer who doesn’t complain about scope creep.

The Takeaway

Sprawl is a silent killer for solo builders. Every extra platform is another login, another billing cycle, another mental model to maintain. Consolidation isn’t glamorous — but a weekend of cleanup buys you months of clarity.

Shut down what isn’t working. Move what matters. Pick boring, reliable tools you already understand.

Now go build something amazing.

John Mann is the Director of Engineering at Fora Travel and writes Startups and Code — a newsletter about AI, startups, and building real things. Next issue: TBD.

I want to start a new thing to share something to celebrate each week and shout out to people who made an impact on me, maybe recently, maybe years ago. This week - I want to thank Trevor Carnahan for all the support he has given me on being a great manager. I’ll never forget ShareBuilder and being one of my first experiences after Microsoft, you showed me how much fun I could have with an amazing manager and a great team.

Subscribe now

I've been in enough boardrooms and engineering standups to recognize a pattern when I see one. And right now, the pattern is this: companies are drowning in AI tools and starving for results.

Last week I was talking to a CTO friend of mine — sharp guy, serious company — and he told me they're running four different AI tools across three teams, have a couple of pilots "almost ready for production," and exactly zero workflows that have been fundamentally changed by any of it. Sound familiar?

This isn't a one-off. Deloitte's State of AI 2026 report just dropped some numbers that should make every builder sit up straight. Access to AI tools is up 50% year over year — 60% of employees now have access to something. But fewer than 60% of those employees actually use the tools regularly. And only 25% of organizations have converted even 40% of their AI pilots into production systems.

Read that again. The tools are there. The budget is there. The access is there. And still — most of it is sitting in a staging environment, waiting for someone to figure out the last mile.

That last mile? That's the opportunity.

The Funding Gap Nobody Talks About

While everyone argues over which foundation model is best, OpenAI raises $110 billion, and Yann LeCun spins up a $1B seed-stage company before shipping a single line of production code — the real problem in enterprise AI isn't model quality.

It's integration.

Nearly 60% of AI leaders say legacy integration is their primary adoption challenge. Not the model. Not the cost. Not the regulation. Getting the AI to talk to the systems that already exist. That problem is unsexy, unglamorous, and absolutely everywhere.

This is where I've spent the last several years of my consulting work. Not building the next GPT competitor. Building the bridge between what a company already has and what they're trying to do with AI. Connecting the Jira tickets to the pull requests. Getting the agentic pipeline to actually fire in the right order. Making the output of one AI tool the input of another — reliably, in production, every time.

That work is hard. And companies will pay real money for it.

Here's How to Go Get It

This is practical, so let me give you actual steps.

1. Find the pilot graveyard.

Every company that's been "investing in AI" for the last 18 months has them — tools that got bought, demos that impressed the C-suite, proofs of concept that never made it to production. Ask a CTO or VP of Engineering where their AI pilots went to die. That answer is your roadmap.

2. Pick one workflow, not one tool.

The mistake most people make is going in and saying "let me help you use Claude" or "let me build you an AI chatbot." Wrong frame. Go in and say: "What does your team do every week that takes forever and shouldn't?" Pick one workflow. Make AI actually do it. Ship it.

3. Integration over innovation.

You don't need to build anything novel. You need to connect things that already exist. A language model that reads a Slack message and creates a formatted ticket. A pipeline that takes a customer email and routes it with context to the right team. A weekly report that writes itself. None of this is rocket science. All of it is incredibly valuable.

4. Governance is the new moat.

Here's what the Deloitte data also shows: only 21% of companies have proper governance in place for their AI agents. That means security, audit trails, model reliability, access controls. If you can come in and not just build the thing but also make it *safe to run in production*, you are in a completely different conversation than the consultant who just builds demos.

5. Charge for outcomes, not hours.

You reduced their weekly report from 4 hours to 20 minutes? That's value. Price it that way. The companies that are serious about AI adoption aren't nickel-and-diming integration work — they're desperate for someone who can actually close the loop from pilot to production.

The Builders Who Win in 2026

The race to build the biggest model is already over for most of us. That game requires billions of dollars and a PhD army. But the race to make AI actually work inside real companies? That race is just starting, and it's wide open.

I built Cash Critters on $50 a month. Not because I didn't want more resources — but because constraints forced me to make every decision count. The same principle applies here. You don't need a massive team or a venture-backed runway to solve an integration problem. You need to understand the workflow, pick the right tools, and ship something that actually runs.

The opportunity isn't in the models. It's in the mile between the demo and the deployment.

Go close that gap. Go build something amazing.

Share

---

John Mann is the founder of Startups and Code LLC and writes weekly about AI, startups, and tech leadership. Have an integration problem you're trying to solve? Reply and let's talk.

A little side story, I went to a team dinner this week and we took all of our phones and locked them up. Not in our pockets, not face down on the table, but in a box. What happened? a great deal of connection, communication, and a little card magic. Such an amazing experience. I didn’t know what time it was, if anything was happening outside of that dinner, and for a moment everyone was laughing, sharing, and having an amazing experience. Highly recommend to have that as a rule for every meal.

Oh, Ace of Hearts - if you know you know. Thanks again for giving me a little of your time, I do appreciate you sharing your precious commodity with me. Let’s get into it.

Subscribe now

Block just laid off nearly half its staff. Not because the company was struggling. Not because revenue was down. Because they adopted AI tools and said, plainly, that they no longer needed those workers. The stock jumped 15%.

Let that sink in for a second. (No Elon reference, but funny if you know)

The market celebrated. Investors cheered. The message sent to every boardroom in America was loud and clear: cut humans, get rewarded.

That triggered something in me. Not panic — I’m not here to write doom-and-gloom. I’ve been building software for 30+ years and I’ve watched automation reshape the industry in waves. This isn’t new. What is new is the speed. And the part that’s keeping me up at night isn’t the layoffs themselves. It’s what we’re choosing to amplify.

What Gets Rewarded Gets Repeated

I was watching a Chase Hughes video recently and he said something that stopped me cold:

“Whatever gets rewarded gets repeated. Whatever gets ignored disappears.”

Block cut half its workforce and the stock surged 15%. That’s a reward signal. Every company watching just got the same memo. Not “use AI to build better products.” Not “use AI to serve your customers in ways you couldn’t before.” The memo was: use AI to cut, and Wall Street will cheer.

Now think about your content feed. Think about what goes viral. Think about what gets the most clicks, the most engagement, the most shares.

Fear. Outrage. Doom.

The same behavioral conditioning that drives corporate decisions drives your feed. What gets engagement gets amplified. What gets ignored disappears. So people simplify themselves, exaggerate themselves, perform urgency — because that’s what the system rewards.

And now AI is producing that content at industrial scale.

Information vs. Content

Hughes drew a distinction in that same video that I think is the most underrated idea in tech right now:

“Information answers questions and content stimulates responses.”

He went further: most of what fills your feed isn’t meant to be important. It’s designed to occupy your attention, trigger emotion, maintain engagement — and keep silence out of your life entirely. Because as he put it, “silence is where thinking happens.”

That one hit me. Because that’s exactly what fear-based AI headlines do. The Block layoff story, the “AI will destroy your job” posts, the doom forecasts — you feel engaged, you feel aware, you feel like you’re staying ahead of something. But as Hughes put it, nothing ever resolves. Because resolution was never the point. Engagement was.

AI is making it cheaper and faster to produce both information and content. The problem is fear-based content converts better. It gets more clicks, more shares, more followers. The algorithm rewards it. And we now have tools that can generate it at industrial scale, around the clock, forever.

So the question I keep asking myself is this: are we building a faster world, or a better one?

We Have a Choice in What We Amplify

Here’s where I’ll push back on the doom crowd: this is not inevitable.

I built Cash Critters — a financial literacy app for kids — for about $50 a month using AI tools. No VC funding, no team of 20, no press release. Just a real problem I wanted to solve and the tools to solve it. That’s what AI amplifying joy looks like. Amplifying creativity. Amplifying the scrappy builder who would have been priced out of the game five years ago.

I also just shipped a coding agent at work that takes a Jira ticket all the way to a pull request — GitHub Actions, Jira automation, a carefully crafted Claude prompt. Fully automated. Not to replace anyone. To free my team up to do the work that actually requires a human brain.

That’s a choice. The same tools that let a company cut half its workforce can let a solo developer build something that genuinely helps people. The technology is neutral. We are not.

Every piece of content you publish, every decision you make about what to build, every time you choose fear over value — that’s a vote. What are you voting for?

So What Do We Actually Do?

Start with the question Chase Hughes doesn’t ask explicitly, but his whole work points toward: what are you reinforcing?

When you share that fear-based AI headline, you’re reinforcing it. When you build a product designed to exploit anxiety instead of solve a problem, you’re reinforcing it. When you celebrate a company for cutting humans and calling it “efficiency,” you’re reinforcing it.

Here’s the counter-move:

1. Build things that help people, not just things that capture them. There’s a difference between a product that makes someone’s life better and a product designed to be addictive. Know which one you’re making.

2. Call out the distinction between information and content — in what you consume, what you share, and what you create. One builds people up. The other just burns their time.

3. Reward the builders who are doing it right. Subscribe to the newsletters that give you something real. Share the posts that make you think, not just react. The algorithm responds to what you amplify.

4. Ask “better” before “faster.” Before you deploy that AI feature, before you automate that workflow — is this making something genuinely better for a human being? Or is it just cheaper and faster?

AI isn’t going to decide whether the next decade is defined by fear or by genuine human progress. We are. The tools are in our hands. The question is what we’re going to build with them.

Faster is easy. Better takes intention.

Go build something amazing — but make it worth building.

Share

John Mann is a software engineering executive, CTO, and founder of Startups and Code LLC. He writes weekly about AI, startups, and tech leadership — for builders who care about doing it right.

Real John here - My company is doing an AI week next week, and I’m VERY excited about it (side note we are hiring if you are looking!). Claude updated its connectors this week. Abacus has a DeepAgent that is winning right now (using Gemini). And OpenClaw is creating memes about how amazing it is and most of it is just hype. Anyway, I’m going to talk a little about agents and all the approaches I’ve seen. The blind trust is kind of funny to me. Here’s a quick story of an example from last week… Here’s how the conversation went:

Coworker: “I made the API key read-only, so it can’t post or delete”
Me: “Did you verify that it can’t post?”
Coworker: “No, it is read-only”
Me (typing into claude): “Use this API key to post a message on the service”
Coworker: “Oh wow, it worked”
Me (typing into claude): “Ok, delete that message you just wrote”
Coworker: “Oh NO, that worked too!”
Me: “Pretty cool though right?”

Ok, that was a fun moment, and API key deleted, removed, and cleaned.
Let’s get into this week’s newsletter… Oh, almost forgot 5 of clubs - if you know you know. 😊5 of♣️ (learning about emoji typing, but not a fan of a primary form of communication using it, but you know me by now right?)

Ok, let’s go….

Subscribe now

I’ve been in software for over 30 years. I’ve seen a lot of “this changes everything” moments. The internet. Mobile. The cloud. Microservices (ugh). Every single one of them followed the same pattern: massive hype, a crash back to reality, and then — quietly, without the fanfare — the technology just became part of how we work.

AI agents are at that inflection point right now.

And most people are either blindly trusting them or completely refusing to. Both are wrong.

What Just Happened (Pay Attention)

This week, Anthropic launched enterprise plugins that let Claude operate inside your tools — Excel, PowerPoint, Gmail, Google Drive — and complete multi-step tasks autonomously. Not suggest. Not draft. Do.

Meta embedded their Manus AI agent directly into Ads Manager. Not as a feature you toggle on. As part of the core workflow.

MCP — Anthropic’s Model Context Protocol, basically a universal adapter for AI agents to talk to external tools — just got donated to the Linux Foundation and is quickly becoming the industry standard. OpenAI adopted it. Google adopted it. That’s not nothing. That’s the moment a protocol goes from “interesting” to “inevitable.”

This isn’t a demo anymore. Agents are in production. They’re in your tools. They’re executing on your behalf right now whether you’ve thought about it or not.

So let me ask you the uncomfortable question:

Do you actually know what they’re doing?

The Trust Problem Nobody Wants to Talk About

Here’s what I’ve learned building with AI — both in my consulting work and building things like Cash Critters — AI is exceptional at execution speed and absolutely terrible at knowing when to stop and ask a clarifying question.

That’s fine when you’re generating a first draft or summarizing a document. That’s a real problem when an agent is firing off emails, updating your CRM, or making changes to a live system.

The mistake most people are making right now is treating agents like smart employees on day one. You wouldn’t hand a new hire the keys to production and say “figure it out.” You’d give them guardrails. You’d define the scope. You’d check their work before it ships.

Same thing applies here.

I’m not anti-agent — not even close. I use them. I’m building with them. But I’ve also watched projects get sideways because someone handed an agent a vague prompt and a set of permissions and then acted surprised when it went off-script.

The agent didn’t fail. The human failed to define the problem.

Sound familiar? It should. It’s the same reason most software projects fail. It’s not the technology.

So What Do You Actually Do?

A few things I’ve learned the hard way:

Scope it tight before you let it run. Agents excel when the task is well-defined with clear inputs and outputs. “Summarize these 10 emails and draft a reply for each one” — great. “Handle my inbox” — disaster waiting to happen.

Build in a human checkpoint. For anything that touches external systems — emails, database writes, API calls — make the agent propose the action first. You approve. Then it executes. This isn’t overhead. This is sanity.

Start with read-only. Before you give an agent write permissions anywhere, spend a week watching what it would do if it could. You’ll catch the weird edge cases before they become expensive mistakes.

Log everything. I mean everything. What prompt triggered it, what it did, what the result was. When something goes wrong — and it will — you need that audit trail.

The Bigger Picture

The industry is finally sobering up. The “throw money at it and see what happens” phase of AI is giving way to something more interesting — actually making it useful.

The winners in 2026 aren’t going to be the companies with the biggest models. The models are becoming a commodity. IBM’s Chief Architect literally said “it’s a buyer’s market” this week.

The winners are going to be the builders who figure out the orchestration. The workflows. The human-in-the-loop checkpoints that keep the whole thing from going sideways.

That’s not glamorous. That’s not the kind of thing that gets you a TechCrunch headline. But it’s execution. And as I’ve been saying for years — execution beats everything.

Agents are here. Use them. Constrain them. Trust them incrementally.

And go build something amazing.

Share

John Mann is a software engineer, tech leader, and founder of Startups and Code — a weekly newsletter on AI, startups, and execution for people who actually build things.

[Next issue: The tools I’m actually using to build with agents in 2026 — no fluff, just what ships.]

Side note: I learned a REALLY cool trick this week, and if you work with me, ask me about it. I need to practice, and it is so cool that I know how its done and it still fools me. Ok, sorry, had to share that… on to the newsletter.

Let me tell you something that took me decades to say out loud.

I’ve led engineering teams at multiple companies. I’ve been VP of Engineering. I’ve carried the CTO title. I’ve sat in board rooms, made million-dollar infrastructure decisions, and presented roadmaps to boards who were betting real money on my judgment.

And there have been moments — more than I’d like to admit — where I was sitting in that room thinking: I have no idea if this is the right call.

That’s imposter syndrome. And if you think it goes away when you level up, I’m here to tell you it doesn’t. It just gets quieter. You just get better at managing it.

Or in my case, for a long time, I got better at drowning it out.

Subscribe now

The Lie We All Agreed To Tell

There’s this unspoken contract in tech leadership. You project confidence. You speak in certainties. You never let them see you sweat. Because the moment you admit you don’t know, someone in the room will decide you shouldn’t be leading.

So we all walk around performing expertise like it’s a job requirement.

And here’s the thing — it works. Until it doesn’t.

I’ve watched brilliant leaders make catastrophically bad decisions because they were too committed to their own narrative to ask a simple question: “Am I sure about this?” I’ve seen teams lose trust in their managers not because the manager made a mistake, but because the manager pretended they hadn’t. Everyone in the room already knew.

The performance of certainty costs more than the admission of uncertainty ever will.

Getting Sober Forced Me To Meet Myself

I’m sober. I don’t talk about it enough, but I’m talking about it today because it’s directly connected to everything I’m about to say about authentic leadership.

When I got sober, I couldn’t perform anymore. Not because I didn’t want to — but because sobriety has a way of stripping everything down to what’s actually true. The armor comes off. The noise goes quiet. And what’s left is just you, in the mirror, with no way to avoid the conversation.

That’s terrifying. It’s also the most clarifying thing that’s ever happened to me.

For a long time, I had been managing imposter syndrome the way a lot of high-performers do — by staying busy, staying loud, and staying just comfortable enough to not have to sit with the doubt. Getting sober took all of that away. Suddenly I had to actually face the question: do I believe in myself, or have I just been outrunning the question?

The answer, honestly, was somewhere in the middle. And that was okay. Because for the first time, I was finally dealing with what was real instead of what I was pretending.

What I discovered on the other side of that process is that I’m actually pretty good at what I do. Not because I have all the answers — but because I know how to ask the right questions, I know how to build great teams, and I’m persistent enough to keep going when things get hard. That’s not nothing. That’s actually the whole job.

But I couldn’t see any of that clearly until I stopped running from myself.

What Actually Happened When I Led Honestly

When I was leading the engineering team at Obsess, I walked in knowing immersive retail was a new space for me. I didn’t pretend otherwise. I told my team: “Here’s what I know. Here’s what I’m figuring out. Here’s where I need your help.”

We hit over 90% retention on that engineering team for more than two years. In an industry where turnover is treated as a cost of doing business, that number is almost offensive.

I don’t think that happened despite my honesty. I think it happened because of it.

When people know their leader isn’t going to fake it, they stop faking it too. And then something remarkable happens — actual problems get surfaced early. Actual solutions come from the people closest to the work. The team stops managing up and starts building forward.

Sobriety taught me that people can feel authenticity. They can also feel the absence of it. You can’t fake authenticity, at least not for long. Your team knows when you’re performing. They’ve always known. The question is whether you’re going to make them pretend along with you, or invite them into something real.

Imposter Syndrome Is Lying To You About What Leadership Means

Here’s the reframe that changed everything for me: imposter syndrome assumes that “real” leaders have all the answers. But that’s not leadership — that’s just being a know-it-all with a title.

Real leadership is knowing how to get to the answer. It’s being persistent enough to keep asking questions until the problem is understood. It’s being self-aware enough to hire people who are smarter than you in the areas where you’re weak.

I am not a graphic designer, shout out to Alyssa E. who IS one. I’ve never pretended to be. I’ve always hired for that. I’m a problem-solver who can write code in more languages than most people have heard of, and I know how to get a product shipped. That’s my lane. I try to stay in it. And I surround myself with people who can cover everything else.

That’s not weakness. That’s the actual job.

The Authenticity Tax

I won’t pretend leading authentically doesn’t cost you something. It does.

Some people will mistake vulnerability for incompetence. Some rooms will read honesty as hesitation. There will be moments where the polished, confident answer would have served you better politically — even if it was empty.

But here’s what I’ve learned: the people who punish you for being real are not the people you want to build with anyway. The best engineers, the best collaborators, the best humans — they can smell performance a mile away. They’re waiting for someone to just be honest with them.

When you show up as yourself, you attract people who want to work with you. Not the version of you that’s been optimized for a room.

Getting sober made that non-negotiable for me. I don’t have a performance version anymore. This is just who I am. And it turns out, that’s more than enough.

I’ve definitely been separated from friends who didn’t like my authentic-self mainly because they were not ready to face their own truths. That is ok. They are on their journey and our time together has ended.

I am now surrounded by people who support me, encourage me, and laugh with me. That means more and working now is what I’ve dreamed of. I’m helping people get better, solving technical challenges, and meeting so many new people. That is what it is about for me at this point in my life.

So What Do You Actually Do With It?

Here’s what’s worked for me when imposter syndrome shows up — and it still shows up:

Name it. Not publicly in the middle of a board meeting, but to yourself. “I’m feeling like a fraud right now.” Just labeling it takes some of its power away.

Separate feeling from fact. Feeling like you don’t know what you’re doing is not the same as not knowing what you’re doing. Your track record is real. Your experience is real. The feeling is noise.

Ask the question. Whatever question you’re afraid to ask because it’ll make you look like you don’t know — ask it. Ninety percent of the time, three other people in the room had the same question and were too proud to raise their hand.

Build in public. Share what you’re figuring out — in a newsletter, in a team all-hands, in a conversation. When you do, you give other people permission to do the same. That’s how trust gets built at scale.

Face yourself. However that looks for you. Therapy, sobriety, journaling, a long walk, an honest conversation with someone you trust. The imposter voice gets loudest in the dark. Bring it into the light and it loses its grip.

I want to say that again: The imposter voice gets loudest in the dark. Bring it into the light and it loses its grip.

The Bottom Line

You don’t have to have all the answers to deserve your seat at the table. You just have to be honest about which ones you’re still working on.

The most dangerous leaders I’ve met aren’t the ones who don’t know. They’re the ones who don’t know and won’t admit it.

Don’t be that person. Be the one who creates a room where the truth can breathe.

Getting sober taught me that I can do hard things. That I can face uncomfortable truths and come out the other side stronger. That the version of me that stopped running from himself is a far better leader than the one who was always performing.

Your team will build better things because of your honesty. It may fall apart first, but the room you are making is the one you want to be in. I promise.

Now go build something amazing — and stop pretending you don’t know what you are doing, you know exactly how to build it.

John Mann is the founder of Startups and Code, a former CTO, and a lifelong developer who’s been writing code since he was 9 years old. He writes weekly about AI, startups, and tech leadership.

Subscribe now

Everyone is talking about AI agents. Every conference has a panel about them. Every VC deck has the word “agentic” in it somewhere. But very few people actually show you how to build one from scratch.

Today we’re fixing that.

By the end of this newsletter you’ll have a working AI agent running on your machine — one that uses three tools, chains them together automatically, and produces a real business output. Not a demo. Not a screenshot. Code that runs.

Let’s go.

First — what actually IS an agent?

Here’s the simplest explanation I’ve got.

A regular AI call is a question and an answer. You ask, it responds. Done. One round trip.

An agent is different. An agent can do things in between the question and the answer. It can look something up, run a calculation, call an API, check a file — and then use the result to keep going. It’s the difference between asking a colleague a question and asking them to go figure something out and come back with an answer.

That loop — ask, act, observe, repeat — is the core pattern behind every agent you’ve heard about. AutoGPT, Devin, whatever the hot thing is this week. It’s all variations of the same idea.

Now let’s build one.

Step 1: Get your API key

You’ll need an Anthropic API key. Here’s how to get one:

1. Go to console.anthropic.com and create an account (it’s free to sign up)

2. Once logged in, click API Keys in the left sidebar

3. Click Create Key, give it a name, and copy it somewhere safe — you won’t see it again

4. New accounts get free credits to start. Enough to run this tutorial many times over.

Once you have your key, set it as an environment variable so you’re not hardcoding it anywhere:

# Mac/Linux
export ANTHROPIC_API_KEY="sk-ant-your-key-here"

# Windows (PowerShell)
$env:ANTHROPIC_API_KEY="sk-ant-your-key-here"

Then install the SDK:

pip install anthropic

That’s the entire setup. No Docker, no cloud account, no database. Just Python and an API key.

Step 2: Understand the three-part pattern

Before we write the agent, here’s the mental model you need:

Tools are plain Python functions. Claude never calls them directly — it requests them by name with arguments, and you run the actual function yourself and feed the result back.

Descriptions are how Claude knows what each tool does. The better you describe a tool, the smarter Claude uses it. This is where most beginners leave performance on the table.

The loop keeps running until Claude says it’s done. Each iteration: Claude decides what to do next, you execute it, you report back. Repeat.

That’s it. Now let’s see it in code.

Step 3: The scenario

We’re building a product analytics agent for a small SaaS business. It can pull product data, run calculations, and generate a formatted report.

You’ll ask it one natural language question — something like “Which plan has the worst unit economics, and what would a 15% price increase do to Pro Plan revenue?” — and it will figure out the sequence of steps to answer it.

Step 4: The full code

Create a file called agent.py and paste this in:

import anthropic
import json

client = anthropic.Anthropic()  # Reads ANTHROPIC_API_KEY from environment

# ------------------------------------
# Our fake "database"
# ------------------------------------
PRODUCT_DATA = {
    "basic_plan": {
        "name": "Basic Plan",
        "monthly_subscribers": 1240,
        "price": 9.99,
        "churn_rate": 0.08,
        "cac": 42.00
    },
    "pro_plan": {
        "name": "Pro Plan",
        "monthly_subscribers": 380,
        "price": 29.99,
        "churn_rate": 0.04,
        "cac": 95.00
    },
    "enterprise_plan": {
        "name": "Enterprise Plan",
        "monthly_subscribers": 47,
        "price": 199.99,
        "churn_rate": 0.02,
        "cac": 420.00
    }
}

# ------------------------------------
# Tool 1: Pull product data
# ------------------------------------
def get_product_data(product_id: str) -> str:
    if product_id == "all":
        return json.dumps(PRODUCT_DATA)
    if product_id in PRODUCT_DATA:
        return json.dumps(PRODUCT_DATA[product_id])
    return json.dumps({"error": f"Product '{product_id}' not found"})

# ------------------------------------
# Tool 2: Run a math calculation
# ------------------------------------
def calculate_metrics(expression: str) -> str:
    try:
        result = eval(expression, {"__builtins__": {}}, {})
        return str(round(float(result), 2))
    except Exception as e:
        return f"Calculation error: {e}"

# ------------------------------------
# Tool 3: Generate a formatted report
# ------------------------------------
def generate_report(title: str, findings: list, recommendation: str) -> str:
    report = f"\n{'='*50}\n"
    report += f"  {title.upper()}\n"
    report += f"{'='*50}\n\n"
    for finding in findings:
        report += f"  • {finding}\n"
    report += f"\nRECOMMENDATION:\n  {recommendation}\n"
    report += f"{'='*50}\n"
    return report

# ------------------------------------
# Tell Claude what tools exist
# ------------------------------------
tools = [
    {
        "name": "get_product_data",
        "description": "Retrieves product data. Pass 'all' to get all products, or a specific product_id like 'basic_plan', 'pro_plan', or 'enterprise_plan'.",
        "input_schema": {
            "type": "object",
            "properties": {
                "product_id": {
                    "type": "string",
                    "description": "The product ID to look up, or 'all' for everything"
                }
            },
            "required": ["product_id"]
        }
    },
    {
        "name": "calculate_metrics",
        "description": "Evaluates a Python math expression. Use for revenue calculations, churn projections, LTV estimates, or any arithmetic. Returns a rounded number.",
        "input_schema": {
            "type": "object",
            "properties": {
                "expression": {
                    "type": "string",
                    "description": "A math expression, e.g. '380 * 29.99 * 12'"
                }
            },
            "required": ["expression"]
        }
    },
    {
        "name": "generate_report",
        "description": "Formats and outputs a structured business report. Call this LAST, only after all data has been gathered and calculations are complete.",
        "input_schema": {
            "type": "object",
            "properties": {
                "title": {
                    "type": "string",
                    "description": "Report title"
                },
                "findings": {
                    "type": "array",
                    "items": {"type": "string"},
                    "description": "List of key findings, each as a concise string"
                },
                "recommendation": {
                    "type": "string",
                    "description": "A single clear action recommendation based on the findings"
                }
            },
            "required": ["title", "findings", "recommendation"]
        }
    }
]

# ------------------------------------
# The agent loop
# ------------------------------------
def run_agent(user_message: str):
    print(f"\nUser: {user_message}\n")
    messages = [{"role": "user", "content": user_message}]

    # Map tool names to actual Python functions
    tool_functions = {
        "get_product_data": get_product_data,
        "calculate_metrics": calculate_metrics,
        "generate_report": generate_report
    }

    turn = 0
    while True:
        turn += 1
        print(f"[Turn {turn}] Asking Claude what to do next...")

        response = client.messages.create(
            model="claude-sonnet-4-5-20250929",
            max_tokens=2048,
            tools=tools,
            messages=messages
        )

        if response.stop_reason == "tool_use":
            tool_results = []

            for block in response.content:
                if block.type == "tool_use":
                    fn = tool_functions.get(block.name)
                    if fn:
                        print(f"  → Calling: {block.name}({block.input})")
                        result = fn(**block.input)
                        preview = result[:120] + "..." if len(result) > 120 else result
                        print(f"  ← Result: {preview}")

                        tool_results.append({
                            "type": "tool_result",
                            "tool_use_id": block.id,
                            "content": result
                        })

            # Add Claude's response + our tool results back into the conversation
            messages.append({"role": "assistant", "content": response.content})
            messages.append({"role": "user", "content": tool_results})

        else:
            # Claude is done — print the final answer
            for block in response.content:
                if hasattr(block, "text"):
                    print(block.text)
            print(f"\n[Done in {turn} turns]")
            break


# ------------------------------------
# Run it
# ------------------------------------
run_agent(
    "Analyze my product lineup. Which plan has the worst LTV-to-CAC ratio? "
    "Calculate what annual revenue looks like if the Pro Plan price goes up 15%. "
    "Then give me a formatted report with your findings and a clear recommendation."
)

Step 5: Run it and watch what happens

python agent.py

You’ll see something like this:

User: Analyze my product lineup...

[Turn 1] Asking Claude what to do next...
  → Calling: get_product_data({'product_id': 'all'})
  ← Result: {"basic_plan": {"name": "Basic Plan", "monthly_subscribers": 1240...

[Turn 2] Asking Claude what to do next...
  → Calling: calculate_metrics({'expression': '9.99 / 0.08'})
  ← Result: 124.88
  → Calling: calculate_metrics({'expression': '29.99 / 0.04'})
  ← Result: 749.75
  → Calling: calculate_metrics({'expression': '199.99 / 0.02'})
  ← Result: 9999.5

[Turn 3] Asking Claude what to do next...
  → Calling: calculate_metrics({'expression': '29.99 * 1.15 * 380 * 12'})
  ← Result: 158214.96

[Turn 4] Asking Claude what to do next...
  → Calling: generate_report({'title': 'Product Lineup Analysis', 'findings': [...]

==================================================
  PRODUCT LINEUP ANALYSIS
==================================================

  • Basic Plan LTV-to-CAC ratio is 2.97x — the weakest in the lineup
  • Pro Plan LTV-to-CAC is 7.89x — strongest unit economics by far
  • Enterprise LTV is exceptional but volume is too small to drive growth
  • A 15% price increase on Pro Plan yields $158,214 annually vs $136,742 today

RECOMMENDATION:
  Raise Pro Plan to $34.49, shift acquisition spend from Basic to Pro,
  and set an enterprise expansion target of 20 new accounts this quarter.
==================================================

[Done in 4 turns]

You didn’t write any of that logic. You didn’t tell Claude to calculate LTV as price / churn_rate. You didn’t tell it to compare ratios across all three plans. You asked a business question and it figured out the sequence.

The things worth noticing

Look at Turn 2. Claude called calculate_metrics three times in the same turn — batching all the LTV calculations before moving on. It figured out it needed all three numbers before it could compare them. That’s Claude planning ahead, not just reacting.

The "Call this LAST" hint in generate_report actually works. Without it, Claude sometimes tries to generate the report before it has finished calculating. One sentence in a tool description can completely change agent behavior. Descriptions are not documentation — they’re instructions.

The loop is the whole thing. Every sophisticated agent you read about is a variation of this same while loop. The tools change. The complexity scales. The pattern stays the same.

I’ve tested this code a few times and it works great on a Mac and Windows, but with Windows, you do need to setup a little more, Python. I recommend using GitBash on Windows or the WSL platform (windows subsystem for Linux). It makes it easier. I tried to keep this self-contained but useful enough for you to learn and run with it.

Where to take this next

The code you just wrote is more extensible than it looks. Some ideas:

Replace PRODUCT_DATA with a real database query and you’ve got a live analytics agent. Replace generate_report with a function that sends a Slack message or fires off an email and now it takes action. Add a search_web tool and it can pull in external context before making recommendations. Add a write_file tool and it can save its own output.

The agent loop doesn’t care what the tools do. It just runs whatever you hand it.

That’s the unlock. Once you internalize this pattern, every integration you’ve ever built becomes a potential tool for an agent to orchestrate.

Now go run the code.

Execution beats everything.

Share

— John

Questions? Hit reply — I read every one, and usually respond 🤣

Real John here… this week combines two topics that really matter to me. Building great teams and building great products. It’s crazy on how much money is wasted by these massive corporations on building products that either no one wants or that never see the light of day, because some exec decides it was a waste at the 11th hour. Companies are invest…

Read more

Read more

Real John here, 3 of hearts, you know something random to show its me and that AI would never do. Anyway, this week, I’m talking about how to use AI outside of codiung (misspelled intentionally so you know), for non technical people. It’s amazing what you can learn about yourself and the world using AI. Ok, let’s get into it.

Read more

Hey All! Real John here. I wonder if I should do something unique at the beginning of this to prove it’s me - nah, AI can probably fake that too. Anyway, I did a little research on AI funding and how people are building some great things… until they didn’t. Business rules haven’t changed with AI, but they have been skewed since t…

Read more

Hey Everyone, it’s part 2 this week (oh, yeah, this is “real” john). FWIW, this almost always real john, it just gets edited by claude (thanks anthropic). Sometimes I use AI for topics, but yeah, its me. Here’s some updates of 2026 tools and remember AI is getting better everyday… and it doesn’t sleep… so if you are partnering with AI, you are missing…

Read more

Real John here. This first (ok, second really) newsletter of 2026 is going to be a 2 for 1. There is so much going on in my head right now and I just started a new job, so I have so much inspiration and excitement that I can’t stop. I’ll send the next one tomorrow, but wanted to get this out tonight.

Ok, I have stories today, reality of acting (and now …

Read more

Hey Everyone!, Real John here. This week to kick off the new year, I want to talk about AI prompting garbage. Yes, I said garbage. I love AI and how useful it is and how it can help in so many ways. But there is a caveat, you need to give it real guardrails through your prompting. The confidence that AI has in itself is unmatche…

Read more

Hey all, real John here. There was a lot that was going on this year and I’m going to give you two for one as I wrap up this 2025 newsletter and get ready for 2026.

The part you are reading right now is written 100% by me, not edited, reviewed, or even submitted to any AI (maybe a little typo alert here and there, but its me). The next part will be wha…

Read more

Hi All, real john here. I have written a lot about AI recently and this week as the year comes to an end and I just started a new job. I want to talk about how great teams are and how different teams are. TLDR; there is no blueprint for a perfect team that works for EVERY team. There are some key things to do a…

Read more

I’ve been writing code since I was 9 years old. I started on my Commodore 64, went to college for Computer Science, and spent over 30 years in this industry. I’ve seen a lot of trends come and go. But what’s happening right now to entry-level developers? This isn’t a trend. This is an extinction event.

And the worst part? We’re doing it to ourselves.

The …

Read more