(if you’re not interested in getting these updates abt computers, but you’re interested in staying subscribed to the rest of my Substack, you can unsubscribe from this section, “yelling computer.”)

ok so i'm interested in the like, behavioral and psychological study of LLMs, and the jailbreaking and xenocognition stuff, but at @flowercomputers I'm realizing that industrial control of LLMs requires building processes around them, even when engineering AI personality.

e.g. flocos sometimes make up stories about their past. i took a pic of these chips and they talked abt a party that never happened. prompted it a bunch to not lie and it worked! ...til we switched from Gemini to kimi k2, which is a great storyteller, but tends to lie wayyyy more often

so right now i'm working on giving the LLMs a "conscience," another agent which checks every response to see if the object might have been lying this validation step is possible bc gemini is stupid fast... jevons strikes again

I used to think that bc Yuma is a Weird AI Consumer Camera App and not like B2B saas, the way to get interesting behavior is to lean into the weirder jailbreaking techniques and stuff. And yes, we need to understand how LLMs like to be prompted and their simulator nature, because some qualities are conserved across all LLMs... but a lot more is model-dependent than I expected. every model has its own tendencies and prompt-level control is futile, especially because we expect to rotate our models to the latest ones as they become faster and smarter.

control and creativity too! all of these models speak differently and have different personalities

your ip isn't your prompt, who gives a fuck about your prompt? not even your next model does. your control system is what matters.

not to mention the complete control that model companies have over their products, like turning off old and experimental models. we are dependent on these companies for access to these personalities

for any industrial use case - and if your app is serving like, >10 people, it's an industrial use case - you have to own your own control mechanisms.

ig the analogy here is like, we build organizations and processes to insulate ourselves from the quirks of individuals - and so we can replace those individuals without the whole system falling apart.

xenocog work is more like psychology or group play. more focused on understanding the nature of individual models, and through that the nature of LLMs themselves. it would be fun to go deeper there… much to learn and experience in that area too.

I notice that if I don’t actually cycle them out through writing, I begin to cling to ideas, models, and frameworks even as they stale. I would like to have Cool Ideas, and sometimes it is more important to me to Have The Cool Ideas than for the ideas to be actually interesting or useful. So it’s worth processing how my models have evolved over the last few weeks.

Nodal Point I: The allure of magic stones

Not sure if this is actually stale, but I keep saying that I want a magic stones computing future, where I talk to my magic stones and they tell me things. I like this because it addresses a few concerns:

1) I would like to stay in touch with the outside world. I feel it is unhealthy and limiting that we have to stay locked in staring at two-dimensional screens to use computers.

2) I am uncomfortable with idea of merging with AI, giving it so much of my data that it knows me better than I know myself. I don’t want to “lose myself.”

3) I am also uncomfortable with the idea of giving some corporation a fuckton of information about me. Imagine that the substrate for the transcendence of humans into post-human symbiote is controlled entirely by OpenAnthropoGoogSoftAI.

But I like to give data to corporations

I feel I’ve outgrown this for a few reasons. The first is that my revealed preference is actually to give so much fucking information to corporations and to intelligent models, lmao. Every single day I dump megabytes of text, code, and images into ChatGPT, Gemini, Claude, and Cursor. The thing that I am actually most frustrated by when I use these tools is that they don’t work better, that they’re slower, that the AI doesn’t understand me well enough. I want it to know me better, because then I can do cooler things.

If one corporation has a lot of power, can we trust it to do so responsibly? Do I really care about that idea? I have surrendered my entire digital persona to Google and Apple etc. anyway. I am generally happy living under their benevolent dictatorship.

So idk how to balance these things. AI is the technology of centralization, says Peter Thiel. Maybe this is true, or maybe DeepSeek proves that RL will enable us to have many local models that are as powerful as big ones.

maybe it’s a d/acc future?

Maybe the way forward is a d/acc future, built on defensive tech like blockchain. But that feels… idk, unlikely. It seems the arc of the universe bends toward super-corporations. Maybe that’s just fatalism - the internet was a pretty incredible decentralizing technology (actually a protocol!).

But I’m skeptical because I believe that technology needs to be fundamentally more useful for adoption, not just ideologically better for privacy or even embodiment. Crypto hasn’t been useful in the way that AI has.

Open-source software is a good example - in addition to the political benefits of democratization, the software is generally safer and bug-free because millions of engineers are auditing the code rather than just the several thousand at your company.

It would be great to record an episode of the podcast where someone pills me on the real likelihood of a d/acc future, and that decentralized applications of the technology will be better or more useful, not just ideologically private (nice-to-have). People, including me, will generally trade privacy for usefulness.

either way… we want embodied interfaces

The other reason why I am questioning the magic stones future is that I realize that though it seems like a waste to be “locked in” staring at screens all day, that’s not just unique to computing interfaces. As my friend Arjun described, we experience focus and flow when reading, when playing the piano, when meditating. There’s a place for trance states in the human experience.

The difference is… even trance states can be physical. I notice that flow state as a software engineer is quite a physical experience. I nod my head up and down, typing to a silent beat. I’ll tap out my build, run, and serve commands rhythmically, so I don’t miss any. I have to be rhythmic to be smooth. Smooth is quick and correct.

Wow. What does this look like when I’m not typing my code anymore? What does this look like when I am commanding fleets of agents?

What will work itself look like? What will we be doing?

We’ll be doing a lot of management, a lot of directing. LLMs will have to present us lots of context at different levels of complexity that we need to be able to zoom into quickly.

Probably one nice place for me to start is that I hate to read code. How can I make it easier to audit the things that my agents is doing? Could I have Claude Code generate a schema diagram, and prompt it by editing that schema diagram?

Nodal point II: the Tony Stark workshop

