AI in Practice: 20 Answers, Straight to the Point

The explanation

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.

Key takeaway

• If the app helps you manage projects while you're away, keep using it.
• If every notification makes you feel guilty, open one session at a time.
• It's a workflow preference, not a rule.

Go deeper at INEMA

The explanation

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.

Key takeaway

• No API: one agent looks at the other's screen.
• Explain the goal and your decision criteria.
• Computer control is a powerful permission: use it carefully.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Terminal: when you need to see every step.
• App: when the result and tests are enough.
• Tools that work together matter more than the “right” interface.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Today's models can already do a lot.
• Automated attacks are growing faster than defenses.
• Protecting what already exists has become a priority.

Go deeper at INEMA

The explanation

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.

Key takeaway

• “I build with AI” on its own doesn't set you apart.
• Understanding the business and teaching the team are more valuable.
• Development is still part of the work, but it's one part of a broader service.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Runway = months until the next milestone + a buffer of ~6 months.
• Test the timeline against a pessimistic scenario.
• Evaluate runway and terms together.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Fixed costs, cost of growth, infrastructure per customer, and a buffer.
• Always model two scenarios: good and bad.
• A high valuation today can cost you dearly tomorrow.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Weekly: quick check.
• Monthly: deep analysis.
• Quarterly: comprehensive testing, with a specialist if needed.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Model ≠ system.
• Tools, memory, and strategy make the difference.
• Same model, different results.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Local = control.
• Provider = paid convenience.
• The model and tools can run in different places.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Frontier model: you can imply more.
• Smaller model: clear goal, context, and guidance.
• The client's question defines the scope.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Attempt ≠ proof.
• Each failure can teach you something for next time.
• A person still needs to guide the process.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Building and inspecting are different jobs.
• Choose your role before choosing a course.
• Teaching and advising are options too.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Test what you own and read through the agent's steps.
• Don't understand something? Look it up right away.
• Offensive or defensive: choose before taking a course.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Talk about the industry, not their flaws.
• Ask permission before looking.
• Be clear about what you can do.

Go deeper at INEMA

The explanation

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.

Key takeaway

• A new feature doesn't create demand.
• Start with the business problem.
• Bring in the system if it solves the problem.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Add a rule to AGENTS.md.
• The API is the foundation; MCP and CLI sit on top.
• A release isn't complete until everything is updated.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Approved program ≠ model without safeguards.
• Always make context and authorization explicit.
• In the program, the provider handles operations.

Go deeper at INEMA

The explanation

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.

Key takeaway

• Train from scratch only for a clear reason.
• Adapting an existing model solves more problems.
• “Improves on its own” needs evidence.

Go deeper at INEMA

The explanation

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.

Key takeaway

• 48 GB ÷ 2 ≈ 24 GB for the model.
• 4 bits: ~0.6 GB per billion → 20 billion ≈ 12 GB.
• On a Mac, use the MLX version.

Go deeper at INEMA