AI in Practice: 20 Answers, Straight to the Point

Apps like this (Duet, which shows your agents and projects on your phone, is one example) work well for people who already have their tools connected through MCP servers (connectors that let an AI assistant use other programs, such as email, calendars, or spreadsheets) and want to keep an eye on projects away from their computer.

The downside is opening the app and finding seventeen reminders about things you haven't done yet. Instead of helping you stay organized, that adds stress.

One alternative is to deliberately open the assistant session you want to work on now, without every unfinished project vying for your attention.

With both apps open, you can ask Codex to keep an eye on Claude: check what it produced, navigate, answer a question, open another session, or unblock something that stalled overnight.

What makes this work is the context you provide: the goal and the decisions you would make in Claude's place.

Note: to interact with the screen, Codex needs permission to control the computer (mouse, keyboard, and windows). Grant that permission only on a machine and account with no sensitive data open, and supervise the first few sessions.

You can also coordinate the two through the command line, but the desktop apps get the job done without adding another system to maintain.

For example, you might move automated tests from GitHub Actions (GitHub's service for running tasks in the cloud, which charges for usage time) to computers in your own office. With the terminal (using Warp, for example, which can access other machines on the network), you can see every incoming request and make sure each task runs on the right computer.

In a typical build, you don't need to follow every line of code. It's enough for the result to work and the right tests to pass.

No one needs to copy someone else's setup. Everyone will have their own mix of tools; what matters is that they work together.

Today's models are already capable enough for a lot of useful work. The bigger concern is that people who already know how to attack systems can now do it with much more automation and at a far greater scale.

Meanwhile, companies keep launching apps they don't fully understand.

That's why it makes sense to spend more time protecting what has already been built, helping companies see their risks, and preparing your own business for a more challenging environment.

People who only develop software are already feeling the pressure: freelancer sites list complex projects at very low prices. If your only offer is “I'll build this with AI,” you're competing with more and more people and tools.

Companies still need someone who understands what they're trying to achieve, knows where it's worth investing, can find problems, and can teach the team to use the tools the right way.

There are still good development clients. But more attention is worth giving to business consulting and team training.

Starting with your own resources (also called bootstrapping) keeps you in control.

If you need an investor, here’s a practical way to decide how much runway to raise: count how many months remain until the next milestone that will make the company clearly more valuable (revenue, customers, a finished product), then add about six months of buffer for delays. Test that timeline in a pessimistic scenario; if the numbers don’t work, you’re short on cash. If your calculation comes out between 18 and 24 months, go with 24: fundraising often takes longer than planned these days.

More money gives you room to get through a rough patch, but a large round with suffocating terms creates another problem. When comparing offers from angel investors (people who invest their own money in early-stage companies) or venture capital funds (firms that invest other people’s money in companies that could grow quickly), remember that where the money comes from, what investors expect from it, and how much control you keep matter as much as the amount on offer.

Answer with numbers: what are your monthly fixed costs? How much does growth cost? If the product gets more customers, how much will the infrastructure bill increase? How much buffer do you need for delays or a contract that takes longer than expected?

Run both an optimistic and a pessimistic scenario. Then ask whether you'll need another round.

Watch out for the valuation trap (the value an investor says the company is worth): raising at a high valuation and then needing money at a lower one can force you to give up far more of the company than you expected. The largest available round isn't always the best one.

A practical cadence is to divide the work into levels: a quick weekly check and a deeper monthly review.

A third level, with much broader and more expensive tests, can happen every quarter. This full assessment still requires a specialist or an advanced tool; in the meantime, a hired specialist can cover this role.

Over time, save the patterns found in each round so the tests become more useful and you don’t have to explain the same approach to the agent every time.

An “uncensored model” is an AI model with safeguards removed so it won’t refuse risky requests. That alone doesn’t make it a security tool: the software around the model determines which tools it can use, what it remembers, how it follows up on a finding, and what it tries when an approach fails.

A system built specifically for security testing gives a model a much more useful workflow than a generic chat window. Talks at security conferences like Black Hat are a good starting point for seeing how these agents and their tools are put together.

That’s why it’s useful to keep the model separate from the system around it: the same model can produce very different results depending on how the system is built.

Running it yourself gives you more control over the setup. A hosted service takes care of the infrastructure and charges for that convenience. RunPod, a service that rents out powerful GPU computers by the hour, is one option for hosting a model when your machine can't handle it.

Keep separate where the model runs from where the tools run. Moving the model to the cloud doesn't automatically move the rest of the testing workflow with it.

And always: test only with the system owner's permission and with the scope (what can and can't be tested) agreed in writing beforehand.