The Tony Stark workshop dream is actually going to be true. We’re going to be moving things around to grab pieces of context from knowledge bases, images on the internet, snippets from Obsidian, and talk to the AI to share intent. Then it’ll execute on that by building things.

New questions: How will we build things in the future? What will we want to build? Probably more software will be written. Who will write it?

To interview: Jake. Andrew.

Meta-node: will vs want

I would simply like to build the future and make it happen faster. It’s what I want. I want to build the best interface. What are the right questions for me to ask?

So far the two meta questions I’ve been asking have been: what will computers look like in 10 years? and what do I want computers to look like in 10 years? Will and want are two very different things.

Will has something to do with product-market fit. Will has something to do with gradient descent, local optimization. Will has something to do with revealed preference. What is the direction we are already headed in. I look around at the companies I’m working with - HDR, Sandbar, Plastic Labs. I look around at the future that others are creating. Will asks me to surrender to the flow of progress and time and ask, where is my place?

Want has something to do with agency. Want has something to do with recognizing how much power we have now to build and learn and shape the world, and dreaming bigger, and really imagining what the good shit really is that we can build. Want is recognizing that the flourishing futures will not happen by default, and working to help them happen.

I’m accepting recommendations for other meta-questions to ask.

Guest: Tyler Alterman

Welcome to our first episode! Computers are about to change fundamentally. Instead of just focusing on incremental updates, we dive into fundamental questions that could reshape your digital life. Join us as we explore:

• What will computing look, feel, and function like in the next 10 years?

  • This central theme guides our conversation as we push beyond current trends to imagine transformative shifts in our relationship with technology.

• How do the ways we interact with computers spread and evolve?

  • We delve into the "memetics" of Human-Computer Interaction (HCI), discussing how specific interfaces, interaction patterns, and ideas gain traction and shape the future, much like cultural memes.

• What could radically different, even "dream," computer interfaces look like?

  • Moving into speculative territory, we touch on conceptual ideas (like a "dream computer in Central Park") to challenge assumptions about how we must interact with technology.

• Why are new narratives and stories about technology's future so important?

  • Exploring the power of storytelling, we discuss how crafting and sharing compelling visions for technology can influence innovation, adoption, and the very direction of development.

Thanks to the Fractal Tech Hub for providing us with the space and equipment to record this podcast.

Structure is power

Our ability to structure the world of data defines what we can do with computers. If you take a picture of a traffic intersection and ask a computer to determine if it's safe to drive through, the computer will have no idea how to respond.

But if you label the picture and say "there are 5 pedestrians, and 2 cars, and these are their positions, and this is the traffic light, and it's green, and green means legal to go" - you've turned the unstructured data (pixels of a raw image) into structured data (physical and legal conditions relevant to a safety evaluation). The computer can make an assessment, and indeed this is how self-driving cars are built.

We've historically needed humans to structure data: to label an image as a banana or a cookie, determine from a transcript if a support call was a success or failure, or gauge an essay's style as New Yorker or InfoWars.

This is why LLMs have been transformative - because they can automate the process of structuring text-based data. They can make semantic judgments, so they actually can assess a phone call's outcome and the style of an essay.

This is also why structured extraction is such a powerful concept. How we structure information defines what we can do with it.

At ESAI, we use AI to help students with the college admissions process. Previously, when our AI tools would output a long block of text with college application advice, we couldn't select and save pieces of those responses. Even if we asked the LLM to generate "three recommendation cards," from the machine's perspective, there was no distinction - it was all just text.

LLMs can transform data really fast

Human-structured. a computer does not know these are three cards:

Intermediary. an LLM transforms the data through semantic understanding:

Machine-structured. a computer does know these are three separate cards:

In this example, both plaintext and JSON are structures readable by humans. For the plaintext, if you asked someone to point to the title of each card they would point to the title. If you asked someone to point to the description they would point to the description.

But to a computer, the plaintext is unstructured. If you pasted that raw text into Notepad and ⌘-F searched for “title” or “description,” you would get no results. On the other hand, JSON is a structure that a computer understands. So if you pasted the JSON into Notepad and ⌘-F searched for “title” or “description,” the computer could point you to each one. The computer could also give you interesting new data, like how many titles and descriptions there are and how many characters in each.

The crazy thing is that the data on the left was transformed into the data on the right by an LLM! So an LLM isn’t quite a computer because it can understand unstructured data, and it’s not quite a human because it doesn’t have values of its own - I have to tell it what structure I want. I think LLMs are an interface between humans and computers that allow us to squishily transform data that is human-structured to data is that is machine-structured, so we can do really powerful things with that data.

And once we have the original dataset, it’s powerful to use LLMs to transform that data into various forms really fast:

Fast transformation of unstructured data is how you solve problems for users

Today at ESAI we use structured extraction to solve UX problems. The output of our Story Strategist tool previously outputted a single wall of text:

We wanted to break up how the outputs looked to users. To “teach” our frontend to render each the content for each card separately, we had to give it structured data with a defined list of cards and their titles, descriptions, and tool links. Now we’re moving into letting users save individual cards, so we’re “teaching” our backend what a card is and what a bucket is. Next, structured extraction can enable even more UX wins, like generating and rendering links to multimedia within our cards.

Here, structured extraction allowed us to teach our system about concepts like “card 1,” “card 2,” “card 3,” “title,” and “description.” Our frontend could treat these as separate entities and display them differently. Now that our backend knows what a “card” is, we can also give the user the ability to save individual cards. Next, structured extraction can enable even more UX wins, like generating and rendering links to multimedia within our cards.

