Jesal Gadhia

building @cora_ai | prev @thoughtful_ai @BetterUp

[Jesal Gadhia @jesalg]

2024: prompt engineering
2025: context engineering
2026: harness engineering
2027: engineering

[David Sacks @DavidSacks]

Q: How are job postings for software engineers rising rapidly despite AI agents automating coding?

A: Because there’s far more code to manage than ever before. We’re already seeing a 14x YoY increase in GitHub commits, and it’s accelerating.

AI has dramatically lowered the cost of writing code, so it’s now being used across far more businesses, applications, and use cases.

We’re at the beginning of a massive productivity boom driven by the proliferation of bespoke software throughout the entire economy.

Coding has been AI’s breakout use case this year. The fact that it’s increased demand for software engineers — rather than decreased it — should call into question the entire “AI will cause mass job loss” narrative.

[Jesal Gadhia @jesalg]

Fully agree.

The moment the agent starts writing an HTML email template, though, all the formatting benefits collapse, most email clients strip the CSS, and you're back to debugging email client quirks. Markdown (with controlled HTML post processing) or plain text still wins there.

[Gokul Rajaram @gokulr]

POD-OF-ONE: THE NEW ORG BUILDING BLOCK

As a @coinbase board member, t’s been a privilege to watch @brian_armstrong @emiliemc, and the Coinbase team build a true AI-native company.

Brian's whole post is worth reading in depth. I want to focus in on one thing that Coinbase is testing: “one-person product teams.”

Most of the AI discourse has focused on one-person companies. The more powerful and more broadly applicable construct will likely be one-person teams inside companies.

The old product org split context across 3 people. The designer held the user experience. The PM held the customer and prioritization context. The engineer held the code and systems context. Coordination was the price you paid to combine those views into one shipping decision.

Agents reduce that coordination cost.

A single high-agency person can now ask agents to draft flows, write code, run QA, summarize customer feedback, generate variants, check edge cases, and produce release notes.

This model rewards a very specific kind of builder:

• Technical enough to inspect the work
• Product-minded enough to choose the right problem
• Tasteful enough to reject mediocre output
• Fast enough to ship before the org forms around the idea

The scarce skill is judgment.

One strong person with customer context and good taste can now do the work of a small pod. One weak person with agents just creates more output for someone else to review.

This changes how early-stage founders should hire.

The most useful hiring question is now: “Can this person own the outcome end-to-end?”

That’s a higher bar than a functional job description. It blends product sense, technical range, design taste, writing clarity, and operating discipline. The title matters less. The span matters more.

Call it pod-of-one thinking.

A pod-of-one builder can go from ambiguous customer pain to shipped v1 without waiting for specs, mocks, tickets, handoffs, or meetings. Agents fill in missing labor. The human carries the context.

Teams still matter. They should form when the surface area is real: multiple customer segments, production risk, complex GTM loops, or enough product depth that specialization pays for itself.

Before that, a pod-of-one may be the fastest shipping unit in the company.

Founders: hire people who can be pods-of-one, who can carry the whole problem in their head and use agents to increase their throughput.

[Javarevisited @javarevisited]

When an Ex-FAANG Engineer Joins a Startup 😂😂

[Mihail Eric @mihail_eric]

Had a great time chatting with @Dpbrinkm from the @mlopscommunity about the future of software engineering in the age of AI.

Some of the most important takeaways:
- AI agents make senior engineering judgment more valuable, not less
- Agents may become part of how junior engineers learn and close the apprenticeship gap
- Writing code is becoming less of the bottleneck than validating it
- The real limit on autonomous agents is verifiability
- “Run more agents in parallel” is often more hype than reality
- Engineers are being pushed earlier toward planning, delegation, and system-level thinking

[Jason Zhu @jayyzhu]

Movie parody launch videos usually miss.
This one doesn’t 🫶

500 Days of Summer, but SaaS

[ndx @netdragon0x]

I have seen how they built this, and it is one of the best examples of applying good taste to agentic business flows.