Frontier models are better at understanding what you mean, so you can leave more things implied.

With smaller models, it helps to give clearer goals, more context, and more guidance when they get stuck.

For security work, everything starts with the client's specific question: Are customer records exposed? Can a payment safeguard be bypassed? Or do they need a general assessment? These are different engagements, and the request and scope should reflect that.

Imagine an authorized test on a small online store: the agent tries to buy a product by changing the price along the way.

There's a big difference between an agent trying something and proving it worked. Seeing an attempt to change a price doesn't prove that the server (the store's computer that actually records the order) accepted the change.

During testing, the system gathers information: a failed approach may reveal an address or detail worth investigating in the next attempt. In practice, it's still useful to have a person guiding the agent; write down what worked so you can repeat the test without explaining everything again.

Building something without examining the engineering details and inspecting a system for flaws are very different activities. Security requires attention to detail.

Becoming a developer and then retraining in security takes a lot of work—and may not even interest you.

Some people are better suited to teaching, consulting, or helping companies recognize when they need a specialist. Choose your role before taking on another long curriculum.

Much of the learning comes from testing your own applications and reading, step by step, what the agent tried.

When you come across something you don’t understand, stop and investigate: what does this term mean? Why did it try this approach? What would prevent this problem?

Also decide whether you’re interested in offensive security (attacking to find vulnerabilities, with permission) or defensive security (protecting systems), since the courses are different. Be transparent with clients about your experience: not having a certification is fine; pretending to be an expert in everything isn’t.

A better approach: companies in their industry are facing certain issues—would they like help checking whether those issues affect them too?

Give them a reason to talk. Ask for permission. Explain what you can examine and what you're qualified to do.

Showing up and saying “I've found all your flaws” is a terrible way to start a relationship.

The company may already have a tool that meets all its needs. Saying your version is more customizable may not make a difference to them.

A foundational business system gives people something to build on—it doesn't promise that every company needs someone to install that exact thing.

The offer is stronger as part of a broader service: understand the business, find what's missing, and deliver the system if it solves that problem. Another feature on its own doesn't create demand.

First, the terminology: the API is the interface your system provides so other programs can communicate with it. The MCP server (the connector AI assistants use) and the CLI (the command-line version used in the terminal) are two ways to use that same interface.

Add a simple rule to AGENTS.md (the instruction file coding agents read when they open a project): when the API changes, check the MCP server and CLI and make any necessary updates.

The API is the foundation these interfaces depend on. Changing the foundation and forgetting what was built on top of it creates an organization and maintenance problem.

A release is only complete when its connected interfaces have been updated too.

Some AI providers have programs for security professionals: you identify yourself, explain the work, and the provider grants broader use with rules and oversight. An uncensored model has none of that.

In defensive work, be clear about what belongs to you, what the client has authorized, and what you're testing. Don't expect the provider to guess the context behind an ambiguous request.

One practical difference: in the provider's program, you pay for usage and the provider handles hosting; you host and maintain your own model yourself.

Have a reason for the training project. A small model for a specific task is very different from trying to create yet another general-purpose model.

For most people, the more useful path is learning to adapt existing models and get the behavior you need from them.

And be skeptical of claims about models that “improve on their own”: not every claim like that proves it already happens the way people imagine.

Parameters are the model's “learned numbers”; the more parameters it has, the more memory it uses. A rough rule of thumb is to reserve about half your RAM for the model—around 24 GB here. It's a conservative starting point (your Mac can use more), not a technical limit.

Here's the math: in the most common compressed version (quantized to 4 bits), each billion parameters takes around 0.6 GB. A 20-billion-parameter model comes to about 12 GB, and the rest of the 24 GB covers the conversation's memory. The system and other programs continue to use the other half.

Don't start by choosing the biggest model that fits on the machine: with some headroom, the computer remains usable while the model runs. On a Mac, look for the MLX version of the model, optimized for Apple's chips.