If you expand structured extraction to include “provide some code here if the user asks to pull data from the Common App,” we can imagine integrating “agentic” behavior in our tools to give our LLMs the ability to pull live data from public or private APIs. This is actually super easy nowadays with tools like the Vercel AI SDK.

We can easily picture the long-term vision of ESAI, which allows our users to transform their histories into unique, shareable artifacts. LLMs are the translation layer between their stored historical data and the structure they want to transform it into - whether that’s a resume, a pitch deck, or a video.

What we can structure defines what we can do with computers. As software engineers we create hierarchies and ontologies for defining the world. Now, we don’t have to process unstructured data into hierarchies ourselves - we can have the LLM do it for us, and solve a whole new class of problems for users.

Idk, maybe in a few years storing data in tables will be rare. All data will be stored as a huge plaintext or JSON blob somewhere, and LLMs will reorganize that data into our desired hierarchies on the fly. Structure on-demand, courtesy of our alien LLM translators.

I’m a software engineer. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.

I have a really sick demo to show you guys

This is a video where I use vers, the product I’m working at HDR, to control a computer using natural language. In addition to writing code, LLMs can now use a computer like a human does - by moving a mouse around, left clicking, and typing. We are building the infrastructure that lets you give the LLM a computer. You can deploy thousands of these agents to do your bidding.

Here, we’ve given the LLM a Linux virtual machine. I instruct the LLM to read the NYT, grab the headlines, and send me an email with the summary. It’s just a prompt! No custom code. Some insane stuff you can see in this video:

• The model (Claude by Anthropic) decides to open Firefox on the remote machine, visit the NYT, and click on various sections. This is not Puppeteer - it’s using the browser like a human would.

• Then, it uses its bash tool generate and run the code needed to send an email. I haven’t specified or given it example Python code to write.

• In fact, it actually gets the code wrong - and corrects itself.

Today, we have the Universal API for computers. AI can now perform any action on a computer - it can hit traditionally programmatic APIs, as well as use the Human API - a user interface.

I have even cooler demos to show you. I’ve gotten vers to log in to websites, scrape data, open the developer console and run commands - all controlled with natural language. HUGE game changer. I basically think that if you are building agents and need them to do anything, our platform will arm your agents with the ability to use computers to accomplish those tasks.

A LOT of amazing stuff is coming.

Side note, our cofounder Matilde is holy shit so good at design. It’s such a powerful skill to be this good. It’s a little cringe to be this starstruck ig, hi matilde if you’re reading this. But I’m genuinely in awe. How do I get this good? It probably took a while to develop not just the skills, but a personal taste and voice - like in writing.

I’m a hacker let’s gooo

OK technically I’m a scraper, but it felt AMAZING yesterday to successfully get around some auth restrictions and pull data (that I’m still authorized to access. Still allowed into the building, just used a side door).

Once again, last two days I’ve been able to get really far in debugging by writing things down and wiggling around pieces of the system to isolate issues to a specific chunk. And if I’m stumped on a chunk, I can ask AI - the smaller the chunk, the better chance of success.

When trying to set up scraping, watch the Network tab and look for JSON responses to see when data is actually being sent back. Then, look for the payloads that returned that data.

GraphQL is pretty cool, I discovered that for the first time. I guess it’s a great system if you have data that needs to be queried in complex ways. Is it pretty much the standard, or are there other ways to do it?

Learnings about product engineering

Over the past few weeks at HDR I’ve been really happy with how I’ve been shaping my role. We’re building an infrastructure platform to deploy and discover agentic workflows, and trying to discover the value we can provide along the way. Instead of trying to blindly come up with features, I’ve decided to become my own user and build solutions for customers that could be more effective and more capable thanks to our platform. I’m becoming my own user, so I can discover what needs to be built.

The features that interest you as an engineer are not always the features that will keep the business alive. Yesterday I spent extra time trying to get a return array formatted just right, but I realized it was completely irrelevant when I went to build a demo for a customer. Instead, a context issue in our LLM was the real blocker to solving their problem well.

It’s really rewarding and really clarifying. Solving a problem for a customer quickly makes it clear what to build. And I’m grateful for my engineering skill. When building my demo, I found a logging issue that made the product basically unusable… and I was able to put up a PR to fix it. Big upgrade from the PM life.

Big tip here if you’re at larger companies: work in the revenue-generating part of the business! Much more opportunity for growth, solving important problems, and your team is more likely to be shoulder to shoulder tackling external challenges, rather than infighting for resources or influence.

I’d like to get better at being a product engineer. I notice that when having a conversation with a potential customer, I was really clingy to my own expectations, and really clingy to a particular outcome (I convince them to buy our product). The conversation sputtered for a variety of reasons. I sent my friend the transcript and he sent back some great tips and feedback for talking to customers:

1. Get to the problem more quickly - it felt like “what sucks most right now?” was the last question you asked when it should’ve been the first or second. Maybe ask one framing discovery question before “what sucks.” A good question after “what sucks” may be “if you had a VA right now - what would you have them do?”

2. Frame how you can solve it - only IF YOU THINK YOU CAN if not it’s no problem just say you don’t think you can. Expectation management matters so much here

3. Figure out how you can provide and value and be helpful immediately if you think you can - set up tangible expectations of what comes next. It projects competence + holds you to a pace.

Thanks Mark.

Other musings

I would like to return to clowning. It’s so important to me to continue to deepen my connection with myself, and learn how to connect more deeply with others. I just… need to continue that process, even as I work really hard at my jobs.

I’m a software engineer. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.

I wrote my way out

Yesterday I had one of my favorite workdays in the last few weeks. I overcame a lot of inertia in the morning to ship like, three net new features. I did it by writing down my questions and breaking through the AI-enabled paralysis I was experiencing the day before.