You can be a company that adds high risk agents like OpenClaw, or you can offload autonomy to a team that gets it.

[Jesal Gadhia @jesalg]

Excited to introduce the world to Cora.

@a_ghowsi and I have spent our careers scaling B2B companies. We've tried every post-sales solution out there. Support chatbots, customer success platforms, and custom internal tools.

But in the B2B world, a reactive support chatbot won't save your customer relationship. Neither will more dashboards and CRM fields.

Now we have Cora.

[cora.ai @cora_ai]

It's time to break-up with the old way of running post-sales.

@cora_ai - the first proactive AI agents for customer success.

Winning the deal is just Day 0. Cora is the AI for everything that comes next.

[Deedy @deedydas]

Narrative violation. Cursor goes $1B to $2B in 3mos.
Claude Code went $0 to $2.5B in 8mos.

Everyone in the tech/X bubble think people are wholesale ditching Cursor, but enterprise diffusion is glacial. Most of the world just got a hold of it.

[Ejaaz @cryptopunk7213]

LMFAO be anthropic:

> wake up, make coffee
> scroll boomer companies worth billions of dollars
> pick one
> "hi claude make a better version of this make no mistakes ty"
> wait 1 hour
> "looks good"
> *push to prod*
> post tweet about how you just displaced boomer company with new feature

> profit

[Symoné B. Beez @SymoneBeez]

Tech careers are now split into 3 tracks

[Jack Clark @jackclarkSF]

People leaving regular companies: Time for a change! Excited for my next chapter!

People leaving AI companies: I have gazed into the endless night and there are shapes out there. We must be kind to one another. I am moving on to study philosophy.

[Jesal Gadhia @jesalg]

What Year One of Building an AI Company Taught Me https://t.co/plCxspnYFH

[Jesal Gadhia @jesalg]

What a year. I used Cursor for 252 days straight 🤯

[Jesal Gadhia @jesalg]

So well put. Small teams win on shared context, not a zoo of services.

Mothership & shuttles are the way to go:

One codebase where everyone can reason end-to-end. Async and bursty work is offloaded to functions that run on serverless runtimes.

Ship a great monolith first. Earn your distributed system later.

[DHH @dhh]

Microservices is the software industry’s most successful confidence scam. It convinces small teams that they are “thinking big” while systematically destroying their ability to move at all. It flatters ambition by weaponizing insecurity: if you’re not running a constellation of services, are you even a real company? Never mind that this architecture was invented to cope with organizational dysfunction at planetary scale. Now it’s being prescribed to teams that still share a Slack channel and a lunch table.

Small teams run on shared context. That is their superpower. Everyone can reason end-to-end. Everyone can change anything. Microservices vaporize that advantage on contact. They replace shared understanding with distributed ignorance. No one owns the whole anymore. Everyone owns a shard. The system becomes something that merely happens to the team, rather than something the team actively understands. This isn’t sophistication. It’s abdication.

Then comes the operational farce. Each service demands its own pipeline, secrets, alerts, metrics, dashboards, permissions, backups, and rituals of appeasement. You don’t “deploy” anymore—you synchronize a fleet. One bug now requires a multi-service autopsy. A feature release becomes a coordination exercise across artificial borders you invented for no reason. You didn’t simplify your system. You shattered it and called the debris “architecture.”

Microservices also lock incompetence in amber. You are forced to define APIs before you understand your own business. Guesses become contracts. Bad ideas become permanent dependencies. Every early mistake metastasizes through the network. In a monolith, wrong thinking is corrected with a refactor. In microservices, wrong thinking becomes infrastructure. You don’t just regret it—you host it, version it, and monitor it.

The claim that monoliths don’t scale is one of the dumbest lies in modern engineering folklore. What doesn’t scale is chaos. What doesn’t scale is process cosplay. What doesn’t scale is pretending you’re Netflix while shipping a glorified CRUD app. Monoliths scale just fine when teams have discipline, tests, and restraint. But restraint isn’t fashionable, and boring doesn’t make conference talks.