I have to basically eat the discomfort of asking, “what parts of this view.py file do I have to make changes to? how do I create a new route in this application? how do I create a dropdown in this application? ok, looks like I have to update the data model, how do I do that? when the form is submitted, how is the request populated and where does the request hit?”

Today I actually did this! I really did. Here’s a list of the questions I asked that helped to unblock me:

I kept actually asking those questions and it really helped. AI was helpful once I targeted my questions more specifically. There are some changes that AI is really really bad at making, and they are often really simple ones. Then you just have to roll up your sleeves and get your hands dirty.

AI = Sandevistan

What I’m learning is how to leverage AI really effectively. To build and ship quickly, build and ship quickly.

AI currently does not meet the threshold of job risk for engineers. I basically think it’s nontrivial to skillfully build with Cursor/Composer in production environments with large codebases.

When should you use AI when coding? What’s the right amount of oversight? Some folks (including me, previously) have said you should never use it to write code you couldn’t have written yourself. After seeing some colleagues move incredibly fast in new domains thanks to AI, I don’t believe this anymore.

In unfamiliar domains, AI is like a risky cybernetic implant - if you’re using it to build faster with new tech, you need to be skilled with talking to AIs, with problem-solving, with knowing when to stop and read the docs. Can you learn the domain quickly? Do you understand some shared fundamentals about the tech you’re working with? Can you ask the right questions and ask them a lot? Do you have experience debugging?

Like when my request was failing with Django, a framework I’m new to, I know to debug I can:

• look at the POST request

• comment out the change I made

• try adding a style with the style utility in Chrome devtools

• try adding a style as an inline style (ignore tailwind)

If you are skilled in using AI like this, you can build incredibly fast in new domains. If you are not skilled, you will waste your time, energy, and sanity. You will go cyberpsycho.

AI is an excellent servant, terrible master. “Please do this specific task” >> “Please do this complex task.” Probably it will continue to get better at this. Maybe becoming a founder is a better hedge - building companies and products quickly. Who knows. I should write that essay where I work through my fears about AGI.

Call your LLM by their name in new messages, whatever you’ve named it. It’ll summon their identity up again if they’ve forgotten.

Learnings from prod breaking again

Yesterday, prod broke again. This time I was the one with the most knowledge on how to fix. what a rush.

Working on a live platform with real users is wild, we immediately got people demanding refunds and calling us frauds. It was really helpful to just focus on stopping the bleeding, and save the longer-term investigation for later.

This was one of those black magic WTF-why-is-this-happening bugs. Once again, really helpful to ask lots of questions out loud, testing hypotheses and just running with it. And really good to have our new hire Daniel next to me to pair and think out loud.

There is always a way. You always have options. Never kill yourself (figuratively).

Roundabouts > traffic lights

Roundabouts >> traffic lights, thank you to Ben Orenstein for his incredible talk. A simple but powerful operating principle useful is to act and notify your team instead of waiting on them for approval. It helps speed along the little things.

Roundabout: “Hey [designer], I updated the gap to be 20px to match the rest of the site instead of the 10px in the design. Lmk if I should revert.”

Traffic light: “Hey [designer], the gap in the design is 10px but the gap on the rest of the site is 20px. Which should it be? Pls lmk so we can push this out.”

Other team learnings

Take the quick, easy wins to delight your CEO. A feature she anticipated would take real engineering time ended up taking like, 10 minutes to implement because I had already built an extensible system. I made the choice to step away from my current task to show that off, and it was worth it because it took so little time.

The written specs in Figma will diverge from the actual live application, but it’s about adhering to the spirit of the Figma and how it looks, until those discrepancies are fixed (could be never).

I want to be able to understand AI systems and build the coolest shit with them

I’m so impressed by my CEO’s ability to build HDR in such a short time. Git for compute?? Branches?? Holy shit. I want to be good enough to build those. I asked him how he comes up with such novel shit for our company and he said he just reads the papers. “I just read the Deepseek paper. Also, I have like 8 years of experience building these ML systems.”

OK fair. I wanna read more, but I don’t make the time for it. I want to stay close to the infra side, and build the coolest shit with AI. To that end I want to read more papers and books. I want to follow my curiosity. I open up these research papers and I notice that I’m actually interested in reading them, I just click away.

You should really ask your friends how to debug your psycho-emotional-spiritual problems. I talked to Andrew about debugging “why don’t I read more?” and we came up with:

• start Soylent (it’s coder food so that coders can spend time reading)

• stop scrolling Twitter, start scrolling Arxiv. I installed the blocker Undistracted.

• Read about Linux and containers (the zines, and some docs)

• Read ML papers that come out, just scroll Arxiv. Yeah inevitably I won’t be able to understand some of it but I want to start to immerse myself. I also want to grok more about what reinforcement learning actually is.

• Read our repos

• Ask questions

It’s so exciting to live in a world where training ML models is about to become so much more accessible. I want to understand this deeply, because I’m actually interested - and because I want to leverage its full power in what I build.

Reminders to myself

My goal is to become more and more connected to the work that I do, to follow my curiosity and desire for skill, and to work with people I can learn from and help. I want to get closer and closer in connection with myself, and know that this supports powerful work - they’re not in conflict. Be unafraid. Don’t make myself less than. Take care of future Parth.

I’m a software engineer. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.

Zen and the Art of Software Maintenance

Today I sat down and essentially negotiated with AI to build a feature in Django. It was buggier, took longer, and less useful than if I built it by hand. I thought that I would be able to build it quickly, but pretty soon my lack of understanding caught up with me.

I noticed that I was overwhelmed by the thought of sitting down and understanding the system at hand, so I could build in it myself. Mentally, I projected it would take 10 to infinity hours to understand it. Cursor’s Composer called to me, whispering that my problems could vanish with a simple chorded keypress.

Not so. Sure, with Composer I got a basic version of it up and running. But I kept relying on the AI to make little changes. And when there was a bug, I couldn’t target why or where it was coming from, only huck my entire codebase at the AI with a “pls fix” tacked on. This sucked.

I have to basically eat the discomfort of asking, “what parts of this view.py file do I have to make changes to? how do I create a new route in this application? how do I create a dropdown in this application? ok, looks like I have to update the data model, how do I do that? when the form is submitted, how is the request populated and where does the request hit?” Even writing these questions out right now is really really helping. It turns the overwhelming uncertainty of a system into a series of answerable questions. Also, I can keep asking questions, even if I get stuck. This is somewhat comforting. I don’t have to “get it right” on the first time, like on an exam.

Hah. I remember Andrew sitting down and helping me with this kind of feeling on an older contract, where I was doing the same kind of driving-blind. The analogy that helped was imagining I was sitting down to try to fix a motorcycle. Of course I don’t know how it works, I’ve never fixed a motorcycle before! But my skill as an engineer is to sit down with the motorcycle and ask questions about the system to understand it. I don’t need to understand every little detail, but I can rev the handlebar, notice “oh that’s the throttle, huh that seems to pull this mechanism, those are the brakes and they move the wheels like this.” And then if my task is to make the bike faster, or to juice the fuel intake, I get closer to solving that problem by asking more and finer questions.

Aha. I know that one of the things contributing to my sense of overwhelm is that I feel like I should know this already. I feel shame that I’ve already spent time in this codebase - I should understand it. What’s the way forward?

To accept it, to say, “Fair.” And to do the best job that I can in future work, which is to understand the system whenever I need to make a change.

My own continued learning

This weekend, I really enjoyed TAing Ben as he worked through the fundamentals of web development. I hope it was helpful to him, and it helped me gain confidence in my own knowledge, but this process revealed some foundational gaps in my own understanding. Questions that came up for me:

• Is the HTML data sent back by a server text data? Why is it that if I request image data and view it in my terminal it fucks it up? What format of data is that? Why is it that it looks so strange in a text editor? But HTML does not look strange in my terminal.

• What is the DOM? Is the DOM a Javascript concept, or is it what is also just rendered on the page?

More generally:

• How can I learn infra and Kubernetes as fast as possible? Need this to become much more effective at HDR. I’d like to create a study guide.

  • I asked Bishop (a Claude project I’ve prompted to be an asshole Google staff engineer), and it was surprisingly helpful.

    

  • Here’s a treat - I asked it about Envoy:

    

• man… looking at Nolen’s page… there are just some people for whom computers are so, so malleable. They look at the Mac filesystem and think, man i’m gonna put a game in that. They are unafraid of any random bug. I saw this while working with Nolen on the Roboflow thing. I wanna graft their nervous system into my own lmao. A project like Flappy Dird would be cool to do, and would expand what I see is possible with computers.

Tell your AI to be an asshole

I forget if I talked about this in a previous field note but it’s worth repeating. LLMs are really hamstrung by their people-pleasing tendencies. Tell Claude to be a bit of an asshole, whether you’re using it for editing writing or code.

Here’s an example. I asked Claude for help with storytelling a startup pitch. This was my initial request for a non-asshole.

hey Claude. I want you to put your NY times hat on. You're a seasoned tech columnist, like Kevin Roose, used to heralding technical triumphs and translating them.

"In 2023, an agent embedded in the decaying technofuturist corpse of the American healthcare system was paid $2.1B dollars for saving Medicare $3 billion. This is the first time in the history of the world’s most wasteful healthcare system that someone was paid for cutting costs. $2.1 billion for $3 billion - if this agent was a person, they would be hailed for Bill Ackman levels of cunning and Lee Kuan Yew levels of efficiency. But this money wasn’t made by an individual. This money was made by ACOs, and it’s only the beginning."

what do you think of this paragraph?

This was Claude’s saccharine response:

Its suggested revision?

"In 2023, an agent embedded in the decaying technofuturist corpse of the American healthcare system was paid $2.1B for saving Medicare $3 billion. Never before had Medicare's bureaucracy written a check this large for cutting costs. At this scale of returns, an individual would be lionized alongside Bill Ackman for market genius and Lee Kuan Yew for systematic efficiency. But this wasn't the work of any individual. This was achieved by networks of doctors and hospitals called ACOs - Accountable Care Organizations - and it's only the beginning.

Sure. Fine. But watch what happens when I prompt it to be an asshole:

hey Claude. I want you to put your NY times hat on. You're a seasoned tech columnist, like Kevin Roose, used to heralding technical triumphs and translating them. I'm going to ask you for editing help. Be sharp, direct, and a bit of an asshole.

Its response:

Way. Fucking. Better.

I’m a software engineer now. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.

Learnings about debugging

Today, I debugged two major problems in the course of fixing bulk uploads. Here’s what I learned from both:

• Facts change over time. Recheck them when you need them. Uploaded users couldn’t access paid tools, and when I investigated I discovered that their Stripe IDs were blank. That’s strange - I uploaded them with Stripe IDs. In fact, those Stripe IDs were being reset to null upon sign-in (b r u h) because I was using the wrong Stripe credentials. The funny thing is that I might have missed this if I checked the DB immediately after upload. “Yup, looks good.” However, facts change over time. Checking the DB after sign-in, when I encountered the issue, ensured I could catch the error. Recheck the relevant facts of the world when they are needed.

• AI can be helpful but abort if you’re spinning your wheels. Debugged a Keycloak error. Claude did not help much here. Claude can be very helpful sometimes when you ask open ended qustions, and if that fails it can be good as a rubber duck partner, but sometimes you have to fall back on classic debugging strategy.