Microservices for small teams is not a technical mistake—it is a philosophical failure. It announces, loudly, that the team does not trust itself to understand its own system. It replaces accountability with protocol and momentum with middleware. You don’t get “future proofing.” You get permanent drag. And by the time you finally earn the scale that might justify this circus, your speed, your clarity, and your product instincts will already be gone.

[dharmesh @dharmesh]

"Why should companies pay for SaaS (HR/CRM/ERP/etc.) when they could just vibe code them?"

I get variations of this question or comment with some regularity (granted, it's sometimes just me talking to myself).

Here are some biased (but hopefully, well-considered) thoughts:

1) I am a big proponent and user of vibe coding (what I call "agentic coding"). I do it every day, 7 days a week, including Sundays. It's amazing.

2) My company, HubSpot is a software company. We have hundreds of professional engineers -- just about all of them use AI for product development too. They are brilliant and know how to build production-grade products.

3) Even with this powerful army of talent, the number of internal, core SaaS applications that we have replaced with a vibe-coded variant is exactly ZERO. The number of applications we plan to replace is also exactly ZERO.

4) It's not the absence of talent that keeps us from rolling our own SaaS apps, it's the presence of focus. It would be silly to try and replace our HR, team collaboration, expense tracking and 100+ other SaaS apps we use when we can just buy them. Just doesn't make sense.

5) That's us -- as a software company at some scale. If you're a non-software company it makes even less sense for you. Doesn't matter how good the AI coding tools get. Let's say you *could* vibe code a replacement for that SaaS app you're using, who's going to maintain it? Who's going to keep up with industry trends? What are you going to do when the 20-something genius that vibe coded it over a weekend leaves the company? Who do you call when there's a major bug?

6) If you're a Fortune 500 company at some scale, perhaps you could pull this off for some discrete use cases and the tradeoffs are worth it. You have an IT/Engineering department that is larger than the population of some countries. You can take on the pain in return for the positives.

For the millions of others, my advice is:

Spend every calorie possible on creating value for your customers.

[Aaron Levie @levie]

We’re starting to get a clearer sign of how vast the surface area of context engineering is going to be.

To build AI agents, in theory, it should be as simple as having a super powerful model, giving it a set of tools, having a really good system prompt, and giving it access to data. Maybe at some point it really will be this simple.

But in practice, to make agents that work today, you’re dealing with a delicate balance of what to give to the global agent vs. a subagent. What things to make agentic vs. just a deterministic tool call. How to handle the inherent limitations of the context window.

You had to figure out how to retrieve the right data for the user’s task, and how much compute to throw at the problem. How to decide what to make fast, and suffer potential quality drops, vs. slow but maybe annoying. And endless other questions.

So far there’s no one right answer for any of this, and there are meaningful tradeoffs for any given approach you take.

And importantly, getting this right requires a deep understanding of the domain you’re solving the problem for. Handling this problem in AI coding is different from law, which is different from healthcare. This is why there’s so much opportunity for AI agent plays right now.

[Akshay Kothari @akothari]

My team: what’s our 2026 plan?
Me:

[Aaron Levie @levie]

The counter dynamic to the AI model doing everything is that, at least in enterprise, bridging the AI models’ capabilities to the customer’s environment still requires a tremendous amount of long tail work.

The gap between an AI agent working for 90% or 95% of the solution and 100% is usually about 10X more work than most realize.

Getting access to the enterprise data, connecting to the enterprise workflows, delivering the change management that employees need to adopt the technology, handling the regulatory and compliance requirements of that industry, and so on all require some degree of highly dedicated focus in a domain.

There’s a strong analogy to vertical SaaS here actually. One would have thought that horizontal technologies could solve all problems in SaaS. But in fact there are endless very large companies that just hyper focus on a single domain, because that level of specialization is valued by the enterprise.

We will likely see the same play out with AI Agents in the enterprise as well. And in fact these domains will be far larger than traditional software categories because the TAM isn’t software, it’s work to be done.

Very fun debate, but I’m taking the other side.