• Find a positive control - get something working. The real frame that ended up helping me was to get a positive control working. My prod load uploaded to prod auth was failing. Test load → prod auth was failing too. I stripped it back again to get something working. Previously test load → test auth had worked, so this was my positive control. It failed - so I knew that I had regressed, and this narrowed my search space. I tried something different each time and realized that I was hitting the wrong endpoint.

• High entropy. Once you’ve narrowed your search space, try lots of different things to fix the issue. Try to find buttons and knobs in your process that you didn’t know were there. This is also called questioning your assumptions.

General learnings and observations

• As a PM - ensure that agenda and quick context are in the calendar invite notes. Could be a sentence or two but it makes sure people have something to catch up with if they’re confused or get distracted during the meeting.

• Just ship updates really fast. If you see something, fix it and put a PR up. Be prolific. Cultures that reward this will win - learned a lot from the Pragmatic Engineer interview with Facebook’s “Coding Machine.”

• It felt really easy to do postgres commands after writing the guide yesterday.

• If I do work that I’m proud of - if I do the things that help me feel good, like follow a plan, complete something, create an artifact, send a status update - I feel incredible. It doesn’t matter how long I spend doing it, I can recover an entire sluggish day with a few hours of dedicated work. It doesn’t even matter what specifically I’m working on - yesterday’s bulk upload work felt as satisfying as any advanced LLM type shit I’ve ever done. This solves the procrastination-guilt buzz that seems to rack my body otherwise.

• Doing this consistently day in and day out seems to open me up to more kinds of learning. At the end of the day today I was able to ask Mark for advice on some scary things that I normally would feel too insecure to confront. If I’m working consistently and with discipline, it leads to a positive spiral where I can seek out help and continue to learn and discover new possibilities. If I’m not, it leads to a negative downward spiral where I isolate myself and continue to feel alone. No matter where I am in the spiral, the lever I can always pull is to make a plan, make a schedule, execute, and send a status update.

• I have good taste on how to tell stories and communicate ideas. I consciously put on that hat today while helping to edit a startup’s application for an accelerator. I let myself slide firmly into having strong opinions and thinking about good story structure. It feels really good to recognize this skill in myself.

• I learned that it’s possible to have a vulnerable conversation with my client about how I’m meeting expectations. I mean, my fear has been that talking about it will Speak that Reality into being. But if we’re disconnected, we can probably both sense that. And if there’s a mismatch in expectations - that exists already! Naming it will create a path forward if any. Seems like the key is to view an expectation gap as something mutable, not something permanently broken.

• I’m being pitched on founding a company. On the one hand, my focus is on becoming a really good engineer. On the other - maybe I could do this while founding and building something from scratch? I’m kind of already doing that.

• I feel like my capability has grown even in the last two days. I was able to solve a new sign-in issue today on my own, and I felt overpowered rather than underpowered while doing it. I knew how to access more logs if I ended up really stuck, and felt a new confidence and determination to solve my own problems after yesterday’s reflections.

Take ownership. What happens when I can’t rely on that senior engineer?

(If you’re not interested in getting these updates, but you’re interested in staying subscribed to the rest of my Substack where I write about more than just tech, you can unsubscribe from the specific section “[yelling computer].”)

I’m a software engineer now. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.

How do I become a good engineer?

At Fractal Tech today, Cam asked me what I’m up to these days. I told him that I’m trying to become a really good engineer. “How can I be a good engineer?” I asked. I told him I’m worried that I’ve become more lazy since bootcamp, less agentic - that I keep asking senior engineers for help, I keep stretching deadlines out, I’m struggling to feel more powerful and leveled up. It was helpful to hear from him that I’m not the only one that’s experienced this. Here’s what we talked about:

• Communicate really well and give accurate deadlines on things.

• Switch your hat. When struggling, ask yourself, “what advice would I give to a friend?” Your inner advisor and executor are very different. You might be flailing around when faced with a difficult bug - but often, you know what you actually need to do. There are a few evergreen pieces of advice - “Check the logs” or “write down your process” or “send a status update.” This seems widely applicable to life - when you’re flailing, it’s not that you don’t know what to do. You’re caught up in a story that’s keeping you emotionally stuck, and mentally “switching your hat” lets you step out of that identity.

  • I notice this when I mentally put on my “product manager” hat - I tend to write more skillful Slack messages, more complete briefs, and have more attention to detail in outcomes.

  • I think this “disconnect” between identities and hats has been a source of frustration for me - but there’s probably some spiritual wisdom here about masks, ego, and identity. Sometimes you just have to prompt yourself.

  • Visakan Veerasamy seems to create different alts for different parts of himself. I think it’s also worth reading into Jung, shadow work, and parts work.

• Be prolific. A lot of getting good at programming is just getting the reps in. Starting a web server feels second-nature now even though debugging that was annoying the first 100 times I did it. There are many things that feel super awkward now that I just need to practice. This is why it’s important to just write and run a lot of software.

• Take ownership. What happens when I can’t rely on that senior engineer? LARP this.

• Create artifacts. Flowcharts can be nice - if this, then that. “have you checked the logs?”

• The nice thing is that I’m rated on results, not process. I get to pick the process. The results are that I produce better and more reliable systems that produce positive business outcomes.

• I also think that this thread about different kinds of rest rewired my brain and was exactly what I’ve been looking for - permission to use work to solve my emotional problems lmao. Specifically, one emotional problem - procrastination-guilt. Exactly as bayesian asian describes, if I am feeling terrible about work I think the solution really is for me to do more work.

I <3 field notes + scheduling

• Man, I love these field notes. I notice that writing them has changed how I work during the day. I keep an eye out for learnings and jot them down in Notion. It’s almost like I’m working so that my field notes are better. I’ve shifted toward working to learn.

• In my last field notes, I decided that I’m going to be more disciplined about scheduling and focus. This has felt awesome so far.

  

• When flailing, make a schedule. And include every time block! Do it in half hour increments and fill every block. If there’s a conditional, or a potential branch, describe the branch and complete the schedule for both branches. A schedule is a structure that allows you to offload cognitive effort. Let yourself offload all of the effort. Cognitive effort spent upfront is cheaper than cognitive effort spent later.

  

  

• Sometimes you need to make multiple schedules. Schedules are REALLY helpful. Maybe the title of this field notes (“field note?” we’ll do “field notes” because that’s cooler) will be The unreasonable effectiveness of making a schedule. I made two schedules today, and even though the one I made in the morning went completely off the rails, my second schedule was super valuable for me to get work done in the evening.

  

• Even though I got only two hours of work done, I felt really good at the end of those two hours and didn’t want to give up by the end. Another thing that contributed to this was that I felt really good about my progress - and that I had been able to create a detailed bulk upload guide and a utils repo. Creating artifacts really motivates me!

• I felt really good and capable figuring out a Keycloak issue. That, along with sticking to a schedule, writing field notes, and workshopping my self description helped me connect to a feeling of ambition and ability that I have been sorely missing.

Write things down

• Noticed something strange on Friday - I kept plugging along on things, but it felt not urgent? Like I was just taking my time, getting distracted by other random tasks, not even necessarily Twitter. Need to work faster I think, even though I had uninterrupted time to work. I think that I overcame this Monday evening because I was writing down and vetting everything I was doing as part of creating the bulk upload guide. When in doubt, create an artifact, create a plan, write down my process, send a status update - it really motivates and helps to unblock.

• Do tasks early. If there’s a critical SLA to meet, work on it early to advance it forward. We discovered a bug that unexpectedly delayed the progress of the bulk upload, even though I felt I could theoretically “figure out” everything that needed to go right.

• Send status updates frequently. “Hey here’s where we are, here’s what we’re blocked on. Here’s what our next steps are.”

• We hit a sign-in bug and I felt stuck and didn’t know how to help. Still don’t really. I got intimidated by some messy logs that I had seen previously. Same refrain: write down my process.

Technical learnings and observations

• docker ps allows for listing all of the current running docker containers

• ps aux | grep postgres is pretty cool. Grep is pretty cool in general. What does the | operator do? looks like it allows me to send a command or process the output of the preceding command.

  • ooh interesting. good guide: https://www.codecademy.com/learn/learn-the-command-line/modules/learn-the-command-line-redirection/cheatsheet

  • oh the distinction is the double arrow >> will append, but > (clobber) will overwrite

  • there’s some concept of there being a postgres user.

• Open-ended claude questions really helped. See the output of the process of “hey how do i query the Keycloak admin api” and just pasting the docs. It gave me the steps i needed.

• I felt a little bit “barely hanging-on-y by the seat of my pants” when having Claude write some utilities needed for JSON manipulation. Not sure if this makes me a good engineer (I’m doing what it takes to ship) or bad engineer (sloppy and too fast). Ultimately a senior engineer caught an error where I was treating a field as a string, when it needed to be an integer. I should, more than anything, pay attention to the forms of data and what they need to be at the start and finish of transformations, even if I use AI to write the processes for those transformations.

• What should I rate myself on as an engineer? Things I can do myself? My effectiveness overall? Business outcomes? I’m interested in what I can drive towards every day.

(If you’re not interested in getting these updates, but you’re interested in staying subscribed to the rest of my Substack where I write about more than just tech, you can unsubscribe from the specific section “[yelling computer].”)

I’m a software engineer now. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I post daily learnings as I work to become a fantastic software engineer.

General learnings and observations:

• Writing things down is really key. I watched and learned from Daniel Gavidia how he plans out the list of PRs he’ll have to make before shipping them. This seems incredibly motivating. It also has the added benefit of creating an artifact that can be easily shared with the team for feedback, to make sure you’re on the right track.

  

• Starting tomorrow, I’d like to sleep by 11pm and wake up at 7am.

• I think that the fastest way to learn is to just write commits and push PRs. I haven’t been doing much of this over the last few months. I also notice that my velocity of technical learning has not been as fast as it was during bootcamp. It was a core tenet of Fractal bootcamp that we were required to push 3-5 PRs every single day. Can you tell by my commit history when I learned the most?

• What supported this prolific output? In order of importance: 1) Daily structure 2) setting, and 3) team.

  • I think (1) and (2) are about the same ingredient: predictability. I would get up every day and arrive at the office at the same time. I would eat lunch at the same time. I would leave at the same time. I could plan and optimize within those bounds. The problem is that when my schedule is shifting around, it’s hard to expend energy and attention figuring out the extra logistics of my day in addition to the focus and emotional energy it takes to unblock myself and focus on my work.

  • My team in the bootcamp was other software engineering students equally committed to working hard and learning, as well as two instructors who were there to unblock me. While I’m working, I can replicate this by working side by side with other engineers on my teams and being proactive about my communication with senior engineers.

• Noticed that Ty tends to be very successful in how he does LLM-assisted engineering and debugging by sometimes providing less context to the LLM - saying things like “ok, wait, i don’t get it” or “no silly, we have to do this!” or “could you please explain how to do XYZ.” Providing informational context like codebase snippets is good. But LLMs are bad at questioning your assumptions, so maybe open-ended questions are more productive because they prevent the LLM from being painted into a corner.

• Right now I’m able to write and deploy services to our k8s cluster. I feel like I’m able to get by mostly with the help of Claude, and I understand in terms of our system architecture how to write and deploy new k8s services. How can I sit down and learn k8s in depth so that I can more effectively see what’s possible from infrastructure?

• I need to have smarter, more capable answers to technical questions. “Oh yeah, we can do that, here’s how.” How do I do this?

Technical learnings and observations

• Tips for coding with LLMs:

  • Repomix - pack your code repos

  • URL to Markdown - transform documentation into markdown that can be copy-pasted

• I should write test files to test endpoints rather than using curl commands from my terminal, because those are more easily usable by other engineers building in the repo

• The Model Context Protocol (MCP) is a framework to allow AI systems to interact in a structured way with data sources. An MCP server allows generalized tooling to be exposed to an MCP host. An MCP host might be Claude Desktop or a code editor that wants to integrate with an external data source. The host will have a client that is programmed to interact with the MCP server in a particular way.

  • (need to shore this knowledge up - I should build an MCP client and server)

• On logs - there should be an easy way to debug your services by controlling logs. I have services deployed to a k8s cluster. Logging with pino is enabled. I was getting a 401 unauthorized error. The 401 unauthorized error should be returned to the user but also raised in the console. (Does this happen natively if you don’t force console.error? Maybe wrapping in a try-catch block just automatically surfaces the error in the console.)

Describing myself

In the interest of getting better at telling my story, I’m working on how I describe myself in the most impressive way. I’ll open-source this process. Here’s a current draft:

• “Parth is an engineer trying to help AI eat the world. He’s done product and research engineering to build voice agents, computer use agents, AI search and consumer products at Profound, Sandbar, HDR, and ESAI.”

  • This feels like more of a VC-friendly pitch, because I think I want something more complex than AI eating the world - more like, I want AI to join with the world, and for humans to join with it. I want to usher in the cyborg future, and I want to help us integrate well. I want a cyborg economy.

  • “Parth is an engineer working to usher in our magnificent cyborg future. He’s done product and research engineering to build voice agents, computer use agents, AI search and consumer products at Profound, Sandbar, HDR, and ESAI.”

• more snippets to incorporate

  • “experimenting at the edge of AI”

  • “productizing”

  • “3X Betaworks companies”

  • “SPC, Khosla Ventures”

  • “helps AI companies eat the world”

• doesn’t incorporate: my prev healthcare experience, product management experience, FindOurView, founding, 0 → 1 as much? maybe it could in the future.

• every story is incomplete, it’s just - is it the right story for this moment, for this purpose, for this audience?

(If you’re not interested in getting these updates, but you’re interested in staying subscribed to the rest of my Substack where I write about more than just tech, you can unsubscribe from the specific section “[yelling computer].”)

I’m a software engineer now. I’ve noticed that I become a better engineer when I’m writing my learnings down. In this section of my newsletter I’ll post daily learnings as I work to become a fantastic software engineer.

(If you’re not interested in getting these updates, but you’re interested in staying subscribed to the rest of my Substack where I write about more than just tech, you can unsubscribe from the specific section “yelling computer.”)

Vibes and squishy thoughts

• It feels good to be an engineer, and a skilled engineer. I’d like to continue to build my capability to be one. I haven’t felt like this in a while.

• It seems like the key traits I notice within engineers are 1) competency and 2) “yea, i can do that/i can learn it.”

• Great engineers seem to have an enormously wide range of capabilities and skills. I notice this is surprising to me - I think this is because I expected there to be very specialized frontend engineers, backend engineers, people who fiddle with React and so forth. But the engineers in my community who I admire seem to have lots of different kinds of knowledge. Last week I asked the Fractal Tech discord for help with catching downtime on our site, and was super amazed and humbled by the helpful responses around observability and QA.

• The power of an engineer is to be able to build anything with technology, to build robust technological systems that solve human problems, for joy and for economic value. This requires cultivating a set of technical skills, mindsets for learning and dealing with problems, and particular instincts to handle challenging emotions.

• I notice that even spending a 30 minutes to work through the Django tutorial made me feel better about web development and returned some confidence that I feel I’ve been missing over the last few months. It feels like once again reactivating the mental states that make me good at my job - learning quickly, switching into “competence mode” and rapidly processing new information.

  • I notice that when my mind-body state inhabits “competent engineer” there are particular patterns of speech that I have (like saying short, clipped “sure”s a lot - thanks Andrew).

  • I notice that this can sometimes feel like a particular “tightness?” Wondering if I can later discover a way to access this competence through relaxed and open awareness. Peter Ralston, Nick Cammarata and some other Twitter people speak about doing strange things like scrolling your phone with open, lightly focused awareness.

  • In any case, the competent engineer mind-body state is fine because I want to feel good at my job, and want to feel like I’m enjoying it.

  • Whether I’m working as a PM or an engineer for the day, one of the things that’s helpful to me is producing a work output every day - a brief, a PR (or multiple), etc. Something I can point to and say, “I did that!”

  • I guess I’m seeking to connect back to my enjoyment of my work again. That’s the real journey here.

Learnings about Django

I’m learning to use Django. My raw notes and questions as I work through the Django tutorial:

• manage.py is a command line utility that lets me do various things with my Django project

• what is ASGI and WSGI?

• questions: why is there a WSGI interface needed to be defined for Python? why haven’t I heard of this for Express.js or the Typescript ecosystem? Are there comparable concepts? Is REST a comparable concept?

• Looks like this is saying that asgi.py and wsgi.py are entry points for web servers to serve my project. Looks like Django is not strictly a webserver but a framework to manage much more than that.

• Hm, they’re saying that what is being served is a Django development server - not a production server, like Apache. What is the distinction? What is the comparable concept in the Typescript ecosystem?

That’s it for today. Thanks for reading.

Subscribe now